GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2024-01-31T18:19:04Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1286videorate: gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed2024-01-31T18:19:04ZJames Hilliardvideorate: gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failedI'm hitting this failure locally on main, not sure why it's not showing up in CI.
```c
1..1
**-> Checking expectations file: '/home/buildroot/gstreamer/subprojects/gst-plugins-base/tests/validate/videorate/change_rate_reverse_playback/fl...I'm hitting this failure locally on main, not sure why it's not showing up in CI.
```c
1..1
**-> Checking expectations file: '/home/buildroot/gstreamer/subprojects/gst-plugins-base/tests/validate/videorate/change_rate_reverse_playback/flow-expectations/log-videorate-sink-expected'**
**-> Checking expectations file: '/home/buildroot/gstreamer/subprojects/gst-plugins-base/tests/validate/videorate/change_rate_reverse_playback/flow-expectations/log-videorate-src-expected'**
**-> Pipeline: 'videotestsrc ! video/x-raw,format=I420,framerate=10/1,width=320,height=240 ! videorate name=videorate ! fakesink sync=true qos=true'**
**-> Running scenario /home/buildroot/gstreamer/subprojects/gst-plugins-base/tests/validate/videorate/change_rate_reverse_playback.validatetest on pipeline pipeline0**
**-> Starting pipeline**
Prerolling...
**-> Pipeline started**
Executing `seek` at change_rate_reverse_playback.validatetest:14 (
- start=0
- stop=5
- flags=accurate+flush
- rate=-1
)
? Action `seek` at change_rate_reverse_playback.validatetest:14 done 'ASYNC' (duration: 0:00:00.018481721)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:17 (
- expected-time=0
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:17 done 'OK' (duration: 0:00:00.000120623)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:18 [repeat=0/4] (
- expected-elapsed-time=0.10000000000000001
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:18 done 'OK' [0/4] (duration: 0:00:00.001369976)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:18 [repeat=1/4] (
- expected-elapsed-time=0.10000000000000001
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:18 done 'OK' [1/4] (duration: 0:00:00.002062006)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:18 [repeat=2/4] (
- expected-elapsed-time=0.10000000000000001
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:18 done 'OK' [2/4] (duration: 0:00:00.001979757)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:18 [repeat=3/4] (
- expected-elapsed-time=0.10000000000000001
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:18 done 'OK' [3/4] (duration: 0:00:00.002117339)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:19 (
- expected-time=0.5
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:19 done 'OK' (duration: 0:00:00.002002966)
Executing `wait` at change_rate_reverse_playback.validatetest:22 (
- on-clock=true
)
? Action `wait` at change_rate_reverse_playback.validatetest:22 done 'OK' (duration: 0:00:00.001861676)
Executing `checkpoint` at change_rate_reverse_playback.validatetest:25 (
- text="Setting\ videorate.rate\=0.5"
)
? Action `checkpoint` at change_rate_reverse_playback.validatetest:25 done 'OK' (duration: 0:00:00.000022958)
Executing `set-property` at change_rate_reverse_playback.validatetest:26 (
- playback-time=99
- target-element-name=videorate
- property-name=rate
- property-value=0.5
)
? Action `set-property` at change_rate_reverse_playback.validatetest:26 done 'OK' (duration: 0:00:00.000215330)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:29 [repeat=0/5] (
- expected-elapsed-time=0.10000000000000001
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:29 done 'OK' [0/5] (duration: 0:00:00.000138289)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:29 [repeat=1/5] (
- expected-elapsed-time=0.10000000000000001
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:29 done 'OK' [1/5] (duration: 0:00:00.001905134)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:29 [repeat=2/5] (
- expected-elapsed-time=0.10000000000000001
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:29 done 'OK' [2/5] (duration: 0:00:00.002039256)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:29 [repeat=3/5] (
- expected-elapsed-time=0.10000000000000001
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:29 done 'OK' [3/5] (duration: 0:00:00.000112581)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:29 [repeat=4/5] (
- expected-elapsed-time=0.10000000000000001
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:29 done 'OK' [4/5] (duration: 0:00:00.000130706)
Executing `wait` at change_rate_reverse_playback.validatetest:30 (
- on-clock=true
)
? Action `wait` at change_rate_reverse_playback.validatetest:30 done 'OK' (duration: 0:00:00.002011840)
Executing `check-position` at change_rate_reverse_playback.validatetest:31 (
- expected-position=4
)
? Action `check-position` at change_rate_reverse_playback.validatetest:31 done 'OK' (duration: 0:00:00.000578406)
Executing `set-vars` at change_rate_reverse_playback.validatetest:33 (
- rate=0.1
)
? Action `set-vars` at change_rate_reverse_playback.validatetest:33 done 'OK' (duration: 0:00:00.000022166)
Executing `checkpoint` at change_rate_reverse_playback.validatetest:34 (
- text="Setting\ videorate.rate\=0.1"
)
? Action `checkpoint` at change_rate_reverse_playback.validatetest:34 done 'OK' (duration: 0:00:00.000021125)
Executing `set-property` at change_rate_reverse_playback.validatetest:35 (
- playback-time=99
- target-element-name=videorate
- property-name=rate
- property-value=0.10000000000000001
)
? Action `set-property` at change_rate_reverse_playback.validatetest:35 done 'OK' (duration: 0:00:00.000198079)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=0/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [0/20] (duration: 0:00:00.000066373)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=1/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [1/20] (duration: 0:00:00.005746609)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=2/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [2/20] (duration: 0:00:00.000084790)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=3/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [3/20] (duration: 0:00:00.000069874)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=4/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [4/20] (duration: 0:00:00.000064666)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=5/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [5/20] (duration: 0:00:00.000061832)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=6/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [6/20] (duration: 0:00:00.000067416)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=7/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [7/20] (duration: 0:00:00.002028132)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=8/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [8/20] (duration: 0:00:00.000062790)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=9/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [9/20] (duration: 0:00:00.000063249)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=10/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [10/20] (duration: 0:00:00.000069082)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=11/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [11/20] (duration: 0:00:00.000064582)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=12/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [12/20] (duration: 0:00:00.000063957)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=13/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [13/20] (duration: 0:00:00.000062999)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=14/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [14/20] (duration: 0:00:00.000081790)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=15/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [15/20] (duration: 0:00:00.000063624)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=16/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [16/20] (duration: 0:00:00.000063165)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=17/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [17/20] (duration: 0:00:00.002091464)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=18/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [18/20] (duration: 0:00:00.000066790)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=19/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [19/20] (duration: 0:00:00.000064624)
Executing `wait` at change_rate_reverse_playback.validatetest:37 (
- on-clock=true
)
? Action `wait` at change_rate_reverse_playback.validatetest:37 done 'OK' (duration: 0:00:00.000021791)
Executing `check-position` at change_rate_reverse_playback.validatetest:38 (
- expected-position=2
)
? Action `check-position` at change_rate_reverse_playback.validatetest:38 done 'OK' (duration: 0:00:00.000578365)
Executing `checkpoint` at change_rate_reverse_playback.validatetest:41 (
- text="Setting\ videorate.rate\=2.0"
)
? Action `checkpoint` at change_rate_reverse_playback.validatetest:41 done 'OK' (duration: 0:00:00.000022958)
Executing `set-property` at change_rate_reverse_playback.validatetest:42 (
- playback-time=-1
- target-element-name=videorate
- property-name=rate
- property-value=2
)
? Action `set-property` at change_rate_reverse_playback.validatetest:42 done 'OK' (duration: 0:00:00.000194496)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:43 [repeat=0/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:43 done 'OK' [0/10] (duration: 0:00:00.000058749)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:43 [repeat=1/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:43 done 'OK' [1/10] (duration: 0:00:00.027939974)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:43 [repeat=2/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:43 done 'OK' [2/10] (duration: 0:00:00.035776879)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:43 [repeat=3/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:43 done 'OK' [3/10] (duration: 0:00:00.007801448)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:43 [repeat=4/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:43 done 'OK' [4/10] (duration: 0:00:00.007349206)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:43 [repeat=5/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:43 done 'OK' [5/10] (duration: 0:00:00.006430972)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:43 [repeat=6/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:43 done 'OK' [6/10] (duration: 0:00:00.003889225)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:43 [repeat=7/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:43 done 'OK' [7/10] (duration: 0:00:00.003849100)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:43 [repeat=8/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:43 done 'OK' [8/10] (duration: 0:00:00.003219236)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:43 [repeat=9/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:43 done 'OK' [9/10] (duration: 0:00:00.003205403)
Executing `wait` at change_rate_reverse_playback.validatetest:44 (
- on-clock=true
)
? Action `wait` at change_rate_reverse_playback.validatetest:44 done 'OK' (duration: 0:00:00.001707720)
Executing `checkpoint` at change_rate_reverse_playback.validatetest:47 (
- text="Filling\ up\ segment\ with\ last\ buffer"
)
? Action `checkpoint` at change_rate_reverse_playback.validatetest:47 done 'OK' (duration: 0:00:00.000100665)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:48 [repeat=0/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:48 done 'OK' [0/10] (duration: 0:00:00.000188997)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:48 [repeat=1/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:48 done 'OK' [1/10] (duration: 0:00:00.005131411)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:48 [repeat=2/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:48 done 'OK' [2/10] (duration: 0:00:00.002966824)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:48 [repeat=3/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:48 done 'OK' [3/10] (duration: 0:00:00.002859200)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:48 [repeat=4/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:48 done 'OK' [4/10] (duration: 0:00:00.002367584)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:48 [repeat=5/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:48 done 'OK' [5/10] (duration: 0:00:00.002356959)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:48 [repeat=6/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:48 done 'OK' [6/10] (duration: 0:00:00.002005590)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:48 [repeat=7/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:48 done 'OK' [7/10] (duration: 0:00:00.001805386)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:48 [repeat=8/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:48 done 'OK' [8/10] (duration: 0:00:00.001839926)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:48 [repeat=9/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:48 done 'OK' [9/10] (duration: 0:00:00.001235687)
<position: 0:00:00.000000000 duration: 99:99:99.999999999 speed: -1.000000 />
<position: 0:00:00.000000000 duration: 99:99:99.999999999 speed: -1.000000 />
Executing `stop` at change_rate_reverse_playback.validatetest:50 (
- on-message=eos
)
? Action `stop` at change_rate_reverse_playback.validatetest:50 done 'OK' (duration: 0:00:00.000257954)
change_rate_reverse_playback.validatetest --> State change request NULL, quitting mainloop
validateflowoverride0 --> Checking that flow /home/buildroot/gstreamer/subprojects/gst-plugins-base/tests/validate/videorate/change_rate_reverse_playback/flow-expectations/log-videorate-sink-expected matches expected flow /home/buildroot/gstreamer/build/subprojects/gst-plugins-base/tests/validate/validate.videorate.change_rate_reverse_playback/change_rate_reverse_playback/log-videorate-sink-actual
validateflowoverride0 --> OK
validateflowoverride1 --> Checking that flow /home/buildroot/gstreamer/subprojects/gst-plugins-base/tests/validate/videorate/change_rate_reverse_playback/flow-expectations/log-videorate-src-expected matches expected flow /home/buildroot/gstreamer/build/subprojects/gst-plugins-base/tests/validate/validate.videorate.change_rate_reverse_playback/change_rate_reverse_playback/log-videorate-src-actual
validateflowoverride1 --> OK
warning : a serialized event received should be pushed in the same 'time' as it was received
Detected on <videorate:src>
Description : serialized events should be pushed in the same order they are received and serialized with buffers. If an event is received after a buffer with timestamp end 'X', it should be pushed right after buffers with timestamp end 'X'
critical : We got a g_log critical issue
Detected on <pipeline0>
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
dotfile : no dotfile produced as GST_DEBUG_DUMP_DOT_DIR is not set.
backtrace :
gst_debug_get_stack_trace (gstinfo.c:3234)
gst_validate_report_new (gst-validate-report.c:921)
gst_validate_report_valist (gst-validate-reporter.c:189)
gst_validate_report (gst-validate-reporter.c:323)
g_logv (/usr/lib/libglib-2.0.so.0.7200.2:0xffff5027b16c)
g_log (/usr/lib/libglib-2.0.so.0.7200.2:0xffff5027b414)
gst_event_new_qos (gstevent.c:1219)
gst_video_rate_src_event (gstvideorate.c:1025)
gst_validate_pad_monitor_src_event_func (gst-validate-pad-monitor.c:2192)
gst_pad_send_event_unchecked (gstpad.c:5897)
gst_pad_push_event_unchecked (gstpad.c:5541)
gst_pad_push_event (gstpad.c:5678)
gst_base_sink_chain_unlocked.constprop.0 (gstbasesink.c:2927)
gst_base_sink_chain_main (gstbasesink.c:4078)
gst_validate_pad_monitor_chain_func (gst-validate-pad-monitor.c:2348)
gst_pad_chain_data_unchecked (gstpad.c:4444)
gst_pad_push_data (gstpad.c:4708)
gst_pad_push (gstpad.c:4827)
gst_video_rate_transform_ip (gstvideorate.c:1718)
default_generate_output (gstbasetransform.c:2187)
gst_base_transform_chain (gstbasetransform.c:2345)
gst_validate_pad_monitor_chain_func (gst-validate-pad-monitor.c:2348)
gst_pad_chain_data_unchecked (gstpad.c:4444)
gst_pad_push_data (gstpad.c:4708)
gst_pad_push (gstpad.c:4827)
gst_base_transform_chain (gstbasetransform.c:2381)
gst_validate_pad_monitor_chain_func (gst-validate-pad-monitor.c:2348)
gst_pad_chain_data_unchecked (gstpad.c:4444)
gst_pad_push_data (gstpad.c:4708)
gst_pad_push (gstpad.c:4827)
gst_base_src_loop (gstbasesrc.c:3030)
gst_task_func (gsttask.c:384)
?? (/usr/lib/libglib-2.0.so.0.7200.2:0xffff502a4650)
?? (/usr/lib/libglib-2.0.so.0.7200.2:0xffff502a37a8)
?? (/usr/lib/libc.so.6:0xffff4fdf0ae8)
?? (/usr/lib/libc.so.6:0xffff4fe5a5d8)
Issues found: 37
Returning 18 as errors were found
=======> Test FAILED (Return value: 18)
not ok 1 /home/buildroot/gstreamer/subprojects/gst-plugins-base/tests/validate/videorate/change_rate_reverse_playback.validatetest Got a critical report
```
[change_rate_reverse_playback-stderr.log](/uploads/9411b8c63cb5c72e2a3d3735eb3bb551/change_rate_reverse_playback-stderr.log)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1288Unsafe eglimage cache usage in gstglupload.c in combination with tee2022-06-17T06:57:29ZErik De RijckeUnsafe eglimage cache usage in gstglupload.c in combination with tee`gstglupload.c` with tee calls `_set_cached_eglimage` and potentially frees the previously stored eglimage pointer, and later triggers critical warnings when the eglimage is unreffed again & potentially causes segfaults.
From gstreamer ...`gstglupload.c` with tee calls `_set_cached_eglimage` and potentially frees the previously stored eglimage pointer, and later triggers critical warnings when the eglimage is unreffed again & potentially causes segfaults.
From gstreamer irc:
```
00:55 < ndufresne> zubzub: ah, the cache is still not tee safe?
00:56 < ndufresne> We've fixed many cache over the time, so I can't remember if that one is still broken... But you can't cache on the buffer itself, that's not safe
```
Tested on gstreamer 1.20.1https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/104iOS GstPlay - Can't receive any signal2022-06-17T09:42:18ZbudainiOS GstPlay - Can't receive any signalI would like to use `GstPlay` to play some audio file from a remote URL. I can `play`, `pause`, `seek`..
I want to listen some event: `state_changed` ([see doc](https://gstreamer.freedesktop.org/documentation/play/gst-libs/gst/play/gstpl...I would like to use `GstPlay` to play some audio file from a remote URL. I can `play`, `pause`, `seek`..
I want to listen some event: `state_changed` ([see doc](https://gstreamer.freedesktop.org/documentation/play/gst-libs/gst/play/gstplay-types.html?gi-language=c#GstPlaySignalAdapter::state-changed))
I don't understand why don't receive any signal:
My code:
```
static GstPlaySignalAdapter *adapter;
-(instancetype)init {
self = [super init];
if (!monoPlayer) {
[self configurePlayer];
}
return self;
}
-(void)configurePlayer {
GstreamerConfiguration(); // Like gst_ios_init
player = gst_play_new(NULL);
adapter = gst_play_signal_adapter_new(player);
gst_play_config_set_seek_accurate(gst_play_get_config(player), true);
[self configureCallBacks];
}
-(void)configureCallBacks {
NSLog(@"---- callllled");
g_signal_connect (adapter, "state-changed", G_CALLBACK(stateChangedCb), NULL);
}
void stateChangedCb (GstPlaySignalAdapter *adapter, GstPlayState *state, void *data) {
NSLog(@"---- NEW STATE");
// gst_print ("State changed: %s\n", gst_play_state_get_name (state));
}
```
I use GStreamer `1.20.2`https://gitlab.freedesktop.org/gstreamer/gstreamer-sharp/-/issues/63gstreamer-sharp: An unhandled exception of type 'System.Exception' occurred i...2022-06-20T15:13:19ZConnor Hawesgstreamer-sharp: An unhandled exception of type 'System.Exception' occurred in GLibSharp.dll Unknown type GstRTSPMessageCurrently trying to handle the before-send rtspsrc signal in order to add headers to RTSP messages.
Upon the handler being triggered the titular message is thrown.
Here is my current handler:
`
private void BeforeSendCb(object s...Currently trying to handle the before-send rtspsrc signal in order to add headers to RTSP messages.
Upon the handler being triggered the titular message is thrown.
Here is my current handler:
`
private void BeforeSendCb(object sender, SignalArgs args)
{
Gst.Rtsp.RTSPMessage message = (Gst.Rtsp.RTSPMessage)args.Args[0];
message.AddHeader(Gst.Rtsp.RTSPHeaderField.CompanyId, "CONNOR HAWES");
Trace.WriteLine("BREAK HERE");
}
`
And the subscription:
`
_rtspsrc.Connect("before-send", BeforeSendCb);
`
I was wondering if I was doing anything wrong or if there is a workaround?
Thanks in advancehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1290gstreamer-sharp: Gst.Application requires WebRTC (gst-plugins-bad) by default2022-06-17T23:28:41ZPedro Castrogstreamer-sharp: Gst.Application requires WebRTC (gst-plugins-bad) by defaultThe static constructor in Gst.Application registers WebRTC by default:
```csharp
GLib.GType.Register(Gst.WebRTC.WebRTCSessionDescription.GType, typeof(Gst.WebRTC.WebRTCSessionDescription));
```
This implies that `gst-plugins-bad`, whic...The static constructor in Gst.Application registers WebRTC by default:
```csharp
GLib.GType.Register(Gst.WebRTC.WebRTCSessionDescription.GType, typeof(Gst.WebRTC.WebRTCSessionDescription));
```
This implies that `gst-plugins-bad`, which contains WebRTC, will be required to run gstreamer-sharp.
Wondering if this was a design decision. I've switched to gstreamer-sharp in Gnome Subtitles and WebRTC isn't used, so would rather prefer not to force users to install plugins-bad unnecessarily.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1291tsdemux: tsdemux produces buffers with no PTS/DST when ignoring PCR.2022-10-20T06:20:12Zazerowalltsdemux: tsdemux produces buffers with no PTS/DST when ignoring PCR.GStreaemer version: 1.20.2
File: [euronews.ts](/uploads/226e3c7b9622e4d43eacc0fa11f3e04c/euronews.ts)
Pipeline:
```
filesrc location=euronews.ts ! tsdemux ignore-pcr=true name=dem \
mpegtsmux name=mux \
dem. ! queue ! video/mpeg ! mpeg...GStreaemer version: 1.20.2
File: [euronews.ts](/uploads/226e3c7b9622e4d43eacc0fa11f3e04c/euronews.ts)
Pipeline:
```
filesrc location=euronews.ts ! tsdemux ignore-pcr=true name=dem \
mpegtsmux name=mux \
dem. ! queue ! video/mpeg ! mpegvideoparse ! mux. \
mux. ! filesink location=out.ts sync=false
```
But if I stream the same file via UDP, then timestamps exist:
```
udpsrc uri=udp://239.1.1.1:1234 do-timestamp=false ! tsdemux ignore-pcr=true name=dem \
mpegtsmux name=mux \
dem. ! queue ! video/mpeg ! mpegvideoparse ! mux. \
mux. ! filesink location=out.ts sync=false
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1295qtdemux: Unexpected segment end detected (EOS) in push mode (live stream, fmp4)2022-06-21T08:59:01ZAndrzej Surdejqtdemux: Unexpected segment end detected (EOS) in push mode (live stream, fmp4)### Describe your issue
The original issue comes from Vevo application live video playback that is interrupted by unexpected EOS (end of segment) detected from qtdemux. The issue exists with push mode only (pull mode doesn't detect EOS i...### Describe your issue
The original issue comes from Vevo application live video playback that is interrupted by unexpected EOS (end of segment) detected from qtdemux. The issue exists with push mode only (pull mode doesn't detect EOS in my case).
The init segment contains duration of 1min(60sec) and with each moof it is extended with "timestamp" (from qtdemux_parse_trun() func) that is fragment decode time (tfdt) or sample dts and the sum of all samples duration. With such calculations the segment stop time is expressed in dts timeline.
Then processing the data (gst_qtdemux_process_adapter() -> QTDEMUX_STATE_MOVIE) tries to detect the end of segment based on PTS value for each frame that is higher value than dts and passes segment stop time:
` /* check for segment end */
if (G_UNLIKELY (demux->segment.stop != -1
&& demux->segment.stop <= pts && stream->on_keyframe)
&& !(demux->upstream_format_is_time && demux->segment.rate < 0)) {
GST_DEBUG_OBJECT (demux, "we reached the end of our segment.");
stream->time_position = GST_CLOCK_TIME_NONE; /* this means EOS */
`
The issue is barely visible because of additional "on_keyframe" check that suppose to cut segment on keyframes only (so the decoder has all data needed).
The difference why I hit this issue is that my stream has more keyframes (couple in single fragment/moof/mdat) and the EOS is thrown before reaching the end acutually (like 3 samples earlier, depending on dts<->pts shift)
#### Expected Behavior
Video playback should continue without EOS detected
#### Observed Behavior
EOS is thrown from qtdemux and the playback is stopped.
#### Setup
- **Operating System:** Ubuntu 20.04
- **Device:** Computer
- **GStreamer Version:** GStreamer 1.16.2 and GStreamer 1.21.0 (GIT)
- **Command line:** GST_DEBUG="qtdemux:5,2" gst-launch-1.0 pushfilesrc location=<path>/video_8 ! qtdemux ! appsink
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
0. Fetch attached video sample (dump from VEVO live channel): [video_8](/uploads/7a80e18f1686084f21cafb6578ef3bf8/video_8)
1. open terminal
3. type `GST_DEBUG="qtdemux:5,2" gst-launch-1.0 pushfilesrc location=<path>/video_8 ! qtdemux ! appsink`
4. Parsing ends with EOS thrown from qtdemux -> segment end detected
### How reproducible is the bug?
Always
### Screenshots if relevant
### Solutions you have tried
The solution for this case would be to replace PTS with DTS when checking for the segment stop. It would make EOS detection more reliable and based on the same timestamp values. This however may interrupt seeking with stop time set (as it's PTS based I believe).
### Related non-duplicate issues
### Additional Information
I have more dumps from the same content if neededhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1299souphttpsrc unable to parse response2022-11-10T09:21:14ZSzymon Mikuliczsouphttpsrc unable to parse response### Describe your issue
I am unable to open any http stream using souphttpsrc (I noticed it while trying to use mopidy)
#### Expected Behavior
The stream starts to play
#### Observed Behavior
With proxy ON: I get "Unable to parse respo...### Describe your issue
I am unable to open any http stream using souphttpsrc (I noticed it while trying to use mopidy)
#### Expected Behavior
The stream starts to play
#### Observed Behavior
With proxy ON: I get "Unable to parse response"<br>
With proxy OFF: Crash (SIGABRT)
#### Setup
- **Operating System:** Fedora 36
- **Device:** Computer
- **GStreamer Version:** 1.20
### Steps to reproduce the bug
`gst-launch-1.0 -v souphttpsrc method='get' location='https://www.soundhelix.com/examples/mp3/SoundHelix-Song-1.mp3' ! decodebin ! audioconvert ! autoaudiosink`
### How reproducible is the bug?
Always
### Additional Information
Logs attached for proxy/noproxy cases
[gst_proxy.log](/uploads/e42233bfc73b4c7190b6bd3aa4544bdc/gst_proxy.log)
[gst_noproxy.log](/uploads/5714bd0016800ac61408fb1f24fc49ab/gst_noproxy.log)https://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/99Dynamic removing webrtcbin from GstTee cause total pipeline paused2022-06-24T10:48:46ZZhuChaselDynamic 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:
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/gstreamer/-/issues/1303Dynamic removing webrtcbin from GstTee cause total pipeline paused2022-11-10T09:21:14ZZhuChaselDynamic 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:
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/gstreamer/-/issues/1305dashsink creates avc / opus fragments that are unplayable in ffmpeg2022-06-29T06:05:49ZWojciech Kapsadashsink creates avc / opus fragments that are unplayable in ffmpeg### Describe your issue
```
gst-launch-1.0 -e dashsink muxer=mp4 target-duration=6 name=dashsink audiotestsrc is-live=true ! opusenc ! dashsink.audio_0 videotestsrc is-live=true ! x264enc ! dashsink.video_0
```
creates only the first a...### Describe your issue
```
gst-launch-1.0 -e dashsink muxer=mp4 target-duration=6 name=dashsink audiotestsrc is-live=true ! opusenc ! dashsink.audio_0 videotestsrc is-live=true ! x264enc ! dashsink.video_0
```
creates only the first audio and video chunks which are playable. Rest of them are empty.
This MR !1722 fixes empty chunks creation but all chunks are not playable in ffmpeg:
```
[h264 @ 0x7f60342808d0] Invalid NAL unit size (1835295092 > 1439).
[h264 @ 0x7f60342808d0] Error splitting the input into NAL units.
[h264 @ 0x7f603429c4b0] Invalid NAL unit 0, skipping.
Last message repeated 44 times
[h264 @ 0x7f603429c4b0] Invalid NAL unit size (1835295092 > 1179).
[h264 @ 0x7f603429c4b0] Error splitting the input into NAL units.
```
Created dash.mpd plays fine in gst-play-1.0.
#### Setup
- Ubuntu 20.04
- GStreamer Version: mainhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1307SYNC/ASYNC KLV support2023-03-31T06:56:14ZAlex CSYNC/ASYNC KLV supportHi guys,
I'm having trouble trying to play files with **SYNC KLV**. Video freezes on the first frame (with any sync klv file I tried).
Here are two identical files, except that the first one has ASYNC KLV and the second one has a SYNC ...Hi guys,
I'm having trouble trying to play files with **SYNC KLV**. Video freezes on the first frame (with any sync klv file I tried).
Here are two identical files, except that the first one has ASYNC KLV and the second one has a SYNC KLV:
- [test-klv-async.ts](https://1drv.ms/v/s!AgXQnBFeIFXX43QMaRfdwIiszPgp?e=UCjzI0)
- [test-klv-sync.ts](https://1drv.ms/v/s!AgXQnBFeIFXX43WMFJuKqpB74Pb4?e=uvgTZM)
Here is a simplified pipeline:
`gst-launch-1.0 filesrc location=C:/Movie/test-klv-sync.ts ! tsdemux name=demux demux. ! queue ! h264parse ! avdec_h264 ! videoconvert ! autovideosink demux. ! queue ! meta/x-klv ! fakesink dump=true`
File with ASYNC KLV will play just fine, but the sync one will freeze on the first frame. I tried many things (gst-launch and code)... Nothing helps. It doesn't work with any GStreamer version.
I saw some discussions on this (and of course, I know that ASYNC and SYNC Klv have different descriptors - all [the relevant info here](https://impleotv.com/2017/02/17/klv-encoded-metadata-in-stanag-4609-streams/)).
How can I solve this? Is there any way to pass something different instead of meta/x-klv so I could get binary KLV data?
Thanks,
Alexhttps://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/392Add support for GstD3D11 binding2022-06-28T20:56:20ZSeungha Yangseungha@centricular.comAdd support for GstD3D11 binding`Direct3D` is the primary graphics and multimedia API on Windows, a kind of OpenGL/Vulkan + VAAPI/NVCODEC + window system (e.g., x11/wayland) + etc (some OS layer optimized features, screen capturing for example).
Now `GstD3D11` is a pu...`Direct3D` is the primary graphics and multimedia API on Windows, a kind of OpenGL/Vulkan + VAAPI/NVCODEC + window system (e.g., x11/wayland) + etc (some OS layer optimized features, screen capturing for example).
Now `GstD3D11` is a public library (but still experimental) in GStreamer term. So, adding support for `GstD3D11` binding would be greathttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1313gstwebrtcbin.c: retransmissions work with bundle-policy=max-bundle but not wi...2023-01-06T03:29:42ZMarkus Pollakgstwebrtcbin.c: retransmissions work with bundle-policy=max-bundle but not with default bundle-policyHello,
I've found a bug in gstwebrtcbin.c (https://github.com/GStreamer/gst-plugins-bad/blob/master/ext/webrtc/gstwebrtcbin.c) which causes retransmissions (RTX for NACKs) to not work in common scenarios. I've also found the root cause ...Hello,
I've found a bug in gstwebrtcbin.c (https://github.com/GStreamer/gst-plugins-bad/blob/master/ext/webrtc/gstwebrtcbin.c) which causes retransmissions (RTX for NACKs) to not work in common scenarios. I've also found the root cause and provide a detailed explanation:
**Setup:**
- Gstreamer installation based on restreamio/gstreamer:1.19.2.0-prod Docker image
- do-nack is set to true at the transceiver (fec-type is not set as I'm testing retransmissions only)
- gst1-java-core:1.4.0 is used to build up the pipeline
- Gstreamer is used to send a video stream (video only, no audio, send-only) to Chrome
- A range of multiple video source is used (rtspsrc, srtsrc, videotestsrc, ...)
- Chrome on Windows is used for receiving a video-stream via WebRTC
- H264 encoding (baseline and high profile) is used in different cases
- Clumsy is used for simulating packet loss (client-side)
**SDPs:**
The SDPs are correctly mentioning nack and rtx and pt mappings seem to be correct.
**SDP Offer:**
```
v=0
o=- 8338404406669528263 0 IN IP4 0.0.0.0
s=-
t=0 0
a=ice-options:trickle
m=video 9 UDP/TLS/RTP/SAVPF 97 96
c=IN IP4 0.0.0.0
a=setup:actpass
a=ice-ufrag:qt8YBq9p6brgGFJPTcOEZnpzNuGGaiZc
a=ice-pwd:IUzbx6zU7c1cAEpr9v8pUd8fQX4WMWc4
a=rtcp-mux
a=rtcp-rsize
a=sendonly
a=rtpmap:97 H264/90000
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 transport-cc
a=framerate:25
a=fmtp:97 packetization-mode=1;profile-level-id=4d001f;sprop-parameter-sets=Z00AH5Y1QKALdNwEBAUAAAcIAAFfkAQ=,aO48gA==
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=97
a=ssrc-group:FID 2 876927395
a=ssrc:2 msid:user73081093@host-10bea89f webrtctransceiver4
a=ssrc:2 cname:user73081093@host-10bea89f
a=ssrc:876927395 msid:user73081093@host-10bea89f webrtctransceiver4
a=ssrc:876927395 cname:user73081093@host-10bea89f
a=mid:video0
a=fingerprint:sha-256 5A:BB:64:EB:DA:4C:59:AE:25:97:46:BA:18:BC:67:A1:8A:8B:30:15:B0:D3:F0:21:7C:43:95:79:DA:EA:66:25
a=rtcp-mux-only
```
**SDP Answer:**
```
v=0
o=- 9170499300271825649 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic: WMS
m=video 9 UDP/TLS/RTP/SAVPF 97 96
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:eFrN
a=ice-pwd:8X4CVq0UQPKCyHgT9Mt+ArfF
a=ice-options:trickle
a=fingerprint:sha-256 9E:43:31:2F:55:64:63:76:53:B8:35:F9:9B:B9:AD:71:04:95:E2:F9:2A:66:71:2D:64:B0:26:42:E8:4D:CD:73
a=setup:active
a=mid:video0
a=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:97 H264/90000
a=rtcp-fb:97 transport-cc
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=fmtp:97 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d001f
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=97
```
I can see that NACKs are sent by Chrome via chrome://webrtc-internals
The NACK count is increasing when packets are lost.
So far so good, but the retransmissions through Gstreamer don't work yet.
**I've debugged it and finally found the reason in gstwebrtcbin.c:**
on_rtpbin_request_aux_sender calls _set_rtx_ptmap_from_stream (webrtc, stream) after creating the rtprtxsend (rtx = gst_element_factory_make ("rtprtxsend", NULL)) while stream->rtxsend has not yet been set.
It's basically set at the end of on_rtpbin_request_aux_sender: stream->rtxsend = gst_object_ref (rtx);
I can verify that _set_rtx_ptmap_from_stream is called only once while rtprtxsend is null via the logs (GST_DEBUG='3,rtprtx*:5,webrtc*:6'):
```
0:01:19.678286676 6 0x7fd1c42d7060 DEBUG webrtcbin gstwebrtcbin.c:4313:_set_rtx_ptmap_from_stream:<transportstream0> setting payload map on (NULL) : (NULL) and application/x-rtp-pt-map, 97=(uint)96;
```
The following logs show that the retransmissions triggered by NACKs are not working:
```
0:01:19.679474693 6 0x7fd1c53bc700 WARN rtprtxsend gstrtprtxsend.c:655:gst_rtp_rtx_send_sink_event:<rtprtxsend0> Payload 97 not in rtx-pt-map
```
and
```
0:08:28.606424318 6 0x7fd1a1176c60 DEBUG rtprtxsend gstrtprtxsend.c:489:gst_rtp_rtx_send_src_event:<rtprtxsend0> got rtx request for seqnum: 31149, ssrc: 2
0:08:28.606434319 6 0x7fd1a1176c60 WARN rtprtxsend gstrtprtxsend.c:525:gst_rtp_rtx_send_src_event:<rtprtxsend0> requested seqnum 31149 has not been transmitted yet in the original stream; eithe
r the remote end is not configured correctly, or the source is too slow
0:08:28.606442719 6 0x7fd1a1176c60 DEBUG rtprtxsend gstrtprtxsend.c:489:gst_rtp_rtx_send_src_event:<rtprtxsend0> got rtx request for seqnum: 31150, ssrc: 2
0:08:28.606447819 6 0x7fd1a1176c60 WARN rtprtxsend gstrtprtxsend.c:525:gst_rtp_rtx_send_src_event:<rtprtxsend0> requested seqnum 31150 has not been transmitted yet in the original stream; eithe
r the remote end is not configured correctly, or the source is too slow
```
The lost packets are not received by Chrome too and the video stream starts freezing already at <5% packet loss.
This is problematic because _set_rtx_ptmap_from_stream only sets the "playload-type-map" if stream->rtxsend is set which is not the case:
```
if (stream->rtxreceive)
g_object_set (stream->rtxreceive, "payload-type-map", pt_map, NULL);
if (stream->rtxsend)
g_object_set (stream->rtxsend, "payload-type-map", pt_map, NULL);
```
A workaround is to use bundle-policy=max-bundle because in this case _set_rtx_ptmap_from_stream is called a second time from _update_transceiver_from_sdp_media:
```
if (!bundled || bundle_idx == media_idx) {
if (stream->rtxsend || stream->rtxreceive) {
_set_rtx_ptmap_from_stream (webrtc, stream);
}
g_object_set (stream, "dtls-client",
new_setup == GST_WEBRTC_DTLS_SETUP_ACTIVE, NULL);
}
```
**The workaround can be verified via logs too:**
The "payload-type-map" is set via _set_rtx_ptmap_from_stream at the second call (from _update_transceiver_from_sdp_media) with `stream->rtxsend` being not null:
```
0:01:11.110764316 7 0x7f9220b115e0 DEBUG webrtcbin gstwebrtcbin.c:4313:_set_rtx_ptmap_from_stream:<transportstream0> setting payload map on (NULL) : (NULL) and application/x-rtp-pt-map, 97=(uin
t)96;
0:01:11.111793531 7 0x7f9220b115e0 DEBUG webrtcbin gstwebrtcbin.c:4313:_set_rtx_ptmap_from_stream:<transportstream0> setting payload map on (NULL) : <rtprtxsend0> and application/x-rtp-pt-map,
97=(uint)96;
```
The requested packets are found and retransmitted:
```
0:02:35.661652056 7 0x7f91fc840d20 DEBUG rtprtxsend gstrtprtxsend.c:489:gst_rtp_rtx_send_src_event:<rtprtxsend0> got rtx request for seqnum: 45671, ssrc: 2
0:02:35.661658856 7 0x7f91fc840d20 DEBUG rtprtxsend gstrtprtxsend.c:405:gst_rtp_rtx_buffer_new:<rtprtxsend0> creating rtx buffer, orig seqnum: 45671, rtx seqnum: 58534, rtx ssrc: 851211DE
0:02:35.661680057 7 0x7f91fc840d20 DEBUG rtprtxsend gstrtprtxsend.c:489:gst_rtp_rtx_send_src_event:<rtprtxsend0> got rtx request for seqnum: 45672, ssrc: 2
0:02:35.661693457 7 0x7f91fc840d20 DEBUG rtprtxsend gstrtprtxsend.c:405:gst_rtp_rtx_buffer_new:<rtprtxsend0> creating rtx buffer, orig seqnum: 45672, rtx seqnum: 58535, rtx ssrc: 851211DE
0:02:35.661705557 7 0x7f91fc840d20 DEBUG rtprtxsend gstrtprtxsend.c:489:gst_rtp_rtx_send_src_event:<rtprtxsend0> got rtx request for seqnum: 45673, ssrc: 2
0:02:35.661715557 7 0x7f91fc840d20 DEBUG rtprtxsend gstrtprtxsend.c:405:gst_rtp_rtx_buffer_new:<rtprtxsend0> creating rtx buffer, orig seqnum: 45673, rtx seqnum: 58536, rtx ssrc: 851211DE
0:02:35.661726757 7 0x7f91fc840d20 DEBUG rtprtxsend gstrtprtxsend.c:489:gst_rtp_rtx_send_src_event:<rtprtxsend0> got rtx request for seqnum: 45674, ssrc: 2
```
Now the retransmission is working and the video stream is still stable at >20% packet loss.
I would appreciate if someone from the Gstreamer community could verify my bug report and fix it.
Thank you!
Best regards,
Markus Pollakhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1316Rename -bad2024-02-16T13:50:41ZPhilippe NormandRename -badFor years now people see -bad and think, oh this is bad, we must avoid it at all cost... This name is so misleading. What about -staging? Or something else that has no misleading meaning?For years now people see -bad and think, oh this is bad, we must avoid it at all cost... This name is so misleading. What about -staging? Or something else that has no misleading meaning?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1317plugin for 3d camera2022-07-05T09:17:05ZAlberto Fanjulplugin for 3d cameraI'm open this general issue to check if there's any solution to render a viewport from a 3d camera.
![Captura_desde_2022-07-05_10-52-01](/uploads/151a38eaa487daf3993870aba6a16727/Captura_desde_2022-07-05_10-52-01.png)
I'm playing with ...I'm open this general issue to check if there's any solution to render a viewport from a 3d camera.
![Captura_desde_2022-07-05_10-52-01](/uploads/151a38eaa487daf3993870aba6a16727/Captura_desde_2022-07-05_10-52-01.png)
I'm playing with gst-plugins-vr and it almost work:
https://github.com/lubosz/gst-plugins-vr/issues/19https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1319Choppy video when using mp4mux with udpsrc2022-07-06T22:11:54ZDavid GrinbergChoppy video when using mp4mux with udpsrcGStreamer version: 1.21.0, built from source - commit b233df3537a67c551d36c69796b05e8d27cf981e
Platform: Ubuntu 20.04 in Docker
I have these pipelines which i'm running on the same machine:
```
gst-launch-1.0 -e -v filesrc location=e...GStreamer version: 1.21.0, built from source - commit b233df3537a67c551d36c69796b05e8d27cf981e
Platform: Ubuntu 20.04 in Docker
I have these pipelines which i'm running on the same machine:
```
gst-launch-1.0 -e -v filesrc location=example_x264.mp4 do-timestamp=true ! qtdemux ! h264parse ! rtph264pay ! multiudpsink clients="127.0.0.1:$PORT"
```
```
gst-launch-1.0 -e udpsrc port=$PORT caps="application/x-rtp, encoding-name=(string)H264" ! rtpjitterbuffer mode=0 ! rtph264depay ! h264parse ! mp4mux ! filesink location=result.mp4
```
The problem is that when I use mp4mux the ```result.mp4``` file contains choppy and slowed video, but everything is fine if I use matroskamux instead.
What i've tried:
* Different latency properties on mp4mux and rtpjitterbuffer
* Replacing rtpjitterbuffer with queue/queue2 kinda helped - resulting video was choppy in one player and OK in VLC
Files attached:
![example_x264](/uploads/0f3ebfcc4ac4f5caaa8f233fc7a87034/example_x264.mp4)
![result](/uploads/dab5f2c83ad0bced8d2a19a54aa5b303/result.mp4)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1321RTP retransmission doesn't seem to be working with rtpbin2022-08-24T16:11:11ZAlireza MiryazdiRTP retransmission doesn't seem to be working with rtpbin### Describe your issue
Activating RTP re-transmission still produces choppy output, even while using the example from the [doc](https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good/html/gst-plugins-good-plugins-rtp...### Describe your issue
Activating RTP re-transmission still produces choppy output, even while using the example from the [doc](https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good/html/gst-plugins-good-plugins-rtprtxqueue.html).
I used it with audio (`audiotestsrc`) and video (`videotestsrc pattern=ball`) and was unsuccessful with both.
#### Expected Behavior
Smooth video/audio
#### Observed Behavior
Audio/video has noticeable choppiness
#### Setup
- Run both on Void Linux(musl - GStreamer 1.20.3) and Windows 10(x64 - GStreamer version 1.20.2)
### Steps to reproduce the bug
Run both these commands in 2 terminals. I also tried running the server in an external VPS and still had the issue.
__Server__:
```
gst-launch-1.0 rtpbin -v name=b rtp-profile=avpf audiotestsrc is-live=true ! opusenc ! rtpopuspay pt=96 ! rtprtxqueue ! b.send_rtp_sink_0 b.send_rtp_src_0 ! udpsink host=127.0.0.1 port=5000 udpsrc port=5001 ! b.recv_rtcp_sink_0 b.send_rtcp_src_0 ! udpsink host=127.0.0.1 port=5002 sync=false async=false
```
__Client__:
```
gst-launch-1.0 rtpbin -v name=b rtp-profile=avpf do-retransmission=true udpsrc port=5000 caps="application/x-rtp,media=(string)audio,clock-rate=(int)48000,encoding-name=(string)OPUS,payload=(int)96" ! netsim drop-probability=0.15 ! b.recv_rtp_sink_0 b. ! rtpopusdepay ! opusdec ! audioconvert ! audioresample ! autoaudiosink udpsrc port=5002 ! b.recv_rtcp_sink_0 b.send_rtcp_src_0 ! udpsink host="127.0.0.1" port=5001 sync=false async=false
```
Any guidance would be greatly appreciated. Thank you for your time.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2785`rtph264depay` element doesn’t handle multiple NALs in a FU as well as VLC an...2023-07-08T10:00:44ZEric Chandrasekhar`rtph264depay` element doesn’t handle multiple NALs in a FU as well as VLC and ffmpegI work for IPConfigure, a video management software company that heavily relies on GStreamer for streaming utilities.
We’ve recently come across an issue when using the `rtph264depay` element while streaming H.264 from one of our camera...I work for IPConfigure, a video management software company that heavily relies on GStreamer for streaming utilities.
We’ve recently come across an issue when using the `rtph264depay` element while streaming H.264 from one of our camera vendors.
When streaming from this camera, no buffers containing I-Frames are pushed out of the rtph264depay element, resulting in corrupted output video. This was strange, as both FFmpeg and VLC display the video fine.
Digging further into what was going on, we discovered the camera fragments multiple NAL units over several RTP packets. Here is a screenshot of wireshark capture when streaming from this camera:
![Screenshot_from_2022-07-06_15-08-21](/uploads/9b191c3d047f9dacb25b58e69c21b383/Screenshot_from_2022-07-06_15-08-21.png)
As seen above, there are multiple NAL units all within the same fragmentation unit, with the final NAL unit of this initial FU, the I-frame, continuing into the next 30 FUs. These NAL units are separated by Annex-B startcodes.
From RFC 6184 (RTP Payload format for H.264 Video), _fragmentation is defined only for a single NAL unit_, which means this camera is not abiding by the RFC.
The rtph264depay element is extracting the initial nal type of 7 (SPS) at the start of the FU, and storing that entire assembled FU as SPS data, when really that buffer contains multiple different NALs including an I-Frame.
Both VLC and FFmpeg support this stream despite the fact that it is non-RFC-compliant. Are there any preferred ways to get GStreamer to handle this situation similarly, and if not, would it be feasible for us to submit a patch that increases this element’s flexibility?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1322Unknown SDP type in python bindings (maybe memory corruption)2022-07-08T03:31:26Zle-chatUnknown SDP type in python bindings (maybe memory corruption)Webrtcbin on create-answer returns WebRTCSessionDescription with unknown WebRTCSDPType (enum value varies at each run) and empty SDP when used as
```python
answer = promise.get_reply().get_value("answer")
```
Though all right if split th...Webrtcbin on create-answer returns WebRTCSessionDescription with unknown WebRTCSDPType (enum value varies at each run) and empty SDP when used as
```python
answer = promise.get_reply().get_value("answer")
```
Though all right if split this to two lines
```python
reply = promise.get_reply()
answer = reply.get_value("answer")
```
Full script is here: https://gist.github.com/le-chat/f0aa4222b5a978446ce937ac59341ba8#file-test-py
And logs are in https://gist.github.com/le-chat/f0aa4222b5a978446ce937ac59341ba8#file-log-txt
Tested on Ubuntu 22.04 (gstreamer 1.20.1, python 3.10) and NixOS 22.05 (gstreamer 1.20.1, python 3.9).
Expected behaviour: get WebRTCSessionDescription with WebRTCSDPType=ANSWER and some SDP.
Observed behaviour: got WebRTCSessionDescription with WebRTCSDPType=unknown random-looking integer and sdp=None.
To reproduce with Nix:
```
git clone https://gist.github.com/f0aa4222b5a978446ce937ac59341ba8.git gst-python-bug-report
cd gst-python-bug-report
nix-shell --run "python test.py"
```
Thanks to Matthew Waters who guess the workaround in https://lists.freedesktop.org/archives/gstreamer-devel/2022-July/080197.html