Whether a frame is interlaced or not is unknown at the time of
buffer allocation, so caps on the buffer in opaque will have
a previous frame's interlaced flag set. So if interlacedness
changes, we update the buffer (if any) caps with the correct
interlaced flag once we know.
https://bugzilla.gnome.org/show_bug.cgi?id=656155
There seems to be a little bit of non obvious logic where
the QoS logic can decide to not drop decoding a frame and
pass it to ffmpeg, telling it to drop.
In this case, the QoS logic does not drop the frame itself,
but since the frame will end up being dropped, we still
mark it as dropped and post a QoS message.
https://bugzilla.gnome.org/show_bug.cgi?id=657950
This include decoder for ASS, SRT, PGS, DVD and DVB. Those are generated
with bad capabilities and are not usable in GStreamer. Other elements exist
to handle those subtitle formats.
https://bugzilla.gnome.org/show_bug.cgi?id=658019
Add a max-threads property, which defaults to '0 = auto'
Add a utility function taken from libschroedinger which sets
the ffmpeg worker thread count to match the computer processor
count by default.
When input buffer timestamps are invalid, next timestamp are used for
audio. Then, the next out timestamp is updated with the used timestamp
and the calculated duration. However, if the used timestamp is invalid,
it should not be used. Otherwise, the next buffer will use a wrong
timestamp that is not in the clipped segment, making the buffer to be
dropped.
This fixes playback with SBTVD MPEG TS streams, using AAC LATM.
A keyframe may be quite a while in the future, and the decoder
has no way of knowing this. A poor decision could mean quite some
time with no video output.
This decision should be left to the upstream element: a demuxer
might know about incoming keyframes, or some other element might
be able to request a keyframe.
Fixes bug #649372.
Right now it doesn't use any of the extra fields AVPacket provides.
It might be wise to investigate the pts/dts ones to see if we can finally
get rid of the timing-related cruft we have.
Set the caps right after allocation of the buffer because we know the buffer is
writable then and we are correctly negotiated. Since ffmpeg keeps around
references to frames, making the buffer metadata writable where it was done
before pushing will always end up with a copy and that makes the sink do a slow
memcpy all the time.
FFMpeg parsing and decoding calls require to additionally allocate bytes
at the end of the input bitstream and this padding must be initialized
to zero.
https://bugzilla.gnome.org/show_bug.cgi?id=595590
Sometimes the parser loses track of timestamps and starts to reuse old
timestamp. Feed it some dummy data and clear some context variables to work
around the problem.
When estimating the frame duration, the diff between two incomming timestamps
should be scaled by the amount of frames in the interval. Improves duration
estimation and DTS interpolation.
Use the diff between input timestamps to estimate the duration when no duration
is set on input buffers. Only do this when there are no reordered input
timestamps. Improves interpolation in DTS mode when no input duration is set.
When we flush the parser cache, we only need to clear the bytes of the cache,
not the complete state of the cache. In the case of H264 this doesn't require
the parser to receive a new SPS/PPS after a DISCONT buffer.
Add function to reset the timestamp tracking.
Check for reordered timestamps on the input buffers and assume PTS input
timestamps when we see reordered timestamps.
Recover from an occasionally wrong input timestamp by also tracking the output
timestamps. When we detect a reordered output timestamp, assume DTS input
timestamps again.
Fixes#611500
The buffer durations were not being reordered along with the timestamp
and offset of the buffers, resulting in buffers using the duration of the
latest incoming frame instead of their original frame.
Fixes#611398
