[FFmpeg-devel] [PATCH] S/PDIF demuxer ( was:[PATCH] Detect?DTS?in wav (issue70) + about ac3-in-wav)

[Anssi Hannula]

Anssi Hannula kirjoitti keskiviikko, 4. elokuuta 2010 18:15:12:
> Michael Niedermayer kirjoitti keskiviikko, 4. elokuuta 2010 15:53:04:
> > On Wed, Jul 28, 2010 at 05:12:21AM +0300, Anssi Hannula wrote:
> > > Michael Niedermayer kirjoitti tiistai, 27. hein?kuuta 2010 16:59:27:
> > > > On Tue, Jul 27, 2010 at 07:59:13AM +0300, Anssi Hannula wrote:
> > > > > +    if (sync_codes == consecutive_codes + 1 &&
> > > > > +        !memcmp(p->buf + 8, "WAVE", 4) && !memcmp(p->buf, "RIFF",
> > > > > 4)) +        /* all sync codes (except first one as it was only
> > > > > after WAV headers)
> > > > > +           were consecutive, but the buffer was too small;
> > > > > +           also, this looks like a WAV file, so we need to delay
> > > > > wav demuxer
> > > > > +           from grabbing this file until we get a big enough
> > > > > buffer to see if
> > > > > +           there are more consecutive codes (we want
> > > > > to be selected for
> > > > > +           (ac3-in-)spdif-in-wav as chained demuxers
> > > > > are not yet supported),
> > > > > +           therefore return the same score as
> > > > > wav demuxer to make it a tie */
> > > > > +        return AVPROBE_SCORE_MAX - 1;
> > > > 
> > > > or make the wav demuxer only return a low score for small probe sizes
> > > > above would for example behave oddly if the wav demuxer is disabled
> > > 
> > > How low?
> >  
> >  < AVPROBE_SCORE_MAX/4 so the code in utils.c doesnt stop early
> >  
> > > I mean, if we change it to AVPROBE_SCORE_MAX / 8 or so, every wav file
> > > would needlessy be probed 1MB, even while 2k would have been enough (if
> > > no spdif sync codes were in first 2k).
> > 
> > we can return a larger score once the amount of data available becomes
> > large enough like 100k ?
> 
> It would still mean that all normal wavs are probed 50-100k even if 2k
> would be enough (as spdif-in-wav would've started in the beginning).
> 
> But if that is preferable over a wav-specific hack in spdif demuxer, I can
> of course do it :)

Alternatively there could be some way for a probe function to signal the core 
that "this is probably it, please continue probe with a bigger buffer and 
ignore other positives for this round".

Either some predefined score value, or something like
#define AVPROBE_SCORE_MOREDATAPLEASE -1
(with a better name that I can't come up with now)

This would allow spdif to return that value in case there are sync codes but 
the buffer is too small to know for sure, preventing wav demuxer from grabbing 
it until spdif has enough data to say a definitive yes or no.

But would that make probing too complex?

-- 
Anssi Hannula