[FFmpeg-devel] [PATCH] Detect DTS in wav (issue70) + about ac3-in-wav

Anssi Hannula anssi.hannula
Thu Jul 22 05:15:17 CEST 2010


Attached are patches that fix issue70 (detection of DTS in wav).

Two new fields are added to AVStream that allow demuxers to set a fallback 
codec to a stream, which gets used if no codec is probed in a defined number 
of bytes.
Please comment if you think this should be done in some better way :)

I made the wav demuxer do the probing only for PCM_S16LE, as all my dts/ac3-
in-wav samples are like that. If people are aware of other kind of files, it 
could be changed to cover more/all PCM codecs if necessary.

This works fine for DTS (issue70), but for AC-3 there are some more issues 
that are left unresolved with these patches for now:

- The byte order seems to be reversed compared to 'normal' AC-3 (thus they
  are not playable in FFmpeg even by forcing codec; mplayer, though, has some
  byteswap code in its liba52 wrapper allowing playback with '-ac +a52')

  o We parse the ac3 headers in raw-ac3 probe, ac3 parser and ac3 decoding..
    Should all of these simply reverse byte order if needed, or is there a
    better way?
    One easy alternative way would be to detect the below 8 byte sequence +
    ac-3 headers in the first wav_read_packet() and then just start reversing
    bytes in all following packets (and probably short-circuit the probe, 
    bypassing most of the issues below). This also feels more correct place as
    the byte-ordering seems to be a format-specific quirk. But is that
    detection good enough? I guess we could read a double sized first packet
    so that we get 2 AC3 frames to be more sure, though.

- The frames seem to be padded to 6144 bytes (to fit the pcm bitrate), causing 
  probe not to find any consecutive frames and returning only score 1.

  o Seems easy to fix. This will, though, currently cause an error flood on
    playback even if the audio plays fine. Probably easy to fix as well.

- Even then, ac3 probe would only return AVPROBE_SCORE_MAX / 4, as the first
  frame starts after 8 bytes.

  o All the ac3-in-wav files (at least all I have) seem to have 8 bytes before
    every ac3 frame: 72 f8 1f 4e 01 00 10 57. I guess this case can be added
    to the probe (either checking the byte values or not).

AC3-in-wav samples other than [1] or [2] would be welcome to confirm this 

Anssi Hannula

More information about the ffmpeg-devel mailing list