[FFmpeg-devel] [PATCH] Add a parser for DNET (byte-swapped AC3).
Måns Rullgård
mans
Thu Mar 3 01:29:24 CET 2011
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.
--
M?ns Rullg?rd
mans at mansr.com
More information about the ffmpeg-devel
mailing list