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

[Reimar Döffinger]

On 3 Mar 2011, at 00:00, Reimar D?ffinger <Reimar.Doeffinger at gmx.de> wrote:
> 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?

And I forgot: stream copy would end up creating files that only FFmpeg can play unless we add a special hack.
Contrary to the different DTS formats which are all really DTS, byte-swapped AC-3 is not considered AC-3 by any implementation I know of.