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

[Michael Niedermayer]

On Thu, Aug 19, 2010 at 05:48:47AM +0300, Anssi Hannula wrote:
> On Wednesday 18 August 2010 20:55:30 Michael Niedermayer wrote:
> > On Wed, Aug 18, 2010 at 04:19:40PM +0300, Anssi Hannula wrote:
> > > On Wednesday 18 August 2010 13:33:11 Michael Niedermayer wrote:
> > > > On Wed, Aug 18, 2010 at 08:24:58AM +0300, Anssi Hannula wrote:
> > > > > On Wednesday 18 August 2010 07:29:15 Anssi Hannula wrote:
> > > > > > On Tuesday 17 August 2010 15:26:52 Michael Niedermayer wrote:
> > > > > > > i meant that the code is a mess and id like it to be simpler.
> > > > > > 
> > > > > > Attached is a completely different simpler approach, then.
> > > > > > Since we are about to do the
> > > > > > lower-wav-score-for-s16le-files-if-small-buffer trick anyway for
> > > > > > the spdif-in-wav files, attached patch does the same for dts-
> > > > > > in-wav, marking such files as raw dts.
> > > > > > 
> > > > > > Better?
> > > > 
> > > > no, its still a mess
> > > 
> > > So it is worse than the fallback_id one?
> > 
> > i dont know, ive not seen a clean implementation of either solution yet
> > 
> > > > everything looks much more complex than it should be and its not clear
> > > > at all why the changes are done.
> > > 
> > > Ok.
> > > 
> > > > a patch touching probe functions from 2 seperate formats is already
> > > > quite suspect.
> > > > if dts detection is not good enough it can be improved in a seperate
> > > > patch
> > > > and each improvement should be seperate and be justified
> > > > for example why do you add such huge amounts of code, is the dts
> > > > detection failing for you?
> > > 
> > > The current dts detection returns AVPROBE_SCORE_MAX/2+1 on match, which
> > > won't be enough to top wav's AVPROBE_SCORE_MAX-1.
> > 
> > but your patch reduced wavs score IIRC
> 
> Only for small probe buffers. If the probe buffer is large enough, wav still 
> returns AVPROBE_SCORE_MAX-1 (otherwise wav probe would need maximum probe 
> buffer, which we obviously do not want).
> 
> > > The added code allows dts probe to return AVPROBE_SCORE_MAX when dts
> > > markers are found with intervals which makes the stream bitrate match
> > > PCM bitrate (and thus transmittable in standard pcm wav / audiocd).
> > 
> > what does a pcm wav bitrate have to do with dts detection?
> 
> Well, I think it is more likely to be a dts file if there are a couple of dts 
> marks found at a regular intervals (that make it match pcm bitrate) than if 
> there are a couple of dts marks randomly there, no?

again what does pcm bitrate has to do with this or what even is pcm bitrate
in the context of dts?


> 
> > dts_probe() should return a score that represents how likely it is dts
> > if it shows false positives or false negatives it should be improved
> > same for wav.
> 
> If all of wav/dts/spdif probe functions strictly followed that, everyone of 
> those would always be detected as 'wav', as dts/spdif can't return anything 
> except "no chance" or "possibly" with the initial probe buffer..

what?!

if p_wav is the probability that a file was created as wav file and p_dts is
the probability that it was created as dts file.
you must with ideal probabilities have p_wav + p_dts <=1 if we assume that
noone creates files that are intended to be both wav and dts.
and p_dts surely will be > 0.5 for a valid dts file thus p_wav must be small

The probe scores do not represent how likely an array of bytes complies to a
spec (this would cause raw to always return MAX) but how likely
the input has actually been created as such file compared to something else.


> 
> > this may very well not be enough and some less clean code might be needed
> > i know but it feels as if you are picking the first thing that works and
> > make no attempt at picking the simplest and cleanest solution
> > maybe iam wrong but iam missing some kind of argumentation why it cant be
> > done cleaner
> 
> Well I was looking for some guidance on what kind of solution would be 
> preferable. But I now see it is more like "any approach is fine, as long as it 
> works and is clean" :)
> 
> IMHO the cleanest solution to both dts/spdif (no matter if we go the 
> fallback_id way or detect-as-raw way, or even chained-demuxer way in the 
> future) is some kind of way for probe functions to signal that they'd like to 
> get more data before they can do an assessment. This could possibly be 

again, probe functions return how likely the input is of their kind compared
to it being something else.
with a small buffer some cannot be sure and return a small score and this is
enough to try with a larger buffer.

if a probe function returns a very high score and is wrong then this is a bug
in this and only this probe function

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

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- 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/20100819/8f62f78c/attachment.pgp>