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

[Justin Ruggles]

Aurelien Jacobs wrote:
> On Sun, 31 Aug 2008 13:44:23 -0400
> Justin Ruggles <justin.ruggles at gmail.com> wrote:
> 
>> 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."
> 
> This sounds OK to me.
> 
>>> 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.
> 
> Such a mixed stream should be marked with CODEC_ID_EAC3.
> 
>>  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.
> 
> Which probe function are you talking about ? The one from the raw ac3
> demuxer ? It may indeed become a little bit more complex.
> And the 2 probe functions would indeed be shared except for the
> bitstream_id check. After a quick look, that seems pretty easy
> to implement.
> 
> But regarding other demuxers (matroska, mp4, maybe mpeg ps/ts and others)
> they already know whether the audio track is AC3 or EAC3. It's
> specified in the container. And currently we have no other solution
> than discarding this information and mark all streams with
> CODEC_ID_AC3. This just breaks proper re-muxing.
> 
> So is it OK to add CODEC_ID_EAC3 ? Anyone against it ?

I have a patch ready-to-go.

Only thing I'm working on now is getting mpeg ps detection correct.
Namely, EVO, which I don't think has a program stream map...

-Justin