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

[Anssi Hannula]

On Thursday 19 August 2010 13:03:03 Michael Niedermayer wrote:
> 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?

It is the bitrate of a 16-bit stereo PCM stream. The effective stream bitrate 
of a DTS stream placed in cd/wav has to match this, as the intent is that e.g. 
a dumb standard CD player can play the DTS track at normal speed and then 
directly feed the audio via s/pdif to an A/V receiver that then decodes the 
DTS stream.
The bitrate can't be higher or lower as the CD player reads data at a constant 
speed.

(this is practically the same as iec61937 encapsulation (our "spdif" 
muxer/demuxer), just without the iec61937 headers)

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

Ok.

I guess the latest detect-as-raw method is indeed probably the way to go, 
then, but it needs more documentation + splitting + code sharing.

BTW, the problem that made the fallback_id solution complex is that in order 
to make it behave in the way you describe above, the fallback_score would need 
to depend in the buffer size (i.e. with small buffer we can't be sure if we 
should fallback, with large buffer we can be quite sure).

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

-- 
Anssi Hannula