View Bug Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001581 | DCP-o-matic | Bugs | public | 2019-07-07 22:45 | 2021-10-08 00:06 |
| Reporter | carl | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | open | ||
| Target Version | 2.16.0 | ||||
| Summary | 0001581: Burnt-in subtitles sometimes missing from DCP | ||||
| Description | Content is a MKV and a SRT. MKV has subtitles but they are not being used. MKV's subtitles finish about 16s before the end of the MKV (let's say at time t). After this point the MKV's decoder reports its position as t forever, since t is found by Decoder::position after it asks the TextDecoder where it is. This means that the MKV is pass()ed instead of the SRT, so eventually there is a frame of video for which a sub from the SRT has not yet been received. | ||||
| Additional Information | |||||
| Tags | No tags attached. | ||||
| Branch | |||||
| Estimated weeks required | |||||
| Estimated work required | Undecided | ||||
|
|
Can the TextDecoder know that it is "finished" i.e. no more subs will be emitted? I don't think so; here the problematic TextDecoder is being fed by subs muxed into a MKV. |
|
|
Could FFmpegDecoder ignore subtitles when doing Decoder::position() in the hope that they will be "swept along" by the emissions from video/audio? |
|
|
We could ignore unused subtitle streams in MKVs but this would just be a sticking plaster and it doesn't solve the underlying problem (and wouldn't solve the case when the MKV's subs were being used). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-07-07 22:45 | carl | New Bug | |
| 2019-07-07 22:46 | carl | Description Updated | |
| 2019-07-07 22:47 | carl | Note Added: 0003381 | |
| 2019-07-07 22:50 | carl | Note Added: 0003382 | |
| 2019-07-07 22:51 | carl | Note Added: 0003383 | |
| 2019-07-08 00:19 | carl | Status | new => resolved |
| 2019-07-08 00:19 | carl | Target Version | 2.14.x => 2.16.0 |
| 2021-10-08 00:06 | carl | Status | resolved => closed |
