[FFmpeg-devel] [PATCH] Detect DTS in wav (issue70) +?about?ac3-in-wav
Michael Niedermayer
michaelni
Wed Aug 4 15:10:51 CEST 2010
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>
More information about the ffmpeg-devel
mailing list