GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-07-21T22:41:46Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1335matroskademux never clears extended-comment tags2022-07-21T22:41:46ZAkito Nozakimatroskademux never clears extended-comment tagsWhen consuming from AWS KVS or mkv with extended-comment tags, the extended-comment tag is never cleared.
#### Expected Behavior
I would expect the tag to be cleared when a tag with the same name is added to the list.
#### Observed Beh...When consuming from AWS KVS or mkv with extended-comment tags, the extended-comment tag is never cleared.
#### Expected Behavior
I would expect the tag to be cleared when a tag with the same name is added to the list.
#### Observed Behavior
Example of the log I'm seeing
```
0:00:00.408059206 464475 0x55f0c5ffc000 DEBUG matroskademux matroska-demux.c:1970:gst_matroska_demux_send_tags:<matroskademux0> Sending global_tags 0x55f0c5f6e590 : taglist, title=(string)"Kinesis\ Video\ SDK", container-format=(string)Matroska, extended-comment=(string){ "AWS_KINESISVIDEO_FRAGMENT_NUMBER\=91343852333182813938717665288591093604867609293", "AWS_KINESISVIDEO_SERVER_TIMESTAMP\=1658326295.221", "AWS_KINESISVIDEO_PRODUCER_TIMESTAMP\=1658326295.183", "AWS_KINESISVIDEO_MILLIS_BEHIND_NOW\=9973", "AWS_KINESISVIDEO_CONTINUATION_TOKEN\=91343852333182813938717665288591093604867609293", "AWS_KINESISVIDEO_FRAGMENT_NUMBER\=91343852333182813943669425445732617381966657914", "AWS_KINESISVIDEO_SERVER_TIMESTAMP\=1658326305.195", "AWS_KINESISVIDEO_PRODUCER_TIMESTAMP\=1658326305.150", "AWS_KINESISVIDEO_MILLIS_BEHIND_NOW\=9955", "AWS_KINESISVIDEO_CONTINUATION_TOKEN\=91343852333182813943669425445732617381966657914", "AWS_KINESISVIDEO_FRAGMENT_NUMBER\=91343852333182813948621185602874141154038790099", "AWS_KINESISVIDEO_SERVER_TIMESTAMP\=1658326315.151", "AWS_KINESISVIDEO_PRODUCER_TIMESTAMP\=1658326315.117", "AWS_KINESISVIDEO_MILLIS_BEHIND_NOW\=9967", "AWS_KINESISVIDEO_CONTINUATION_TOKEN\=91343852333182813948621185602874141154038790099", "AWS_KINESISVIDEO_FRAGMENT_NUMBER\=91343852333182813953572945760015664929440834816", "AWS_KINESISVIDEO_SERVER_TIMESTAMP\=1658326325.119", "AWS_KINESISVIDEO_PRODUCER_TIMESTAMP\=1658326325.083", "AWS_KINESISVIDEO_MILLIS_BEHIND_NOW\=10044", "AWS_KINESISVIDEO_CONTINUATION_TOKEN\=91343852333182813953572945760015664929440834816", "AWS_KINESISVIDEO_FRAGMENT_NUMBER\=91343852333182813958524705917157188710723158129", "AWS_KINESISVIDEO_SERVER_TIMESTAMP\=1658326335.109", "AWS_KINESISVIDEO_PRODUCER_TIMESTAMP\=1658326335.050", "AWS_KINESISVIDEO_MILLIS_BEHIND_NOW\=9937", "AWS_KINESISVIDEO_CONTINUATION_TOKEN\=91343852333182813958524705917157188710723158129", "AWS_KINESISVIDEO_FRAGMENT_NUMBER\=91343852333182813963476466074298712477954886035", "AWS_KINESISVIDEO_SERVER_TIMESTAMP\=1658326345.047", "AWS_KINESISVIDEO_PRODUCER_TIMESTAMP\=1658326345.017", "AWS_KINESISVIDEO_MILLIS_BEHIND_NOW\=9982", "AWS_KINESISVIDEO_CONTINUATION_TOKEN\=91343852333182813963476466074298712477954886035", "AWS_KINESISVIDEO_FRAGMENT_NUMBER\=91343852333182813968428226231440236257366233734", "AWS_KINESISVIDEO_SERVER_TIMESTAMP\=1658326355.030", "AWS_KINESISVIDEO_PRODUCER_TIMESTAMP\=1658326354.983", "AWS_KINESISVIDEO_MILLIS_BEHIND_NOW\=9956", "AWS_KINESISVIDEO_CONTINUATION_TOKEN\=91343852333182813968428226231440236257366233734", "AWS_KINESISVIDEO_FRAGMENT_NUMBER\=91343852333182813973379986388581760029655738809", "AWS_KINESISVIDEO_SERVER_TIMESTAMP\=1658326364.987", "AWS_KINESISVIDEO_PRODUCER_TIMESTAMP\=1658326364.950", "AWS_KINESISVIDEO_MILLIS_BEHIND_NOW\=9980", "AWS_KINESISVIDEO_CONTINUATION_TOKEN\=91343852333182813973379986388581760029655738809", "AWS_KINESISVIDEO_FRAGMENT_NUMBER\=91343852333182813978331746545723283808674689459", "AWS_KINESISVIDEO_SERVER_TIMESTAMP\=1658326374.968", "AWS_KINESISVIDEO_PRODUCER_TIMESTAMP\=1658326374.917", "AWS_KINESISVIDEO_MILLIS_BEHIND_NOW\=9946", "AWS_KINESISVIDEO_CONTINUATION_TOKEN\=91343852333182813978331746545723283808674689459", "AWS_KINESISVIDEO_FRAGMENT_NUMBER\=91343852333182813983283506702864807578357597355", "AWS_KINESISVIDEO_SERVER_TIMESTAMP\=1658326384.915", "AWS_KINESISVIDEO_PRODUCER_TIMESTAMP\=1658326384.883", "AWS_KINESISVIDEO_CONTINUATION_TOKEN\=91343852333182813983283506702864807578357597355", "AWS_KINESISVIDEO_FRAGMENT_NUMBER\=91343852333182813988235266860006331356970818261", "AWS_KINESISVIDEO_SERVER_TIMESTAMP\=1658326394.895", "AWS_KINESISVIDEO_PRODUCER_TIMESTAMP\=1658326394.850", "AWS_KINESISVIDEO_CONTINUATION_TOKEN\=91343852333182813988235266860006331356970818261", "AWS_KINESISVIDEO_FRAGMENT_NUMBER\=91343852333182813993187027017147855136150841697", "AWS_KINESISVIDEO_SERVER_TIMESTAMP\=1658326404.878", "AWS_KINESISVIDEO_PRODUCER_TIMESTAMP\=1658326404.817", "AWS_KINESISVIDEO_MILLIS_BEHIND_NOW\=9941", "AWS_KINESISVIDEO_CONTINUATION_TOKEN\=91343852333182813993187027017147855136150841697", "AWS_KINESISVIDEO_FRAGMENT_NUMBER\=91343852333182813998138787174289378904307565646", "AWS_KINESISVIDEO_SERVER_TIMESTAMP\=1658326414.819", "AWS_KINESISVIDEO_PRODUCER_TIMESTAMP\=1658326414.783", "AWS_KINESISVIDEO_CONTINUATION_TOKEN\=91343852333182813998138787174289378904307565646", "AWS_KINESISVIDEO_FRAGMENT_NUMBER\=91343852333182814003090547331430902683768329867", "AWS_KINESISVIDEO_SERVER_TIMESTAMP\=1658326424.802", "AWS_KINESISVIDEO_PRODUCER_TIMESTAMP\=1658326424.750", "AWS_KINESISVIDEO_MILLIS_BEHIND_NOW\=9960", "AWS_KINESISVIDEO_CONTINUATION_TOKEN\=91343852333182814003090547331430902683768329867", "AWS_KINESISVIDEO_FRAGMENT_NUMBER\=91343852333182814008042307488572426456935450750", "AWS_KINESISVIDEO_SERVER_TIMESTAMP\=1658326434.762", "AWS_KINESISVIDEO_PRODUCER_TIMESTAMP\=1658326434.717" };
```
Attaching output of `mkinfo -a test.mkv`
[mkvinfo.txt](/uploads/c110ef357a5926a8309ac9f0722378f9/mkvinfo.txt)
link to the test video: [test.mkv](https://drive.google.com/file/d/10TAAPxDCnXZtlYwT3Nu4jKcbmP067D92/view?usp=sharing)
#### Setup
- **Operating System:** ubuntu 20.04
- **Device:** Desktop Machine
- **GStreamer Version:** 1.20.3
- **Command line:** gst-launch-1.0 filesrc location=test.mkv ! matroskademux ! fakesink
### Steps to reproduce the bug
Use a simple test.mkv with multiple extended comments.
I generated the test.mkv by pushing a videotestsrc to kvs using:
gst-launch-1.0 videotestsrc is-live=true pattern=snow ! x264enc ! kvssink stream-name=test-stream aws-region=us-west-2 credential-path=./aws_credentials
Then simply saved the output from KVS to a file.
In my actual code, I'm streaming the KVS data into gstreamer using appsink.
### Solutions you have tried
I started with a version that comes with ubuntu, which was 1.16.2, and worked my way up to 1.20.3 (which I compiled myself).https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/219tracers: queue-levels / buffer-lateness: Support for writing out file periodi...2022-07-20T10:22:24ZSebastian Drögetracers: queue-levels / buffer-lateness: Support for writing out file periodically in a background threadhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1331webrtcbin: Input caps changes handling2023-01-15T14:25:47ZPhilippe Normandwebrtcbin: Input caps changes handlingI have a test case in WebKit where the PeerConnection is initially configured for VP8 sending and then re-configured to send H.264. In webrtcbin the sink pad receives a CAPS event, but doesn't re-trigger negotiation. There is a FIXME abo...I have a test case in WebKit where the PeerConnection is initially configured for VP8 sending and then re-configured to send H.264. In webrtcbin the sink pad receives a CAPS event, but doesn't re-trigger negotiation. There is a FIXME about this which might be related in `_check_if_negotiation_is_needed()`: ` /* FIXME: emit when input caps/format changes? */`https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/217threadshare: appsrc is missing callbacks for need-data2022-08-30T06:09:17ZJeremy Clinethreadshare: appsrc is missing callbacks for need-dataI've got an application that creates many pipelines for transcoding realtime media and would very much like to replace my usage of `appsrc` with `ts-appsrc`. Currently, I'm using the `appsrc` [callbacks](https://gstreamer.freedesktop.org...I've got an application that creates many pipelines for transcoding realtime media and would very much like to replace my usage of `appsrc` with `ts-appsrc`. Currently, I'm using the `appsrc` [callbacks](https://gstreamer.freedesktop.org/documentation/applib/gstappsrc.html?gi-language=c#gst_app_src_set_callbacks) to push data into the pipeline from an asynchronous runtime, but unfortunately the `ts-appsrc` doesn't have a similar interface.
I'm interested in making this work, but before I wandered too far down that path I wanted to see if folks would be open to such an interface being added to `ts-appsrc`.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1330gstapp timeout and application crash2022-07-14T12:50:52ZGokila Mgstapp timeout and application crashHello,
We have a Media Server integrated with GStreamer for transcoding. Our application is running absolutely fine in production system.
Recently, we have upgraded the G-Streamer to 1.20.0 version and integration went fine without err...Hello,
We have a Media Server integrated with GStreamer for transcoding. Our application is running absolutely fine in production system.
Recently, we have upgraded the G-Streamer to 1.20.0 version and integration went fine without errors.
When we run the application, even for a single call we see that G-Streamer timeout happens when we transcode the media.
Every time our Media Server application crashed due to this issue and the dump is being generated.
While analysing the dump, it is pointing the G-Streamer function as mentioned below,
```
0:159> ~#kv
ChildEBP RetAddr Args to Child
WARNING: Frame IP not in any known module. Following frames may be wrong.
2d11eb6c 6fb4986b 2678e7c0 0a15bea8 f1683d72 0x1633eaed
2d11eb98 77c58389 00000000 00000021 25d2b0a8 **libgstapp_1_0_0!gst_app_src_set_callbacks+0x16ab**
2d11ec30 77c582b7 25d2b0a8 6df29bed 6810ab1e ntdll!RtlReAllocateHeap+0x109
2d11ec6c 64bf74bb 25d2b0a8 2d11ec8c 7573261b ntdll!RtlReAllocateHeap+0x37
2d11ec78 7573261b 01430000 00000000 00000000 libglib_2_0_0!g_realloc+0x2b
2d11ec8c 64c4688f 266b3634 00000000 00000020 ucrtbase!free_base+0x1b
2d11ecac 6de99217 266b3634 2d11ecf0 77c53e1d libglib_2_0_0!g_mutex_unlock+0xf
2d11ecb8 77c53e1d 0000000c 00000000 264da6c1 libgstreamer_1_0_0!gst_mini_object_remove_parent+0x3527
2d11ed1c 64bf74bb 262ff548 00000000 00000000 ntdll!RtlAllocateHeap+0x23d
00000000 00000000 00000000 00000000 00000000 libglib_2_0_0!g_realloc+0x2b
```
Please provide your comments on this issue and let us know if you need any additional information.
Also please provide steps to capture the G-Streamer logs.
Note: We can able to capture the G-Streamer logs when we invoke it independently. How do we capture the logs when G-Streamer integrated with any other application ?
Thanks in advance,
Gokilahttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1325opusenc: Bad quality with low bitrates2022-07-13T12:56:59ZNicolas Cavallariopusenc: Bad quality with low bitratesThe `opusenc` element from gst-plugin-base with bitrate=8000 produce bad quality output, much worse than the `opusenc` program from opus-tools.
Compare:
```
$ gst-launch-1.0 -e audiotestsrc is-live=true '!' opusenc bitrate=8000 '!' oggm...The `opusenc` element from gst-plugin-base with bitrate=8000 produce bad quality output, much worse than the `opusenc` program from opus-tools.
Compare:
```
$ gst-launch-1.0 -e audiotestsrc is-live=true '!' opusenc bitrate=8000 '!' oggmux '!' filesink location=/tmp/test-gstreamer.opus
```
with
```
$ gst-launch-1.0 -e audiotestsrc is-live=true '!' wavenc '!' filesink location=/tmp/test.wav
$ opusenc --hard-cbr --bitrate=8 /tmp/test.wav /tmp/test-opustools.opus
```
The first produce a file with a very noisy sine, while the second is almost a pure sine.
Replacing the sine with actual voice data produce the same effect. The bad quality is always reproducible with every tested opus decoder, including gstreamer's `opusdec` and opus-tools's `opusdec`.
Tested on debian unstable amd64 (gstreamer 1.20.3, libopus 1.3.1, opus-tools 0.1.10)
and also on armv7 with a gstreamer compiled from git (4902076968bb62fc03f70bc7c733eeb1d26f40d2) with the same libopus 1.3.1 and a more recent version of opus-tools.
### Additional Information
In newer opus-tools versions, `opusenc` uses the libopusenc wrapper library instead of directly using libopus.
Both libopusenc and gstreamer use libopus in a similar way, except for the `OPUS_SET_PREDICTION_DISABLED` handling in libopusenc.
I also suspected a discontinuity issue, but the opusenc element always get 20ms of samples at a time, which is exactly what libopus wants, so no clipping appears to be done in `gst_opus_enc_encode()`.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1324docs: Windows installation guide must be updated2022-07-11T19:58:25ZSeungha Yangseungha@centricular.comdocs: Windows installation guide must be updatedSee https://gstreamer.freedesktop.org/documentation/installing/on-windows.html?gi-language=c
Many things are outdated (mentioning ancient VS 2010 and Win7 for example) and even wrong (`GSTREAMER_ROOT_X86_64`, `WinDDK`, `MSVCRT.dll`, etc)See https://gstreamer.freedesktop.org/documentation/installing/on-windows.html?gi-language=c
Many things are outdated (mentioning ancient VS 2010 and Win7 for example) and even wrong (`GSTREAMER_ROOT_X86_64`, `WinDDK`, `MSVCRT.dll`, etc)https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/105Links are not working / are not visible on the rtpbin documentation page2022-09-09T16:03:27Zdb-techLinks are not working / are not visible on the rtpbin documentation pageLinks are not working / are not visible on the rtpbin documentation page
[https://gstreamer.freedesktop.org/documentation/rtpmanager/rtpbin.html?gi-language=c#rtpbin ](https://gstreamer.freedesktop.org/documentation/rtpmanager/rtpbin.htm...Links are not working / are not visible on the rtpbin documentation page
[https://gstreamer.freedesktop.org/documentation/rtpmanager/rtpbin.html?gi-language=c#rtpbin ](https://gstreamer.freedesktop.org/documentation/rtpmanager/rtpbin.html?gi-language=c#rtpbin)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1323SDPDEMUX : Padname stream_0 is not unique in element sdpdemux0, not adding2022-07-19T17:37:14ZChristophe LAFOLETSDPDEMUX : Padname stream_0 is not unique in element sdpdemux0, not addingDetected on Linux with GStreamer 1.20.3
Start a client :
gst-launch-1.0 filesrc location=file.sdp ! sdpdemux ! decodebin ! glimagesink
Start a server :
gst-launch-1.0 -v gltestsrc ! glcolorconvert ! "video/x-raw(memory:GLMemory),format...Detected on Linux with GStreamer 1.20.3
Start a client :
gst-launch-1.0 filesrc location=file.sdp ! sdpdemux ! decodebin ! glimagesink
Start a server :
gst-launch-1.0 -v gltestsrc ! glcolorconvert ! "video/x-raw(memory:GLMemory),format=NV12,width=640,height=480,framerate=30/1" ! queue ! nvh264enc ! rtph264pay config-interval=-1 ! udpsink port=5000 host=127.0.0.1
=> the client connect to the stream => OK
Stop the server, re-start the server
=> the client do not reconnect to the stream and crash => KO
In method sdpdemux::new_session_pad, a pad with name "stream_0" is added for the first session.
On server lost, no pad is removed. On the re-start, sdpdemux try to add an new pad "stream_0" but a pad still exists with this name.
- 0:00:07.899807062 3430 0x7f64a0088860 DEBUG sdpdemux gstsdpdemux.c:524:new_session_pad:<sdpdemux0> got new session pad <rtpbin0:recv_rtp_src_0_170610515_96>
- 0:00:07.899837704 3430 0x7f64a0088860 DEBUG sdpdemux gstsdpdemux.c:532:new_session_pad:<sdpdemux0> stream: 0, SSRC 170610515, PT 96
- 0:00:07.899914007 3430 0x7f64a0088860 INFO GST_PADS gstpad.c:2382:gst_pad_link_prepare: trying to link rtpbin0:recv_rtp_src_0_170610515_96 and stream_0:proxypad9
- 0:00:07.899937413 3430 0x7f64a0088860 INFO GST_PADS gstpad.c:2590:gst_pad_link_full: linked rtpbin0:recv_rtp_src_0_170610515_96 and stream_0:proxypad9, successful
- 0:00:07.899957868 3430 0x7f64a0088860 INFO GST_EVENT gstevent.c:1660:gst_event_new_reconfigure: creating reconfigure event
- 0:00:07.900016894 3430 0x7f64a0088860 INFO GST_ELEMENT_PADS gstelement.c:759:gst_element_add_pad:<sdpdemux0> adding pad 'stream_0'
-
- (gst-launch-1.0:3430): GStreamer-CRITICAL **: 15:26:19.007: Padname stream_0 is not unique in element sdpdemux0, not adding
- 0:00:07.900147525 3430 0x7f64a0088860 INFO GST_ELEMENT_PADS gstpad.c:2137:gst_pad_unlink: unlinking rtpbin0:recv_rtp_src_0_170610515_96(0x5640a763fd90) and stream_0:proxypad9(0x7f648800c120)
- 0:00:07.900177248 3430 0x7f64a0088860 INFO GST_ELEMENT_PADS gstpad.c:2192:gst_pad_unlink: unlinked rtpbin0:recv_rtp_src_0_170610515_96 and stream_0:proxypad9
- 0:00:07.900213628 3430 0x7f64a0088860 DEBUG sdpdemux gstsdpdemux.c:570:new_session_pad:<sdpdemux0> We added all streamshttps://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/330HEVC Encode corruption with max_transform_hierarchy_depth_inter=22022-07-08T04:26:33ZBoyuan ZhangHEVC Encode corruption with max_transform_hierarchy_depth_inter=2HEVC encode output shows corruption using any AMD/radeon GPU. The issue is cause by patch: https://github.com/GStreamer/gstreamer-vaapi/commit/17d82e14e78af901f1cd7f2344e173ad6ae6a8a6. (According to comment, this workaround was made due ...HEVC encode output shows corruption using any AMD/radeon GPU. The issue is cause by patch: https://github.com/GStreamer/gstreamer-vaapi/commit/17d82e14e78af901f1cd7f2344e173ad6ae6a8a6. (According to comment, this workaround was made due to Intel HW limitations at that time)
After reverting above changes, all tests pass.https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/376MinGW toolchain (v6.0.0) is too ancient2022-07-07T20:54:23ZSeungha Yangseungha@centricular.comMinGW toolchain (v6.0.0) is too ancientThere are a few (super ugly) hacks in `gstd3d11` to make things work with current MinGW toolchain and
I gave up shipping `mediafoundation`/`wasapi2`/`wic` plugins in case of MinGW build because a lot of things are broken in the current ...There are a few (super ugly) hacks in `gstd3d11` to make things work with current MinGW toolchain and
I gave up shipping `mediafoundation`/`wasapi2`/`wic` plugins in case of MinGW build because a lot of things are broken in the current MinGW toolchain.
We should upgrade it to the most recent versionhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1322Unknown SDP type in python bindings (maybe memory corruption)2022-07-08T03:31:26Zle-chatUnknown SDP type in python bindings (maybe memory corruption)Webrtcbin on create-answer returns WebRTCSessionDescription with unknown WebRTCSDPType (enum value varies at each run) and empty SDP when used as
```python
answer = promise.get_reply().get_value("answer")
```
Though all right if split th...Webrtcbin on create-answer returns WebRTCSessionDescription with unknown WebRTCSDPType (enum value varies at each run) and empty SDP when used as
```python
answer = promise.get_reply().get_value("answer")
```
Though all right if split this to two lines
```python
reply = promise.get_reply()
answer = reply.get_value("answer")
```
Full script is here: https://gist.github.com/le-chat/f0aa4222b5a978446ce937ac59341ba8#file-test-py
And logs are in https://gist.github.com/le-chat/f0aa4222b5a978446ce937ac59341ba8#file-log-txt
Tested on Ubuntu 22.04 (gstreamer 1.20.1, python 3.10) and NixOS 22.05 (gstreamer 1.20.1, python 3.9).
Expected behaviour: get WebRTCSessionDescription with WebRTCSDPType=ANSWER and some SDP.
Observed behaviour: got WebRTCSessionDescription with WebRTCSDPType=unknown random-looking integer and sdp=None.
To reproduce with Nix:
```
git clone https://gist.github.com/f0aa4222b5a978446ce937ac59341ba8.git gst-python-bug-report
cd gst-python-bug-report
nix-shell --run "python test.py"
```
Thanks to Matthew Waters who guess the workaround in https://lists.freedesktop.org/archives/gstreamer-devel/2022-July/080197.htmlhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1321RTP retransmission doesn't seem to be working with rtpbin2022-08-24T16:11:11ZAlireza MiryazdiRTP retransmission doesn't seem to be working with rtpbin### Describe your issue
Activating RTP re-transmission still produces choppy output, even while using the example from the [doc](https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good/html/gst-plugins-good-plugins-rtp...### Describe your issue
Activating RTP re-transmission still produces choppy output, even while using the example from the [doc](https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good/html/gst-plugins-good-plugins-rtprtxqueue.html).
I used it with audio (`audiotestsrc`) and video (`videotestsrc pattern=ball`) and was unsuccessful with both.
#### Expected Behavior
Smooth video/audio
#### Observed Behavior
Audio/video has noticeable choppiness
#### Setup
- Run both on Void Linux(musl - GStreamer 1.20.3) and Windows 10(x64 - GStreamer version 1.20.2)
### Steps to reproduce the bug
Run both these commands in 2 terminals. I also tried running the server in an external VPS and still had the issue.
__Server__:
```
gst-launch-1.0 rtpbin -v name=b rtp-profile=avpf audiotestsrc is-live=true ! opusenc ! rtpopuspay pt=96 ! rtprtxqueue ! b.send_rtp_sink_0 b.send_rtp_src_0 ! udpsink host=127.0.0.1 port=5000 udpsrc port=5001 ! b.recv_rtcp_sink_0 b.send_rtcp_src_0 ! udpsink host=127.0.0.1 port=5002 sync=false async=false
```
__Client__:
```
gst-launch-1.0 rtpbin -v name=b rtp-profile=avpf do-retransmission=true udpsrc port=5000 caps="application/x-rtp,media=(string)audio,clock-rate=(int)48000,encoding-name=(string)OPUS,payload=(int)96" ! netsim drop-probability=0.15 ! b.recv_rtp_sink_0 b. ! rtpopusdepay ! opusdec ! audioconvert ! audioresample ! autoaudiosink udpsrc port=5002 ! b.recv_rtcp_sink_0 b.send_rtcp_src_0 ! udpsink host="127.0.0.1" port=5001 sync=false async=false
```
Any guidance would be greatly appreciated. Thank you for your time.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1319Choppy video when using mp4mux with udpsrc2022-07-06T22:11:54ZDavid GrinbergChoppy video when using mp4mux with udpsrcGStreamer version: 1.21.0, built from source - commit b233df3537a67c551d36c69796b05e8d27cf981e
Platform: Ubuntu 20.04 in Docker
I have these pipelines which i'm running on the same machine:
```
gst-launch-1.0 -e -v filesrc location=e...GStreamer version: 1.21.0, built from source - commit b233df3537a67c551d36c69796b05e8d27cf981e
Platform: Ubuntu 20.04 in Docker
I have these pipelines which i'm running on the same machine:
```
gst-launch-1.0 -e -v filesrc location=example_x264.mp4 do-timestamp=true ! qtdemux ! h264parse ! rtph264pay ! multiudpsink clients="127.0.0.1:$PORT"
```
```
gst-launch-1.0 -e udpsrc port=$PORT caps="application/x-rtp, encoding-name=(string)H264" ! rtpjitterbuffer mode=0 ! rtph264depay ! h264parse ! mp4mux ! filesink location=result.mp4
```
The problem is that when I use mp4mux the ```result.mp4``` file contains choppy and slowed video, but everything is fine if I use matroskamux instead.
What i've tried:
* Different latency properties on mp4mux and rtpjitterbuffer
* Replacing rtpjitterbuffer with queue/queue2 kinda helped - resulting video was choppy in one player and OK in VLC
Files attached:
![example_x264](/uploads/0f3ebfcc4ac4f5caaa8f233fc7a87034/example_x264.mp4)
![result](/uploads/dab5f2c83ad0bced8d2a19a54aa5b303/result.mp4)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1318webrtcbin: Missing ICE restart support2022-07-09T13:57:03ZPhilippe Normandwebrtcbin: Missing ICE restart supportPerhaps this could be exposed as an action signal? There are some FIXMEs about this in the code as well.Perhaps this could be exposed as an action signal? There are some FIXMEs about this in the code as well.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1317plugin for 3d camera2022-07-05T09:17:05ZAlberto Fanjulplugin for 3d cameraI'm open this general issue to check if there's any solution to render a viewport from a 3d camera.
![Captura_desde_2022-07-05_10-52-01](/uploads/151a38eaa487daf3993870aba6a16727/Captura_desde_2022-07-05_10-52-01.png)
I'm playing with ...I'm open this general issue to check if there's any solution to render a viewport from a 3d camera.
![Captura_desde_2022-07-05_10-52-01](/uploads/151a38eaa487daf3993870aba6a16727/Captura_desde_2022-07-05_10-52-01.png)
I'm playing with gst-plugins-vr and it almost work:
https://github.com/lubosz/gst-plugins-vr/issues/19https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1316Rename -bad2024-02-16T13:50:41ZPhilippe NormandRename -badFor years now people see -bad and think, oh this is bad, we must avoid it at all cost... This name is so misleading. What about -staging? Or something else that has no misleading meaning?For years now people see -bad and think, oh this is bad, we must avoid it at all cost... This name is so misleading. What about -staging? Or something else that has no misleading meaning?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1313gstwebrtcbin.c: retransmissions work with bundle-policy=max-bundle but not wi...2023-01-06T03:29:42ZMarkus Pollakgstwebrtcbin.c: retransmissions work with bundle-policy=max-bundle but not with default bundle-policyHello,
I've found a bug in gstwebrtcbin.c (https://github.com/GStreamer/gst-plugins-bad/blob/master/ext/webrtc/gstwebrtcbin.c) which causes retransmissions (RTX for NACKs) to not work in common scenarios. I've also found the root cause ...Hello,
I've found a bug in gstwebrtcbin.c (https://github.com/GStreamer/gst-plugins-bad/blob/master/ext/webrtc/gstwebrtcbin.c) which causes retransmissions (RTX for NACKs) to not work in common scenarios. I've also found the root cause and provide a detailed explanation:
**Setup:**
- Gstreamer installation based on restreamio/gstreamer:1.19.2.0-prod Docker image
- do-nack is set to true at the transceiver (fec-type is not set as I'm testing retransmissions only)
- gst1-java-core:1.4.0 is used to build up the pipeline
- Gstreamer is used to send a video stream (video only, no audio, send-only) to Chrome
- A range of multiple video source is used (rtspsrc, srtsrc, videotestsrc, ...)
- Chrome on Windows is used for receiving a video-stream via WebRTC
- H264 encoding (baseline and high profile) is used in different cases
- Clumsy is used for simulating packet loss (client-side)
**SDPs:**
The SDPs are correctly mentioning nack and rtx and pt mappings seem to be correct.
**SDP Offer:**
```
v=0
o=- 8338404406669528263 0 IN IP4 0.0.0.0
s=-
t=0 0
a=ice-options:trickle
m=video 9 UDP/TLS/RTP/SAVPF 97 96
c=IN IP4 0.0.0.0
a=setup:actpass
a=ice-ufrag:qt8YBq9p6brgGFJPTcOEZnpzNuGGaiZc
a=ice-pwd:IUzbx6zU7c1cAEpr9v8pUd8fQX4WMWc4
a=rtcp-mux
a=rtcp-rsize
a=sendonly
a=rtpmap:97 H264/90000
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 transport-cc
a=framerate:25
a=fmtp:97 packetization-mode=1;profile-level-id=4d001f;sprop-parameter-sets=Z00AH5Y1QKALdNwEBAUAAAcIAAFfkAQ=,aO48gA==
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=97
a=ssrc-group:FID 2 876927395
a=ssrc:2 msid:user73081093@host-10bea89f webrtctransceiver4
a=ssrc:2 cname:user73081093@host-10bea89f
a=ssrc:876927395 msid:user73081093@host-10bea89f webrtctransceiver4
a=ssrc:876927395 cname:user73081093@host-10bea89f
a=mid:video0
a=fingerprint:sha-256 5A:BB:64:EB:DA:4C:59:AE:25:97:46:BA:18:BC:67:A1:8A:8B:30:15:B0:D3:F0:21:7C:43:95:79:DA:EA:66:25
a=rtcp-mux-only
```
**SDP Answer:**
```
v=0
o=- 9170499300271825649 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic: WMS
m=video 9 UDP/TLS/RTP/SAVPF 97 96
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:eFrN
a=ice-pwd:8X4CVq0UQPKCyHgT9Mt+ArfF
a=ice-options:trickle
a=fingerprint:sha-256 9E:43:31:2F:55:64:63:76:53:B8:35:F9:9B:B9:AD:71:04:95:E2:F9:2A:66:71:2D:64:B0:26:42:E8:4D:CD:73
a=setup:active
a=mid:video0
a=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:97 H264/90000
a=rtcp-fb:97 transport-cc
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=fmtp:97 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d001f
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=97
```
I can see that NACKs are sent by Chrome via chrome://webrtc-internals
The NACK count is increasing when packets are lost.
So far so good, but the retransmissions through Gstreamer don't work yet.
**I've debugged it and finally found the reason in gstwebrtcbin.c:**
on_rtpbin_request_aux_sender calls _set_rtx_ptmap_from_stream (webrtc, stream) after creating the rtprtxsend (rtx = gst_element_factory_make ("rtprtxsend", NULL)) while stream->rtxsend has not yet been set.
It's basically set at the end of on_rtpbin_request_aux_sender: stream->rtxsend = gst_object_ref (rtx);
I can verify that _set_rtx_ptmap_from_stream is called only once while rtprtxsend is null via the logs (GST_DEBUG='3,rtprtx*:5,webrtc*:6'):
```
0:01:19.678286676 6 0x7fd1c42d7060 DEBUG webrtcbin gstwebrtcbin.c:4313:_set_rtx_ptmap_from_stream:<transportstream0> setting payload map on (NULL) : (NULL) and application/x-rtp-pt-map, 97=(uint)96;
```
The following logs show that the retransmissions triggered by NACKs are not working:
```
0:01:19.679474693 6 0x7fd1c53bc700 WARN rtprtxsend gstrtprtxsend.c:655:gst_rtp_rtx_send_sink_event:<rtprtxsend0> Payload 97 not in rtx-pt-map
```
and
```
0:08:28.606424318 6 0x7fd1a1176c60 DEBUG rtprtxsend gstrtprtxsend.c:489:gst_rtp_rtx_send_src_event:<rtprtxsend0> got rtx request for seqnum: 31149, ssrc: 2
0:08:28.606434319 6 0x7fd1a1176c60 WARN rtprtxsend gstrtprtxsend.c:525:gst_rtp_rtx_send_src_event:<rtprtxsend0> requested seqnum 31149 has not been transmitted yet in the original stream; eithe
r the remote end is not configured correctly, or the source is too slow
0:08:28.606442719 6 0x7fd1a1176c60 DEBUG rtprtxsend gstrtprtxsend.c:489:gst_rtp_rtx_send_src_event:<rtprtxsend0> got rtx request for seqnum: 31150, ssrc: 2
0:08:28.606447819 6 0x7fd1a1176c60 WARN rtprtxsend gstrtprtxsend.c:525:gst_rtp_rtx_send_src_event:<rtprtxsend0> requested seqnum 31150 has not been transmitted yet in the original stream; eithe
r the remote end is not configured correctly, or the source is too slow
```
The lost packets are not received by Chrome too and the video stream starts freezing already at <5% packet loss.
This is problematic because _set_rtx_ptmap_from_stream only sets the "playload-type-map" if stream->rtxsend is set which is not the case:
```
if (stream->rtxreceive)
g_object_set (stream->rtxreceive, "payload-type-map", pt_map, NULL);
if (stream->rtxsend)
g_object_set (stream->rtxsend, "payload-type-map", pt_map, NULL);
```
A workaround is to use bundle-policy=max-bundle because in this case _set_rtx_ptmap_from_stream is called a second time from _update_transceiver_from_sdp_media:
```
if (!bundled || bundle_idx == media_idx) {
if (stream->rtxsend || stream->rtxreceive) {
_set_rtx_ptmap_from_stream (webrtc, stream);
}
g_object_set (stream, "dtls-client",
new_setup == GST_WEBRTC_DTLS_SETUP_ACTIVE, NULL);
}
```
**The workaround can be verified via logs too:**
The "payload-type-map" is set via _set_rtx_ptmap_from_stream at the second call (from _update_transceiver_from_sdp_media) with `stream->rtxsend` being not null:
```
0:01:11.110764316 7 0x7f9220b115e0 DEBUG webrtcbin gstwebrtcbin.c:4313:_set_rtx_ptmap_from_stream:<transportstream0> setting payload map on (NULL) : (NULL) and application/x-rtp-pt-map, 97=(uin
t)96;
0:01:11.111793531 7 0x7f9220b115e0 DEBUG webrtcbin gstwebrtcbin.c:4313:_set_rtx_ptmap_from_stream:<transportstream0> setting payload map on (NULL) : <rtprtxsend0> and application/x-rtp-pt-map,
97=(uint)96;
```
The requested packets are found and retransmitted:
```
0:02:35.661652056 7 0x7f91fc840d20 DEBUG rtprtxsend gstrtprtxsend.c:489:gst_rtp_rtx_send_src_event:<rtprtxsend0> got rtx request for seqnum: 45671, ssrc: 2
0:02:35.661658856 7 0x7f91fc840d20 DEBUG rtprtxsend gstrtprtxsend.c:405:gst_rtp_rtx_buffer_new:<rtprtxsend0> creating rtx buffer, orig seqnum: 45671, rtx seqnum: 58534, rtx ssrc: 851211DE
0:02:35.661680057 7 0x7f91fc840d20 DEBUG rtprtxsend gstrtprtxsend.c:489:gst_rtp_rtx_send_src_event:<rtprtxsend0> got rtx request for seqnum: 45672, ssrc: 2
0:02:35.661693457 7 0x7f91fc840d20 DEBUG rtprtxsend gstrtprtxsend.c:405:gst_rtp_rtx_buffer_new:<rtprtxsend0> creating rtx buffer, orig seqnum: 45672, rtx seqnum: 58535, rtx ssrc: 851211DE
0:02:35.661705557 7 0x7f91fc840d20 DEBUG rtprtxsend gstrtprtxsend.c:489:gst_rtp_rtx_send_src_event:<rtprtxsend0> got rtx request for seqnum: 45673, ssrc: 2
0:02:35.661715557 7 0x7f91fc840d20 DEBUG rtprtxsend gstrtprtxsend.c:405:gst_rtp_rtx_buffer_new:<rtprtxsend0> creating rtx buffer, orig seqnum: 45673, rtx seqnum: 58536, rtx ssrc: 851211DE
0:02:35.661726757 7 0x7f91fc840d20 DEBUG rtprtxsend gstrtprtxsend.c:489:gst_rtp_rtx_send_src_event:<rtprtxsend0> got rtx request for seqnum: 45674, ssrc: 2
```
Now the retransmission is working and the video stream is still stable at >20% packet loss.
I would appreciate if someone from the Gstreamer community could verify my bug report and fix it.
Thank you!
Best regards,
Markus Pollakhttps://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/392Add support for GstD3D11 binding2022-06-28T20:56:20ZSeungha Yangseungha@centricular.comAdd support for GstD3D11 binding`Direct3D` is the primary graphics and multimedia API on Windows, a kind of OpenGL/Vulkan + VAAPI/NVCODEC + window system (e.g., x11/wayland) + etc (some OS layer optimized features, screen capturing for example).
Now `GstD3D11` is a pu...`Direct3D` is the primary graphics and multimedia API on Windows, a kind of OpenGL/Vulkan + VAAPI/NVCODEC + window system (e.g., x11/wayland) + etc (some OS layer optimized features, screen capturing for example).
Now `GstD3D11` is a public library (but still experimental) in GStreamer term. So, adding support for `GstD3D11` binding would be greathttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1307SYNC/ASYNC KLV support2023-03-31T06:56:14ZAlex CSYNC/ASYNC KLV supportHi guys,
I'm having trouble trying to play files with **SYNC KLV**. Video freezes on the first frame (with any sync klv file I tried).
Here are two identical files, except that the first one has ASYNC KLV and the second one has a SYNC ...Hi guys,
I'm having trouble trying to play files with **SYNC KLV**. Video freezes on the first frame (with any sync klv file I tried).
Here are two identical files, except that the first one has ASYNC KLV and the second one has a SYNC KLV:
- [test-klv-async.ts](https://1drv.ms/v/s!AgXQnBFeIFXX43QMaRfdwIiszPgp?e=UCjzI0)
- [test-klv-sync.ts](https://1drv.ms/v/s!AgXQnBFeIFXX43WMFJuKqpB74Pb4?e=uvgTZM)
Here is a simplified pipeline:
`gst-launch-1.0 filesrc location=C:/Movie/test-klv-sync.ts ! tsdemux name=demux demux. ! queue ! h264parse ! avdec_h264 ! videoconvert ! autovideosink demux. ! queue ! meta/x-klv ! fakesink dump=true`
File with ASYNC KLV will play just fine, but the sync one will freeze on the first frame. I tried many things (gst-launch and code)... Nothing helps. It doesn't work with any GStreamer version.
I saw some discussions on this (and of course, I know that ASYNC and SYNC Klv have different descriptors - all [the relevant info here](https://impleotv.com/2017/02/17/klv-encoded-metadata-in-stanag-4609-streams/)).
How can I solve this? Is there any way to pass something different instead of meta/x-klv so I could get binary KLV data?
Thanks,
Alex