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

[Anssi Hannula]

Michael Niedermayer kirjoitti keskiviikko, 4. elokuuta 2010 16:10:51:
> On Sat, Jul 24, 2010 at 06:15:23AM +0300, Anssi Hannula wrote:
> > Michael Niedermayer kirjoitti perjantai, 23. hein?kuuta 2010 23:53:08:
> > > On Fri, Jul 23, 2010 at 10:42:53PM +0300, Anssi Hannula wrote:
> > > > Michael Niedermayer kirjoitti perjantai, 23. hein?kuuta 2010 21:29:38:
> > > > > On Fri, Jul 23, 2010 at 06:40:30AM +0300, Anssi Hannula wrote:
> > > > > > Anssi Hannula kirjoitti torstai, 22. hein?kuuta 2010 06:15:17:
> > > > > > > Hi!
> > > > > > > 
> > > > > > > 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)
> > > > > > 
> > > > > > The first patch added a warning (mixed code and declarations),
> > > > > > attached is a fixed one. The second patch was ok.
> > > > > 
> > > > > i dont think this code will work reliable like this as the chances
> > > > > are pretty high that mp3 or ac3 will be detected in random data
> > > > > with a very low score
> > > > 
> > > > That won't happen, since set_codec_from_probe_data() gets called with
> > > > score AVPROBE_SCORE_MAX / 4 (i.e. any score <= AVPROBE_SCORE_MAX / 4
> > > > is ignored), except in the very last iteration (st->probe_packet ==
> > > > 0), which we do not actually reach due to s->probe_fallback_bytes.
> > > 
> > > that is if probe_packets is "larger" than probe_fallback_bytes
> > > this feels quite hackish and it depends on how many bytes there
> > > are per packet
> > 
> > Indeed.
> > 
> > And I guess it would be nice to avoid probing the full 80 kB if there are
> > no DTS start codes in the first wav "packet" (4 kB)..
> > 
> > > I think it should be fallback_codec_id and fallback_score
> > 
> > Sounds better.. but do you have an idea of good semantics for
> > fallback_score?
> > 
> > I can only think of this: Assume a fallback_score of AVPROBE_SCORE_MAX/4.
> > dts_probe could set AVPROBE_SCORE_MAX/4 if it detects marker(s) but the
> > probe buffer was too small to make a proper decision. After being called
> > with a big enough buffer, it can return 1 or AVPROBE_SCORE_MAX/2 + 1,
> > depending if there were enough markers or not.
> > I.e. score < AVPROBE_SCORE_MAX / 4  => fallback selected
> > 
> >      score ==AVPROBE_SCORE_MAX / 4  => probe continued
> >      score > AVPROBE_SCORE_MAX / 4  => probed codec selected
> > 
> > Actually, we could maybe just use always AVPROBE_SCORE_MAX/4 as the
> > "unsure" value, no need for the demuxer to select one..
> 
> yes
> 
> > Is the above anything like you were thinking?
> 
> yes

OK, revised patches attached.

-- 
Anssi Hannula