GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T13:33:03Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/479qmlglsrc: Black frames with Mesa2021-09-24T13:33:03ZBugzilla Migration Userqmlglsrc: Black frames with Mesa## Submitted by Julien Isorce `@cap`
**[Link to original bug (#796506)](https://bugzilla.gnome.org/show_bug.cgi?id=796506)**
## Description
I installed Ubuntu 18.04 in VM (virtual box) and the example https://cgit.freedesktop.org/gs...## Submitted by Julien Isorce `@cap`
**[Link to original bug (#796506)](https://bugzilla.gnome.org/show_bug.cgi?id=796506)**
## Description
I installed Ubuntu 18.04 in VM (virtual box) and the example https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/tests/examples/qt/qmlsrc renders black frames.
I will attach logs that I can get while running the pipeline LIBGL_DEBUG=verbose MESA_DEBUG=1 MESA_XSYNC=1 SVGA_EXTRA_LOGGING=1 GST_GL_XINITTHREADS=1 ./grabqmlhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/478rtspsrc: add on-timeout signal2021-09-24T13:33:03ZBugzilla Migration Userrtspsrc: add on-timeout signal## Submitted by Justin Kim `@joykim`
**[Link to original bug (#796471)](https://bugzilla.gnome.org/show_bug.cgi?id=796471)**
## Description
Created attachment 372490
rtspsrc: add on-timeout signal
When udpsrc posts a timeout ...## Submitted by Justin Kim `@joykim`
**[Link to original bug (#796471)](https://bugzilla.gnome.org/show_bug.cgi?id=796471)**
## Description
Created attachment 372490
rtspsrc: add on-timeout signal
When udpsrc posts a timeout message, it doesn't reach to an application because rtspsrc unref the message. but, IMHO, the message is a simple way to know the current network status.
**Patch 372490**, "rtspsrc: add on-timeout signal":
[0001-rtspsrc-add-on-timeout-signal.patch](/uploads/5ba75e05661283c802f307800e4b9e0b/0001-rtspsrc-add-on-timeout-signal.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/476using rtspsrc with tcp has a much higher CPU usage then with udp2021-09-24T13:33:03ZBugzilla Migration Userusing rtspsrc with tcp has a much higher CPU usage then with udp## Submitted by Ivan Roubíček
**[Link to original bug (#796455)](https://bugzilla.gnome.org/show_bug.cgi?id=796455)**
## Description
When using rtspsrc with tcp protocol it has a much larger CPU usage then with UDP. I was trying tha...## Submitted by Ivan Roubíček
**[Link to original bug (#796455)](https://bugzilla.gnome.org/show_bug.cgi?id=796455)**
## Description
When using rtspsrc with tcp protocol it has a much larger CPU usage then with UDP. I was trying that with gstreamer 1.12.4 (ubuntu 17.10) and 1.14.0 (ubuntu 18.04 LTS)
htop using tcp:
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
14679 servis 20 0 961M 12636 10280 S 8.0 0.1 0:01.00 gst-launch-1.0 rtspsrc protocols=tcp location=rtsp://192.168.0.1:554/ ! fakesink
14680 servis 20 0 961M 12636 10280 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=tcp location=rtsp://192.168.0.1:554/ ! fakesink
14681 servis 20 0 961M 12636 10280 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=tcp location=rtsp://192.168.0.1:554/ ! fakesink
14682 servis 20 0 961M 12636 10280 S 8.0 0.1 0:00.95 gst-launch-1.0 rtspsrc protocols=tcp location=rtsp://192.168.0.1:554/ ! fakesink
14683 servis 20 0 961M 12636 10280 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=tcp location=rtsp://192.168.0.1:554/ ! fakesink
14684 servis 20 0 961M 12636 10280 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=tcp location=rtsp://192.168.0.1:554/ ! fakesink
14685 servis 20 0 961M 12636 10280 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=tcp location=rtsp://192.168.0.1:554/ ! fakesink
14686 servis 20 0 961M 12636 10280 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=tcp location=rtsp://192.168.0.1:554/ ! fakesink
14687 servis 20 0 961M 12636 10280 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=tcp location=rtsp://192.168.0.1:554/ ! fakesink
14688 servis 20 0 961M 12636 10280 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=tcp location=rtsp://192.168.0.1:554/ ! fakesink
14690 servis 20 0 961M 12636 10280 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=tcp location=rtsp://192.168.0.1:554/ ! fakesink
14691 servis 20 0 961M 12636 10280 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=tcp location=rtsp://192.168.0.1:554/ ! fakesink
htop using udp:
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
14707 servis 20 0 1251M 12916 10576 S 0.0 0.1 0:00.08 gst-launch-1.0 rtspsrc protocols=udp location=rtsp://192.168.0.1:554/ ! fakesink
14708 servis 20 0 1251M 12916 10576 S 0.0 0.1 0:00.02 gst-launch-1.0 rtspsrc protocols=udp location=rtsp://192.168.0.1:554/ ! fakesink
14709 servis 20 0 1251M 12916 10576 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=udp location=rtsp://192.168.0.1:554/ ! fakesink
14710 servis 20 0 1251M 12916 10576 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=udp location=rtsp://192.168.0.1:554/ ! fakesink
14711 servis 20 0 1251M 12916 10576 S 0.0 0.1 0:00.01 gst-launch-1.0 rtspsrc protocols=udp location=rtsp://192.168.0.1:554/ ! fakesink
14712 servis 20 0 1251M 12916 10576 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=udp location=rtsp://192.168.0.1:554/ ! fakesink
14713 servis 20 0 1251M 12916 10576 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=udp location=rtsp://192.168.0.1:554/ ! fakesink
14714 servis 20 0 1251M 12916 10576 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=udp location=rtsp://192.168.0.1:554/ ! fakesink
14715 servis 20 0 1251M 12916 10576 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=udp location=rtsp://192.168.0.1:554/ ! fakesink
14716 servis 20 0 1251M 12916 10576 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=udp location=rtsp://192.168.0.1:554/ ! fakesink
14717 servis 20 0 1251M 12916 10576 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=udp location=rtsp://192.168.0.1:554/ ! fakesink
14718 servis 20 0 1251M 12916 10576 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=udp location=rtsp://192.168.0.1:554/ ! fakesink
14719 servis 20 0 1251M 12916 10576 S 0.3 0.1 0:00.02 gst-launch-1.0 rtspsrc protocols=udp location=rtsp://192.168.0.1:554/ ! fakesink
14720 servis 20 0 1251M 12916 10576 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=udp location=rtsp://192.168.0.1:554/ ! fakesink
14722 servis 20 0 1251M 12916 10576 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=udp location=rtsp://192.168.0.1:554/ ! fakesink
14723 servis 20 0 1251M 12916 10576 S 0.0 0.1 0:00.00 gst-launch-1.0 rtspsrc protocols=udp location=rtsp://192.168.0.1:554/ ! fakesink
Version: 1.14.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/475flvmux: flvmux is not giving the request pad name as mentioned in sink template2021-09-24T13:33:03ZBugzilla Migration Userflvmux: flvmux is not giving the request pad name as mentioned in sink template## Submitted by parithi
**[Link to original bug (#796436)](https://bugzilla.gnome.org/show_bug.cgi?id=796436)**
## Description
For gst_element_get_request_pad() call, flvmux is returning pad with name "sink_0", instead of "video" as...## Submitted by parithi
**[Link to original bug (#796436)](https://bugzilla.gnome.org/show_bug.cgi?id=796436)**
## Description
For gst_element_get_request_pad() call, flvmux is returning pad with name "sink_0", instead of "video" as mentioned in sink template.
From my analysis figured out that, Aggregator is creating pad with name "sink_0" and flvmux is returning same pad to the application. This is creating problem when we try to probe flvmuxer's pad, with the name mentioned in sink template, in later point of time.
Version: 1.14.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/473splitmuxsink: remove old files with max-files property2021-09-24T13:33:02ZBugzilla Migration Usersplitmuxsink: remove old files with max-files property## Submitted by Daeseok Youn
**[Link to original bug (#796292)](https://bugzilla.gnome.org/show_bug.cgi?id=796292)**
## Description
If max-files has a not zero value, splitmuxsink should remove old segment files which is managed by ...## Submitted by Daeseok Youn
**[Link to original bug (#796292)](https://bugzilla.gnome.org/show_bug.cgi?id=796292)**
## Description
If max-files has a not zero value, splitmuxsink should remove old segment files which is managed by queue with file name. (referenced by multifilesink element)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/471id3demux : Does not send segment-start and segment-done message2021-09-24T13:33:02ZBugzilla Migration Userid3demux : Does not send segment-start and segment-done message## Submitted by Baby octopus
**[Link to original bug (#795882)](https://bugzilla.gnome.org/show_bug.cgi?id=795882)**
## Description
I have developed an application to stream a file indefinitely by looping it. For looping, I do a seg...## Submitted by Baby octopus
**[Link to original bug (#795882)](https://bugzilla.gnome.org/show_bug.cgi?id=795882)**
## Description
I have developed an application to stream a file indefinitely by looping it. For looping, I do a segment seek and then catch the SEGMENT_DONE message. However, this approach works for Mp4 and not work for mp3. Digging deeper, I found id3mux does not send these messages
One another issue here is the id3demux is optional for mp3 decoding. Decodebin does not autoplug id3demux for certain mp3 files but directly uses the mpegaudioparse. I'm not really sure which element is to send segment-start and segment-done messages in such a casehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/469Cannot bind udpsink to IPv4 address, which is incorrectly treated as an IPv6 one2021-09-24T13:33:01ZBugzilla Migration UserCannot bind udpsink to IPv4 address, which is incorrectly treated as an IPv6 one## Submitted by Daniel F
**[Link to original bug (#795502)](https://bugzilla.gnome.org/show_bug.cgi?id=795502)**
## Description
I am trying to bind udpsink to local IPv4 address, but for some reason this address is treated as an IPv...## Submitted by Daniel F
**[Link to original bug (#795502)](https://bugzilla.gnome.org/show_bug.cgi?id=795502)**
## Description
I am trying to bind udpsink to local IPv4 address, but for some reason this address is treated as an IPv6 one, and udpsink complains about incorrect address family.
gst-launch-1.0 -v udpsink bind-address="192.168.100.20"
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
ERROR: from element /GstPipeline:pipeline0/GstUDPSink:udpsink0: Could not get/set settings from/on resource.
Additional debug info:
gstmultiudpsink.c(1286): gst_multiudpsink_configure_client (): /GstPipeline:pipeline0/GstUDPSink:udpsink0:
Invalid address family (got 10)
Setting pipeline to NULL ...
Freeing pipeline ...
I have CentOS 7.4 64-bit.
uname -a
Linux daniel.localdomain 3.10.0-693.21.1.el7.x86_64` #1` SMP Wed Mar 7 19:03:37 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
gst-launch-1.0 --version
gst-launch-1.0 version 1.10.4
GStreamer 1.14.0
http://www.redhat.com
Version: 1.14.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/466pulsesrc fails to start up2021-09-24T13:33:00ZBugzilla Migration Userpulsesrc fails to start up## Submitted by David Woodhouse
**[Link to original bug (#795374)](https://bugzilla.gnome.org/show_bug.cgi?id=795374)**
## Description
Using a Pidgin/Farstream pipeline I occasionally see pulsesrc failing to start up. It seems timin...## Submitted by David Woodhouse
**[Link to original bug (#795374)](https://bugzilla.gnome.org/show_bug.cgi?id=795374)**
## Description
Using a Pidgin/Farstream pipeline I occasionally see pulsesrc failing to start up. It seems timing-related.
0:00:05.967852418 23118 0x2e41630 INFO basesrc gstbasesrc.c:2739:gst_base_src_loop:`<pulsesrc0>` pausing after gst_base_src_get_range() = flushing
0:00:05.967864004 23118 0x2e41630 INFO task gsttask.c:316:gst_task_func:<pulsesrc0:src> Task going to paused
Working call log at http://david.woodhou.se/fscall-working and
http://david.woodhou.se/fscall-working-graph.svg
Failing call log at http://david.woodhou.se/fscall-silent and
http://david.woodhou.se/fscall-silent-graph.svg
In the working call, the first sample from pulsesrc seems to happen earlier, and it all works fine. In the failing call, we see the above messages. And nothing ever comes out of the pulsesrc again.
`<thaytan>` dwmw2_gone, it's not trying to push the samples downstream yet then though - it's just trying to create the first buffer
`<thaytan>` it doesn't get as far as trying to push it
`<thaytan>` so seems more like a startup race in pulsesrc
Version: 1.8.3https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/464udpsrc listens on Legacy IP only2021-09-24T13:33:00ZBugzilla Migration Userudpsrc listens on Legacy IP only## Submitted by David Woodhouse
**[Link to original bug (#795268)](https://bugzilla.gnome.org/show_bug.cgi?id=795268)**
## Description
Using 'udpsrc port=7200' in my pipeline only listens on the Legacy IP address 0.0.0.0 by default,...## Submitted by David Woodhouse
**[Link to original bug (#795268)](https://bugzilla.gnome.org/show_bug.cgi?id=795268)**
## Description
Using 'udpsrc port=7200' in my pipeline only listens on the Legacy IP address 0.0.0.0 by default, instead of [::].
Version: 1.12.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/462Various patches on ptdemux2021-09-24T13:32:59ZBugzilla Migration UserVarious patches on ptdemux## Submitted by Håvard Graff (hgr)
**[Link to original bug (#795160)](https://bugzilla.gnome.org/show_bug.cgi?id=795160)**
## Description
Created attachment 370800
rtpptdemux: Fix debug to use GST_DEBUG_OBJECT
.
**Patc...## Submitted by Håvard Graff (hgr)
**[Link to original bug (#795160)](https://bugzilla.gnome.org/show_bug.cgi?id=795160)**
## Description
Created attachment 370800
rtpptdemux: Fix debug to use GST_DEBUG_OBJECT
.
**Patch 370800**, "rtpptdemux: Fix debug to use GST_DEBUG_OBJECT":
[0001-rtpptdemux-Fix-debug-to-use-GST_DEBUG_OBJECT.patch](/uploads/657eee5e7300087736b7e664972a36af/0001-rtpptdemux-Fix-debug-to-use-GST_DEBUG_OBJECT.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/461Various patches on ssrcdemux2021-09-24T13:32:59ZBugzilla Migration UserVarious patches on ssrcdemux## Submitted by Håvard Graff (hgr)
**[Link to original bug (#795159)](https://bugzilla.gnome.org/show_bug.cgi?id=795159)**
## Description
Created attachment 370796
rtpssrcdemux: introduce max-streams property
The property is ...## Submitted by Håvard Graff (hgr)
**[Link to original bug (#795159)](https://bugzilla.gnome.org/show_bug.cgi?id=795159)**
## Description
Created attachment 370796
rtpssrcdemux: introduce max-streams property
The property is useful against attacks when the sender changes SSRC for
every RTP packet. The property with the same name introduced in rtpbin
was not enough, because we still can end up with thousands of pads
allocated in rtpssrcdemux.
**Patch 370796**, "rtpssrcdemux: introduce max-streams property":
[0001-rtpssrcdemux-introduce-max-streams-property.patch](/uploads/5c44e4c705d92d7305ec2131ff5e3ef6/0001-rtpssrcdemux-introduce-max-streams-property.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/460Various patches on rtpsession2021-09-24T13:32:58ZBugzilla Migration UserVarious patches on rtpsession## Submitted by Håvard Graff (hgr)
**[Link to original bug (#795139)](https://bugzilla.gnome.org/show_bug.cgi?id=795139)**
## Description
Created attachment 370740
Running gst-indent on the rtpsession tests
A collection of pa...## Submitted by Håvard Graff (hgr)
**[Link to original bug (#795139)](https://bugzilla.gnome.org/show_bug.cgi?id=795139)**
## Description
Created attachment 370740
Running gst-indent on the rtpsession tests
A collection of patches for rtpsession, to be applied in order.
**Patch 370740**, "Running gst-indent on the rtpsession tests":
[0001-rtpsession-run-gst-indent.patch](/uploads/644284008e05013984235df95b01a70d/0001-rtpsession-run-gst-indent.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/459progressreport: Progress report message is not reporting percent-double and p...2021-09-24T13:32:58ZBugzilla Migration Userprogressreport: Progress report message is not reporting percent-double and percentage for some files## Submitted by Vinod Kesti `@vinodkesti`
**[Link to original bug (#795003)](https://bugzilla.gnome.org/show_bug.cgi?id=795003)**
## Description
progressreport message pattern is inconsistent with some file
Below are the behaviour...## Submitted by Vinod Kesti `@vinodkesti`
**[Link to original bug (#795003)](https://bugzilla.gnome.org/show_bug.cgi?id=795003)**
## Description
progressreport message pattern is inconsistent with some file
Below are the behaviour.
1. When file processing start progressreport message contains percent-double and percentage
2. After some time percentage details are missing in the message.
3. This issue is observed when system is loaded with multiple file processing.
Further analyses and found that issue comes when gst_pad_peer_query_duration (sink_pad, format, &total) function returns total = -1
I tried debugging but not able to figure out which element responds to the query.
Can some one help me to give pointer where the problem is
~ Vinod
Version: 1.13.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/458qtdemux: edit list segment bound check is buggy2021-09-24T13:32:58ZBugzilla Migration Userqtdemux: edit list segment bound check is buggy## Submitted by Alicia Boya García `@ntrrgc`
**[Link to original bug (#794906)](https://bugzilla.gnome.org/show_bug.cgi?id=794906)**
## Description
In pull mode (the only mode where complex edit lists are supported), the condition t...## Submitted by Alicia Boya García `@ntrrgc`
**[Link to original bug (#794906)](https://bugzilla.gnome.org/show_bug.cgi?id=794906)**
## Description
In pull mode (the only mode where complex edit lists are supported), the condition to check if a frame is outside the current edit is:
QTSAMPLE_DTS (stream, sample) >= segment->media_stop
That is wrong because it's comparing DTS with PTS (`segment->media_stop`). In consequence, often one or two extra frames that are out-of-segment are sent before the new GstSegment.
See the tests introduced in https://bugzilla.gnome.org/show_bug.cgi?id=794902 to see this bug in action.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/457qtdemux tests: Add edit list test battery2021-09-24T13:32:58ZBugzilla Migration Userqtdemux tests: Add edit list test battery## Submitted by Alicia Boya García `@ntrrgc`
**[Link to original bug (#794902)](https://bugzilla.gnome.org/show_bug.cgi?id=794902)**
## Description
Edit list handling has enough complexity to warrant some tests.
This patch intr...## Submitted by Alicia Boya García `@ntrrgc`
**[Link to original bug (#794902)](https://bugzilla.gnome.org/show_bug.cgi?id=794902)**
## Description
Edit list handling has enough complexity to warrant some tests.
This patch introduces a test battery that generates a variety of edit
lists in different types of files (fragmented or not fragmented) and
tests them in both push and pull mode.
Since the valid combinations of all the test variables are quite a few
(35 tests), code generation is used for the actual test functions.
The code generator also defines the expected failures due to bugs not
currently fixed.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/456wavenc : adding support for broadcast wave format (BWF)2021-09-24T13:32:57ZBugzilla Migration Userwavenc : adding support for broadcast wave format (BWF)## Submitted by Yves Lefebvre
**[Link to original bug (#794804)](https://bugzilla.gnome.org/show_bug.cgi?id=794804)**
## Description
I will provide a patch to add support for bwf version 0 :
https://tech.ebu.ch/docs/tech/tech32...## Submitted by Yves Lefebvre
**[Link to original bug (#794804)](https://bugzilla.gnome.org/show_bug.cgi?id=794804)**
## Description
I will provide a patch to add support for bwf version 0 :
https://tech.ebu.ch/docs/tech/tech3285.pdfhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/455rtpssrcdemux: add the support of buffer list2021-09-24T13:32:56ZBugzilla Migration Userrtpssrcdemux: add the support of buffer list## Submitted by Eloi BAIL
**[Link to original bug (#794794)](https://bugzilla.gnome.org/show_bug.cgi?id=794794)**
## Description
Add the support of buffer list in rtpssrcdemux so that we can handle buffer list on sink pad.
Each bu...## Submitted by Eloi BAIL
**[Link to original bug (#794794)](https://bugzilla.gnome.org/show_bug.cgi?id=794794)**
## Description
Add the support of buffer list in rtpssrcdemux so that we can handle buffer list on sink pad.
Each buffer list on the sink pad may contain different RTP SSRC. For each SSRC, a different buffer list will be created and buffers matching this SSRC will be added.
Those buffer lists will be then pushed on the src pad.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/454rtpbin: updating ts_offset often cause audio glitches when using ntp-sync=true2021-09-24T13:32:56ZBugzilla Migration Userrtpbin: updating ts_offset often cause audio glitches when using ntp-sync=true## Submitted by Danny
**[Link to original bug (#794762)](https://bugzilla.gnome.org/show_bug.cgi?id=794762)**
## Description
Following the procedure outlined in the pdf below we have encountered audio glitches in our audio receivers...## Submitted by Danny
**[Link to original bug (#794762)](https://bugzilla.gnome.org/show_bug.cgi?id=794762)**
## Description
Following the procedure outlined in the pdf below we have encountered audio glitches in our audio receivers. Have tracked it down to that constantly updating the ts_offset in the rtpbin results in glitches when streaming audio using ntp-sync=true. Seems to be related to jittery behaviour in the local/remote clock causing the ts_offset to be updated often with very small changes (<100 microseconds) which in turn causes the alsasink to jump around in its audio buffer.
https://gstreamer.freedesktop.org/data/events/gstreamer-conference/2015/Sebastian%20Dr%C3%B6ge%20-%20Synchronised%20multi-room%20media%20playback%20and%20distributed%20live%20media%20processing%20and%20mixing%20with%20GStreamer.pdf
Version: 1.14.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/451[souphttpsrc] TLS/SSL support not available on Win322021-09-24T13:32:55ZBugzilla Migration User[souphttpsrc] TLS/SSL support not available on Win32## Submitted by Tao
**[Link to original bug (#794425)](https://bugzilla.gnome.org/show_bug.cgi?id=794425)**
## Description
Hello,
It's my first bug report on gnome, so please don't blame me. This bug report is a followup of htt...## Submitted by Tao
**[Link to original bug (#794425)](https://bugzilla.gnome.org/show_bug.cgi?id=794425)**
## Description
Hello,
It's my first bug report on gnome, so please don't blame me. This bug report is a followup of https://github.com/ua-i2cat/gst-unity-bridge/issues/36
My goal is to play live HLS stream in unity, for this I use GStreamer Unity3D Bridge. This library obviously rely on GStreamer. But gstreamer looks to be unable to perform an HTTPS request with following message:
souphttpsrc gstsouphttpsrc.c:1279:gst_soup_http_src_parse_status:`<souphttpsrc2>` error: TLS/SSL support not available; install glib-networking (6), URL: https://protectedurl/forthisbugreport, Redirect to: (NULL)
The old discussion on gstreamer dev mailing list http://gstreamer-devel.966125.n4.nabble.com/Queries-about-libgstsouphttpsrc-td4667605.html suggests to simply add libgiognutls.dll to my project, but it did not fix my problem. Notice I also tried to put libgiognutls.dll in windows system32 dir.
This bug is reproducible with GStreamer 1.13.91.
Kind regards,
Laurent.
Version: 2.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/448qtdemux: playback interrupt when reverse video2021-09-24T13:32:55ZBugzilla Migration Userqtdemux: playback interrupt when reverse video## Submitted by Chenglin Ye
**[Link to original bug (#794101)](https://bugzilla.gnome.org/show_bug.cgi?id=794101)**
## Description
Created attachment 369369
Fix media interruption issue when reverse video
I tried to reverse M...## Submitted by Chenglin Ye
**[Link to original bug (#794101)](https://bugzilla.gnome.org/show_bug.cgi?id=794101)**
## Description
Created attachment 369369
Fix media interruption issue when reverse video
I tried to reverse MJPEG format video, but it got media interruption error, and log shown that "This file is invalid and cannot be played.", I found the position of the log, as follow:
source code(qtdemux.c):
------------------------------------------------------------------------------
746 if (G_UNLIKELY (size > QTDEMUX_MAX_ATOM_SIZE)) {
747 if (qtdemux->state != QTDEMUX_STATE_MOVIE && qtdemux->got_moov) {
748 /* we're pulling header but already got most interesting bits,
749 * so never mind the rest (e.g. tags) (that much) */
750 GST_WARNING_OBJECT (qtdemux, "atom has bogus size %" G_GUINT64_FORMAT,
751 size);
752 return GST_FLOW_EOS;
753 } else {
754 GST_ELEMENT_ERROR (qtdemux, STREAM, DEMUX,
755 (_("This file is invalid and cannot be played.")),
756 ("atom has bogus size %" G_GUINT64_FORMAT, size));
757 return GST_FLOW_ERROR;
758 }
759 }
------------------------------------------------------------------------------
However, if (qtdemux->state == QTDEMUX_STATE_MOVIE && qtdemux->got_moov) is TRUE, could we consider that the file is invalid?
test video URL:https://cinelerra-cv.org/footage/grill-mjpeg.mov
**Patch 369369**, "Fix media interruption issue when reverse video":
[0001-qtdemux-add-judgment-condition-when-catch-bogus-size.patch](/uploads/1b6307fe6de5f59e342932c96927462b/0001-qtdemux-add-judgment-condition-when-catch-bogus-size.patch)
Version: 1.12.x