FFMpeg audio codecs for transcoding

[tdiguy 96]

I hate to ask but would it also be possible to enable support for libmp3lame or libfdk_aac?

I am not sure which sounds better mostly because i am a terrible judge of audio quality. both however seem to be less demanding than the built in aac encoder.

sample use:

-c:a libmp3lame -c:v h264_omx out.mp4

 -c:a libfdk_aac -c:v h264_omx out.mp4

 

 

Thank you very much.

 

[Luke 37161]

Why do you think they're less demanding? Is there any evidence to support this? 

 

@@Waldonnis

[tdiguy 96]

Here is a comparison:

Using libfdk_aac:

./ffmpeg -i Jeopardy\!\ 2017-10-06\ -\ 10-06-2017.ts -c:a libfdk_aac -c:v h264_omx out.mp4  ffmpeg version git-2017-09-30-148c8e8 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 6.3.0 (Raspbian 6.3.0-18+rpi1) 20170516
  configuration: --arch=armhf --target-os=linux --enable-gpl --enable-libx264 --enable-nonfree --enable-libfdk-aac --enable-libvpx --enable-libopus --enable-librtmp --enable-libmp3lame --enable-gpl --enable-omx --enable-omx-rpi --enable-version3 --enable-decoder=mpeg2_mmal --enable-mmal
  libavutil      55. 77.101 / 55. 77.101
  libavcodec     57.106.104 / 57.106.104
  libavformat    57. 82.102 / 57. 82.102
  libavdevice    57.  9.101 / 57.  9.101
  libavfilter     6.106.100 /  6.106.100
  libswscale      4.  7.103 /  4.  7.103
  libswresample   2.  8.100 /  2.  8.100
  libpostproc    54.  6.100 / 54.  6.100
[mpeg2video @ 0x1f1e3a0] Invalid frame dimensions 0x0.
    Last message repeated 9 times
[mpegts @ 0x1f19ee0] PES packet size mismatch
    Last message repeated 1 times
Input #0, mpegts, from 'Jeopardy! 2017-10-06 - 10-06-2017.ts':
  Duration: 00:04:23.43, start: 19542.387033, bitrate: 2365 kb/s
  Program 131
    Stream #0:0[0x8c0]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, top first), 720x480 [SAR 8:9 DAR 4:3], Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x8c1](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 384 kb/s
    Stream #0:2[0x8c2](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 192 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video (native) -> h264 (h264_omx))
  Stream #0:1 -> #0:1 (ac3 (native) -> aac (libfdk_aac))
Press [q] to stop, [?] for help
[h264_omx @ 0x1f6f9e0] Using OMX.broadcom.video_encode
Output #0, mp4, to 'out.mp4':
  Metadata:
    encoder         : Lavf57.82.102
    Stream #0:0: Video: h264 (h264_omx) (avc1 / 0x31637661), yuv420p, 720x480 [SAR 8:9 DAR 4:3], q=2-31, 200 kb/s, 29.97 fps, 30k tbn, 29.97 tbc
    Metadata:
      encoder         : Lavc57.106.104 h264_omx
    Stream #0:1(eng): Audio: aac (libfdk_aac) (mp4a / 0x6134706D), 48000 Hz, 5.1, s16, 488 kb/s
    Metadata:
      encoder         : Lavc57.106.104 libfdk_aac
frame=  437 fps= 54 q=-0.0 Lsize=    1200kB time=00:00:14.54 bitrate= 675.5kbits/s dup=39 drop=0 speed=1.79x
video:369kB audio:817kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.105037%

Using libmp3lame:

./ffmpeg -i Jeopardy\!\ 2017-10-06\ -\ 10-06-2017.ts -c:a libmp3lame -c:v h264_omx out.mp4
ffmpeg version git-2017-09-30-148c8e8 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 6.3.0 (Raspbian 6.3.0-18+rpi1) 20170516
  configuration: --arch=armhf --target-os=linux --enable-gpl --enable-libx264 --enable-nonfree --enable-libfdk-aac --enable-libvpx --enable-libopus --enable-librtmp --enable-libmp3lame --enable-gpl --enable-omx --enable-omx-rpi --enable-version3 --enable-decoder=mpeg2_mmal --enable-mmal
  libavutil      55. 77.101 / 55. 77.101
  libavcodec     57.106.104 / 57.106.104
  libavformat    57. 82.102 / 57. 82.102
  libavdevice    57.  9.101 / 57.  9.101
  libavfilter     6.106.100 /  6.106.100
  libswscale      4.  7.103 /  4.  7.103
  libswresample   2.  8.100 /  2.  8.100
  libpostproc    54.  6.100 / 54.  6.100
[mpeg2video @ 0x1e223a0] Invalid frame dimensions 0x0.
    Last message repeated 9 times
[mpegts @ 0x1e1dee0] PES packet size mismatch
    Last message repeated 1 times
Input #0, mpegts, from 'Jeopardy! 2017-10-06 - 10-06-2017.ts':
  Duration: 00:04:23.43, start: 19542.387033, bitrate: 2365 kb/s
  Program 131
    Stream #0:0[0x8c0]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, top first), 720x480 [SAR 8:9 DAR 4:3], Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x8c1](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 384 kb/s
    Stream #0:2[0x8c2](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 192 kb/s
File 'out.mp4' already exists. Overwrite ? [y/N] y
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video (native) -> h264 (h264_omx))
  Stream #0:1 -> #0:1 (ac3 (native) -> mp3 (libmp3lame))
Press [q] to stop, [?] for help
[h264_omx @ 0x1e739e0] Using OMX.broadcom.video_encode
Output #0, mp4, to 'out.mp4':
  Metadata:
    encoder         : Lavf57.82.102
    Stream #0:0: Video: h264 (h264_omx) (avc1 / 0x31637661), yuv420p, 720x480 [SAR 8:9 DAR 4:3], q=2-31, 200 kb/s, 29.97 fps, 30k tbn, 29.97 tbc
    Metadata:
      encoder         : Lavc57.106.104 h264_omx
    Stream #0:1(eng): Audio: mp3 (libmp3lame) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp
    Metadata:
      encoder         : Lavc57.106.104 libmp3lame
frame=  402 fps= 87 q=-0.0 Lsize=     544kB time=00:00:13.38 bitrate= 333.0kbits/s dup=39 drop=0 speed= 2.9x
video:339kB audio:195kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.756271%

./ffmpeg -i Jeopardy\!\ 2017-10-06\ -\ 10-06-2017.ts -c:v h264_omx out.mp4
ffmpeg version git-2017-09-30-148c8e8 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 6.3.0 (Raspbian 6.3.0-18+rpi1) 20170516
  configuration: --arch=armhf --target-os=linux --enable-gpl --enable-libx264 --enable-nonfree --enable-libfdk-aac --enable-libvpx --enable-libopus --enable-librtmp --enable-libmp3lame --enable-gpl --enable-omx --enable-omx-rpi --enable-version3 --enable-decoder=mpeg2_mmal --enable-mmal
  libavutil      55. 77.101 / 55. 77.101
  libavcodec     57.106.104 / 57.106.104
  libavformat    57. 82.102 / 57. 82.102
  libavdevice    57.  9.101 / 57.  9.101
  libavfilter     6.106.100 /  6.106.100
  libswscale      4.  7.103 /  4.  7.103
  libswresample   2.  8.100 /  2.  8.100
  libpostproc    54.  6.100 / 54.  6.100
[mpeg2video @ 0x323b380] Invalid frame dimensions 0x0.
    Last message repeated 9 times
[mpegts @ 0x3236ec0] PES packet size mismatch
    Last message repeated 1 times
Input #0, mpegts, from 'Jeopardy! 2017-10-06 - 10-06-2017.ts':
  Duration: 00:04:23.43, start: 19542.387033, bitrate: 2365 kb/s
  Program 131
    Stream #0:0[0x8c0]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, top first), 720x480 [SAR 8:9 DAR 4:3], Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x8c1](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 384 kb/s
    Stream #0:2[0x8c2](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 192 kb/s
File 'out.mp4' already exists. Overwrite ? [y/N] y
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video (native) -> h264 (h264_omx))
  Stream #0:1 -> #0:1 (ac3 (native) -> aac (native))
Press [q] to stop, [?] for help
[h264_omx @ 0x328c9b0] Using OMX.broadcom.video_encode:32:22.77 bitrate=  -0.0kbits/s speed=N/A
Output #0, mp4, to 'out.mp4':
  Metadata:
    encoder         : Lavf57.82.102
    Stream #0:0: Video: h264 (h264_omx) (avc1 / 0x31637661), yuv420p, 720x480 [SAR 8:9 DAR 4:3], q=2-31, 200 kb/s, 29.97 fps, 30k tbn, 29.97 tbc
    Metadata:
      encoder         : Lavc57.106.104 h264_omx
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, 5.1(side), fltp, 341 kb/s
    Metadata:
      encoder         : Lavc57.106.104 aac
frame=  183 fps= 34 q=-0.0 Lsize=     389kB time=00:00:06.07 bitrate= 525.3kbits/s dup=39 drop=0 speed=1.11x
video:161kB audio:222kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.560693%

This last window is not specifying a encoder to use. 

Also maybe i am not correct saying less demanding per say, but the pi is able to transcode significantly faster using libmp3lame than not specifying an encoder. I am curious how these would pan out using the command line that emby uses with all the other options that are specified.

Edited October 7, 2017 by tdiguy

[Waldonnis 148]

I'm not sure about the license for fdk_aac (requires --enable-nonfree when compiling ffmpeg), but it would need to be checked before distributing. I prefer fdk_aac as well and use it for all of my AAC encodes due to some of the options it provides, so I compile my own ffmpeg to include it.

 

Also, looking at those two logs, it's not a fair comparison.  libmp3lame is going to be faster in most circumstances, but you have a 5.1->2-channel transcode vs. a 5.1->5.1-channel.  I'm no fan of mp3, though, so I avoid libmp3lame unless I have to use it (long story).

Edited October 7, 2017 by Waldonnis

[tdiguy 96]

I'm not sure about the license for fdk_aac (requires --enable-nonfree when compiling ffmpeg), but it would need to be checked before distributing. I prefer fdk_aac as well and use it for all of my AAC encodes due to some of the options it provides, so I compile my own ffmpeg to include it.

 

Also, looking at those two logs, it's not a fair comparison.  libmp3lame is going to be faster in most circumstances, but you have a 5.1->2-channel transcode vs. a 5.1->5.1-channel.  I'm no fan of mp3, though, so I avoid libmp3lame unless I have to use it (long story).

Using a rpi i have found its best to use a custom compiled ffmpeg also. Otherwise i dont get any optimization from any of the static builds. If i remember correctly even the omx hardware acceleration is non free. 

I was thinking of this feature mostly as a user selectable thing in the gui since all that needs to change is a option in the ffmpeg command line. I also figure that it would likely effect audio quality so might not be something everyone wants but for low powered hardware its an option.

As far as the audio output goes i assume that is a function of the encoding and or the encoders limitations. Libmp3lame  maybe only does stereo lol i mean it has lame right in its name.

Edited October 7, 2017 by tdiguy

[tdiguy 96]

This is actually interesting. It seems that the fdk_aac is not GPL which is why the nonfree tag is required it so it could not be baked into a distro without contacting them and getting license permissions.

The options for using audio codecs in ffmpeg are surprisingly limited and or have giant compatibility issues. I tried several of the "baked in" codecs for ffmpeg and often saw: Error initializing output stream 0:1 -- Error while opening encoder for output stream #0:1 - maybe incorrect parameters such as bit_rate, rate, width or height

 

Also support for a couple codecs that i was trying like crazy to enable in ffmpeg were removed from ffmpeg which really explains why i had such a time trying to get libaacplus to work. It seems like there would be 3 options for highly compatible codecs, the aac built in to ffmpeg, libfdk ( not gpl i think fits best because its free but not distributable ) or libmp3lame. Whats weird to me is that the built in aac encoder in ffmpeg seems to be a giant drag on encoding speed. libmp3lame is fast but you go from the station transmitted 5.1 audio to stereo.

 

I found some info about libfdk from this page: http://wiki.hydrogenaud.io/index.php?title=Fraunhofer_FDK_AAC#FDK_License

https://trac.ffmpeg.org/wiki/Encode/AAC

Edited October 7, 2017 by tdiguy

[tdiguy 96]

Would this be feasible as a user selected option? I am thinking it would be useful in both transcoding and direct streaming. Or if emby has device profiles that users can edit it would be a handy feature there so that say your cell phone can use libmp3lame and the receiver can use ffmpegs default or libfdk-aac.

Since like hardware acceleration if someone does not have libfdk-aad compiled into their ffmpeg it might be prudent to say it could break things and use with caution.

[tdiguy 96]

Somewhat surprised i seem to be the only person interested in this. It can make a noticeable difference on performance and implementing would not be incredibly difficult.

[Luke 37161]

Did you read waldonnis's post?

 

 

 

 

Also, looking at those two logs, it's not a fair comparison.  libmp3lame is going to be faster in most circumstances, but you have a 5.1->2-channel transcode vs. a 5.1->5.1-channel.  I'm no fan of mp3, though, so I avoid libmp3lame unless I have to use it (long story).

[tdiguy 96]

Did you read waldonnis's post?

 

 

Also, looking at those two logs, it's not a fair comparison.  libmp3lame is going to be faster in most circumstances, but you have a 5.1->2-channel transcode vs. a 5.1->5.1-channel.  I'm no fan of mp3, though, so I avoid libmp3lame unless I have to use it (long story).

Yes,

What should i have gotten out of that as an understanding other than 1 being non gpl ( hardware acceleration on the pi is also not baked into ffmpeg static builds ) and 1 he personally does not like?

[Waldonnis 148]

Yes,

What should i have gotten out of that as an understanding other than 1 being non gpl ( hardware acceleration on the pi is also not baked into ffmpeg static builds ) and 1 he personally does not like?

 

The first sentence of that quote     The AC3->AAC encoding is converting/encoding four more channels than the MP3 encoding.  For a fair comparison, specify the same audio channels for both in your ffmpeg command line when trying AC3->AAC since AC3->MP3 is going from 5.1 to 2.0.  Downmixing to two channels is computationally cheap (especially with the defaults) compared to encoding six channels.

 

I have little doubt that mp3 encoding will be "lighter", but it's hard to see just how much when the channel count being encoded is different.

[tdiguy 96]

The first sentence of that quote     The AC3->AAC encoding is converting/encoding four more channels than the MP3 encoding.  For a fair comparison, specify the same audio channels for both in your ffmpeg command line when trying AC3->AAC since AC3->MP3 is going from 5.1 to 2.0.  Downmixing to two channels is computationally cheap (especially with the defaults) compared to encoding six channels.

 

I have little doubt that mp3 encoding will be "lighter", but it's hard to see just how much when the channel count being encoded is different.

I think the downmixing is likely a limitation of using libmp3lame, mostly because when i did the comparison the only difference in the command was the codec used for encoding. The people over at ffmpeg seem to really like libfdk_aac also since right in their documentation they suggest to use it in place of the old high efficiency codec.

[Waldonnis 148]

I think the downmixing is likely a limitation of using libmp3lame, mostly because when i did the comparison the only difference in the command was the codec used for encoding. The people over at ffmpeg seem to really like libfdk_aac also since right in their documentation they suggest to use it in place of the old high efficiency codec.

 

They do, and mostly because it's really good especially at certain bitrates.  Their documentation doesn't get a lot of attention generally, though, and may not have been reviewed fully since the new AAC encoder replaced the old one (fdk_aac was a lot better than the old aac encoder ffmpeg used before).

 

If you want a more equal comparison, add -ac 2 to the ac3->aac encoding test rather than using the default.  This will force a stereo downmix before the aac encoding, just like what's automatically done when dealing with libmp3lame.  mp3 is limited to two channel output, which is why downmixing is the default and automatically done.  AAC supports more channels, so the default is to preserve the input's channel layout when encoding when possible, so in your test it was going from 6-channel AC3 to 6-channel AAC, meaning more channels' worth of data were being encoded...and more work (cpu time) being needed to do so compared to only having to encode two channels.

[tdiguy 96]

That will be interesting I will try it later on, I expect libfdkaac encoding only 2 channels will likely be even faster than libmp3lame given how close they were in a 5 vs 2 race.

Sent from my SM-G900P using Tapatalk

pi@raspberrypi:/media/emby/ffmpeg-stuff/FFmpeg $ sudo ./ffmpeg -i Jeopardy\!\ 2017-10-06\ -\ 10-06-2017.ts -ac 2 -c:a libfdk_aac -c:v h264_omx out.mp4
ffmpeg version git-2017-09-30-148c8e8 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 6.3.0 (Raspbian 6.3.0-18+rpi1) 20170516
  configuration: --arch=armhf --target-os=linux --enable-gpl --enable-libx264 --enable-nonfree --enable-libfdk-aac --enable-libvpx --enable-libopus --enable-librtmp --enable-libmp3lame --enable-gpl --enable-omx --enable-omx-rpi --enable-version3 --enable-decoder=mpeg2_mmal --enable-mmal
  libavutil      55. 77.101 / 55. 77.101
  libavcodec     57.106.104 / 57.106.104
  libavformat    57. 82.102 / 57. 82.102
  libavdevice    57.  9.101 / 57.  9.101
  libavfilter     6.106.100 /  6.106.100
  libswscale      4.  7.103 /  4.  7.103
  libswresample   2.  8.100 /  2.  8.100
  libpostproc    54.  6.100 / 54.  6.100
[mpeg2video @ 0x2ab9370] Invalid frame dimensions 0x0.
    Last message repeated 9 times
[mpegts @ 0x2ab4ec0] PES packet size mismatch
    Last message repeated 1 times
Input #0, mpegts, from 'Jeopardy! 2017-10-06 - 10-06-2017.ts':
  Duration: 00:04:23.43, start: 19542.387033, bitrate: 2365 kb/s
  Program 131
    Stream #0:0[0x8c0]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, top first), 720x480 [SAR 8:9 DAR 4:3], Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x8c1](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 384 kb/s
    Stream #0:2[0x8c2](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 192 kb/s
File 'out.mp4' already exists. Overwrite ? [y/N] y
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video (native) -> h264 (h264_omx))
  Stream #0:1 -> #0:1 (ac3 (native) -> aac (libfdk_aac))
Press [q] to stop, [?] for help
[h264_omx @ 0x2b09b80] Using OMX.broadcom.video_encode
Output #0, mp4, to 'out.mp4':
  Metadata:
    encoder         : Lavf57.82.102
    Stream #0:0: Video: h264 (h264_omx) (avc1 / 0x31637661), yuv420p, 720x480 [SAR 8:9 DAR 4:3], q=2-31, 200 kb/s, 29.97 fps, 30k tbn, 29.97 tbc
    Metadata:
      encoder         : Lavc57.106.104 h264_omx
    Stream #0:1(eng): Audio: aac (libfdk_aac) (mp4a / 0x6134706D), 48000 Hz, stereo, s16, 139 kb/s
    Metadata:
      encoder         : Lavc57.106.104 libfdk_aac
frame=  320 fps= 89 q=-0.0 Lsize=     448kB time=00:00:10.64 bitrate= 345.0kbits/s dup=39 drop=0 speed=2.97x

I would bet with the libfdk_aac set for 5 channels i might get a decent live stream from the pi, but it would even more likely with just stereo. 

My own opinion seeing this is that libfdk seems better all around. I mean 1 it doesnt have lame in its name but otherwise i have read that aac is a better format than mp3 and libfdk is out-performing lame. The only other thing is that libfdk_aac is not gpl so if people want to use it they would have to compile ffmpeg themselves.

Edited October 10, 2017 by tdiguy

[Waldonnis 148]

That will be interesting I will try it later on, I expect libfdkaac encoding only 2 channels will likely be even faster than libmp3lame given how close they were in a 5 vs 2 race.

 

I would bet with the libfdk_aac set for 5 channels i might get a decent live stream from the pi, but it would even more likely with just stereo. 

My own opinion seeing this is that libfdk seems better all around. I mean 1 it doesnt have lame in its name but otherwise i have read that aac is a better format than mp3 and libfdk is out-performing lame. The only other thing is that libfdk_aac is not gpl so if people want to use it they would have to compile ffmpeg themselves.

 

Using two-channel audio should lighten the load no matter what, but I agree that fdk_aac will probably be better load-wise even with 6 channels compared to aac (at least in my experience).  mp3 has some limitations that I've run into, which is why I mentioned my preference before, but it always comes back to what sounds okay for your ears on your equipment and how many audio channels you want/need.  If you prefer having surround audio over just stereo, obviously mp3 wouldn't be the way you want to go and fdk_aac is a strong choice.  If you don't notice a difference or it sounds good enough to you with the mp3 encoder choice and don't mind the stereo output, then it wouldn't be bad to just stick with that.

 

Of course, all of that depends on Emby supporting the option to change default audio encoders, which I also agree would be very nice, even if it's an experimental feature.  It could get complicated in some scenarios, though, since if someone chose an encoder like mp3 as a default, they may end up complaining later on that they're not getting surround sound output.  Usually, the clients determine what they can accept and the server tries to accommodate that, but a server setting like that would override that which could lead to confusion.  Perhaps the better compromise would be to allow overriding only aac with fdk_aac since they can be used interchangeably (and leaving libmp3lame out of it entirely) and having a big proviso that it's experimental and requires a "roll your own" ffmpeg build.

 

Side note: fdk_aac inclusion is the primary reason I started building my own ffmpeg binaries here, so I can definitely understand why you would want to use it 

Edited October 11, 2017 by Waldonnis

[tdiguy 96]

@@Waldonnis

One thing i just noticed since i installed the beta deb version of emby on my old intel core2 atom ( which it seems it too old to have intel quickstep ) with this build of emby it looks like they are leaning more towards a all inclusive build, with a version of ffmpeg rolled into it. 

Course looking at the log file i know right where that ffmpeg build is so i could always replace it.

your points about the end user / client hardware are very good ones. Though the fdkaac seems more efficient all the way around. Also i am not sure if it can be done but when you tell ffmpeg to use encoder a if its not there it just fails, it wont fallback on its built in encoder. 

I somewhat wonder if there is device profiling in the works. I mean why transcode dolby surround sound to a mobile phone? ( ok maybe the new ones support this but my galaxy s5 doesnt lol ) device profiles that are editable on the server could make for a handy way to control which devices are more cpu intensive than others. Granted i do not have any devices that support more than 3 channels of audio. But if i did i would only enable 5.1 on that 1 device and lets say stereo on everything else.

For my use 2 buttons would suffice really, 1 to turn on libfdk_aac codec and 1 to downmix to stereo. I can see though for others more options would likely be desired.

 

Tonight i have also disapointingly found out that when it comes to transcoding my atom ( which i dont think has any hardware acceleration or at least none i can figure out so far ) is about as good as my hardware accelerated pi. It works, but it works best if you start a show and pause for about a minute so it can run smoothly.

[Waldonnis 148]

One thing i just noticed since i installed the beta deb version of emby on my old intel core2 atom ( which it seems it too old to have intel quickstep ) with this build of emby it looks like they are leaning more towards a all inclusive build, with a version of ffmpeg rolled into it. 

Course looking at the log file i know right where that ffmpeg build is so i could always replace it.

Yep.  There's a setting in the Transcoding section off the Dashboard that lets you set the path to ffmpeg, so you wouldn't even need to overwrite that ffmpeg binary...just point Emby at a different one.

 

your points about the end user / client hardware are very good ones. Though the fdkaac seems more efficient all the way around. Also i am not sure if it can be done but when you tell ffmpeg to use encoder a if its not there it just fails, it wont fallback on its built in encoder. 

I somewhat wonder if there is device profiling in the works. I mean why transcode dolby surround sound to a mobile phone? ( ok maybe the new ones support this but my galaxy s5 doesnt lol ) device profiles that are editable on the server could make for a handy way to control which devices are more cpu intensive than others. Granted i do not have any devices that support more than 3 channels of audio. But if i did i would only enable 5.1 on that 1 device and lets say stereo on everything else.

For my use 2 buttons would suffice really, 1 to turn on libfdk_aac codec and 1 to downmix to stereo. I can see though for others more options would likely be desired.

I'm not sure a device profile would really be needed.  Aside from DLNA, the clients already report back to the server what they support and the server transcodes when needed to match the codecs/bandwidth/etc. that the client supports.  For instance, I have two Rokus, but only one is connected to an AVR.  When trying to play something with 6-channel DTS or AC3 audio, the Roku with the AVR will direct play the file, but an audio transcode is done for the "two-channel AAC only" Roku.  Most playback devices already have settings for audio channels and codec support, so additional control would probably be redundant.  For instance, Rokus let you change to stereo only in settings, as does my FireTV Stick...and I've seen similar settings on other family members' devices from other manufacturers.  Things like Chromecasts and some of the less flexible devices often just query the monitor/AVR they're connected to for determining audio support, and phone OSes should return whatever their hardware can support.

 

Almost forgot - Emby already detects the presence of certain encoders in the ffmpeg build that it's pointed at, so detecting fdk_aac wouldn't be hard, necessarily.  Any setting added could even be hidden or disabled if the ffmpeg binary doesn't support it.

 

Tonight i have also disapointingly found out that when it comes to transcoding my atom ( which i dont think has any hardware acceleration or at least none i can figure out so far ) is about as good as my hardware accelerated pi. It works, but it works best if you start a show and pause for about a minute so it can run smoothly.

A lot of those older Atom processors just weren't that powerful, unfortunately.  They did make great playback devices (and still do if you don't deal with HEVC), though, and are pretty energy efficient.  Adding a budget video card that can do hardware transcoding would be an option, but that depends on if your particular system is expandable that way (lots of factors there including space, slot availability, power supply, etc.).

Edited October 12, 2017 by Waldonnis

[tdiguy 96]

I prefer to keep the playback devices in the house very user friendly the fire sticks and firetv seem to be nearly the most universally accepted devices these days as far as software offerings go. I was thinking of going 100% internet based tv ( aside from locals ) and my old favorite the roku was not supported by a couple providers i was looking at. I will have to try taking a look for those settings also, course for cpu limited devices a universal setting to limit the number of audio channels that are decoded could be handy. 

[tdiguy 96]

I have started fooling around with the profiling under dlna, i think much of what i want to accomplish i can under profiling. 

Though i am still not sure where i can find a setting to use a custom compiled ffmpeg.

Now i need to install libfdkaac and see if i can get that to work, i am thinking its very likely, just not sure if i can force it to use stereo or not. 

One thing that really can be said for emby is the ability to customize and tweak this. I dont have my pi running any more and right now dont feel like bringing it back online but i think i could get live tv to transcode smoothly, albeit without 5.1 sound.

Edited October 13, 2017 by tdiguy

[Luke 37161]

The upcoming Emby Server 4.2 release will have improved hardware transcoding support for both RockPro64 and Raspberry Pi. Thanks guys.

[BillOatman 502]

This thread is a great example of why I enjoy this forum.  I don't know a ton about audio or audio codecs.  Reading discussions like this helps me, and I'm sure others, understand a lot more.