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

[Anssi Hannula]

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