View Bug Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000719 | DCP-o-matic | Clean-up | public | 2015-10-15 12:02 | 2021-01-08 00:30 |
Reporter | carl | Assigned To | carl | ||
Priority | normal | Severity | minor | Reproducibility | N/A |
Status | closed | Resolution | fixed | ||
Summary | 0000719: Subtitling rework | ||||
Description | We have the following sources of subtitles:
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. | ||||
Tags | No tags attached. | ||||
Branch | |||||
Estimated weeks required | |||||
Estimated work required | Average | ||||
|
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. |
|
I think we now have a reasonable compromise for this. |
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 |