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

Anssi Hannula anssi.hannula
Thu Mar 3 01:39:23 CET 2011

On 03.03.2011 02:29, 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.

Well, for iec61937 it is done for all codecs, not just ac3. So the
byte-swapping can't completely be removed from the demuxer unless we'd
add byte-swapped support to the rest of the codecs/parsers...

Anssi Hannula

More information about the ffmpeg-devel mailing list