GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-07-07T20:54:23Zhttps://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-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/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/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/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/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/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/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/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/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/gstreamer/-/issues/1337too many open files, still open files after stop pipeline2022-07-22T14:11:14Zdecembersoultoo many open files, still open files after stop pipeline### Describe your issue
I have a problem with open file descriptors with GStreamer 1.18.4 (and 1.20.3)
I have an iOS app which uses gst to receive and demux the video stream. The decoding and displaying is then done by iOS.
However, th...### Describe your issue
I have a problem with open file descriptors with GStreamer 1.18.4 (and 1.20.3)
I have an iOS app which uses gst to receive and demux the video stream. The decoding and displaying is then done by iOS.
However, there are always some file descriptors (FD) left open when I stop the stream and start a new stream.
So not the whole app but only the gstreamer part.
After a while, this results in "too many open files" errors
I have an iOS objectiv c code that shows me all open file descriptors.
I can see that every time I start a stream, 4-6 are added.
If I'm really mean and just close the FD's, then I see that it pops in GstPoll.
So I looked further in there. I see that there are a few FD's used for the poll. I put in some additional debug output and see that it opens in GstPoll but unfortunately never closes.
I suspect that something is not closed cleanly when the pipeline is terminated.
My first guess was that events or messages are not processed and hang.
Am I doing something wrong?
This is very hard to find, so I'm asking for some tips here.
#### Expected Behavior
Play a lot of times
#### Observed Behavior
quit after x times. Sometimes after 256 open files.
#### Setup
- **Operating System:** iOS
- **Device:** iPad
- **GStreamer Version:** 1.18.4 and 1.20.3
- **Command line:** -
### Steps to reproduce the bug
open my app, play a stream, end a stream and repeat play/end
### How reproducible is the bug?
start and stop the pipeline
### Screenshots if relevant
![pipeline](/uploads/5cc7e3dbd19450e2cb854b39ea8e3271/pipeline.png)
### Solutions you have tried
check bus for remaining messages.
### Related non-duplicate issues
### Additional Information
`
```c++
LOGI ("Running...\n");
g_main_loop_run(main_loop);
//gst_event_new_flush_start();
//gst_event_new_flush_stop(FALSE);
//gst_pad_push_event (mCustomData.src, GST_EVENT_FLUSH_START);
/* Free resources */
//LOGI("flush bus");
//gst_bus_set_flushing(bus, TRUE);
gst_object_unref(bus);
/* Out of the main loop, clean up nicely */
LOGI ("Returned, stopping playback\n");
gst_element_set_state(mCustomData.pipeline, GST_STATE_NULL);
LOGI ("Deleting pipeline\n");
gst_object_unref(GST_OBJECT (mCustomData.pipeline));
g_main_loop_unref(mCustomData.main_loop);
`https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1338Automatically rotate video preview, if required, using metadata and `Rotate` ...2023-11-28T13:05:32ZovariAutomatically rotate video preview, if required, using metadata and `Rotate` buttons> When taking a video using a phone the video can show, incorrectly orientated, 180 degrees rotated in [Video Trimmer](https://flathub.org/apps/details/org.gnome.gitlab.YaLTeR.VideoTrimmer).
>
> [Celluloid](https://celluloid-player.gith...> When taking a video using a phone the video can show, incorrectly orientated, 180 degrees rotated in [Video Trimmer](https://flathub.org/apps/details/org.gnome.gitlab.YaLTeR.VideoTrimmer).
>
> [Celluloid](https://celluloid-player.github.io/) and [VLC media player](https://www.videolan.org/vlc/) both show the video correctly.
>
> When [GIMP - GNU Image Manipulation Program](https://gimp.org/) opens images taken with the phone it sometimes asks `Keep original orientation` or `Rotate image`. Does this mean there is [metadata](https://en.wikipedia.org/wiki/Metadata) stored with the file?
>
> 1. Should Video Trimmer automatically rotate the video image 180 degrees, if required, based on the metadata?
> 1. Should a button be added to rotate the preview?
> 1. Should two buttons be added to rotate the preview?<br>
> a) One button to rotate the preview 90 degrees anticlockwise `Rotate left` and another button to rotate the preview 90 degrees clockwise `Rotate right`?<br>
> b) Multiple clicks allowed.<br>
> This functionality is available in [PDF Arranger](https://github.com/pdfarranger/pdfarranger).
>
> What do you think?
>
> Thank you
https://gitlab.gnome.org/YaLTeR/video-trimmer/-/issues/46
> Hey! Video Trimmer uses `GtkMediaStream` for playback, so I'd say there's something missing from either `GtkGstMediaStream` or `GstPlayer` that it uses under the hood. There's not really much I can control from Video Trimmer when using this interface, and it's supposed to "just work" by itself. So I think it should be fixed in either GTK or GStreamer.
https://gitlab.gnome.org/YaLTeR/video-trimmer/-/issues/46#note_1508801https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1340rawvideoparse: did not consider UV tile subsample case in gst_raw_video_parse...2022-07-28T06:12:34ZMacross Chenrawvideoparse: did not consider UV tile subsample case in gst_raw_video_parse_update_info()### Describe your issue
When parsing a NV12_16L32S raw video, gstrawvideoparse produces a wrong size video frame to the downstream element.
for example,
a 320x256 NV12_16L32S raw video, one frame size is 122880 (320x256x1.5),
but in gs...### Describe your issue
When parsing a NV12_16L32S raw video, gstrawvideoparse produces a wrong size video frame to the downstream element.
for example,
a 320x256 NV12_16L32S raw video, one frame size is 122880 (320x256x1.5),
but in gst_raw_video_parse_update_info() it becomes 163840 (320x256x2).
suggestion:
- there is no per-plane w/h in GstVideoFormatInfo
- or it might be calculated by each video format.
### Solutions you have tried
* in the calculation last_plane_size of gst_raw_video_parse_update_info() :
```
if (GST_VIDEO_FORMAT_INFO_IS_TILED (info->finfo)) {
gint stride = GST_VIDEO_INFO_PLANE_STRIDE (info, last_plane);
gint x_tiles = GST_VIDEO_TILE_X_TILES (stride);
gint y_tiles = GST_VIDEO_TILE_Y_TILES (stride);
gint tile_width = 1 << GST_VIDEO_FORMAT_INFO_TILE_WS (info->finfo);
gint tile_height = 1 << GST_VIDEO_FORMAT_INFO_TILE_HS (info->finfo);
if (GST_VIDEO_FORMAT_INFO_FORMAT(info->finfo) == GST_VIDEO_FORMAT_NV12_16L32S) {
/* (UV tile_height) is subsampled */
if (last_plane == 1) {
tile_height = tile_height / 2;
}
}
last_plane_size = x_tiles * y_tiles * tile_width * tile_height;
} else {
....
}
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1341gst/gl/glprototypes/gstgl_compat.h definition of GLsync conflicts with others2022-07-26T00:37:08ZThomas Petazzonigst/gl/glprototypes/gstgl_compat.h definition of GLsync conflicts with othersThe gst/gl/glprototypes/gstgl_compat.h file has this logic:
#if !GST_GL_HAVE_GLSYNC
typedef gpointer GLsync;
#endif
Unfortunately, the real definition of GLsync in the Khronos headers is different. You might think that this is not a pr...The gst/gl/glprototypes/gstgl_compat.h file has this logic:
#if !GST_GL_HAVE_GLSYNC
typedef gpointer GLsync;
#endif
Unfortunately, the real definition of GLsync in the Khronos headers is different. You might think that this is not a problem because when the Khronos headers define GLsync, ```GST_GL_HAVE_GLSYNC``` is defined, and therefore the definition of GLsync by Gstreamer isn't used.
But when the Khronos headers do *not* define GLsync, and you build the Qt plugin in gst-plugins-good, what happens is that:
* GStreamer provides its replacement definition of GLsync: ```typedef gpointer GLsync;```
* Qt provides its replacement definition of GLsync: ```typedef struct __GLsync *GLsync;```
and beng, you get a build failure due to conflicting types:
```
.../host/arm-linucleus-linux-gnueabihf/sysroot/usr/include/gstreamer-1.0/gst/gl/glprototypes/gstgl_compat.h:40:18: error: conflicting declaration ‘typedef void* GLsync’
40 | typedef gpointer GLsync;
| ^~~~~~
.../host/arm-linucleus-linux-gnueabihf/sysroot/usr/include/qt5/QtGui/qopengles2ext.h:24:26: note: previous declaration as ‘typedef struct __GLsync* GLsync’
24 | typedef struct __GLsync *GLsync;
| ^~~~~~
```
The definition from Qt is the correct one, as it's the same in the Khronos headers. The definition in GStreamer however doesn't match, and therefore is probably the incorrect one.
In practice, this issue happens when building gst-plugins-good Qt's plugin, using the OpenGL implementation for RaspberryPi provided by https://github.com/raspberrypi/userland/.
Webkit has also been hit by a similar issue, due to GStreamer defining GLsync "incorrectly": https://bugs.webkit.org/show_bug.cgi?id=185639https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1345alsasink seems to be limited to 8 channels2022-07-27T08:55:56ZSerguei Kozlovskialsasink seems to be limited to 8 channelsHi, I often playback video files with soundtracks that have 9 to 10 channels such as upper-front-left, lower-front-left, upper-front-right, lower-front-right, upper-rear-left, lower-rear-left, upper-rear-right, lower-rear-right, dialog, ...Hi, I often playback video files with soundtracks that have 9 to 10 channels such as upper-front-left, lower-front-left, upper-front-right, lower-front-right, upper-rear-left, lower-rear-left, upper-rear-right, lower-rear-right, dialog, LFE. I had as many as 16 channels in the past based on the application. I have used pulsesink, but I recently switch to alsa-sink and liked it a lot as ALSA gives me more flexibility under Linux as I can use alsa multi plugins to combine a couple of audio devices into one... Anyways, I have encountered that alsa-sink is limited to 8 channels and crashs if I attempt to play 9 or more channels. Forgetting my specific applications, with things like ATMOS becoming more and more popular, it seems that expanding alsa-sink to at least 16 channels or preferably more, would be a welcome thing. Thank you,https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1342`netsim` and `identity` elements should support seeding the random generator2022-07-25T21:50:06ZJeffrey Zampieron`netsim` and `identity` elements should support seeding the random generator### Describe your issue
There is no way to seed the random generator within the `netsim` and `identity` elements when using `drop-probability`.
This is a missing property and makes it impossible to have 100% repeatable unit test behavio...### Describe your issue
There is no way to seed the random generator within the `netsim` and `identity` elements when using `drop-probability`.
This is a missing property and makes it impossible to have 100% repeatable unit test behavior for tests that rely on this element.
The fix is to add an appropriate property.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/226threadshare: ts-udpsrc insufficient caps negotiation compared to udpsrc2022-08-30T06:09:02Zrochaudharithreadshare: ts-udpsrc insufficient caps negotiation compared to udpsrcHere is my receiver:
`gst-launch-1.0 ts-udpsrc port=11000 caps=application/x-rtp ! rtpjitterbuffer ! rtpopusdepay ! opusdec ! fakesink`
and sender:
`gst-launch-1.0 filesrc location=audio_16k.wav ! wavparse ! audioconvert ! deinterlea...Here is my receiver:
`gst-launch-1.0 ts-udpsrc port=11000 caps=application/x-rtp ! rtpjitterbuffer ! rtpopusdepay ! opusdec ! fakesink`
and sender:
`gst-launch-1.0 filesrc location=audio_16k.wav ! wavparse ! audioconvert ! deinterleave ! audioconvert ! audioresample ! opusenc ! rtpopuspay ! udpsink port=11000`
Receiver gives an error:
`Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
ERROR: from element /GstPipeline:pipeline0/RsTsUdpSrc:rstsudpsrc0: Internal data stream error
Additional debug info:
generic/threadshare/src/udpsrc/imp.rs(377): gstthreadshare::udpsrc::imp (): /GstPipeline:pipeline0/RsTsUdpSrc:rstsudpsrc0:
streaming stopped, reason Pad is not negotiated
`
GStreamer Core Library version 1.16.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/227threadshare: ts-udpsrc gives an error with eos event2022-08-30T06:08:14Zrochaudharithreadshare: ts-udpsrc gives an error with eos eventsending eos event to `ts-udpsrc` is not working. I am using `gst_element_send_event(element, gst_event_new_eos())` which is returning `false`. Does it mean event handler missing?sending eos event to `ts-udpsrc` is not working. I am using `gst_element_send_event(element, gst_event_new_eos())` which is returning `false`. Does it mean event handler missing?https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/228threadshare: ts-jitterbuffer missing some params2022-08-30T06:08:31Zrochaudharithreadshare: ts-jitterbuffer missing some paramsthreadshare plugin is missing few params compared to rtpjitterbuffer: faststart-min-packets, drop-on-latency and mode .threadshare plugin is missing few params compared to rtpjitterbuffer: faststart-min-packets, drop-on-latency and mode .