| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This fixes the failure to keep track of the `position' of
each stream of a multi-stream file. It also tidies things
up a bit.
|
|
debug logging.
|
|
|
|
|
|
|
|
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.
|
|
|
|
This fixes audio-only content when the first-emitted audio is not
at time zero. This used to cause a seek which is not possible
with audio-only. This commit removes the unnecessary seek which
was due to missing silent-padding of the first-emitted audio.
|
|
Before this commit, an audio delay of -110ms on a test project
would result in a seek on every video and audio fetch.
This commit does two things to fix that:
1. Don't discard audio data that arrives with a timestamp
before the last seek time. In the case that we are fixing
we had the following sequence:
- video seeks to some frame F
- this causes audio data to arrive a little before F
- this audio data is discarded
- and audio get happens just after F
- the audio code thinks it must seek rather than just pass()ing
since it has no data
If we keep the audio data from before the seek our _decoded
will be much closer to the audio request, so a pass() is more
likely to happen.
2. Extend the length of time that we will happily pass() for
rather than seeking when looking for audio data. Seeking is
really bad so we can tolerate quite long times here. The sensible
length of this value should probably be investigated as the
one in this commit is a finger-in-the-air guess.
|
|
|
|
Support for this seems to vary wildly across DoM's build
targets. Stuff that builds on 16.04 won't build on 14.04,
for example. Seems to not be worth the hassle now.
This reverts commit 5a5324ed3a381a86dfe0a6e3932c1d58fdcd596f.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
but only for preview.
|
|
This reverts commit 9e025d3f85f9d6d855b3d5e6c90bca0eac3a3d49.
It causes corruption in prophet_clip.xml for reasons that
are not yet known.
|
|
The "accumulation" of, for example, video data when we are looking
for audio data is an *optimisation* to reduce the number of seeks.
It should not be necessary for correctness (the output should be right
even if we never kept anything except what we were looking for).
Doing this accumulation is not always an optimisation; sometimes not
doing it is better. Avoiding it when going back for subtitles is one
of these cases.
|
|
|
|
|
|
|
|
frame rates.
|
|
|
|
|
|
I believe both are necessary; doing floor instead of round caused #648.
|
|
|
|
|
|
This feels wrong: it means that it is possible for FFmpegDecoder
to discard packets. I can't see how this is ok in all cases:
maybe we were lucky that it worked at all.
|
|
in a similar way to the V1 patch.
|
