It might cause invalid calculations during the CONVERT query otherwise.

It might cause invalid calculations during the CONVERT query otherwise.

No need to duplicate this non-trivial function.

https://bugzilla.gnome.org/show_bug.cgi?id=766970

And especially don't use the stream lock for that, as otherwise non-serialized
queries (CONVERT) will cause the stream lock to be taken and easily causes the
application to deadlock.

https://bugzilla.gnome.org/show_bug.cgi?id=768361

videoencoder/decoder: Move conversion utility functions to a common header and use consistently in encoder/decoder

... instead of the time when it was pushed further downstream.

https://bugzilla.gnome.org/show_bug.cgi?id=763630

This will become an error in 1.10.

https://bugzilla.gnome.org/show_bug.cgi?id=765796

By default we'll wait for a certain amount of data before
attempting typefinding. However, if the stream is fairly
short, we might get EOS before we ever attempted any
typefinding, so at this point we should force typefinding
and output any pending data if we manage to detect the
type.

https://bugzilla.gnome.org//show_bug.cgi?id=768178

In 0.10 the source pad was a dynamic pad that was only added once
the type had been detected, but in 1.x it's an always source pad,
so checking whether it's still NULL won't work to detect if the
type has been detected.

Makes tagdemux error out when we get EOS but haven't managed to
identify the format of the data after the tag.

https://bugzilla.gnome.org//show_bug.cgi?id=768178

This was committed by mistake. The solution forward is to use the
appropriate combination of urisourcebin and decodebin3

With contributions from Jan Schmidt <jan@centricular.com>

* decodebin3 and playbin3 have the same purpose as the decodebin and
playbin elements, except make usage of more 1.x features and the new
GstStream API. This allows them to be more memory/cpu efficient.

* parsebin is a new element that demuxers/depayloads/parses an incoming
stream and exposes elementary streams. It is used by decodebin3.
It also automatically creates GstStream and GstStreamCollection for
elements that don't natively create them and sends the corresponding
events and messages

* Any application using playbin can use playbin3 by setting the env
variable USE_PLAYBIN3=1 without reconfiguration/recompilation.

It's 0 and no mask should be set for mono at all.

https://bugzilla.gnome.org/show_bug.cgi?id=757472

Otherwise we would end up with a deadlock as the audio-sink emits step-done
from its streaming thread.

It does not make much sense for audio sinks.

https://bugzilla.gnome.org/show_bug.cgi?id=767463

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

https://bugzilla.gnome.org/show_bug.cgi?id=767859

From ac2f647 to f363b32

If buffer duration is missing, it is parsed from the packet data.
This is not foolproof, since Opus can change durations on the
fly.

https://bugzilla.gnome.org/show_bug.cgi?id=767826

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

They will be incomplete otherwise and we can't generate the full serialized
information, and instead will crash somewhere on the way.

https://bugzilla.gnome.org/show_bug.cgi?id=767859

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

Use bpf instead of channels * sizeof(gint16).

https://bugzilla.gnome.org/show_bug.cgi?id=767505

https://bugzilla.gnome.org/show_bug.cgi?id=767506

We have to use bps*channels instead of just bps, which is exactly what bpf is for.

https://bugzilla.gnome.org/show_bug.cgi?id=767507

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.

videodecoder: Use input segment rate instead of output segment rate to decide whether the drain on keyframes

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.