GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2023-05-03T17:10:44Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2541validate: gst-validate-launcher doc is outdated2023-05-03T17:10:44ZGuillaume Desmottesvalidate: gst-validate-launcher doc is outdatedSee https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-validate/html/gst-validate-launcher.html
* The example doesn't mention and explain `TEST_MANAGER` and it uses `validate` instead of `test_manager` to call `add_scenarios` ...See https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-validate/html/gst-validate-launcher.html
* The example doesn't mention and explain `TEST_MANAGER` and it uses `validate` instead of `test_manager` to call `add_scenarios` etc
* The example doesn't implement `setup_tests()`
* It uses `--config` which has been deprecatedhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2540meson test Command printed by the gst-validate-launcher is super painful to r...2023-05-03T17:04:49ZOlivier Crêteolivier.crete@ocrete.cameson test Command printed by the gst-validate-launcher is super painful to reproduce locally because of absolute pathsThe current gst-validate-launcher command is super long and impossible to re-use locally. The big issue are the absolute paths.
I get something like:
``` bash
HOSTNAME='runner-nXyY3ZHz-project-1497-concurrent-0' CI_BUILD_NAME='build fed...The current gst-validate-launcher command is super long and impossible to re-use locally. The big issue are the absolute paths.
I get something like:
``` bash
HOSTNAME='runner-nXyY3ZHz-project-1497-concurrent-0' CI_BUILD_NAME='build fedora x86_64' CI_CONCURRENT_ID='1' CI_BUILD_ID='1114297' CCACHE_BASEDIR='/cache/gstreamer/gst-build' G_DEBUG='gc-friendly' GST_TAG_LICENSE_TRANSLATIONS_DICT='/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-plugins-base/gst-libs/gst/tag/license-translations.dict' GST_CHECKS='test_reuse_without_decoders' CI_BUILD_TOKEN='W1yynZbq3PdZkJnY6bBE' CI_RUNNER_ID='382' _='/usr/local/bin/meson' CI_BUILD_STAGE='build' G_SLICE='always-malloc' CI_REGISTRY_PASSWORD='W1yynZbq3PdZkJnY6bBE' CI_JOB_TOKEN='W1yynZbq3PdZkJnY6bBE' CCACHE_MAXSIZE='10G' GST_PLUGIN_SYSTEM_PATH_1_0='' CI_JOB_NAME='build fedora x86_64' CCACHE_DIR='/cache/gstreamer/gst-build/ccache/' MESON_ARGS='-Dpython=enabled -Dlibav=enabled -Dugly=enabled -Dbad=enabled -Ddevtools=enabled -Dges=enabled -Drtsp_server=enabled -Dvaapi=enabled -Dsharp=disabled
-Dsharp=enabled -Domx=enabled -Dgst-omx:target=generic -Ddoc=enabled --default-library=both --werror' CI_REPOSITORY_URL='https://gitlab-ci-token:W1yynZbq3PdZkJnY6bBE@gitlab.freedesktop.org/ocrete/gst-plugins-base.git' PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' GST_PLUGIN_PATH_1_0='/builds/ocrete/gst-plugins-base/gst-build/build:/usr/local/lib64/gstreamer-1.0' GST_REGISTRY='/builds/ocrete/gst-plugins-base/gst-build/build/subprojects/gst-plugins-base/tests/check/elements_decodebin.registry' CK_DEFAULT_TIMEOUT='20' CCACHE_COMPRESS='true' CK_TIMEOUT_MULTIPLIER='20' CI_JOB_STAGE='build' CI_RUNNER_DESCRIPTION='gst-gitlab-htz-runner1' GST_VALIDATE_CONFIG='/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-devtools/validate/data/valgrind.config' CI_JOB_ID='1114297' ORC_CODE='backup' CI_RUNNER_SHORT_TOKEN='nXyY3ZHz' CCACHE_COMPILERCHECK='content' GST_STATE_IGNORE_ELEMENTS='cdio cdparanoiasrc libvisual_ alsasrc alsasink' CI_JOB_URL='https://gitlab.freedesktop.org/ocrete/gst-plugins-base/-/jobs/1114297' GST_PLUGIN_LOADING_WHITELIST='gstreamer:gst-plugins-base@/builds/ocrete/gst-plugins-base/gst-build/build' valgrind --trace-children=yes --tool=memcheck --leak-check=full --leak-resolution=high --errors-for-leak-kinds=definite,indirect --show-leak-kinds=definite,indirect --show-possibly-lost=no --num-callers=20 --error-exitcode=20 --gen-suppressions=all --log-file=/builds/ocrete/gst-plugins-base/validate-logs/check/gst-plugins-base/elements_decodebin/test_reuse_without_decoders.valgrind --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-devtools/validate/data/gstvalidate.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/gstreamer/tests/check/gstreamer.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-plugins-base/tests/check/gst-plugins-base.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-plugins-good/tests/check/gst-plugins-good.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-plugins-bad/tests/check/gst-plugins-bad.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-plugins-ugly/tests/check/gst-plugins-ugly.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-libav/tests/check/gst-libav.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-devtools/validate/data/gstvalidate.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/libnice/tests/libnice.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/libsoup/tests/libsoup.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/glib/glib.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-python/testsuite/gstpython.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-python/testsuite/python.supp /builds/ocrete/gst-plugins-base/gst-build/build/subprojects/gst-plugins-base/tests/check/elements_decodebin
```
I'd rather have something like
``` bash
HOSTNAME='runner-nXyY3ZHz-project-1497-concurrent-0' CI_BUILD_NAME='build fedora x86_64' CI_CONCURRENT_ID='1' CI_BUILD_ID='1114297' CCACHE_BASEDIR='/cache/gstreamer/gst-build' G_DEBUG='gc-friendly' GST_TAG_LICENSE_TRANSLATIONS_DICT='/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-plugins-base/gst-libs/gst/tag/license-translations.dict' GST_CHECKS='test_reuse_without_decoders' CI_BUILD_TOKEN='W1yynZbq3PdZkJnY6bBE' CI_RUNNER_ID='382' _='/usr/local/bin/meson' CI_BUILD_STAGE='build' G_SLICE='always-malloc' CI_REGISTRY_PASSWORD='W1yynZbq3PdZkJnY6bBE' CI_JOB_TOKEN='W1yynZbq3PdZkJnY6bBE' CCACHE_MAXSIZE='10G' GST_PLUGIN_SYSTEM_PATH_1_0='' CI_JOB_NAME='build fedora x86_64' CCACHE_DIR='/cache/gstreamer/gst-build/ccache/' MESON_ARGS='-Dpython=enabled -Dlibav=enabled -Dugly=enabled -Dbad=enabled -Ddevtools=enabled -Dges=enabled -Drtsp_server=enabled -Dvaapi=enabled -Dsharp=disabled
-Dsharp=enabled -Domx=enabled -Dgst-omx:target=generic -Ddoc=enabled --default-library=both --werror' CI_REPOSITORY_URL='https://gitlab-ci-token:W1yynZbq3PdZkJnY6bBE@gitlab.freedesktop.org/ocrete/gst-plugins-base.git' PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' GST_PLUGIN_PATH_1_0='/builds/ocrete/gst-plugins-base/gst-build/build:/usr/local/lib64/gstreamer-1.0' GST_REGISTRY='/builds/ocrete/gst-plugins-base/gst-build/build/subprojects/gst-plugins-base/tests/check/elements_decodebin.registry' CK_DEFAULT_TIMEOUT='20' CCACHE_COMPRESS='true' CK_TIMEOUT_MULTIPLIER='20' CI_JOB_STAGE='build' CI_RUNNER_DESCRIPTION='gst-gitlab-htz-runner1' GST_VALIDATE_CONFIG='/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-devtools/validate/data/valgrind.config' CI_JOB_ID='1114297' ORC_CODE='backup' CI_RUNNER_SHORT_TOKEN='nXyY3ZHz' CCACHE_COMPILERCHECK='content' GST_STATE_IGNORE_ELEMENTS='cdio cdparanoiasrc libvisual_ alsasrc alsasink' CI_JOB_URL='https://gitlab.freedesktop.org/ocrete/gst-plugins-base/-/jobs/1114297' GST_PLUGIN_LOADING_WHITELIST='gstreamer:gst-plugins-base@/builds/ocrete/gst-plugins-base/gst-build/build' valgrind --trace-children=yes --tool=memcheck --leak-check=full --leak-resolution=high --errors-for-leak-kinds=definite,indirect --show-leak-kinds=definite,indirect --show-possibly-lost=no --num-callers=20 --error-exitcode=20 --gen-suppressions=all --log-file=/builds/ocrete/gst-plugins-base/validate-logs/check/gst-plugins-base/elements_decodebin/test_reuse_without_decoders.valgrind --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-devtools/validate/data/gstvalidate.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/gstreamer/tests/check/gstreamer.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-plugins-base/tests/check/gst-plugins-base.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-plugins-good/tests/check/gst-plugins-good.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-plugins-bad/tests/check/gst-plugins-bad.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-plugins-ugly/tests/check/gst-plugins-ugly.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-libav/tests/check/gst-libav.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-devtools/validate/data/gstvalidate.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/libnice/tests/libnice.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/libsoup/tests/libsoup.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/glib/glib.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-python/testsuite/gstpython.supp --suppressions=/builds/ocrete/gst-plugins-base/gst-build/subprojects/gst-python/testsuite/python.supp /builds/ocrete/gst-plugins-base/gst-build/build/subprojects/gst-plugins-base/tests/check/elements_decodebin
```
I'd prefer if we removed the `/builds/ocrete/gst-plugins-base/gst-build/` from the command to make it easier to run locally.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2538validate: Add `GST_USE_UNSTABLE_API` guards as the API is not meant to be st...2023-05-03T17:05:33ZThibault Sauniertsaunier@igalia.comvalidate: Add `GST_USE_UNSTABLE_API` guards as the API is not meant to be stableThe following discussion from gst-devtools!248 should be addressed:
- [ ] @tpm started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-devtools/-/merge_requests/248#note_1231221): (+3 comments)
> @thiblahute this looks...The following discussion from gst-devtools!248 should be addressed:
- [ ] @tpm started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-devtools/-/merge_requests/248#note_1231221): (+3 comments)
> @thiblahute this looks like an API/ABI break?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2534macOS only: gstvideometa.c "Stride of plane 0 is different... alignment"2023-05-01T05:07:19ZF. DuncanhmacOS only: gstvideometa.c "Stride of plane 0 is different... alignment"In macOS 13.3 (and 10.13.x) GST_DEBUG=2 reveals that EVERY video frame (30 fps h264, streamed from Apple AirPlay) triggers a warning
```
0:17:32.989417000 5843 0x1419a1ad0 WARN videometa gstvideometa.c:416:gst_video_me...In macOS 13.3 (and 10.13.x) GST_DEBUG=2 reveals that EVERY video frame (30 fps h264, streamed from Apple AirPlay) triggers a warning
```
0:17:32.989417000 5843 0x1419a1ad0 WARN videometa gstvideometa.c:416:gst_video_meta_validate_alignment: Stride of plane 0 defined in meta (1472) is different from the one computed from the alignment (1440)
0:17:33.024003000 5843 0x1419a1ad0 WARN videometa gstvideometa.c:416:gst_video_meta_validate_alignment: Stride of plane 0 defined in meta (1472) is different from the one computed from the alignment (1440)
0:17:33.053544000 5843 0x1419a1ad0 WARN videometa gstvideometa.c:416:gst_video_meta_validate_alignment: Stride of plane 0 defined in meta (1472) is different from the one computed from the alignment (1440)
0:17:33.087698000 5843 0x1419a1ad0 WARN videometa gstvideometa.c:416:gst_video_meta_validate_alignment: Stride of plane 0 defined in meta (1472) is different from the one computed from the alignment (1440)
```
This error is current and is present already in 1.20.5
I'll see if its occurs in any older gstreamer I can install.
This is only in MacOS, both M2 and intel.
* EDIT: is this just "spam" that should be suppressed, or is there a bug in computing alignment (on macOS only?) that should be tracked down (I have a self-compiled 1.22.2 on MacOS 13.3 that I can investigate with).
The h264video plays OK, it seems.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/346ci: missing dtls elements in Windows images2023-05-21T19:43:22ZFrançois Laignelci: missing dtls elements in Windows imagesdtls elements are not included in Windows CI images, causing a new WebRTC test to fail on this platform.
Isolated job: https://gitlab.freedesktop.org/fengalin/gst-plugins-rs/-/jobs/40919231dtls elements are not included in Windows CI images, causing a new WebRTC test to fail on this platform.
Isolated job: https://gitlab.freedesktop.org/fengalin/gst-plugins-rs/-/jobs/40919231Jordan PetridіsJordan Petridіshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2532v4l2sink: incorrectly reports "bytes_used" in the queued v4l2-buffer2023-05-02T11:04:03Zumläutev4l2sink: incorrectly reports "bytes_used" in the queued v4l2-bufferthere has been a long-standing bug-report with the [v4l2loopback](https://github.com/umlaeute/v4l2loopback/issues/190) kernel module, where `ffmpeg` reports errors when reading from `v4l2loopback` with streams provided by GStreamer's `v4...there has been a long-standing bug-report with the [v4l2loopback](https://github.com/umlaeute/v4l2loopback/issues/190) kernel module, where `ffmpeg` reports errors when reading from `v4l2loopback` with streams provided by GStreamer's `v4l2sink`.
the pipeline is launched as follows (with `/dev/video2` being a loopback device)
```sh
$ gst-launch-1.0 videotestsrc ! video/"x-raw,width=320,height=240" ! videoconvert ! v4l2sink device=/dev/video2
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
Redistribute latency...
New clock: GstSystemClock
0:00:01.4 / 99:99:99.
```
reading the device with `ffmpeg` gives us something like this:
```sh
$ ffplay -hide_banner -i /dev/video2
Input #0, video4linux2,v4l2, from '/dev/video2':
Duration: N/A, start: 433809.417170, bitrate: 36864 kb/s
Stream #0:0: Video: rawvideo (YUY2 / 0x32595559), yuyv422, 320x240, 36864 kb/s, 30 fps, 30 tbr, 1000k tbn
[video4linux2,v4l2 @ 0x7fff70000c80] Dequeued v4l2 buffer contains 155648 bytes, but 153600 were expected. Flags: 0x00006001.
[video4linux2,v4l2 @ 0x7fff70000c80] Dequeued v4l2 buffer contains 155648 bytes, but 153600 were expected. Flags: 0x00006001.
[video4linux2,v4l2 @ 0x7fff70000c80] Dequeued v4l2 buffer contains 155648 bytes, but 153600 were expected. Flags: 0x00006001.
```
typically, ffmpeg freezes the image in this case.
afaict, the problem is that the `struct v4l2_buffer` has two members `bytesused` and `length`
```
struct v4l2_buffer {
__u32 index;
__u32 type;
__u32 bytesused;
// ...
__u32 length;
```
with the [following semantics](https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/buffer.html):
| member | descr |
|--------|-------|
| bytesused | The number of bytes occupied by the data in the buffer. It depends on the negotiated data format and may change with each buffer for compressed variable size data like JPEG images. Drivers must set this field when type refers to a capture stream, applications when it refers to an output stream. [...] |
| length | Size of the buffer (not the payload) in bytes for the single-planar API. [...] |
in the above example we observe that the payload on the video device is a 320x240 YUY2 stream, which has a nominal payload of **320x240x2=153600** bytes.
on a system with a pagesize of 4096 bytes, a buffer will be padded to **155648** bytes.
it seems that the problem really is, that `ffmpeg` knows that the payload is **153600**, and if it receives buffers that claim that `bytesused=155648` then it complains that something is wrong.
so who is to blame?
- `ffmpeg` might be a bit relaxed about too large buffers, however it is correct in complaining that the reported payload-size does not match the actual payload size.
- `v4l2loopback` simply copies the buffer metadata from the OUTPUT stream to the CAPTURE stream. i think this is reasonable, as `v4l2loopback` tries to be a very thin connecting layer (but then, i'm the v4l2loopback upstream so i might be biased)
- GStreamer's `v4l2sink` is the one who sets both the `bytesused` and the `length` fields of the buffers. i argue that it should properly set the `bytesused` field to the actual payload size.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2530playsink: the element never transitions into playing state with audio and video2023-04-28T09:47:41ZAndoni Morales Alastrueyplaysink: the element never transitions into playing state with audio and videoThe following pipeline using playsink with audio and video doesn't transition into playing state:
`gst-launch-1.0 playsink name=ps audiotestsrc ! ps.audio_raw_sink videotestsrc ! "video/x-raw" ! ps.video_raw_sink`
```
➜ gstreamer gi...The following pipeline using playsink with audio and video doesn't transition into playing state:
`gst-launch-1.0 playsink name=ps audiotestsrc ! ps.audio_raw_sink videotestsrc ! "video/x-raw" ! ps.video_raw_sink`
```
➜ gstreamer git: ✗ gst-launch-1.0 playsink name=ps audiotestsrc ! ps.audio_raw_sink videotestsrc ! "video/x-raw" ! ps.video_raw_sink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'videosink': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayCocoa\)\ gldisplaycocoa0";
0:00:00.074332000 58323 0x148e68c90 ERROR glcaopengllayer gstglcaopengllayer.m:161:-[GstGLCAOpenGLLayer copyCGLContextForPixelFormat:]: failed to retrieve GStreamer GL context in CAOpenGLLayer
Redistribute latency...
```
Live:
```
➜ gstreamer git: ✗ gst-launch-1.0 playsink name=ps audiotestsrc is-live=true ! ps.audio_raw_sink videotestsrc is-live=true ! "video/x-raw" ! ps.video_raw_sink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got context from element 'videosink': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayCocoa\)\ gldisplaycocoa0";
0:00:00.071120000 58384 0x1367c5aa0 ERROR glcaopengllayer gstglcaopengllayer.m:161:-[GstGLCAOpenGLLayer copyCGLContextForPixelFormat:]: failed to retrieve GStreamer GL context in CAOpenGLLayer
Redistribute latency..
```
Audio-only or Video-only works as expectedhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2527[2.0] {audio,video}rate: set skip-to-first=true as default2023-04-26T13:15:11ZGuillaume Desmottes[2.0] {audio,video}rate: set skip-to-first=true as defaultI've been hit again by `skip-to-first=false` being the default on `videorate`. Opening this ticket so we can change the default for 2.0I've been hit again by `skip-to-first=false` being the default on `videorate`. Opening this ticket so we can change the default for 2.0https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2526matroskamux: file not seekable maybe due to timecode rounding problem2023-11-07T11:45:53ZNicoDeLargematroskamux: file not seekable maybe due to timecode rounding problem### Describe your issue
I am using an app that uses gstreamer to export application internal video streams to stand alone MKV files. Unfortunately, the files generated can be played by e.g. VLC but are not seekable (i.e. I cannot jump to...### Describe your issue
I am using an app that uses gstreamer to export application internal video streams to stand alone MKV files. Unfortunately, the files generated can be played by e.g. VLC but are not seekable (i.e. I cannot jump to specific positions in the video).
#### Expected Behavior
The videos should be seekable.
#### Observed Behavior
The video is not seekable.
#### Setup
- **Operating System:** Windows 10
- **Device:** Computer
- **GStreamer Version:** 1.22.2
- **Command line:** "jpegdec ! videoconvert ! nvh264enc ! h264parse" (source and sink part of the pipeline are controlled by the app, only the pipeline between can be adapted by the user)
### Steps to reproduce the bug
### How reproducible is the bug?
Every time exporting/generating a MKV using the app.
### Screenshots if relevant
### Solutions you have tried
- Using different input files
- Using different pipelines
- Adapting matroskamux properties (not possible due to limitations in app)
### Related non-duplicate issues
### Additional Information
mkvalidator-0.6 gives the following results:
```
230331_091006.adtfdat_export_Video.mkv
ERR201: Invalid 'Colour' for profile 'matroska v2' in Video at 371
ERR201: Invalid 'Range' for profile 'matroska v2' in Colour at 391
ERR201: Invalid 'MatrixCoefficients' for profile 'matroska v2' in Colour at 391
ERR201: Invalid 'TransferCharacteristics' for profile 'matroska v2' in Colour at 391
ERR201: Invalid 'Primaries' for profile 'matroska v2' in Colour at 391
ERR312: CueEntry Track #1 and timecode g80249104967 ms not found
ERR312: CueEntry Track #1 and timecode g80249119965 ms not found
ERR312: CueEntry Track #1 and timecode g80249164966 ms not found
ERR312: CueEntry Track #1 and timecode g80249194964 ms not found
ERR312: CueEntry Track #1 and timecode g80249209963 ms not found
file "D:\20230331_091006.adtfdat_export_Video.mkv"
created with GStreamer matroskamux version 1.22.2 / GStreamer Matroska muxer
```
mkvtoolnix shows, that the cues and the referenced clusters have the same timecode, but the first SimpleBlock of the Cluster has sometimes a timecode that differs by 1*timecodescale from the timecode of the cluster (see e.g. timestamps in lines 43 vs. 44 or 195 vs 197 in mkvinfo below)
[mkvinfo_full.txt](/uploads/616845ad825159636fd1a5c7b25652bb/mkvinfo_full.txt)
I am totally new to gstreamer and video processing, and may be wrong in my conclusion, but dig down the code a little and I suppose the core issues is matroskamux does a [rounding of the time codes for the *Blocks*](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-good/gst/matroska/matroska-mux.c#L4214), that in some cases (maybe related with inappropriate timecodescale), leads to +-1 values. Whereas the timecode in the *Clusters* is [taken (quite) straight from the buffer_timestamp](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-good/gst/matroska/matroska-mux.c#L4158)
Unfortunately, the app does not allow me to configure the properties of matroskamux and try another timecodescale, so my conclusion is until now mainly based on "theoretical analysis".https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2520gst-python: segment fault for import gst in python on macOS2023-04-25T09:48:03ZRobin Qugst-python: segment fault for import gst in python on macOS### 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
<!-- What actually happened -->
#### Setup
- **Operating System:** OXS 13.3.1
- **Device:** Computer
- **GStreamer Version:** 1.22.2
- **Command line:** See below
```
meson --prefix=${CONDA_PREFIX} \
--buildtype=release \
--libdir=$CONDA_PREFIX/lib \
-Dexamples=disabled \
-Dtests=disabled \
--wrap-mode=nofallback \
..
```
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. open terminal
2. type `python -c 'import gi; gi.require_version("Gst", "1.0"); from gi.repository import Gst'`
### How reproducible is the bug?
Always
### Screenshots if relevant
None
### Solutions you have tried
switch to different python version before rebuild, but the problem persists.
### Related non-duplicate issues
### Additional Information
* meson log output: [meson_output.txt](/uploads/cdaaf5cd4e50f3f00a4d4dc541ab7832/meson_output.txt)
* Segmentfault logs: [segmentfault.txt](/uploads/07c6bc73657b4ae6f24a92f7a3fbf889/segmentfault.txt)https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/341How can I make dynamic textoverlay on a video feed quicker when the encoding ...2023-04-25T18:17:54Znabil riseHow can I make dynamic textoverlay on a video feed quicker when the encoding and decoding is done by GPU?I got a pipeline like the following:
> rtspsrc ! queue ! rtph264depay ! h264parse ! vaapidecodebin ! queue flush-on-eos=TRUE ! videorate ! video/x-raw,framerate=5/1 ! textoverlay name=textsrc ! videorate ! vaapih264enc ! rtph264pay
Thi...I got a pipeline like the following:
> rtspsrc ! queue ! rtph264depay ! h264parse ! vaapidecodebin ! queue flush-on-eos=TRUE ! videorate ! video/x-raw,framerate=5/1 ! textoverlay name=textsrc ! videorate ! vaapih264enc ! rtph264pay
This is being run on an intel GPU with iHD as a driver, and it's working well to make textoverlay on video and stream it back, the problem is that when I have the textoverlay active it causes delays, after some research I found [This](https://gstreamer.freedesktop.org/documentation/additional/design/subtitle-overlays.html?gi-language=c) which explains a potential issue, encoding/decoding being done on GPU and the textoverlay on CPU (using pango) causes the problem.
I also found about vaapioverlay, which is unlike what it's name indicates is more a video mixer.
I am not sure if it's possible to use vaapioverlay to get the desired result.
Is it possible to get a video feed with just textoverlay on it ? the idea is to overlay it on video stream using vaapioverlay.
Is there a way I can make the textoverlay faster that I am missing?
I didn't find a vaapitextoverlay but is there something close to this?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2516gl: Propagation of GL display/context not working correctly if using GL eleme...2024-02-09T14:41:21Zmarcbullgl: Propagation of GL display/context not working correctly if using GL elements outside and inside playsinkThe following pipeline does not work with 1.22 / git main (and deadlocks for other reasons with 1.20):
```shell
$ gst-launch-1.0 videotestsrc ! glvideomixer ! sink.video_sink playsink name=sink video-sink="glimagesink"
```
What happe...The following pipeline does not work with 1.22 / git main (and deadlocks for other reasons with 1.20):
```shell
$ gst-launch-1.0 videotestsrc ! glvideomixer ! sink.video_sink playsink name=sink video-sink="glimagesink"
```
What happens here is that outside and inside playsink a different GL display and context are used, and both contexts are not sharing with each other.
This then causes no window to show up, rendering to fail and for each frame errors as follows to be printed
```
0:00:00.103075402 3920565 0x7f0664002180 ERROR gldebug gstgldebug.c:306:_gst_gl_debug_callback:<glcontextegl1> high: GL error from API id:2, GL_INVALID_FRAMEBUFFER_OPERATION in glClear(incomplete framebuffer)
0:00:00.103086683 3920565 0x7f0664002180 ERROR gldebug gstgldebug.c:306:_gst_gl_debug_callback:<glcontextegl1> high: GL error from API id:2, GL_INVALID_FRAMEBUFFER_OPERATION in glDrawElements
0:00:00.136571386 3920565 0x7f0664002180 ERROR gldebug gstgldebug.c:306:_gst_gl_debug_callback:<glcontextegl1> high: GL error from API id:2, GL_INVALID_FRAMEBUFFER_OPERATION in glClear(incomplete framebuffer)
0:00:00.136615900 3920565 0x7f0664002180 ERROR gldebug gstgldebug.c:306:_gst_gl_debug_callback:<glcontextegl1> high: GL error from API id:2, GL_INVALID_FRAMEBUFFER_OPERATION in glDrawElements
0:00:00.169940583 3920565 0x7f0664002180 ERROR gldebug gstgldebug.c:306:_gst_gl_debug_callback:<glcontextegl1> high: GL error from API id:2, GL_INVALID_FRAMEBUFFER_OPERATION in glClear(incomplete framebuffer)
```
Original issue description below
----
I have a problem with the gtk4paintablesink and OpenGL playback, when using a video-stream-combiner with gst_play. I used a modified Glide to produce this problem. You can find it here: https://github.com/marcbull/glide/tree/video-compositor
The repository contains two Dot files of the pipeline and logs for both cases.
Without a video-stream-combiner property set, the gtk4paintablesink shows the expected video frames. If I assign a glvideomixer to the video-stream-combiner property, the view stays black, but you can hear audio playback.
I experienced this on Linux and on macOS.
Glide was started like this:
```
GST_DEBUG_DUMP_DOT_DIR=/tmp/gst GST_DEBUG="gtk4paintablesink:7" cargo r -- -i -c SampleVideo_1280x720_1mb.mp4 &| tee /tmp/glide.log
```
I added an command line argument to enable the use of the glvideomixer:
```
-c, --compositor Use glvideomixer as video-stream-combiner in the pipeline
```
The issue also occurs with the playbin3 element. It can be enabled with the following command line argument:
```
-p, --playbin3 Use playbin3 instead of playbin2
```
Is this a problem in the gtk4paintablesink or another component?
Thanks for your help.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2515nvd3d11h264enc: is there a way to limit the bitrate?2023-04-25T01:20:53ZMaurizio Buratonvd3d11h264enc: is there a way to limit the bitrate?using nvd3d11h264enc here to stream rtmp over a wowza server that has bitrate limitation (1536 kbits)
nvd3d11h264enc bitrate=1200 preset=hq rate-control=2 gop-size=60 repeat-sequence-header=true
is there a way to prevent the bitrate fr...using nvd3d11h264enc here to stream rtmp over a wowza server that has bitrate limitation (1536 kbits)
nvd3d11h264enc bitrate=1200 preset=hq rate-control=2 gop-size=60 repeat-sequence-header=true
is there a way to prevent the bitrate from exceeding the 1536 kbits limit?
actually depending on the encoded video content the bitrate goes up over 2000 kbits and the rtmp server close the connectionhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2513Streaming with parameters in rtsp link2023-04-25T19:18:53ZJaquesMStreaming with parameters in rtsp linkWhen I try this command:
`gst-launch-1.0 -v rtspsrc location=rtsp://admin:passwd@192.168.15.6:554/cam/realmonitor?channel=1&subtype=0 short-header=TRUE ! rtph264depay ! h264parse ! kvssink stream-name=YourStreamName storage-size=128 acc...When I try this command:
`gst-launch-1.0 -v rtspsrc location=rtsp://admin:passwd@192.168.15.6:554/cam/realmonitor?channel=1&subtype=0 short-header=TRUE ! rtph264depay ! h264parse ! kvssink stream-name=YourStreamName storage-size=128 access-key="YourAccessKey" secret-key="YourSecretKey`
I get this:
![WhatsApp_Image_2023-04-19_at_21.33.44](/uploads/b1a469f432b60eb07db1718c43e4e110/WhatsApp_Image_2023-04-19_at_21.33.44.jpeg)
As you can see, the last paramether of the link, after the & symbol, is being ignored.
We currently use an IP camera from a brazilian manufacturer that only accepts rtsp link in this format. Because of that, we are not being able to stream it to Kinesis.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2512Video delay occurs in stream playback (Gstreamer1.14.5)2023-04-24T00:25:18ZFumihiro NakayamaVideo delay occurs in stream playback (Gstreamer1.14.5)Hi,please tell me
how to receive rtsp for 30fps camera stream.
Camera resolution is 1920×1080.
When the following command was executed, the video was played with more and more delays.
_ gst-launch-1.0 rtspsrc location=<URL> ! decodebin...Hi,please tell me
how to receive rtsp for 30fps camera stream.
Camera resolution is 1920×1080.
When the following command was executed, the video was played with more and more delays.
_ gst-launch-1.0 rtspsrc location=<URL> ! decodebin ! autovideosink sync=false_
I would like to know the cause of the video playback delay.
After that, adding a parameter to drop the framerate made the delay go away.
_ gst-launch-1.0 rtspsrc location=<URL> ! decodebin ! videorate ! video/x-raw,framerate=10/1 ! autovideosink sync=false_
Is it possible to play video at 30fps?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2511sdp: media to caps generates non-spec compliant OPUS rtpmap2023-04-21T10:27:16ZPhilippe Normandsdp: media to caps generates non-spec compliant OPUS rtpmapAccording to https://www.rfc-editor.org/rfc/rfc7587.html#section-7 the media subtype should be "opus", not "OPUS".According to https://www.rfc-editor.org/rfc/rfc7587.html#section-7 the media subtype should be "opus", not "OPUS".https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2510v4l2object: there have some errors in aligning width/height in the case of st...2023-05-06T03:22:53Zshengqi2022v4l2object: there have some errors in aligning width/height in the case of stepwise frame sizes1. there are errors about print log in hint1. this shoule be max height.
```
2. when the w, maxw and step_w(or h, maxh and step_h)size got form dirver
is not meet the condition of gst_value_set_int_range_step,the step_range will
got no...1. there are errors about print log in hint1. this shoule be max height.
```
2. when the w, maxw and step_w(or h, maxh and step_h)size got form dirver
is not meet the condition of gst_value_set_int_range_step,the step_range will
got not correct value.
For example, we got size as bellow, and these size are not meet the conditions
in gst_value_set_int_range_step, and then we got error width and height as caps
video/x-vp9, width=(int)[ 0, 0 ], height=(int)[ 0, 0 ].
And I think different platform have different size alignment rules.
Gstreamer should not align again, and should set min_width/height
and max_width/height to caps directly
>
gst_v4l2_object_probe_caps_for_format:<v4l2mtkvpudec0:sink> Enumerating frame sizes for VP90
gst_v4l2_object_probe_caps_for_format:<v4l2mtkvpudec0:sink> we have stepwise frame sizes:
gst_v4l2_object_probe_caps_for_format:<v4l2mtkvpudec0:sink> min width: 16
gst_v4l2_object_probe_caps_for_format:<v4l2mtkvpudec0:sink> min height: 16
gst_v4l2_object_probe_caps_for_format:<v4l2mtkvpudec0:sink> max width: 4096
gst_v4l2_object_probe_caps_for_format:<v4l2mtkvpudec0:sink> min height: 2304
gst_v4l2_object_probe_caps_for_format:<v4l2mtkvpudec0:sink> step width: 64
gst_v4l2_object_probe_caps_for_format:<v4l2mtkvpudec0:sink> step height: 64
>
```
the relate code is in gst_v4l2_object_probe_caps_for_format as bellow, and I didn't modify anything.
```
} else if (size.type == V4L2_FRMSIZE_TYPE_STEPWISE) {
guint32 maxw, maxh, step_w, step_h;
GST_DEBUG_OBJECT (v4l2object->dbg_obj, "we have stepwise frame sizes:");
GST_DEBUG_OBJECT (v4l2object->dbg_obj, "min width: %d",
size.stepwise.min_width);
GST_DEBUG_OBJECT (v4l2object->dbg_obj, "min height: %d",
size.stepwise.min_height);
GST_DEBUG_OBJECT (v4l2object->dbg_obj, "max width: %d",
size.stepwise.max_width);
GST_DEBUG_OBJECT (v4l2object->dbg_obj, "min height: %d", //hint1
size.stepwise.max_height);
GST_DEBUG_OBJECT (v4l2object->dbg_obj, "step width: %d",
size.stepwise.step_width);
GST_DEBUG_OBJECT (v4l2object->dbg_obj, "step height: %d",
size.stepwise.step_height);
w = MAX (size.stepwise.min_width, 1);
h = MAX (size.stepwise.min_height, 1);
maxw = MIN (size.stepwise.max_width, G_MAXINT);
maxh = MIN (size.stepwise.max_height, G_MAXINT);
step_w = MAX (size.stepwise.step_width, 1);
step_h = MAX (size.stepwise.step_height, 1);
/* FIXME: check for sanity and that min/max are multiples of the steps */
/* we only query details for the max width/height since it's likely the
* most restricted if there are any resolution-dependent restrictions */
tmp = gst_v4l2_object_probe_caps_for_format_and_size (v4l2object,
pixelformat, maxw, maxh, template);
if (tmp) {
GValue step_range = G_VALUE_INIT;
g_value_init (&step_range, GST_TYPE_INT_RANGE);
gst_value_set_int_range_step (&step_range, w, maxw, step_w);
gst_structure_set_value (tmp, "width", &step_range);
gst_value_set_int_range_step (&step_range, h, maxh, step_h);
gst_structure_take_value (tmp, "height", &step_range);
/* no point using the results list here, since there's only one struct */
gst_v4l2_object_update_and_append (v4l2object, pixelformat, ret, tmp);
}
} else if (size.type == V4L2_FRMSIZE_TYPE_CONTINUOUS) {
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2509rtpjitterbuffer/h264parse timestamp issue (regression)2023-04-20T11:16:15ZBugzilla Migration Userrtpjitterbuffer/h264parse timestamp issue (regression)## Submitted by Nicola `@drakkan`
**[Link to original bug (#788777)](https://bugzilla.gnome.org/show_bug.cgi?id=788777)**
## Description
Created attachment 361248
logs that show the issue
In a pipeline like this:
rtspsrc...## Submitted by Nicola `@drakkan`
**[Link to original bug (#788777)](https://bugzilla.gnome.org/show_bug.cgi?id=788777)**
## Description
Created attachment 361248
logs that show the issue
In a pipeline like this:
rtspsrc ! rtph264depay ! h264parse ! ...
using rtsp over tcp can happen that rtspsrc outputs buffers with the same timestamp, when this happen h264parse outputs buffer with invalid timestamps.
Please take a look at the attached logs, you can see:
rtpjitterbuffer.c:916:rtp_jitter_buffer_calculate_pts:[00m backwards timestamps, using previous time
so different buffers with pts 0:15:23.020362975 are sended.
Not sure how to handle this case, we need to change rtpjitterbuffer or h264parse?
This problem seems to happen only using rtsp over tcp, I'm unable to reproduce it using rtsp over udp.
**Attachment 361248**, "logs that show the issue":
[log.txt](/uploads/beac41b97709f74dfb724f589e3b11e4/log.txt)
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2508av1parse: split master frame buffer into sub frame buffers or merge sub frame...2024-01-22T07:42:05ZJeri Liav1parse: split master frame buffer into sub frame buffers or merge sub frame buffers into one master frame bufferWith this change [av1parse: Fix several issues and correct the PTS](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3182#note_1591585),
av1 parser split master frame buffer into sub frame buffers and send to video de...With this change [av1parse: Fix several issues and correct the PTS](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3182#note_1591585),
av1 parser split master frame buffer into sub frame buffers and send to video decoder:
```
frame 0 PTS 0:00:00.000000000, DTS 99:99:99.999999999 duration 0:00:00.016683333 size 141165 flags 0x640
frame 1 PTS 99:99:99.999999999, DTS 99:99:99.999999999 duration 99:99:99.999999999 size 128133 flags 0x2220
frame 2 PTS 99:99:99.999999999, DTS 99:99:99.999999999 duration 99:99:99.999999999 size 25063 flags 0x6220
frame 3 PTS 99:99:99.999999999, DTS 99:99:99.999999999 duration 99:99:99.999999999 size 12399 flags 0x6220
frame 4 PTS 99:99:99.999999999, DTS 99:99:99.999999999 duration 99:99:99.999999999 size 6139 flags 0x6220
frame 5 PTS 0:00:00.017000000, DTS 99:99:99.999999999 duration 0:00:00.016683333 size 2451 flags 0x6200
frame 6 PTS 0:00:00.034000000, DTS 99:99:99.999999999 duration 0:00:00.016683333 size 5 flags 0x2200
frame 7 PTS 0:00:00.050000000, DTS 99:99:99.999999999 duration 0:00:00.016683333 size 2647 flags 0x2200
```
Frame 1/2/3/4 are all for decode only (for flag 0x**20**) but not dqbuf from v4l2 video decoder, then frame 1/2/3/4 could not be deleted from video decoder list, this would due to a warning log in v4l2videodec: `Too old frames, bug in decoder -- please file a bug`
So with this change, we have to modify v4l2videodec.
Why split master frame buffer into sub frame buffers but not merge sub frame 1/2/3/4/5 into one master frame buffer, then the input frame number is equal to the output frame number of v4l2videodec ?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2507playbin3/decodebin3: Pipeline hang for streams that parser cannot parse one t...2023-07-17T08:45:12ZQi Houplaybin3/decodebin3: Pipeline hang for streams that parser cannot parse one trackIn playbin3 framework, multiqueue1 is connected after parsebin and linked by decodebin3.
For streams that both have audio and video, all video frames are dropped by h265 parser in parsebin.
Then multiqueue only receives audio date with...In playbin3 framework, multiqueue1 is connected after parsebin and linked by decodebin3.
For streams that both have audio and video, all video frames are dropped by h265 parser in parsebin.
Then multiqueue only receives audio date with interleave 0. This also means that audio can continuously send data to multiqueue until fiiled. The pipeline is bound to hang.
This works for playbin2, as multiqueue is connected before parser. For users that not aware the playbin upgrading, they may regards this as regression.