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

Reimar Döffinger Reimar.Doeffinger
Wed Mar 2 22:07:53 CET 2011


On Wed, Mar 02, 2011 at 09:04:54PM +0000, M?ns Rullg?rd wrote:
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> 
> > On Wed, Mar 02, 2011 at 09:23:17PM +0100, Kostya wrote:
> >> On Wed, Mar 02, 2011 at 08:12:15PM +0000, M?ns Rullg?rd wrote:
> >> > Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> >> > 
> >> > > Currently we simply byte-swap DNET directly in the Real demuxer,
> >> > > however this is not generally possible/correct since which two bytes we
> >> > > need to swap depends on whether the header starts on an even or an odd
> >> > > byte.
> >> > > Not useful on its own within FFmpeg, but could e.g. be used together
> >> > > with a byte-swap bitstream filter or a modified AC3-decoder to implement
> >> > > more robust DNET support.
> >> > 
> >> > Where does the name DNET come from?
> >> > 
> >> > > @@ -390,6 +390,7 @@ enum CodecID {
> >> > >      CODEC_ID_BINKAUDIO_DCT,
> >> > >      CODEC_ID_AAC_LATM,
> >> > >      CODEC_ID_QDMC,
> >> > > +    CODEC_ID_DNET,
> >> > 
> >> > I don't think a new codec ID is called for.  Couldn't it be handled the
> >> > same way as byte-swapped DTS?
> >> 
> >> I think it can and should - and there's AC3-in-WAV too to be supported.
> >
> > AC3 has only about 17 bits to identify a header on (compared to 32 or
> > more for DTS/DCA).  Searching for a byte-swapped variant is far too
> > likely to result in false positives to be acceptable.
> 
> Then how did you intend to detect it as ac3 in the first place?

By the fact that the RealMedia header says "DNET"?
Though I would detect it as DNET or byte-swapped AC3 in that
case, not as AC3.



More information about the ffmpeg-devel mailing list