gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2024-02-27T18:28:27Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1489nvav1enc:Add support for av1 hardware encoding2024-02-27T18:28:27Z谢美龙nvav1enc:Add support for av1 hardware encodingThe 8th generation nvenc has added support for av1 encoding. [Support Matrix](https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new).
And rtpav1pay just released in gstreamer 1.21.1. The nvav1enc + rtpav1pay + web...The 8th generation nvenc has added support for av1 encoding. [Support Matrix](https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new).
And rtpav1pay just released in gstreamer 1.21.1. The nvav1enc + rtpav1pay + webrtc will be a nice combination.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/1571New WebTransport sink/bin interface2023-11-17T12:33:44ZSeungmin KimNew WebTransport sink/bin interfacehttps://web.dev/i18n/en/webtransport/
https://www.w3.org/TR/webtransport/
https://web.dev/webcodecs/
https://www.w3.org/TR/webaudio/
https://web.dev/media-mse-basics/
> Currently, Web application developers have two APIs for bidirection...https://web.dev/i18n/en/webtransport/
https://www.w3.org/TR/webtransport/
https://web.dev/webcodecs/
https://www.w3.org/TR/webaudio/
https://web.dev/media-mse-basics/
> Currently, Web application developers have two APIs for bidirectional communications with a remote server: WebSockets and RTCDataChannel. WebSockets are TCP-based, thus having all of the drawbacks of TCP that make it a poor fit for latency sensitive applications (head of line blocking, lack of support for unreliable data transport). RTCDataChannel is based on SCTP, which does not have these drawbacks; however, it is designed to be used in a peer-to-peer context, which caused its use in client-server settings to be fairly low. WebTransport provides a client-server API that supports bidirectional transfer of both unreliable and reliable data, using UDP-like datagrams and cancellable streams.
https://chromestatus.com/feature/4854144902889472
WebTransport is a promising new web protocol based on HTTP3. This reduces the complexity of WebRTC in arbitrary client-server streams and is using QUIC Transport to achieve UDP connections within web browsers. Chromium-based browsers >= 105 are currently the representative supporting browsers.
This combined with WebCodecs and WebAudio will make it a feasible alternative for both WebRTC and WebSockets, filling a void between the two main TCP/UDP transport methods for the web browser.
Implementation on GStreamer should also be much easier than that of webrtcbin, as the complexity of ICE, DTLS, and SCTP is removed and only the knowledge of HTTP3 would be required.
If a developer should have the time and resources, it would be a very useful plugin and with high feasibility when implemented in Rust, although also possible with C.
WebTransport would also solve the WASM UDP networking problem within web browsers.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2760webrtcbin: Probably needs a way to close the connection to the peer2023-07-04T14:46:35ZSebastian Drögewebrtcbin: Probably needs a way to close the connection to the peerBasically mapping to the [`close()`](https://www.w3.org/TR/webrtc/#dom-rtcpeerconnection-close) function of the peer connection. Among other things this would cause orderly shutdown/closing of any SCTP datachannel connections and of the ...Basically mapping to the [`close()`](https://www.w3.org/TR/webrtc/#dom-rtcpeerconnection-close) function of the peer connection. Among other things this would cause orderly shutdown/closing of any SCTP datachannel connections and of the DTLS connection (that can already be triggered with an EOS event).
CC @ystreethttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3212debug: Add API to push/pop current object to TLS for logging purposes2024-01-09T06:54:20ZSebastian Drögedebug: Add API to push/pop current object to TLS for logging purposesCurrently we either have to pass through objects to code that does not concern itself with the object just for logging purposes, or get logs that are unconnected to the object that initially initiated them.
It would be great if we had s...Currently we either have to pass through objects to code that does not concern itself with the object just for logging purposes, or get logs that are unconnected to the object that initially initiated them.
It would be great if we had some API that allows pushing/popping the current object to a TLS variable, and then `GST_DEBUG()` etc make use of that if set. This would, for example, allow the code in `GstVideoConverter` to print the `videoconvert` object as part of the debug logs instead of just printing generic logs.
Main question here would be if this has considerable performance impact if logging is disabled (you'd still need to push/pop the object because you don't know what actual debug category and level is used at a later time).https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2880x264: Missing ROI driven QP adjustment2023-08-03T19:31:21ZDhaval Sutariax264: Missing ROI driven QP adjustment### Describe your issue
For ROI based QP value, we are using "gst_buffer_add_video_region_of_interest_meta" and "gst_video_region_of_interest_meta_add_param" APIs.
But after calling this APIs, before x264enc we are not getting expected b...### Describe your issue
For ROI based QP value, we are using "gst_buffer_add_video_region_of_interest_meta" and "gst_video_region_of_interest_meta_add_param" APIs.
But after calling this APIs, before x264enc we are not getting expected behaviour.
#### Expected Behavior
Region selected should looks different than other region. Like if qp is high that ROI should look blur.
#### Observed Behavior
No different between ROI and non ROI area.
#### Setup
Linux 18.04https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2802mpegtsmux: mux private data streams2023-10-01T20:31:56ZBugzilla Migration Usermpegtsmux: mux private data streams## Submitted by Martijn Grendelman
**[Link to original bug (#673582)](https://bugzilla.gnome.org/show_bug.cgi?id=673582)**
## Description
Mpegtsdemux is capable of demuxing private data streams, like subtitles and teletext, but mpeg...## Submitted by Martijn Grendelman
**[Link to original bug (#673582)](https://bugzilla.gnome.org/show_bug.cgi?id=673582)**
## Description
Mpegtsdemux is capable of demuxing private data streams, like subtitles and teletext, but mpegtsmux is not capable of muxing them. So, if you want to transcode a TS, but keep all non-audio/video streams as-is, this is not possible.
This is a request to add private data stream support to mpegtsmux.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2742qtdemux: Support chapters and provide a GstToc2023-07-01T19:20:38ZBugzilla Migration Userqtdemux: Support chapters and provide a GstToc## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#540887)](https://bugzilla.gnome.org/show_bug.cgi?id=540887)**
## Description
There's currently no chapters support in qtdemux. This could be used to browse in files ...## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#540887)](https://bugzilla.gnome.org/show_bug.cgi?id=540887)**
## Description
There's currently no chapters support in qtdemux. This could be used to browse in files such as:
http://downloads.oreilly.com/make/MAKE_2005-07-18.m4b
### Depends on
* [Bug 540890](https://bugzilla.gnome.org/show_bug.cgi?id=540890)
### Blocking
* [Bug 163546](https://bugzilla.gnome.org/show_bug.cgi?id=163546)
* [Bug 328298](https://bugzilla.gnome.org/show_bug.cgi?id=328298)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2655uridecodebin: Add properties and documentation for better control over buffering2023-08-03T12:52:05ZBugzilla Migration Useruridecodebin: Add properties and documentation for better control over buffering## Submitted by Carlos Rafael Giani
**[Link to original bug (#762125)](https://bugzilla.gnome.org/show_bug.cgi?id=762125)**
## Description
Created attachment 321347
uridecodebin patch for enhanced buffering control
Currently,...## Submitted by Carlos Rafael Giani
**[Link to original bug (#762125)](https://bugzilla.gnome.org/show_bug.cgi?id=762125)**
## Description
Created attachment 321347
uridecodebin patch for enhanced buffering control
Currently, there are only two properties for controlling the buffering: buffer-size and buffer-duration. Properties for the low/high percentage thresholds are missing. Also, the default value for buffer-size and buffer-duration is -1, which means "automatic/default". It is not obvious what this exactly means, and relies on hardcoded internal values.
Furthermore, buffer-duration conflates two distinct concepts: its value is used both for bitrate-based and for input data rate based buffer size estimation. As a result, a buffer-duration value of for example 5 seconds can either mean a buffer size of bitrate*5 seconds , or in case of slow connections, in-data-rate*5 seconds, whichever is lower. In many cases, it is desirable to use only one of these two estimations.
The exact way how buffering behaves, how the properties work, and how it should be used is not documented.
This is the first version of a patch that deprecates buffer-size and buffer-duration in favor of three new properties: max-buffer-size, max-buffering-duration, and buffer-estimate-duration.
The new properties work as follows:
* max-buffer-size: The upper limit for the buffer size, in bytes; this value is passed to the internal queue/decodebin as the "max-size-bytes" property; default value is 10 MB
* max-buffering-duration: The in-data-rate*duration estimate mentioned above; this value is passed to the internal queue/decodebin as the "max-size-time" property, but it is *not* used for bitrate based estimations; default value is 0 (= disables data rate based estimates)
* buffer-estimate-duration: The bitrate*duration estimate mentioned above; this value is not passed to the internal queue, and used only if a bitrate tag is encountered; default value is 6.5 seconds
Out of these three, the lowest size (in bytes) is picked.
The patch also makes it possible to set these property during playback; the buffer size will be readjusted on the fly.
Properties for low/high percentage are also introduced. Default values are: low 5%, high 5%. Together with the default values for the other three properties, this means buffering messages will reach 100% once 1.5 seconds are buffered. During playback, if the source can deliver data faster than realtime, additional 5 second can be buffered on the fly. This makes streaming playback more robust against network bandwidth drops without having to let the user wait too long for buffering to finish.
gtkdoc documentation for how to use these new properties and how configuring buffer size works is also added.
Also, a new "will-post-buffering" signal is added. This is emitted whenever uridecodebin sets the "use-buffering" property of an internal queue to TRUE. This is useful for applications to let them know that they should *not* switch to PLAYING just yet, because buffering messages *will* be posted soon. This prevents the possibility that the PLAYING state is reached, playback goes on briefly, and then the application receives the first BUFFERING message, and pauses playback again.
In subsequent patches, playbin could also get these new properties (they'd be forwarded to uridecodebin just like buffer-size and buffer-duration are now), and the new signal. Another planned addition is a "current-buffer-level" property; however, this first requires a patch for multiqueue, since it doesn't have any property like that (queue2 does have "current-level-bytes"). Also, several parsers such as flacparse, wavparse, aiffparse have been found to not push bitrate tags downstream, and therefore also require patching to further improve buffering behavior.
**Patch 321347**, "uridecodebin patch for enhanced buffering control":
[0001-uridecodebin-Add-properties-and-signals-for-better-c.patch](/uploads/dab7fd226cd0303c015cf427dd222271/0001-uridecodebin-Add-properties-and-signals-for-better-c.patch)Edward HerveyEdward Herveyhttps://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/2605playbin3: more flexible URI property2023-07-03T14:42:59ZGuillaume Desmottesplaybin3: more flexible URI property`playbin3` currently implements the same URI properties as `playbin`:
- `uri`: URI of the media to play
- `suburi`: Optional URI of a subtitle
- `current-uri`: The currently playing URI
- `current-suburi`: The currently playing URI of a ...`playbin3` currently implements the same URI properties as `playbin`:
- `uri`: URI of the media to play
- `suburi`: Optional URI of a subtitle
- `current-uri`: The currently playing URI
- `current-suburi`: The currently playing URI of a subtitle
`suburi` can actually be used to play audio or video, at least with `playbin`, see gst-plugins-base#690, no the naming isn't great.
Also, one may want to play 3 streams together (audio, video, text) which is currently not possible. Or even be able to quickly switch between different streams of the same type.
I was thinking we could implement something more flexible and generic using the new stream APIs:
- add a new `uris` property taking an array of URIs
- expose them all using `GstStreamCollection`
- activate by default the first audio/video/text streams
- let user activate specific streams using `GST_EVENT_SELECT_STREAMS`
- add a new `current-uris` property containing the subset of `uris` currently activated.
@bilboed : any thoughts?https://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/2394Add vvdec/vvenc-based VVC/h266 decoder/encoder elements2023-06-26T23:12:42ZSebastian DrögeAdd vvdec/vvenc-based VVC/h266 decoder/encoder elementsSee https://github.com/fraunhoferhhiSee https://github.com/fraunhoferhhihttps://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/1473mfvideosrc: Expose camera control options2024-01-09T01:01:11ZSeungha Yangseungha@centricular.commfvideosrc: Expose camera control optionsimage quality related properties (e.g., brightness) and camera properties (zoom, focus, etc) are controllable via `IAMVideoProcAmp` and `IAMCameraControl` interfacesimage quality related properties (e.g., brightness) and camera properties (zoom, focus, etc) are controllable via `IAMVideoProcAmp` and `IAMCameraControl` interfaceshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/749dashsink: add webm support2021-09-29T09:32:14ZStéphane Cerveauscerveau@igalia.comdashsink: add webm supportThe dash sink should be able to generate a MPD with webm/vp8 content.
Here is documentation on how to generate this MPD/content with ffmpeg.
http://wiki.webmproject.org/adaptive-streaming/instructions-to-do-webm-live-streaming-via-dashThe dash sink should be able to generate a MPD with webm/vp8 content.
Here is documentation on how to generate this MPD/content with ffmpeg.
http://wiki.webmproject.org/adaptive-streaming/instructions-to-do-webm-live-streaming-via-dashStéphane Cerveauscerveau@igalia.comStéphane Cerveauscerveau@igalia.comhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/580GstUri: Port to GUri if using new enough GLib2021-09-24T11:08:41ZSebastian DrögeGstUri: Port to GUri if using new enough GLibSee https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1328
Has a better and more robust URI parser/serializer (which might solve a few bugs we have right now), better error reporting. Main issue might be that it's immutable.See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1328
Has a better and more robust URI parser/serializer (which might solve a few bugs we have right now), better error reporting. Main issue might be that it's immutable.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/495device: Add a unique, persistent identifier2021-09-24T11:08:56ZSebastian Drögedevice: Add a unique, persistent identifierCurrently there's no way to know across application restarts or even when restarting the device provider which device maps to one that was selected in a previous run. Some unique identifier for this would be useful for applications to al...Currently there's no way to know across application restarts or even when restarting the device provider which device maps to one that was selected in a previous run. Some unique identifier for this would be useful for applications to allow users to select a device and then reliably get that very same device again at a future run.
While this can already be done per provider via the extra properties on the device this doesn't give us a common API for it yet. So I'd propose an additional property on `GstDevice` for this very purpose.
The main question then would be what we would do as a backward compatibility fallback.
CC @ocretehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/6Better flow / negotiation error reporting2024-01-10T10:54:54ZBugzilla Migration UserBetter flow / negotiation error reporting## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#350545)](https://bugzilla.gnome.org/show_bug.cgi?id=350545)**
## Description
Durinf development one often gets:
basesrc( 1083) gstbasesrc.c(1698):gst_base_src_sta...## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#350545)](https://bugzilla.gnome.org/show_bug.cgi?id=350545)**
## Description
Durinf development one often gets:
basesrc( 1083) gstbasesrc.c(1698):gst_base_src_start:`<v4l2src0>` error: Could not negotiate format
WARN (0x19000 - 0:00:07.850402000) basesrc( 1083) gstbasesrc.c(1698):gst_base_src_start:`<v4l2src0>` error: Check your filtered caps, if any
This definitely need fixing. There is no point that deverlopers spend years reading GST_DEBUG="GST_CAPS:4" output to figure the problem. If format cannot be negotiated then a reason *must* be given.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3361wavenc: Go EOS and report an error if larger than 2GB2024-03-07T13:02:33ZBugzilla Migration Userwavenc: Go EOS and report an error if larger than 2GB## Submitted by j^
**[Link to original bug (#654243)](https://bugzilla.gnome.org/show_bug.cgi?id=654243)**
## Description
encoding files longer than 1h40m with this pipeline:
gst-launch-0.10 pulsesrc ! queue ! audio/x-raw-int,r...## Submitted by j^
**[Link to original bug (#654243)](https://bugzilla.gnome.org/show_bug.cgi?id=654243)**
## Description
encoding files longer than 1h40m with this pipeline:
gst-launch-0.10 pulsesrc ! queue ! audio/x-raw-int,rate=44100,channels=2 ! wavenc ! filesink location=/tmp/test.wav
creates a corrupt wav files. its opened in totem/audacity but only the first 2GB of data are played.
Ot is possible to open the file in audacity as raw samples, skipping the header(first 20bytes). So data gets written to disk but the wav headers are wrong.