Long Standing EAC3 Issue

[plazma 13]

Hi,

 

I dont frequently use the web interface and only really fall back to it when i need it as the wmc client is broken, however i have friends and family who do and they would occasionally complain about the audio going out of sync.

 

I dont know when this started, however i had my first complaint about it around sept/oct last year.

 

Investigating the issue ive found it only appears to happen with files that have eac3 audio streams

 

I found this had previously been a reported issue in ffmpeg and had been fixed at some point previously so i had (when specify your own ffmpeg option was still a thing in the server) attempted to test with the latest build of ffmpeg (as it was much more upto date than the on in the ubuntu repository), however this appeared to have no effect on the issue.

 

Im not 100% sure when using chrome for playback if the audio is actually being transcoded or is simply passed off to chrome as is for eac3, i now know some audio types like mp3,aac/m4a are just passed, where as DTS is always decoded back to stereo and passed over (i think as m4a).

 

Most of the time the issue manifests around 12 - 15 minutes into a video, ive had it happen sooner and occasionally later, but on average when ive tested it its around then, but obviously its dependant on when the bit stream has a glitch.

 

For now i will continue to re-encode these from eac3 to ac3, although its a pain its something i can live with

 

This has been reported as a bug to the ffmpeg thread previously here:

https://trac.ffmpeg.org/ticket/5319

 

And then more recently here:

https://trac.ffmpeg.org/ticket/4861

[Luke 37112]

Hi, Chrome does not support ac3 or eac3 so it always has to be converted. If you can provide a sample file for testing I will try it out. thanks.

[Happy2Play 8296]

You can see what your browser supports at "https://html5test.com/".

Edited February 9, 2017 by Happy2Play

[plazma 13]

Hi, Chrome does not support ac3 or eac3 so it always has to be converted. If you can provide a sample file for testing I will try it out. thanks.

 

Hi, sadly this would not be easy as the files are 6GB a pop normally being a higher 1080p video rate, as the issue happens normally well into the files 10 minus plus of say a 40 minute video it would mean the files would still be very large.

 

I can PM you some file names if you would like on files where ive seen this happen (if your able to obtain from source), however as i said ive long been converting the audio out to ac3 from eac3 to work around the issue and for pretty much all of the files the are now ac3 on the files i have.

 

Does emby-server now also use an internal ffmpeg on linux (where as previously it would be installed from else where, eg repository), if so i know the ubuntu repository has a 2.x version, i did try with a later 3.x version around early nov time, but this did not fix the issue, however this was possibly before they implemented the fix.

 

I know on one of the ffmpeg threads i posted above there is a supposed work around for builds that had not had the patch.

 

Its strange as to re-encode the audio i typically use handbrake (which also uses ffmpeg) and the eac3 is converted to ac3 without any issues with becoming de-synced from the video.

Edited February 9, 2017 by plazma