GitLab

CID 1364606

CID 1363331

CID 1363330

CID 1363327

CID 1362896

if the vorbis encoder receives new headers it must be
reset and re-initialized to continue decoding, e. g.
for live streams

The headers are usually changing together with the caps, and they are
nedeed for correct decoding.

Broke build in gnome continuous

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

This way they can be distinguished from any other threads in the same
process.

There's no reason to lock anything if only the current thread is ever
going to do any work.

This adds a property to select the maximum number of threads to use for
conversion and scaling. During processing, each plane is split into
an equal number of consecutive lines that are then processed by each
thread.

During tests, this gave up to 1.8x speedup with 2 threads and up to 3.2x
speedup with 4 threads when converting e.g. 1080p to 4k in v210.

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

In gst_video_time_code_is_valid, also check for invalid
ranges when using drop-frame TC. Refactor some code which
broke after the check was added.

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

Add a function to init the time code from a GDateTime

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

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

This would ideally be solved in baseparse but that requires further
thought at this point, and in the meantime it would be good to have
rawbaseparse not assert on this but handle it gracefully instead.

It was taking the initial input y-offset from the output value, which
only works for y=0 (in which case both are the same). If y > 0, we would
always stay behind the requested input offset and never ever read
anything from the input.

Buildbot doesn't like wildcards here for some reason.

Ship meson build files in tarballs, so people who use tarballs
in their builds can start playing with meson already.

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

Previously it happened that reused buffer caused the discont to be on the wrong
buffers.

The parser might do some conversion on a stream but the stream keeps
being the same, and we need to make sure GstDiscoverer detects it is the
case.

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

Oops, also add FLAC to the debug strings array.

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

Add new audio types to the list of strings used for debug
so we don't index past the end of that array.

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

Probe for MultiQueue source pad might receive EOS twice,
the first is fake-eos and the other is actual EOS.
And the slot can be freed with fake-eos/EOS if the slot has no input.

Since slot freeing is async, double free can be possible.
So, decodebin3 needs to remove the probe also with slot freeing.

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

Free no more used list variables

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

"requested_selection" list might be generated by select-streams event.
And memory of stream-id(s) in select-streams is independent from that of stream-collection.

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

Change return types of functions to get memory address of stream-id.

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

Since gst_event_parse_select_streams() returns newly allocated
memory for stream-id(s), it should be freed explicitly.

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

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

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