| Age | Commit message (Collapse) | Author |
|---|
|
In one example we have the sequence
video 3088,377
sub 3087,334
sub 3088,710
video 3088,419
so the 3087,334 sub is very late. Here we insert a queue to bring
subtitle packets a little forward for processing.
There is already a similar thing in the player (_delay) but adding
a longer delay there seems wasteful because a) the video is by
that point already decompressed and b) this problem only
applies to FFmpeg-decoded files (and then, I think only if we are
previewing or burning in subtitles).
|
|
|
|
Previously if some FFmpeg content was set to use only its subtitles, and
the first subtitle was 1 minute in to the content, the content would be
selected for pass() until its first minute had been scanned.
This could be slow, and incorrect as on the way to this 1 minute we want
to look at other content.
Here we store the PTS of dropped packets to use as a fallback position
when there is no video or audio enabled.
|
|
|
|
Previously a call to flush() could result in a lot of audio being
emitted from the decoder (if there is a big gap between the end
of the audio and the video). This would end up being emitted in
one chunk from the player, crashing the audio analyser with an OOM
in some cases.
|
|
|
|
|
|
The comment says that we're handling differences between channel
counts in the frame and stream but the code wasn't doing that.
|
|
Previously if there were two images at the same time we would start
them both, then the stop time would be set in the second one but
not the first. This meant that the first one would hang around
forever.
|
|
|
|
|
|
|
|
After seeking it appears that we often get irrelevant errors from this
method. ffplay.c seems to ignore them, and this commit means that
we do too (just logging them).
I think these errors during a non-seeking "encoding" run could be
cause for concern; perhaps we should take more note of them in that
case.
|
|
The comments discuss this in a bit more depth, but basically we see
errors from avcodec_send_packet after seek. ffplay etc. seem basically
to ignore all errors from avcodec_send_packet, and I can't find a
"proper" fix, so here's a half-way house hack: ignore some errors
after seek. Nasty.
|
|
|
|
|
|
This seems necessary with the multi-threaded decoding; it looks
like we were doing it quite wrong before but getting away with it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
with a pts.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
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.
|
