Just like for the seconds field, there are no limitations on the hours and
minutes fields. The specification for xml schema duration fields doesn't forbid
specifying durations with only (huge) minutes or hours values.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2951>
When updating a manifest during live playback, preserve the current
representation for each stream.
During update_fragment_info, if the current representation changed
because it couldn't be matched, trigger a caps change and new
header download.
This reverts commit e0e1db212f
and reapplies "dashdemux: Fix issue when manifest update sets slow start
without passing necessary header & caps changes downstream" with
changes.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2920>
Timers for RTX packets are dealt with later in update_rtx_timers(), and
timers for non-RTX packets would potentially also be unscheduled a
second time from there so avoid that.
Also don't shadow the timer variable from the outer scope but instead
make use of it directly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2973>
libsoup 3.0.x dispatches using a single source attached when the session
is created, so we need to create the session with the same context that
our download thread is later using.
2.74 or 3.1 will dispatch a response using the context which sent the
request. However, for any context other than the one that created the
session, this will also create and destroy sources, so there's still
some slight performance benefit.
Fixes: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1384
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2913>
Handle select-streams and seek events in an element
level send_event() vfunc, so they can be received
before any source pads are created.
This allows preferred streams to be selected before
segment downloading starts.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2912>
When stopping the element, make sure the pad task
is stopped before destroying the part readers.
Closes a race where the pad task might access
a freed pointer.
Also add a guard against this sort of thing
by holding a ref to the reader in the pad loop.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2901>
When playing live, it's possible that one stream reaches
the end of the available playback window and goes to sleep
waiting for a manifest update, and the manifest update
introduces a new period. In that case, the sleeping
stream needs to wake up and go 'properly' EOS before we
can advance the input to the new period.
Accordingly, make sure that a stream's last_ret value
is not marked as EOS if it's just sleeping waiting for a live
manifest update.
Also fix the output loop to go back and re-check if it's
time to switch to the next period after dequeuing and
discarding an EOS event.
https://livesim.dashif.org/livesim/periods_20/testpic_2s/Manifest.mpd
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2895>
That is, get rid of unnecessary and wrong special-casing.
This could always use gst_rtsp_url_get_request_uri_with_control() but as
we only have the control base URI as string it is easier to just call
gst_uri_join_strings().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2868>
Otherwise we won't send the protection packets for the last few
packets when a stream ends.
Also send EOS on the FEC src row pad immediately, and on the FEC src
column pad after draining is complete. This makes it so that the FEC
src pads on rtpbin behave the same way as the RTCP src pads on rtpbin
when EOS is received on the send_rtp_sink pad.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2863>
When returning GST_ADAPTIVE_DEMUX_FLOW_RESTART_FRAGMENT
for the first segment data, we might need to requeue the
header.
This was leading to occasional prerolling stalls on
HLS live streams with renditions.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2849>
Make sure gst_adaptive_demux_loop_cancel_call()
never tries to operate on an invalidated main context. Make
sure to clear the main context pointer while holding the lock,
and to check it in gst_adaptive_demux_loop_cancel_call()
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2847>
Media playlist updates and fragment downloads happen in an interleaved
fashion. When a media playlist update fails *while* a segment is being
downloaded, this means we lost synchronization.
Properly propagate and handle this
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2839>
There is now only a single case where we setup the initial playlist to 0, which
is for the very first variant stream.
Rendition streams will have the initial playlist "synchronized" against the
variant stream media playlist.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2839>
Loss of synchronization happens when the updated media playlist has no
relationship to the previous ones. This could happen because of network issues,
server issues, etc...
When this happens, we take no chance and "reset" ourselves so that we can "seek
back to live" against the new updated playlists.
Since this happens at the "media playlist update" level, make sure the custom
flow return is propagated up.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2839>
We are already in the main scheduler thread, therefore we can do the "seek back
to live" directly. This also avoids other pending actions to take place.
Also handle the loss of sync when doing manifest updates.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2839>
Close some race conditions in switching to the next period,
by ensuring the tracks are completely drained first and by
not outputting EOS events to the output source pad
if there is another period pending.
Fixes Manifest_MultiPeriod_1080p.mpd some more.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2838>
Before sending EOS, update the period's has_next_period
flag and/or create the next period. This closes a race
where the output loop might receive the EOS event
and either push it downstream (causing premature EOS),
or receive it and try and switch to the next period
before that period is completely set up.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2838>
When combining stream flows, ignore streams that
are not selected, instead of checking whether
the stream state has changed yet.
Fixes another issue with dashdemux2 where it fails to
change to the next period when playing content with
several video, audio and text streams, as with
Manifest_MultiPeriod_1080p.mpd when seeking to 730
just before the end of the first period.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2838>
With the 2.72 release, glib-networking developers have decided that
TLS certificate validation cannot be implemented correctly by them, so
they've deprecated it.
In a nutshell: a cert can have several validation errors, but there
are no guarantees that the TLS backend will return all those errors,
and things are made even more complicated by the fact that the list of
errors might refer to certs that are added for backwards-compat and
won't actually be used by the TLS library.
Our best option is to ignore the deprecation and pass the warning onto
users so they can make an appropriate security decision regarding
this.
We can't deprecate the tls-validation-flags property because it is
very useful when connecting to RTSP cameras that will never get
updates to fix certificate errors.
Relevant upstream merge requests / issues:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2214https://gitlab.gnome.org/GNOME/glib-networking/-/issues/179https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/193
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2494>
The caps negotiation should respect the selected method to the test pipeline below works properly.
gst-launch-1.0 videotestsrc ! video/x-raw,width=320,height=600 ! videoflip method=clockwise ! video/x-raw,width=600,height=320 ! fakesink
Signed-off-by: Adrian Fiergolski <adrian.fiergolski@fastree3d.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2803>
In the trick mode, driver may queue a valid buffer follow by an
empty buffer which has no valid data to indicate EOS.For the empty
buffer whose memory is multi-plane, need to resize it before
unreference it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2731>
In file included from ../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/gstreamer-1.0/gst/gl/gstglfuncs.h:87,
from ../gst-plugins-good-1.20.3/ext/qt/qtglrenderer.cc:14:
../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/gstreamer-1.0/gst/gl/glprototypes/gstgl_compat.h:40:18: error: conflicting declaration 'typedef void* GLsync'
40 | typedef gpointer GLsync;
| ^~~~~~
In file included from ../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/QtGui/qopengl.h:127,
from ../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/QtQuick/qsggeometry.h:44,
from ../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/QtQuick/qsgnode.h:43,
from ../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/QtQuick/qsgrendererinterface.h:43,
from ../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/QtQuick/qquickwindow.h:44,
from ../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/QtQuick/QQuickWindow:1,
from ../gst-plugins-good-1.20.3/ext/qt/qtglrenderer.cc:6:
../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/QtGui/qopengles2ext.h:24:26: note: previous declaration as 'typedef struct __GLsync* GLsync'
24 | typedef struct __GLsync *GLsync;
| ^~~~~~
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2763>
* When dealing with rendition streams, we attempt to synchronize the media
playlist against the variant stream. This helps with speeding up the correct
initial fragment search and avoids issues when streams at activated at a much
later time.
* Also add checks for variant stream existence before attempting to use them
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2679>
When updating playlists, there is a possibility that the playlists don't
perfectly align, but the last entry of the previous playlist is *just* before
the first entry of the new playlist.
In those cases, we still can transfer the timing information from one playlist
to another, but we do not want to return that segment as being the matching one.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2679>
When matching playlists, there is a possibility that rendition streams will not
have been updated in time (for example because that stream started later, or
playback was paused). This would cause several playback failures and seeking
failures.
In order to still fall back on our feet, attempt to synchronize that rendition
playlist against the current variant playlist. This will attempt to match the
stream time using SN/DNS/PDT/...
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2679>
If we have been updating too slowly and have gone out of the current live
window, inform the baseclass accordingly.
This is different from the case where we have been updating quicker than what
the server provides.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2679>
* Since only flushing seeks are allowed, the "current" position is always the
global output position (and not "some" stream current position).
* In terms of figuring out to which stream to "snap" to, we can send it to any
selected stream. Removes the requirement of this function to a specific output
pad.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2679>
Remove the "pending advance" hack and instead rely on the base stream current
position to track our position (instead of a potentially NULL "current
segment").
Also ensure the media playlists are always refreshed with valid stream time,
even if there is no current segment.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2679>
The stream start and current position would be properly set when seeking or
activating a stream after playback started. But it would never be properly
initialized.
Set it to NONE initially to indicate to subclasses that no position has been
tracked yet. This will allow them to detect initial stream usage.
Futhermore, once the initial streams setup is done, make sure that it is set to
a valid initial value:
* The minimum stream time in live
* Or else the period start
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2679>
If the driver does not support VIDIOC_CREATE_BUFS ioctl, the pool
configuration may get changed, which requires a validation. This would
fail to activate a pool in a case it shouldn't normally fail unless we
are out of memory.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2456>
Some mpeg-ts streams have extra data at the beginning. While it's not ideal, we
should be able to cope with it.
Therefore increase the initial search window for at least 4 consecutive
synchronization points to 1kB.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2626>
Various variables were of smaller types than needed and there were no
checks for any overflows when doing additions on the sizes. This is all
checked now.
In addition the size of the decompressed data is limited to 200MB now as
any larger sizes are likely pathological and we can avoid out of memory
situations in many cases like this.
Also fix a bug where the available output size on the next iteration in
the zlib decompression code was provided too large and could
potentially lead to out of bound writes.
Thanks to Adam Doupe for analyzing and reporting the issue.
CVE: tbd
https://gstreamer.freedesktop.org/security/sa-2022-0003.html
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1225
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2610>
Various variables were of smaller types than needed and there were no
checks for any overflows when doing additions on the sizes. This is all
checked now.
In addition the size of the decompressed data is limited to 120MB now as
any larger sizes are likely pathological and we can avoid out of memory
situations in many cases like this.
Also fix a bug where the available output size on the next iteration in
the zlib/bz2 decompression code was provided too large and could
potentially lead to out of bound writes.
Thanks to Adam Doupe for analyzing and reporting the issue.
CVE: CVE-2022-1922, CVE-2022-1923, CVE-2022-1924, CVE-2022-1925
https://gstreamer.freedesktop.org/security/sa-2022-0002.html
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1225
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2610>
Uses prelude header files with #defines to rename DASH and MSS
symbols duplicated in their old standalone versions.
Also redefines soup-related functions when building it for
adaptivedemux2 to prevent symbol conflicts there.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2534>
macOS features hidden devices. These are devices that will
not be shown in the macOS UIs and that cannot be retrieved
without having the specific UID of the hidden device. There
are cases when you might want to have a hidden device, for example
when having a virtual speaker that forwards the data to a virtual
hidden input device from which you can then grab the audio.
The blackhole project supports these hidden devices and
this patch provides a way that if the device id is a hidden
device it will use it instead of check the hardware list of devices
to understand if the device is valid.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2251>
gtk_gl_area_get_error() doesn't return a copy of the error, but just the
error. If initialising OpenGL fails, then GtkGstGLWidget will consume
the error, and cause GTK to try and display freed memory.
==50914== Invalid read of size 8
==50914== at 0x4C4CB8A: gtk_gl_area_draw_error_screen (gtkglarea.c:663)
==50914== by 0x4C4CB8A: gtk_gl_area_draw (gtkglarea.c:687)
==50914== by 0x4E061CA: gtk_widget_draw_internal (gtkwidget.c:7084)
==50914== by 0x4BAEFB1: gtk_container_propagate_draw (gtkcontainer.c:3854)
==50914== by 0x4D4B6BF: gtk_stack_render (gtkstack.c:2207)
==50914== by 0x4BB4B03: gtk_css_custom_gadget_draw (gtkcsscustomgadget.c:159)
==50914== by 0x4BBA4C4: gtk_css_gadget_draw (gtkcssgadget.c:885)
==50914== by 0x4D4D780: gtk_stack_draw (gtkstack.c:2119)
==50914== by 0x4E061CA: gtk_widget_draw_internal (gtkwidget.c:7084)
==50914== by 0x4BAEFB1: gtk_container_propagate_draw (gtkcontainer.c:3854)
==50914== by 0x4BAF0C3: gtk_container_draw (gtkcontainer.c:3674)
==50914== by 0x4E061CA: gtk_widget_draw_internal (gtkwidget.c:7084)
==50914== by 0x4BAEFB1: gtk_container_propagate_draw (gtkcontainer.c:3854)
==50914== Address 0x187a0818 is 8 bytes inside a block of size 16 free'd
==50914== at 0x48480E4: free (vg_replace_malloc.c:872)
==50914== by 0x49A5B8C: g_free (gmem.c:218)
==50914== by 0x49C1013: g_slice_free1 (gslice.c:1183)
==50914== by 0x4990DE4: g_error_free (gerror.c:870)
==50914== by 0x4990FE9: g_clear_error (gerror.c:1052)
==50914== by 0x1A489780: _get_gl_context (gtkgstglwidget.c:540)
==50914== by 0x1A4863CB: gst_gtk_invoke_func (gstgtkutils.c:39)
==50914== by 0x49A3834: g_main_context_invoke_full (gmain.c:6137)
==50914== by 0x1A486450: gst_gtk_invoke_on_main (gstgtkutils.c:59)
==50914== by 0x1A48A29E: gtk_gst_gl_widget_init_winsys (gtkgstglwidget.c:632)
==50914== by 0x1A4887E7: gst_gtk_gl_sink_start (gstgtkglsink.c:267)
==50914== by 0x6579810: gst_base_sink_change_state (gstbasesink.c:5662)
==50914== Block was alloc'd at
==50914== at 0x484586F: malloc (vg_replace_malloc.c:381)
==50914== by 0x49A9278: g_malloc (gmem.c:125)
==50914== by 0x49C1BA5: g_slice_alloc (gslice.c:1072)
==50914== by 0x49C3BCC: g_slice_alloc0 (gslice.c:1098)
==50914== by 0x499096B: g_error_allocate (gerror.c:708)
==50914== by 0x4990AF1: UnknownInlinedFun (gerror.c:722)
==50914== by 0x4990AF1: g_error_copy (gerror.c:892)
==50914== by 0x4C4B9F9: gtk_gl_area_set_error (gtkglarea.c:1036)
==50914== by 0x4C4BAF7: gtk_gl_area_real_create_context (gtkglarea.c:346)
==50914== by 0x4B21B28: _gtk_marshal_OBJECT__VOIDv (gtkmarshalers.c:2730)
==50914== by 0x4920B78: UnknownInlinedFun (gclosure.c:893)
==50914== by 0x4920B78: g_signal_emit_valist (gsignal.c:3406)
==50914== by 0x4920CB2: g_signal_emit (gsignal.c:3553)
==50914== by 0x4C4B927: gtk_gl_area_realize (gtkglarea.c:308)
Reproduced by running:
MESA_GL_VERSION_OVERRIDE=2.7 totem
See https://gitlab.gnome.org/GNOME/totem/-/issues/522
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2565>
If our downstream caps didn't intersect, we attempted to convert between
raw and ADTS stream formats, if possible. If the caps still did not
intersect, we then used the modified `src_caps` but left the
`output_header_type` unmodified.
This caused a mismatch between caps and actual stream format.
Avoid this by first copying the `src_caps` to `convcaps` for the
additional intersection tests, replacing `src_caps` if we succeed.
While we're here, clean up the code a bit and remove the `codec_data`
field from outgoing ADTS caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2550>
In case of per features registration such as the
customizable gstreamer-full library, each
element should check that the soup library can be loaded to
facilitate the element registration.
Initialize the debug categories properly
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2348>
https://bugzilla.gnome.org/show_bug.cgi?id=741398 changed
rtpptdemux in 2014 to not post a GST_ELEMENT_ERROR on the
bus when dropping an invalid (non-RTP) packet, but still
returned GST_FLOW_ERROR upstream - so the pipeline still
stops, but now without a useful bus error.
Return GST_FLOW_OK instead, so the pipeline keeps
running. Some old telephony equipment can send invalid
packets before the real RTP traffic starts.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2520>
get_colorspace() checks input caps transfer when mapping V4L2_XFER_FUNC_709
back to V4L2_COLORSPACE_BT2020 and GST_VIDEO_TRANSFER_BT2020_12. After
receiving source change event, decoder will G_FMT and S_FMT again. So need
to reset transfer when acquiring format to avoid using the old transfer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2475>
In case of per features registration such as the
customizable gstreamer-full library, each
element should check that the soup library can be loaded to
facilitate the element registration.
Initialize the debug category properly
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2349>
zlib is required, and if it isn't found it is checked several ways and
then forced via subproject(). This code was added in commit
b93e37592a, to account for systems where
zlib doesn't have pkg-config files installed.
But Meson already does dependency fallback, and also, since 0.54.0, does
the in-between checks for find_library('z') and has_header('zlib.h') via
the "system" type dependency. Simplify dependency lookup by marking it
as required, which also makes sure that the console log doesn't
confusingly list "not found".
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2484>
The pool process function may poll and get the resolution-change event
whenever it is not possible to share our buffers. This typically happen
when downstream does not support GstVideoMeta.
Not handling this would cause the decoder thread to exit silently and the
pipeline to stall.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2457>
Output may attemp to set the width and height to zero values if
caps has no such information, which will cause capture get invalid
dimensions. Then decoder reports negotiation failure.
So need to set default resolution if caps has no such information.
Real values can be set again until source change event is signaled.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2400>
When processing the first event after probing the
file and being activated, requeue sticky events
as there's no requirement that demuxers send tag
and other events again after a seek - that's
why they're sticky.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2432>
- Consistently unref the chained buffer at the end of the chain
function, if we're not handing it off to `gst_pad_push`. This avoids a
few buffer leaks in the error paths in `_chain` and `_push_history`.
- When mapping the video frame fails, return a flow error instead of
crashing.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2428>
If we just break the loop, we might run into the `gop != NULL` assert
that follows it. Rather, exit immediately with flushing flow.
Also use this flushing mechanism when we release a pad. This avoids
having an extra flag.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1030>
The timestamp in the tfdt refers to the first trun box and if there are
multiple trun boxes then the distance between the first timestamps will
grow.
At some point this distance reaches a threshold and triggers the
resetting of the first sample's timestamp of this trun box to be reset
to the tfdt.
This threshold is implemented for files where there is a jump in the
timeline between fragments and where this can be detected via a jump
between the end timestamp of the previous fragment and the tfdt of the
next. This behaviour is preserved.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2409>
If for some reason the encoder produces frames with a pts higher than
the input one, we were dropping all the video encoder frames and ended
up crashing when trying to access the pts of a NULL pointer returned by
gst_video_encoder_get_oldest_frame().
I hit this scenario by feeding a decreasing timestamp to vp8enc which
seem to confuse the encoder.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2405>
Hantro H1 and Rockchip VEPU2 drivers will pad the width/height to a
multiple of 16. In order to obtain the right JPEG size, the image needs
to be cropped using the S_SELECTION API. This support is added as best
effort since older drivers may emulate this by looking at the capture
queue width/height.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2329>
mp4mux can't negotiate caps with upstream/downstream and always outputs
specific caps based on the input streams. This will always happen before
it produces the first buffers.
By having the default aggregator negotiation enabled the same caps
would be pushed twice in the beginning, and again every time a
reconfigure event is received.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2372>
flvmux can't negotiate caps with upstream/downstream and always outputs
specific caps based on the input streams. This will always happen before
it produces the first buffers.
By having the default aggregator negotiation enabled the same caps
would be pushed twice in the beginning, and again every time a
reconfigure event is received.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2372>
