[FFmpeg-cvslog] r15103 - in trunk: Changelog libavcodec/Makefile libavcodec/ac3dec.c

[Justin Ruggles]

Hi,

Aurelien Jacobs wrote:
> On Sun, 31 Aug 2008 05:08:18 +0200 (CEST)
> jbr <subversion at mplayerhq.hu> wrote:
> 
>> Author: jbr
>> Date: Sun Aug 31 05:08:18 2008
>> New Revision: 15103
>>
>> Log:
>> turn on E-AC-3 decoding support and update the Changelog
> 
> Great !!! Thanks a lot !
> I think it deserves a news on ffmpeg.org front page.

Does this sound OK?

"The E-AC-3 decoder from Summer of Code 2007 has made it to FFmpeg
trunk.  It will decode nearly all E-AC-3 streams we have come across.
Work is still in progress to fully support decoding of all 8 channels
from Blu-ray 7.1 streams."

> BTW: I seem to recall that there was a CODEC_ID_EAC3 in the
> old days, during SoC developpment. It's now gone, because
> the same decoder handle both AC3 and EAC3.
> But this is causes some trouble. Various containers have a
> specific way to store EAC3 (different than AC3). It's generaly
> simply a different codec ID (or whatever the format calls it).
> As we have no CODEC_ID_EAC3, muxers can't distinguish between
> AC3 and EAC3, and thus can't mux EAC3 correctly.
> I propose to add a CODEC_ID_EAC3, to allow correct muxing.
> See attached patch.

 There is 1 problem I can see with that.  It is valid to mix AC3 and
EAC3 frames together in the same stream.  In fact, that is what is done
in Blu-ray.  It is still possible to make this work, but I believe the
probe function would have to search for at least 2 frames before
determining AC3 vs. EAC3.  The 2 probe functions would likely be shared
except for the checking of the bitstream id.

 It would certainly be helpful for E-AC-3 encoding (which is on my
personal TODO list).

 I vaguely recall a discussion at one point about codec sub-types...  I
don't quite remember how that was supposed to work though.

-Justin