View Bug Details

IDProjectCategoryView StatusLast Update
0000981DCP-o-matic[All Projects] Bugspublic2016-11-17 20:37
Reportercarl 
Assigned To 
PriorityimmediateSeverityminorReproducibilityN/A
Status newResolutionopen 
Product Version 
Target Version2.11.0Fixed in Version 
Summary0000981: Merge better-seek branch
Description[]
TagsNo tags attached.
Estimated work requiredAverage

Relationships

Activities

carl

2016-11-07 13:20

administrator   ~0001523

Can we then also get rid of the subtitle period stuff? We can ask the parent decoder where we are so only scan the bit we are asked for.

carl

2016-11-17 01:09

administrator   ~0001548

Merged in 97d39f46795af78b84d5f7bc9118a188f2864781; need to look at subtitle period code.

carl

2016-11-17 11:11

administrator   ~0001551

Had some hacks at this in no-subtitle-scan. The first problem is that you no longer definitely know when a subtitle ends.

One can imagine the corner case of an image subtitle which lasts a long time and is being written as a PNG subtitle in the DCP.

You have to know the duration of the subtitle when you write it to the DCP, but if it's written to a FFmpeg file as separate start/end you have to go through all the way to the end of the subtitle to find the end. This would slow things down a lot, but should still work, especially as the scan should only happen once.

Even with short subs though you may have a problem;

subtitle start packet
pass() until end is found, producing maybe 100s of video frames which are (currently) discarded

Either you need to only write the sub when it finishes, or you need to store all these video frames.

Subtitle sources can be "start/end" or "period". Destinations can be time-critical (burn) or non-time-critical (XML).

Start/end burn -> just assume unknown end means "infinity"
Start/end XML -> write subtitle when end is seen
Period burn -> no problem
Period XML -> no problem

carl

2016-11-17 12:00

administrator   ~0001552

Last edited: 2016-11-17 12:04

View 2 revisions

Calls by Transcoder to Player are interleaved video,audio,sub,video,audio,sub so the Player has to return a subtitle when it's start has been seen, but not necessarily it's end.

Only way around this would be to allow out-of-order subtitle write calls to Writer, which would in turn mean you have to store them all and sort at the end I think.

carl

2016-11-17 20:37

administrator   ~0001553

Also, how do you know how far back to go when seeking to frame N, if the subtitle starts before then?

Bug History

Date Modified Username Field Change
2016-10-24 21:36 carl New Bug
2016-10-24 21:37 carl Priority normal => high
2016-11-02 12:23 carl Priority high => immediate
2016-11-07 13:20 carl Note Added: 0001523
2016-11-17 01:09 carl Note Added: 0001548
2016-11-17 11:11 carl Note Added: 0001551
2016-11-17 12:00 carl Note Added: 0001552
2016-11-17 12:04 carl Note Edited: 0001552 View Revisions
2016-11-17 20:37 carl Note Added: 0001553