[FFmpeg-devel] [PATCH 2/2] ADP demuxer

[Michael Niedermayer]

On Wed, Apr 24, 2013 at 03:01:09AM -0300, James Almer wrote:
> On 24/04/13 12:01 AM, Michael Niedermayer wrote:
> > in that case you could test all the headers within 260+ bytes instead
> > of just 2
> > 
> > 
> >> valid frame to avoid tiertexseq files being misdetected as adp (The first 256 bytes 
> >> are all 0 on tiertexseq).
> >> If buf_size is < 260 and the probe for tiertexseq succeeds, then the probe for adp 
> >> will succeed as well. Making adp return a lower score than tiertexseq in that case 
> >> will make sure tiertexseq is chosen.
> >>
> >> I'll make it return 0 if that's preferred, though.
> > 
> > i think 1 is better
> > returning 0 for short adp files doesnt feel correct
> 
> Would something like this be ok?
> 
>     if (p->buf_size < 32)
>         return 0;
> 
>     for (i = 0; i < p->buf_size - 3; i+=32)
>         if (p->buf[i] != p->buf[i+2] || p->buf[i+1] != p->buf[i+3])
>             return 0;
> 
>     return p->buf_size < 260 ? 1 : AVPROBE_SCORE_MAX / 4;

yes


> 
> >>
> >>>> +    if (s->pb->seekable)
> >>>> +        st->duration          = avio_size(s->pb) / 32 * 28;
> >>>
> >>> Is this check needed ?
> >>> avio_size() should harmlessly fail if the protocal cant seek
> >>
> >> Many other demuxers check for pb->seekable before calling avio_seek() or avio_size(),
> >> so i figured it was the proper way to handle this.
> >> Personally, I'd like to keep it this way.
> > 
> > whichever way you prefer
> > 
> > 
> >>
> >>>> +AVInputFormat ff_adp_demuxer = {
> >>>> +    .name           = "adp",
> >>>> +    .long_name      = NULL_IF_CONFIG_SMALL("ADP"),
> >>>> +    .read_probe     = adp_probe,
> >>>> +    .read_header    = adp_read_header,
> >>>> +    .read_packet    = adp_read_packet,
> >>>> +    .extensions     = "adp,dtk",
> >>>> +};
> >>>
> >>> does seeking work with this demuxer ?
> >>> (also see AVFMT_GENERIC_INDEX)
> >>
> >> Doesn't look like, even after adding that flag "ffmpeg -ss 1 -i sample.adp" warns 
> >> that it couldn't seek.
> > 
> > hmm
> > probably would make sense to compare with a other simple demuxer that
> > can seek
> 
> I can't seem to find anything different in other simple demuxers that has any effect
> here.

hmm, ok, this will need more investigation then once its in ffmpeg

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130424/aafb46d4/attachment.asc>