[FFmpeg-devel] [PATCH 1/2] lavf/subtitles: add ff_subtitles_queue_seek().

[Michael Niedermayer]

On Tue, Nov 27, 2012 at 04:21:55PM +0100, Clément Bœsch wrote:
> On Mon, Nov 26, 2012 at 03:39:58AM +0100, Michael Niedermayer wrote:
> [...]
> > > > > +            if (pts >= min_ts && pts <= max_ts && ts_diff < min_ts_diff) {
> > > > > +                min_ts_diff = ts_diff;
> > > > > +                idx = i;
> > > > > +            }
> > > > 
> > > > iam not sure this is correct, please correct me if i misunderstand
> > > > something.
> > > > consider there are subtitles, first one displays from 2 to 10 second
> > > > second one displays from 5 to 18 seconds
> > > > if you want to seek to second 8 you actually need to seek to 2 to
> > > > get both displayed at your target
> > > > 
> > > 
> > > I admit I didn't give much thoughts about it; as stated in the commit
> > > description I took this code from lavf/assdec:read_seek2(), added in
> > > ac066b83. The code is just adapted to work with FFDemuxSubtitlesQueue, and
> > > it appeared to work fine with my simple tests so I didn't look much into
> > > it.
> > > 
> > > Now if we want to honor the overlapping issue you're mentioning, we will
> > > likely need to introduce a small threshold, such as limit to 5 or 10
> > > seconds
> > 
> > > (imagine the case where a subtitle event from the beginning up to
> > > 1 hour, like a banner, branding or something).
> > 
> > > BTW, I don't know what are
> > > the consequences of a very incorrect seek with subtitles…
> > 
> > for a video with subtitles, you dont see the correct subtitles after
> > seeking or in case of -ss with ffmpeg they are permanently missing
> > in the transcoded file.
> > That assumes here that you flush the renderer, seek and then feed it
> > with the following subtitles.
> > 
> 
> If we have a subtitle event starting at t=2sec, with duration=1hour,
> followed by normal subtitles at a frequency of about 1000 subtitles per
> hour, what happens if the seek at t=30min happens to actually seek at
> t=2sec? What's gonna happen to the ~500 subtitles to keep up with the
> current time? Remuxing them doesn't sound right, and same for making the
> player display all of them as fast as possible.

can we discard such "past" subtitles somewhere conveniently, so that
effectively only the 1h and the actually relevant subtitles after that
are used ?
(that could be done efficiently in the demuxer or less efficiently
 afterwards)

> 
> This is an extreme case, but similar situations are going to happen if we
> start looking at solving these overlapping issues.
> 
> BTW, I'm a bit reluctant to changing this in this patch (I'm just
> moving/copying the code to allow re-use it with all the subtitles format),
> could we delay that feature, or you believe it's blocking?

delay is fine, but it has to be dealt with at some point, and
preferably before too much code uses the function because it may
become more painfull then if something needs to be changed for all
users


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- 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/20121127/48e6fa7c/attachment.asc>