[FFmpeg-devel] [PATCH] Add a parser for DNET (byte-swapped AC3).

[Reimar Döffinger]

On Thu, Mar 03, 2011 at 12:29:24AM +0000, M?ns Rullg?rd wrote:
> Anssi Hannula <anssi.hannula at iki.fi> writes:
> 
> > On 03.03.2011 00:18, M?ns Rullg?rd wrote:
> >> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> >> 
> >>> On Wed, Mar 02, 2011 at 09:10:21PM +0000, M?ns Rullg?rd wrote:
> >>>> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> >>>>>> Then how did you intend to detect it as ac3 in the first place?
> >>>>>
> >>>>> By the fact that the RealMedia header says "DNET"?
> >>>>
> >>>> AC3 exists outside of realmedia file, you know...
> >>>
> >>> So what? Has anyone seen the byte-swapped variant outside a container?
> >>> Either way libavformat has a better infrastructure to do this kind
> >>> of format detection when it's hard to decide, a parser is not really
> >>> such a great place for it.
> >> 
> >> The parser can reasonably assume it is being fed AC3 data in some form
> >> or other, so the difficulty of detection is irrelevant there.
> >> 
> >>> Which, as said, is in addition to the fact whether there is a point
> >>> at all of supporting byte-swapped raw AC3. It obviously exists
> >>> in other containers, but already for that there seem to be no samples
> >>> available, DNET is the only one actually common (and even that seems
> >>> relative).
> >> 
> >> AC3 in WAV is fairly common.  I'm sure we have a few samples of that.
> >
> > Note that our spdif/iec61937 demuxer already does the byteswap for that
> > case, so the decoder doesn't need to handle it.
> >
> > (note that I'm not for or against anything, just making sure all the
> > facts are available :) )
> 
> So should byte-swapping be done by the demuxer or elsewhere?  We should
> probably be consistent.

In this case the byte-swapping is part of the IEC container, it is not
really related to this IMO.
Also since in IEC teh AC-3 header must be placed at specific locations
there is no issue with byte-swapping before parsing since we do know
which bytes we have to swap anyway (and I think there's not really much
if any point in doing parsing?).
Now I do not know whether that is an issue with real-world RM, AVI etc.
files containing such byte-swapped AC-3, the reason is mostly that I
am starting from existing code and I don't like to remove features,
mostly just assuming those features are there for a reason even though
I do not have a sample.