| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
