Dropping a buffer because we have a seek pending is normal,
and will now happen when we trigger a seek while going through
the packets in a page. So this should not be an error.
Fix problem with the line cache where it would forget the first line in
the cache in some cases.
Keep as much backlog as we have taps. This generally works better and we
could do even better by calculating the overlap in all taps.
Allocated enough lines for the line cache.
Use only half the number of taps for the interlaced lines because we
only have half the number of lines.
The pixel shift should be relative to the new output pixel size so scale
it.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=767921
gst_buffer_copy_region() does not copy the duration if it doesn't start
with the first byte. We just skip the tag here, so the duration is still
valid.
https://bugzilla.gnome.org/show_bug.cgi?id=767791
A low bitrate stream which can pack more than 2 seconds of audio
in a page would cause the stream's position to be updated not
often enough, and would trigger a spurious "jump" via a GAP
event. Instead, we update the stream position after calculating
the new overall segment position.
https://bugzilla.gnome.org/show_bug.cgi?id=764966
Elements inherited from GstAudioDecoder, supporting PLC and introducing
delay produce invalid timestamps. Good example is opusdec with in-band FEC
enabled. After receiving GAP event it delays the audio concealment until
the next buffer arrives. The next buffer will have DISCONT flag set which
will make GstAudioDecoder to reset it's internal state, thus forgetting
the timestamp of GAP event. As a result the concealed audio will have the
timestamp of the next buffer (with DISCONT flag) but not the timestamp
from the event.
The serialization of double typed geographical
coordinates to DMS system supported by the exif
standards was previously truncated without need.
The previous code truncated the seconds part of
the coordinate to a fraction with denominator
equal to 1 causing a bug on the deserialization
when the test for the coordinate to be serialized
was more precise.
This patch applies a 10E6 multiplier to the numerator
equal to the denominator of the rational number.
Eg. Latitude = 89.5688643 Serialization
DMS Old code = 89/1 deg, 34/1 min, 7/1 sec
DMS New code = 89/1 deg, 34/1 min, 79114800UL/10000000UL
Deserialization
DMS Old code = 89.5686111111
DMS New code = 89.5688643
The new test tries to serialize a higher precision
coordinate.
The types of the coordinates are also guint32 instead
of gint like previously. guint32 is the type of the
fraction components in the exif.
https://bugzilla.gnome.org/show_bug.cgi?id=767537
For reverse playback it is important to handle correctly the frame sync
points, which is set when the input buffer doesn't have the DELTA_UNIT flag.
This is handled correctly when decoder is packetized, but when it is not the
frame's sync point is not copied, and the reverse playback never decodes frame
batches.
The current patch adds the buffer's flags to the Timestamp list, where the
timestamp and duration of the input buffers are hold.
There were two consecutive log messages in gst_video_decoder_decode_frame().
Given the information they provide, it is more efficient to squash them into a
single one.
The playback rate is hold in the input_segment member variable, not in the
output_segment, and the parse_gather list was never filled because of that.
This patch changes the comparison with input_segment.
The output segment is only set up after data is output, which might be far in
the future for reverse playback. Also we are here interested in the state at
the current *input* frame (which is the keyframe), not any possible output.
For reverse playback the same behaviour was already implemented in
flush_parse().
For reverse playback, chain_forward() is only used to gather frames and not
for decoding, and it is actually called by the draining logic, causing an
infinite recursion.
While it's a bit tricky to discard frames *before* decoding (because
we might not be sure which data is needed or not by the decoder), we
can discard them after decoding if they are too late anyway.
Any following basetransform based element or similar would drop the frame too.
When asked to just decode keyframe, if we got a keyframe drain out
the decoder straight away.
This avoids having to wait for the next frame and reduces delay even
more.
https://bugzilla.gnome.org/show_bug.cgi?id=767232
This ensures the decoder is properly drained out when receiving a
DISCONT buffer. The optimal way of doing this would have been to
receive a GAP event before hand but it is not always possible.
Fixes big delays with some decoders (ex gst-libav) that will not
drain out data when only decoding keyframes.
https://bugzilla.gnome.org/show_bug.cgi?id=767232
gst_buffer_copy_region() does not copy the timestamp if it doesn't start
with the first byte. We just skip the tag here, so the timestamp is still
valid.
https://bugzilla.gnome.org/show_bug.cgi?id=767173
The base class was setting the DISCONT flag before checking whether the buffer
would be in segment or not.
Fix issues with DISCONT flags not being properly propagated downstream when
decoders buffers were out of segment.
https://bugzilla.gnome.org/show_bug.cgi?id=766800
_get_gl_context() can be called concurrently from either propose_allocation() or
decide_allocation(). If it so happens that this happens at the same time,
the check for whether we already had a GL context was outside the lock. Inside
the lock and loop, the first thing that happens is that we unref the current GL
context (if valid) as if there was a conflict adding it to the display. If the
timing was unlucky, subsequent use of the GL context would be referencing an
already unreffed GL context object resulting in a critical:
g_object_ref: assertion 'object->ref_count > 0' failed
https://bugzilla.gnome.org/show_bug.cgi?id=766703
If the input buffer is after the end of the output buffer, then waiting
for more data won't help. We will never get an input buffer for this point.
This fixes compositing of streams from rtspsrc.
https://bugzilla.gnome.org/show_bug.cgi?id=766422
