[FFmpeg-cvslog] r15103 - in trunk: Changelog libavcodec/Makefile libavcodec/ac3dec.c
Sun Aug 31 19:44:23 CEST 2008
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.
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.
More information about the ffmpeg-cvslog