GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-07-12T10:00:41Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1311glupload: Responds to caps queries incorrectly2022-07-12T10:00:41ZJan Schmidtglupload: Responds to caps queries incorrectlyWhen glupload responds to caps queries, it calls gst_gl_upload_transform_caps().
Before it starts, gst_gl_upload_transform_caps() will return the set of all possible caps from all possible upload methods, but if there is already a curre...When glupload responds to caps queries, it calls gst_gl_upload_transform_caps().
Before it starts, gst_gl_upload_transform_caps() will return the set of all possible caps from all possible upload methods, but if there is already a current upload method then only the transform_caps() result from that upload method is checked first. Since the raw memory uploader is the only one that adds plain `video/x-raw` to the transform_caps result, this can mean that upstream will query glupload, and be told that it accepts `video/x-raw...,video/x-raw(memory:GLMemory)...` and then later after choosing `video/x-raw` and things are running, querying `glupload`'s sink pad will claim it now only supports `video/x-raw(memory:GLMemory)` as input.
I attempted a fix in !2687, but it caused a regression and was partially reverted.
I think a correct fix would be to ensure the `gst_gl_upload_transform_caps()` function always appends the results of calling the raw memory upload transform_caps implementation.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1310glupload: EGL regression with `meta->format != info->finfo->format`2023-04-26T15:39:00ZSebastian Drögeglupload: EGL regression with `meta->format != info->finfo->format`Introduced by https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2687
Reproducible via
```console
$ GST_GL_WINDOW=egl gst-launch-1.0 videotestsrc ! video/x-raw,format=I420 ! glvideomixer ! fakesink
[...]
(gst-launch-1....Introduced by https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2687
Reproducible via
```console
$ GST_GL_WINDOW=egl gst-launch-1.0 videotestsrc ! video/x-raw,format=I420 ! glvideomixer ! fakesink
[...]
(gst-launch-1.0:1318439): GStreamer-Video-CRITICAL **: 15:55:47.580: gst_video_frame_map_id: assertion 'info->finfo->format == meta->format' failed
0:00:00.735363225 1318439 0x55e1750dfc00 ERROR glmixer gstglmixer.c:124:gst_gl_mixer_pad_prepare_frame:<mixer:sink_0> Failed to map input frame
[...]
```
GLX works fine.
CC @thaytanhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/214roundedcorners: Panics when updating radius-px property at runtime2022-06-30T17:28:56ZPhilippe Normandroundedcorners: Panics when updating radius-px property at runtime```
0:00:01.634596807 2256598 0x55b1fcd24cc0 INFO roundedcorners video/videofx/src/border/roundedcorners.rs:308:gstvideofx::border::roundedcorners:<rc> Changing border radius from 0 to 4
0:00:01.658060203 2256598 0x55b1fcf099e0 ...```
0:00:01.634596807 2256598 0x55b1fcd24cc0 INFO roundedcorners video/videofx/src/border/roundedcorners.rs:308:gstvideofx::border::roundedcorners:<rc> Changing border radius from 0 to 4
0:00:01.658060203 2256598 0x55b1fcf099e0 DEBUG roundedcorners video/videofx/src/border/roundedcorners.rs:463:gstvideofx::border::roundedcorners:<rc> Transformed caps from video/x-raw, format=(string)I420, width=(int)1280, height=(int)720, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive to video/x-raw, format=(string){ A420, I420 }, width=(int)1280, height=(int)720, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive in direction Sink
0:00:01.658260803 2256598 0x55b1fcf099e0 DEBUG roundedcorners video/videofx/src/border/roundedcorners.rs:534:gstvideofx::border::roundedcorners:<rc> Caps or border radius changed, generating alpha mask
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', video/videofx/src/border/roundedcorners.rs:118:37
stack backtrace:
0: rust_begin_unwind
at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:584:5
1: core::panicking::panic_fmt
at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/panicking.rs:143:14
2: core::panicking::panic
at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/panicking.rs:48:5
3: core::option::Option<T>::unwrap
at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/option.rs:755:21
4: gstvideofx::border::roundedcorners::RoundedCorners::generate_alpha_mask
at /var/home/phil/dev/rust/gst-plugins-rs/video/videofx/src/border/roundedcorners.rs:118:23
5: <gstvideofx::border::roundedcorners::RoundedCorners as gstreamer_base::subclass::base_transform::BaseTransformImpl>::prepare_output_buffer
at /var/home/phil/dev/rust/gst-plugins-rs/video/videofx/src/border/roundedcorners.rs:549:24
6: gstreamer_base::subclass::base_transform::base_transform_prepare_output_buffer::{{closure}}
at /var/home/phil/.cargo-home/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/c61d913/gstreamer-base/src/subclass/base_transform.rs:1197:15
7: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/panic/unwind_safe.rs:271:9
8: std::panicking::try::do_call
at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:492:40
9: std::panicking::try
at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:456:19
10: std::panic::catch_unwind
at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panic.rs:137:14
11: gstreamer_base::subclass::base_transform::base_transform_prepare_output_buffer
at /var/home/phil/.cargo-home/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/c61d913/gstreamer-base/src/subclass/base_transform.rs:1196:5
12: default_generate_output
at /var/home/phil/gstreamer/build/../subprojects/gstreamer/libs/gst/base/gstbasetransform.c:2163:9
13: <T as gstreamer_base::subclass::base_transform::BaseTransformImplExt>::parent_generate_output
at /var/home/phil/.cargo-home/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/c61d913/gstreamer-base/src/subclass/base_transform.rs:864:45
14: gstreamer_base::subclass::base_transform::BaseTransformImpl::generate_output
at /var/home/phil/.cargo-home/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/c61d913/gstreamer-base/src/subclass/base_transform.rs:190:9
15: gstreamer_base::subclass::base_transform::base_transform_generate_output::{{closure}}
at /var/home/phil/.cargo-home/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/c61d913/gstreamer-base/src/subclass/base_transform.rs:1450:15
16: core::ops::function::FnOnce::call_once
at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/ops/function.rs:227:5
17: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/panic/unwind_safe.rs:271:9
18: std::panicking::try::do_call
at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:492:40
19: std::panicking::try
at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:456:19
20: std::panic::catch_unwind
at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panic.rs:137:14
21: gstreamer_base::subclass::base_transform::base_transform_generate_output
at /var/home/phil/.cargo-home/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/c61d913/gstreamer-base/src/subclass/base_transform.rs:1449:5
22: gst_base_transform_chain
at /var/home/phil/gstreamer/build/../subprojects/gstreamer/libs/gst/base/gstbasetransform.c:2345:11
23: gst_pad_chain_data_unchecked
at /var/home/phil/gstreamer/build/../subprojects/gstreamer/gst/gstpad.c:4444:11
24: gst_pad_push_data
at /var/home/phil/gstreamer/build/../subprojects/gstreamer/gst/gstpad.c:4708:9
25: gst_pad_push
at /var/home/phil/gstreamer/build/../subprojects/gstreamer/gst/gstpad.c:4827:9
26: gst_base_transform_chain
at /var/home/phil/gstreamer/build/../subprojects/gstreamer/libs/gst/base/gstbasetransform.c:2381:15
27: gst_pad_chain_data_unchecked
at /var/home/phil/gstreamer/build/../subprojects/gstreamer/gst/gstpad.c:4444:11
28: gst_pad_push_data
at /var/home/phil/gstreamer/build/../subprojects/gstreamer/gst/gstpad.c:4708:9
29: gst_pad_push
at /var/home/phil/gstreamer/build/../subprojects/gstreamer/gst/gstpad.c:4827:9
30: gst_base_transform_chain
at /var/home/phil/gstreamer/build/../subprojects/gstreamer/libs/gst/base/gstbasetransform.c:2381:15
31: gst_pad_chain_data_unchecked
at /var/home/phil/gstreamer/build/../subprojects/gstreamer/gst/gstpad.c:4444:11
32: gst_pad_push_data
at /var/home/phil/gstreamer/build/../subprojects/gstreamer/gst/gstpad.c:4708:9
33: gst_pad_push
at /var/home/phil/gstreamer/build/../subprojects/gstreamer/gst/gstpad.c:4827:9
34: gst_base_src_loop
at /var/home/phil/gstreamer/build/../subprojects/gstreamer/libs/gst/base/gstbasesrc.c:3030:11
35: gst_task_func
at /var/home/phil/gstreamer/build/../subprojects/gstreamer/gst/gsttask.c:384:5
36: g_thread_pool_thread_proxy
at /usr/src/debug/glib2-2.72.1-1.fc36.x86_64/redhat-linux-build/../glib/gthreadpool.c:354:15
37: g_thread_proxy
at /usr/src/debug/glib2-2.72.1-1.fc36.x86_64/redhat-linux-build/../glib/gthread.c:827:20
38: start_thread
39: clone3
```
so the alpha mem stored in state is not writable (AFAIU), likely because its refcount is `> 1`.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1309How to build the demo plugin?2022-06-29T11:05:53ZAlex CHow to build the demo plugin?
Hi all,
I'm very new to all this... Can someone point me in the right direction?
I'm trying to build the plugin (by following the tutorial).
After running **meson build** this is what I get:
`
alexc@impNUC:-/WorkTmp/gst-template$ me...
Hi all,
I'm very new to all this... Can someone point me in the right direction?
I'm trying to build the plugin (by following the tutorial).
After running **meson build** this is what I get:
`
alexc@impNUC:-/WorkTmp/gst-template$ meson build
The Meson build system
Version: 0.60.2
Source dir: /home/alexc/WorkTmp/gst-template
Build dir: /home/alexc/WorkTmp/gst-template/build
Build type: native build
Project name: gst-template
Project version: 1.19.0.1
C compiler for the host machine: cc (gcc 9.4.0 "cc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0")
C linker for the host machine: cc ld.bfd 2.34
Host machine cpu family: x86_64
Host machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (0.29.1)
Dependency gstreamer-1.0 found: **NO** found 1.16.2 but need: '>=1.19'
Found CMake: /usr/bin/cmake (3.16.3)
Run-time dependency gstreamer-1.0 found: **NO** (tried pkgconfig and make)
Looking for a fallback subproject for the dependency gstreamer-1.0
meson.build:11:0: ERROR: Neither a subproject directory nor a gstreamer.wrap file was found.
`
How do I set the correct version?
**gst-element-maker** also didn't work for me - I'm missing some files they mentioned and have no idea where to get them...
Thanks,
Alexhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1308v4l2: SIGSEGV when doing 'change state' during 'format change'2022-12-01T13:40:00ZPaweł Stawickiv4l2: SIGSEGV when doing 'change state' during 'format change'#### Observed Behavior
When playing a HLS video that has a 'resolution change' and changing state (stopping playback) during the resolution change I'm getting a SIGSEGV.
#### Setup
- **Operating System:** Raspberry Pi OS 11 (bullseye)
...#### Observed Behavior
When playing a HLS video that has a 'resolution change' and changing state (stopping playback) during the resolution change I'm getting a SIGSEGV.
#### Setup
- **Operating System:** Raspberry Pi OS 11 (bullseye)
- **Device:** Raspberry Pi 400
- **GStreamer Version:** 1.21.0 (GIT), commit: b09ae1d63557987340992760cfa8291ecec79fe7
- **Build command line:** `meson builddir -Dgst-plugins-base:gl=disabled`
- **Command line:** `gst-launch-1.0 --no-fault souphttpsrc location="$HLS1" ! hlsdemux ! parsebin ! v4l2h264dec ! autovideosink`
### Steps to reproduce the bug
see: https://github.com/stawel/gstreamer-tests/tree/main/format-change
1. checkout above repo
2. in terminal 1:
```
cd format-change
python -m http.server
```
3. in terminal 2:
```
cd format-change
./readme.txt
```
after a while you should get:
```
...
################################### Tue 28 Jun 2022 05:26:47 PM CEST #### test 20, sleep time 5.282498487952571
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'souphttpsrc0': gst.soup.session=context, session=(GstSoupSession)NULL;
Got context from element 'souphttpsrc1': gst.soup.session=context, session=(GstSoupSession)NULL;
Redistribute latency...
Redistribute latency...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
Redistribute latency...
New clock: GstSystemClock
Got context from element 'souphttpsrc1': gst.soup.session=context, session=(GstSoupSession)NULL;
0:00:03.3 / 0:00:12.0 (28.2 %)
** (gst-launch-1.0:14838): WARNING **: 17:26:51.762: v4l2h264dec0: Too old frames, bug in decoder -- please file a bug
** (gst-launch-1.0:14838): WARNING **: 17:26:51.768: v4l2h264dec0: Too old frames, bug in decoder -- please file a bug
** (gst-launch-1.0:14838): WARNING **: 17:26:51.769: v4l2h264dec0: Too old frames, bug in decoder -- please file a bug
handling interrupt..0 (40.8 %)
Interrupt: Stopping pipeline ...
Execution ended after 0:00:04.951858206
Setting pipeline to NULL ...
./readme.txt: line 30: 14838 Segmentation fault (core dumped) gst-launch-1.0 --no-fault souphttpsrc location="$HLS1" ! hlsdemux ! parsebin ! v4l2h264dec ! autovideosink
pi@raspberrypi:~/format-change $
```
### How reproducible is the bug?
with the script above it take about 5 minutes to reproduce
### gdb core callstack
```
Core was generated by `gst-launch-1.0 --no-fault souphttpsrc location=http://localhost:8000/resolution'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 malloc_consolidate (av=av@entry=0x7f50000020) at malloc.c:4475
4475 malloc.c: No such file or directory.
[Current thread is 1 (Thread 0x7f57fff180 (LWP 4369))]
(gdb) bt
#0 malloc_consolidate (av=av@entry=0x7f50000020) at malloc.c:4475
#1 0x0000007f80e5b210 in _int_malloc (av=av@entry=0x7f50000020, bytes=bytes@entry=127297) at malloc.c:3699
#2 0x0000007f80e5cc38 in __GI___libc_malloc (bytes=127297) at malloc.c:3066
#3 0x0000007f8104db40 in g_malloc () at /lib/aarch64-linux-gnu/libglib-2.0.so.0
#4 0x0000007f7dc49a30 in gst_adapter_get_internal (adapter=adapter@entry=0x7f4800bea0, nbytes=nbytes@entry=127297) at ../subprojects/gstreamer/libs/gst/base/gstadapter.c:736
#5 0x0000007f7dc4b048 in gst_adapter_get_buffer (adapter=adapter@entry=0x7f4800bea0, nbytes=nbytes@entry=127297) at ../subprojects/gstreamer/libs/gst/base/gstadapter.c:1012
#6 0x0000007f7dc4b158 in gst_adapter_take_buffer (adapter=0x7f4800bea0, nbytes=127297) at ../subprojects/gstreamer/libs/gst/base/gstadapter.c:1076
#7 0x0000007f7c2f40d0 in gst_h264_parse_parse_frame (parse=<optimized out>, frame=0x7f50122630) at ../subprojects/gst-plugins-bad/gst/videoparsers/gsth264parse.c:2720
#8 0x0000007f7c2f5820 in gst_h264_parse_handle_frame (parse=<optimized out>, frame=0x7f50122630, skipsize=0x7f57ffd8a4) at ../subprojects/gst-plugins-bad/gst/videoparsers/gsth264parse.c:1579
#9 0x0000007f7dc5f1e4 in gst_base_parse_handle_buffer (parse=parse@entry=0x7f500cbaa0, buffer=<optimized out>, skip=skip@entry=0x7f57ffd8a4, flushed=flushed@entry=0x7f57ffd8a8)
at ../subprojects/gstreamer/libs/gst/base/gstbaseparse.c:2253
#10 0x0000007f7dc64614 in gst_base_parse_chain (pad=<optimized out>, parent=<optimized out>, buffer=<optimized out>) at ../subprojects/gstreamer/libs/gst/base/gstbaseparse.c:3302
#11 0x0000007f811d7570 in gst_pad_chain_data_unchecked (pad=pad@entry=0x7f5c00af60, type=type@entry=4112, data=<optimized out>, data@entry=0x7f501487e0) at ../subprojects/gstreamer/gst/gstpad.c:4444
#12 0x0000007f811d9370 in gst_pad_push_data (pad=pad@entry=0x7f5c00aac0, type=type@entry=4112, data=data@entry=0x7f501487e0) at ../subprojects/gstreamer/gst/gstpad.c:4708
#13 0x0000007f811e0c88 in gst_pad_push (pad=0x7f5c00aac0, buffer=buffer@entry=0x7f501487e0) at ../subprojects/gstreamer/gst/gstpad.c:4827
#14 0x0000007f7c420f40 in gst_ts_demux_push_pending_data (demux=demux@entry=0x7f5c008ce0, stream=stream@entry=0x7f500c56b0, target_program=target_program@entry=0x0)
at ../subprojects/gst-plugins-bad/gst/mpegtsdemux/tsdemux.c:3544
#15 0x0000007f7c422790 in gst_ts_demux_handle_packet (section=<optimized out>, packet=<optimized out>, stream=0x7f500c56b0, demux=0x7f5c008ce0)
at ../subprojects/gst-plugins-bad/gst/mpegtsdemux/tsdemux.c:3632
#16 gst_ts_demux_push (base=0x7f5c008ce0, packet=<optimized out>, section=<optimized out>) at ../subprojects/gst-plugins-bad/gst/mpegtsdemux/tsdemux.c:3700
...
```
### valgrind logs
```
==13800== Invalid write of size 4
==13800== at 0x4B98CE8: pthread_mutex_lock (pthread_mutex_lock.c:118)
==13800== by 0x48B66EF: gst_buffer_pool_is_active (gstbufferpool.c:598)
==13800== by 0xA9F1C0B: gst_v4l2_object_unlock (gstv4l2object.c:4563)
==13800== by 0xAA04AF3: gst_v4l2_video_dec_change_state (gstv4l2videodec.c:1059)
==13800== by 0x48D48EB: gst_element_change_state (gstelement.c:3093)
==13800== by 0x48D5093: gst_element_set_state_func (gstelement.c:3047)
==13800== by 0x48AE863: gst_bin_element_set_state (gstbin.c:2581)
==13800== by 0x48AE863: gst_bin_change_state_func (gstbin.c:2923)
==13800== by 0x4900E5B: gst_pipeline_change_state (gstpipeline.c:529)
==13800== by 0x48D48EB: gst_element_change_state (gstelement.c:3093)
==13800== by 0x48D492B: gst_element_change_state (gstelement.c:3132)
==13800== by 0x48D5093: gst_element_set_state_func (gstelement.c:3047)
==13800== by 0x10BD0F: main (gst-launch.c:1339)
==13800== Address 0x8b191e4 is 4 bytes inside a block of size 48 free'd
==13800== at 0x484AFE0: free (vg_replace_malloc.c:538)
==13800== by 0x48B6037: gst_buffer_pool_finalize (gstbufferpool.c:213)
==13800== by 0x4B3B95F: g_object_unref (in /usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0.6600.8)
==13800== by 0xA9F84D7: gst_v4l2_buffer_pool_orphan (gstv4l2bufferpool.c:1049)
==13800== by 0xA9F1D63: gst_v4l2_object_stop (gstv4l2object.c:4593)
==13800== by 0xAA06CDB: gst_v4l2_video_dec_set_format (gstv4l2videodec.c:274)
==13800== by 0x9EC235F: gst_video_decoder_setcaps (gstvideodecoder.c:897)
==13800== by 0x9EC235F: gst_video_decoder_sink_event_default (gstvideodecoder.c:1379)
==13800== by 0x48F30F3: gst_pad_send_event_unchecked (gstpad.c:5897)
==13800== by 0x48F352F: gst_pad_push_event_unchecked (gstpad.c:5541)
==13800== by 0x48F3B0B: push_sticky (gstpad.c:4044)
==13800== by 0x48F16DF: events_foreach (gstpad.c:605)
==13800== by 0x48FCC87: check_sticky (gstpad.c:4103)
==13800== by 0x48FCC87: gst_pad_push_event (gstpad.c:5672)
==13800== Block was alloc'd at
==13800== at 0x4849E4C: malloc (vg_replace_malloc.c:307)
==13800== by 0x4A84167: ??? (in /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0.6600.8)
==13800== by 0x4A841F3: g_rec_mutex_init (in /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0.6600.8)
==13800== by 0x48B6E07: gst_buffer_pool_init (gstbufferpool.c:160)
==13800== by 0x4B56787: g_type_create_instance (in /usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0.6600.8)
==13800== by 0x4B3BE87: ??? (in /usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0.6600.8)
==13800== by 0x4B3DCF3: g_object_new_valist (in /usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0.6600.8)
==13800== by 0x4B3DF6F: g_object_new (in /usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0.6600.8)
==13800== by 0xA9F8593: gst_v4l2_buffer_pool_new (gstv4l2bufferpool.c:1819)
==13800== by 0xA9E93B3: gst_v4l2_object_setup_pool (gstv4l2object.c:3161)
==13800== by 0xA9EC97B: gst_v4l2_object_set_format_full (gstv4l2object.c:4045)
==13800== by 0xAA06D17: gst_v4l2_video_dec_set_format (gstv4l2videodec.c:304)
```
### Additional Information
It looks like the heap is corrupted.
Reason (from valgrind logs):
`gst_v4l2_video_dec_change_state(...)` is touching something what was released in a different thread by `gst_v4l2_video_dec_set_format(...)`https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1306wasapi loopback captures audio from a muted device2023-04-07T18:59:06ZIgnaziowasapi loopback captures audio from a muted device### Describe your issue
Both wasapi and waspi2 sources captures audio from a muted device when loopback=true.
wasapi2src provides a `mute` property however this value is related only to the application's `mute` state reported in the Wind...### Describe your issue
Both wasapi and waspi2 sources captures audio from a muted device when loopback=true.
wasapi2src provides a `mute` property however this value is related only to the application's `mute` state reported in the Windows audio mixer.
The global device's `mute` state is completely ignored during audio grabbing.
#### Expected Behavior
- No audio should be captured when the device is muted.
#### Observed Behavior
- Both wasapisrc+loopback and waspi2src+loopback captures audio when the device is muted.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1724hlssink2 -> splitmuxsink format-location-full handler2022-06-28T09:11:25ZTonyfacehlssink2 -> splitmuxsink format-location-full handlerIn 1.14.5, the custom handler for format-location-full in splitmuxsink was expected to return a gchar* with the custom location to store a fragment. Providing a custom handler for this successfully created custom named files and those fi...In 1.14.5, the custom handler for format-location-full in splitmuxsink was expected to return a gchar* with the custom location to store a fragment. Providing a custom handler for this successfully created custom named files and those filenames were passed to the hlssink2, and ended up in the output playlist.
Now (1.20.1), the default on_format_location in hlssink2 returns NULL, and sets a private variable current_location whose value is used to create the appropriate line in the output playlist.
If one now returns a gchar* from a custom handler, and creates a GOutputStream and assigns it to the splitmux giostreamsink, the location isn't seen by hlssink2, current_location isn't updated, the resulting playlist is empty (aside from headers), and an element message is posted indicating "Fragment closed without knowing its location".
I currently can't see any way to have both
- a custom format-location-full handler, and
- working playlist file output
Am I just missing something obvious? Is there a way I can access and set current_location?
If not, would it break any rules to have the hlssink2 provide an equivalent "format-location-full" signal, emitted when the splitmuxsink emits its own, but which would capture the return value, store it in current_location, then pass it as the return value to the splitmuxsink signal handler?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1304d3d11videosink force-aspect-ratio=false doesn't work when draw-on-shared-text...2022-07-01T18:15:02Zilwoo Namd3d11videosink force-aspect-ratio=false doesn't work when draw-on-shared-texture=true### Describe your issue
d3d11videosink force-aspect-ratio=false doesn't work when draw-on-shared-texture=true
#### Expected Behavior
When we set force-aspect-ratio=false on d3d11videosink (draw-on-shared-texture=true), aspect ratio of...### Describe your issue
d3d11videosink force-aspect-ratio=false doesn't work when draw-on-shared-texture=true
#### Expected Behavior
When we set force-aspect-ratio=false on d3d11videosink (draw-on-shared-texture=true), aspect ratio of the image rendered on shared texture should be ignored.
#### Observed Behavior
When we set force-aspect-ratio=false on d3d11videosink (draw-on-shared-texture=true), aspect ratio of the image rendered on shared texture is still kept.
#### Setup
* **Operating System:** Windows 10 (version 21H2 (OS Build 19044.1645)
* **Device:** Desktop with Nvidia Quadro P4000 GPU
* **GStreamer Version:** 1.20.2
### Steps to reproduce the bug
I made sample application to show rtsp camera with c# WPF.
In that application, I created shared texture and let d3d11videosink (force-aspect-ratio=false, draw-on-shared-texture=true) write decoded image on shared texture.
And then I draw image with d3dimage connected to that shared texture.
The image on my WPF application has top, down or right, left blank area because of aspect ratio.
### How reproducible is the bug?
always
### Solutions you have tried
I think that
In 363 line of gstd3d11videosink.cpp,
case PROP_FORCE_ASPECT_RATIO:
self->force_aspect_ratio = g_value_get_boolean (value);
if (self->window)
g_object_set (self->window,
"force-aspect-ratio", self->force_aspect_ratio, NULL);
when draw-on-shared-texture=true, because if(self->window) is false, g_object_set doesn't run.
When I changed the gstd3d11videosink.cpp code like below, the issue was solved.
732 line
if (self->draw_on_shared_texture) {
GST_INFO_OBJECT (self,
"Create dummy window for rendering on shared texture");
self->window = gst_d3d11_window_dummy_new (self->device);
g_object_set(self->window,
"force-aspect-ratio", self->force_aspect_ratio, NULL);
return TRUE;
}
Please check this issue and if this is the right place to correct.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/213Fallbackswitch : erroneous pipeline: could not link videotestsrc0 to s2022-06-28T06:20:30ZFredericFallbackswitch : erroneous pipeline: could not link videotestsrc0 to sI have two Gstreamer pipelines that work separately:
```
gst-launch-1.0 nvarguscamerasrc sensor-id=0 ! "video/x-raw(memory:NVMM),width=1920,height=1080,framerate=30/1" ! nvvidconv ! video/x-raw ! ximagesink
```
and
```gst-launch-1.0 vid...I have two Gstreamer pipelines that work separately:
```
gst-launch-1.0 nvarguscamerasrc sensor-id=0 ! "video/x-raw(memory:NVMM),width=1920,height=1080,framerate=30/1" ! nvvidconv ! video/x-raw ! ximagesink
```
and
```gst-launch-1.0 videotestsrc ! ximagesink```
But when I join them together with fallbackswitch like:
```
gst-launch-1.0 nvarguscamerasrc sensor-id=0 ! "video/x-raw(memory:NVMM),width=1920,height=1080,framerate=30/1" ! nvvidconv ! video/x-raw ! fallbackswitch name=s ! ximagesink videotestsrc ! s.fallback_sink
```
I get the following error message:
```
WARNING: erroneous pipeline: could not link videotestsrc0 to s
```
Any idea why this does not work ?
Regards.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/212fallbackswitch : Compilation with elder version of GStreamer2022-06-27T11:10:14ZFredericfallbackswitch : Compilation with elder version of GStreamerHello, I would like to install and use fallbackswitch on a Nvidia Jetson Xavier NX with Ubuntu 18 and GStreamer 1.14. However the compilation of the plugin with cargo build provides the following error message : Requested 'gstreamer-1.0 ...Hello, I would like to install and use fallbackswitch on a Nvidia Jetson Xavier NX with Ubuntu 18 and GStreamer 1.14. However the compilation of the plugin with cargo build provides the following error message : Requested 'gstreamer-1.0 >= 1.20' but version of GStreamer is 1.14.5
Is there a way around this because I cannot change the version of GStreamer ?
Thanks for your help.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/211aws-s3-sdk: add endpoint2022-08-04T12:15:20ZAadeITaws-s3-sdk: add endpointHello everyone, this is a good project. I need to specify the ip:port when using it. Do you consider supporting endpoint? We look forward to your reply,thank youHello everyone, this is a good project. I need to specify the ip:port when using it. Do you consider supporting endpoint? We look forward to your reply,thank youhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1302info audioresample2022-11-10T09:21:14ZFilippo raciinfo audioresampleHi,
I'm trying to resample audio files, I use a shell script and the command I use is this.
But I'm not sure if the parameters I write are right, whatever I write as parameters never gives me an error, so I can't tell if I'm right:
the...Hi,
I'm trying to resample audio files, I use a shell script and the command I use is this.
But I'm not sure if the parameters I write are right, whatever I write as parameters never gives me an error, so I can't tell if I'm right:
the string is this:
`gst-launch-1.0 -v filesrc location="$file" ! decodebin ! audioconvert ! audioresample ! audio/x-raw, format=S24LE,rate=176400,dithering=tpdf_hf,dithering-threshold=24,noise-shaping=high,quality=10,resample-method=blackman-nuttall,sinc-filter-interpolation=linear,sinc-filter-mode=full ! alsasink device=hw:1,0`https://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/98Dynamic removing webrtcbin from GstTee cause total pipeline paused2022-06-24T10:47:02ZZhuChaselDynamic removing webrtcbin from GstTee cause total pipeline pausedI use one tee for maybe 5 webrtcbins as receiver, and one appsrc as sender. Between appsrc and tee, I have GstQueue, named queue1. I try to remove one webrtcbin frequently. Then i found queue1 paused sometimes, then block all the pipelin...I use one tee for maybe 5 webrtcbins as receiver, and one appsrc as sender. Between appsrc and tee, I have GstQueue, named queue1. I try to remove one webrtcbin frequently. Then i found queue1 paused sometimes, then block all the pipeline.
I even use GST_PAD_PROBE_TYPE_IDLE to unlink teepad using gst_pad_unlink before removing webrtcbin, code like,
gst_pad_add_probe(sink->teepad, GST_PAD_PROBE_TYPE_IDLE, unlink_cb, sink, (GDestroyNotify)g_free);
But I can still produce pipeline block, queue1 paused. I dig into the source code, when peer(chrome) leaves, I find teepad change to GST_FLOW_FLUSHING(-2) state even without removing webrtcbin from pipeline, I think changing to GST_FLOW_FLUSHING state is inevitable. Below is the state related log:
>>>>>>>>>>>>>>>>>>log>>>>>>>>>>>>>>>>>>>>>>>>>
tee gsttee.c:940:gst_tee_handle_data:<videotee:src_4> Starting to push buffer 0000027DC865E000
0:00:03.219030000 9820 0000027DC5905800 INFO GST_SCHEDULING gstpad.c:4860:gst_pad_push_data:<videotee:src_4> error pushing events, return flushing
0:00:03.219759000 9820 0000027DC5905800 INFO tee gsttee.c:945:gst_tee_handle_data:<videotee:src_4> Pushing item 0000027DC865E000 yielded result flushing pad src_4
0:00:03.220583000 9820 0000027DC5905800 INFO tee gsttee.c:1013:gst_tee_handle_data:<videotee> received error flushing
0:00:03.222496000 9820 0000027DC5905800 INFO GST_PADS gstpad.c:4468:gst_pad_chain_data_unchecked:<videotee> chainfunc return2 queue videotee return -2 funcname gst_tee_chain pad sink
0:00:03.223200000 9820 0000027DC5905800 INFO GST_SCHEDULING gstpad.c:4478:gst_pad_chain_data_unchecked:<videotee:sink> called chainfunction &gst_tee_chain with buffer 0000027DC865E000, returned flushing
0:00:03.223904000 9820 0000027DC5905800 INFO GST_PADS gstpad.c:4511:gst_pad_chain_data_unchecked:<videotee> chainfunc return queue videotee pad sink return -2
0:00:03.227789000 9820 0000027DC5905800 INFO GST_SCHEDULING gstpad.c:4478:gst_pad_chain_data_unchecked:<caps:sink> called chainfunction &gst_base_transform_chain with buffer 0000027DC865E000, returned flushing
0:00:03.228397000 9820 0000027DC5905800 INFO GST_PADS gstpad.c:4511:gst_pad_chain_data_unchecked:<caps> chainfunc return queue caps pad sink return -2
0:00:03.228885000 9820 0000027DC5905800 INFO GST_SCHEDULING gstpad.c:4500:gst_pad_chain_data_unchecked:<caps:sink> called chainlistfunction &gst_pad_chain_list_default, returned flushing ret -2
0:00:03.229151000 9820 0000027DC5905800 INFO GST_PADS gstpad.c:4511:gst_pad_chain_data_unchecked:<caps> chainfunc return queue caps pad sink return -2
0:00:03.229579000 9820 0000027DC5905800 INFO task gsttask.c:733:gst_task_set_state_unlocked:<queuebb:src> Changing task 0000027DC5907290 to state 2
0:00:03.230532000 9820 0000027DC5905800 INFO queue_dataflow gstqueue.c:1660:gst_queue_loop:<queuebb> pause task, reason: flushing
0:00:03.231669000 9820 0000027DC5905800 INFO task gsttask.c:369:gst_task_func:<queuebb:src> Task 0000027DC5907290 going to paused
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
from function gst_tee_handle_data,
while (pads) {
GstPad *pad;
/* stop pushing more buffers when we have a fatal error */
if (G_UNLIKELY (ret != GST_FLOW_OK && ret != GST_FLOW_NOT_LINKED))
goto error;
pads = g_list_next (pads);
}
if one pad is not OK, then all pads will be affected. How about move goto error out? So, what can I do to dynamically remove webrtcbin from tee without affect other webrtcbin? Please advise.
Thanks.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/210Handling SIGSEGV: invalid address on gstElementFactory.create()2022-06-24T12:03:56ZMattia AHandling SIGSEGV: invalid address on gstElementFactory.create()Hi all,
I'm working on a loader for the nodes present on the system, however, I'm having some issues with some third-party nodes.
Or better I started to have issues after their installation.
After some LLDB, I managed to pinpoint that t...Hi all,
I'm working on a loader for the nodes present on the system, however, I'm having some issues with some third-party nodes.
Or better I started to have issues after their installation.
After some LLDB, I managed to pinpoint that the error is generated from the create method of a **gstElementFactory** on the **create** method.
the object is the **avmux_ttml** .
Now the problem is that even if I know the line giving me issues I can't check for error since it is generated from the c side, Does someone know how can I work around this?
I would like to help if someone gives me some guidance to propose a fix to propagate the error back from c to rust wrapping it inside a nice Err().
This is a part of the backtrace:
```
`* thread #1, name = 'myapp', stop reason = signal SIGSEGV: invalid address (fault address: 0x70)
* frame #0: 0x00007ffff7e75c7b libgstreamer-1.0.so.0`gst_pad_new_from_template + 11
frame #1: 0x00007ffff5a4b678 libgstlibav.so`gst_ffmpegmux_init + 72
frame #2: 0x00007ffff7f781dd libgobject-2.0.so.0`g_type_create_instance + 781
frame #3: 0x00007ffff7f5734d libgobject-2.0.so.0`___lldb_unnamed_symbol127$$libgobject-2.0.so.0 + 509
frame #4: 0x00007ffff7f58b45 libgobject-2.0.so.0`g_object_new_with_properties + 629
frame #5: 0x00007ffff7f596f1 libgobject-2.0.so.0`g_object_new + 193
frame #6: 0x00007ffff7e579f3 libgstreamer-1.0.so.0`gst_element_factory_create + 435
frame #7: 0x0000555555d9e221 myapp`gstreamer::auto::element_factory::ElementFactory::create::h3b3646d7343bf9f8(self=0x00007fffffff7518, name=Option<&str> @ 0x00007fffffff6c48) at element_factory.rs:66:41
frame #8: 0x00005555556e2563 myapp`myapp::dgi::element::DgiElement::from_plugin_factory::hcd8baf6093ae2986(gst_factory=0x00007fffffff7518, gst_plugin=0x00007fffffff74d0) at element.rs:27:23
frame #9: 0x0000555555706835 myapp`myapp::dgi::inspector::index_elements::h86477c7f8cd922c6 at inspector.rs:26:27
frame #10: 0x0000555555763041 myapp`myapp::cli_commands::list_elements_commands::handle_list_element::ha7f1cee74af359f3 at list_elements_commands.rs:6:20
frame #11: 0x0000555555786f48 myapp`myapp::main::_$u7b$$u7b$closure$u7d$$u7d$::h29467d2c73ededaa((null)=Pin<&mut myapp::main::{async_block_env#0}> @ 0x00007fffffffbd98, (null)=ResumeTy @ 0x00007fffffffbda0) at main.rs:35:30`
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1300gst-launch-1.0 pipeline freezes after recording of rapidly changing images2022-11-10T09:21:14ZSzczempusgst-launch-1.0 pipeline freezes after recording of rapidly changing images### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstream...### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstreamer.freedesktop.org/lists/ -->
UDP pipeline gets frozen after a fast-changing image (ie. while waving a hand in front of camera or shaking). The internal clock is working, but pipeline clock stops without state changing. Only pipeline restart helps.
#### Expected Behavior
The pipeline should still transmit video
#### Observed Behavior
The pipeline does not send any video data and is still in a playing state with a stopped pipeline clock.
#### Setup
- **Operating System:** Debian 11 aarch64
- **Device:** Raspberry Pi3B+ 1 GB, EM7455 LTE Modem (1Mbit/s real speed), PS3 Eye webcam
- **GStreamer Version:** 1.0
### Steps to reproduce the bug
host pipeline:
`
gst-launch-1.0 -ve v4l2src device=/dev/video0 ! video/x-raw,width=640,height=480,framerate=\(fraction\)30/1 ! clockoverlay ! v4l2h264enc extra-controls=s,video_bitrate=250000 capture-io-mode=4 output-io-mode=4 ! "video/x-h264,level=(string)4" ! rtph264pay config-interval=1 ! multiudpsink clients="127.0.0.1:5006,10.123.0.2:5006" sync=false
`
client pipeline:
`
udpsrc port=5006 do-timestamp=true ! application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 ! rtpjitterbuffer latency=100 drop-on-latency=true drop-messages-interval=100000000 ! queue max-size-buffers=20000 ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! glupload ! qmlglsink name=qmlglsink sync=false
`
### Solutions you have tried
Modifying pipeline in many ways. Modifying rtpjitter buffer, queue, camera bitrate and resolution. Tried to change h264 encoder, but pipeline starts only with hardware v4l2h264enc. Connecting via ethernet also doesn't resolve the problem.
For testing, I lunch a simple ffmpeg pipeline and it worked without any problems so that excludes hardware problems.
### Additional Information
For more information, I enclose a log file. Pay attention to what happens after the last sent video frame. It falls into the loop while sending a query and in v4l2src0 gets a timeout. [zipped log file](/uploads/4016b85eaf33171a0949c8fc9222b6a4/gst.zip)https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/209hlssink3: playlist type should be an enum2022-07-09T11:44:29ZArun Raghavanhlssink3: playlist type should be an enumThe playlist type property is currently implemented as a string. Since we have a limited number of valid values, we should potentially implement this as an enum instead.The playlist type property is currently implemented as a string. Since we have a limited number of valid values, we should potentially implement this as an enum instead.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1298gst-rtsp-server: not able to send big frames for 2 clients both using rtsp ov...2023-03-09T10:26:07ZBruce Lianggst-rtsp-server: not able to send big frames for 2 clients both using rtsp over tcp in low bandwidth networkHi,
I'm using gstreamer 1.20.2. and come across a problem about rtsp over tcp.
I add a shared media factory to rtsp-server for a h.264 stream.
And there are 2 clients that will access the stream by rtsp over tcp and the network has lo...Hi,
I'm using gstreamer 1.20.2. and come across a problem about rtsp over tcp.
I add a shared media factory to rtsp-server for a h.264 stream.
And there are 2 clients that will access the stream by rtsp over tcp and the network has low bandwidth(100Mbps network).
When the first client accesses the stream from the server choosing rtsp over tcp, it works correctly.
Then the second client accesses the same stream by rtsp over tcp, it will work correctly only while the frame size is not big.
When there is a large I frame that has size over 200KB sent to both clients, the following log shows:
`0:10:04.842062023 420 0x1a5a790 DEBUG rtspclient rtsp-client.c:4908:do_send_messages:<GstRTSPClient at 0x7574c430> wait for message 1, channel 0`
And the server stops sending frames to second client after the large I frame sent, while the server continues to send frames to the first client.
After investigation, I found that:
When rtsp server send rtp/rtcp data over tcp, the tcp send thread(created in handle_new_sample()) calls send_tcp_message().
It will push rtp/rtcp buffer to each transport's backlog and then calls check_transport_backlog() to pop buffer from backlog queue and push buffer to client.
If the buffer can't be sent completely in a single push_data() call, the buffer will be queued and continued to send in client watch thread.
And if the transport is still sending the buffer in client thread, next time calling push_data() in the tcp send thread will get return value false.
Then the transport will be removed and the rtp/rtcp data will not be able to be sent thereafter.
Also I found that when the backlog queue mechanism was introduced, in send_tcp_message(), the backpressure is checked using gst_rtsp_stream_transport_check_back_pressure() before calling push_data().
If there is a buffer queued in client watch(the backlog), the new buffer will not be pushed to client and will be pushed into backlog queue.
According to my understanding, the check mechanism might be the possible solution to this situation.
But I am not sure the reason why it is removed now.
Would you please help to take a look and advise the next step?
Thank you.
related commit:
https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/commit/dd32924eb020b01fdec511c9f10a283383312488https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1297gst-rtsp-server: different media will be created for URL rtsp://<IP>:<PORT> a...2022-07-20T07:01:11ZBruce Lianggst-rtsp-server: different media will be created for URL rtsp://<IP>:<PORT> and URL rtsp://<IP>:<PORT>/Hi,
I'm using gstreamer 1.20.2 and come across a problem about mount point "/".
When using shared media factory and mount it at mount point "/", the factory can be accessed by both the URL forms `rtsp://<IP>:<PORT>` and `rtsp://<IP>:...Hi,
I'm using gstreamer 1.20.2 and come across a problem about mount point "/".
When using shared media factory and mount it at mount point "/", the factory can be accessed by both the URL forms `rtsp://<IP>:<PORT>` and `rtsp://<IP>:<PORT>/`.
But I found that the media created by the factory can't be shared between the 2 URL forms.
After the media is created by accessing URL `rtsp://<IP>:<PORT>/`, accessing URL `rtsp://<IP>:<PORT>` will match the same factory but create another new media.
The result of accessing URL `rtsp://<IP>:<PORT>` first and then accessing URL `rtsp://<IP>:<PORT>/` is the same, 2 media created while factory is shared.
After investigation, I found that:
When DESCRIBE request is handled for an URL, the default_make_path() will normalize URL `rtsp://<IP>:<PORT>` to `rtsp://<IP>:<PORT>/` to generate path.
And the path is passed to find_media().
According to my understanding, if the media factory is shared and is attached to mount point "/", the media should be shared for both URL forms.
The default_gen_key() is used to generated key for caching media in gst_rtsp_media_factory_construct().
However, the key is generated by the following line in default_gen_key():
`result = g_strdup_printf ("%u%s%s%s", port, url->abspath, pre_query, query);`
url->abspath is not normalized, so the key will be different and therefore different media will be created for URL `rtsp://<IP>:<PORT>` and URL `rtsp://<IP>:<PORT>/`.
According to my understanding, the possible solution to this situation might be the url could either be normalized before it is passed to gst_rtsp_media_factory_construct() or be normalized in default_gen_key() directly.
Would you please help to take a look and advise the next step?
Thank you.
related commit
https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/commit/e9555d1539643f7861a80a7d1333876e90d05134https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/329Vaapih264enc encoded ts segments do not play on AVPlayer2022-06-22T12:21:32ZGuru GovindanVaapih264enc encoded ts segments do not play on AVPlayerThe ts segments generated by `vaapih264enc` elements do not play in AVplayer(quicktime or IOS).
For example the ts segment generated by the following pipeline does not play in quicktime player.
```
gst-launch-1.0 rtspsrc location=rtsp:...The ts segments generated by `vaapih264enc` elements do not play in AVplayer(quicktime or IOS).
For example the ts segment generated by the following pipeline does not play in quicktime player.
```
gst-launch-1.0 rtspsrc location=rtsp://admin:pass@10.10.0.233:554/ name=rtpsrc0 rtpsrc0. ! rtph264depay ! queue ! decodebin ! vaapih264enc ! mpegtsmux name=mux ! filesink location=mymux.ts rtpsrc0. ! decodebin ! queue ! fdkaacenc ! mux.
```
However if I use a SW encoder `x264enc`, it plays fine.
Another weird scenario is it plays fine when the original stream from the rtsp is H265.
If I wrap this over with an ffmpeg copy that would just work fine
eg: doing the following will just work fine
```
ffmpeg -i mymux.ts -vcodec copy -acodec copy mymux_ffmpeg.ts
```
I appreciate any help with this. Please let me know if you need me to attach the ts segments.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1294rtsp-client/rtsp-media: Adjust error code before sending request response2022-10-11T09:17:42Zspluyyytrtsp-client/rtsp-media: Adjust error code before sending request responseIssue: There is no way for an application to control what response is sent to a request when rtsp-client encounters an error while setting up the pipeline.
Solution: Store the errors reported from the medias pipeline in rtsp-media. Also...Issue: There is no way for an application to control what response is sent to a request when rtsp-client encounters an error while setting up the pipeline.
Solution: Store the errors reported from the medias pipeline in rtsp-media. Also add a virtual function in rtsp-client which, if overriden by the application will be called before sending the error response. There should be no change in todays behaviour unless this method is overriden.