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

[Anssi Hannula]

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..

Is the above anything like you were thinking?


And here's yet another alternative approach to the issue:
No changes to API, just use normal CODEC_ID_PROBE in wav and have 
wav_read_packet() itself switch to PCM codec_id (ending probe) when a) no DTS 
markers exist in first packet, or b) a defined amount of packets have passed 
without the regular probe code finding anything credible.

> or maybe even
> a pcm probe(), which is not impossible to do (0th order compressability
> before and after dct)

Well, this should be solvable without one..

-- 
Anssi Hannula