gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2023-06-01T16:26:05Zhttps://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/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.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2602mxfdemux: Parse/store colorimetry, chroma-site and interlaced-mode/field-order2023-05-25T10:05:10ZBugzilla Migration Usermxfdemux: Parse/store colorimetry, chroma-site and interlaced-mode/field-order## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#772182)](https://bugzilla.gnome.org/show_bug.cgi?id=772182)**
## Description
See summary and [bug 771376](https://bugzilla.gnome.org/show_bug.cgi?id=771376)## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#772182)](https://bugzilla.gnome.org/show_bug.cgi?id=772182)**
## Description
See summary and [bug 771376](https://bugzilla.gnome.org/show_bug.cgi?id=771376)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2581[2.0] encoder elements should all use bits/sec as the unit for bitrate proper...2023-05-18T16:10:52ZBugzilla Migration User[2.0] encoder elements should all use bits/sec as the unit for bitrate properties## Submitted by Thomas Vander Stichele `@thomasvs`
**[Link to original bug (#337409)](https://bugzilla.gnome.org/show_bug.cgi?id=337409)**
## Description
theoraenc for example uses kbit/sec
it's an ABI change so we have to do i...## Submitted by Thomas Vander Stichele `@thomasvs`
**[Link to original bug (#337409)](https://bugzilla.gnome.org/show_bug.cgi?id=337409)**
## Description
theoraenc for example uses kbit/sec
it's an ABI change so we have to do it in 0.112.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2579avdec: better multi-threaded decoding performance for live pipelines where do...2023-05-18T11:34:29ZBugzilla Migration Useravdec: better multi-threaded decoding performance for live pipelines where downstream does not sync to clock## Submitted by Tim Müller `@tpm`
**[Link to original bug (#696501)](https://bugzilla.gnome.org/show_bug.cgi?id=696501)**
## Description
Currently we always use FF_THREAD_SLICE mode for multithreaded H.264 decoding.
This mode r...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#696501)](https://bugzilla.gnome.org/show_bug.cgi?id=696501)**
## Description
Currently we always use FF_THREAD_SLICE mode for multithreaded H.264 decoding.
This mode requires encoder support, so multiple threads will only be used if the H.264 video is encoded in a suitable way (i.e. with multiple slices per frame). This is not necessarily the case, and where this is not the case decoding will be done in a single thread only, hampering performance.
We should use FF_THREAD_SLICE only for live pipelines where latency is important, and use FF_THREAD_FRAME for decoding scenarios where latency does not matter, to make sure we actually use multiple threads for decoding if possible.
### See also
* https://bugs.freedesktop.org/show_bug.cgi?id=56206https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2569WebRTC: Support of Receiver Reference Time for non-sending (browser) peers2023-05-17T16:44:30ZOliver WanglerWebRTC: Support of Receiver Reference Time for non-sending (browser) peersHey there!
Thanks for your work implementing WebRTC support for the gstreamer stack!
I'm a gst apprentice (is that a thing?), so it's very probable that I missed something obvious. Now to my use case:
Native process running a gstreame...Hey there!
Thanks for your work implementing WebRTC support for the gstreamer stack!
I'm a gst apprentice (is that a thing?), so it's very probable that I missed something obvious. Now to my use case:
Native process running a gstreamer pipeline, basically: `appsrc ! webrtcsink`.
I'm using the `net/webrtc/protocol` to signal the connection with a browser (Chrome) peer/"client".
I'm looking to compute/extract the sender's wall clock from an individual frame in the browser using the `HTMLVideoElement.requestVideoFrameCallback()` [API](https://wicg.github.io/video-rvfc/#dom-videoframecallbackmetadata-capturetime); unfortunately the (optional) `captureTime` field is undefined.
According to [this](https://github.com/webrtc/samples/pull/1408#issuecomment-760902189), one can enable [Receiver Reference Time Reports](https://datatracker.ietf.org/doc/html/rfc3611#section-4.4) by munging the (answer's) SDP (include attribute `a=rtcp-fb:[payload] rrtr` for each payload), and thus populate the `captureTime` field.
Unfortunately this is not working for me. I'm overwhelmed by the huge machineries involved (gst & chrome), so before debugging this further: Should this even work?
------
Background: I'm looking to synchronize individual video frames with metadata sent over a datachannel. The sender's wall-clock timestamp should serve as the common key to match the pair in the browser. So far I have been manually calculating the sender's wall-clock from gst Sender Reports (also sent via the same data channel periodically), but I'm looking for a better way ..https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/19Macro to check check mutability in set_property functions2023-05-15T18:28:47ZBugzilla Migration UserMacro to check check mutability in set_property functions## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#644776)](https://bugzilla.gnome.org/show_bug.cgi?id=644776)**
## Description
Now that we have GST_PARAM_MUTABLE_*, we should add a way to enforce them.
I suggest...## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#644776)](https://bugzilla.gnome.org/show_bug.cgi?id=644776)**
## Description
Now that we have GST_PARAM_MUTABLE_*, we should add a way to enforce them.
I suggest having a macro like the following and putting it as the first line of the set_property() function in the various elements after adding the mutability flags.
#define GST_PARAM_CHECK_MUTABILITY(element, pspec) G_STMT_START { \
GstState state; \
\
g_return_if_fail ((element) != NULL && GST_IS_ELEMENT (element)); \
GST_OBJECT_LOCK (element); \
state = GST_STATE (element); \
GST_OBJECT_UNLOCK (element); \
g_return_if_fail (state == GST_STATE_PLAYING || \
(pspec)->flags & GST_PARAM_MUTABLE_PLAYING); \
g_return_if_fail (state >= GST_STATE_PAUSED || \
(pspec)->flags & GST_PARAM_MUTABLE_PAUSED); \
g_return_if_fail (state >= GST_STATE_READY || \
(pspec)->flags & GST_PARAM_MUTABLE_READY); \
} G_STMT_END
We may want to have a version that doesn't release the object lock if the paramspec is mutable above NULL, since I guess for many cases, we'd want to make the change atomic, but that means being a little more clever (and maybe we want to use GST_ERROR_OBJECT() instead of g_warning .. maybe g_critical?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/18tee: needs to aggregate QoS THROTTLE events from all source branches2023-05-15T18:28:47ZBugzilla Migration Usertee: needs to aggregate QoS THROTTLE events from all source branches## Submitted by Yongnian
**[Link to original bug (#638891)](https://bugzilla.gnome.org/show_bug.cgi?id=638891)**
## Description
There might be many cases that some window is invisible
(for example other window is in full screen)...## Submitted by Yongnian
**[Link to original bug (#638891)](https://bugzilla.gnome.org/show_bug.cgi?id=638891)**
## Description
There might be many cases that some window is invisible
(for example other window is in full screen), its related sink elements are still busy in rendering and upstream elements are busy in processing and decoding. Here a new event type "QOS_OBSCURED" is introduced.
The UI toolkit (Gtk+, Qt) already keeps track of windows status information: visible or invisible etc. So it would be straightforward to extend the GstVideoSink class to have a property that encourages degraded rendering. When such property is set, the "QOS_OBSCURED" event is pushed to upstream elements for handling: degraded quality for less resources.
And, for bonus points, as there is a trend in the industry toward stream switching for video over the internet, such event could be used to select appropriate media info in future.
After discussion with David Schleef (ds@entropywave.com) and Halley Zhao (halley.zhao@intel.com), the patches (based on version 0.10.28) for such mechanism are ready for video rendering degradation when it is invisible. They include below changes:
1. gstquark.h/gstquark.c: new quark string
2. gstevent.h/gstevent.c: new QoS event
3. gstvideosink.c: generate new QoS event when it encourages degraded rendering
3. gsttee.c: degrade handling rate when it receives degraded rendering requesthttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/17RFC: operation hints for GstElement2023-05-15T18:28:47ZBugzilla Migration UserRFC: operation hints for GstElement## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#634687)](https://bugzilla.gnome.org/show_bug.cgi?id=634687)**
## Description
[Bug 564749](https://bugzilla.gnome.org/show_bug.cgi?id=564749) mostly blocks on the GstTa...## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#634687)](https://bugzilla.gnome.org/show_bug.cgi?id=634687)**
## Description
[Bug 564749](https://bugzilla.gnome.org/show_bug.cgi?id=564749) mostly blocks on the GstTagReaderIface. An alternative would be to have a set of hint-flags on GstElement. Those flags can be set on the pipeline, individual bins and even elements. Bins could propagate the hints to new children and hint-changes to existing children.
The purpose of the hints is to specify the intended use case a bit more to give elements a chances for optimization. Right now gstreamer elements prepare to support everything.
Some use cases
1) quickly play something from start to end
- no need for metadata
- no seeking/no playback rate changes
- no mucking with the pipeline at all until eos
2) quick metadata reading
- no prerolling
- no seektable building
3) no caps changes (video in fullscreen)
- quicker pad_alloc or even no need to check for caps changes in basetransform
No proposal for a set of hints yet :/
### Blocking
* [Bug 532307](https://bugzilla.gnome.org/show_bug.cgi?id=532307)
* [Bug 564749](https://bugzilla.gnome.org/show_bug.cgi?id=564749)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2458qmlglsink: Feature request: implement QAbstractVideoFilter-like feature in Gs...2023-04-07T09:19:43ZVincas Dargisqmlglsink: Feature request: implement QAbstractVideoFilter-like feature in GstGLVideoItem for convenient way for getting QImages frome the samplesIn Qt Multimedia there's a way to install a filter https://doc.qt.io/qt-5/qabstractvideofilter.html into Qml `VideoOutput` which allows acquiring frames as `QImage`s and then perform some additional processing, like passing that image to...In Qt Multimedia there's a way to install a filter https://doc.qt.io/qt-5/qabstractvideofilter.html into Qml `VideoOutput` which allows acquiring frames as `QImage`s and then perform some additional processing, like passing that image to OpenCV algorithms.
Currently I presume one would have to modify pipeline to use `tee` and `appsink` and get frames via it, or to poll `last-sample` property using timer, after determining what is frame rate of the pipeline..?
Having optional mode there `GstGLVideoItem` would emit `QImage` on every sample or by introducing analogous "filter" runnable that would not block the pipeline, would make it much easier, without need to modify pipeline or do some other "gymnastics".https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/27basetransform: should try to reconfigure on not-negotiated2023-04-03T13:20:14ZBugzilla Migration Userbasetransform: should try to reconfigure on not-negotiated## Submitted by Tim Müller `@tpm`
**[Link to original bug (#681624)](https://bugzilla.gnome.org/show_bug.cgi?id=681624)**
## Description
+++ This bug was initially created as a clone of [Bug 681198](https://bugzilla.gnome.org/show_b...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#681624)](https://bugzilla.gnome.org/show_bug.cgi?id=681624)**
## Description
+++ This bug was initially created as a clone of [Bug 681198](https://bugzilla.gnome.org/show_bug.cgi?id=681198) +++
basetransform (e.g. videoconvert, videoscale) should try to reconfigure itself on not-negotiated if a reconfiguration is pending.
Possibly even retry with the same buffer... (keeping a buffer ref doesn't force unnecessary memory copies downstream any more now, does it?)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/26Add function to pretty-print durations2023-04-03T13:20:14ZBugzilla Migration UserAdd function to pretty-print durations## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#679850)](https://bugzilla.gnome.org/show_bug.cgi?id=679850)**
## Description
Something similar to:
http://git.gnome.org/browse/totem/tree/src/gst/totem-time-helper...## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#679850)](https://bugzilla.gnome.org/show_bug.cgi?id=679850)**
## Description
Something similar to:
http://git.gnome.org/browse/totem/tree/src/gst/totem-time-helpers.c#n33
We would also want to be able to force showing the hour item, if the corresponding item has an hour field.
eg., progress as I've just started watching a film:
00:00:15/1:25:00
And usefully, print time left:
00:00:15 [===============] -1:24:45
API bikeshedding appreciated.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/25[2.0] support negative DTS2023-04-03T13:20:14ZBugzilla Migration User[2.0] support negative DTS## Submitted by Matej `@Knopp`
**[Link to original bug (#679466)](https://bugzilla.gnome.org/show_bug.cgi?id=679466)**
## Description
[I'm not hoping for this to get fixed for 1.0; filing the bug to raise awareness anyway]
x264...## Submitted by Matej `@Knopp`
**[Link to original bug (#679466)](https://bugzilla.gnome.org/show_bug.cgi?id=679466)**
## Description
[I'm not hoping for this to get fixed for 1.0; filing the bug to raise awareness anyway]
x264 generates one or two frames with negative DTS (one with b-frames enabled, two with b-pyramid).
This is necessary for sequence such as
IPBPP (PTS=0,2,1,3,4 DTS=-1,0,1,2,3)
to be decoded properly - B frame in the middle has PTS 1, but needs two frames (I, B) decoded before it can be displayed.
In GStreamer there is currently no way to represent a negative DTS. There are few hacks around this (encoder could compress the DTS - i.e. 0, 0.5, 1, 2, 3) or the DTS can be shifted in the encoder and shifted back in muxer, but these are either ugly or not entirely legal (compression).
If anyone has a nicer/or simpler solution I'm all ears.
Version: 2.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/23Configuration system (for element ranks and other things)2023-04-03T13:20:14ZBugzilla Migration UserConfiguration system (for element ranks and other things)## Submitted by Benjamin Gaignard
**[Link to original bug (#649542)](https://bugzilla.gnome.org/show_bug.cgi?id=649542)**
## Description
Created attachment 187346
draft of implementation
The idea is to offer a way to customiz...## Submitted by Benjamin Gaignard
**[Link to original bug (#649542)](https://bugzilla.gnome.org/show_bug.cgi?id=649542)**
## Description
Created attachment 187346
draft of implementation
The idea is to offer a way to customize element ranking without hacking/patch code.
I need that feature because some decoders (like h264) may request to autoplug a parser between them and the demuxer. Today ins't possible without hack parser code.
This could be done by modify the element rank before write it into cache registry.
Modifications are store in a file (in a humain readable format) and I add a gst tool, named gst-rank, to edit this file.
All comments/review/help is welcome
~~**Patch 187346**~~, "draft of implementation":
[0001-add-element-ranking-customization-feature.patch](/uploads/cbaa05c445e4df2fa5e9cac57da79624/0001-add-element-ranking-customization-feature.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/22Better handling of blacklisted plugins: re-scan occasionally, store reason fo...2023-04-03T13:20:14ZBugzilla Migration UserBetter handling of blacklisted plugins: re-scan occasionally, store reason for blacklisting## Submitted by Tim Müller `@tpm`
**[Link to original bug (#648010)](https://bugzilla.gnome.org/show_bug.cgi?id=648010)**
## Description
+++ This bug was initially created as a clone of [Bug 503675](https://bugzilla.gnome.org/show_b...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#648010)](https://bugzilla.gnome.org/show_bug.cgi?id=648010)**
## Description
+++ This bug was initially created as a clone of [Bug 503675](https://bugzilla.gnome.org/show_bug.cgi?id=503675) +++
`<__tim>` nekohayo, your registry file is full of BLACKLISTED. The problem isn't
registry file writing or parsing, but that plugins get blacklisted for some
reason
`<nekohayo>` When does blacklisting occur?
`<__tim>` nekohayo, when an error occurs when loading the plugin, usually a
missing symbol or library or somesuch
`<nekohayo>` videomixer was indeed on the gst-inspect blacklist
`<__tim>` are you sometimes downgrading versions of core or gst-plugins-base?
`<nekohayo>` no, not that I know of. Downgrading was downright impossible in
ubuntu, and I haven't used downgrade in fedora yet
`<__tim>` GStreamer installed in different prefixes?
`<nekohayo>` currently this machine is using the official gstreamer packages from
fedora + rpmfusion
`<nekohayo>` I'm wondering why those blacklisted plugins are never "re-scanned"
by gstreamer
`<__tim>` that's a fair question I guess. But when would one rescan them? You
don't want to do it every time. So once an hour? once a day? once a week?
`<nekohayo>` what if they were rescanned when apps try to access them? like when
pitivi tries to use videomixer (on top of your approach of rescanning
periodically maybe)
`<__tim>` interesting, maybe one could do something clever there
`<__tim>` ideally we'd store the reason for the blacklisting as well
`<ocrete>` arent they rechecked if the file changes already ?
`<thaytan>` the plugins are rescanned if they change
`<__tim>` but if they don't change ...
`<thaytan>` but if they failed because some underlying lib was broken and then
fixed, that's not detected
`<__tim>` right
`<ocrete>` hmm interesting point
`<thaytan>` storing the reason for the blacklisting is probably hard
`<ocrete>` also check if ld.so.cache has changed ?
`<thaytan>` since it's usually just 'failed to g_module_open() because of an
unresolved symbol'
`<ocrete>` and ignore blacklists if ld.so.cache has changed (and rescan)
`<__tim>` thaytan, it doesn't mention the symbol? I think it does..
`<ds>` if the so fails to load, there isn't much overhead trying to load every
time
`<ocrete>` that said, doesnt help if one use using LD_LIBRARY_PATH
`<thaytan>` ds: except for forking the scanner process to re-check an otherwise
clean registry
`<ds>` oooh, maybe recheck blacklisted plugins whenever the scanner is run, but
not run the scanner just for blacklisted plugins. Although, also mark potential
crasher blacklist plugins
### See also
* http://bugs.debian.org/867574https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2441vah264dec: vah264enc: support VAProfileH264High102023-04-03T05:30:31ZVíctor Manuel Jáquez Lealvah264dec: vah264enc: support VAProfileH264High10https://github.com/intel/libva/pull/664https://github.com/intel/libva/pull/664https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2432ci: Consider using sccache instead of ccache2023-03-30T18:13:55ZGuillaume Desmottesci: Consider using sccache instead of ccacheWondering if it would sense to try using [sccache](https://github.com/mozilla/sccache) instead of `ccache`. We would gain Rust support which could speed things up.Wondering if it would sense to try using [sccache](https://github.com/mozilla/sccache) instead of `ccache`. We would gain Rust support which could speed things up.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/123taglist: update merge logic when one of the input is empty2023-03-17T10:37:28ZBugzilla Migration Usertaglist: update merge logic when one of the input is empty## Submitted by Vineeth
**[Link to original bug (#752362)](https://bugzilla.gnome.org/show_bug.cgi?id=752362)**
## Description
When tag_list_merge is called with either of the input lists empty, right now, a new empty list is being ...## Submitted by Vineeth
**[Link to original bug (#752362)](https://bugzilla.gnome.org/show_bug.cgi?id=752362)**
## Description
When tag_list_merge is called with either of the input lists empty, right now, a new empty list is being created and on top of that the other list is being merged.
But if one of the input is empty, it is supposed to just create a copy of the other as the merged list.
This was added to handle GST_TAG_MERGE_KEEP_ALL and GST_TAG_MERGE_REPLACE_ALL mode during merging.
But these modes should be valid only when both the inputs are not NULL. It doesn't make sense to create a new empty list, just to handle these two modes,
even though NULL is being passed as input.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2092AV1 mpeg-ts muxing & demuxing2023-03-02T14:48:15ZOlivier Crêteolivier.crete@ocrete.caAV1 mpeg-ts muxing & demuxingWe should try to implement the AV1 in MPEG-TS spec in GStreamer:
https://code.videolan.org/videolan/av1-mapping-specs/blob/master/ts-carriage.mdWe should try to implement the AV1 in MPEG-TS spec in GStreamer:
https://code.videolan.org/videolan/av1-mapping-specs/blob/master/ts-carriage.mdEdward HerveyEdward Herveyhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1793ci: Add an integration test for the uninstalled dev env esp for macOS and Win...2023-02-11T18:12:40ZNirbheek Chauhannirbheek.chauhan@gmail.comci: Add an integration test for the uninstalled dev env esp for macOS and WindowsThis should be useful for ensuring that the uninstalled env is working correctly on macOS and Windows, which aren't tested daily by gstreamer developers.
- [ ] Run a simple test pipeline and check the return code
- [ ] Run `gst-inspect-...This should be useful for ensuring that the uninstalled env is working correctly on macOS and Windows, which aren't tested daily by gstreamer developers.
- [ ] Run a simple test pipeline and check the return code
- [ ] Run `gst-inspect-1.0` and compare the plugin list against a static list, and fail if a plugin is gone