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

[Anssi Hannula]

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 :)

-- 
Anssi Hannula