GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2023-06-05T09:18:32Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2637hlsdemux2: Limit amount of HLSTimeMap stored2023-06-05T09:18:32ZEdward Herveyhlsdemux2: Limit amount of HLSTimeMap storedRight now the HLSTimeMap list is only cleared when the element is resetted.
It might be good to figure out a way to limit the amount stored. Like only keep the last n-th.
When updating from playlists, look at the first DSN, keep fr...Right now the HLSTimeMap list is only cleared when the element is resetted.
It might be good to figure out a way to limit the amount stored. Like only keep the last n-th.
When updating from playlists, look at the first DSN, keep from N before that one.
Also make it an array (instead of a list) while at it.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2636hlsdemux2 : Not all subtitles are present in track/collection. Usage of `FORC...2023-06-05T09:16:41ZEdward Herveyhlsdemux2 : Not all subtitles are present in track/collection. Usage of `FORCE` `EXT-X-MEDIA` fieldStream : https://devstreaming-cdn.apple.com/videos/streaming/examples/bipbop_16x9/bipbop_16x9_variant.m3u8
Only the "forced" subtitle streams end up being used, the others are considered as duplicates.Stream : https://devstreaming-cdn.apple.com/videos/streaming/examples/bipbop_16x9/bipbop_16x9_variant.m3u8
Only the "forced" subtitle streams end up being used, the others are considered as duplicates.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2635dashdemux2 : Add synchronization loss support2023-06-05T09:13:11ZEdward Herveydashdemux2 : Add synchronization loss supportIf the pipeline is paused, or playback is too slow, the next playlist update might be outside of the available window.
We need to gracefully handle that by returning `GST_DEMUX_FLOW_LOST_SYNC`If the pipeline is paused, or playback is too slow, the next playlist update might be outside of the available window.
We need to gracefully handle that by returning `GST_DEMUX_FLOW_LOST_SYNC`https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2634dvdlpcmdec? mpegpsdemux? some vob files with lpcm audio don't preroll2023-06-04T10:42:04ZBugzilla Migration Userdvdlpcmdec? mpegpsdemux? some vob files with lpcm audio don't preroll## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#603528)](https://bugzilla.gnome.org/show_bug.cgi?id=603528)**
## Description
i have a vob file with an lpcm audio track only and it doesn't start playing with play...## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#603528)](https://bugzilla.gnome.org/show_bug.cgi?id=603528)**
## Description
i have a vob file with an lpcm audio track only and it doesn't start playing with playbin2 or decodebin2
what works fine is plugging the pipeline manually like this:
gst-launch-0.10 filesrc location=VTS_01_1.VOB ! dvddemux ! dvdlpcmdec ! multiqueue ! audioconvert ! audioresample ! alsasinkhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2633asfdemux: scan files saved from broadcast to report duration and support seeking2023-06-04T10:40:25ZBugzilla Migration Userasfdemux: scan files saved from broadcast to report duration and support seeking## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#678531)](https://bugzilla.gnome.org/show_bug.cgi?id=678531)**
## Description
But MPlayer could seek in it.## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#678531)](https://bugzilla.gnome.org/show_bug.cgi?id=678531)**
## Description
But MPlayer could seek in it.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2632videoflip: Missing support for ARGB64 video2023-06-04T10:32:07ZRuslan Khamidullinvideoflip: Missing support for ARGB64 videoGStreamer version: 1.16.2.
Operating system: Windows 8.1 x64 (desktop), macOS 10.14.6.
**Reproduce:** run the following command (substitute the real video file path):
`gst-launch-1.0 uridecodebin uri="file:///path/to/movie" ! videocon...GStreamer version: 1.16.2.
Operating system: Windows 8.1 x64 (desktop), macOS 10.14.6.
**Reproduce:** run the following command (substitute the real video file path):
`gst-launch-1.0 uridecodebin uri="file:///path/to/movie" ! videoconvert ! video/x-raw, format=ARGB64 ! videoflip video-direction=vert ! videoconvert ! pngenc ! multifilesink max-files=1 location=gst_dec_%05d.png`
**Expected:** a flipped frame from the video as a PNG file.
**Actual:** no PNG file, a stderr message instead: `WARNING: erroneous pipeline: could not link videoconvert0 to videoflip0, videoflip0 can't handle caps video/x-raw, format=(string)ARGB64`.
**Note:** if we replace `ARGB64` with `RGBA`, the pipeline works as expected.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2631GstRTSPServer::create_client is not introspectable2023-06-03T19:10:03ZintractabilisGstRTSPServer::create_client is not introspectableThe only way to use a subclassed `GstRTSPClient` is to subclass `GstRTSPServer` and redefine `create_client`. However, `GstRTSPServer::create_client` virtual method is marked with `introspectable="0"` in the generated .gir file and is ig...The only way to use a subclassed `GstRTSPClient` is to subclass `GstRTSPServer` and redefine `create_client`. However, `GstRTSPServer::create_client` virtual method is marked with `introspectable="0"` in the generated .gir file and is ignored by gir binding generation tools. My guess would be, it is unclear for `g-ir-scanner` how to transfer the ownership to the returned `GstRTSPClient`.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2630utils: Use new gst_utils_simplify_fraction in GstValueFraction2023-06-02T18:08:09ZNicolas Dufresneutils: Use new gst_utils_simplify_fraction in GstValueFractionThe new fraction simplify function have nice feature, like understanding that 0.33333 means 1/3 and not 10000/33333. Though we retracted from that as it didn't pass the unit test yet and needed further testing and debugging.
cc @m.tretterThe new fraction simplify function have nice feature, like understanding that 0.33333 means 1/3 and not 10000/33333. Though we retracted from that as it didn't pass the unit test yet and needed further testing and debugging.
cc @m.tretterhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2629utils: Avoid dynamic allocation in gst_utils_simplify_fraction2023-06-02T18:08:09ZNicolas Dufresneutils: Avoid dynamic allocation in gst_utils_simplify_fractionThe following discussion from !1304 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1304#note_1938088):
> Couldn't we go with a big enough, stack allocat...The following discussion from !1304 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1304#note_1938088):
> Couldn't we go with a big enough, stack allocated array here and limit `n_terms` to e.g. 32 or so?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2628vp9dec: "Internal GStreamer error: code not implemented" when post-processing...2023-06-02T16:50:59ZBugzilla Migration Uservp9dec: "Internal GStreamer error: code not implemented" when post-processing=true## Submitted by Florian Nierhaus
**[Link to original bug (#781559)](https://bugzilla.gnome.org/show_bug.cgi?id=781559)**
## Description
Hi,
I want to enable the post-processing in vp9dec .
When I enable it then I get:
...## Submitted by Florian Nierhaus
**[Link to original bug (#781559)](https://bugzilla.gnome.org/show_bug.cgi?id=781559)**
## Description
Hi,
I want to enable the post-processing in vp9dec .
When I enable it then I get:
ERROR default video-frame.c:161:gst_video_frame_map_id: failed to map video frame plane 0
WARN videofilter gstvideofilter.c:292:gst_video_filter_transform:`<videoconvert1>` warning: invalid video buffer received
ERROR:root:(GLib.Error('Internal GStreamer error: code not implemented. Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer.', 'gst-core-error-quark', 3), 'gstvideofilter.c(292): gst_video_filter_transform (): /GstPipeline:main-pipeline/GstVide
oConvert:videoconvert1:\ninvalid video buffer received')
(GLib.Error('Internal GStreamer error: code not implemented. Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer.', 'gst-core-error-quark', 3), 'gstvideofilter.c(292): gst_video_filter_transform (): /GstPipeli
ne:main-pipeline/GstVideoConvert:videoconvert1:\ninvalid video buffer received')
my pipeline works fine with post-processing disabled in vp9dec
I am using current master (v1.6.1-467-g15afee1) of libvpx and compiled it with:
--enable-vp9-postproc --enable-error-concealment --enable-postproc --enable-shared --enable-pic
Thank you and best regards,
Florianhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2627qtmux, qtdemux, mp4: Is missing GstAudioClippingMeta support for Opus2023-06-02T15:16:15ZNicolas Dufresneqtmux, qtdemux, mp4: Is missing GstAudioClippingMeta support for OpusOpus codec introduce some delay which needs to be transmitted using the GstAudioClippingMeta. This is a follow up of issue gst-plugins-good#150Opus codec introduce some delay which needs to be transmitted using the GstAudioClippingMeta. This is a follow up of issue gst-plugins-good#150https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2626v4l2: Implement automatic dmabuf importation2023-06-01T16:26:05ZBugzilla Migration Userv4l2: Implement automatic dmabuf importation## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#583890)](https://bugzilla.gnome.org/show_bug.cgi?id=583890)**
## Description
v4l2src uses own mmapped buffer pool, but should ideall request buffers from xvideo for ze...## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#583890)](https://bugzilla.gnome.org/show_bug.cgi?id=583890)**
## Description
v4l2src uses own mmapped buffer pool, but should ideall request buffers from xvideo for zerocopy. initial patch follows.
### Blocking
* [Bug 796986](https://bugzilla.gnome.org/show_bug.cgi?id=796986)https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/371NDI receiver having 10-20seconds delay in receiving first TCP packet from NDI...2023-06-01T14:27:21Zjacob sunilNDI receiver having 10-20seconds delay in receiving first TCP packet from NDI sourceI am working on NDI project to stream NDI content from Camera / VLC player / OBS studio onto my arm based target device.
While receiving data frames, I am seeing that there is significant delay while receiving the first data frame.
The ...I am working on NDI project to stream NDI content from Camera / VLC player / OBS studio onto my arm based target device.
While receiving data frames, I am seeing that there is significant delay while receiving the first data frame.
The target device that is used as receiver is arm based and is ported with libndi 5.5.3 and gst-plugins-rs/net/ndi
When I checked the same in ubuntu, the receiver quickly receives the data frames without any delay.
Observation : I also noticed that NDI frames are received through UDP in ubuntu case.
Whereas the target I am using is using TCP to receive data frames.
So I felt the delay could be due to TCP connection which might involve many handshakes.
But still the delay is found to be too much which is about 10 - 20 seconds.
So I would like to know if there is any configuration change that can be made in NDI receiver to change from TCP -> UDP.
Also will there be any other reason for this delay ?
Need Help.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2625matroskademux : can no longer seek right after the no-more-pads signal2023-06-05T07:10:47ZJacob Foytikmatroskademux : can no longer seek right after the no-more-pads signalWe have a custom gstreamer plugin that uses matroskademux internally and requires the demux element to seek as soon as it can. We are currently handling this by performing the seek immediately after we receive the 'no-more-pads' signal f...We have a custom gstreamer plugin that uses matroskademux internally and requires the demux element to seek as soon as it can. We are currently handling this by performing the seek immediately after we receive the 'no-more-pads' signal from matroskademux. It appears this behavior is no longer supported (in v1.14.4) since changes related to [this enhancement.](https://bugzilla.gnome.org/show_bug.cgi?id=793333).
It was my understanding that if the element was in the PAUSED state and all of its pads were created, then it was safe to seek on the element. If this is not the case, what is the best method for finding the earliest time to seek on an element?https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/370webrtcsink: issue with EOS events2023-06-20T21:47:45ZAlbert Muriennewebrtcsink: issue with EOS eventsHello,
I'm encountering issues, which I guess may be related to EOS bus event managment.
For example if I run the following pipeline:
`gst-launch-1.0 webrtcsink name=ws videotestsrc ! ws. multifilesrc location=music.wav loop=true ! wa...Hello,
I'm encountering issues, which I guess may be related to EOS bus event managment.
For example if I run the following pipeline:
`gst-launch-1.0 webrtcsink name=ws videotestsrc ! ws. multifilesrc location=music.wav loop=true ! wavparse ! audioconvert ! audioresample ! ws.`
I get the following errors when the `multifilesrc` seeks an end:
`0:00:43.090680871 5117 0x7f2480129920 ERROR rtpgccbwe net/rtp/src/gcc/imp.rs:1104:gstrsrtp::gcc::imp::BandwidthEstimator::start_task::{{closure}}:<rtpgccbwe0> pause task, reason: Eos`
`0:00:43.103863259 5117 0x7f248014fd80 ERROR gstrtpfunnel gstrtpfunnel.c:202:gst_rtp_funnel_forward_segment:<rtpfunnel0> Could not push segment`
I also tested a "coded" pipeline version, using `filesrc`, without the loop option, and trying to handle EOS bus event to rewind file back at the beginning, but the crash happens before the event callback gets called.
Any clue on how to solve this?
Thanks for your help,
Alberthttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2622GstMemory needs warnings in documentation or rework2023-06-12T13:05:45ZCélestin Marotmarotcelestin@gmail.comGstMemory needs warnings in documentation or rework**A *GstMemory* object created with `gst_memory_new_wrapped(0, ...)` can easily induce data-races.**
As you know, it is a data-race to `memcpy` a memory block that is being written to. So one would think there is a mechanism to avoid wr...**A *GstMemory* object created with `gst_memory_new_wrapped(0, ...)` can easily induce data-races.**
As you know, it is a data-race to `memcpy` a memory block that is being written to. So one would think there is a mechanism to avoid writable memory from being copied without locking that memory or without having a reference count equal to 1. However, the longer I dig in the code, the more I realize that GstMemory is only safe when it is directly wrapped in a buffer and then accessed only through *GstBuffer*'s API.
Let me detail this: `gst_memory_new_wrapped()` will simply call `_sysmem_new()` which calls `_sysmem_init()` which in turns calls `gst_memory_init()` with `_sysmem_allocator` as allocator. `_sysmem_allocator` is a *GstAllocator* of type *GstAllocatorSysmem*, which uses `_sysmem_copy()` as copy function. That function basically does an allocation followed by a `memcpy()` without any thread safety mechanism.
Notice that `_fallback_mem_copy()` maps the memory with read access before copying but that function is not used with the *GstAllocatorSysmem*. Hence the behavior is not uniform among allocators.
Therefore, when one calls `gst_memory_copy()` on memory created with *GstAllocatorSysmem*, it will simply do a `memcpy()` without any protection against possible data-races. No, the user is not supposed to lock the memory before doing a copy: it is not specified anywhere, and even functions like `gst_buffer_append_memory()` will simply call `gst_memory_copy()` if the memory is locked (potentially with write access) by another buffer (see ´_memory_get_exclusive_reference()´).
In my humble opinion, in addition to being unnecessarily complicated (see https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/302), the behavior of *GstMemory* is broken in the sense that it does not offer the guarantee one would expect when reading its API. If copying memory requires mapping/locking it with read access, it must be clearly specified and done in GStreamer internal code like ´_memory_get_exclusive_reference()´ and removed from allocators *copy* functions like `_fallback_mem_copy()`. The mapping/locking can also be done in the `gst_memory_copy()` function itself or in the allocator's *copy* function. Consistency is probably the key here.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/368webrtcsink: race condition between on_remote_description_set & handle_ice2023-05-30T17:28:56ZFrançois Laignelwebrtcsink: race condition between on_remote_description_set & handle_iceIn [`on_remote_description_set`](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/blob/main/net/webrtc/src/webrtcsink/imp.rs#L2545), the session is removed from the sessions list
and the `state` lock is temporarily released befo...In [`on_remote_description_set`](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/blob/main/net/webrtc/src/webrtcsink/imp.rs#L2545), the session is removed from the sessions list
and the `state` lock is temporarily released before calling `connect_input_stream` [to avoid a deadlock](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/commit/f82a731b3a09f2752c0475ff6e51757b8551868a). A concurrent [`handle_ice`](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/blob/main/net/webrtc/src/webrtcsink/imp.rs#L2636) for the same session
can lock the `state` and not find the removed session in the list, causing the
candidate to be ignored.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2620glstereosplit: unable to split line by line image2023-05-30T11:46:30ZWojciech Kapsaglstereosplit: unable to split line by line imageHi,
I have a 3d line by line video and I want to split it into left and right eye. Unfortunately without success. The RAW video is large, so I put the image in the example:
`gst-launch-1.0 filesrc blocksize=10000000 location=img.tga ! ...Hi,
I have a 3d line by line video and I want to split it into left and right eye. Unfortunately without success. The RAW video is large, so I put the image in the example:
`gst-launch-1.0 filesrc blocksize=10000000 location=img.tga ! image/x-tga,width=1920,height=1080,framerate=1/1,multiview-mode=row-interleaved ! avdec_targa ! imagefreeze ! videoconvert ! glupload ! glstereosplit name=s s.left ! queue ! glimagesink s.right ! queue ! glimagesin`
[img.tga](/uploads/ec70526f5efa4ec00916f2a56cf407c4/img.tga)
It looks like a bug.
Another example of a pipeline that doesn't work:
`gst-launch-1.0 videotestsrc pattern=ball name=left videotestsrc name=right glstereomix name=mix left. ! video/x-raw,width=640,height=480 ! glupload ! mix. right. ! video/x-raw,width=640,height=480 ! glupload ! mix. mix. ! "video/x-raw(memory:GLMemory),multiview-mode=row-interleaved" ! glstereosplit name=s s.left ! queue ! glimagesink s.right ! queue ! glimagesink`
If you change the row-interleaved to eg. top-bottom it will work.
My gstreamer is 1.22.3.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2619x264enc: High resolution with default settings (cbr and 2Mb/s) produces broke...2023-05-30T10:23:11ZBugzilla Migration Userx264enc: High resolution with default settings (cbr and 2Mb/s) produces broken stream## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#797161)](https://bugzilla.gnome.org/show_bug.cgi?id=797161)**
## Description
See below
gst-launch-1.0 videotestsrc ! capsfilter caps=video/x-raw,width=1800,heig...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#797161)](https://bugzilla.gnome.org/show_bug.cgi?id=797161)**
## Description
See below
gst-launch-1.0 videotestsrc ! capsfilter caps=video/x-raw,width=1800,height=1600 ! x264enc ! rtph264pay ! rtph264depay ! queue ! decodebin ! videoconvert ! autovideosink
Lower resolution or not going through RTP makes it work fine.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2617[PLUGIN-MOVE] Move dvdlpcmdec to -good2023-05-30T10:14:47ZBugzilla Migration User[PLUGIN-MOVE] Move dvdlpcmdec to -good## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#774577)](https://bugzilla.gnome.org/show_bug.cgi?id=774577)**
## Description
There's no point in having it in -ugly.## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#774577)](https://bugzilla.gnome.org/show_bug.cgi?id=774577)**
## Description
There's no point in having it in -ugly.