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

[Michael Niedermayer]

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


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

this feels a bit hackish to me

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100804/59c1328b/attachment.pgp>