aboutsummaryrefslogtreecommitdiffhomepage
path: root/video/sws_utils.c
diff options
context:
space:
mode:
authorGravatar wm4 <wm4@nowhere>2017-10-24 19:33:01 +0200
committerGravatar wm4 <wm4@nowhere>2017-10-24 19:35:55 +0200
commita5b51f75dc049b0713f4bb77cae4cb9e39ae8d49 (patch)
treeb7bc61f0f67e0cee678537ad0077b61c78b050db /video/sws_utils.c
parentbb9679d9a3c681d7b87664a4b09b284b889561a1 (diff)
demux: get rid of demux_packet.new_segment field
The new_segment field was used to track the decoder data flow handler of timeline boundaries, which are used for ordered chapters etc. (anything that sets demuxer_desc.load_timeline). This broke seeking with the demuxer cache enabled. The demuxer is expected to set the new_segment field after every seek or segment boundary switch, so the cached packets basically contained incorrect values for this, and the decoders were not initialized correctly. Fix this by getting rid of the flag completely. Let the decoders instead compare the segment information by content, which is hopefully enough. (In theory, two segments with same information could perhaps appear in broken-ish corner cases, or in an attempt to simulate looping, and such. I preferred the simple solution over others, such as generating unique and stable segment IDs.) We still add a "segmented" field to make it explicit whether segments are used, instead of doing something silly like testing arbitrary other segment fields for validity. Cached seeking with timeline stuff is still slightly broken even with this commit: the seek logic is not aware of the overlap that segments can have, and the timestamp clamping that needs to be performed in theory to account for the fact that a packet might contain a frame that is always clipped off by segment handling. This can be fixed later.
Diffstat (limited to 'video/sws_utils.c')
0 files changed, 0 insertions, 0 deletions