A possibly-better approach to seeking.
authorCarl Hetherington <cth@carlh.net>
Fri, 7 Oct 2016 15:22:38 +0000 (16:22 +0100)
committerCarl Hetherington <cth@carlh.net>
Thu, 17 Nov 2016 01:06:31 +0000 (01:06 +0000)
commit97d39f46795af78b84d5f7bc9118a188f2864781
tree354ad3d03ba0bf545fc76102c907dab2d31a0b08
parent987e2daa218ab39c6ddc3780667eedaab1c0872e
A possibly-better approach to seeking.

Before this commit, decoders try to guess whether they should
request a seek based on what they have in their buffers.  This
seems reasonable for video and audio, which will always (I think)
have some data lying around to give an indication of where their
parent decoders are in the timeline.

It doesn't work so well for subtitles, as the storage of subs is
cleared out based on time (+/- 5s of "now") so there is a good chance
that the storage will be empty.  This gives the subtitle decoder no
chance of knowing where its parent is, so it's very likely to seek.

This commit asks the parent decoder to seek if it wants to, and it
decides based on a knowledge of roughly where it is in the timeline.
Hence the sub-decoders just see if they have got the data that is being
requested, and if not they suggest to the parent that it might like
to seek.  They then start calling pass().  Hence the parent should only
seek if some calls to pass() are not going to elicit the required data
in a reasonable time.
14 files changed:
src/lib/audio_decoder_stream.cc
src/lib/dcp_decoder.cc
src/lib/dcp_subtitle_decoder.cc
src/lib/decoder.cc [new file with mode: 0644]
src/lib/decoder.h
src/lib/ffmpeg_decoder.cc
src/lib/ffmpeg_decoder.h
src/lib/ffmpeg_subtitle_stream.cc
src/lib/image_decoder.cc
src/lib/subtitle_decoder.cc
src/lib/text_subtitle_decoder.cc
src/lib/video_decoder.cc
src/lib/video_mxf_decoder.cc
src/lib/wscript