[FFmpeg-devel] [PATCH] Add SUP/PGS subtitle demuxer

[wm4]

On Sun, 31 Aug 2014 15:16:49 +0200
Reimar Döffinger <Reimar.Doeffinger at 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.Doeffinger at 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.