GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2023-06-24T11:45:11Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2697matroskademux does not set codec data duration to buffer for h.264 or AVC videos2023-06-24T11:45:11ZGaël Bonithonmatroskademux does not set codec data duration to buffer for h.264 or AVC videosI'm using GStreamer 1.20.1 on Arch Linux
gst-play-1.0 fails to display the video content of this file: ![opus_WITH_COVER](/uploads/766c747af2fb2418cb0175b6f5703c2f/opus_WITH_COVER.webm)
It displays correctly in VLC or MPV for example. ...I'm using GStreamer 1.20.1 on Arch Linux
gst-play-1.0 fails to display the video content of this file: ![opus_WITH_COVER](/uploads/766c747af2fb2418cb0175b6f5703c2f/opus_WITH_COVER.webm)
It displays correctly in VLC or MPV for example. It is therefore not possible to extract a thumbnail from this file using the GStreamer APIs.
Downstream report: https://gitlab.xfce.org/xfce/tumbler/-/issues/35https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2695rtsp steam capture with splitmuxsink and mpegtsmux randomly remains open2023-06-21T12:14:23ZFrancesco Contertsp steam capture with splitmuxsink and mpegtsmux randomly remains open### Describe your issue
Capturing rtsp udp mcast stream from IP camera to multiple files with following pipeline:
gst-launch-1.0 rtspsrc name=myrtsp buffer-mode=synced protocols=udp-mcast location=rtsp://admin:Admin.1234@10.1.50.108 ! r...### Describe your issue
Capturing rtsp udp mcast stream from IP camera to multiple files with following pipeline:
gst-launch-1.0 rtspsrc name=myrtsp buffer-mode=synced protocols=udp-mcast location=rtsp://admin:Admin.1234@10.1.50.108 ! rtph264depay name=rtphdep ! queue name=q ! h264parse name=parse ! splitmuxsink location=/home/fconte/gstreamer/TestCamera_%d.mp4 name=mysink-1 send-keyframe-requests=TRUE async-finalize=TRUE muxer-factory=mpegtsmux muxer-properties=properties,name=muxer max-size-time=30000000000
#### Expected Behavior
Captured files shell be closed while, randomly, some files are reported (fuser) as still in use by gst-launch.
#### Observed Behavior
Unclosed file events are more frequents on slower system:
1 - Intel(R) Core(TM) i9-10920X CPU @ 3.50GHz --> 1 event in 48 hours
2 - Intel(R) Xeon(R) Bronze 3104 CPU @ 1.70GHz --> 55 events in 24 hours
#### Setup
- **Operating System:** Red Hat Enterprise Linux version 8 update 4
- **Device 1:** Dell Precision 5820
- **Device 2:** HP Z4
- **GStreamer Version:** 1.22.1
- **Command line:** previously reported
### Steps to reproduce the bug
run gst-launch pipeline and wait...
### How reproducible is the bug?
run gst-launch pipeline and wait...
### Solutions you have tried
On HP z4 system, by removing "muxer-factory=mpegtsmux" from pipeline, unclosed file event not occurred during 24 hours continuos session. However, this cannot be considerd a solution while recording files are not usable if truncated; by using "muxer-factory=mpegtsmux" files are usable even if truncated.
### Related non-duplicate issues
none
### Additional Information
xfs filesystem is used to store capture fileshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2693asfdemux: add support for trick play in push mode2023-06-20T17:14:05ZBugzilla Migration Userasfdemux: add support for trick play in push mode## Submitted by Rajesh Singh
**[Link to original bug (#749956)](https://bugzilla.gnome.org/show_bug.cgi?id=749956)**
## Description
Current implementation of ASFDemux, does not support the push mode Trick Play.
Trick Play means Fo...## Submitted by Rajesh Singh
**[Link to original bug (#749956)](https://bugzilla.gnome.org/show_bug.cgi?id=749956)**
## Description
Current implementation of ASFDemux, does not support the push mode Trick Play.
Trick Play means Forward(1/2X, 2X, 4X) and Rewind (-1/2X, -2X, -4X).
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2692asfdemux: Seeking close to duration not working2023-06-20T16:33:55ZBugzilla Migration Userasfdemux: Seeking close to duration not working## Submitted by Nirmal Palanisamy
**[Link to original bug (#789710)](https://bugzilla.gnome.org/show_bug.cgi?id=789710)**
## Description
When we seek close to file duration, playback exits immediately for the attached stream. Playba...## Submitted by Nirmal Palanisamy
**[Link to original bug (#789710)](https://bugzilla.gnome.org/show_bug.cgi?id=789710)**
## Description
When we seek close to file duration, playback exits immediately for the attached stream. Playback is not continuing from the seek position.
Attached stream duration is 50 sec. When seek is issued between 42 to 46 sec, playback ends immediately. Ideally playback should continue from 42 to 46 sec after seek operation.
Version: 1.12.0https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2691x264enc: core on Intel CPUs with avx512. Missing memory alignment ?2023-06-20T16:17:41ZGruikx264enc: core on Intel CPUs with avx512. Missing memory alignment ?Hello
I am using gtsreamer 1.18.2 built from source using meson, on a Centos 7.5.
Everything is working as expected, except the x264 encoding on CPUs with avx512.
On these hosts, even this simple command line provoke a crash:
`gst-laun...Hello
I am using gtsreamer 1.18.2 built from source using meson, on a Centos 7.5.
Everything is working as expected, except the x264 encoding on CPUs with avx512.
On these hosts, even this simple command line provoke a crash:
`gst-launch-1.0 -v videotestsrc num-buffers=1000 ! x264enc qp-min=18 ! avimux ! filesink location=videotestsrc.avi`
```bash
(gdb) where
#0 0x00007f7e2a778f3d in nanosleep () from /lib64/libpthread.so.0
#1 0x00007f7e2ac4bb58 in g_usleep () from /lib64/libglib-2.0.so.0
#2 0x0000000000404f0a in fault_spin () at ../subprojects/gstreamer/tools/gst-launch.c:131
#3 fault_handler_sighandler (signum=11) at ../subprojects/gstreamer/tools/gst-launch.c:112
#4 <signal handler called>
#5 0x00007f7e22047800 in x264_8_memcpy_aligned_avx512 () from /opt/gstreamer1.18/lib/libx264.so.160
#6 0x00007f7e2209ee5a in rd_cost_mb (h=h@entry=0x7f7e18083cc0, i_lambda2=921) at ../subprojects/x264/encoder/rdo.c:182
#7 0x00007f7e220af3e2 in intra_rd (h=h@entry=0x7f7e18083cc0, a=a@entry=0x7f7e1ea9d1a0, i_satd_thresh=i_satd_thresh@entry=268435456)
at ../subprojects/x264/encoder/analyse.c:991
#8 0x00007f7e220b166f in x264_8_macroblock_analyse (h=h@entry=0x7f7e18083cc0) at ../subprojects/x264/encoder/analyse.c:2941
#9 0x00007f7e220ea692 in slice_write (h=h@entry=0x7f7e18083cc0) at ../subprojects/x264/encoder/encoder.c:2786
#10 0x00007f7e220ecd7d in slices_write (h=0x7f7e18083cc0) at ../subprojects/x264/encoder/encoder.c:3127
#11 0x00007f7e220f7106 in threadpool_thread (pool=0x7f7e180283c0) at ../subprojects/x264/common/threadpool.c:69
#12 0x00007f7e2a771e25 in start_thread () from /lib64/libpthread.so.0
#13 0x00007f7e2a49bbad in clone () from /lib64/libc.so.6
```
When looking at the assembly code where it crashed :
```bash
>│0x7f7e22047800 <x264_8_memcpy_aligned_avx512+32> vmovdqa32 %zmm16,(%rdi,%rdx,1){%k1}
rdx 0x400 1024
rdi 0x7f7e1ea9cb20 140179657050912
```
=> rdi is not a multiple of 64, and AFAIK vmovdqa32 instruction requires a 64 bytes alignment
Is there something I can do to work around ? Other than adding "-Dx264:asm=disabled" ?
I tried to recompile gstreamer with "-Dmemory-alignment=64", but it did not help.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2690x264enc: Segment changes can cause invalid DTS to be generated2023-06-20T18:55:48ZSebastian Drögex264enc: Segment changes can cause invalid DTS to be generatedSee below log of `mp4mux`. `in` is the PTS/DTS from `x264enc`, `out` is the corresponding running time with the currently configured segment.
```
in: pts 1000:00:01.666666667 dts 1000:00:01.600000000 dur 0:00:00.033333333
segment: time ...See below log of `mp4mux`. `in` is the PTS/DTS from `x264enc`, `out` is the corresponding running time with the currently configured segment.
```
in: pts 1000:00:01.666666667 dts 1000:00:01.600000000 dur 0:00:00.033333333
segment: time segment start=999:59:58.858892452, offset=0:00:01.141107548, stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.000000000, base=0:00:00.000000000, position 999:59:58.858892452, duration 99:99:99.999999999
out: pts 0:00:01.666666667 dts 0:00:01.600000000 dur 0:00:00.033333333
in: pts 1000:00:01.633333333 dts 1000:00:01.633333333 dur 0:00:00.033333333
segment: time segment start=999:59:58.858892452, offset=0:00:01.141107548, stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.000000000, base=0:00:00.000000000, position 999:59:58.858892452, duration 99:99:99.999999999
out: pts 0:00:01.633333333 dts 0:00:01.633333333 dur 0:00:00.033333333
in: pts 1000:00:01.700000000 dts 1000:00:01.666666667 dur 0:00:00.033333333
segment: time segment start=999:59:58.858892452, offset=0:00:01.141107548, stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.000000000, base=0:00:00.000000000, position 999:59:58.858892452, duration 99:99:99.999999999
out: pts 0:00:01.700000000 dts 0:00:01.666666667 dur 0:00:00.033333333
[new segment -- shifted by about 3s]
in: pts 1000:00:03.733333333 dts 1000:00:01.700000000 dur 0:00:00.033333333
segment: time segment start=999:59:58.858892452, offset=0:00:03.041107548, stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.000000000, base=0:00:00.000000000, position 999:59:58.858892452, duration 99:99:99.999999999
out: pts 0:00:01.833333333 dts 99:99:99.999999999 dur 0:00:00.033333333
in: pts 1000:00:03.833333333 dts 1000:00:01.800000000 dur 0:00:00.033333333
segment: time segment start=999:59:58.858892452, offset=0:00:03.041107548, stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.000000000, base=0:00:00.000000000, position 999:59:58.858892452, duration 99:99:99.999999999
out: pts 0:00:01.933333333 dts 99:99:99.999999999 dur 0:00:00.033333333
[DTS has caught up]
in: pts 1000:00:03.766666667 dts 1000:00:03.733333333 dur 0:00:00.033333333
segment: time segment start=999:59:58.858892452, offset=0:00:03.041107548, stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.000000000, base=0:00:00.000000000, position 999:59:58.858892452, duration 99:99:99.999999999
out: pts 0:00:01.866666667 dts 0:00:01.833333333 dur 0:00:00.033333333
```
Maybe the correct behaviour of `x264enc` would be to always drain on segment changes to avoid this?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2689tags: better metadata / tag editing API2023-06-20T16:15:00ZBugzilla Migration Usertags: better metadata / tag editing API## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#613320)](https://bugzilla.gnome.org/show_bug.cgi?id=613320)**
## Description
GStreamer has no easy to use and efficient api for metadata editing of files. These are th...## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#613320)](https://bugzilla.gnome.org/show_bug.cgi?id=613320)**
## Description
GStreamer has no easy to use and efficient api for metadata editing of files. These are the usecases which are not well supported:
- add new metadata to a file (tagging)
- changing existing metadata in a file (editing)
- strippping some (or all) metadata from a file (privacy filter)
In-place editing would be fast (no need to rewrite long files), but difficult to achieve with gstreamer and would only cover striping and a subset of editing (new size <= old size).
The classic way would be to do
filesrc location=a.mp4 ! mp4demux name=d ! queue ! mp4mux name=m ! filesink location=b.mp4
with extra .d ! queue ! .m for each stream. This is cumbersome as one would need to filter/process the tag-events either on each stream or via tagSetter on the muxer.
Thus we would like to have remux elements that have same in/out caps. Eventually demuxer code could register remuxers as well and reuse the parsing code. One would run them as below and do an atomic delete and rename upon success.
Adding:
- filesrc location=a.mp4 ! mp4remux tags-add=tags ! filesink location=b.mp4
- tags is GstTagList of tags to add
- go to playing
- wait for eos
Editing:
- tagreadbin uri=file://a.mp4
- wait for tags
- edit values
- filesrc location=a.mp4 ! mp4remux tags=tags ! filesink location=b.mp4
- tags is GstTagList of tags to set
- go to playing
- wait for eos
Filtering:
- filesrc location=a.mp4 ! mp4remux tags-remove=tags ! filesink location=b.mp4
- tags is GList of tags to supress
- go to playing
- wait for eos
One alternative would be also to always supply tags-old=tags1 and tags-new=tags2 - both GstTagLists.
Problems:
- Remux elements would need to buffer the whole file in memory until they get to a point where no further metadata is in the file. Then the size corrected headers followed by the data can be written. Trailing buffers can be pushed as they are.
Does this sound doable? Does it stretch what GStreamer is covering too much?
One alternative would be to have a tageditbin, that does the classic pipeline, but manages the internals.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2687Document lock usage in GstVideoDecoder2023-06-20T10:52:24ZFabián OrccónDocument lock usage in GstVideoDecoderAs follow up of https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/358, it may be useful to add this to the documentation of GstVideoDecoder, in relation to GST_VIDEO_DECODER_STREAM_LOCK.
> The decoder stream lock is lik...As follow up of https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/358, it may be useful to add this to the documentation of GstVideoDecoder, in relation to GST_VIDEO_DECODER_STREAM_LOCK.
> The decoder stream lock is likely redundant, but we are stuck with it, since it's in the API/Abi.
> That lock though should always be dropped when a flush or a transition to ready State occurs. Subclass are > responsible for that if these subclass have a separated thread, like omxvideodec and v4l2videodec.
Please, feel free to close this issue, if it is not worth it.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2684Video and audio freeze when seeking an AVI file2024-02-10T18:48:30ZFrom SkyVideo and audio freeze when seeking an AVI fileWhen playing an AVI file (container #0: Audio Video Interleave (AVI), video #1: MPEG-4 Video (Simple Profile), audio #2: MPEG-1 Layer 3 (MP3)), it will be well if play continuously, but seeking play position may cause video freezes, whil...When playing an AVI file (container #0: Audio Video Interleave (AVI), video #1: MPEG-4 Video (Simple Profile), audio #2: MPEG-1 Layer 3 (MP3)), it will be well if play continuously, but seeking play position may cause video freezes, while audio becomes silent or sometimes stuttering. This occurs with gnome's totem player, gst-play-1.0, and some simple pipeline with avidemux, avdec_mpeg4, avdec_mp3.
There's no such issue when play video only, but it will be stutter seeking when only play audio from AVI file. Change avdec_mp3 to mpg123audiodec does not solve the problem. I'm not sure which plugin cause the problem, but it seems only relate to AVI. There's no problem when play mp3 audio file and other video format.
Same video files play well with ffplay.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1775SRT simple loopback test pipeline not working_gstreamer_v_1.16.32023-07-18T15:57:01ZSujin KimSRT simple loopback test pipeline not working_gstreamer_v_1.16.3Hi,
Trying to do some SRT loopback test at NVIDIA AGX Orin which is using gstreamer v1.16.3.
However with no errors following pipeline is not working properly. Cannot see any video displays..
Encode : gst-launch-1.0 v4l2src io-mode=4 d...Hi,
Trying to do some SRT loopback test at NVIDIA AGX Orin which is using gstreamer v1.16.3.
However with no errors following pipeline is not working properly. Cannot see any video displays..
Encode : gst-launch-1.0 v4l2src io-mode=4 device=/dev/video0 do-timestamp=true ! 'video/x-raw, width=1920, height=1088, framerate=60/1, format=BGRx' ! nvvidconv ! 'video/x-raw(memory:NVMM), ftrate=4000000 ! h265parse ! mpegtsmux ! srtsink uri=srt://:8888
Decode : gst-launch-1.0 srtsrc uri=srt://127.0.0.1:8888 ! tsparse ! tsdemux ! h265parse ! nvv4l2decoder ! nvvidconv ! queue ! ximagesink
Can any one give me some advises?
Am I using MPEG-TS MUX/DEMUX wrong?
P.S. Loop back test over UDP using udpsink and udpsrc works finehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2682flacparse: Seeking in variable blocksize FLAC file fails, timestamp is wrong2023-06-21T05:16:46ZMartijn van Beurdenflacparse: Seeking in variable blocksize FLAC file fails, timestamp is wrongWhen playing [this file](https://github.com/ietf-wg-cellar/flac-test-files/blob/main/subset/24%20-%20variable%20blocksize%20file%20created%20with%20flake%20revision%20264.flac) with gst-play-1.0, gst 1.22.3, FLAC 1.4.2, the position stay...When playing [this file](https://github.com/ietf-wg-cellar/flac-test-files/blob/main/subset/24%20-%20variable%20blocksize%20file%20created%20with%20flake%20revision%20264.flac) with gst-play-1.0, gst 1.22.3, FLAC 1.4.2, the position stays at 0:00:00.0, seeking forward results in immediate termination of playback and seeking backwards results in seeking all the way to the start of the file
#### Setup
- **Operating System:** OpenSUSE Tumbleweed 20230614-0
- **Device:** Computer
- **GStreamer Version:** 1.22.3
- **Command line:** gst-play-1.0 24\ -\ variable\ blocksize\ file\ created\ with\ flake\ revision\ 264.flac
### Steps to reproduce the bug
1. open terminal
2. type `gst-play-1.0 24\ -\ variable\ blocksize\ file\ created\ with\ flake\ revision\ 264.flac`
3. observe timestamp not increasing
4. seek backwards
5. observe playback starting at beginning of file
6. seek forwards
7. observe termination of playback
### How reproducible is the bug?
Always
### Solutions you have tried
I can't seem to find the location in the source code where the timestamp is updated, nor figure out how seeking is performed exactly.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2681Better Audio Clock Skew Correction2023-06-23T11:25:31ZJamie WBetter Audio Clock Skew CorrectionCurrently, GStreamer has support for `skew` and `resample` methods (and bring-your-own) of correcting clock skew.
However, these are not good enough for professional use, as - for instance - GStreamer struggles on its own to reliably p...Currently, GStreamer has support for `skew` and `resample` methods (and bring-your-own) of correcting clock skew.
However, these are not good enough for professional use, as - for instance - GStreamer struggles on its own to reliably play out a live audio stream (even locally generated) without re-syncing in a very noticable way (#317, gst-plugins-base#80, https://narkive.com/oUoa2zeg).
This can be observed by running these really simple pipelines on the same machine (and waiting for 5 - 30 minutes - depending on how accurate the clock in your sound card is - to observe a glitch or drop-out):
# Terminal 1
gst-launch-1.0 audiotestsrc wave=sine freq=1000 volume=0.1 is-live=1 do-timestamp=1 \
! audio/x-raw,sample-rate=48000,channels=2,format=S16LE \
! queue \
! srtsink uri="srt://127.0.0.1:9001?mode=caller" sync=true wait-for-connection=0
# Terminal 2
gst-launch-1.0 srtsrc uri="srt://127.0.0.1:9001?mode=listener" do-timestamp=1 keep-listening=1 \
! rawaudioparse pcm-format=s16le \
! queue \
! alsasink
The resample method produces very audible artefacts and only works when sync=false on the sink, and the `skew` method drops buffers (skips) or introduces noticable underruns when the drift reaches a certain threshold.
I note the PipeWire project implements a Delay-Locked Loop and good adaptive resampling that could be re-purposed for use inside GStreamer. This can be done inside a project by using a custom `slave-method` on a sink (and indeed an easier but limited workaround on Linux is to play out to pipewiresink and let that handle synchronisation). But this is something I'd really want to see GStreamer do natively/better in the GstAudioBaseSink.
I'd love to have a go at this but admittedly I'm not a strong C developer.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2680nvcodec: No way to crop cuda memory without device transfer2023-06-16T19:36:03ZBrandon Oglenvcodec: No way to crop cuda memory without device transferI have a gstreamer pipeline where I am trying to keep all operations on GPU to improve throughput and ideally reduce latency. In broad strokes this pipeline fetches some segment of h264 video, crops, resizes and finally encodes back to h...I have a gstreamer pipeline where I am trying to keep all operations on GPU to improve throughput and ideally reduce latency. In broad strokes this pipeline fetches some segment of h264 video, crops, resizes and finally encodes back to h264. I have hit a roadblock at the moment where it does not seem possible to crop the video without a transfer back to host memory where I can use the `videocrop` element. I noticed in the gst-plugins-bad nvenc plugin directory, the `cuda-converter.c` file implements most of the kernel functions for the plugin. This file has a list of TODO's including cropping, is there any ETA to such functionality becoming available?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2679tsdemux sends gap event before segment event on sparse streams2023-06-16T11:29:45ZBenjamin Muzaltsdemux sends gap event before segment event on sparse streamstsdemux sends a new gap event on sparse streams with timesamp=0 in gst_ts_demux_update_program() and gst_ts_demux_program_started()
This happens before the segment event is sent out.
Downstream from tsdemux, this causes an ugly critical...tsdemux sends a new gap event on sparse streams with timesamp=0 in gst_ts_demux_update_program() and gst_ts_demux_program_started()
This happens before the segment event is sent out.
Downstream from tsdemux, this causes an ugly critical warning in GstAggregator based elements when they try to clip the event without a segment.
If streams always need a gap event at the beginning of sparse streams, maybe the gap event should be sent at the end of calculate_and_push_newsegment() using the start of the segment for the timestamp instead of a timestamp of 0?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2678vpxenc (vp8 and vp9) don't seem to respect calculated bitrate2023-06-18T00:20:00Zkyteinskyvpxenc (vp8 and vp9) don't seem to respect calculated bitrate### Describe your issue
vp8enc and vp9enc use the correct bitrate when `target-bitrate` is set to a fixed number but do not calculate the same when `target-bitrate = 0` and `bits-per-pixel = 0.1`.
#### Expected Behavior
The bitrate of t...### Describe your issue
vp8enc and vp9enc use the correct bitrate when `target-bitrate` is set to a fixed number but do not calculate the same when `target-bitrate = 0` and `bits-per-pixel = 0.1`.
#### Expected Behavior
The bitrate of the encoder to be calculated based on the `bits-per-pixel` value.
#### Observed Behavior
The bitrate falls back to the default 256000 value when `target-bitrate = 0` and `bits-per-pixel = 0.1`.
#### Setup
- **Operating System:** Fedora 37
- **Device:** Computer
- **GStreamer Version:** 1.20.5
- **Command line:** (I am using it in a C project)
### Steps to reproduce the bug
1. Create a sample pipeline using vp8enc or vp9enc in C
2. Set the properties `target-bitrate = 0` and `bits-per-pixel = 0.1`
3. Compile and launch the program with the `GST_DEBUG_DUMP_DOT_DIR` environment variable set (/tmp for example)
4. Use the following line to dump a dot file
`GST_DEBUG_BIN_TO_DOT_FILE (bin, GST_DEBUG_GRAPH_SHOW_ALL, "bin-file");`
5. Generate an image from the dumped file
`dot -Tpng -oimage.png bin-file.dot`
This image file shows the properties set for the encoder.
### How reproducible is the bug?
Always
### Screenshots if relevant
![pipeline image](/uploads/be4899ec0a2df4dea3b195ae2fbfd1ee/image.png)
### Solutions you have tried
Knew it wouldn't work, but still tried setting `target-bitrate` to 1, the result was it was set to 0. The video output was non-existent after this as expected.
### Related non-duplicate issues
### Additional Informationhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2677AMF amfh264enc gop-size2023-06-16T02:29:12ZpigeatgarlicAMF amfh264enc gop-size### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstream...### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstreamer.freedesktop.org/lists/ -->
#### Expected Behavior
<!-- What did you expect to happen -->
#### Observed Behavior
Our application using amf and nvcodec, which require the encoder to disable IDR frame generation periodically (by setting gop-size to -1 or 0), and instead call gst_video_event_new_upstream_force_key_unit.
However, for AMFh264enc, when we set AMF_VIDEO_ENCODER_IDR_PERIOD to 0, IDR still be generated every 4sec (~gop-size=200), I Frame did not generated when we call AMF_VIDEO_ENCODER_FORCE_PICTURE_TYPE.
I highly doubt that this issue cause by AMF it self
#### Setup
- **Operating System:** Window 10
- **Device:** Virtual Machine with AMD v520 GPU
- **GStreamer Version:** 1.22.3
- **Command line:**
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. open terminal
2. type `command`
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
### Screenshots if relevant
![image](/uploads/c9c8adfcdd07d0916866972ec0d41601/image.png)
### Solutions you have tried
### Related non-duplicate issues
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2676ci: Windows SDK needs to be updated2023-06-16T09:28:35ZMaurizio Buratoci: Windows SDK needs to be updatedfor testing purpose i downloaded the latest artifacts from here: https://gitlab.freedesktop.org/gstreamer/cerbero/-/jobs/43863575/artifacts/download?file_type=archive but d3d11screencapturesrc element in this build is obsolete and is mis...for testing purpose i downloaded the latest artifacts from here: https://gitlab.freedesktop.org/gstreamer/cerbero/-/jobs/43863575/artifacts/download?file_type=archive but d3d11screencapturesrc element in this build is obsolete and is missing most of the properties that was added in the last year (ex: no capture-api property)
```
gst-inspect-1.0 d3d11screencapturesrc
Factory Details:
Rank none (0)
Long-name Direct3D11 Screen Capture Source
Klass Source/Video
Description Captures desktop screen
Author Seungha Yang <seungha@centricular.com>
Documentation https://gstreamer.freedesktop.org/documentation/d3d11/d3d11screencapturesrc.html
Plugin Details:
Name d3d11
Description Direct3D11 plugin
Filename D:\GB32\gstreamer\1.0\msvc_x86_64\lib\gstreamer-1.0\gstd3d11.dll
Version 1.23.0.1
License LGPL
Source module gst-plugins-bad
Documentation https://gstreamer.freedesktop.org/documentation/d3d11/
Binary package GStreamer Bad Plug-ins git
Origin URL Unknown package origin
GObject
+----GInitiallyUnowned
+----GstObject
+----GstElement
+----GstBaseSrc
+----GstD3D11ScreenCaptureSrc
Pad Templates:
SRC template: 'src'
Availability: Always
Capabilities:
video/x-raw(memory:D3D11Memory)
format: BGRA
width: [ 1, 16384 ]
height: [ 1, 16384 ]
framerate: [ 0/1, 2147483647/1 ]
pixel-aspect-ratio: 1/1
video/x-raw
format: BGRA
width: [ 1, 16384 ]
height: [ 1, 16384 ]
framerate: [ 0/1, 2147483647/1 ]
pixel-aspect-ratio: 1/1
Element has no clocking capabilities.
Element has no URI handling capabilities.
Pads:
SRC: 'src'
Pad Template: 'src'
Element Properties:
blocksize : Size in bytes to read per buffer (-1 = default)
flags: readable, writable
Unsigned Integer. Range: 0 - 4294967295 Default: 4096
crop-height : Height of screen capture area (0 = maximum)
flags: readable, writable
Unsigned Integer. Range: 0 - 4294967295 Default: 0
crop-width : Width of screen capture area (0 = maximum)
flags: readable, writable
Unsigned Integer. Range: 0 - 4294967295 Default: 0
crop-x : Horizontal coordinate of top left corner for the screen capture area
flags: readable, writable
Unsigned Integer. Range: 0 - 4294967295 Default: 0
crop-y : Vertical coordinate of top left corner for the screen capture area
flags: readable, writable
Unsigned Integer. Range: 0 - 4294967295 Default: 0
do-timestamp : Apply current stream time to buffers
flags: readable, writable
Boolean. Default: false
monitor-handle : A HMONITOR handle of monitor to capture
flags: readable, writable, changeable only in NULL or READY state
Unsigned Integer64. Range: 0 - 18446744073709551615 Default: 0
monitor-index : Zero-based index for monitor to capture (-1 = primary monitor)
flags: readable, writable, changeable only in NULL or READY state
Integer. Range: -1 - 2147483647 Default: -1
name : The name of the object
flags: readable, writable
String. Default: "d3d11screencapturesrc0"
num-buffers : Number of buffers to output before sending EOS (-1 = unlimited)
flags: readable, writable
Integer. Range: -1 - 2147483647 Default: -1
parent : The parent of the object
flags: readable, writable
Object of type "GstObject"
show-cursor : Whether to show mouse cursor
flags: readable, writable
Boolean. Default: false
typefind : Run typefind before negotiating (deprecated, non-functional)
flags: readable, writable, deprecated
Boolean. Default: false
```
could you please check if the bot is compiling an old source?
i would like to test the new d3d11 stuff 1.23https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2675mp4mux reserved-max-duration property should not accept value 02023-06-15T19:00:02ZFlorent Thierymp4mux reserved-max-duration property should not accept value 0mp4mux's property documentation states that value 0 is accepted:
```
reserved-max-duration: When set to a value > 0, reserves space for index tables at the beginning of the file.
flags: accès en lecture, accès ...mp4mux's property documentation states that value 0 is accepted:
```
reserved-max-duration: When set to a value > 0, reserves space for index tables at the beginning of the file.
flags: accès en lecture, accès en écriture
Unsigned Integer64. Range: 0 - 18446744073709551615 Default: 18446744073709551615
```
However:
```
$ gst-launch-1.0 videotestsrc is-live=true ! x264enc tune=zerolatency ! mp4mux reserved-max-duration=0 reserved-moov-update-period=30000000000 ! filesink location=/tmp/test.mp4
...
ERROR: from element /GstPipeline:pipeline0/GstMP4Mux:mp4mux0: reserved-max-duration of 0 is not allowed
Additional debug info:
../subprojects/gst-plugins-good/gst/isomp4/gstqtmux.c(3052): gst_qt_mux_start_file (): /GstPipeline:pipeline0/GstMP4Mux:mp4mux0
```
As a workaround, i used the value `-1`
```
$ LANG=C gst-launch-1.0 videotestsrc is-live=true ! x264enc tune=zerolatency ! mp4mux reserved-max-duration=-1 reserved-moov-update-period=30000000000 ! filesink location=/tmp/test.mp4
```
Why is 0 even in the accepted range ? Should the documentation not state `When set to a value >= 0` ?https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/376gtk4paintablesink: fails to display correctly the colors on MacOS2023-06-15T11:03:51ZStéphane Cerveauscerveau@igalia.comgtk4paintablesink: fails to display correctly the colors on MacOS### Describe your issue
The color space is incorrect using gtkpaintablesink in a GTK application and with gstreamer pipeline such
as videotestsrc ! videoconvert ! gtkpaintablesink
#### Expected Behavior
To have the right color space
##...### Describe your issue
The color space is incorrect using gtkpaintablesink in a GTK application and with gstreamer pipeline such
as videotestsrc ! videoconvert ! gtkpaintablesink
#### Expected Behavior
To have the right color space
#### Observed Behavior
The colors are not correct
#### Setup
- **Operating System:** MacOS Catalina
- **Device:** Computer
- **GStreamer Version:** 1.23.1
- **Command line:**
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. Use GstPipelineStudio to reproduce the issue
### How reproducible is the bug?
Always
### Screenshots if relevant
![Capture_d_écran_2023-06-15_à_10.10.24](/uploads/0103834009a0e4d8a01bee2f57ed3154/Capture_d_écran_2023-06-15_à_10.10.24.png)
### Solutions you have tried
I have a try with glimagesink and this is working fine
### Related non-duplicate issues
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/433ci: build gst-plugins-rs in debug mode for git monorepo ci, for faster builds?2024-02-12T12:42:31ZTim-Philipp Müllertim@centricular.comci: build gst-plugins-rs in debug mode for git monorepo ci, for faster builds?Currently the gst-plugins-rs build takes a long time, especially on macOS, and is the bottleneck for any monorepo merge request.
I wonder if it would make sense to perhaps build gst-plugins-rs in debug mode instead of release mode for s...Currently the gst-plugins-rs build takes a long time, especially on macOS, and is the bottleneck for any monorepo merge request.
I wonder if it would make sense to perhaps build gst-plugins-rs in debug mode instead of release mode for such merge request pipelines?
Debug mode should be faster, but will generate larger artefacts.
Question is how much faster and how much larger are the artefacts - something to try perhaps.