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

[Aurelien Jacobs]

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 ?

Aurel