Emby Converted MP4 (H264 AAC) "No Compatible Streams" on Second Audio Track Only

[Losey 4]

Server Log attached. After getting this error, I attempted to remux the file in a few different ways using FFMPEG, with limited results. Demuxing the second audio stream into a WAV file, converting it to 32-bit AAC M4A in Audacity (only because I haven't figured out how to do it properly in FFMPEG) and remuxing it back in resulted in a file being able to playback in Emby for a few seconds (I can provide a log of that as well, if warranted), but ultimately freeze up. Examining the Emby-converted file's Codec data in VLC, its first audio stream is in MPEG AAC Audio (mp4a) stereo at 48000 Hz with a bits per sample of 32. The second stream is almost the same, except the bits per sample is 16. Remuxing in various ways I've managed to reverse that, but the second audio stream remains the only one that attempting to playback produces the "No Compatible Streams" error.

I've also been attempting to generate a batch file to use with FFMPEG to bulk convert my files to be optimized for Emby playback, generally to great success up until I got to this file. Prior, I only rarely encountered playback issues and then only limited to the H264 video codec not playing nice with everything (using libx264 picked up the slack on that at least).

ffmpeg-transcode-ae9590d0-6f28-4ad4-8e7e-06374d68ea1a_1.txt

[rbjtech 5284]

Looking at your log, ffmpeg is simply copying the Audio stream (AAC) - so it thinks it is compatible, but I suspect the conversion you did is not compatible or not a standard AAC file, thus it throws the error.

What is the original sound format ?  I'm surprised ffmpeg can't convert it tbh, as it's pretty rare to find a format that it won't convert.

Maybe use something like mediaInfo to find the track details if ffmpeg is not recognising it.

 

 

 

 

 

[Losey 4]

Here's a log from mediainfo and ffprobe of the original file and its converted form. The process I've been using is before I load a copy into my test folder on the Emby server, I run the following code on it to strip out all subtitles to prevent any possibility of accidental subtitle hardcoding during Emby's conversion of the file.

for %%a in ("old\*.mkv") do ffmpeg -i "%%a" -map 0:s:0 "new\%%~na.eng.ass"
for %%a in ("old\*.mkv") do ffmpeg -i "%%a" -map 0:s:1 "new\%%~na.fre.ass"
for %%a in ("old\*.mkv") do ffmpeg -i "%%a" -map 0:s:2 "new\%%~na.ger.ass"
for %%a in ("old\*.mkv") do ffmpeg -i "%%a" -map 0:s:3 "new\%%~na.ita.ass"
for %%a in ("old\*.mkv") do ffmpeg -i "%%a" -map 0:s:4 "new\%%~na.spa.ass"
for %%a in ("old\*.mkv") do ffmpeg -i "%%a" -map 0:s:5 "new\%%~na.lat.ass"
for %%a in ("old\*.mkv") do ffmpeg -i "%%a" -map 0:s:6 "new\%%~na.por.ass"
for %%a in ("old\*.mkv") do ffmpeg -i "%%a" -map 0:s:7 "new\%%~na.rus.ass"
for %%a in ("old\*.mkv") do ffmpeg -i "%%a" -map 0:s:8 "new\%%~na.ara.ass"
for %%a in ("old\*.mkv") do ffmpeg -i "%%a" -map 0:v -map 0:a -y -vcodec copy -acodec copy -sn "new\%%~na.mkv"

And whenever Emby fails to convert any file I run the following code and upload the result.

for %%a in ("old\*.mkv") do ffmpeg -i "%%a" -map 0:v -map 0:a -y -vcodec h264 -acodec aac "new\%%~na.mp4"

If the file still has issues after, I try swapping the video codec to libx264, as follows.

for %%a in ("old\*.mkv") do ffmpeg -i "%%a" -map 0:v -map 0:a -y -vcodec libx264 -acodec aac "new\%%~na.mp4"

 

mediainfo-log.txt ffprobe-info.txt ffprobe-original-info.txt mediainfo-original-log.txt

[rbjtech 5284]

So both audio tracks use the same AAC codec, but one is constant bitrate, the other variable bitrate.  Are these the same audio track ?

If yes, and in your script you want to select the 2nd track instead - then you just need to put in the stream modifier on the ffmpeg command line.

ie

-map 0:a will use the first Audio track it finds - can also be written as -map 0:a:0

but by putting -map 0:a:1 - you'll select the 2nd Audio track - the same logic as you used for the subtitle extract.

If you suspect the issue is the AAC - then changing the video encoder will have no impact on this - you may need to modify the audio encoder - such as libfdk.  Have a look here -

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

 

[Luke 42083]

9 hours ago, Losey said:

Server Log attached. After getting this error, I attempted to remux the file in a few different ways using FFMPEG, with limited results. Demuxing the second audio stream into a WAV file, converting it to 32-bit AAC M4A in Audacity (only because I haven't figured out how to do it properly in FFMPEG) and remuxing it back in resulted in a file being able to playback in Emby for a few seconds (I can provide a log of that as well, if warranted), but ultimately freeze up. Examining the Emby-converted file's Codec data in VLC, its first audio stream is in MPEG AAC Audio (mp4a) stereo at 48000 Hz with a bits per sample of 32. The second stream is almost the same, except the bits per sample is 16. Remuxing in various ways I've managed to reverse that, but the second audio stream remains the only one that attempting to playback produces the "No Compatible Streams" error.

I've also been attempting to generate a batch file to use with FFMPEG to bulk convert my files to be optimized for Emby playback, generally to great success up until I got to this file. Prior, I only rarely encountered playback issues and then only limited to the H264 video codec not playing nice with everything (using libx264 picked up the slack on that at least).

ffmpeg-transcode-ae9590d0-6f28-4ad4-8e7e-06374d68ea1a_1.txt 23.72 kB · 2 downloads

If you look at this log, your server is only able to transcode at 3-4 fps, which is not fast enough to be playable. That means the video player is throwing an error because data isn't getting there quickly enough.

[Losey 4]

39 minutes ago, rbjtech said:

So both audio tracks use the same AAC codec, but one is constant bitrate, the other variable bitrate.  Are these the same audio track ?

If yes, and in your script you want to select the 2nd track instead - then you just need to put in the stream modifier on the ffmpeg command line.

ie

-map 0:a will use the first Audio track it finds - can also be written as -map 0:a:0

but by putting -map 0:a:1 - you'll select the 2nd Audio track - the same logic as you used for the subtitle extract.

If you suspect the issue is the AAC - then changing the video encoder will have no impact on this - you may need to modify the audio encoder - such as libfdk.  Have a look here -

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

 

For this, the first track is a Japanese and the second is English. It baffles me as of why the original file wouldn't have the same bitrate treatment uniformly. I'll see if I can muddle through fixing the bitrate, then try libfdk later today, but I've got to attend to my day job for the moment. Quite the nuisance to take arcane steps like compiling ffmpeg just to give it a test.

6 minutes ago, Luke said:

If you look at this log, your server is only able to transcode at 3-4 fps, which is not fast enough to be playable. That means the video player is throwing an error because data isn't getting there quickly enough.

Ideally, I'd like to get my media configuration uniform to the point it doesn't need to do any transcoding, as my system seems to utterly fail to keep up if any transcoding is required ever.

[rbjtech 5284]

The file itself appears to be a pretty standard 1080p h264 - but the remux part suggests it is a full bitrate version which your device cannot play directly (likely due to bandwidth restrictions) thus it is needing to transcode - which equals the playback issues.  In the original ffmpeg log, the Audio track is simply being copied - that is not the problem.

If there are option to get lower bitrate versions (non-remux) then I would suggest you try those - still 1080p, but 4-5 Mbit/sec should still be good quality - maybe less, it depends on the content - you'll need to experiment here.  Or you can convert them in emby - BUT if your cpu cannot keep up with this transcode, it will likely take a VERY long time to convert anything .

 

[Luke 42083]

4 hours ago, Losey said:

For this, the first track is a Japanese and the second is English. It baffles me as of why the original file wouldn't have the same bitrate treatment uniformly. I'll see if I can muddle through fixing the bitrate, then try libfdk later today, but I've got to attend to my day job for the moment. Quite the nuisance to take arcane steps like compiling ffmpeg just to give it a test.

Ideally, I'd like to get my media configuration uniform to the point it doesn't need to do any transcoding, as my system seems to utterly fail to keep up if any transcoding is required ever.

In that case, however you're producing the mp4 is leading the browser video player to throw an error when attempting to play, and then the web app automatically switches to server transcoding in order to ensure successful playback.