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

[Reimar Döffinger]

On 2 Mar 2011, at 23:43, Justin Ruggles <justin.ruggles at gmail.com> wrote:
> On 03/02/2011 05:18 PM, 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.
>> 
>> All else aside, calling it DNET is ridiculous.  It is called AC3
>> whatever container you wrap it in.  We don't have a CODEC_ID_ for every
>> tag used in some obscure container, we have one per codec.  Please keep
>> it that way.
> 
> 
> I agree. We can handle this in a different way.
> 
> For example, I think it would be fine for the AC3 parser to detect byte
> order and then not accept switching byte order during parsing.  This
> would mitigate the false positive probability increase for all but the
> first frame, which is ok with me.

Why would you want to do this? Making things difficult just for the heck of it or what?
There is _no_ AC3 decoder that even tries to do this.
Just to avoid a CODEC_ID? We do have one for each raw format, including differently swapped ones. And you would be ready to accept an error rate of 1:64000 just for that?