The base class is trying to align the processed data, but it endup
removing the GstVideoMeta. That caused wrong result. Instead, just copy
from the process function with the appropriate alignment.
https://bugzilla.gnome.org/show_bug.cgi?id=781204
And only set low-percent/high-percent if not using downloadbuffer, just
like in old uridecodebin. using the watermark based buffering causes
playback to hang never finish buffering with downloadbuffer.
With both audiorate and videorate, it seems more sensible to apply rate
adjustments after the first buffer appears. For example, with v4l2src,
there is often a small delay before the first video buffer turns up, and
this can cause a stuttery start because of videorate trying to ensure a
perfect stream.
Those multiqueue are the ones dealing with adaptive demuxers. They should
have a time limit set so that they don't end up buffering too much data.
They would previously be set with no limits at all, which would cause them
to grow indefinitely until downstream blocks.
gst_video_rate_flush_prev() ensures that the pushed buffer is writable
by calling gst_buffer_make_writable() on videorate->prevbuf.
In drop-only mode we always push buffers directly when they are received
from GstBaseTransform (gst_video_rate_transform_ip()) and do not keep them
around. GstBaseTransform already ensures that those buffers are
writable so there is no need to do it twice.
This change saves us from copying buffers in drop-only mode as we no longer
calls gst_buffer_make_writable() with a buffer having a refcount of 2
(one ref owned by GstBaseTransform and one in videorate->prevbuf).
https://bugzilla.gnome.org/show_bug.cgi?id=780767
Instead go backwards before segment.stop based on the framerate or the
next buffers end timestamp. Otherwise the first buffer will usually be
dropped because outside the segment.
https://bugzilla.gnome.org/show_bug.cgi?id=781899
HLS files can have arbitrary extra tags in them, and
those can be quite long lines. We need to search
further than 256 bytes sometimes just to get past the
first few lines of the file. Make the limit 4KB,
which matches a typical input block size and should
hopefully cover every crazy input.
https://bugzilla.gnome.org/show_bug.cgi?id=780559
The term stride is confusing here, since the stride is always use
to signal the pixel row size of an image (including padding). Also
a frame may have a single stride, which adds to the confusion. This
patch uses frame-size, which simply indicate the frame size in the
case the images have some padding in between.
https://bugzilla.gnome.org/show_bug.cgi?id=780053
This allow using those property through gst-launch-1.0. This type
gained a deserilizer recently. The syntax is: <val1, val2, ...>.
Note that we also use the type int instead of uint to avoid having
to cast when specifying the values. The deserilizers assume
int by default.
https://bugzilla.gnome.org/show_bug.cgi?id=780053
When a clip has video audio and subtitle, if need send gap event
to audio and subtitle, we should make sure all has been sent, so
need every stream keep one send_gap_event.
https://bugzilla.gnome.org/show_bug.cgi?id=780429
When posting 100% buffering due to removing the last
buffering element, we still need to hold the posting
lock as well, to avoid any race with other elements
that might post a buffering message at that exact
moment
Add locking, and handle EOS properly now that urisourcebin
uses custom events in place of real EOS events, so we
need to manually remove buffering messages and potentially
post 100% in that situation
The expanded 4 second buffering was making radio streams that are
being delivered at real-time speeds too slow. We might need
a better plan for matching the queue2 size to incoming bitrate
in the absence of tag information or timestamping.
In uridecodebin, it used tags on the output of decodebin to
adjust the queue2 buffering, but urisourcebin doesn't have that
view - decodebin is downstream from us.
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
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.
