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

Clément Bœsch ubitux at gmail.com
Tue Nov 27 16:21:55 CET 2012


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.

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?

> If you consider a system where all the files subtitles are send to
> the renderer at startup then this problem does not arrise in such case
> that is the seeking function is unused. but this doesnt solve the
> transcoding case and it only works when the container makes all
> subititles efficiently available at startup
> 

Ah indeed I didn't have in mind the situation where the whole file is sent
to the renderer at first.

> 1 hour long subtitles could be split, for example on load or during
> seeking virtually to start from the seeking position, or it could
> simply be accepted that they are output as they are on seeking.

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121127/a7250bc4/attachment.asc>


More information about the ffmpeg-devel mailing list