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

[Anssi Hannula]

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?

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

> 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 
implemented either as a simple flag, or some kind of "possible_score" value 
that indicates that there is a reasonable-to-high possibility that bigger 
probe buffer would result in possible_score getting reached (for example, 1 
marker was found but 2nd would be outside buffer). The core could then make 
the buffer bigger if some format returned a possible_score that is higher than 
the highest actual score.

I was under the impression that such a significant modification/addition was 
not something we wanted for just a couple of formats, though. Was I wrong, and 
it would actually be ok if it just were clean and workable?

-- 
Anssi Hannula