| Age | Commit message (Collapse) | Author |
|---|
|
This commit changes the approach with video timing. Previously,
we would (more-or-less) try to use every video frame from the content
in the output, hoping that they come at a constant frame rate.
This is not always the case, however. Here we preserve the PTS
of video frames, and then when one arrives we output whatever
DCP video frames we can (at the regular DCP frame rate).
Hopefully this will solve a range of sync problems, but it
could also introduce new ones.
|
|
|
|
I'm not 100% sure about this but they seem to end up giving audio
packets with no channels and no frames. Here we handle such packets
better.
|
|
|
|
Since e29ce33a36c2e20444d57196defc86d5072bce81 channels is the
number of channels in the frame, and also the number in data,
so we don't need to check this any more.
|
|
On switching to the new FFmpeg send/receive API in
e29ce33a36c2e20444d57196defc86d5072bce81
the channels variable in deinterleave_audio() was switched from
stream channels to frame channels.
I'm not sure if this is right, but it does mean that audio has
`channels` channels, so calling make_silent() up to the stream
channel count is clearly wrong if the stream has more channels
than the frame.
|
|
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.
|
|
|
|
|
|
for fixes to \c tags in SSA files.
|
|
be emitted, instead of the time that the last thing was (#2268).
This is to avoid problems with the example shown in the test, where
just because a subtitle in source A comes before a subtitle in source B,
source A is pass()ed next and may then emit a subtitle which should
be after the next one in B.
|
|
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.
|
|
|
|
|
|
The docs say on EAGAIN we should call avcodec_receive_frame()
and then re-send the same packet again. This should do that.
This is a fix for errors trigged by the accompanying test.
|
|
|
|
|
|
This seems to be what ffplay does and it feels like it makes sense
as frames may be built from multiple packets AFAICS.
|
|
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.
|
|
|
|
|
|
Since the FFmpeg 4.4 update it seems that AVSubtitle::pts is no longer
set (it's AV_NOPTS_VALUE, i think).
Instead we apparently need to get the PTS from the packet, which in
turn requires the stream's timebase.
|
|
|
|
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.
|
|
The test fails if we don't do this; it doesn't really seem 100%
convincing but we are already doing this for audio.
|
|
|
|
|
|
|
|
|
|
|
|
This seems necessary with the multi-threaded decoding; it looks
like we were doing it quite wrong before but getting away with it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Previously we would ignore audio timestamps because they are not
contiguous in a sample-accurate way.
However with bugs like #1833 we do need to obey large discontinuities
in audio timestamps, otherwise we get large sync errors.
Here we change timestamp handling to ignore small discontinuities
in timestamps but not larger ones.
|
|
|
|
instead, assume it should be at timestamp 0.
|
|
hang around. Part of the fix for #1857.
|
|
|
|
|
