On Sun, 31 Aug 2014 15:16:49 +0200 Reimar Döffinger <reimar.doeffin...@gmx.de> wrote:
> On Sun, Aug 31, 2014 at 02:57:54PM +0200, wm4 wrote: > > On Sun, 31 Aug 2014 14:25:21 +0200 > > Reimar Döffinger <reimar.doeffin...@gmx.de> wrote: > > > > > On Sun, Aug 31, 2014 at 01:04:29PM +0200, wm4 wrote: > > > > +static int sup_probe(AVProbeData *p) > > > > +{ > > > > + if (p->buf_size < 2 || memcmp(p->buf, "PG", 2)) > > > > + return 0; > > > > + return AVPROBE_SCORE_EXTENSION; > > > > > > I understand if you consider it not worth the effort, > > > but ideally this would scan ahead several packets, > > > and if it all matches up return a higher score. > > > The MP3 probe function is possibly a good reference (though > > > this one should be bit simpler). > > > > Other formats are also relatively lazy and just check the magic atthe > > start of the file and call it a day (e.g. flac, some img2dec probers). > > Of course it's possible that 2 bytes (and ASCII) is a bit too prone to > > false positives, so maybe it should be improved. > > > > Since PGS packets can be only at most ~64KB big, I guess it would be > > feasible to check whether there is a second PGS packet after the first > > one. Would that be sufficient? > > Ideally it would scan the whole probe buffer, and return a score based > on how many consecutive packets it found compared to the probe size > (more or less). > tools/probetest is a useful tool, but so far it will only check if > the score is above MAX/4, so demuxers (needlessly) crappy probe but > also low score get a pass... Well yes, it would be possible to loop over the entire probe buffer, until it ends on a packet boundary, or there's a partial cut-off packet. How exactly would you suggest the probe score? Personally, I'd probably do the following: if the header of the first packet is available (i.e. "PG" magic), then return SCORE_EXTENSION-1. If the probe buffer is large enough to include the header of the next packet, and the next packet has no magic (i.e. probably invalid), return 0. Otherwise, return SCORE_EXTENSION+1. Suggestions? > > In theory, it would be nice if the general probe code could jzst try to > > read a few packets... > > Probing is quite performance critical, especially since fringe formats > can even impact the major ones (unless we start sorting them by how > common they are and abort early - but that has its own long list of > issues). > So I think specialized code will remain necessary. > However it might be possible to factor out common approaches, but that > would need some careful checking. Possibly it would make sense to provide a generic function, that creates an in-memory aviobuf, and lets the demuxer read packets from it. Demuxers which need it could use it in the probe function. But yeah, that probably is a bit out of the scope of this tiny patch. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel