diff options
author | wm4 <wm4@nowhere> | 2017-10-24 19:33:01 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2017-10-24 19:35:55 +0200 |
commit | a5b51f75dc049b0713f4bb77cae4cb9e39ae8d49 (patch) | |
tree | b7bc61f0f67e0cee678537ad0077b61c78b050db /video/sws_utils.c | |
parent | bb9679d9a3c681d7b87664a4b09b284b889561a1 (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