[FFmpeg-cvslog] r15103 - in trunk: Changelog libavcodec/Makefile libavcodec/ac3dec.c
Sun Aug 31 22:16:24 CEST 2008
Justin Ruggles wrote:
> 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
>>> 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.
Wrapping is also different for mp4, a way to distinguish would be really
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc. http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
More information about the ffmpeg-cvslog