View Bug Details

IDProjectCategoryView StatusLast Update
0000719DCP-o-maticClean-uppublic2021-01-08 00:30
Reportercarl Assigned Tocarl  
PrioritynormalSeverityminorReproducibilityN/A
Status closedResolutionfixed 
Summary0000719: Subtitling rework
Description

We have the following sources of subtitles:

  1. FFmpeg image and text subtitles interleaved into the (possibly very large) file.
  2. SubRip / DCP XML subtitles which are stored in small text files separate from video / audio data.

The basic problem with subs is that they do not occur regularly. At the moment we search through (1) files and make a note of where the subs are. This means that if we want the image at time t we know whether there is a subtitle there and when it started. Hence we can seek backwards to find that subtitle.

This works ok except that it is inefficient, especially for long subtitles. If there is a 30s sub we may have to seek back 30s to find the start of it so we can read it in. We then scan forward again the 30s, all the while decoding video and audio packets.

Maybe we should change the whole thing so that all subs can be treated as (2), i.e. arbitrary subs can be obtained quickly without any seeking of the containing file. This would mean writing the subs to the project folder when they are "found" then pulling them off disk when required. The subs stuff would then come out of the pass() API altogether and just fetched without any seeking or whatever.

This would probably make the code much neater, improve speed under seek, but would mean that more stuff is kept in the project, ready to be made out of date, deleted accidentally etc. etc.

TagsNo tags attached.
Branch
Estimated weeks required
Estimated work requiredAverage

Activities

carl

2015-10-15 12:31

administrator   ~0000917

Last edited: 2015-10-15 12:32

Another thought is that all this is unnecessary for running from beginning to end of a piece of content in sequence: it's only for seeking. Is it worth all this effort to ensure that the odd sub isn't dropped when you seek about in the preview?

For better or for worse the 2.x setup is based on the ability to get an arbitrary frame with no distinction between seek and run.

carl

2019-11-17 21:47

administrator   ~0003590

I think we now have a reasonable compromise for this.

Bug History

Date Modified Username Field Change
2015-10-15 12:02 carl New Bug
2015-10-15 12:31 carl Note Added: 0000917
2015-10-15 12:32 carl Note Edited: 0000917
2015-10-30 13:31 carl Assigned To => carl
2015-10-30 13:31 carl Status new => acknowledged
2019-11-17 21:47 carl Status acknowledged => resolved
2019-11-17 21:47 carl Resolution open => fixed
2019-11-17 21:47 carl Note Added: 0003590
2021-01-08 00:30 carl Status resolved => closed