gst-plugins-good issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues2021-09-24T13:33:31Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/640v4l2src: Does not save brightness/hue/contrast/saturation values when in NULL...2021-09-24T13:33:31ZMichael Rodinv4l2src: Does not save brightness/hue/contrast/saturation values when in NULL statev4l2src sets the properties PROP_BRIGHTNESS, PROP_CONTRAST, PROP_SATURATION and PROP_HUE in
gst_v4l2src_set_property() -> gst_v4l2_object_set_property_helper() -> gst_v4l2_set_attribute()
via VIDIOC_S_CTRL. It is required that the vide...v4l2src sets the properties PROP_BRIGHTNESS, PROP_CONTRAST, PROP_SATURATION and PROP_HUE in
gst_v4l2src_set_property() -> gst_v4l2_object_set_property_helper() -> gst_v4l2_set_attribute()
via VIDIOC_S_CTRL. It is required that the video device is already opened and v4l2object->video_fd is valid. But video device is opened too late in
gst_v4l2src_change_state() -> gst_v4l2_object_open() -> gst_v4l2_open()
during the state transition from NULL to READY. Therefore setting of the mentioned properties always fails. Unfortunately I could not switch to the latest gstreamer version to verify this but the code looks very similar so the issue should still exist. Can somebody confirm this?https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/648Black flickering when displaying multiple 4K videos in qmlglsink2021-09-24T13:33:31ZTim AutinBlack flickering when displaying multiple 4K videos in qmlglsinkHello,
I'm using qmlglsink to display several 4K videos in an application (currently up to 4, in the future up to 8, when I'll have received some more hardware). The current hardware is the following:
* 2 4K cameras, let's call them A a...Hello,
I'm using qmlglsink to display several 4K videos in an application (currently up to 4, in the future up to 8, when I'll have received some more hardware). The current hardware is the following:
* 2 4K cameras, let's call them A and B (there will be more in the future)
* 1 Blackmagic Smart VideoHub 12G
* 1 DeckLink 8K Pro (a second one will arrive in a few weeks)
* 1 Dell Precision with 2 Intel Xeon E5-2698 (40c/80t), 256GB of RAM and an Nvidia GeForce GTX 1080
When dispaying 3/4 videos, I often see a black flickering (there's a black frame and then the video is back). I reduced my code to the minimum and the problem is still there. When displaying 4 videos, the flickering is frequent enough to make the software unusable.
Say I'm displaying camera A twice and camera B twice. When a flickering occurs, it does for all the GstGLVideoItems showing that camera. So if A flickers, it will on the 2 GstGLVideoItems showing A, while B will not. An vice versa if B flickers.
If I start my app 4 times with one video in each instance, there's no problem (or maybe so rare that it's not a big deal).
I have a GStreamer development environment setup, and I can run some tests if needed.
It might be related to issue #396 , but there does not seem to be much activity there, and the op talked about artifacts, not black frames.
Thanks in advance for any help.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/649rtspsrc: non-flushing seek when connecting over TCP causes deadlock2021-09-24T13:33:32ZAaron Boxerrtspsrc: non-flushing seek when connecting over TCP causes deadlockCode deadlocks on stream lock:
```
/* we should now be able to grab the streaming thread because we stopped it
* with the above flush/pause code */
GST_RTSP_STREAM_LOCK (src);
GST_DEBUG_OBJECT (src, "stopped streaming");
```
T...Code deadlocks on stream lock:
```
/* we should now be able to grab the streaming thread because we stopped it
* with the above flush/pause code */
GST_RTSP_STREAM_LOCK (src);
GST_DEBUG_OBJECT (src, "stopped streaming");
```
This is on latest master via gst-build.
OS is Windows 10, running in Visual Studio with debug symbols loaded.
Code that triggers the event:
```
double speed = 4.0;
GstSeekFlags flags = (GstSeekFlags)( GST_SEEK_FLAG_TRICKMODE);
/* Create the seek event */
seek_event =
gst_event_new_seek(speed, GST_FORMAT_PERCENT, flags, GST_SEEK_TYPE_NONE,
0, GST_SEEK_TYPE_NONE, 0);
/* Send the event */
gboolean res = gst_element_send_event(m_playbin, seek_event);
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/852Autoaudiosink ignores the buffer-time and latency-time properties2021-09-24T13:34:22ZIgnazioAutoaudiosink ignores the buffer-time and latency-time propertiesOn both windows and Linux the autoaudiosink ignores the buffer-time and latency-time properties. As reported in the documentation the autoaudiosink is not a subclass of baseaudiosink.
To test you can use the audiolatency module to compa...On both windows and Linux the autoaudiosink ignores the buffer-time and latency-time properties. As reported in the documentation the autoaudiosink is not a subclass of baseaudiosink.
To test you can use the audiolatency module to compare the output of these pipelines:
```
gst-launch-1.0 pulsesrc device=auto_null.monitor ! audiolatency print-latency=true ! autoaudiosink buffer-time=20000 latency-time=10000
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstPulseSrcClock
Redistribute latency...
Redistribute latency...
last latency: 135ms, running average: 135ms
last latency: 122ms, running average: 129ms
last latency: 122ms, running average: 126ms
last latency: 122ms, running average: 125ms
last latency: 133ms, running average: 127ms
...
```
```
gst-launch-1.0 pulsesrc device=auto_null.monitor ! audiolatency print-latency=true ! pulsesink buffer-time=20000 latency-time=10000
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstPulseSrcClock
Redistribute latency...
Redistribute latency...
last latency: 153ms, running average: 153ms
last latency: 30ms, running average: 92ms
last latency: 27ms, running average: 70ms
last latency: 23ms, running average: 58ms
last latency: 31ms, running average: 53ms
...
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/656ximagesrc: hangs when the streaming xwindow gets closed2021-09-24T13:33:33ZPascalximagesrc: hangs when the streaming xwindow gets closedThis only applies to Linux with X11 and XDamage.
Seen on CentOS 7 with GStreamer 1.16
How to reproduce, with two different shells:
```
shell-1$ xeyes&
shell-2$ gst-launch-1.0 ximagesrc xname=xeyes ! queue ! videoconvert ! xvimagesink
sh...This only applies to Linux with X11 and XDamage.
Seen on CentOS 7 with GStreamer 1.16
How to reproduce, with two different shells:
```
shell-1$ xeyes&
shell-2$ gst-launch-1.0 ximagesrc xname=xeyes ! queue ! videoconvert ! xvimagesink
shell-1$ xdotool search xeyes windowkill
```
In this case, the xeyes window gets killed but nothing happens to GStreamer.
By running the same pipeline in an application, most interactions would hang such as
- Sending eos message to the ximagesrc element
- Setting the pipeline state back to NULLhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/673Flaky Test: validate.launch_pipeline.scaletempo_playbin_audio_filter.fast_for...2021-09-24T13:33:37ZNicolas DufresneFlaky Test: validate.launch_pipeline.scaletempo_playbin_audio_filter.fast_forwardIt's the second time I stumble across this failure. It was last seen here:
https://gitlab.freedesktop.org/bilboed/gst-plugins-base/-/jobs/1035351
```
validate.launch_pipeline.scaletempo_playbin_audio_filter.fast_forward
Command
...It's the second time I stumble across this failure. It was last seen here:
https://gitlab.freedesktop.org/bilboed/gst-plugins-base/-/jobs/1035351
```
validate.launch_pipeline.scaletempo_playbin_audio_filter.fast_forward
Command
| GST_VALIDATE_SCENARIOS_PATH='/builds/bilboed/gst-plugins-base/gst-build/prefix/share/gstreamer-1.0/validate/scenarios:/builds/bilboed/gst-plugins-base/gst-build/subprojects/gst-devtools/validate/data/scenarios' GST_VALIDATE_SCENARIO='fast_forward' DISPLAY=':27' GST_VALIDATE_CONFIG='/builds/bilboed/gst-plugins-base/gst-build/subprojects/gst-integration-testsuites/integration-testsuites.config:' GST_GL_XINITTHREADS='1' /builds/bilboed/gst-plugins-base/gst-build/build/subprojects/gst-devtools/validate/tools/gst-validate-1.0 playbin audio-filter=scaletempo video-sink=fakesink uri=file:///builds/bilboed/gst-plugins-base/gst-build/subprojects/gst-integration-testsuites/testsuites/../medias/defaults/mp4/mp3_h264.0.mp4
gst-validate-1.0 output
| **-> Running scenario fast_forward on pipeline playbin0**
|
| Starting pipeline
| Prerolling...
| Pipeline started
| 0:00:00.561865557 90389 0x7fe344080f70 ERROR validate gst-validate-reporter.c:196:gst_validate_report_valist: <playbin0> 2461 (critical) : g-log: We got a g_log critical issue : file ../subprojects/gst-plugins-base/gst-libs/gst/audio/gstaudioringbuffer.c: line 2054 (gst_audio_ring_buffer_set_channel_positions): should not be reached
|
| Executing set-vars (
| - default_flags=accurate+flush
| )
|
| Executing (subaction)seek (
| - name=Fast-forward-seek
| - playback-time=0
| - rate=2
| - start=0
| - flags=accurate+flush
| )
| -> Action seek done (duration: 0:00:00.032781838)
|
| Executing (subaction)seek (
| - name=Fast-forward-seek
| - playback-time=0:00:00.626937500
| - rate=4
| - start=0
| - flags=accurate+flush
| )
| -> Action seek done (duration: 0:00:00.033435261)
|
| Executing (subaction)seek (
| - name=Fast-forward-seek
| - playback-time=0:00:01.253875000
| - rate=8
| - start=0
| - flags=accurate+flush
| )
| -> Action seek done (duration: 0:00:00.028066567)
|
| Executing (subaction)seek (
| - name=Fast-forward-seek
| - playback-time=0:00:02.507750000
| - rate=16
| - start=0
| - flags=accurate+flush
| )
| -> Action seek done (duration: 0:00:00.022695295)
|
| Executing (subaction)seek (
| - name=Fast-forward-seek
| - playback-time=0:00:05.015500000
| - rate=32
| - start=0
| - flags=accurate+flush
| )
| -> Action seek done (duration: 0:00:00.019863917)
| <position: 0:00:02.866666667 duration: 0:00:10.031000000 speed: 1.000000 />
|
| Executing (subaction)stop (
| - playback-time=0:00:09.731000000
| )
|
| fast_forward --> State change request NULL, quiting mainloop
| warning : buffer timestamp is out of the received buffer timestamps' range
| Detected on <avdec_mp3-0:src>
| Description : a buffer leaving an element should have its timestamps in the range of the received buffers timestamps. i.e. If an element received buffers with timestamps from 0s to 10s, it can't push a buffer with a 11s timestamp, because it doesn't have data for that
|
| warning : received the same caps twice
| Detected on <avdec_h264-0:sink>
| Detected on <h264parse0:sink>
| Detected on <mpegaudioparse0:sink>
| Detected on <avdec_mp3-0:sink>
|
| warning : a new segment event has different value than the received one
| Detected on <scaletempo0:src>
| Description : when receiving a new segment, an element should push an equivalent segment downstream
|
| critical : We got a g_log critical issue
| Detected on <playbin0>
| Details : file ../subprojects/gst-plugins-base/gst-libs/gst/audio/gstaudioringbuffer.c: line 2054 (gst_audio_ring_buffer_set_channel_positions): should not be reached
| dotfile : https://gitlab.freedesktop.org/bilboed/gst-plugins-base/-/jobs/1035351/artifacts/raw/validate-logs/validate/launch_pipeline/scaletempo_playbin_audio_filter/fast_forward.pipelines_dot_files/0:00:00.539117841-validate-report-critical-on-playbin0-g-log::critical.dot
| backtrace :
| gst_debug_get_stack_trace (gstinfo.c:2971)
| gst_validate_report_new (gst-validate-report.c:746)
| gst_validate_report_valist (gst-validate-reporter.c:187)
| gst_validate_report (gst-validate-reporter.c:320)
| g_logv (gmessages.c:1350)
| g_log (gmessages.c:1413)
| alsa_detect_channels_mapping (gstalsa.c:822)
| gst_alsasink_prepare (gstalsasink.c:926)
| gst_audio_sink_ring_buffer_acquire (gstaudiosink.c:401)
| gst_audio_ring_buffer_acquire (gstaudioringbuffer.c:625)
| gst_audio_base_sink_setcaps (gstaudiobasesink.c:950)
| gst_base_sink_default_event (gstbasesink.c:3391)
| gst_base_sink_event (gstbasesink.c:3651)
| gst_validate_pad_monitor_downstream_event_check (gst-validate-pad-monitor.c:2005)
| gst_validate_pad_monitor_sink_event_full_func (gst-validate-pad-monitor.c:2357)
| gst_validate_pad_monitor_sink_event_func (gst-validate-pad-monitor.c:2369)
| gst_pad_send_event_unchecked (gstpad.c:5841)
| gst_pad_push_event_unchecked (gstpad.c:5484)
| push_sticky (gstpad.c:3999)
| events_foreach (gstpad.c:608)
| gst_pad_push_event (gstpad.c:4058)
| event_forward_func (gstpad.c:3120)
| gst_pad_forward (gstpad.c:3074)
| gst_pad_event_default (gstpad.c:3171)
| gst_pad_send_event_unchecked (gstpad.c:5841)
| gst_pad_push_event_unchecked (gstpad.c:5484)
| push_sticky (gstpad.c:3999)
| events_foreach (gstpad.c:608)
| gst_pad_push_event (gstpad.c:4058)
| gst_base_transform_setcaps (gstcompat.h:59)
| gst_base_transform_sink_eventfunc (gstbasetransform.c:1898)
| gst_validate_pad_monitor_downstream_event_check (gst-validate-pad-monitor.c:2005)
| gst_validate_pad_monitor_sink_event_full_func (gst-validate-pad-monitor.c:2357)
| gst_validate_pad_monitor_sink_event_func (gst-validate-pad-monitor.c:2369)
| gst_pad_send_event_unchecked (gstpad.c:5841)
| gst_pad_push_event_unchecked (gstpad.c:5484)
| push_sticky (gstpad.c:3999)
| events_foreach (gstpad.c:608)
| gst_pad_push_event (gstpad.c:4058)
| gst_base_transform_setcaps (gstcompat.h:59)
| gst_base_transform_sink_eventfunc (gstbasetransform.c:1898)
| gst_validate_pad_monitor_downstream_event_check (gst-validate-pad-monitor.c:2005)
| gst_validate_pad_monitor_sink_event_full_func (gst-validate-pad-monitor.c:2357)
| gst_validate_pad_monitor_sink_event_func (gst-validate-pad-monitor.c:2369)
| gst_pad_send_event_unchecked (gstpad.c:5841)
| gst_pad_push_event_unchecked (gstpad.c:5484)
| push_sticky (gstpad.c:3999)
| events_foreach (gstpad.c:608)
| gst_pad_push_event (gstpad.c:4058)
| gst_base_transform_setcaps (gstcompat.h:59)
| gst_base_transform_sink_eventfunc (gstbasetransform.c:1898)
| gst_validate_pad_monitor_downstream_event_check (gst-validate-pad-monitor.c:2005)
| gst_validate_pad_monitor_sink_event_full_func (gst-validate-pad-monitor.c:2357)
| gst_validate_pad_monitor_sink_event_func (gst-validate-pad-monitor.c:2369)
| gst_pad_send_event_unchecked (gstpad.c:5841)
| gst_pad_push_event_unchecked (gstpad.c:5484)
| push_sticky (gstpad.c:3999)
| events_foreach (gstpad.c:608)
| gst_pad_push_event (gstpad.c:4058)
| event_forward_func (gstpad.c:3120)
| gst_pad_forward (gstpad.c:3074)
| gst_pad_event_default (gstpad.c:3171)
| gst_play_sink_convert_bin_sink_event (gstplaysinkconvertbin.c:260)
| gst_validate_pad_monitor_downstream_event_check (gst-validate-pad-monitor.c:2005)
| gst_validate_pad_monitor_sink_event_full_func (gst-validate-pad-monitor.c:2357)
| gst_validate_pad_monitor_sink_event_func (gst-validate-pad-monitor.c:2369)
| gst_pad_send_event_unchecked (gstpad.c:5841)
| gst_pad_push_event_unchecked (gstpad.c:5484)
| push_sticky (gstpad.c:3999)
| events_foreach (gstpad.c:608)
| gst_pad_push_event (gstpad.c:4058)
| gst_queue_loop (gstqueue.c:1455)
| gst_task_func (gsttask.c:328)
| g_thread_pool_thread_proxy (gthreadpool.c:308)
| g_thread_proxy (gthread.c:805)
| start_thread (pthread_create.c:479)
| __clone (clone.S:93)
|
|
|
|
| **Got criticals. Return value set to 18**:
| * critical error file ../subprojects/gst-plugins-base/gst-libs/gst/audio/gstaudioringbuffer.c: line 2054 (gst_audio_ring_buffer_set_channel_positions): should not be reached
|
| Issues found: 4
| Returning 18 as errors were found
|
| =======> Test FAILED (Return value: 18)
You can mark the issues as 'known' by adding the following lines to the list
of known issues
| "FIXME 'validate.launch_pipeline.scaletempo_playbin_audio_filter.fast_forward' issues [REPORT A BUG in https://gitlab.freedesktop.org/gstreamer/ or use a proper bug description]": {
| "tests": [
| "validate.launch_pipeline.scaletempo_playbin_audio_filter.fast_forward"
| ],
| "issues": [
| {
| 'returncode': 18,
| 'sometimes': True,
| },
| {
| "issue-id": "g-log::critical",
| "summary": "We got a g_log critical issue",
| "level": "critical",
| "detected-on": "playbin0",
| # "details": "file ../subprojects/gst-plugins-base/gst-libs/gst/audio/gstaudioringbuffer.c: line 2054 (gst_audio_ring_buffer_set_channel_positions): should not be reached",
| },
| ],
| },
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/674UDPSink is using wrong socket option for multicast interface (patch)2021-09-24T13:33:38ZMike FletcherUDPSink is using wrong socket option for multicast interface (patch)The UDPSink/MultiUDPSink is using the `SO_BINDTODEVICE` option to attempt to limit the multicast interface on which multicast udp streams are output. The correct socket options are `IP_MULTICAST_IF` and `IPV6_MULTICAST_IF`. The patch ref...The UDPSink/MultiUDPSink is using the `SO_BINDTODEVICE` option to attempt to limit the multicast interface on which multicast udp streams are output. The correct socket options are `IP_MULTICAST_IF` and `IPV6_MULTICAST_IF`. The patch referenced below switches the behaviour to using these APIs. This produces correct behaviour (on Linux machines).
Note that the two options require slightly different parameters. The IPv4 API requires the IP address of the local interface to which to limit (we are using bind-address for this, as it appears that was the original intent), while the IPv6 API requires the interface index (we are using multicast-iface for this). I've tried to make the property documentation a bit clearer on that.
I'm unsure if the headers/socket functions I'm introducing are available on Windows or Mac, so that should be reviewed by someone more knowledgeable about such thing. On Linux both IPv4 and IPv6 variants are shown to correctly limit output to specified interfaces.
https://github.com/ATX-Networks/gst-plugins-good/commit/e85e8eab93228e76d57966397634c0ae28b93278
Hope this helps,
Mikehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/675udpsrc lost UDP multicast packets when starting another receiver app2021-09-24T13:33:38ZChristophe Allartudpsrc lost UDP multicast packets when starting another receiver appI found a strange problem on udpsrc Gstreamer 1.16.0 , reproduced on several other versions of GStreamer (1.16.1 , 1.12 , 1.10 and 1.8.3 , but not on 1.8.0) so i came back to 1.8.0 for my current project. I suspect some changes in udpsr...I found a strange problem on udpsrc Gstreamer 1.16.0 , reproduced on several other versions of GStreamer (1.16.1 , 1.12 , 1.10 and 1.8.3 , but not on 1.8.0) so i came back to 1.8.0 for my current project. I suspect some changes in udpsrc in 2016 to be the culprit.
On my Windows 10 64 bits PC , i am running a simple pipeline that receives and displays a UDP/RTP/H264 video stream :
gst-launch-1.0 udpsrc do-timestamp=1 port=5004 address=239.20.40.1 buffer-size=800000 caps="application/x-rtp,media=(string)video,clock-rate=(int)90000" ! rtph264depay ! avdec_h264 ! fpsdisplaysink sync=0
Of course there is some sender on the local network to generate this stream. Everything goes fine.
If then i start another app that wants to display this video stream ( VLC player for the test , using a small SDP file ) , the Gstreamer pipeline freezes, or more precisely the udpsrc element do not receive anymore the UDP packets.
If i stop VLC , the Gstreamer video runs again.
NO problem when starting several Gstreamer pipelines on the same stream (same IP multicast, same port).
NO problem in loopback mode, that is , when i generate the stream locally with some Gstreamer pipeline for the test.
I repeat , with Gstreamer 1.8.0 , no problem , the video goes fine , even with VLC running.
I don't think VLC is to be blamed on this . I have reproduced the problem with one of our developped apps here that create and bind to a multicast socket (and set the SO_REUSEADDR option).
I suspect some Multicast settings in udpsrc code to be the culprit but unfortunately i don't have much time to investigate and recompile udpsrc to check my hypothesis.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/678rtp_payloading: Tests succeed although they actually fail2021-09-24T13:33:38ZSebastian Drögertp_payloading: Tests succeed although they actually failLet's take this as an example
```sh
$ GST_CHECKS=rtp_vorbis meson test --suite gst-plugins-good elements_rtp_payloading
```
Also happens with `rtp_mp4v` at least. If we look in the logs we see
```
0:00:00.583530701 753358 0x556af2f485...Let's take this as an example
```sh
$ GST_CHECKS=rtp_vorbis meson test --suite gst-plugins-good elements_rtp_payloading
```
Also happens with `rtp_mp4v` at least. If we look in the logs we see
```
0:00:00.583530701 753358 0x556af2f48590 WARN GST_CAPS gstpad.c:3230:gst_pad_query_accept_caps_default:<rtpvorbisdepay0:sink> caps: application/x-rtp, media=(string)audio, payload=(int)96, encoding-name=(string)VORBIS, ssrc=(uint)922420776, timestamp-offset=(uint)2224758342, seqnum-offset=(uint)2906 were not compatible with: application/x-rtp, media=(string)audio, payload=(int)96, encoding-name=(string)VORBIS, ssrc=(uint)922420776, timestamp-offset=(uint)2224758342, seqnum-offset=(uint)2906, clock-rate=(int)[ 1, 2147483647 ]
[...]
0:00:00.583758172 753358 0x556af2f48590 DEBUG GST_SCHEDULING gstpad.c:4401:gst_pad_chain_data_unchecked:<rtpvorbispay0:sink> called chainfunction &0x7f81bded6f90 with buffer 0x556af306c240, returned ok
[...]
0:00:00.584860036 753358 0x556af2f48590 DEBUG GST_EVENT gstpad.c:5770:gst_pad_send_event_unchecked:<fakesink0:sink> have event type eos event: 0x556af30616b0, time 99:99:99.999999999, seq-num 19, (NULL)
```
The depayloader does not accept the caps of the payloader because they contain no `clock-rate` field. However this does not cause the test to fail because the payloader does not even try to output a buffer, it only consumes the buffer and happily returns. Then the app source is done and sends EOS, and it gets send through until the sink.
There is no dataflow happening between the payloader and the sink at all in this test.
This probably happens because the data passed into the payloader is invalid.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/679new fakevideodec element2021-09-24T13:30:28ZBugzilla Migration Usernew fakevideodec element## Submitted by Julien Isorce `@cap`
**[Link to original bug (#723778)](https://bugzilla.gnome.org/show_bug.cgi?id=723778)**
## Description
I have started a fakevideodec element here http://cgit.collabora.com/git/user/julien/gst-plu...## Submitted by Julien Isorce `@cap`
**[Link to original bug (#723778)](https://bugzilla.gnome.org/show_bug.cgi?id=723778)**
## Description
I have started a fakevideodec element here http://cgit.collabora.com/git/user/julien/gst-plugins-good.git/commit/?h=fakevideodec&id=7a4c1ce6e3ecaa35ffbd74b7e37968e3adc70485
It's useful when you have a new embedded platform and you want to know what would be the performance if you had a decoder that use 0% CPU. (hardware decoder except the zero-copy part)
videotestsrc is not really usable on embedded like RPI, I mean it uses so much CPU so not really useful to identify what would be the best FPS.
Also fpsdisplaysink uses textoverlay for the visual fps information. When you want a visual information only (and not a console info)
Also fakevideodec is compatible with playbin as long as you increase its rank.
For now fakevideodec just draw a kind of snake on 1 line (to make it use the CPU the less possible)
And the snake moves from left to right in 1 sec if no drop. So that when there are frame dropping the snake freez and you see it jumps to other positions. At every new frame it clears the line and draw the next position base on the framerate and the resolution.
I made it quite quickly so it may not being exactly correct right now.
Also even if it currently visually gives an idea of the FPS, it still does not allow to determine visually what is the precise FPS (can't say 24 or 25 FPS)
It could be improved to draw a kind of minimal meter and then draw a spot to indicate what is the current framerate. There are several ideas.
Do no hesitate to put a comment :)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/686qmlglsink: qt app stop rendering after setting the pipeline to NULL, all qti...2021-09-24T13:33:40ZLouis Leqmlglsink: qt app stop rendering after setting the pipeline to NULL, all qtimer stopped. Window updates the scene after moving the mouse then stop.Hi there, I'm running the qt app with GLVideoItem and qmlglsink example. It works fines and render the stream very well. I have set a timer to stop the stream (set pipeline state to NULL) after a couple of seconds, after that, all my tim...Hi there, I'm running the qt app with GLVideoItem and qmlglsink example. It works fines and render the stream very well. I have set a timer to stop the stream (set pipeline state to NULL) after a couple of seconds, after that, all my timers stop firing trigger, the app did not render it self, I have to move the mouse or switch to another window. After that, the scene call render for a couple of frames then stop again.
Anyone have experienced with this?
Note: I'm running the app on the wayland platform.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/687audiobuffersplit: Move to gst-plugins-good2021-09-24T13:33:41ZSebastian Drögeaudiobuffersplit: Move to gst-plugins-goodSee title. Are there any objections regarding the current API and code?
The element works reliable since quite some time in various places and is not very complicated.See title. Are there any objections regarding the current API and code?
The element works reliable since quite some time in various places and is not very complicated.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/690jpegenc is ignoring pixel-aspect-ratio2021-09-24T13:33:41ZMathieu Pierfittejpegenc is ignoring pixel-aspect-ratio`jpegenc` seems to be ignoring the `pixel-aspect-ratio` information from the caps, which can be a problem for non-square pixel ratios.
I found this bug trying to export JPEGs from a camera with a SAR of `95:112`, even though the caps we...`jpegenc` seems to be ignoring the `pixel-aspect-ratio` information from the caps, which can be a problem for non-square pixel ratios.
I found this bug trying to export JPEGs from a camera with a SAR of `95:112`, even though the caps were correct in my GStreamer pipeline: `[...]pixel-aspect-ratio=(fraction)95/112[...]`.
@ndufresne could reproduce the problem earlier on IRC:
>did a quick test here, and jpegenc seems to present some bug
>if I save a jpeg to disk with S/PAR 4:3, and then call gst-disoverer-1.0 -v test.jpg, it says the PAR is 1/1
>if I use ffprobe, it says Stream #0:0: Video: mjpeg (Baseline), yuvj420p(pc, bt470bg/unknown/unknown), 320x240 [SAR 1:1 DAR 4:3]
As he suggested, a workaround for now is to add `videoscale ! video/x-raw,pixel-aspect-ratio=1/1` after the decoder to force using square pixels.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/691rtpmp2tdepay: should advertise clock-rate=90000 by default to avoid bogus neg...2024-03-16T10:10:47ZTim-Philipp Müllertim@centricular.comrtpmp2tdepay: should advertise clock-rate=90000 by default to avoid bogus negotiation to clock-rate=1 if rate is missing in udpsrc caps`gst-launch-1.0 udpsrc caps=application/x-rtp,media=video ! rtpjitterbuffer ! rtpmp2tdepay ! fakesink -v`
makes `udpsrc` negotiate the following caps by default:
> application/x-rtp, media=(string)video, **clock-rate=(int)1**, encoding...`gst-launch-1.0 udpsrc caps=application/x-rtp,media=video ! rtpjitterbuffer ! rtpmp2tdepay ! fakesink -v`
makes `udpsrc` negotiate the following caps by default:
> application/x-rtp, media=(string)video, **clock-rate=(int)1**, encoding-name=(string)MP2T
which leads to two problems:
1. `rtpjitterbuffer` doesn't warn any more that the clock-rate is absent from the input caps
2. constant `rtpjitterbuffer.c:572:calculate_skew: delta - skew: 0:49:59.966666351 too big, reset skew` because timestamp interpretation is bogus now.
I think `rtpmp2tdepay` should advertise the normal 90000 clock-rate in its caps by default (as per the spec). I will prepare an MR for that.
Secondly, the fact that `udpsrc` does intersection/fixation here with the downstream caps seems a bit dubious. I can see how it makes things work with depayloaders where there's a standard rate, but in this case it's really quite wrong. I wonder if we should filter out int ranges for the clock-rate field "somewhere" (probably in the depayloader base class or `rtpjitterbuffer`)?Tim-Philipp Müllertim@centricular.comTim-Philipp Müllertim@centricular.comhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/694rtpjitterbuffer: need unit test for RTP-time to NTP-time scaling bug-fix2021-09-24T13:33:42ZNicolas Dufresnertpjitterbuffer: need unit test for RTP-time to NTP-time scaling bug-fixA bug fix was added into jitterbuffer in !470 without an appropriate unit test. I'm making this issue a blocker for 1.16 and 1.18 release.
cc @slomo @thaytan @hgr @pogojotzA bug fix was added into jitterbuffer in !470 without an appropriate unit test. I'm making this issue a blocker for 1.16 and 1.18 release.
cc @slomo @thaytan @hgr @pogojotzhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/697capssetter: negotiation failure2021-09-24T13:33:43ZEdward Herveycapssetter: negotiation failureExample pipeline : `videotestsrc ! video/x-raw,format=v210 ! videoconvert ! capssetter caps="video/x-raw" ! video/x-raw,format=UYVY ! fakesink`
This should not fail (the capssetter is in 'join' mode, which will add/override the incoming...Example pipeline : `videotestsrc ! video/x-raw,format=v210 ! videoconvert ! capssetter caps="video/x-raw" ! video/x-raw,format=UYVY ! fakesink`
This should not fail (the capssetter is in 'join' mode, which will add/override the incoming caps values). Theoretically `videoconvert` should end up negotiating to `UYVY`.... but it doesn't (it ends up doing passthrough).
The problem is that the caps transformation function of `capssetter` only works in one direction (converting upstream caps to downstream ones). When converting caps from downstream to upstream it either returns the query filter caps or ANY.
Ideally it *should* do something smarter to allow passing some of the downstream information (i.e. negotiated caps) upstream if at least the caps name is the same.
Further example: `capssetter caps="video/x-raw,pixel-aspect-ratio=8/9` if you wanted to override the PAR. In this case , when converting caps in reverse, capssetter could detect that the field will be overriden and therefore just return the downstream caps with the `pixel-aspect-ratio` field removed (it will replace it anyway).https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/698qmlglsink: can not be properly compiled with sysroot using meson2021-09-24T13:33:44ZVolodymyr Nazarchukqmlglsink: can not be properly compiled with sysroot using mesonI run meson on gst-plugins-good with such environment variables:
```
DESTDIR = /home/vavooon/build/ubuntu-base-19.10-base-amd64-root
PKG_CONFIG_SYSROOT_DIR = /home/vavooon/build/ubuntu-base-19.10-base-amd64-root
PKG_CONFIG_LIBDIR = /hom...I run meson on gst-plugins-good with such environment variables:
```
DESTDIR = /home/vavooon/build/ubuntu-base-19.10-base-amd64-root
PKG_CONFIG_SYSROOT_DIR = /home/vavooon/build/ubuntu-base-19.10-base-amd64-root
PKG_CONFIG_LIBDIR = /home/vavooon/build/ubuntu-base-19.10-base-amd64-root/usr/lib/x86_64-linux-gnu/pkgconfig
CFLAGS, CXXFLAGS, LDFLAGS = --sysroot=/home/vavooon/build/ubuntu-base-19.10-base-amd64-root
```
so meson is able to properly recognize all dependencies and compile/link against them.
E.g. here in `/ext/qt/meson.build:46`
```
qt5core_dep = dependency('Qt5Core', required: false)
```
If you print *qt5core_dep.compile_args* you'll see that it returns full path including sysroot: `/home/vavooon/build/ubuntu-base-19.10-base-amd64-root/usr/include/x86_64-linux-gnu/qt5`
But here in `/ext/qt/meson.build:50`
```
qt_include_dir = qt5core_dep.get_pkgconfig_variable('includedir')
```
If you inspect this one you'll see path only relative to sysroot `/usr/include/x86_64-linux-gnu/qt5`
So far I've prefixed it with my sysroot path for successful compilation but it looks it should be like:
```
qt_include_dir = get_option('pkgconfig-sysroot-path') + qt5core_dep.get_pkgconfig_variable('includedir')
```
I quickly searched in entire GStreamer repo and looks like there is couple of places with same behavior.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/701rtspsrc: not possible to skip particular stream with select-stream signal.2021-09-24T13:33:44Zcarrotstealerrtspsrc: not possible to skip particular stream with select-stream signal.**How to reproduce:**
Attach custom handler to rtspsrc "select-stream" signal.
Return FALSE from handler.
Check further "pad-added" signals.
**Expected:**
No "pad-added" should be invoked for unselected stream.
**Actual:**
"pad-adde...**How to reproduce:**
Attach custom handler to rtspsrc "select-stream" signal.
Return FALSE from handler.
Check further "pad-added" signals.
**Expected:**
No "pad-added" should be invoked for unselected stream.
**Actual:**
"pad-added" signal invoked for unselected stream.
Tested with Gstreamer 1.16.1 and GLib 2.62.0. Looks like related to recent GLib 2.62 [change](https://gitlab.gnome.org/GNOME/glib/merge_requests/1053?commit_id=153ac4c82a98d8b51b821d693ba8a570040acb57)
Log GStreamer 1.16.1 + GLib 2.62.0(selectSourceStream is my handler returning FALSE to skip stream)
```
0:00:00.190302000 598 0x4f0a90 DEBUG rtspsrc gstrtspsrc.c:501:default_select_stream:<src> default handler
0:00:00.190380334 598 0x4f0a90 DEBUG rtspsrc gstrtspsrc.c:512:select_stream_accum: accum 1
0:00:00.190476334 598 0x4f0a90 INFO CCTV_RECORDER RtspRecorder.cpp:92:selectSourceStream: skip source audio stream 1
0:00:00.190548000 598 0x4f0a90 DEBUG rtspsrc gstrtspsrc.c:512:select_stream_accum: accum 0
0:00:00.190624667 598 0x4f0a90 DEBUG rtspsrc gstrtspsrc.c:501:default_select_stream:<src> default handler
0:00:00.190693000 598 0x4f0a90 DEBUG rtspsrc gstrtspsrc.c:512:select_stream_accum: accum 1
0:00:00.190792667 598 0x4f0a90 DEBUG rtspsrc gstrtspsrc.c:7201:gst_rtspsrc_setup_streams_start:<src> doing setup of stream 0x73f0ea78 with rtsp://10.0.3.12/Streaming/Channels/101/trackID=2
```
Log GStreamer 1.16.1 + GLib 2.56.4(selectSourceStream is my handler returning FALSE to skip stream)
```
0:00:00.145556155 2093 0x5a0a90 DEBUG rtspsrc gstrtspsrc.c:501:default_select_stream:<src> default handler
0:00:00.145585697 2093 0x5a0a90 DEBUG rtspsrc gstrtspsrc.c:512:select_stream_accum: accum 1
0:00:00.145622364 2093 0x5a0a90 INFO CCTV_RECORDER RtspRecorder.cpp:92:selectSourceStream: skip source audio stream 1
0:00:00.145653115 2093 0x5a0a90 DEBUG rtspsrc gstrtspsrc.c:512:select_stream_accum: accum 0
0:00:00.145680490 2093 0x5a0a90 DEBUG rtspsrc gstrtspsrc.c:501:default_select_stream:<src> default handler
0:00:00.145713533 2093 0x5a0a90 DEBUG rtspsrc gstrtspsrc.c:7160:gst_rtspsrc_setup_streams_start:<src> skipping stream 0xb3f15228, disabled by signal
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/713Pipeline fails when multiudpsink has clients with ip address that does NOT EX...2021-09-24T13:33:47ZVyacheslavPipeline fails when multiudpsink has clients with ip address that does NOT EXIST in networkI use following pipeline to send audio:
gst-launch-1.0 -v uridecodebin uri=file:///tmp/1.mp3 ! audioconvert ! rtpL16pay ! multiudpsink clients=127.0.0.1:9000,192.168.0.138:9000,192.168.0.140:9000,192.168.0.141:9000,192.168.0.210:9000
an...I use following pipeline to send audio:
gst-launch-1.0 -v uridecodebin uri=file:///tmp/1.mp3 ! audioconvert ! rtpL16pay ! multiudpsink clients=127.0.0.1:9000,192.168.0.138:9000,192.168.0.140:9000,192.168.0.141:9000,192.168.0.210:9000
and receive:
gst-launch-1.0 -v udpsrc port=9000 caps="application/x-rtp, clock-rate=(int)44100, channels=(int)2" ! rtpL16depay ! audioconvert ! volume name=localVol volume=0.3 ! autoaudiosink
When some of 192.168... addresses is unavailable pipeline hangs every 3-5 seconds. So playing not acceptable.
When all addresses exists (simply response on ping, no need receiving pipeline) all works as expected.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/720baseparse: negotiation failure with eac3 stream, default caps are set to audi...2021-09-24T13:33:49ZArnaud Vracbaseparse: negotiation failure with eac3 stream, default caps are set to audio/x-ac3Hi,
The following video fails to play with a negotiation error:
gst-play-1.0 https://absolut.zogzog.org/share/samples/mkv/eac3_nego_failure.mka
The video contains two EAC3 streams, which matroskademux properly exposes as audio/x-eac3....Hi,
The following video fails to play with a negotiation error:
gst-play-1.0 https://absolut.zogzog.org/share/samples/mkv/eac3_nego_failure.mka
The video contains two EAC3 streams, which matroskademux properly exposes as audio/x-eac3. ac3parse can also parse those streams independently with no issue.
However, during an initial GAP event, baseparse will report default caps with audio/x-ac3. Since ac3parse reports both audio/x-eac3 and audio/x-ac3 in its sink templates caps, baseparse incorrectly assumes ac3parse is able to convert from eac3 to ac3. decodebin then plugs an ac3 decoder, and the negotiation fails by the time ac3parse actually set audio/x-eac3 on its source pad.
The parser should be able to report it cannot determine the proper output caps yet, and prevent baseparse from setting wrong default caps.
There is already an old case describing a similar issue: gstreamer/gstreamer#263https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/728rtph265pay: F bit not properly used/propagated for aggregate packets2021-09-24T13:33:50ZEdward Herveyrtph265pay: F bit not properly used/propagated for aggregate packetsWhen dealing with aggregated packets, `rtph265pay` should propagate the 'F' bit
accordingly.
There are 2 problems, both in `gst_rtp_h265_pay_send_bundle()`.
* `guint ap_header[2]` is used unitialized by `ap_header[0] |= 0x80;`
``` c
...When dealing with aggregated packets, `rtph265pay` should propagate the 'F' bit
accordingly.
There are 2 problems, both in `gst_rtp_h265_pay_send_bundle()`.
* `guint ap_header[2]` is used unitialized by `ap_header[0] |= 0x80;`
``` c
guint8 ap_header[2];
/* ... */
/* Propagate F bit */
if ((nal_header[0] & 0x80))
ap_header[0] |= 0x80;
```
* It is then completely overwritten when being set in the top-level RTP header:
``` c
ap_header[0] = (AP_TYPE_ID << 1) | (layer_id & 0x20);
ap_header[1] = ((layer_id & 0x1F) << 3) | (temporal_id & 0x07);
gst_buffer_fill (outbuf, 0, &ap_header, sizeof ap_header);
```
(See also CID 1455496)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/731qtdemux(?): colorimetry issue2021-09-24T13:33:51ZPhilippe Normandqtdemux(?): colorimetry issueThis video has 3 frames, one red, one green, one blue. The problem is that the green one has an rgb value of `(0, 113, 0)` instead of `(0, 126, 0)`.
I'm not sure this is a qtdemux bug yet. Just filing it here as temporary placeholder fo...This video has 3 frames, one red, one green, one blue. The problem is that the green one has an rgb value of `(0, 113, 0)` instead of `(0, 126, 0)`.
I'm not sure this is a qtdemux bug yet. Just filing it here as temporary placeholder for now.
![animated-red-green-blue](/uploads/5f81df406f4fb0b296fbe41cf2435db1/animated-red-green-blue.mp4)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/734qtdemux: Wrong first buffer running time with a certain file2021-09-24T13:33:51ZDavid Ingqtdemux: Wrong first buffer running time with a certain fileWith ![`video`](/uploads/c68425fa44fd397d7a57d844d796e1f9/video.m4v) the first outputted video frame running time is at 0.5sec, it should be at 0. More details in the comments.
----
I am using Gstreamer 1.16.1.
Suppose I have a video ...With ![`video`](/uploads/c68425fa44fd397d7a57d844d796e1f9/video.m4v) the first outputted video frame running time is at 0.5sec, it should be at 0. More details in the comments.
----
I am using Gstreamer 1.16.1.
Suppose I have a video file where the first frame has a timestamp of 0.1 seconds, and the last frame has a timestamp of 1.1 seconds. For this file, `GstDiscoverer` correctly reports the duration to be 1.0 seconds.
If I create a `GESClip` for the file, say with an inpoint at 0, then the first 0.1 seconds of the composition is blank (because there were no frames in the source file until the timestamp at 0.1). This behavior is correct.
If my clip is intended to play for a time which takes it past the timestamp at 1.0, then the clip cannot be added to the layer because `timeline_tree_can_move_element` will say that the clip is invalid in some way. The function `timeline_tree_can_move_element` seems to be assuming that the maximum timestamp in the source file is the same thing as the duration of the source file, but this is not true for files where the earliest timestamp is above zero.
The faulty logic seems to be in here:
* `timeline_tree_can_move_element`
* `check_track_elements_overlaps_and_values`https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/743rtsp/rtpsession: No way to reset BYE status2021-09-24T13:33:53ZEdward Herveyrtsp/rtpsession: No way to reset BYE statusWhen doing seeks on a remote server, we could very well end up with the following situation:
* Seek close to the end of the stream
* Server pushes everything out and sends BYE RTCP message
* That bye is not acted upon immediately in...When doing seeks on a remote server, we could very well end up with the following situation:
* Seek close to the end of the stream
* Server pushes everything out and sends BYE RTCP message
* That bye is not acted upon immediately in rtpsession, but it stored to be acted upon on the next RTCP_thread timeout
* Seek again somewhere else
* Data starts flowing again
* The rtpsession rtcp_thread times out, sees that a stream got a BYE message and informs rtspsrc
* rtspsrc sends EOS stopping the stream
What should happen is that we should be able (from rtspsrc or any other rtpsession user) to inform rtpsession that we *are* requesting new data on the same streams and that it should reset the BYE status of the various streams
This is *one* of the reason of the various hangs with rtspsrc validate testshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/744jack: Uses a boxed type for the client property2021-09-24T13:33:53ZSebastian Drögejack: Uses a boxed type for the client propertyThis is a boxed type around the `JackClient` from jack itself. But as this is plugin API, application code has a hard time to actually construct a boxed value for this.
Also the way how it is registered defeats the purpose of boxed type...This is a boxed type around the `JackClient` from jack itself. But as this is plugin API, application code has a hard time to actually construct a boxed value for this.
Also the way how it is registered defeats the purpose of boxed types. There is no memory management at all, this is completely unsafe would've been more correct as a `G_TYPE_POINTER` property:
```cpp
static gpointer
gst_jack_client_copy (gpointer jclient)
{
return jclient;
}
static void
gst_jack_client_free (gpointer jclient)
{
return;
}
```
CC @wtayhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/746rtpjitterbuffer: Add reliable test for EOS2021-09-24T13:33:54ZNicolas Dufresnertpjitterbuffer: Add reliable test for EOS!608 is currently covered sometimes by a validate test. To void this type of bug coming back, we should also write a reliable test. This normally required for all rtpjitterbuffer tests.
cc @hgr!608 is currently covered sometimes by a validate test. To void this type of bug coming back, we should also write a reliable test. This normally required for all rtpjitterbuffer tests.
cc @hgrhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/748jitterbuffer: Flushing and timer thread2021-09-24T13:33:55ZEdward Herveyjitterbuffer: Flushing and timer threadAlmost all rtsp *seeking* validate tests are failing right now, one part of it is related to how jitterbuffer handles flushing.
The timer thread is:
* Started in READY=>PAUSED (but actually blocked until PAUSED=>PLAYING)
* Stopped in PA...Almost all rtsp *seeking* validate tests are failing right now, one part of it is related to how jitterbuffer handles flushing.
The timer thread is:
* Started in READY=>PAUSED (but actually blocked until PAUSED=>PLAYING)
* Stopped in PAUSED=>READY (but the blocked variable is set in PLAYING=>PAUSED)
The problem is that this assumes that the jitterbuffer:
* Will only ever go to PLAYING once
* Will never ever get any FLUSH events (resetting the contents)
* By extension will never see more than one EOS
If the jitterbuffer receives a flush start/stop events:
* It won't reset all the timers (especially the EOS one)
* It won't stop waiting and put itself in a "before anything arrived" state
When the pads are deactivated (PAUSED=>READY) that thread won't put itself in a "Ready to be stoped" state either which can cause various deadlockshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/758multiudpsink and udpsink ipv6 support for the "clients" property2021-09-24T13:33:56Zbicbenmultiudpsink and udpsink ipv6 support for the "clients" propertyWhen I'm using udpsink element with ipv6 addresses it works fine if I define the destination through "host" and "port" properties but when I'm using the "clients" property in both udpsink and multiudpsink the elements don't send anything...When I'm using udpsink element with ipv6 addresses it works fine if I define the destination through "host" and "port" properties but when I'm using the "clients" property in both udpsink and multiudpsink the elements don't send anything.
If I run a simple debug pipeline like `GST_DEBUG=*udpsink*:5 gst-launch-1.0 videotestsrc ! udpsink clients="2001:8db6:85a3:8d3:1319:8a2e:370:7348:5004"` the debug output says that the udpsink is trying to send data to host 2001 with port 8. In other words it reacts to the first colon symbol as an end of host address and a start of the port number.
I was trying surround the host part with square brackets, shoving "\\" before the colon symbols and many other things.
Moreover if I use the "add" signal to add a new destination it adds ipv6 addresses in the same manner as in the pipeline described above.
I understand that there IS a method to use ipv6 addresses in "clients" property because the source code of those elements clearly have methods to use and sort them but there are no documentations and/or tutorials about the proper syntax or manner of using the ipv6 addresses so it is too obscure for me. Hope you understand, thank you.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/759gstreamer pipeline cannot put tags into m4a file2023-08-14T07:59:56Zsezanzebgstreamer pipeline cannot put tags into m4a fileMaybe I'm just doing it wrong, but it somewhat looks like a bug to some nice people from the gstreamer irc and me. I had it posted on StackOverflow as well, but didn't get answers so far: https://stackoverflow.com/questions/62609411/gstr...Maybe I'm just doing it wrong, but it somewhat looks like a bug to some nice people from the gstreamer irc and me. I had it posted on StackOverflow as well, but didn't get answers so far: https://stackoverflow.com/questions/62609411/gstreamer-pipeline-cannot-put-tags-into-m4a-file
Using the following pipeline
```
gst-launch-1.0 filesrc location="/home/mango/Desktop/gst-test/input.mp3" name=src \
! decodebin \
! audioconvert \
! faac \
! mp4mux \
! filesink location="/home/mango/Desktop/gst-test/output.m4a" \
```
I get
`0:00:00.046300293 8742 0x7f4e340779e0 WARN audioencoder gstaudioencoder.c:965:gst_audio_encoder_finish_frame:<faac0> Can't copy metadata because input buffer disappeared`
It also happens with avenc_aac.
mp4mux is in plugins_good, decodebin in plugins_base and faac in plugins_bad according to gst-inspect-1.0, so I don't know which repo to use to post this issue.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/760avimux: should error out if video input caps are missing2021-09-24T13:33:57ZFolkert van Heusdenavimux: should error out if video input caps are missing[gst.cpp](/uploads/3fcf33cdf08cb6cc2ee1b01ec38147b9/gst.cpp)
When running this program, you'll end up with test.avi which has resolution 0x0 and > 30 fps.[gst.cpp](/uploads/3fcf33cdf08cb6cc2ee1b01ec38147b9/gst.cpp)
When running this program, you'll end up with test.avi which has resolution 0x0 and > 30 fps.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/765souphttpsrc: "don't fail when seeking past the end of the content" needs a test2021-09-24T13:33:57ZSebastian Drögesouphttpsrc: "don't fail when seeking past the end of the content" needs a testThe following discussion from !385 should be addressed:
- [ ] @ndufresne started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/385#note_399908): (+4 comments)
> That looks aligned with t...The following discussion from !385 should be addressed:
- [ ] @ndufresne started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/385#note_399908): (+4 comments)
> That looks aligned with the intent. Do you think you could contribute a test into https://gitlab.freedesktop.org/gstreamer/gst-integration-testsuites ? This is a good candidate for gst-validate since seeking passed the end of a file seems to be something we'd like to have consistent across all sources/formats.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/766matroskaparse/matroskademux Fails when TrackUID is 02021-10-01T00:23:56Zahokamatroskaparse/matroskademux Fails when TrackUID is 0When loading a webm/mkv file with a TrackUID of 0 gstreamer fails to play the file.
I checked the Matroska specification and saw that this should be the case, but files with TrackUID's of 0 still play in many other applications (Chrome, ...When loading a webm/mkv file with a TrackUID of 0 gstreamer fails to play the file.
I checked the Matroska specification and saw that this should be the case, but files with TrackUID's of 0 still play in many other applications (Chrome, Firefox, mpv, ffplay) to name a few.
Instead of the erroring out in this situation, would it not be better to just throw a warning and continue?
Attached is a webm file which triggers the described event.
![test](/uploads/57813d9c2bed6a685c2c2ef8f606c1b6/test.webm)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/769rtpbin: warning: rtpsource.c:XXXX:calculate_jitter: cannot get clock-rate for...2021-09-24T13:33:58ZPeter Srtpbin: warning: rtpsource.c:XXXX:calculate_jitter: cannot get clock-rate for pt NNI've been trying to debug other issues I've been having by setting GST_DEBUG=2, however the logs were getting spammed with the following warning message repeatedly. (the full log is attached)
```
0:00:00.159406572 5991 0x1422800 WARN ...I've been trying to debug other issues I've been having by setting GST_DEBUG=2, however the logs were getting spammed with the following warning message repeatedly. (the full log is attached)
```
0:00:00.159406572 5991 0x1422800 WARN rtpsource rtpsource.c:1013:calculate_jitter: cannot get clock-rate for pt 96
```
Digging into the related code it seems that for whatever reason rtpsource is unable to obtain the clock-rate through the use of callbacks. I don't have the log handy but I have seen that in one different test case it was able to correctly get the clock-rate as part of rtp_source_update_caps, but then would some how set it back to -1 and then continually warn me that it couldn't get it as part of the callback from fetch_clock_rate_from_payload.
```
0:00:00.139710579 5991 0x1422800 DEBUG rtpsource rtpsource.c:1058:init_seq: base_seq 3737
0:00:00.139730486 5991 0x1422800 DEBUG rtpsource rtpsource.c:1137:update_receiver_stats: probation: seqnr 3737 == expected 3737
0:00:00.139748005 5991 0x1422800 DEBUG rtpsource rtpsource.c:1151:update_receiver_stats: probation 1: queue packet
0:00:00.158875276 5991 0x1422800 DEBUG rtpbin gstrtpbin.c:3481:pt_map_requested:<rtpbin> payload map requested for pt 96 in session 0
0:00:00.158921295 5991 0x1422800 DEBUG rtpbin gstrtpbin.c:881:get_pt_map: searching pt 96 in cache
0:00:00.158970998 5991 0x1422800 DEBUG rtpbin gstrtpbin.c:894:get_pt_map: emitting signal for pt 96 in session 0
0:00:00.159028406 5991 0x1422800 DEBUG rtpbin gstrtpbin.c:945:get_pt_map: no pt map could be obtained
0:00:00.159078202 5991 0x1422800 DEBUG rtpbin gstrtpbin.c:3492:pt_map_requested:<rtpbin> could not get caps
0:00:00.159130665 5991 0x1422800 DEBUG rtpsession gstrtpsession.c:1667:gst_rtp_session_get_caps_for_pt:<rtpsession0> could not get caps
0:00:00.159178035 5991 0x1422800 DEBUG rtpsession rtpsession.c:1542:source_clock_rate: got clock-rate -1 for pt 96
0:00:00.159225554 5991 0x1422800 DEBUG rtpsource rtpsource.c:944:fetch_clock_rate_from_payload: got clock-rate -1
0:00:00.159275609 5991 0x1422800 DEBUG rtpsource rtpsource.c:1137:update_receiver_stats: probation: seqnr 3738 == expected 3738
0:00:00.159315794 5991 0x1422800 DEBUG rtpsource rtpsource.c:1146:update_receiver_stats: probation done!
0:00:00.159363479 5991 0x1422800 DEBUG rtpsource rtpsource.c:1058:init_seq: base_seq 3738
0:00:00.159406572 5991 0x1422800 WARN rtpsource rtpsource.c:1013:calculate_jitter: cannot get clock-rate for pt 96
```
Here are the two commands used. (each run in a different terminal).
```
gst-launch-1.0 rtpbin name=rtpbin \
audiotestsrc ! amrnbenc ! rtpamrpay ! rtpbin.send_rtp_sink_0 \
rtpbin.send_rtp_src_0 ! udpsink host=127.0.0.1 port=5002 \
rtpbin.send_rtcp_src_0 ! udpsink host=127.0.0.1 port=5003 sync=false async=false \
udpsrc port=5007 ! rtpbin.recv_rtcp_sink_0
gst-launch-1.0 -v rtpbin name=rtpbin \
udpsrc caps="application/x-rtp,media=(string)audio,clock-rate=(int)8000,encoding-name=(string)AMR,encoding-params=(string)1,octet-align=(string)1" \
port=5002 ! rtpbin.recv_rtp_sink_0 \
rtpbin. ! rtpamrdepay ! amrnbdec ! alsasink \
udpsrc port=5003 ! rtpbin.recv_rtcp_sink_0 \
rtpbin.send_rtcp_src_0 ! udpsink host=127.0.0.1 port=5007 sync=false async=false
```
The full error log with "export GST_DEBUG=2,rtp*:5" is attached to help see the full context.
[simple_example_cannot_get_clock_rate_for_pt.txt](/uploads/b5d33f0f5efcc5465aff7c51e91d8ceb/simple_example_cannot_get_clock_rate_for_pt.txt)
I'm not really sure why it keeps saying "no pt map could be obtained" when the caps are specified on the udpsrc.
I also tried writing a custom program where I implement the callback for "request-pt-map" but it didn't seem to have any effect. I'm not sure if I needed to force clear the pt cache with "clear-pt-map" or not.
Anyways I would have thought the example provided above should work fine as the cap is available for the udpsrc, and the rtpjitterbuffer has not difficulty getting the clock-rate from the caps.
```
0:00:00.162786993 5991 0x1422800 DEBUG rtpjitterbuffer gstrtpjitterbuffer.c:1408:gst_jitter_buffer_sink_parse_caps:<rtpjitterbuffer0> got caps application/x-rtp, media=(string)audio, clock-rate=(int)8000, encoding-name=(string)AMR, encoding-params=(string)1, octet-align=(string)1, ssrc=(uint)2921936800
0:00:00.162815456 5991 0x1422800 DEBUG rtpjitterbuffer gstrtpjitterbuffer.c:1430:gst_jitter_buffer_sink_parse_caps:<rtpjitterbuffer0> got clock-rate 8000
```
Let me know if there's any additional information I can provide that would help me determine if I am just doing something wrong or if there is some issue causing rtpbin to not be able to supply the caps to rtpsession and rtpsource (perhaps due to missing callbacks).
I've reproduced this on 1.14, 1.16.2 and 1.17.2.1 (the latest master)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/770souphttpsrc: Dynamic blocksize adjustment constantly increases blocksize, cau...2021-09-24T13:33:59ZCarlos Rafael Gianisouphttpsrc: Dynamic blocksize adjustment constantly increases blocksize, causing problems with queue2 bufferingIn a pipeline with souphttpsrc and a downstream queue2 element, souphttpsrc's dynamic blocksize adjustment can cause problems, because the blocksize constantly increases.
I was able to see the constant increases with this test command l...In a pipeline with souphttpsrc and a downstream queue2 element, souphttpsrc's dynamic blocksize adjustment can cause problems, because the blocksize constantly increases.
I was able to see the constant increases with this test command line:
gst-launch-1.0 souphttpsrc location="<HTTP audio stream URL>" ! identity silent=false ! queue2 max-size-buffers=1 max-size-bytes=0 max-size-time=0 ! decodebin ! fakesink sync=true -v
Result:
```
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (32768 bytes, dts: none, pts: none, duration: none, offset: 39232, offset_end: -1, flags: 00000000 , meta: none) 0x7f7c3ae520
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (65536 bytes, dts: none, pts: none, duration: none, offset: 72000, offset_end: -1, flags: 00000000 , meta: none) 0x7f7c3ae630
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (131072 bytes, dts: none, pts: none, duration: none, offset: 137536, offset_end: -1, flags: 00000000 , meta: none) 0x7f840484b0
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (238416 bytes, dts: none, pts: none, duration: none, offset: 268608, offset_end: -1, flags: 00000000 , meta: none) 0x7f840485c0
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (262144 bytes, dts: none, pts: none, duration: none, offset: 507024, offset_end: -1, flags: 00000000 , meta: none) 0x7f840486d0
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (524288 bytes, dts: none, pts: none, duration: none, offset: 769168, offset_end: -1, flags: 00000000 , meta: none) 0x7f840487e0
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (1048576 bytes, dts: none, pts: none, duration: none, offset: 1293456, offset_end: -1, flags: 00000000 , meta: none) 0x7f840488f0
```
I then disabled the dynamic blocksize adjustment in souphttpsrc to verify. Result:
```
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (8192 bytes, dts: none, pts: none, duration: none, offset: 6952, offset_end: -1, flags: 00000000 , meta: none) 0x7f905c3300
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (13416 bytes, dts: none, pts: none, duration: none, offset: 15144, offset_end: -1, flags: 00000000 , meta: none) 0x7f905c3410
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (7140 bytes, dts: none, pts: none, duration: none, offset: 28560, offset_end: -1, flags: 00000000 , meta: none) 0x7f905c3520
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (4284 bytes, dts: none, pts: none, duration: none, offset: 35700, offset_end: -1, flags: 00000000 , meta: none) 0x7f905c3630
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (11424 bytes, dts: none, pts: none, duration: none, offset: 39984, offset_end: -1, flags: 00000000 , meta: none) 0x7f980494b0
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (7140 bytes, dts: none, pts: none, duration: none, offset: 51408, offset_end: -1, flags: 00000000 , meta: none) 0x7f980495c0
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (5712 bytes, dts: none, pts: none, duration: none, offset: 58548, offset_end: -1, flags: 00000000 , meta: none) 0x7f980496d0
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (4284 bytes, dts: none, pts: none, duration: none, offset: 64260, offset_end: -1, flags: 00000000 , meta: none) 0x7f980497e0
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (1428 bytes, dts: none, pts: none, duration: none, offset: 68544, offset_end: -1, flags: 00000000 , meta: none) 0x7f980498f0
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (2856 bytes, dts: none, pts: none, duration: none, offset: 69972, offset_end: -1, flags: 00000000 , meta: none) 0x7f98049a00
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (4284 bytes, dts: none, pts: none, duration: none, offset: 72828, offset_end: -1, flags: 00000000 , meta: none) 0x7f98049b10
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (2856 bytes, dts: none, pts: none, duration: none, offset: 77112, offset_end: -1, flags: 00000000 , meta: none) 0x7f98049c20
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (5712 bytes, dts: none, pts: none, duration: none, offset: 79968, offset_end: -1, flags: 00000000 , meta: none) 0x7f98049d30
```
Commit 1081a2ee50885f69375f12144bda6ae3bf3c3498 in gst-plugins-good at least applies some degree of limitation, but the buffer size still gets big enough to match the capacity of queue2. The result is that in typical HTTP streaming pipelines, the queue2 then only has room for one incoming buffer, so the buffer fill level constantly switches between 0% and 100%. (Note: The test pipeline above artificially limits the queue2 capacity to 1 buffer, but this is only for testing purposes.) Since applications typically pause when the buffering message reports <100%, this ultimately results in a stuttering playback, because the player pauses & unpauses all the time.
The proper solution perhaps would be a new type of query sent downstream by souphttpsrc to ask what max buffer size is allowed. If queue2 exists downstream, it could then pick a number that guarantees that at least N buffers fit into it. Aside from that, some sort of "max-dynamic-blocksize" property would perhaps make sense. It would act as a hard limit for dynamically adjusted buffer sizes. Default value 0 (= no limit). If it is set to a value smaller than that of the blocksize property, it would result in a GObject warning (since that would make no sense).https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/774H264 compatibility issue with RTP (no window pops up)2021-09-24T13:34:00ZFengyu GaoH264 compatibility issue with RTP (no window pops up)I'm working on Ubuntu 20.04, with GStreamer 1.16.2 and FFmpeg 4.2.2
Here's detailed steps to reproduce the issue.
1. Download test video from https://www.freedesktop.org/software/gstreamer-sdk/data/media/sintel_trailer-480p.webm
2. Con...I'm working on Ubuntu 20.04, with GStreamer 1.16.2 and FFmpeg 4.2.2
Here's detailed steps to reproduce the issue.
1. Download test video from https://www.freedesktop.org/software/gstreamer-sdk/data/media/sintel_trailer-480p.webm
2. Convert to VP9 / PCM with FFmpeg command `ffmpeg -i sintel.webm -c:v vp9 -ar 8000 -ac 1 -c:a pcm_s16le sintel-vp9-pcm.mkv`
3. Convert to H264 / PCM with FFmpeg command `ffmpeg -i sintel.webm -c:v libx264 -ar 8000 -ac 1 -c:a pcm_s16le sintel-h264-pcm.mkv`
Now we have two video files, sintel-vp9-pcm.mkv and sintel-h264-pcm.mkv, and we are going to send the video / audio streams by RTP.
Commands for VP9 are:
```bash
# sender
gst-launch-1.0 rtpbin name=rtpbin \
filesrc location=/tmp/sintel-vp9-pcm.mkv ! matroskademux name=demux \
demux.audio_0 ! "audio/x-raw, format=S16LE, width=16, rate=8000, channels=1, layout=interleaved" ! alawenc ! rtppcmapay ! rtpbin.send_rtp_sink_0 \
demux.video_0 ! rtpvp9pay ! rtpbin.send_rtp_sink_1 \
rtpbin.send_rtp_src_0 ! udpsink host=127.0.0.1 port=5000 sync=true async=false \
rtpbin.send_rtcp_src_0 ! udpsink host=127.0.0.1 port=5001 sync=false async=false \
rtpbin.send_rtp_src_1 ! udpsink host=127.0.0.1 port=5002 sync=true async=false \
rtpbin.send_rtcp_src_1 ! udpsink host=127.0.0.1 port=5003 sync=false async=false
# client
gst-launch-1.0 rtpbin name=rtpbin \
udpsrc address=127.0.0.1 port=5000 caps="application/x-rtp, media=audio, encoding-name=PCMA, clock-rate=8000" ! rtpbin.recv_rtp_sink_0 \
udpsrc address=127.0.0.1 port=5001 caps="application/x-rtcp" ! rtpbin.recv_rtcp_sink_0 \
udpsrc address=127.0.0.1 port=5002 caps="application/x-rtp, media=video, encoding-name=VP9, clock-rate=90000" ! rtpbin.recv_rtp_sink_1 \
udpsrc address=127.0.0.1 port=5003 caps="application/x-rtcp" ! rtpbin.recv_rtcp_sink_1 \
rtpbin. ! rtppcmadepay ! queue ! autoaudiosink sync=true \
rtpbin. ! rtpvp9depay ! queue ! avdec_vp9 ! autovideosink sync=true
```
It works and a window will pop up showing the video with audio.
Commands for H264 are:
```bash
# sender
gst-launch-1.0 rtpbin name=rtpbin \
filesrc location=/tmp/sintel-h264-pcm.mkv ! matroskademux name=demux \
demux.audio_0 ! "audio/x-raw, format=S16LE, width=16, rate=8000, channels=1, layout=interleaved" ! alawenc ! rtppcmapay ! rtpbin.send_rtp_sink_0 \
demux.video_0 ! rtph264pay ! rtpbin.send_rtp_sink_1 \
rtpbin.send_rtp_src_0 ! udpsink host=127.0.0.1 port=5000 sync=true async=false \
rtpbin.send_rtcp_src_0 ! udpsink host=127.0.0.1 port=5001 sync=false async=false \
rtpbin.send_rtp_src_1 ! udpsink host=127.0.0.1 port=5002 sync=true async=false \
rtpbin.send_rtcp_src_1 ! udpsink host=127.0.0.1 port=5003 sync=false async=false
# client
gst-launch-1.0 rtpbin name=rtpbin \
udpsrc address=127.0.0.1 port=5000 caps="application/x-rtp, media=audio, encoding-name=PCMA, clock-rate=8000" ! rtpbin.recv_rtp_sink_0 \
udpsrc address=127.0.0.1 port=5001 caps="application/x-rtcp" ! rtpbin.recv_rtcp_sink_0 \
udpsrc address=127.0.0.1 port=5002 caps="application/x-rtp, media=video, encoding-name=H264, clock-rate=90000" ! rtpbin.recv_rtp_sink_1 \
udpsrc address=127.0.0.1 port=5003 caps="application/x-rtcp" ! rtpbin.recv_rtcp_sink_1 \
rtpbin. ! rtppcmadepay ! queue ! autoaudiosink sync=true \
rtpbin. ! rtph264depay ! queue ! avdec_h264 ! autovideosink sync=true
```
It does not work and no window pops up. There is no warning / error logs either.
It seems that something's wrong with the elements' internal implementations, or an appropriate warning / error message is absent.
The test video files are provided as attachments:
[sintel-h264-pcm.mkv.zip](/uploads/ea7e8834fc5fbcda7b2ce9d9d984cc49/sintel-h264-pcm.mkv.zip)
[sintel-vp9-pcm.mkv.zip](/uploads/bb2e6fd296142e138b89665c574cb85c/sintel-vp9-pcm.mkv.zip)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/776ONVIF Profile-T Camera RTSP stream stops after 1 minute2022-02-17T21:30:40ZYousf AteyaONVIF Profile-T Camera RTSP stream stops after 1 minuteWhen using gstreamer to process RTSP stream from camera with onvif [profile-T](https://www.onvif.org/profiles/profile-t/) support, the stream stops after 1 minute.
How to reproduce (Same behaviour on 1.16.2 and 1.17.2):
`gst-launch-1.0...When using gstreamer to process RTSP stream from camera with onvif [profile-T](https://www.onvif.org/profiles/profile-t/) support, the stream stops after 1 minute.
How to reproduce (Same behaviour on 1.16.2 and 1.17.2):
`gst-launch-1.0 rtspsrc location="rtsp://admin:pass@192.168.22.145:554/media/video1" protocols=tcp ! queue ! checksumsink`
Profile-T onvif cameras negotiates video and meta data streams
```
DESCRIBE rtsp://192.168.22.145:554/media/video1 RTSP/1.0
Accept: application/sdp
CSeq: 3
User-Agent: Lavf58.29.100
Authorization: Digest username="admin", realm="999a63d42ca1", nonce="999ad5e322732acb606dae0f68567f11", uri="rtsp://192.168.22.145:554/media/video1", response="999434127ac6b07a2861077c50e2f111"
RTSP/1.0 200 OK
CSeq: 3
Content-Base: rtsp://192.168.22.145:554/media/video1
Content-Length: 546
Content-Type: application/sdp
v=0
o=- 1001 1 IN IP4 192.168.22.145
s=VCP IPC Realtime stream
m=video 0 RTP/AVP 105
c=IN IP4 192.168.22.145
a=control:rtsp://192.168.22.145/media/video1/video
a=rtpmap:105 H264/90000
a=fmtp:105 profile-level-id=640032; packetization-mode=1; sprop-parameter-sets=999q2EAQwgCGEAQwgCGEAQwgCEO1AUAFrTcBAQFAAAD6AAAw1CEA==,aO4xs77=
a=recvonly
m=application 0 RTP/AVP 107
c=IN IP4 192.168.22.145
a=control:rtsp://192.168.22.145/media/video1/metadata
a=rtpmap:107 vnd.onvif.metadata/90000
a=fmtp:107 DecoderTag=h3c-v3 RTCP=0
a=recvonly
```
Channel `media/video1/metadata` receives few packets when the stream starts, then no more packets are sent.
The problem starts to happen after sometime (around 15 seconds after stream starts), with this DEBUG log message:
> rtpsession rtpsession.c:3855:session_cleanup:�[00m sender source 0e5ab0bb timed out and became receiver, last 44:53:26.230475361
Because the `media/video1/metadata` channel is not a continuous stream like `media/video1/video`, camera will only send packets when there is some camera event (like motion or tampering). Since no packets are being received, rtp session changed this source to receiver.
After around 20 seconds, rtspsrc decides that this `metadata` stream is EOS; with this DEBUG log messages:
> rtspsrc gstrtspsrc.c:3458:on_timeout_common:<rtspsrc0>�[00m source 0e5ab0bb, stream 0e5ab0bb in session 1 timed out
> rtspsrc gstrtspsrc.c:3417:gst_rtspsrc_do_stream_eos:<rtspsrc0>�[00m setting stream for session 1 to EOS
After some time (normally each minute), camera will send few packets on the `media/video1/metadata` channel. When rtsp tries to send this packet to the rtp session, it will find it is EOS already.
> rtspsrc gstrtspsrc.c:6043:gst_rtspsrc_loop:<rtspsrc0>�[00m pausing task, reason eos
Then rtsp will stop consuming TCP packets, video will freeze and TCP buffers will keep filling up, until it TCP buffer is 100% , then connection will be closed.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/780scaletempo: glitchy audio when playing backwards2021-09-24T13:34:01ZJoe Neemanscaletempo: glitchy audio when playing backwardsscaletempo is working well for me when playing forwards, but not when playing backwards.
The first issue is that the sound has lots of artifacts, almost as though the buffers are being played in reverse, but each individual buffer is no...scaletempo is working well for me when playing forwards, but not when playing backwards.
The first issue is that the sound has lots of artifacts, almost as though the buffers are being played in reverse, but each individual buffer is not being reversed. I had a quick look at the source and this doesn't look like the problem, but maybe it's because there is no 2-byte-sample code path in reverse_buffer? scaletempo claims to take F32LE, F64LE, and S6LE as both sink and src.
The second issue is that sometimes when changing from speed 1.0 to speed -1.0, the audio simply cuts out. I can't replicate this with other speed changes (e.g. 1.0 to -1.1 works reliably).
Here is a short rust program that demonstrates both issues:
https://gist.github.com/jneem/b95f20fbbea4708a166abce7d8b174ad
To run the example:
- install a rust toolchain if you don't have one
- make a directory (say gst-test) and put the Cargo.toml file there
- make a subdirectory called "src" and put the main.rs file there
- run "cargo run", and then use the left/right arrow keys to change speedhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/782gtkglsink: spurious X11 error2023-10-25T07:48:06ZIvan Molodetskikhgtkglsink: spurious X11 errorI have a Flatpak app which displays a video in a `GtkGlSink`: https://flathub.org/apps/details/org.gnome.gitlab.YaLTeR.VideoTrimmer
When running under a Ubuntu 18.04 VM under X11, it frequently, but not always, crashes with an X11 error...I have a Flatpak app which displays a video in a `GtkGlSink`: https://flathub.org/apps/details/org.gnome.gitlab.YaLTeR.VideoTrimmer
When running under a Ubuntu 18.04 VM under X11, it frequently, but not always, crashes with an X11 error upon opening the screen with the `GtkGlSink`:
```
(video-trimmer:2): Gdk-ERROR **: 14:57:15.591: The program 'video-trimmer' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
(Details: serial 398 error_code 8 request_code 150 (GLX) minor_code 34)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
```
Sometimes this message is also printed:
```
Xlib: sequence lost (0x1027c > 0x27f) in reply type 0x0!
```
Doing as the error message suggests, I get this backtrace:
```
#0 0x00007ffff7625c80 in gdk_x_error (xdisplay=0x5555558e7440, error=0x7fff93ffe850) at gdkmain-x11.c:271
#1 0x00007ffff7ebb30b in _XError (dpy=0x5555558e7440, rep=0x7fff93ffe950) at ../../src/XlibInt.c:1489
#2 0x00007fffedd2f10f in () at /usr/lib/x86_64-linux-gnu/GL/default/lib/libGLX_mesa.so.0
#3 0x00007fffedd29030 in () at /usr/lib/x86_64-linux-gnu/GL/default/lib/libGLX_mesa.so.0
#4 0x00007fffeed1d44c in glXCreateContextAttribsARB (dpy=0x5555558e7440, config=0x555555d3c030, share_list=0x555555dcf7f0, direct=1, attrib_list=0x7fff93ffeaa0) at ../../../src/GLX/libglx.c:305
#5 0x00007fffeeea5b4d in _create_context_with_flags (contextFlags=1, profileMask=1, minor=<optimized out>, major=<optimized out>, share_context=0x555555dcf7f0, fbconfig=0x555555d3c030, dpy=0x5555558e7440, context_glx=0x555555b787b0 [GstGLContextGLX]) at ../gst-libs/gst/gl/x11/gstglcontext_glx.c:182
#6 0x00007fffeeea5b4d in gst_gl_context_glx_create_context (context=0x555555b787b0 [GstGLContextGLX], gl_api=65539, other_context=<optimized out>, error=0x7ffff4841290) at ../gst-libs/gst/gl/x11/gstglcontext_glx.c:263
#7 0x00007fffeee7e5de in gst_gl_context_create_thread (context=0x555555b787b0 [GstGLContextGLX]) at ../gst-libs/gst/gl/gstglcontext.c:1238
#8 0x00007ffff7111731 in g_thread_proxy (data=0x7fffe4003520) at ../glib/gthread.c:807
#9 0x00007ffff6f255e2 in start_thread (arg=<optimized out>) at pthread_create.c:479
#10 0x00007ffff6e38413 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
Full backtrace:
```
#0 0x00007ffff7625c80 in gdk_x_error (xdisplay=0x5555558e7440, error=0x7fff93ffe850) at gdkmain-x11.c:271
#1 0x00007ffff7ebb30b in _XError (dpy=0x5555558e7440, rep=0x7fff93ffe950) at ../../src/XlibInt.c:1489
rtn_val = <optimized out>
event = {type = 0, xany = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416}, xkey = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, root = 140735676410080, subwindow = 140735676410048, time = 93824995990688, x = -1811945288, y = 32767, x_root = -155382679, y_root = 32767, state = 636, keycode = 0, same_screen = -155382363}, xbutton = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, root = 140735676410080, subwindow = 140735676410048, time = 93824995990688, x = -1811945288, y = 32767, x_root = -155382679, y_root = 32767, state = 636, button = 0, same_screen = -155382363}, xmotion = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, root = 140735676410080, subwindow = 140735676410048, time = 93824995990688, x = -1811945288, y = 32767, x_root = -155382679, y_root = 32767, state = 636, is_hint = 0 '\000', same_screen = -155382363}, xcrossing = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, root = 140735676410080, subwindow = 140735676410048, time = 93824995990688, x = -1811945288, y = 32767, x_root = -155382679, y_root = 32767, mode = 636, detail = 0, same_screen = -155382363, focus = 32767, state = 4}, xfocus = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, mode = -1811945248, detail = 32767}, xexpose = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, x = -1811945248, y = 32767, width = -1811945280, height = 32767, count = 1435409568}, xgraphicsexpose = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, drawable = 140735661905416, x = -1811945248, y = 32767, width = -1811945280, height = 32767, count = 1435409568, major_code = 21845, minor_code = -1811945288}, xnoexpose = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, drawable = 140735661905416, major_code = -1811945248, minor_code = 32767}, xvisibility = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, state = -1811945248}, xcreatewindow = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, parent = 140735661905416, window = 140735676410080, x = -1811945280, y = 32767, width = 1435409568, height = 21845, border_width = -1811945288, override_redirect = 32767}, xdestroywindow = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, event = 140735661905416, window = 140735676410080}, xunmap = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, event = 140735661905416, window = 140735676410080, from_configure = -1811945280}, xmap = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, event = 140735661905416, window = 140735676410080, override_redirect = -1811945280}, xmaprequest = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, parent = 140735661905416, window = 140735676410080}, xreparent = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, event = 140735661905416, window = 140735676410080, parent = 140735676410048, x = 1435409568, y = 21845, override_redirect = -1811945288}, xconfigure = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, event = 140735661905416, window = 140735676410080, x = -1811945280, y = 32767, width = 1435409568, height = 21845, border_width = -1811945288, above = 140737332972649, override_redirect = 636}, xgravity = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, event = 140735661905416, window = 140735676410080, x = -1811945280, y = 32767}, xresizerequest = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, width = -1811945248, height = 32767}, xconfigurerequest = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, parent = 140735661905416, window = 140735676410080, x = -1811945280, y = 32767, width = 1435409568, height = 21845, border_width = -1811945288, above = 140737332972649, detail = 636, value_mask = 140737332972965}, xcirculate = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, event = 140735661905416, window = 140735676410080, place = -1811945280}, xcirculaterequest = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, parent = 140735661905416, window = 140735676410080, place = -1811945280}, xproperty = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, atom = 140735676410080, time = 140735676410048, state = 1435409568}, xselectionclear = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, selection = 140735676410080, time = 140735676410048}, xselectionrequest = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, owner = 140735661905416, requestor = 140735676410080, selection = 140735676410048, target = 93824995990688, property = 140735676410040, time = 140737332972649}, xselection = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, requestor = 140735661905416, selection = 140735676410080, target = 140735676410048, property = 93824995990688, time = 140735676410040}, xcolormap = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, colormap = 140735676410080, new = -1811945280, state = 32767}, xclient = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, message_type = 140735676410080, format = -1811945280, data = {b = "\240\234\216UUU\000\000\270\350\377\223\377\177\000\000i\f\275", <incomplete sequence \366>, s = {-25440, 21902, 21845, 0, -5960, -27649, 32767, 0, 3177, -2371}, l = {93824995990688, 140735676410040, 140737332972649, 636, 140737332972965}}}, xmapping = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, request = -1811945248, first_keycode = 32767, count = -1811945280}, xerror = {type = 0, display = 0x5555558e7440, resourceid = 33554483, serial = 636, error_code = 8 '\b', request_code = 150 '\226', minor_code = 34 '"'}, xkeymap = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, key_vector = "\340\350\377\223\377\177\000\000\300\350\377\223\377\177\000\000\240\234\216UUU\000\000\270\350\377\223\377\177\000"}, xgeneric = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, extension = -1826449912, evtype = 32767}, xcookie = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, extension = -1826449912, evtype = 32767, cookie = 2483022048, data = 0x7fff93ffe8c0}, pad = {140733193388032, 93824995980352, 33554483, 636, 140735661905416, 140735676410080, 140735676410048, 93824995990688, 140735676410040, 140737332972649, 636, 140737332972965, 4, 0, 636, 140735676410080, 0, 0, 0, 0, 0, 0, 17179869184, 0}}
async = <optimized out>
next = <optimized out>
#2 0x00007fffedd2f10f in () at /usr/lib/x86_64-linux-gnu/GL/default/lib/libGLX_mesa.so.0
#3 0x00007fffedd29030 in () at /usr/lib/x86_64-linux-gnu/GL/default/lib/libGLX_mesa.so.0
#4 0x00007fffeed1d44c in glXCreateContextAttribsARB (dpy=0x5555558e7440, config=0x555555d3c030, share_list=0x555555dcf7f0, direct=1, attrib_list=0x7fff93ffeaa0) at ../../../src/GLX/libglx.c:305
context = 0x0
vendor = 0x555555c28c00
#5 0x00007fffeeea5b4d in _create_context_with_flags (contextFlags=1, profileMask=1, minor=<optimized out>, major=<optimized out>, share_context=0x555555dcf7f0, fbconfig=0x555555d3c030, dpy=0x5555558e7440, context_glx=0x555555b787b0 [GstGLContextGLX]) at ../gst-libs/gst/gl/x11/gstglcontext_glx.c:182
ret = <optimized out>
attribs = {8337, 4, 8338, 5, 8340, 1, 37158, 1, 0, 1, 8, 1, 9, 1, 10, 1, 12, 16, 5, 1}
x_error = 0
n = <optimized out>
profileMask = 1
contextFlags = 1
context_glx = 0x555555b787b0 [GstGLContextGLX]
window = 0x555555bbc8b0 [GstGLWindowX11]
window_x11 = 0x555555bbc8b0 [GstGLWindowX11]
display = 0x55555592a5f0 [GstGLDisplayX11]
create_context = <optimized out>
glx_exts = <optimized out>
device = 0x5555558e7440
external_gl_context = 93825001125872
__func__ = "gst_gl_context_glx_create_context"
#6 0x00007fffeeea5b4d in gst_gl_context_glx_create_context (context=0x555555b787b0 [GstGLContextGLX], gl_api=65539, other_context=<optimized out>, error=0x7ffff4841290) at ../gst-libs/gst/gl/x11/gstglcontext_glx.c:263
profileMask = 1
contextFlags = 1
context_glx = 0x555555b787b0 [GstGLContextGLX]
window = 0x555555bbc8b0 [GstGLWindowX11]
window_x11 = 0x555555bbc8b0 [GstGLWindowX11]
display = 0x55555592a5f0 [GstGLDisplayX11]
create_context = <optimized out>
glx_exts = <optimized out>
device = 0x5555558e7440
external_gl_context = 93825001125872
__func__ = "gst_gl_context_glx_create_context"
#7 0x00007fffeee7e5de in gst_gl_context_create_thread (context=0x555555b787b0 [GstGLContextGLX]) at ../gst-libs/gst/gl/gstglcontext.c:1238
context_class = 0x7fffe4008380
window_class = 0x7fffe4009540
compiled_api = 65539
user_api = GST_GL_API_ANY
gl_api = <optimized out>
display_api = GST_GL_API_ANY
api_string = <optimized out>
compiled_api_s = 0x7fffe40021a0 "opengl opengl3 gles2"
user_api_s = 0x7fffe4009900 "any"
display_api_s = 0x7fff88001360 "any"
user_choice = <optimized out>
error = 0x7ffff4841290
other_context = 0x555555b5c190 [GstGLWrappedContext]
__func__ = "gst_gl_context_create_thread"
#8 0x00007ffff7111731 in g_thread_proxy (data=0x7fffe4003520) at ../glib/gthread.c:807
thread = 0x7fffe4003520
__func__ = "g_thread_proxy"
#9 0x00007ffff6f255e2 in start_thread (arg=<optimized out>) at pthread_create.c:479
ret = <optimized out>
pd = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140735676413696, -8133131588441933399, 140737295683806, 140737295683807, 140735676411008, 140735676413696, 8133052422939015593, 8133116158072781225}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 0
#10 0x00007ffff6e38413 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
Runtimes I'm using:
```
Application ID Version Branch
org.freedesktop.Platform.GL.default 19.08
org.freedesktop.Platform.ffmpeg-full 19.08
org.freedesktop.Platform.openh264 2.1.0 2.0
org.gnome.Platform 3.36
org.gnome.Sdk 3.36
org.gnome.gitlab.YaLTeR.VideoTrimmer 0.2.0 stable
org.gnome.gitlab.YaLTeR.VideoTrimmerDevel 0.2.0 master
org.gtk.Gtk3theme.Ambiance 3.22
```
I couldn't figure out what `.Debug` to install to get libGLX debug info.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/784rpicamsrc: lookup for bcm_host and friends using dependency mechanics2021-09-24T13:34:03ZRoman Valovrpicamsrc: lookup for bcm_host and friends using dependency mechanicsHello,
I'm cross-compiling GStreamer 1.18 for RPi board and found there are several components that depend on `bcm_host` library and friends. However various components detect libraries in inconsistent ways.
Whereas [gst-omx](https://g...Hello,
I'm cross-compiling GStreamer 1.18 for RPi board and found there are several components that depend on `bcm_host` library and friends. However various components detect libraries in inconsistent ways.
Whereas [gst-omx](https://gitlab.freedesktop.org/gstreamer/gst-omx/-/blob/master/examples/egl/meson.build) and [gst-gl](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/gst-libs/gst/gl/meson.build) relies on the dependency mechanics, the `rpicamsrc` introduces two additional options.
Please use the same `dependency` mechanics for `rpicamsrc` to detect `bcm_host` libraries.
In this case it's only enough to add `$sys_root/opt/vc/lib/pkgconfig` additional path to `pkg_config_libdir` in order to make all `bcm_hiost` dependent parts to build.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/789qtmux: cannot reliably wait to fix caps before the first buffer2021-09-24T13:34:03ZMatthew Watersmatthew@centricular.comqtmux: cannot reliably wait to fix caps before the first bufferProblem has to do with the aggregator design, the internal aggregator sink pad queue and around aggregator's delayed negotiation in general.
1. Caps events are serialised so are pushed through the queue just like buffers.
2. qtmux conta...Problem has to do with the aggregator design, the internal aggregator sink pad queue and around aggregator's delayed negotiation in general.
1. Caps events are serialised so are pushed through the queue just like buffers.
2. qtmux contains a hook at the start of the queue to reject caps changes once successfully set
3. caps successfully set is decided in the src aggregator task
This is also racy-ish but qtmux will not output until all sink pads have caps so that is mitigated there.
Any attempt to move to fixing the caps at the generation of the first output buffer would introduce a race where the caps could make it into the sink event queue and then be rejected. This means that that input stream would not be muxed at all (or maybe even appear to hang) depending on timings with some scenarios.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/791rtspsrc: Cannot run in UWP ARM64 and x64 environments (v 1.18.0)2022-04-14T14:23:02ZNHarishGitrtspsrc: Cannot run in UWP ARM64 and x64 environments (v 1.18.0)v1.18.0 RTSP server running on Win 10 platform
(1) Running "**gst-launch-1.0 rtspsrc location=rtsp://192.168.50.167:8554/realtime latency=0 ! decodebin ! autovideosink sync=false**" yields perfect results on Win 10 machine itself
(2...v1.18.0 RTSP server running on Win 10 platform
(1) Running "**gst-launch-1.0 rtspsrc location=rtsp://192.168.50.167:8554/realtime latency=0 ! decodebin ! autovideosink sync=false**" yields perfect results on Win 10 machine itself
(2) Running same pipeline with slight change in the sink as "**rtspsrc location=rtsp://192.168.50.167:8554/realtime latency=0 ! decodebin ! appsink name=videoSink sync=false**" on a Hololens 2, yields the following error:
Info: **_g_io_module_get_default**: Found default implementation dummy (GDummyProxyResolver) for ‘gio-proxy-resolver’The thread 0x1730 has exited with code 0 (0x0).
error in module rtspsrc0 reported: Could not get/set settings from/on resource. - ../gst/rtsp/gstrtspsrc.c(7527): **gst_rtspsrc_setup_streams_start **(): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0:
**Could not setup transport.**https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/795osxaudiodeviceprovider: no audio source for USB device2021-09-24T13:34:05ZRoman Shpuntovosxaudiodeviceprovider: no audio source for USB deviceI have USB audio card `Scarlett 2i2 USB` and `gst-device-monitor-1.0` displays it as sink device, but there is not source (`microphone` input) device. This is standard audio USB device with the support builtin system drivers. I use gstre...I have USB audio card `Scarlett 2i2 USB` and `gst-device-monitor-1.0` displays it as sink device, but there is not source (`microphone` input) device. This is standard audio USB device with the support builtin system drivers. I use gstreamer 1.18 downloaded from site. Also I see USB audio input device in the macOS `Sound` system preferences.
```
bash-3.2$ gst-device-monitor-1.0
Probing devices...
Device found:
name : FaceTime HD Camera (Built-in)
class : Video/Source
caps : video/x-raw(memory:GLMemory), width=1280, height=720, format=UYVY, framerate={ (fraction)10000000/333333, (fraction)10000000/344827, (fraction)5000000/178571, (fraction)1000000/37037, (fraction)2000000/76923, (fraction)25/1, (fraction)5000000/208333, (fraction)5000000/217391, (fraction)2000000/90909, (fraction)1000000/47619, (fraction)20/1, (fraction)2000000/105263, (fraction)2000000/111111, (fraction)2000000/117647, (fraction)16/1, (fraction)5000000/333333, (fraction)2000000/142857, (fraction)1000000/76923, (fraction)10000000/833333, (fraction)1000000/90909, (fraction)10/1, (fraction)10000000/1111111, (fraction)8/1, (fraction)10000000/1428571, (fraction)5000000/833333, (fraction)5/1, (fraction)4/1, (fraction)10000000/3333333, (fraction)2/1, (fraction)1/1 }, texture-target=rectangle
video/x-raw(memory:GLMemory), width=640, height=480, format=UYVY, framerate={ (fraction)10000000/333333, (fraction)10000000/344827, (fraction)5000000/178571, (fraction)1000000/37037, (fraction)2000000/76923, (fraction)25/1, (fraction)5000000/208333, (fraction)5000000/217391, (fraction)2000000/90909, (fraction)1000000/47619, (fraction)20/1, (fraction)2000000/105263, (fraction)2000000/111111, (fraction)2000000/117647, (fraction)16/1, (fraction)5000000/333333, (fraction)2000000/142857, (fraction)1000000/76923, (fraction)10000000/833333, (fraction)1000000/90909, (fraction)10/1, (fraction)10000000/1111111, (fraction)8/1, (fraction)10000000/1428571, (fraction)5000000/833333, (fraction)5/1, (fraction)4/1, (fraction)10000000/3333333, (fraction)2/1, (fraction)1/1 }, texture-target=rectangle
video/x-raw, width=1280, height=720, format={ (string)UYVY, (string)YUY2, (string)NV12, (string)BGRA }, framerate={ (fraction)1/1, (fraction)2/1, (fraction)10000000/3333333, (fraction)4/1, (fraction)5/1, (fraction)5000000/833333, (fraction)10000000/1428571, (fraction)8/1, (fraction)10000000/1111111, (fraction)10/1, (fraction)1000000/90909, (fraction)10000000/833333, (fraction)1000000/76923, (fraction)2000000/142857, (fraction)5000000/333333, (fraction)16/1, (fraction)2000000/117647, (fraction)2000000/111111, (fraction)2000000/105263, (fraction)20/1, (fraction)1000000/47619, (fraction)2000000/90909, (fraction)5000000/217391, (fraction)5000000/208333, (fraction)25/1, (fraction)2000000/76923, (fraction)1000000/37037, (fraction)5000000/178571, (fraction)10000000/344827, (fraction)10000000/333333 }
video/x-raw, width=640, height=480, format={ (string)UYVY, (string)YUY2, (string)NV12, (string)BGRA }, framerate={ (fraction)1/1, (fraction)2/1, (fraction)10000000/3333333, (fraction)4/1, (fraction)5/1, (fraction)5000000/833333, (fraction)10000000/1428571, (fraction)8/1, (fraction)10000000/1111111, (fraction)10/1, (fraction)1000000/90909, (fraction)10000000/833333, (fraction)1000000/76923, (fraction)2000000/142857, (fraction)5000000/333333, (fraction)16/1, (fraction)2000000/117647, (fraction)2000000/111111, (fraction)2000000/105263, (fraction)20/1, (fraction)1000000/47619, (fraction)2000000/90909, (fraction)5000000/217391, (fraction)5000000/208333, (fraction)25/1, (fraction)2000000/76923, (fraction)1000000/37037, (fraction)5000000/178571, (fraction)10000000/344827, (fraction)10000000/333333 }
properties:
device.api = avf
avf.unique_id = 0x8020000005ac8514
avf.model_id = "UVC\ Camera\ VendorID_1452\ ProductID_34068"
avf.has_flash = false
avf.has_torch = false
avf.manufacturer = "Apple\ Inc."
gst-launch-1.0 avfvideosrc device-index=0 ! ...
Device found:
name : MacBook Pro Speakers
class : Audio/Sink
caps : audio/x-raw, format=F32LE, layout=interleaved, rate=44100, channels=2, channel-mask=0x0000000000000003
audio/x-raw, format={ (string)F64LE, (string)F64BE, (string)F32LE, (string)F32BE, (string)S32LE, (string)S32BE, (string)U32LE, (string)U32BE, (string)S24_32LE, (string)S24_32BE, (string)U24_32LE, (string)U24_32BE, (string)S24LE, (string)S24BE, (string)U24LE, (string)U24BE, (string)S20LE, (string)S20BE, (string)U20LE, (string)U20BE, (string)S18LE, (string)S18BE, (string)U18LE, (string)U18BE, (string)S16LE, (string)S16BE, (string)U16LE, (string)U16BE, (string)S8, (string)U8 }, layout=interleaved, rate=[ 1, 2147483647 ], channels=2, channel-mask=0x0000000000000003
audio/x-raw, format={ (string)F64LE, (string)F64BE, (string)F32LE, (string)F32BE, (string)S32LE, (string)S32BE, (string)U32LE, (string)U32BE, (string)S24_32LE, (string)S24_32BE, (string)U24_32LE, (string)U24_32BE, (string)S24LE, (string)S24BE, (string)U24LE, (string)U24BE, (string)S20LE, (string)S20BE, (string)U20LE, (string)U20BE, (string)S18LE, (string)S18BE, (string)U18LE, (string)U18BE, (string)S16LE, (string)S16BE, (string)U16LE, (string)U16BE, (string)S8, (string)U8 }, layout=interleaved, rate=[ 1, 2147483647 ], channels=1
gst-launch-1.0 ... ! osxaudiosink device=82
Device found:
name : MacBook Pro Microphone
class : Audio/Source
caps : audio/x-raw, format=F32LE, layout=interleaved, rate=48000, channels=1
audio/x-raw, format={ (string)F64LE, (string)F64BE, (string)F32LE, (string)F32BE, (string)S32LE, (string)S32BE, (string)U32LE, (string)U32BE, (string)S24_32LE, (string)S24_32BE, (string)U24_32LE, (string)U24_32BE, (string)S24LE, (string)S24BE, (string)U24LE, (string)U24BE, (string)S20LE, (string)S20BE, (string)U20LE, (string)U20BE, (string)S18LE, (string)S18BE, (string)U18LE, (string)U18BE, (string)S16LE, (string)S16BE, (string)U16LE, (string)U16BE, (string)S8, (string)U8 }, layout=interleaved, rate=48000, channels=2, channel-mask=0x0000000000000003
audio/x-raw, format={ (string)F64LE, (string)F64BE, (string)F32LE, (string)F32BE, (string)S32LE, (string)S32BE, (string)U32LE, (string)U32BE, (string)S24_32LE, (string)S24_32BE, (string)U24_32LE, (string)U24_32BE, (string)S24LE, (string)S24BE, (string)U24LE, (string)U24BE, (string)S20LE, (string)S20BE, (string)U20LE, (string)U20BE, (string)S18LE, (string)S18BE, (string)U18LE, (string)U18BE, (string)S16LE, (string)S16BE, (string)U16LE, (string)U16BE, (string)S8, (string)U8 }, layout=interleaved, rate=48000, channels=1
gst-launch-1.0 osxaudiosrc device=89 ! ...
Device found:
name : Scarlett 2i2 USB
class : Audio/Sink
caps : audio/x-raw, format=F32LE, layout=interleaved, rate=192000, channels=2, channel-mask=0x0000000000000003
audio/x-raw, format={ (string)F64LE, (string)F64BE, (string)F32LE, (string)F32BE, (string)S32LE, (string)S32BE, (string)U32LE, (string)U32BE, (string)S24_32LE, (string)S24_32BE, (string)U24_32LE, (string)U24_32BE, (string)S24LE, (string)S24BE, (string)U24LE, (string)U24BE, (string)S20LE, (string)S20BE, (string)U20LE, (string)U20BE, (string)S18LE, (string)S18BE, (string)U18LE, (string)U18BE, (string)S16LE, (string)S16BE, (string)U16LE, (string)U16BE, (string)S8, (string)U8 }, layout=interleaved, rate=[ 1, 2147483647 ], channels=2, channel-mask=0x0000000000000003
audio/x-raw, format={ (string)F64LE, (string)F64BE, (string)F32LE, (string)F32BE, (string)S32LE, (string)S32BE, (string)U32LE, (string)U32BE, (string)S24_32LE, (string)S24_32BE, (string)U24_32LE, (string)U24_32BE, (string)S24LE, (string)S24BE, (string)U24LE, (string)U24BE, (string)S20LE, (string)S20BE, (string)U20LE, (string)U20BE, (string)S18LE, (string)S18BE, (string)U18LE, (string)U18BE, (string)S16LE, (string)S16BE, (string)U16LE, (string)U16BE, (string)S8, (string)U8 }, layout=interleaved, rate=[ 1, 2147483647 ], channels=1
gst-launch-1.0 ... ! osxaudiosink device=109
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/797rtspsrc: Use fallback stream when getting invalid transport headers2021-09-24T13:34:06ZStian Bergliertspsrc: Use fallback stream when getting invalid transport headersWhen trying to connect to a stream where the server replies with invalid headers we get 'Server did not select transport' error and the stream is not played. This happens even if the video transport header is ok and audio transport is th...When trying to connect to a stream where the server replies with invalid headers we get 'Server did not select transport' error and the stream is not played. This happens even if the video transport header is ok and audio transport is the only invalid header.
If the audio transport header parsing fails, it should try parsing the video transport header and show stream without audio if parsing of video header is fine. And also vice-versa.
The same stream with invalid audio transport header is tested and shown to be supported by several other media player such as VLC, where the stream will be shown without the audio track.
Ref. [issue #787](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/787#note_628833), where the audio transport header was invalid from server side:
`0:00:00.997070000 7576 126F3378 LOG rtspsrc gstrtspsrc.c:9647:dump_key_value:<source> key: 'Transport', value: 'Transport: RTP/AVP;unicast;client_port=59576-59577;server_port=21438-21439;source=192.168.105.5;destination=192.168.5.1'`
Quote @slomo comment:
> The problem is that the server is sending `Transport: Transport: RTP/AVP...`, so sending an invalid Transport header that has the header name duplicated in the value. So a broken server here
The issue was solved by fixing the header from server side in this case, but it would be nice to have a fallback in case it should happen with other servers as well.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/799rtph264depay: bytestream/AU output doesn't output individual AUs/frames per b...2021-09-24T13:34:06ZSebastian Drögertph264depay: bytestream/AU output doesn't output individual AUs/frames per buffer```sh
gst-launch-1.0 videotestsrc pattern=ball ! video/x-raw,width=1280,height=720,framerate=25/1 ! timeoverlay halignment=center valignment=center ! tee name=t ! queue ! x264enc tune=zerolatency key-int-max=50 ! video/x-h264,profile=con...```sh
gst-launch-1.0 videotestsrc pattern=ball ! video/x-raw,width=1280,height=720,framerate=25/1 ! timeoverlay halignment=center valignment=center ! tee name=t ! queue ! x264enc tune=zerolatency key-int-max=50 ! video/x-h264,profile=constrained-baseline ! rtph264pay config-interval=-1 aggregate-mode=zero-latency ! rtph264depay ! video/x-h264,stream-format=byte-stream,alignment=au ! fakesink silent=false -v
```
See e.g.
```
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (1191 bytes, dts: 1000:00:07.960000000, pts: 1000:00:07.960000000, duration: none, offset: -1, offset_end: -1, flags: 00002200 marker delta-unit , meta: none) 0x7fd45828e6c0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (481 bytes, dts: 1000:00:08.000000000, pts: 1000:00:08.000000000, duration: none, offset: -1, offset_end: -1, flags: 00000000 , meta: none) 0x7fd45828e120
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (378 bytes, dts: none, pts: 1000:00:08.000000000, duration: none, offset: -1, offset_end: -1, flags: 00000000 , meta: none) 0x7fd45828ec60
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (438 bytes, dts: none, pts: 1000:00:08.000000000, duration: none, offset: -1, offset_end: -1, flags: 00000000 , meta: none) 0x7fd45828e6c0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (6054 bytes, dts: 1000:00:08.000000000, pts: 1000:00:08.000000000, duration: none, offset: -1, offset_end: -1, flags: 00000000 , meta: none) 0x7fd450019900
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (378 bytes, dts: none, pts: 1000:00:08.000000000, duration: none, offset: -1, offset_end: -1, flags: 00000000 , meta: none) 0x7fd45828e5a0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (746 bytes, dts: none, pts: 1000:00:08.000000000, duration: none, offset: -1, offset_end: -1, flags: 00000000 , meta: none) 0x7fd45828e6c0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (563 bytes, dts: 1000:00:08.000000000, pts: 1000:00:08.000000000, duration: none, offset: -1, offset_end: -1, flags: 00000000 , meta: none) 0x7fd450019900
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (439 bytes, dts: none, pts: 1000:00:08.000000000, duration: none, offset: -1, offset_end: -1, flags: 00000200 marker , meta: none) 0x7fd450019ea0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (2022 bytes, dts: 1000:00:08.040000000, pts: 1000:00:08.040000000, duration: none, offset: -1, offset_end: -1, flags: 00002200 marker delta-unit , meta: none) 0x7fd45828e360
```
All the buffers with `1000:00:08.000000000` timestamp are decoding to a single frame.
Having `rtph264depay` output AVC/AU and then let `h264parse` convert that to bytestream/AU works around this problem. Simply putting an `h264parse disable-passthrough=true` there does **not** work around it, so there's probably also a bug in `h264parse` here.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/806fragmentation units type b (FU-B) are not supported in gstrtph264depay2023-07-08T10:03:19Zuharbandfragmentation units type b (FU-B) are not supported in gstrtph264depayin gstrtph264depay fu-b packets are not handled correctly. the DON (decoder order number) bytes are ignored
`case 29:
{
/* FU-A Fragmentation unit 5.8 */
/* FU-B Fragmentation unit ...in gstrtph264depay fu-b packets are not handled correctly. the DON (decoder order number) bytes are ignored
`case 29:
{
/* FU-A Fragmentation unit 5.8 */
/* FU-B Fragmentation unit 5.8 */
gboolean S, E;`
note that the bytes ARE taken into account in the STAB-B packet type though:
`case 25:
/* STAP-B Single-time aggregation packet 5.7.1 */
/* 2 byte extra header for DON */
header_len += 2;
/* fallthrough */`
this causes a stream with packetization-mode = 2 (interleaved mode) to fail with this pluignhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/813wavparse: Add operation modes2021-09-24T13:34:08ZDavid Fernandez Lopezwavparse: Add operation modesHi,
We have detected a problem with the wavparse element when you want to reproduce several files in a row in a streaming mode. If you set the property ignore_length to TRUE, headers are read as media and played sound make some artifact...Hi,
We have detected a problem with the wavparse element when you want to reproduce several files in a row in a streaming mode. If you set the property ignore_length to TRUE, headers are read as media and played sound make some artifacts at the start of every file.
Our proposal is to add three operations mode and deprecating the ignore_length property. These modes are:
* GST_WAVPARSE_MODE_DEFAULT
* GST_WAVPARSE_MODE_STREAMING -> Length is taken into account like in DEFAULT mode but an EOS is never sent when the end is achieved. This allows to reproduce several files in a row.
* GST_WAVPARSE_MODE_STREAMING_IGNORE_LENGTH -> Length found in a data chunk is ignored. This may be useful for streamed audio where the length is unknown until the end of streaming.
You can find a patch with these changes attached [0001-wavparse-Add-working-modes.patch](/uploads/14b48b29f31b8ae91eaed8df99ec314b/0001-wavparse-Add-working-modes.patch)
Thanks in advance.
Regards.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/814qtdemux: Inconsitent handling of UNKNOWN colorimetry field2021-09-24T13:34:09ZNicolas Dufresneqtdemux: Inconsitent handling of UNKNOWN colorimetry fieldI'm a bit puzzled, I've hit a use case where some colorimetry field are 0 and lead to negotiation failure with v4l2h264dec (something also a bit broken in v4l2h264dec, I can admit). Now, looking at qtdemux first, I notice that handling o...I'm a bit puzzled, I've hit a use case where some colorimetry field are 0 and lead to negotiation failure with v4l2h264dec (something also a bit broken in v4l2h264dec, I can admit). Now, looking at qtdemux first, I notice that handling of "UNKNOWN" field is inconsistent. For VP9, we ignore anything that would have unkown, but for `colr` we don't.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/gst/isomp4/qtdemux.c#L11841
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/gst/isomp4/qtdemux.c#L8509
I'm filling an issue to understand which way is right, of course for me the VP9 way would fix stuff, but I want to get the rationales before sending patches.
cc @slomo @seungha.yanghttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/815udpsink: Is it possible to set qos-dscp on windows? Any attempt shows no resu...2021-09-24T13:34:11ZMaximDanilovudpsink: Is it possible to set qos-dscp on windows? Any attempt shows no results in Wiresharkhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/824Pipeline blocking when part of an mp4mux is not receiving data2021-09-24T13:34:15ZWayne PiekarskiPipeline blocking when part of an mp4mux is not receiving dataI have a use case where I'm recording from multiple video and audio udpsrc sources and combining them with an mp4mux. If one of them does not receive any packets, the entire pipeline blocks and there is no output.
I have managed to prod...I have a use case where I'm recording from multiple video and audio udpsrc sources and combining them with an mp4mux. If one of them does not receive any packets, the entire pipeline blocks and there is no output.
I have managed to produce a simple test case that demonstrates this behavior:
`
gst-launch-1.0 mp4mux name=combo fragment-duration=1000 ! fakesink async=false videotestsrc pattern=ball is-live=true ! video/x-raw, framerate=15/1, width=320, height=240 ! x264enc bitrate=1000 speed-preset=1 ! h264parse ! tee name=tv0 ! queue ! h264parse ! avdec_h264 ! videoconvert ! autovideosink async=false tv0. ! queue ! combo.video_0 udpsrc port=5701 ! application/x-rtp, clock-rate=44100, config=40002410adca00 ! rtpmp4adepay ! aacparse ! queue ! combo.audio_1
`
The ball moves for a few frames, then stops forever. If you send some packets to port 5701 then the ball starts moving again.
If you remove the mp4mux then everything works fine, each pipeline can run separately with async=false. I reported this with gstreamer 1.16 [2] but at the time mp4mux did not implement GstAggregator, but in 1.18 this was added in [1]. So I believe the pipeline above should work even with no udpsrc input coming in.
[1] https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/commit/e2462005fbac72bd49c4158e9476c5f76919f887
[2] https://lists.freedesktop.org/archives/gstreamer-devel/2019-August/072575.htmlhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/828rtpsession: old addresses do not get removed from conflict table2021-09-24T13:34:16ZYury Shatzrtpsession: old addresses do not get removed from conflict tableWe have our application working in a docker container. Docker routes incoming RTP stream to the appropriate port on our container. Our application sees these packets as coming from a random port on the host machine (e.g. 172.18.0.1:38724...We have our application working in a docker container. Docker routes incoming RTP stream to the appropriate port on our container. Our application sees these packets as coming from a random port on the host machine (e.g. 172.18.0.1:38724). It turns out that docker changes that port periodically (every 2 minutes in our experience).
In default mode, rtpsession thinks it is a different stream and starts to drop buffers every two minutes.
We set it to **favor-new=true**, and it helps. Port changes, it works.
After a few HOURS, docker reuses the port it was using a few hours before. And then rtpsession starts to drop buffers.
The reason is - old address is still in the table of conflicting addresses.
```c
if (rtp_source_find_conflicting_address (source,
pinfo->address, pinfo->current_time)) {
gchar *buf1;
buf1 = __g_socket_address_to_string (pinfo->address);
GST_LOG ("Known conflict on %x for %s, dropping packet", ssrc,
buf1);
g_free (buf1);
return TRUE;
```
It seems from rtp_source_timeout that it should have expired long ago. But I don't think this function is ever called.
Either someone needs to call rtp_source_timeout periodically, or we need a "super-favor-new" mode. Or a check for collision agd in find_conflicting_addresshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/837qtmux: need remove moov track when release pad2021-09-24T13:34:20ZKevin Songqtmux: need remove moov track when release padBelow code in gst_qt_mux_request_new_pad() will add track in moov. But don't remove it in gst_qt_mux_release_pad(). Our video encoder don't support one preset. it will call request pad and then release pad for the first try. But the outp...Below code in gst_qt_mux_request_new_pad() will add track in moov. But don't remove it in gst_qt_mux_release_pad(). Our video encoder don't support one preset. it will call request pad and then release pad for the first try. But the output mp4 file can't be playback as below code. Do we need remove moov track in release pad function or need put below code in other function to delay add moov track?
qtpad->trak = atom_trak_new (qtmux->context);
atom_moov_add_trak (qtmux->moov, qtpad->trak);https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/838deinterlace : Regression handling telecine/onefield streams2021-09-24T13:34:20ZEdward Herveydeinterlace : Regression handling telecine/onefield streamsIntroduced by https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/472
The problem is that currently it doesn't make any difference between:
* A frame which has two fields but only one contains valid data (which is...Introduced by https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/472
The problem is that currently it doesn't make any difference between:
* A frame which has two fields but only one contains valid data (which is what the field meant)
* A frame which has a single field (which is the new changed)
You can use the following file to see the regression and `gst-launch-1.0 -v uridecodebin uri=file:///.../dvgrab-2008.03.05_08-55-01.m2t ! fieldanalysis ! deinterlace ! autovideosink` . in 1.16 it works fine, in 1.18 it flickers because it's wrongly using the onefield flag
[dvgrab-2008.03.05_08-55-01.m2t](/uploads/c0308c6488991f0ba405e8fb000c1d17/dvgrab-2008.03.05_08-55-01.m2t)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/842RTSPSRC duration time record2021-09-24T13:34:21ZSwingRTSPSRC duration time recordHey, I don't really know where to ask my question. I try here.
I'm using Gstreamer for android.
Gstreamer's version is 1.16.2 rebuild to add some plugin
My issue is that Gstreamer doesn't know the duration time of a record.
I use 2 di...Hey, I don't really know where to ask my question. I try here.
I'm using Gstreamer for android.
Gstreamer's version is 1.16.2 rebuild to add some plugin
My issue is that Gstreamer doesn't know the duration time of a record.
I use 2 differente pipeline.
One in HTTPS and the other one in RTSPS.
`rtspsrc name=src latency=1000 buffer-mode=1 protocols=4 src. ! queue ! rtph264depay ! avdec_h264 ! videoconvert ! videocrop name=cropper ! videoscale add-borders=false ! capsfilter name=filter ! autovideosink sync=false src. ! queue ! rtpmp4gdepay ! aacparse ! faad ! volume name=vol volume=0.00000001 ! autoaudiosink sync=false`
`souphttpsrc name=src ! hlsdemux ! tsdemux name=u u. ! queue ! h264parse ! avdec_h264 ! videoconvert ! videocrop name=cropper ! videoscale add-borders=false ! capsfilter name=filter ! autovideosink sync=false u. ! queue ! aacparse ! faad ! volume name=vol volume=0.00000001 ! audioconvert ! audioresample ! autoaudiosink sync=false`
With souphttpsrc I can get the info but when i'm using rtspsrc i can't.
I also used VLC to check that the info was send by the server, and it is.
I'don't know if the problème come from my pipeline or elsewhere.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-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-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-good/-/issues/870v4l2videoenc: Implement default profile/level selection2021-09-24T13:34:24ZNicolas Dufresnev4l2videoenc: Implement default profile/level selectionRecently there was more and more report of:
```
v4l2videoenc gstv4l2videoenc.c:440:negotiate_profile_and_level:<v4l2h264enc0> Failed to set H264 profile: 'Invalid argument'
```
This was reported on downstream driver, notably RPi rpivid...Recently there was more and more report of:
```
v4l2videoenc gstv4l2videoenc.c:440:negotiate_profile_and_level:<v4l2h264enc0> Failed to set H264 profile: 'Invalid argument'
```
This was reported on downstream driver, notably RPi rpivid and IMX8 malone drivers. These downstream driver do take care of adjusting the profile/level to a valid value and just fail (which is btw against the V4L2 spec). Though, GStreamer is not doing anything either, so perhaps we could implement some logic to select a profile/level pair that is valid for the caps and the input pixel format.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/871add support for HEP (HOMER) from RTCP statistics2021-09-24T13:34:24ZDaniel Pocockadd support for HEP (HOMER) from RTCP statisticsThis is a feature request, I might prepare a contribution for this myself, can anybody point me at any existing examples relevant to RTCP from GStreamer?
The rtp, srtp and webrtcbin plugins include RTCP streams. These streams carry qua...This is a feature request, I might prepare a contribution for this myself, can anybody point me at any existing examples relevant to RTCP from GStreamer?
The rtp, srtp and webrtcbin plugins include RTCP streams. These streams carry quality information about the media stream.
Many people are now using the HOMER software for capturing and analyzing this type of data across their site.
HEP is a very simple protocol for sending information from either the signalling or media stack to the HOMER capture server. HEP is defined here:
https://github.com/sipcapture/HEP
Here is how we integrated HEP into the reflow media library in reSIProcate:
https://github.com/resiprocate/resiprocate/blob/master/reflow/HEPRTCPEventLoggingHandler.cxx
https://github.com/resiprocate/resiprocate/tree/master/rutil/hephttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/873Excessive rtpjitterbuffer cpu utilisation2021-09-24T13:34:25ZHamdi OzbayburtluExcessive rtpjitterbuffer cpu utilisationIn a 8 core (AMD EPYC 7551) VM I've an application managing ~50 gstreamer (`1.18.4`) pipelines with rtspsrc elements provided like:
```
rtspsrc location="rtsp://..." ntp-sync=true rfc7273-sync=true latency=3000 protocols=GST_RTSP_LOWER_T...In a 8 core (AMD EPYC 7551) VM I've an application managing ~50 gstreamer (`1.18.4`) pipelines with rtspsrc elements provided like:
```
rtspsrc location="rtsp://..." ntp-sync=true rfc7273-sync=true latency=3000 protocols=GST_RTSP_LOWER_TRANS_TCP
```
Half of the pipelines are used for storing the video using `hlssink2` and the other half is just relaying the RTP packets via UDP using `gst-rtsp-server`. In normal conditions I'm not not observing >50% CPU utilisation on this application/system. But in a network where the application is (i _think_) struggling to do time synchronisation the CPU usage hits to 100% and the thread breakdown (via `top -H -p <pid>`) shows `rtpjitterbuffer`s as the top consumers (>9%).
On stdout there're periodic:
```
transmission on unparented target pad rtpsessionXX_send_rtcp_src -> ''_internalsink_0
transmission on unparented target pad manager_send_rtcp_src_0 -> ''_internalsink_0
```
messages from each `rtspsrc` which is indicating an RTCP comm issue. Additionally increasing the logging verbosity (`GST_DEBUG=4,GST_TRACER:7`) reduces the cpu utilisation to <60-70% levels. Just wanted to raise the issue to collect further/relevant data on this network.
I see some rtspjitterbuffer internal timer improvements mentioned in 1.18.4 release notes, so could be a regression or a known issue.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/874twcc: enabling it increases packet loss2021-09-24T13:34:25ZTtwcc: enabling it increases packet lossWhen I enable twcc via capsfilter I start to get a lot of packet loss (according to twcc) and the video becomes unwatchable.
I experimented with different encoders and payloaders but the results are similar.
I use webrtcbin to stream vi...When I enable twcc via capsfilter I start to get a lot of packet loss (according to twcc) and the video becomes unwatchable.
I experimented with different encoders and payloaders but the results are similar.
I use webrtcbin to stream video from GStreamer to GStreamer, ie. 1-way.
Running on MacOS Big Sur, building from master with Cerbero.
As discussed with @hgr on MR !927, this is not fixed by !927 and gstreamer!384.
I'm probably doing something wrong so any pointers will be much appreciated.
---
**VP8**
Source:
`videotestsrc ! video/x-raw,framerate=5/1 ! videoconvert ! vp8enc deadline=1 target-bitrate=5000 ! queue ! rtpvp8pay !
capsfilter caps=application/x-rtp,media=video,payload=96,clock-rate=90000,encoding-name=VP8,extmap-3=http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01`.
Receiving end (I set the same capsfilter on a recvonly webrtctransceiver):
`rtpvp8depay ! vp8dec ! videoconvert ! queue ! glimagesink`
Rtpsession is giving this every few seconds:
`rtpsession rtpsession.c:2228:process_twcc_packet: [00m Could not schedule TWCC straight away`
---
**H264**
Source:
`videotestsrc ! video/x-raw,framerate=5/1 ! x264enc ! queue ! rtph264pay !
capsfilter caps=application/x-rtp,media=video,payload=96,clock-rate=90000,encoding-name=H264,extmap-3=http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01`
Receiving end (I set the same capsfilter on a recvonly webrtctransceiver):
`rtph264depay request-keyframe=true ! queue ! h264parse config-interval=-1 !
avdec_h264 qos=true ! videoconvert ! glimagesink`
The h264 depayloader is giving warnings when twcc is enabled:
`gstrtph264depay.c:1365:gst_rtp_h264_depay_process:<rtph264depay0> [00m missing FU start bit on an earlier packet. Dropping.`
---
**Output**.
This is a sample log output with a very large negative avg-delta-of-delta, which seems curious to me. But that's is perhaps due to the large packet loss:
`rtpsession rtpsession.c:2890:rtp_session_process_twcc:<RTPSession@0x7ff26612c010> [00m Current TWCC stats RTPTWCCStats, bitrate-sent=(uint)38220, bitrate-recv=(uint)50289, packets-sent=(uint)13, packets-recv=(uint)1, packet-loss-pct=(double)86.343612670898438, avg-delta-of-delta=(gint64)-97416666;`
---
**Misc**.
I experimented with the following, but it did't seem to change anything:
- webrtc bundle policy vs none.
- 1-way vs 2-way video.
- Relay server vs. p2p.
- Wifi vs cellular network. (Haven't tried cable but just enabling twcc makes everything worse, so this doesn't seem to be the reason).https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/877lamemp3enc: incorrect duration / bitrate for vbr encoded tracks2021-09-24T13:34:26Zcrvilamemp3enc: incorrect duration / bitrate for vbr encoded tracksHere, we enncode Track_1.wav to vbr mp3.
`$ gst-launch-1.0 -v filesrc location="Track_1.wav" ! decodebin ! audioconvert ! audioresample ! lamemp3enc target=quality quality="0.0" ! filesink location="Track_1_lamemp3enc_vbr_q_0.000.mp3"`
...Here, we enncode Track_1.wav to vbr mp3.
`$ gst-launch-1.0 -v filesrc location="Track_1.wav" ! decodebin ! audioconvert ! audioresample ! lamemp3enc target=quality quality="0.0" ! filesink location="Track_1_lamemp3enc_vbr_q_0.000.mp3"`
```sh
$ file Track_1_lamemp3enc_vbr_q_0.000.mp3
Track_1_lamemp3enc_vbr_q_0.000.mp3: MPEG ADTS, layer III, v1, 32 kbps, 44.1 kHz, JntStereo
```
```sh
$ mplayer Track_1_lamemp3enc_vbr_q_0.000.mp3
MPlayer 1.4 (Debian), built with gcc-10 (C) 2000-2019 MPlayer Team
Playing Track_1_lamemp3enc_vbr_q_0.000.mp3.
libavformat version 58.45.100 (external)
Audio only file format detected.
Load subtitles in ./
==========================================================================
Opening audio decoder: [mpg123] MPEG 1.0/2.0/2.5 layers I, II, III
AUDIO: 44100 Hz, 2 ch, s16le, 32.0 kbit/2.27% (ratio: 4000->176400)
Selected audio codec: [mpg123] afm: mpg123 (MPEG 1.0/2.0/2.5 layers I, II, III)
==========================================================================
AO: [pulse] 44100Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...
A: 1.8 (01.8) of 1590.0 (26:30.0) 0.6%
```
**Results:**
--------------
Incorrect duration : `1590 secs`<br>
Expected duration : `198` seconds
Incorrect bitrate : `32 kbps`<br>
Expected bitrate : `> 200 kbps`, since vbr encoding quality is best ( `0.0` ) )https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/880Improvements camera modes documentation GstRpiCamSrc2021-09-24T13:34:26ZPanderImprovements camera modes documentation GstRpiCamSrcHere are some improvements I would like to suggest for the documentation of GstRpiCamSrc. The source for these changes is https://picamera.readthedocs.io/en/release-1.12/fov.html#camera-modes
1. For https://gitlab.freedesktop.org/gstrea...Here are some improvements I would like to suggest for the documentation of GstRpiCamSrc. The source for these changes is https://picamera.readthedocs.io/en/release-1.12/fov.html#camera-modes
1. For https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/sys/rpicamsrc/gstrpicamsrc.c#L277 change first string into `"1920x1080 16:9 1-30fps / 1920x1080 0.1-30fps w/ v.2 board"`
2. For https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/sys/rpicamsrc/gstrpicamsrc.c#L280 change first string into `2592x1944 4:3 1-15fps / 3240x2464 0.1-15fps w/ v.2 board`
3. For https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/sys/rpicamsrc/gstrpicamsrc.c#L283 change first string into `"2592x1944 4:3 0.1666-1fps / 3240x2464 0.1-15fps w/ v.2 board"`
4. For https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/sys/rpicamsrc/gstrpicamsrc.c#L285 change first string into `"1296x972 4:3 1-42fps / 1640x1232 4:3 0.1-40fps w/ v.2 board"`
5. For https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/sys/rpicamsrc/gstrpicamsrc.c#L287 change first string into `"1296x730 16:9 1-49fps / 1640x922 16:9 0.1-40fps w/ v.2 board"`
6. For https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/sys/rpicamsrc/gstrpicamsrc.c#L290 change first string into `"640x480 4:3 42.1-60fps / 1280x720 16:9 40-90fps w/ v.2 board"`
7. For https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/sys/rpicamsrc/gstrpicamsrc.c#L292 change first string into `"640x480 4:3 60.1-90fps / 640x480 4:3 40-90fps w/ v.2 board"`
Please, double check that these proposed strings are correct. I have also the following questions:
- A. What should happen to the second string on the lines listed above with respect to the v.2 board? (What does `-slow` and `-fast` represent exactly? Are there conflicts with v.1 definitions for v.2?)
- B. Should the Partial Fov or Full FoV from readthedocs URL be added somehwere?
- C. Should the Video and Image support from readthedocs URL be added somewhere?
See also https://gstreamer.freedesktop.org/documentation/rpicamsrc/index.html?gi-language=c#GstRpiCamSrcSensorModehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/881GstRpiCamSrc error for bitrate greater than 200000002021-09-24T13:34:26ZPanderGstRpiCamSrc error for bitrate greater than 20000000GstRpiCamSrc documentation says maximum bitrate is 24000000 (24E6) but gives an error for bitrates greater than 20000000 (20E6) for camera version 2 (perhaps not for version 1).
Can somebody reproduce this for version 1 camera and/or ve...GstRpiCamSrc documentation says maximum bitrate is 24000000 (24E6) but gives an error for bitrates greater than 20000000 (20E6) for camera version 2 (perhaps not for version 1).
Can somebody reproduce this for version 1 camera and/or version 2 camera? Perhaps there is only for version 2 another maximum that applies.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/882Cannot capture window image with ximagesrc and xid : X reports invalid parame...2021-09-24T13:34:27ZYann SalmonCannot capture window image with ximagesrc and xid : X reports invalid parameter attributesI am trying to pinpoint why I sometimes (and unpredictably !) get a black video instead of the image of the selected window in Kazam screencast. It uses GStreamer for capturing so I tried to run a capture using the command line example i...I am trying to pinpoint why I sometimes (and unpredictably !) get a black video instead of the image of the selected window in Kazam screencast. It uses GStreamer for capturing so I tried to run a capture using the command line example in the GStreamer documentation.
I can (seemingly always) capture the whole desktop with
``gst-launch-1.0 ximagesrc ! video/x-raw,framerate=5/1 ! videoconvert ! theoraenc ! oggmux ! filesink location=/tmp/desktop.ogg``
However, specifying an xid gives various results. Sometimes it just works. Sometimes it fails with
```
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 130 (MIT-SHM)
Minor opcode of failed request: 4 (X_ShmGetImage)
Serial number of failed request: 42
Current serial number in output stream: 42
```
Sometimes it seems to start recording normally but on Ctrl-C'ing it, it says
```
^Chandling interrupt.
Interruption : arrêt du pipeline…
Execution ended after 0:00:04.728716374
Définition du pipeline à PAUSED...
Définition du pipeline à READY (prêt)…
```
then seems to stall for several minutes before concluding
```
Définition du pipeline à NULL…
Libération du pipeline…
```
and the resulting video is a corrupted file.
This is with
GStreamer 1.16.2
X.Org X Server 1.20.9
kernel 5.8.0-50-lowlatency
KUbuntu 20.04
KDE Framework 5.68.0
nvidia driver, 460.73.01
Capturing the same window with OBS works without a problem on the same system.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/884v4l2convert: race condition of group_released_handler2021-09-24T13:34:27ZKevin Songv4l2convert: race condition of group_released_handlerWe found below WARNING when run v4l2convert. How can we ensure group_released_handler don't disconnect in gst_v4l2_buffer_pool_stop when gst_v4l2_buffer_pool_resurrect_buffer()?
gst-launch-1.0 videotestsrc num-buffers=50 ! video/x-raw,f...We found below WARNING when run v4l2convert. How can we ensure group_released_handler don't disconnect in gst_v4l2_buffer_pool_stop when gst_v4l2_buffer_pool_resurrect_buffer()?
gst-launch-1.0 videotestsrc num-buffers=50 ! video/x-raw,format=BGRx,width=640,height=480 ! v4l2convert ! video/x-raw,format=RGB16 ! waylandsink sync=false
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.807843250
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
(gst-launch-1.0:5105): GLib-GObject-WARNING **: 20:17:06.169: ../glib-2.60.7/gobject/gsignal.c:2641: instance '0xffff94011200' has no handler with id '16'
Setting pipeline to NULL ...
Total showed frames (51), playing for (0:00:00.808691125), fps (63.065).
Freeing pipeline ...https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/885rtspsrc: set-parameter / get-parameter action signals assume parameter values...2021-09-24T13:34:28ZNirbheek Chauhannirbheek.chauhan@gmail.comrtspsrc: set-parameter / get-parameter action signals assume parameter values are text"set-parameter" takes four params:
`const char *name` (the name of the param)
`const char *value` (the value of the param)
`const char *content_type` (text/parameters, etc)
`GstPromise * promise` (to get notified when the action com..."set-parameter" takes four params:
`const char *name` (the name of the param)
`const char *value` (the value of the param)
`const char *content_type` (text/parameters, etc)
`GstPromise * promise` (to get notified when the action completes)
And then it just does:
> `g_string_append_printf (req->body, "%s: %s\r\n", name, value);`
This means you can't send arbitrary data (via media type negotiation); all you can send is content-type "text/<something>". This does not match all the possibilities listed in the spec: https://datatracker.ietf.org/doc/html/rfc7826#section-13.9
Interestingly, the "handle-request" signal is correctly implemented, and you can receive arbitrary data in "SET_PARAMETER".
The same problem also exists for "get-parameter". We should probably rework these and add new signals that allow sending / receiving GBytes.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/893rtph264pay: aggregate-mode=zerolatency does not work with Chrome (2021-09-24T13:34:30ZSebastian Drögertph264pay: aggregate-mode=zerolatency does not work with Chrome (When enabling logs, Chrome prints the following over and over again and nothing else.
```
[406344:15:0604/080643.626376:WARNING:video_rtp_depacketizer_h264.cc(226)] Received packet containing more than 10 NAL units. Will not keep track ...When enabling logs, Chrome prints the following over and over again and nothing else.
```
[406344:15:0604/080643.626376:WARNING:video_rtp_depacketizer_h264.cc(226)] Received packet containing more than 10 NAL units. Will not keep track sps and pps ids for all of them.
[406344:15:0604/080643.950581:WARNING:video_receive_stream2.cc(788)] No decodable frame in 200 ms, requesting keyframe.
```
Sometimes it's displaying a few frames, most of the time it just hangs. `chrome://webrtc-internals` shows that it receives packets, can't decode them and sends PLIs all the time.
This can be reproduced with the webrtc-unidirectional-h264 example with some minor changes to get a very low complexity stream. Using a plain black videotestsrc makes it even worse. Note that you might have to right-click in Chrome, enable controls and then click on the "play" button due to restrictive autoplay rules.
```diff
diff --git a/webrtc/sendonly/webrtc-unidirectional-h264.c b/webrtc/sendonly/webrtc-unidirectional-h264.c
index 593d861..07abceb 100644
--- a/webrtc/sendonly/webrtc-unidirectional-h264.c
+++ b/webrtc/sendonly/webrtc-unidirectional-h264.c
@@ -22,7 +22,7 @@
#ifdef G_OS_WIN32
#define VIDEO_SRC "mfvideosrc"
#else
-#define VIDEO_SRC "v4l2src"
+#define VIDEO_SRC "videotestsrc pattern=ball"
#endif
gchar *video_priority = NULL;
```
Streams with more complexity don't show this problem so much.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/894matroskademux: Attachments undetected when their size exceeds 15MB2021-10-20T08:16:35ZRafał Dzięgielmatroskademux: Attachments undetected when their size exceeds 15MB`matroskademux` element has a defined [`MAX_BLOCK_SIZE` of 15MB](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/aad9c8a2165b0bbee957c54262391006e81907af/gst/matroska/matroska-demux.c#L5311). Due to how it is handled, it...`matroskademux` element has a defined [`MAX_BLOCK_SIZE` of 15MB](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/aad9c8a2165b0bbee957c54262391006e81907af/gst/matroska/matroska-demux.c#L5311). Due to how it is handled, it unfortunately breaks attachments detection if their combined size in video exceeds that limit.
Tested on both 1.18 and 1.19 git.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/895equalizer plugin doesn't seem to be controllable2021-09-24T13:34:31ZMWWorksequalizer plugin doesn't seem to be controllableTrying to attach a control source to the equalizer plugin - the source code suggests the bands values are GST_PARAM_CONTROLLABLE. I'm using python, which hopefully isn't the issue! My code works with the volume plugin:
```
gst_adjust = ...Trying to attach a control source to the equalizer plugin - the source code suggests the bands values are GST_PARAM_CONTROLLABLE. I'm using python, which hopefully isn't the issue! My code works with the volume plugin:
```
gst_adjust = Gst.ElementFactory.make("volume", "adjust")
gst_pipeline.add(gst_adjust)
gst_cs0 = GstController.InterpolationControlSource()
gst_cs0.set_property('mode', GstController.InterpolationMode.LINEAR)
gst_adjust.add_control_binding(GstController.DirectControlBinding.new(gst_adjust,"volume",gst_cs0))
print(gst_cs0.set(0.1*Gst.SECOND,0.2))
```
But not when adjusted to the 3 or 10 band equalizer (I also get a True output, but no audible effect):
```
gst_adjust = Gst.ElementFactory.make("equalizer-3bands", "adjust")
gst_pipeline.add(gst_adjust)
gst_cs0 = GstController.InterpolationControlSource()
gst_cs0.set_property('mode', GstController.InterpolationMode.LINEAR)
gst_adjust.add_control_binding(GstController.DirectControlBinding.new(gst_adjust, "band0", gst_cs0))
print(gst_cs0.set(0.1*Gst.SECOND,0.99))
```
Presetting the property prior to running the pipline works as expected, but obviously not dynamic:
`print(gst_cs0.set(0.1*Gst.SECOND,12))`
I'm not an expert so could be missing something - but it seems that the equalizer should respond to controller changes?https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/904Demote dvdemux to marginal2021-09-24T13:34:37ZEdward HerveyDemote dvdemux to marginal`dvdemux` (and `dvdec`) both rely on libdv which hasn't been maintained in ages.
* Means it doesn't properly recognize any non-SD formats (i.e. all the DVCPro variants)
* The fact that it's not maintained means that we can't really fix/...`dvdemux` (and `dvdec`) both rely on libdv which hasn't been maintained in ages.
* Means it doesn't properly recognize any non-SD formats (i.e. all the DVCPro variants)
* The fact that it's not maintained means that we can't really fix/improve it. If ever there are any security issues that's also worrying
I propose we do like for `dvdec` and we demote the rank of `dvdemux` to marginal, and enable the gst-libav DV demuxer with a rank of SECONDARY. I've tested a few files with that demuxer and it works fine.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/928souphttpsrc: session sharing2021-09-24T13:34:42ZBetacentaurisouphttpsrc: session sharingIt's regarding this line:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/ext/soup/gstsouphttpsrc.c#L924
Why can a session not be shared if a proxy or a custom timeout or ssl-strict is set?
Background: I try to o...It's regarding this line:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/ext/soup/gstsouphttpsrc.c#L924
Why can a session not be shared if a proxy or a custom timeout or ssl-strict is set?
Background: I try to open a hls stream. The http request to the master manifest returns Set-Cookie http headers. These cookies need to be added to subsequent http calls to the segment manifests.
When I set a custom timeout or a proxy or ssl-strict = false, the http session is not shared and so cookies are not used in subsequent http calls which results in a connection failure. It only works with default values for timeout, proxy and ssl-strict.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/931rtspsrc: pipeline struck after few minutes of streaming when `select-stream` ...2021-10-01T17:23:30ZDeep Patelrtspsrc: pipeline struck after few minutes of streaming when `select-stream` callback is enabledversion: 1.18.5
My callback function is as below:
```py
def select_stream_callback(self, rtspsrc, num, caps, udata):
media = caps.get_structure(0).get_value('media')
encoding = caps.get_structure(0).get_value('encoding-...version: 1.18.5
My callback function is as below:
```py
def select_stream_callback(self, rtspsrc, num, caps, udata):
media = caps.get_structure(0).get_value('media')
encoding = caps.get_structure(0).get_value('encoding-name')
# skip stream other than video
if media != 'video':
return False
return True
```
It is to be noted that the stream works fine if this signal is not enabled
Here is the debug logs
```log
0:04:26.241871000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.241877000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.241891000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.241901000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.241907000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.241921000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.241931000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.241962000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.241988000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.241997000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242012000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242035000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242046000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242248000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242286000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242298000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242312000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242385000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242398000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242414000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242440000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242450000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242465000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242488000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242497000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242512000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242535000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242545000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242560000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242583000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242592000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242607000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242630000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242639000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242654000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242728000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242740000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242756000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242780000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242789000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242805000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242828000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242837000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242853000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242876000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242886000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242900000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242922000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242931000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242946000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.243039000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.243052000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.243066000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
2021-10-01 17:18:14 INFO 1633108694.376356
0:04:26.533112000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533151000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533314000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.533391000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533410000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533429000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.533465000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533511000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533529000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.533558000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533567000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533585000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.533615000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533630000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533650000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.533689000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533703000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533714000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 950 on channel 0
0:04:26.533745000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533760000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533773000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.533799000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533811000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533823000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 777 on channel 0
0:04:26.673265000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.673296000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.673312000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 76 on channel 1
0:04:26.673430000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:04:28.069402000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 84 bytes RTCP
0:04:28.069475000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:04:30.960379000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:30.960410000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:30.960439000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 76 on channel 1
0:04:30.960504000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:04:32.167497000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 84 bytes RTCP
0:04:32.167569000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:04:35.578354000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:35.578386000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:35.578402000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 76 on channel 1
0:04:35.578450000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:04:35.716265000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 84 bytes RTCP
0:04:35.716330000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:04:39.466840000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:39.466873000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:39.466903000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 56 on channel 1
0:04:39.466959000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:04:40.946154000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 60 bytes RTCP
0:04:40.946293000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:04:44.898856000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:44.898895000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:44.898917000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 56 on channel 1
0:04:44.898968000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:04:45.429008000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 60 bytes RTCP
0:04:45.429091000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:04:49.466056000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 60 bytes RTCP
0:04:49.466136000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:04:49.743003000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:49.743039000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:49.743061000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 56 on channel 1
0:04:49.743113000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:04:53.399676000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 60 bytes RTCP
0:04:53.399758000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:04:55.208214000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:55.208252000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:55.208275000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 56 on channel 1
0:04:55.208325000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:04:57.821064000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 60 bytes RTCP
0:04:57.821148000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:05:00.858707000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:05:00.858746000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:05:00.858769000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 56 on channel 1
0:05:00.858923000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:05:03.120458000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 60 bytes RTCP
0:05:03.120543000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:05:06.542809000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:05:06.542842000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:05:06.542866000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 56 on channel 1
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/943splitmuxsrc: pattern-matching syntax inconsistent with other "multifile" elem...2021-12-13T22:34:31ZAbleBaconsplitmuxsrc: pattern-matching syntax inconsistent with other "multifile" elementsThe `splitmuxsrc` element uses glob-style pattern matching, so like:
- `myfiles*.mp4`
Whereas other `mutlifile` elements (like `multifilesrc`) use a `printf`-style of pattern-matching:
- `myfiles%04d.mp4`
The `splitmuxsrc` element also...The `splitmuxsrc` element uses glob-style pattern matching, so like:
- `myfiles*.mp4`
Whereas other `mutlifile` elements (like `multifilesrc`) use a `printf`-style of pattern-matching:
- `myfiles%04d.mp4`
The `splitmuxsrc` element also lacks the ability of `multifilesrc` to specify start and stop indices.
Is there a reason for this inconsistency? It would be nice if `splitmuxsrc` had the same syntax and capabilities as `multifilesrc`.
And how come these elements don't allow filenames to be specified via regex via GLib's `GRegex` utilities?https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/957rtpsession: receiving own RTCP packet triggers SSRC reset (multicast)2023-01-02T16:08:01ZMarc Leemanrtpsession: receiving own RTCP packet triggers SSRC reset (multicast)When using multicast, rtpsession will handle the RTCP packets it receives from itself. As a result, it will conclude that a sender is on the network with the same SSRC (collission detection) and will trigger an SSRC rotation on the paylo...When using multicast, rtpsession will handle the RTCP packets it receives from itself. As a result, it will conclude that a sender is on the network with the same SSRC (collission detection) and will trigger an SSRC rotation on the payloader.
This was detected with rtpsink, but I remember fixing this issue some time ago with using rtpsrc too.
```
0:00:34.327905772 3455462 0x7f5c6c06b520 DEBUG rtpsession rtpsession.c:3035:rtp_session_process_rtcp: received RTCP packet
0:00:34.327952247 3455462 0x7f5c6c06b520 DEBUG rtpsession rtpsession.c:2424:rtp_session_process_sr: got SR packet: SSRC 5b942eaf, time 117:48:14.735605623
0:00:34.327975166 3455462 0x7f5c6c06b520 DEBUG rtpsession rtpsession.c:1703:check_collision: Collision for SSRC 5b942eaf from new incoming packet, change our sender ssrc
0:00:34.327997084 3455462 0x7f5c6c06b520 DEBUG rtpsource rtpsource.c:1300:rtp_source_mark_bye: marking SSRC 5b942eaf as BYE, reason: SSRC Collision
0:00:34.328074452 3455462 0x7f5c6c06b520 DEBUG GST_EVENT gstevent.c:310:gst_event_new_custom: creating new event 0x7f5c600054b0 custom-upstream 69121
```
Seems to be related to this issue:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/568https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/959Memory OOM when using v4l2h264enc2022-03-11T14:20:14ZBenjaminMemory OOM when using v4l2h264encI'm using the v4l2h264enc element to encode the video stream from a ADV7282-M CSI2 Video Decoder, which I'm passing via an appsrc element. In certain scenarios (e.g. disconnecting the Video Source to the Video Decoder) I encounter the is...I'm using the v4l2h264enc element to encode the video stream from a ADV7282-M CSI2 Video Decoder, which I'm passing via an appsrc element. In certain scenarios (e.g. disconnecting the Video Source to the Video Decoder) I encounter the issue that my Application runs OOM.
This starts with the encoder not outputting any data anymore and the Application taking more and more Memory. Like if a Worker Thread stops working, and it queues the Input Data till OOM.
I was able to reproduce this issue with feeding in random Data from `/dev/urandom` via an appsrc. I guess something similar happens when disconnecting the Video Source to the Video Decoder as it tries to lock to the Video Signal and outputs whatever it receives At this moment.
An example Application to reproduce this is attached to this issue.
I was able to reproduce this issue on:
- Raspberry Pi CM4 - Debian 11 - GStreamer 1.18.4 - Linux 5.15.24
- Raspberry Pi 3 - ArchLinux ARM - GStreamer 1.20.0 - Linux 5.15.27-1-rpi-ARCH
- i.MX8MM - Debian 11 - GStreamer 1.16.2 - Linux 5.17.0-rc1
Code:
```
#include <stdio.h>
#include <stdbool.h>
#include <unistd.h>
#include <gst/gst.h>
#include <gst/app/gstappsrc.h>
#include <gst/app/gstappsink.h>
#include <gst/gstbuffer.h>
#include <gst/gstmemory.h>
#ifdef __arm__
#define IMAGE_WIDTH 720
#define IMAGE_HEIGHT 576
#endif
#define VIDEO_GST_DEBUG "*:3"
GstElement *pPipeline = NULL;
GstElement *pAppSrc = NULL;
void init_pipeline()
{
if (pPipeline != NULL)
return;
unsigned int major, minor, micro, nano;
/* initialize gstreamer */
setenv("GST_DEBUG", VIDEO_GST_DEBUG, 5);
gst_init(NULL, NULL);
gst_version(&major, &minor, µ, &nano);
gst_update_registry();
printf("Gstreamer initialized. \n");
printf("Gstreamer version: %u %u %u %u \n", major, minor, micro, nano);
#ifdef __arm__
char *pipelineStr = "appsrc name=appsrc ! video/x-raw, interlace-mode=interleaved, framerate=25/1, format=UYVY, width=720, height=576 ! "
"deinterlace method=linear ! videocrop top=16 left=16 right=16 bottom=16 ! videorate ! videoscale ! "
"video/x-raw, framerate=25/1, width=640, height=480 ! videoconvert ! "
"queue ! v4l2h264enc output-io-mode=2 extra-controls=\"controls,h264_profile=0,video_bitrate=1000000,h264_i_frame_period=10,repeat_sequence_header=1;\" ! "
"video/x-h264, level=(string)3, profile=baseline, stream-format=byte-stream ! filesink location=out.h264";
pPipeline = gst_parse_launch(pipelineStr, NULL);
printf("Pipeline: %s \n", pipelineStr);
#endif
pAppSrc = gst_bin_get_by_name(GST_BIN(pPipeline), "appsrc");
// ASSERT(pAppSrc != NULL);
g_object_set(pAppSrc, "format", GST_FORMAT_TIME, NULL);
if (pPipeline == NULL)
{
printf("Failed to init pipeline \n");
exit(-1);
}
/* Start playing */
gst_element_set_state(pPipeline, GST_STATE_PLAYING);
}
FILE *myfile = NULL;
void write_gst_data(char *buffer, size_t length)
{
GstBuffer *gstbuffer;
GstFlowReturn ret;
GstMapInfo map;
/* copy frame to gst buffer */
gstbuffer = gst_buffer_new_and_alloc(length);
gst_buffer_map(gstbuffer, &map, GST_MAP_WRITE);
memcpy(map.data, buffer, length);
gst_buffer_unmap(gstbuffer, &map);
/* push data to appsrc */
ret = gst_app_src_push_buffer(GST_APP_SRC(pAppSrc), gstbuffer);
if (ret != GST_FLOW_OK)
{
printf("-EINVAL GST_FLOW! \n");
}
}
int main(int argc, char *argv[])
{
init_pipeline();
while (true)
{
char *uyvybuffer = (char *)malloc(IMAGE_WIDTH * IMAGE_HEIGHT * 2);
FILE *fp;
fp = fopen("/dev/urandom", "r");
fread(uyvybuffer, 1, IMAGE_WIDTH * IMAGE_HEIGHT * 2, fp);
fclose(fp);
write_gst_data(uyvybuffer, IMAGE_WIDTH * IMAGE_HEIGHT * 2);
free(uyvybuffer);
// 25FPS -> 40ms
usleep(40 * 1000);
}
}
```
Build:
```
gcc -g main.c -I. -o decoder `pkg-config --cflags --libs gstreamer-1.0` `pkg-config --cflags --libs gstreamer-app-1.0`
```
For reference:
https://github.com/raspberrypi/linux/issues/4906
https://forums.raspberrypi.com/viewtopic.php?p=1977561#p1977561https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/974qtmoovrecover: vlc does not play the recovered mp42022-05-16T14:05:47ZVincenzo Martenaqtmoovrecover: vlc does not play the recovered mp4if vlc founds the sample_description_index set to 0 in the stsc atom
it refuses to play the video while other players don't.
attached you can find a patch containing a workaround for this problem.
[0001-qtmoovrecover-workaround-to-make...if vlc founds the sample_description_index set to 0 in the stsc atom
it refuses to play the video while other players don't.
attached you can find a patch containing a workaround for this problem.
[0001-qtmoovrecover-workaround-to-make-the-recovered-file-.patch](/uploads/55b93775a0cff482e10fe9041b5043fe/0001-qtmoovrecover-workaround-to-make-the-recovered-file-.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/975qtmoovrecover: wrong recover for mov with fixed audio sample rate2022-05-16T14:05:37ZVincenzo Martenaqtmoovrecover: wrong recover for mov with fixed audio sample ratethe qtmoovrecover plugin fails to correctly recover mov files with fixed audio sample rate.
attached you can find a patch containing a fix for this problem.
[0002-qtmoovrecover-fix-for-recoverying-mov-with-fixed-aud.patch](/uploads/067...the qtmoovrecover plugin fails to correctly recover mov files with fixed audio sample rate.
attached you can find a patch containing a fix for this problem.
[0002-qtmoovrecover-fix-for-recoverying-mov-with-fixed-aud.patch](/uploads/067717e09e05c316e6887463fcb0a251/0002-qtmoovrecover-fix-for-recoverying-mov-with-fixed-aud.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/992rollback seek RTSP2022-08-25T14:44:21ZSwingrollback seek RTSPHey,
I'm having a mysterious problem when I'm seeking.
So I'm using gstreamer 1.20.3 on Android.
I also had this problem with all other version.
Here is my custom Pipeline: "`rtspsrc name=src protocols=4 buffer-mode=1 is-live=false ...Hey,
I'm having a mysterious problem when I'm seeking.
So I'm using gstreamer 1.20.3 on Android.
I also had this problem with all other version.
Here is my custom Pipeline: "`rtspsrc name=src protocols=4 buffer-mode=1 is-live=false latency=2000 src. ! queue ! rtph264depay ! avdec_h264 ! videoconvert ! capsfilter name=filter ! autovideosink sync=true src. ! queue ! rtpmp4gdepay ! aacparse ! avdec_aac ! audioconvert ! audioresample ! volume name=vol volume=0.00000001 ! autoaudiosink sync=false`"
To seek I use "` gst_element_seek (data->pipeline, 1.0, GST_FORMAT_TIME, GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_ACCURATE, GST_SEEK_TYPE_SET, desired_position, GST_SEEK_TYPE_SET, GST_CLOCK_TIME_NONE);`"
I have no errors from Gstreamer in the log.
I got different type of "bug"
- if my first seek in the video is to 2:01 i will go back to 0:00 and then i seek again to 3:41 i will go to 2:01 etc i will always have one seek latethe thing is that the video I received is good but only the seekbar and the timer are wrong.
- sometimes it works perfectly
- My first seek work and then we go back to the first problem
I've tried a lot of different things but I can't figure out why sometimes it works and sometimes it doesn't.
When I look with wireshark on my network, I take a look at the packet. The packet I send is good (PLAY with range) and the packet I receive is (200 OK with a good range).So it can't come from a mistake in a packet.
I put a lot of debug inside my code to see if something wasn't good, but everything was fine.
I have no more ideas.When I'm using my url on VLC it works perfectly.
Disclaimer: Yes I know that rtsp isn't made for this. But I have no other choice.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/1042qml6glsink: impossible to render in parallel into 2 (or more) qml6glsinks2024-03-28T09:21:55ZRobert Guziolowskiqml6glsink: impossible to render in parallel into 2 (or more) qml6glsinksCreate a simple QML application with 2 (or more) qml6glsinks with 2 different pipelines (see attached files).
**Observed behavior**
The application crashes or shows only the stream attached to the first GstGLQt6VideoItem item from the ...Create a simple QML application with 2 (or more) qml6glsinks with 2 different pipelines (see attached files).
**Observed behavior**
The application crashes or shows only the stream attached to the first GstGLQt6VideoItem item from the .qml file (in the test application the _snow_ pattern.
**Expected behavior**
Two streams shown independently (_snow_ and _smpte_ patterns).
**Suggested correction**
I found the correction (in my case) for this problem changing the code of the destructor of GstQSGTexture (gstqsg6material.cc file) from
`delete m_texture;`
to
`m_texture->deleteLater();`
Edit: [merge request](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6467) ready.
~~I'll create a merge request soon.~~
[CMakeLists.txt](/uploads/205dbecbffd2f9bf6eaa2d27e699ed7b/CMakeLists.txt)
[main.cpp](/uploads/a8bc6bb2b07640b8c87e1d178e3436a2/main.cpp)
[Main.qml](/uploads/e6e90727abf79eaaae869be14d5435fb/Main.qml)