GitLab

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

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

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

And do it always, not inside a g_return_val_if_fail().

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

Before we would hit an assertion "'gst_buffer_pool_is_active (bpool)' failed"
if the internal pool was not used to push buffer downstrea, hence not
given to the baseclass.

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

We only want to unlock if we push an event downstream and
jump to done_unlock label afterwards. We would also unlock
in case of a segment seek and then unlock again later, and
nothing good can come of that.

(This code looks a bit dodgy anyway though, shouldn't it
also bail out with FLOW_EOS here in case of a segment seek
scenario, just without the event?)

Previously this was printed as characters which caused later processing
of the error message to sometimes warn about non-UTF-8 characters.

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

If special stride is needed and downstream don't support VideoMeta,
pool might be NULL in order to let the baseclass create a generic
pool­. This would lead to assertion with on Exynos with:

gst-launch-1.0 -v filesrc location=mov ! qtdemux ! h264parse ! \
                    v4l2video8dec ! fakesink

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

This will ensure we fail earlier if something unrecoverable
happens.

In kernel before 3.17, polling during queue underrun would unblock right
away and trigger POLLERR. As we are not handling POLLERR, we would endup
blocking in DQBUF call, which won't be unblocked correctly when going
to NULL state. A deadlock at start caused by locking error in libv4l2 was
also seen before this patch. Instead, we wait until the queue is no longer
empty before polling.

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

The code enumerating STEPWISE framesizes would start from
(min_w, min_h) and then add (step_w, step_h) to get the
next framesize. However, it should really allow any width
from min_w to max_w with step_w and same for heights.
Secondly, we would add and probe each individual stepped
frame size to the caps as separate structure, which would
lead to hundreds if not thousands of structs ending up in
the probed caps. Use integer ranges with steps instead.

This was particularly noticable with the Raspberry Pi Cam.

https://bugzilla.gnome.org/show_bug.cgi?id=724521
https://bugzilla.gnome.org/show_bug.cgi?id=732458
https://bugzilla.gnome.org/show_bug.cgi?id=726521

This workaround from 2011 was causing 25 S_FMT ioctls to be sent
to my UVC webcam from under gst_v4l2_object_get_caps as it probes
all the formats. In total, this adds up to about 5 seconds of
execution time, or a 10 second delay while starting up cheese.

These ioctls come from a workaround from 2011 where TRY_FMT might
make changes to hardware settings, so S_FMT was used to restore
the original config:
https://bugzilla.gnome.org/show_bug.cgi?id=649067

The driver bug is now assumed fixed. Remove the workaround to fix the
long startup delay.

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

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

This fixes missing frames from being time skipped.

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

Compiler complains about uninitialised variables in the impossible
'default' code path in device provider source/sink switch-case.

Compiler complains about uninitialised variables in the impossible
'default' code path in device provider source/sink switch-case.

Actually look for error messages on the bus and fail if there
is one before the EOS message. Disable pull mode test which is
pointless as long as matroskaparse only supports push mode
(pull mode support has not been ported over to 1.0).

gst_matroska_parse_take() would return FLOW_ERROR instead of
FLOW_EOS in case there's less data in the adapter than requested,
because buffer is NULL in that case which triggers the error
code path. This made the unit test fail (occasionally at least,
because of a bug in the unit test there's a race and it would
happen only sporadically).

And also rename the remaining symbols to prevent conflicts
during static linking.

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

fakesrc doesn't announce video caps, so most video pipelines will
just error out with not-negotiated if a fallback element is created.

fakesrc doesn't announce audio caps, so most audio pipelines will
just error out with not-negotiated if a fallback element is created.

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

Decoder complains about "notification: Invalid mode encountered.
The stream is corrupted" though, even if it works, so there's
probably something wrong with the generated codec headers.

Speex in FLV is always mono @ 16kHz, see
http://download.macromedia.com/f4v/video_file_format_spec_v10_1.pdf
section E.4.2.1: "If the SoundFormat indicates Speex, the audio is
compressed mono sampled at 16 kHz, the SoundRate shall be 0, the
SoundSize shall be 1, and the SoundType shall be 0"

Also see https://bugzilla.gnome.org/show_bug.cgi?id=683622

Enables playback for files with DTS audio tracks.
Also add an extra AC-3 variant fourcc from Nero

Change function pointers to NULL while holding the lock to avoid
race conditions

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

Implement 3 different cases for handling the SR:

 1) we don't have enough timing information to handle the SR packet and
    we need to wait a little for more RTP packets. In that case we keep
    the SR packet around and retry when we get an RTP packet in the
    chain function.

 2) the SR packet has a too old timestamp and should be discarded. It is
    labeled invalid and the last_sr is cleared.

 3) the SR packet is ok and there is enough timing information, proceed
    with processing the SR packet.

Before this patch, case 2) and 1) were handled in the same way,
resulting that SR packets with too old timestamps were checked over and
over again for each RTP packet.