FFMPEG 3.2.2 trancoding 2-ch aac to mp3

[Jdiesel 1431]

I've been doing some testing with ffmpeg 3.2.2 and noticed that 2-channel aac is being transcoded to mp3 when playing a live tv stream. It occurs on both the release and preview Roku apps. Playing the same stream in the web client the aac audio is copied. If playing a recorded copy of the show, local copy, the aac audio track is direct played.

 

 

[ebr 16177]

That tells me we must not know what the audio is when it is in the live stream so have to assume it needs converting to something we know we can play.

 

What is the Live TV source?

[Jdiesel 1431]

The source is an IPTV provider. Like the webclient, the Android TV app is also copying the video and audio streams. FFmpeg 3.2.2 has been causing lots of problems for me so I will revert back to 2.8.20 and do some more testing but if I recall correctly the audio was also being transcoded on FFmpeg 2.8.10.

 

@@ebr I won't be able to troubleshoot for a while but if you would like a copy of the m3u for testing let me know.

Edited February 10, 2017 by Jdiesel

[Luke 42078]

We probed it for media info but it was not able to determine the audio bitrate. Without having that information that's why we decided to convert it rather than stream copy.

[Jdiesel 1431]

Does the Roku have a audio bitrate limitation that requires it to fallback to a conservative method if unknown? The web app and Android TV app seem to be able to handle the same stream without converting from aac to mp3.

[Luke 42078]

We'd have to look at a log but most likely the probe in those cases succeeded in determining an audio bitrate.

[Jdiesel 1431]

I will do some more testing tonight now that I am back on FFmpeg 2.8.10 and gather some log files from different clients and scenarios. 

[speechles 2055]

In blue neon it would keep the AAC. Both the unknown audio and default audio are set as AAC to start with. You can of course change these to MP3 or AC3. The AAC audio when transcoded makes clicks and pops on some devices. This is why the official and beta are using MP3.

 

The audio info must not be complete. You can tell by play in blue neon, then fast-fwd a tiny bit, wait for video to play and press OK. Do you see "Audio: ?-> aac" shown on the screen? The question mark means the server didnt supply the audio codec and the app used the codec assigned to unknown audio. You can always force directstream too, any issues when forced?

 

Sent from my Nexus 7 using Tapatalk

[Jdiesel 1431]

I will try testing with Blue Neon as well

[Jdiesel 1431]

I've reverted back to FFmpeg 2.8.10 and have been successfully been playing streams with copied audio and video on all three Roku apps tonight. I have had a few streams stop playing after about a minute of playback, restarting the stream resulted in it playing properly.

[Luke 42078]

There is a regression in ffmpeg 3.2 that was affecting us. We submitted a patch to ffmpeg, it was approved and merged in but I don't know if it's been packaged into an ffmpeg release or not yet.

[Jdiesel 1431]

I recall having issues with ffmpeg 3.2 back in December but thought I'd try again to see if anything had changed. Not that I feel I need 3.2, just curious to test it. Any thoughts on forking ffmpeg and including a customized build as part Emby server for consistency?   

[Luke 42078]

I suppose if there is ever a need for customization but we don't have that need right now.