Today when using the `splitmuxsrc` on a collection of files named as:
```
item0.mkv
item1.mkv
item2.mkv
[...]
item10.mkv
item11.mkv
[...]
```
You will get a continuous stream made in the order of:
```
item0.mkv -> item1.mkv -> item10.mkv -> item11.mkv -> [...]
```
You can fix this by having smarter names of the items:
```
item000.mkv
item001.mkv
item002.mkv
[...]
item010.mkv
item011.mkv
[...]
```
Will get you:
```
item000.mkv -> item001.mkv -> item003.mkv -> item004.mkv -> [...]
```
But, we could also "fix" the former case by using natural ordering when
comparing the files in gstsplitutils.c.
Fixes#2523
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4491>
boiler.md:
Update meson command to avoid warning.
states.md:
Clarify that a sink element accepting only one buffer only happens when paused.
Link text duplicated normal text.
args.md:
A valid range is between values, not between ranges. Reword for clarity.
testapp.md:
Clarify linking refers to the pipeline, not build time compilation and linking.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5939>
We access fields that are protected by the lock and this was already
held in other places where we call the method. I have got cases where
we get the following stack/assertion:
```
#0 g_logv (log_domain=0x7fb9d84e6cd5 "GStreamer", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fb9d4de54e0) at ../glib/gmessages.c:1433
#1 0x00007fb9d802d0f3 in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at ../glib/gmessages.c:1471
#2 0x00007fb9d845bc2c in gst_pad_send_event (pad=0x7fb98c01e050, event=0x7fb9c4105b90) at ../subprojects/gstreamer/gst/gstpad.c:6096
#3 0x00007fb9d6541c35 in gst_uri_decode_bin3_set_uri (dec=0x7fb9bc450960 [GstURIDecodeBin3], uri=0x7fb9c40f5410 "file:///var/home/thiblahute/devel/gstreamer/gstreamer/subprojects/gst-integration-testsuites/medias/defaults/mp4/mp3_h264.0.mp4") at ../subprojects/gst-plugins-base/gst/playback/gsturidecodebin3.c:1918
#4 0x00007fb9d6540c40 in gst_uri_decode_bin3_set_property (object=0x7fb9bc450960 [GstURIDecodeBin3], prop_id=1, value=0x7fb9d4de57b0, pspec=0x7fb9bcee5280 [GParamString]) at ../subprojects/gst-plugins-base/gst/playback/gsturidecodebin3.c:1569
#5 0x00007fb9d7f8f73d in object_set_property (object=0x7fb9bc450960 [GstURIDecodeBin3], pspec=0x7fb9bcee5280 [GParamString], value=0x7fb9d4de57b0, nqueue=0x7fb9c40d0c40, user_specified=<optimized out>) at ../gobject/gobject.c:1794
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5968>
This protocol does what it says on the box, avoiding the need for a 1x1
wl_shm buffer.
A wayland-projects wrap has been added for users who do not have v1.26
available.
This commit was partly authored by Robert Mader.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2662>
If GST_PAD_SINK is passed in this means that we're supposed to convert
from sink caps to src caps, not the other way around. In other words, if
GST_PAD_SINK is passed we're supposed to produce the possible output
caps.
Previously this was inverted. This had the effect that glcolorconvert
pretended to be able to convert *to* I420 without glDrawBuffers, which is
not possible, and pretended not to be able to convert *from* I420
without glDrawBuffers, which it always supports.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5941>
Explicitly calls gst_vtenc_pause_output_loop when going PAUSED->READY to make sure GST_PAD_STREAM_LOCK is not taken.
Before this change, a deadlock would occur if pipeline got stopped right after one output buffer was generated by vtenc.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5933>
Instead of passing along the system frame number, we pass along a reference to
the GstVideoCodecFrame.
In order for all internal cleanup to happen properly, this also requires
switching to the proper AVPacket creation/destruction methods (av_packet_alloc()
and av_packet_unref())
Fixes#2568
Co-authored-by: Edward Hervey <edward@centricular.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5186>
Until now when doing `+test-clip blue +effect effect1 + effect effect2`
leaded to the following pseudo pipeline
videotestsrc ! effect2 ! effect1
given the `ges-launch` syntax this is quite unexpected and this needed
fixing
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5735>
This allows user to be in control of when scaling happens in the pipeline.
It can be plugged as an effect and scaling will be forced to happen in
the effect instead of in the compositor.
Without this, it would not be possible for users to, for example,
crop a video source before scaling to the target source size.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5735>
Modify the fix_output_format in vpp to directly generate caps with
negotiated src caps, and we have the correct dma caps negotiation in
fix_output_format function. And thus, we can remove the redundant
negotiation of using function pad_accept_memory in vpp.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5845>
