GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T14:36:50Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/845wpesrc: SIGABRT in linux_dmabuf_setup2021-09-24T14:36:50ZMathieu Duponchellewpesrc: SIGABRT in linux_dmabuf_setup[stack.txt](/uploads/d3ad39567c535c0ea0839559ae3a4f77/stack.txt)
I get this when running the example pipeline (`gst-launch-1.0 -v wpesrc location="https://gstreamer.freedesktop.org" ! queue ! glimagesink`), @philn let me know if you nee...[stack.txt](/uploads/d3ad39567c535c0ea0839559ae3a4f77/stack.txt)
I get this when running the example pipeline (`gst-launch-1.0 -v wpesrc location="https://gstreamer.freedesktop.org" ! queue ! glimagesink`), @philn let me know if you need more info :)Philippe NormandPhilippe Normandhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/851Encodebin? regression: WMV transcoding in Rygel does not work anymore2021-09-24T13:26:11ZJens GeorgEncodebin? regression: WMV transcoding in Rygel does not work anymoreIt looks like the transcoding to WMV in Rygel has stopped working somewhere between 1.14.5 (Ubuntu 18.04, works) and 1.18 (Ubuntu 20.04 and later, stopped working).
I'm not sure where exactly the problem lies or if that's even a change ...It looks like the transcoding to WMV in Rygel has stopped working somewhere between 1.14.5 (Ubuntu 18.04, works) and 1.18 (Ubuntu 20.04 and later, stopped working).
I'm not sure where exactly the problem lies or if that's even a change in behavior in GStreamer that I need to adapt to, I start at the toplevel, encodebin. Please move accordingly if unfitting.
Test input used: https://upload.wikimedia.org/wikipedia/commons/b/b3/Big_Buck_Bunny_Trailer_400p.ogv
Example program is attached [encode.c](/uploads/c200600601b02f96bd1977487949fda6/encode.c)
Pipeline on 1.18: ![foo](/uploads/6e295b0b787b7eaab5e5282aa232f7d3/foo.png)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/790elements_shm.test_shm_live: Sometimes times out2022-11-10T09:21:08ZSebastian Drögeelements_shm.test_shm_live: Sometimes times out```
check.gst-plugins-bad.elements_shm.test_shm_live: Failed 'Application returned 1'
You can reproduce with: GST_CHECKS='test_shm_live' GST_PLUGIN_SYSTEM_PATH_1_0='' GST_PLUGIN_PATH_1_0='/builds/gstreamer/gst-plugins-good/gst-bui...```
check.gst-plugins-bad.elements_shm.test_shm_live: Failed 'Application returned 1'
You can reproduce with: GST_CHECKS='test_shm_live' GST_PLUGIN_SYSTEM_PATH_1_0='' GST_PLUGIN_PATH_1_0='/builds/gstreamer/gst-plugins-good/gst-build/build' CK_DEFAULT_TIMEOUT='20' GST_REGISTRY='/builds/gstreamer/gst-plugins-good/gst-build/build/subprojects/gst-plugins-bad/tests/check/elements_shm.registry' GST_STATE_IGNORE_ELEMENTS='' /builds/gstreamer/gst-plugins-good/gst-build/build/subprojects/gst-plugins-bad/tests/check/elements_shm
Dumping log files on failure
Dumping contents of /builds/gstreamer/gst-plugins-good/validate-output/logs/check/gst-plugins-bad/elements_shm/test_shm_live
=================
Test name: check.gst-plugins-bad.elements_shm.test_shm_live
Command: '/builds/gstreamer/gst-plugins-good/gst-build/build/subprojects/gst-plugins-bad/tests/check/elements_shm'
=================
Running suite(s): shm
0%: Checks: 1, Failures: 0, Errors: 1
../subprojects/gst-plugins-bad/tests/check/elements/shm.c:219:E:shm2:test_shm_live:0: (after this point) Test timeout expired
Check suite shm ran in 20.002s (tests failed: 1)
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/853textoverlay: shaded-background works on some systems but not on others2021-09-24T13:26:11ZAndy Robinsontextoverlay: shaded-background works on some systems but not on othersThe following pipeline:
gst-launch-1.0 \
textoverlay name=ov shaded-background=true ! autovideosink \
filesrc location=my-video.mp4 ! decodebin ! videoconvert ! videoscale ! ov.video_sink \
filesrc location=Test.srt ! subparse ...The following pipeline:
gst-launch-1.0 \
textoverlay name=ov shaded-background=true ! autovideosink \
filesrc location=my-video.mp4 ! decodebin ! videoconvert ! videoscale ! ov.video_sink \
filesrc location=Test.srt ! subparse ! ov.text_sink
[Test.srt](/uploads/54e37d6212a671370ffc60f3c283ece7/Test.srt)
produces a shaded background for the subtitles on some systems:
1.14.5 on Linux 64-bit
<br>1.14.2 on Windows 10 32-bit
and not on others:
1.14.2 on Mac Big Sur
<br>1.18.2 on Mac Big Sur
<br>1.18.2 on Windows 10 32-bithttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2774scaletempo: does not support instant rate change2023-07-06T11:06:08Zrlandjscaletempo: does not support instant rate changeATTATThttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/792elements_netsim.netsim_stress: Sometimes fails with "Got data flow before str...2021-10-12T20:09:52ZSebastian Drögeelements_netsim.netsim_stress: Sometimes fails with "Got data flow before stream-start event"```
check.gst-plugins-bad.elements_netsim.netsim_stress: Failed 'Application returned 1'
You can reproduce with: GST_STATE_IGNORE_ELEMENTS='' GST_CHECKS='netsim_stress' GST_PLUGIN_SYSTEM_PATH_1_0='' CK_DEFAULT_TIMEOUT='20' GST_REG...```
check.gst-plugins-bad.elements_netsim.netsim_stress: Failed 'Application returned 1'
You can reproduce with: GST_STATE_IGNORE_ELEMENTS='' GST_CHECKS='netsim_stress' GST_PLUGIN_SYSTEM_PATH_1_0='' CK_DEFAULT_TIMEOUT='20' GST_REGISTRY='/builds/tpm/gst-plugins-bad/gst-build/build/subprojects/gst-plugins-bad/tests/check/elements_netsim.registry' GST_PLUGIN_PATH_1_0='/builds/tpm/gst-plugins-bad/gst-build/build' /builds/tpm/gst-plugins-bad/gst-build/build/subprojects/gst-plugins-bad/tests/check/elements_netsim
Dumping log files on failure
Dumping contents of /builds/tpm/gst-plugins-bad/validate-output/logs/check/gst-plugins-bad/elements_netsim/netsim_stress
=================
Test name: check.gst-plugins-bad.elements_netsim.netsim_stress
Command: '/builds/tpm/gst-plugins-bad/gst-build/build/subprojects/gst-plugins-bad/tests/check/elements_netsim'
=================
Running suite(s): netsim
Unexpected critical/warning: ../subprojects/gstreamer/gst/gstpad.c:4292:gst_pad_chain_data_unchecked:<netsim0:sink> Got data flow before stream-start event
Stack trace:
gst_debug_get_stack_trace (gstinfo.c:2788)
gst_check_log_critical_func (gstcheck.c:281)
g_logv (/usr/lib64/libglib-2.0.so.0.5800.1:0x7f828b2c66db)
g_log (/usr/lib64/libglib-2.0.so.0.5800.1:0x7f828b2c68cf)
gst_pad_push_data (gstpad.c:4290)
gst_pad_push (gstpad.c:4701)
gst_harness_stress_buffer_func (gstharness.c:2936)
?? (/usr/lib64/libglib-2.0.so.0.5800.1:0x7f828b2e8486)
start_thread (/usr/lib64/libpthread-2.28.so:0x7f828b25558a)
__clone (/usr/lib64/libc-2.28.so:0x7f828b18464f)
0%: Checks: 1, Failures: 1, Errors: 0
../subprojects/gstreamer/libs/gst/check/gstcheck.c:286:F:general:netsim_stress:0: Unexpected critical/warning: ../subprojects/gstreamer/gst/gstpad.c:4292:gst_pad_chain_data_unchecked:<netsim0:sink> Got data flow before stream-start event
Check suite netsim ran in 0.804s (tests failed: 1)
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/853rtph265pay doesn't parse codec_data from caps with stream-format=hvc1 and out...2021-09-24T13:34:22ZNirbheek Chauhannirbheek.chauhan@gmail.comrtph265pay doesn't parse codec_data from caps with stream-format=hvc1 and output sprop-sps/pps/vpsBecause of this, the receiver never gets sps/pps/vps and the decoder can't output anything. The workaround is to either force stream-format=byte-stream or add an h265parse before rtph265pay which will do the parsing for us.
To reproduce...Because of this, the receiver never gets sps/pps/vps and the decoder can't output anything. The workaround is to either force stream-format=byte-stream or add an h265parse before rtph265pay which will do the parsing for us.
To reproduce, compare:
```
$ gst-launch-1.0 videotestsrc num-buffers=1 ! vaapih265enc ! rtph265pay config-interval=-1 ! fakesink -v
```
and
```
$ gst-launch-1.0 videotestsrc num-buffers=1 ! vaapih265enc ! video/x-h265, stream-format=byte-stream ! rtph265pay config-interval=-1 ! fakesink -v
```
Note that `x265enc` can't currently output `hvc1`.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/856compilation of latest release fails on Windows (MSYS2 + mingw-w64)2021-09-24T13:26:12Zvtorricompilation of latest release fails on Windows (MSYS2 + mingw-w64)Hello
I am trying to compile gst-plugins-base 1.18.2 with MSYS2 + mingw-w64 and gl_mkenum.py fails :
```
FAILED: gst-libs/gst/gl/gl-enumtypes.h
"c:/documents/msys2/mingw64/bin/python.exe" "C:/Documents/msys2/opt/ewpi_64/share/ewpi/pac...Hello
I am trying to compile gst-plugins-base 1.18.2 with MSYS2 + mingw-w64 and gl_mkenum.py fails :
```
FAILED: gst-libs/gst/gl/gl-enumtypes.h
"c:/documents/msys2/mingw64/bin/python.exe" "C:/Documents/msys2/opt/ewpi_64/share/ewpi/packages/gst-plugins-base/gst-plugins-base-1.18.2/gst-libs/gst/gl/gl_mkenum.py" "C:/Documents/msys2/mingw64/bin/glib-mkenums.EXE" "gst-libs/gst/gl/gl-enumtypes.h" "../gst-libs/gst/gl/gl.h" "../gst-libs/gst/gl/gl-prelude.h" "../gst-libs/gst/gl/gstgl_enums.h" "../gst-libs/gst/gl/gstgl_fwd.h" "../gst-libs/gst/gl/gstglapi.h" "../gst-libs/gst/gl/gstglbasefilter.h" "../gst-libs/gst/gl/gstglbasememory.h" "../gst-libs/gst/gl/gstglbasesrc.h" "../gst-libs/gst/gl/gstglbuffer.h" "../gst-libs/gst/gl/gstglbufferpool.h" "../gst-libs/gst/gl/gstglcolorconvert.h" "../gst-libs/gst/gl/gstglcontext.h" "../gst-libs/gst/gl/gstgldebug.h" "../gst-libs/gst/gl/gstgldisplay.h" "../gst-libs/gst/gl/gstglfeature.h" "../gst-libs/gst/gl/gstglfilter.h" "../gst-libs/gst/gl/gstglformat.h" "../gst-libs/gst/gl/gstglframebuffer.h" "../gst-libs/gst/gl/gstglmemory.h" "../gst-libs/gst/gl/gstglmemorypbo.h" "../gst-libs/gst/gl/gstgloverlaycompositor.h" "../gst-libs/gst/gl/gstglquery.h" "../gst-libs/gst/gl/gstglrenderbuffer.h" "../gst-libs/gst/gl/gstglshader.h" "../gst-libs/gst/gl/gstglshaderstrings.h" "../gst-libs/gst/gl/gstglsl.h" "../gst-libs/gst/gl/gstglslstage.h" "../gst-libs/gst/gl/gstglsyncmeta.h" "../gst-libs/gst/gl/gstglupload.h" "../gst-libs/gst/gl/gstglutils.h" "../gst-libs/gst/gl/gstglviewconvert.h" "../gst-libs/gst/gl/gstglwindow.h"
Traceback (most recent call last):
File "C:/Documents/msys2/opt/ewpi_64/share/ewpi/packages/gst-plugins-base/gst-plugins-base-1.18.2/gst-libs/gst/gl/gl_mkenum.py", line 42, in <module>
ofilename = sys.argv[argn]
IndexError: list index out of range
```
Does someone know what happens ?
thank youhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/858gst_video_chroma_resample() ends up with an empty method name in gobject-intr...2021-09-24T13:26:12ZSebastian Drögegst_video_chroma_resample() ends up with an empty method name in gobject-introspectionSee below. It's also moved-to a global function with an actual name but that all seems a bit suboptimal.
We should probably provide a `gst_video_chroma_resample_resample()` or something like that in addition.
```xml
<record name="V...See below. It's also moved-to a global function with an actual name but that all seems a bit suboptimal.
We should probably provide a `gst_video_chroma_resample_resample()` or something like that in addition.
```xml
<record name="VideoChromaResample"
c:type="GstVideoChromaResample"
disguised="1">
<source-position filename="../gst-libs/gst/video/video-chroma.h"
line="87"/>
<method name=""
c:identifier="gst_video_chroma_resample"
moved-to="video_chroma_resample">
[...]
<function name="video_chroma_resample"
c:identifier="gst_video_chroma_resample">
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3062directsound: AC3/DTS passthrough does not work2023-11-01T09:52:00ZMilenko Mitrovicdirectsound: AC3/DTS passthrough does not workThere are a couple of issues in directsoundsink when trying to passthrough AC3/DTS.
I am not sure whether there is a bug in gst_audio_iec61937_payload itself or the G_BYTE_ORDER parameter added to the gst_audio_iec61937_payload call is ...There are a couple of issues in directsoundsink when trying to passthrough AC3/DTS.
I am not sure whether there is a bug in gst_audio_iec61937_payload itself or the G_BYTE_ORDER parameter added to the gst_audio_iec61937_payload call is wrong. I haven't really looked into it but changing G_BYTE_ORDER to G_BIG_ENDIAN fixed one part of it.
I am also not sure what gst_buffer_copy_into was supposed to do. IMO it was supposed to copy metadata and not copy the buffer and therefore override what has been created by the gst_audio_iec61937_payload call.
The _swab call swapped infobuf.size amount of data ignoring that the gst_audio_iec61937_payload call actually added a header to it. Maybe after the byte order was added as parameter to gst_audio_iec61937_payload this _swab call is not necessary anymore but IMO this could never have worked.
Attached is a patch that fixes the passthrough for me.
[0001-directsound-Fixed-AC3-DTS-passthrough.patch](/uploads/f0db7a47b606ff7e8b709066c39e25b0/0001-directsound-Fixed-AC3-DTS-passthrough.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/857rtspsrc: PAUSE reply is sometimes considered as a reply to the subsequent TEA...2021-09-24T13:34:23ZMarc Leemanrtspsrc: PAUSE reply is sometimes considered as a reply to the subsequent TEARDOWNThere seems to be a race condition where the reply to the TEARDOWN that is sent after that. Also, printing the CSeq field in the messages at level TRACE would help debugging....
```
^Chandling interrupt.
Interrupt: Stopping pipeline ......There seems to be a race condition where the reply to the TEARDOWN that is sent after that. Also, printing the CSeq field in the messages at level TRACE would help debugging....
```
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:00:03.644101094
Setting pipeline to NULL ...
0:00:03.856278865 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:6071:gst_rtspsrc_loop_send_cmd:<rtspsrc0> sending cmd WAIT
0:00:03.856290885 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:6096:gst_rtspsrc_loop_send_cmd:<rtspsrc0> cancel previous request LOOP
0:00:03.856298877 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:6104:gst_rtspsrc_loop_send_cmd:<rtspsrc0> connection flush busy LOOP
0:00:03.856306758 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:5227:gst_rtspsrc_connection_flush:<rtspsrc0> set flushing 1
0:00:03.856313838 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:5230:gst_rtspsrc_connection_flush:<rtspsrc0> connection flush
0:00:03.856389220 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:5811:gst_rtspsrc_loop_udp:<rtspsrc0> got interrupted
0:00:03.856403087 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:6169:gst_rtspsrc_loop:<rtspsrc0> pausing task, reason flushing
0:00:03.856409040 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:6071:gst_rtspsrc_loop_send_cmd:<rtspsrc0> sending cmd WAIT
0:00:03.856414152 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:6104:gst_rtspsrc_loop_send_cmd:<rtspsrc0> connection flush busy LOOP
0:00:03.856419079 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:5227:gst_rtspsrc_connection_flush:<rtspsrc0> set flushing 1
0:00:03.856487204 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:6071:gst_rtspsrc_loop_send_cmd:<rtspsrc0> sending cmd PAUSE
0:00:03.856501474 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:6109:gst_rtspsrc_loop_send_cmd:<rtspsrc0> not interrupting busy cmd WAIT
0:00:03.856553487 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:9062:gst_rtspsrc_thread:<rtspsrc0> got command PAUSE
0:00:03.856566689 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:5227:gst_rtspsrc_connection_flush:<rtspsrc0> set flushing 0
0:00:03.856572367 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:5230:gst_rtspsrc_connection_flush:<rtspsrc0> connection flush
0:00:03.856583195 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:8837:gst_rtspsrc_pause:<rtspsrc0> PAUSE...
0:00:03.856601088 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:530:default_before_send:<rtspsrc0> default handler
0:00:03.856607421 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:530:default_before_send:<rtspsrc0> default handler
0:00:03.856613644 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:6500:gst_rtspsrc_try_send:<rtspsrc0> sending message
0:00:03.856619349 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9709:gst_rtspsrc_print_rtsp_message:<rtspsrc0> --------------------------------------------
0:00:03.856625222 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9712:gst_rtspsrc_print_rtsp_message:<rtspsrc0> RTSP request message 0x7f4aec07cc10
0:00:03.856629642 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9713:gst_rtspsrc_print_rtsp_message:<rtspsrc0> request line:
0:00:03.856635086 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9715:gst_rtspsrc_print_rtsp_message:<rtspsrc0> method: 'PAUSE'
0:00:03.856640097 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9716:gst_rtspsrc_print_rtsp_message:<rtspsrc0> uri: 'rtsp://garage.fritz.box/'
0:00:03.856644996 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9718:gst_rtspsrc_print_rtsp_message:<rtspsrc0> version: '1.0'
0:00:03.856650593 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9719:gst_rtspsrc_print_rtsp_message:<rtspsrc0> headers:
0:00:03.856643234 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:6071:gst_rtspsrc_loop_send_cmd:<rtspsrc0> sending cmd CLOSE
0:00:03.856660118 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9693:dump_key_value:<rtspsrc0> key: 'User-Agent', value: 'GStreamer/1.18.3'
0:00:03.856668032 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:6096:gst_rtspsrc_loop_send_cmd:<rtspsrc0> cancel previous request LOOP
0:00:03.856679435 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:6104:gst_rtspsrc_loop_send_cmd:<rtspsrc0> connection flush busy PAUSE
0:00:03.856671324 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9721:gst_rtspsrc_print_rtsp_message:<rtspsrc0> body:
0:00:03.856699967 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9801:gst_rtspsrc_print_rtsp_message:<rtspsrc0> --------------------------------------------
0:00:03.856689563 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:5227:gst_rtspsrc_connection_flush:<rtspsrc0> set flushing 1
0:00:03.856718069 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:5230:gst_rtspsrc_connection_flush:<rtspsrc0> connection flush
0:00:03.856757871 1719898 0x55e278591400 WARN rtspsrc gstrtspsrc.c:6455:gst_rtsp_src_receive_response:<rtspsrc0> receive interrupted
0:00:03.856765090 1719898 0x55e278591400 WARN rtspsrc gstrtspsrc.c:6553:gst_rtspsrc_try_send:<rtspsrc0> receive interrupted
0:00:03.856770985 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:6656:gst_rtspsrc_send:<rtspsrc0> got error -3
0:00:03.856776496 1719898 0x55e278591400 WARN rtspsrc gstrtspsrc.c:8950:gst_rtspsrc_pause:<rtspsrc0> PAUSE interrupted
0:00:03.856813329 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:9062:gst_rtspsrc_thread:<rtspsrc0> got command CLOSE
0:00:03.856820049 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:5227:gst_rtspsrc_connection_flush:<rtspsrc0> set flushing 0
0:00:03.856824692 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:5230:gst_rtspsrc_connection_flush:<rtspsrc0> connection flush
0:00:03.856834951 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:8157:gst_rtspsrc_close:<rtspsrc0> TEARDOWN...
0:00:03.858738243 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:8199:gst_rtspsrc_close:<rtspsrc0> Teardown on rtsp://garage.fritz.box/
0:00:03.858764413 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:530:default_before_send:<rtspsrc0> default handler
0:00:03.858770738 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:530:default_before_send:<rtspsrc0> default handler
0:00:03.858775952 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:6500:gst_rtspsrc_try_send:<rtspsrc0> sending message
0:00:03.858781040 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9709:gst_rtspsrc_print_rtsp_message:<rtspsrc0> --------------------------------------------
0:00:03.858786794 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9712:gst_rtspsrc_print_rtsp_message:<rtspsrc0> RTSP request message 0x7f4aec07cc10
0:00:03.858791107 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9713:gst_rtspsrc_print_rtsp_message:<rtspsrc0> request line:
0:00:03.858796019 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9715:gst_rtspsrc_print_rtsp_message:<rtspsrc0> method: 'TEARDOWN'
0:00:03.858800587 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9716:gst_rtspsrc_print_rtsp_message:<rtspsrc0> uri: 'rtsp://garage.fritz.box/'
0:00:03.858805297 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9718:gst_rtspsrc_print_rtsp_message:<rtspsrc0> version: '1.0'
0:00:03.858809267 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9719:gst_rtspsrc_print_rtsp_message:<rtspsrc0> headers:
0:00:03.858814761 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9693:dump_key_value:<rtspsrc0> key: 'User-Agent', value: 'GStreamer/1.18.3'
0:00:03.858818921 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9721:gst_rtspsrc_print_rtsp_message:<rtspsrc0> body:
0:00:03.858823403 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9801:gst_rtspsrc_print_rtsp_message:<rtspsrc0> --------------------------------------------
0:00:03.859368744 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9709:gst_rtspsrc_print_rtsp_message:<rtspsrc0> --------------------------------------------
0:00:03.859379127 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9731:gst_rtspsrc_print_rtsp_message:<rtspsrc0> RTSP response message 0x7f4aec07cc70
0:00:03.859382634 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9732:gst_rtspsrc_print_rtsp_message:<rtspsrc0> status line:
0:00:03.859386218 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9733:gst_rtspsrc_print_rtsp_message:<rtspsrc0> code: '551'
0:00:03.859389753 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9734:gst_rtspsrc_print_rtsp_message:<rtspsrc0> reason: 'Option not supported'
0:00:03.859393468 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9736:gst_rtspsrc_print_rtsp_message:<rtspsrc0> version: '1.0
0:00:03.859396630 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9737:gst_rtspsrc_print_rtsp_message:<rtspsrc0> headers:
0:00:03.859400971 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9693:dump_key_value:<rtspsrc0> key: 'CSeq', value: '6'
0:00:03.859404870 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9693:dump_key_value:<rtspsrc0> key: 'Session', value: '487329988'
0:00:03.859408953 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9693:dump_key_value:<rtspsrc0> key: 'Date', value: 'Tue, Mar 02 2021 20:57:48 GMT'
0:00:03.859414871 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9740:gst_rtspsrc_print_rtsp_message:<rtspsrc0> body: length 0
0:00:03.859419251 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9801:gst_rtspsrc_print_rtsp_message:<rtspsrc0> --------------------------------------------
0:00:03.859423272 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:6402:gst_rtsp_src_receive_response:<rtspsrc0> received response message
0:00:03.859428372 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:6421:gst_rtsp_src_receive_response:<rtspsrc0> got response message 551
0:00:03.859435944 1719898 0x55e278591400 WARN rtspsrc gstrtspsrc.c:6715:gst_rtspsrc_send:<rtspsrc0> error: Unhandled error
0:00:03.859440818 1719898 0x55e278591400 WARN rtspsrc gstrtspsrc.c:6715:gst_rtspsrc_send:<rtspsrc0> error: Option not supported (551)
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/854mpegts: elements do not emit corresponding messages on SI/PSI tables update2021-09-24T14:36:52ZAlexmpegts: elements do not emit corresponding messages on SI/PSI tables updateI use tsparse element to obtain the current PAT/PMT/SDT tables from my stream. However, the behavior of the element seems unintuitive to me: if the PAT of the same content was met before, the corresponding message does not appear. For ex...I use tsparse element to obtain the current PAT/PMT/SDT tables from my stream. However, the behavior of the element seems unintuitive to me: if the PAT of the same content was met before, the corresponding message does not appear. For example when I feed two streams interchangeably to the tsparse, it emits PAT for each stream only once, so I couldn't fetch the actual stream structure. Is there any way to get the actual stream PAT (and SDT)? Is there any way to check if the PAT has changed?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/861Decodebin preroll does not complete when the first packet of a selected strea...2021-09-24T13:26:13ZGuy1524Decodebin preroll does not complete when the first packet of a selected stream is located more than 2 megabytes into a container.When attempting to play some .ogv video files, produced by a ffmpeg trans-coder, decodebin never finishes prerolling and the application hangs. This is because decodebin is configured to preroll 2MB of data from a container file before ...When attempting to play some .ogv video files, produced by a ffmpeg trans-coder, decodebin never finishes prerolling and the application hangs. This is because decodebin is configured to preroll 2MB of data from a container file before finishing.
However, if the demuxer doesn't output a buffer for at-least one of the selected streams during this process, gstreamer doesn't complete this step. This can be confirmed by either increasing the prerolling amount for decodebin, compressing the video stream more, causing the the first audio packet to land within the first 2MB, or only selecting one of the two streams. In all of these cases gstreamer plays the file correctly.
Attached is one such problematic video, I've reproduced the bug with gst123 and gst-launch:
![problematic_video](/uploads/c9c0b5242ccc6de41433d4a43860c00f/problematic_video.ogv)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/862DecodeBin Doesn't Choose nvv4l2decoder on Nvidia tegra systems2021-09-24T13:26:13ZtheofficialgmanDecodeBin Doesn't Choose nvv4l2decoder on Nvidia tegra systemsWhen utilizing decodebin on nvidia tegra systems, decodebin does software video decoding.
The best scenario for compatibility with other gstreamer applications which utilize glimagesink would be to use nvv4l2decoder with nvvidconv, as s...When utilizing decodebin on nvidia tegra systems, decodebin does software video decoding.
The best scenario for compatibility with other gstreamer applications which utilize glimagesink would be to use nvv4l2decoder with nvvidconv, as shown in the below pipeline.
`gst-launch-1.0 souphttpsrc is-live=true location="$(youtube-dl --format "best[ext=mp4][protocol=https]" --get-url https://www.youtube.com/watch?v=Uo2SNtFofWI)" ! qtdemux name=demux ! queue ! h264parse ! nvv4l2decoder ! nvvidconv ! glimagesink -e demux.audio_0 ! queue ! avdec_aac ! audioconvert ! pulsesink -e`https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/861SDP tags should be converted to TagList by the depayloader2021-09-24T13:34:23ZNirbheek Chauhannirbheek.chauhan@gmail.comSDP tags should be converted to TagList by the depayloaderThe SDP spec [rfc4566](https://tools.ietf.org/html/rfc4566) supports the following tags:
[`i=<value>`](https://tools.ietf.org/html/rfc4566#section-5.4) also called `information` is the title of the media, `GST_TAG_TITLE`
[`a=lang:<valu...The SDP spec [rfc4566](https://tools.ietf.org/html/rfc4566) supports the following tags:
[`i=<value>`](https://tools.ietf.org/html/rfc4566#section-5.4) also called `information` is the title of the media, `GST_TAG_TITLE`
[`a=lang:<value>`](https://tools.ietf.org/html/rfc4566#page-29) is the language of the stream ([RFC 3066](https://www.ietf.org/rfc/rfc3066.txt), which is explicitly compatible with ISO 639), `GST_TAG_LANGUAGE_CODE`
Attributes are already in the RTP caps as `a-lang=<lang>`, so that can be directly translated to TagList by the depayloader. Not sure about the title.
Also, when we're using RTSP, we can likely also emit `GST_TAG_DURATION` when playing [on-demand media](https://tools.ietf.org/html/rfc7826#section-13.4.4).https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/862videoflip: caps are not properly renegotiated when changing the method to GST...2021-09-24T13:34:24ZMichael Olbrichvideoflip: caps are not properly renegotiated when changing the method to GST_VIDEO_ORIENTATION_IDENTITYI have an application that changes the flip method at runtime with a tag event.
When the method is changed to `GST_VIDEO_ORIENTATION_IDENTITY` then the caps are not correctly renegotiated.
I think, this is caused by !836. The problem i...I have an application that changes the flip method at runtime with a tag event.
When the method is changed to `GST_VIDEO_ORIENTATION_IDENTITY` then the caps are not correctly renegotiated.
I think, this is caused by !836. The problem is, that in this case, the element is set into passthrough mode. As a result, `gst_video_flip_transform_frame` is no longer called and ``change_configuring_method`` is never set to `TRUE`. So `gst_video_flip_transform_caps()` continues to use the old method.
The result is, that I see a 2160x3840 resolution in the caps but a buffer with 3840x2160 at the sink.
I'm not sure how this should be fixed. From what I understand, we can set `change_configuring_method` in `gst_video_flip_set_method()`. I think that would work when it is called from a tag event, but not from the property. Or am I missing something here?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/865video-hdr: HDR10plus signalling by using only blob data might be suboptimal2021-09-24T13:26:13ZSeungha Yangseungha@centricular.comvideo-hdr: HDR10plus signalling by using only blob data might be suboptimalWe added support for HDR10+ https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/650 in a way that GstMeta holds blob data (raw data with size). Most likely the GstMeta will be attached by demuxer/codec parsers (or ...We added support for HDR10+ https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/650 in a way that GstMeta holds blob data (raw data with size). Most likely the GstMeta will be attached by demuxer/codec parsers (or via streaming/codec specific spec).
Then if there are consumer elements which want to read HDR10+ data, consumer element needs to parse blob data by using util method, that is `gst_video_hdr_parse_hdr10_plus`.
It's suboptimal in case that there are multiple consumer elements that have interested in parsed HDR10+ meta data.
Probably we can hold `GstVideoHDR10Plus` struct in a HDR10+ specific GstMeta so that one consumer of the blob data can update the corresponding `GstVideoHDR10Plus` struct in `GstMeta` to avoid double parsing. But it might make this API complicated.
The simplest API design (but still not optimal because we need to parse it always) would be an approach that modifying HDR10+ specific metadata to hold parsed HDR10+ data (like [ffmpeg's approach](https://github.com/FFmpeg/FFmpeg/blob/069d2b4a50a6eb2f925f36884e6b9bd9a1e54670/libavutil/hdr_dynamic_metadata.h#L243)), instead of holding blob data.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/866multihandlesink: Clients timed out as too slow if the sink received no buffer...2021-09-24T13:26:14ZSebastian Drögemultihandlesink: Clients timed out as too slow if the sink received no buffer for more than the timeoutSay the timeout is set to 10s and the sink receives no buffer for 11s, then on the next buffer all clients would be immediately timed out.Say the timeout is set to 10s and the sink receives no buffer for 11s, then on the next buffer all clients would be immediately timed out.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2545validateflow: Take into account buffer video (and audio?) flags when serializ...2023-05-03T17:14:05ZVivia Nikolaidouvalidateflow: Take into account buffer video (and audio?) flags when serializing buffer flagsThat would also mean we can't check for them in gst-validate, which in turn means all the tests would need to be updated.
See also https://gitlab.freedesktop.org/gstreamer/gst-integration-testsuites/-/merge_requests/93#note_788162That would also mean we can't check for them in gst-validate, which in turn means all the tests would need to be updated.
See also https://gitlab.freedesktop.org/gstreamer/gst-integration-testsuites/-/merge_requests/93#note_788162https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/868videoconvert: NV12(bt601) to GRAY8 conversion results in image with limited r...2021-09-24T13:26:14ZMarianna Smidth Buschlevideoconvert: NV12(bt601) to GRAY8 conversion results in image with limited range [16:235] instead of full range [0:255]I believe there is an error in how `videoconvert` is handling the conversion of NV12(bt601) to GRAY8.
The resulting gray image has the limited range from YCrCb [16:235] instead of the expected full range [0:255].
It is missing a scalin...I believe there is an error in how `videoconvert` is handling the conversion of NV12(bt601) to GRAY8.
The resulting gray image has the limited range from YCrCb [16:235] instead of the expected full range [0:255].
It is missing a scaling step which should do the "contrast stretching".
Note that it handles NV12(bt709) to GRAY8 correctly, it produces an image where it is clear the histogram has been streched to cover the full range.
Example:
- This produces very similar videos (color and intensity wise):
```
GST_DEBUG="*:3" gst-launch-1.0 videotestsrc ! "video/x-raw,width=1920,height=1080,format=RGB,framerate=30/1" ! tee name=t ! queue ! videoconvert ! "video/x-raw,format=NV12,colorimetry=bt709" ! videoconvert ! ximagesink t. ! queue ! videoconvert ! "video/x-raw,format=NV12,colorimetry=bt601" ! videoconvert ! ximagesink
```
- This produces videos with difference in the grey intensities: the one from bt601 has limited range [16:235] instead of full range [0:255]
```
GST_DEBUG="*:3" gst-launch-1.0 videotestsrc ! "video/x-raw,width=1920,height=1080,format=RGB,framerate=30/1" ! tee name=t ! queue ! videoconvert ! "video/x-raw,format=NV12,colorimetry=bt709" ! videoconvert ! "video/x-raw,format=GRAY8" ! videoconvert ! ximagesink t. ! queue ! videoconvert ! "video/x-raw,format=NV12,colorimetry=bt601" ! videoconvert ! "video/x-raw,format=GRAY8" ! videoconvert ! ximagesink
```
- This again produces very similar videos
```
GST_DEBUG="*:3" gst-launch-1.0 videotestsrc ! "video/x-raw,width=1920,height=1080,format=RGB,framerate=30/1" ! tee name=t ! queue ! videoconvert ! "video/x-raw,format=NV12,colorimetry=bt709" ! videoconvert ! "video/x-raw,format=RGB" ! videoconvert ! "video/x-raw,format=GRAY8" ! videoconvert ! ximagesink t. ! queue ! videoconvert ! "video/x-raw,format=NV12,colorimetry=bt601" ! videoconvert ! "video/x-raw,format=RGB" ! videoconvert ! "video/x-raw,format=GRAY8" ! videoconvert ! ximagesink
```
Note that the same can be seen if fx saving the gray frames as PNM with `pnmenc` and `filesink` so it has nothing to do with `videoconvert ! ximagesink`.
When inspecting the gstreamer logs with: `GST_DEBUG="*:3,*video-color*:5,*video-converter*:5"` I can see the RGB->NV12 conversions for both cases, but the NV12->GRAY8 conversion is only done for the BT709, it gets bypassed when using BT601.
And I can see in the code that it seems to be because it detects the conversion has the same color matrix, so it thinks it is unnecessary, while BT709 uses a different color matrix so it requires conversion.
But the step that does the matrix conversion is the same as the one that does the scaling/offset correction from limited to full range.
So for me it seems like videoconvert is missing taking the range of the colorimetry into account.
```
0:00:00.037669400 74014 0x5558a695fe30 DEBUG video-converter video-converter.c:1747:chain_convert: matrix 4 -> 4 (1)
```
vs
```
0:00:00.031250922 74044 0x559cca812a30 DEBUG video-converter video-converter.c:1747:chain_convert: matrix 3 -> 4 (0)
0:00:00.031331090 74044 0x559cca812a30 DEBUG video-color video-color.c:247:gst_video_color_range_offsets: scale: 219 224 224 255
0:00:00.031353379 74044 0x559cca812a30 DEBUG video-color video-color.c:248:gst_video_color_range_offsets: offset: 16 128 128 0
0:00:00.031685485 74044 0x559cca812a30 DEBUG video-color video-color.c:247:gst_video_color_range_offsets: scale: 255 255 255 255
0:00:00.031707225 74044 0x559cca812a30 DEBUG video-color video-color.c:248:gst_video_color_range_offsets: offset: 0 128 128 0
```
It seems like it misses calling this: `gst_video_color_range_offsets()` https://github.com/GStreamer/gst-plugins-base/blob/master/gst-libs/gst/video/video-color.c#L204
* this tells that the primaries are the same: https://github.com/GStreamer/gst-plugins-base/blob/master/gst-libs/gst/video/video-converter.c#L1696
* Then because the matrix and bits are also the same we never enter here: https://github.com/GStreamer/gst-plugins-base/blob/master/gst-libs/gst/video/video-converter.c#L1769
* So we dont call this: `compute_matrix_to_RGB()` https://github.com/GStreamer/gst-plugins-base/blob/master/gst-libs/gst/video/video-converter.c#L1777
* Which is the one to call `gst_video_color_range_offsets()` https://github.com/GStreamer/gst-plugins-base/blob/master/gst-libs/gst/video/video-converter.c#L1341