[FFmpeg-devel] [PATCH 2/2] ADP demuxer
Michael Niedermayer
michaelni at gmx.at
Wed Apr 24 05:01:16 CEST 2013
On Tue, Apr 23, 2013 at 11:28:26PM -0300, James Almer wrote:
> On 23/04/13 7:54 PM, Michael Niedermayer wrote:
> > On Sat, Apr 20, 2013 at 08:12:24PM -0300, James Almer wrote:
> >> +static int adp_probe(AVProbeData *p)
> >> +{
> >> + if (p->buf[0] == p->buf[2] && p->buf[1] == p->buf[3]) {
> >> + if (p->buf_size < 260)
> >> + return AVPROBE_SCORE_MAX / 4 - 1;
> >
> > return 0 or 1 here IMHO
> > just a single frame is very odd and doesnt look like a correct file
>
> Frames are 32 bytes long. I arbitrarily chose 256-259 when checking for another
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
>
> >> + 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
>
> > No more comments from me, rest looks good, feel free to ask for a
> > merge once all dependancies are ready too
>
> Ok, thanks.
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- 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/8ef97d21/attachment.asc>
More information about the ffmpeg-devel
mailing list