GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-10-11T09:54:32Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1677Unable to play dash with ttml subtitles2021-10-11T09:54:32ZShlomi AmitUnable to play dash with ttml subtitlesHi.
I'm trying to play a dash mpd file which contains subtitles, as a first step, just trying to get those subtitles into fakesink for now:
(Using gstreamer 1.18.4 on Ubuntu)
```
gst-launch-1.0 playbin uri=https://livesim.dashif.org/dash...Hi.
I'm trying to play a dash mpd file which contains subtitles, as a first step, just trying to get those subtitles into fakesink for now:
(Using gstreamer 1.18.4 on Ubuntu)
```
gst-launch-1.0 playbin uri=https://livesim.dashif.org/dash/vod/testpic_2s/multi_subs.mpd \
text-sink="fakesink dump=true"
```
gstreamer logs the following:
```
WARNING: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: No decoder available for type 'application/ttml+xml'.
```
I've made sure to install pango & cairo and rebuild gstreamer, and ttmlparse and ttmlrender can be found:
```
#gst-inspect-1.0 | grep ttml
typefindfunctions: application/ttml+xml: ttml+xml
ttmlsubs: ttmlparse: TTML subtitle parser
ttmlsubs: ttmlrender: TTML subtitle renderer
```
I've also googled about this ttml plugin, and I believe it even supposed to work with gst-play, but it also doesn't work:
```
gst-play-1.0 https://livesim.dashif.org/dash/vod/testpic_2s/multi_subs.mpd
Press 'k' to see a list of keyboard shortcuts.
Now playing https://livesim.dashif.org/dash/vod/testpic_2s/multi_subs.mpd
WARNING No decoder available for type 'application/ttml+xml'.
WARNING debug information: ../subprojects/gst-plugins-base/gst/playback/gsturidecodebin.c(957): unknown_type_cb (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0
WARNING No decoder available for type 'application/ttml+xml'.
WARNING debug information: ../subprojects/gst-plugins-base/gst/playback/gsturidecodebin.c(957): unknown_type_cb (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0
WARNING No decoder available for type 'application/ttml+xml'.
WARNING debug information: ../subprojects/gst-plugins-base/gst/playback/gsturidecodebin.c(957): unknown_type_cb (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0
WARNING No decoder available for type 'application/ttml+xml'.
WARNING debug information: ../subprojects/gst-plugins-base/gst/playback/gsturidecodebin.c(957): unknown_type_cb (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0
WARNING No decoder available for type 'application/ttml+xml'.
WARNING debug information: ../subprojects/gst-plugins-base/gst/playback/gsturidecodebin.c(957): unknown_type_cb (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0
```
(Video & Audio are played fine).
I've also tried with playbin3, and this case the pipeline is not even linked and nothing is being played at all
```
USE_PLAYBIN3=1 gst-play-1.0 https://livesim.dashif.org/dash/vod/testpic_2s/multi_subs.mpd
Press 'k' to see a list of keyboard shortcuts.
Now playing https://livesim.dashif.org/dash/vod/testpic_2s/multi_subs.mpd
ERROR Your GStreamer installation is missing a plug-in. for https://livesim.dashif.org/dash/vod/testpic_2s/multi_subs.mpd
ERROR debug information: ../subprojects/gst-plugins-base/gst/playback/gstparsebin.c(3479): gst_parse_bin_expose (): /GstPlayBin3:playbin/GstURIDecodeBin3:uridecodebin3-0/GstDecodebin3:decodebin3-0/GstParseBin:parsebin1:
no suitable plugins found:
Missing parser: application/ttml+xml (application/ttml+xml)
Reached end of play list.
```
Kindly help me, I wonder if something is messed up with my build and I might need additional plugins (e.g. something else wasn't built due to missing packages) to get it to work.
I've also tried the Windows installation, same issue, and in addition, windows build doesn't seem to have the ttmlparse and ttmldump plugins at all.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1676Setting next uri for gap-less playback using playbin causes freeze with track...2021-10-11T07:22:46ZJonas KvingeSetting next uri for gap-less playback using playbin causes freeze with tracker audio (MOD/S3M/XM/IT)Transitioning from a tracker audio file (MOD/S3M/XM/IT) to any other file makes gstreamer freeze. All other formats work fine.
I made a minimal example code from the gstreamer code used in Strawberry (https://github.com/strawberrymusicp...Transitioning from a tracker audio file (MOD/S3M/XM/IT) to any other file makes gstreamer freeze. All other formats work fine.
I made a minimal example code from the gstreamer code used in Strawberry (https://github.com/strawberrymusicplayer/strawberry) to reproduce the issue.
[gstenginepipelineplaybin.h](/uploads/747c39a89b13f717df147621bb6dad53/gstenginepipelineplaybin.h)
[gstenginepipelineplaybin.cpp](/uploads/4ccda90bc551832c19e41b628d0074c0/gstenginepipelineplaybin.cpp)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1675tsdemux: demux ts file failed2022-04-27T13:38:01ZAlanKing95tsdemux: demux ts file failed[4K-UHD-_3840x2160__.ts](/uploads/6eb8bba50cb5c20bdc1b8a9bd68dca30/4K-UHD-_3840x2160__.ts)
Here is some information about this issue:
gst_ts_demux_get_duration:<tsdemux1> No active program yet, can't provide duration
push_event:<tsdem...[4K-UHD-_3840x2160__.ts](/uploads/6eb8bba50cb5c20bdc1b8a9bd68dca30/4K-UHD-_3840x2160__.ts)
Here is some information about this issue:
gst_ts_demux_get_duration:<tsdemux1> No active program yet, can't provide duration
push_event:<tsdemux1> Ignoring segment event (recreated later)
gst_ts_demux_program_started Current program -1, new program 1 requested program -1
gst_ts_demux_program_started:<tsdemux1> error: This stream contains no valid or supported streams.
gst_ts_demux_program_started:<tsdemux1> error: activating program but got no pads
gst_ts_demux_can_remove_program Attempting to remove current program, delaying until new program gets activated
gst_ts_demux_program_started Current program -1, new program 1 requested program -1
gst_ts_demux_program_started:<tsdemux1> Draining previous program
The file which is attached can be played by ffplay or VLC player, but cannot played by gst-launch-1.0 playbin.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/766giosrc: read-growing-file test sometimes crashes after g_object_ref: assertio...2022-11-10T09:21:07ZTim-Philipp Müllertim@centricular.comgiosrc: read-growing-file test sometimes crashes after g_object_ref: assertion 'G_IS_OBJECT (object)' failedStacktrace from CI for `` test crash below.
Crashes in: `gst_base_src_query (pad=<optimized out>, parent=0x1ecc1f0, query=0x1c5a540) at ../subprojects/gstreamer/libs/gst/base/gstbasesrc.c:1397`
which is:
```
1397 if (bclass->query)
1...Stacktrace from CI for `` test crash below.
Crashes in: `gst_base_src_query (pad=<optimized out>, parent=0x1ecc1f0, query=0x1c5a540) at ../subprojects/gstreamer/libs/gst/base/gstbasesrc.c:1397`
which is:
```
1397 if (bclass->query)
1398 bclass->query (...)
```
Probably caused by a refcount bug somewhere:
```
Trying to dispose element giosrc, but it is in PLAYING instead of the NULL state.
```
and
```
g_object_ref: assertion 'G_IS_OBJECT (object)' failed
```
Full log: [giosrc.log](/uploads/a4456e574c10c5c3af35a4a0079991ac/giosrc.log)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/765v4l2src:output truncated after changing capture size2022-03-03T14:07:11ZDamian Hobson-Garciadamian@hobsong.comv4l2src:output truncated after changing capture sizeWhen doing some testing with the vivid driver I noticed that if the v4l2src capture size is reduced
from the default, it can never be properly restored to its original size. This behaviour carries
across processes, so this problem exist...When doing some testing with the vivid driver I noticed that if the v4l2src capture size is reduced
from the default, it can never be properly restored to its original size. This behaviour carries
across processes, so this problem exists even when running `gst-launch` multiple times.
This only happens for devices that support the crop / compose API.
To reproduce:
```bash
$ sudo modprobe vivid n_devs=1 input_types=0x3
```
```
$ gst-launch-1.0 v4l2src ! video/x-raw, width=640, width=480 ! ximagesink
```
Output scaled down to 640x480 as expected
```
$ gst-launch-1.0 v4l2src ! ximagesink
```
Window size is 1280x720, but the image data is still 640x480 (right and bottom of image is black)
```
$ gst-launch-1.0 v4l2src ! video/x-raw, width=1280, width=720 ! ximagesink
```
Even explicitly setting the output size makes no difference. Image is still 640x480.
It seems like the problem is that the composition selection rectangle is reduced to 640x480 by the vivid driver, but is not
increased again when a larger capture buffer size is requested. This looks like valid driver behaviour according
to the spec, which doesn't require that the compose rectangle is reset on S_FMT.
I think that v4l2src would need to reset the compose rectangle to the default value when it does the format setting to avoid this
problem.
Does this sound correct?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1674webrtcbin: 4K h264 problems2021-10-07T09:07:20ZDavid Elywebrtcbin: 4K h264 problemsWe are having issues sending a 4K, H264 stream through WebRTC on Windows (3840x2160, 30hz, 8Mbs). Playback of the video stream stutters or may get stuck. Our application captures the desktop, encodes it to H264 and streams it to Chrome o...We are having issues sending a 4K, H264 stream through WebRTC on Windows (3840x2160, 30hz, 8Mbs). Playback of the video stream stutters or may get stuck. Our application captures the desktop, encodes it to H264 and streams it to Chrome or another of our applications, both of which exhibit the problem. This issue only happens on Windows, CentOS7 and Ubuntu20.04 work (using the same hardware). Lower resolutions (1080P) work across all 3 operations systems. Chrome's webrtc-internals shows the packetsLost or freezeCount increase when the stutter occurs.
Points of note:
* Our GStreamer version is 1.19.1.
* This was reproduced with two PCs on a local network. The problem won't occur if the sender and receiver are on the same computer.
* We did some Wireshark captures on the sending PC and it showed some packets aren't making it to the NIC. It appears occasionally a NAL is being truncated.
* In attempt reduced the scope of the problem, I reproduced the issue in one of the gst-examples (webrtc\sendonly\webrtc-unidirectional-h264.c) by modifying the pipeline to stream from a file (I only tested this on Windows). The file is 30hz, 4K H264 video with a birate of 8 Mbs. The pipeline looks like this
* *filesrc location=C:\\tmp\\test.mkv ! queue ! matroskademux ! queue ! h264parse ! video/x-h264,alignment=au,stream-format=byte-stream !
rtph264pay config-interval=1 aggregate-mode ! application/x-rtp,media=video,encoding-name=H264,encoding-payload=96 !
webrtcbin*
* Reducing the bitrate alleviates the problem.
* For reference this is our application's pipeline on Windows
* *dxgiscreencapsrc cursor=true ! video/x-raw,format=BGRA,framerate=30/1 ! videoconvert ! queue ! video/x-raw,format=I420 !
nvh264enc preset=low-latency-hp bitrate=8192 rc-mode=cbr gop-size=90 zerolatency=true !
video/x-h264,framerate=30/1,alignment=au,stream-format=byte-stream ! rtph264pay ! application/x-rtp,media=video,encoding-name=H264,payload=96 ! webrtcbin*
As I was able to reproduce the issue in the modified example it points to webrtcbin as the problem.
Any help/suggestions to resolve the problem would be greatly appreciated.
Thanks
Davidhttps://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/348monorepo: cerbero is feching submodules by default and fetch gst-integration-...2021-10-06T19:41:35ZStéphane Cerveauscerveau@igalia.commonorepo: cerbero is feching submodules by default and fetch gst-integration-testsuites mediasAs gst-integration-testsuites medias is a large repository, it takes a lot of time to fetch the gstreamer-1.0 repository for the first time.
These medias are not necessary to build gstreamer-1.0.As gst-integration-testsuites medias is a large repository, it takes a lot of time to fetch the gstreamer-1.0 repository for the first time.
These medias are not necessary to build gstreamer-1.0.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/764msdk: vp9 encode regression2022-06-06T05:39:33ZU. Artie Eoffmsdk: vp9 encode regressionUnable to encode vp9 on Intel ICL+ since gst-plugins-bad!2523.
```
gst-launch-1.0 -vf videotestsrc num-buffers=150 \
! video/x-raw,format=NV12 \
! msdkvp9enc rate-control=cqp hardware=true gop-size=30 \
qpi=28 qpp=28 qpb=28 target-...Unable to encode vp9 on Intel ICL+ since gst-plugins-bad!2523.
```
gst-launch-1.0 -vf videotestsrc num-buffers=150 \
! video/x-raw,format=NV12 \
! msdkvp9enc rate-control=cqp hardware=true gop-size=30 \
qpi=28 qpp=28 qpb=28 target-usage=4 num-slices=1 \
! video/x-vp9 ! vp9parse \
! matroskamux ! filesink location=output.webm
...
0:00:00.027971857 25341 0x55997fca2de0 ERROR msdkenc gstmsdkenc.c:766:gst_msdkenc_init_encoder:<msdkvp9enc0> Video Encode Query failed (undefined behavior)
...
```Haihao XiangHaihao Xianghttps://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/347Android porting issue2021-10-06T04:54:56ZShiv shankarAndroid porting issuePorting gsteamer custom plugins into android with logs and we see following error. where should i include android log library in configuration file for cerbero build.
**error:**
_/home/Documents/project/Gst_Cerbero/build/sources/andro...Porting gsteamer custom plugins into android with logs and we see following error. where should i include android log library in configuration file for cerbero build.
**error:**
_/home/Documents/project/Gst_Cerbero/build/sources/android_universal/armv7/gst/streamer/streamer_conf.c:418: error: undefined reference to '__android_log_print'
/home/Documents/project/Gst_Cerbero/build/sources/android_universal/armv7/streamer/gst/streamer/streamer_conf.c:233: error: undefined reference to '__android_log_print'
/home/Documents/project/Gst_Cerbero/build/sources/android_universal/armv7/streamer/gst/streamer/streamer_subplugin.c:118: error: undefined reference to '__android_log_print'
/home/Documents/project/Gst_Cerbero/build/sources/android_universal/armv7/streamer/gst/streamer/streamer_subplugin.c:127: error: undefined reference to '__android_log_print'
clang++: error: linker command failed with exit code 1 (use -v to see invocation)_
https://stackoverflow.com/questions/4455941/undefined-reference-to-android-log-printhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/763pixman/fontconfig subproject do not build correcty with monorepo infra on Ubu...2023-05-08T08:12:18ZStéphane Cerveauscerveau@igalia.compixman/fontconfig subproject do not build correcty with monorepo infra on Ubuntu Bionic 32 bits### Describe your issue
fontconfig and pixman are not correctly configured when used subprojects of the GStreamer build on Ubuntu Bionic 32 bits.
```
ninja: Entering directory `build_i386/'
ninja: error: 'subprojects/fontconfig/fc-case/...### Describe your issue
fontconfig and pixman are not correctly configured when used subprojects of the GStreamer build on Ubuntu Bionic 32 bits.
```
ninja: Entering directory `build_i386/'
ninja: error: 'subprojects/fontconfig/fc-case/fccase.h', needed by 'subprojects/fontconfig/src/libfontconfig.so.1.12.0.p/fcatomic.c.o', missing and no known rule to make it
```
After installing libfontconfig-dev
```Ubuntu
pixman : YES 3 warnings
pycairo : YES 2 warnings
pygobject : YES 4 warnings
sqlite3 : YES
sysprof : YES 1 warnings
tinyalsa : NO
Neither a subproject directory nor a tinyalsa.wrap file was found.
Found ninja-1.8.2 at /usr/bin/ninja
root@272c0b4623f3:~/DEV/COMMUNITY/GSTREAMER/gstreamer# ninja -C build_i386/
ninja: Entering directory `build_i386/'
ninja: error: 'subprojects/pixman/pixman/libpixman-mmx.a.p/pixman-mmx.c.o', needed by 'subprojects/pixman/pixman/libpixman-1.so.0.40.1', missing and no known rule to make it
```
I tried the same configure line:
```
$ meson build_i386 -Dugly=disabled -Dgood=disabled -Dges=disabled -Dlibav=disabled
```
with gst-build without any problem.
#### Expected Behavior
To not miss any target in the ninja build.
#### Observed Behavior
Missing subprojects
#### Setup
- **Operating System:** Ubuntu Bionic 32 bits
- **Device:** Computer (docker)
- **GStreamer Version:** 1.19.3
- **Command line:** meson build_i386 -Dugly=disabled -Dgood=disabled -Dges=disabled -Dlibav=disabled
### Steps to reproduce the bug
1. open terminal
2. clone gstreamer in a docker image with the bare necessity (build-essential/python3/flex/bison/ninja/meson)
### How reproducible is the bug?
Always
### Screenshots if relevant
### Solutions you have tried
### Related non-duplicate issues
### Additional Information
[configure_pixman_failing_gstreamer.log](/uploads/0fdc84a8935fef8a452c5a893c189636/configure_pixman_failing_gstreamer.log)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1673d3d11desktopdupsrc: Screen capture on the right screen. monitor-index is bind...2021-10-13T13:13:31ZDavide Perinid3d11desktopdupsrc: Screen capture on the right screen. monitor-index is binded to a random screen.Hi all,
thank you for your awesome work here...
I'm using this command to screen capture
> ./gst-launch-1.0 d3d11desktopdupsrc monitor-index=1 ! d3d11convert ! d3d11download ! autovideosink
I have noticed that "monitor-index" does not ...Hi all,
thank you for your awesome work here...
I'm using this command to screen capture
> ./gst-launch-1.0 d3d11desktopdupsrc monitor-index=1 ! d3d11convert ! d3d11download ! autovideosink
I have noticed that "monitor-index" does not represents the real display number on Windows.
![image](/uploads/159e85b1d3c3017f96122ceac321626c/image.png)
If I rearrange the monitor order in Windows, monitor index on gstreamer does not change.
It seems that gstreamer monitor index is binded to a "random" screen,
how can I tell gstreamer to bind the screen capture to Monitor 1, monitor 2, or 3?
I think that this should be fixed if possible.
Thank you!https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/761uridecodebin3, dashdemux: Video is not playing when dashdemux switch to next ...2022-04-30T22:34:21ZShlomi Amituridecodebin3, dashdemux: Video is not playing when dashdemux switch to next period in mpdHi.
I'm using the following pipeline to play a dash where the mpd is having 2 periods. (gstreamer v1.18.4)
`gst-launch-1.0 -v uridecodebin3 uri=https://dash.akamaized.net/dash264/TestCases/5a/nomor/4.mpd name=decodebin connection-speed=...Hi.
I'm using the following pipeline to play a dash where the mpd is having 2 periods. (gstreamer v1.18.4)
`gst-launch-1.0 -v uridecodebin3 uri=https://dash.akamaized.net/dash264/TestCases/5a/nomor/4.mpd name=decodebin connection-speed=250 caps="video/x-h264;audio/x-raw" decodebin.video_0 ! h264parse config-interval=-1 ! video/x-h264,stream-format=byte-stream ! rtph264pay ! udpsink host=host.docker.internal port=55006 decodebin.audio_0 ! audioconvert ! audioresample ! opusenc ! rtpopuspay ! udpsink host=host.docker.internal port=55008`
Both audio and video are playing fine, but after ~4m when dashdemux advance to the next period, I see the following:
new audio_01 src pad is created
new video_01 src pad is created
decodebin3 automatically selects properly audio_01, but it doesn't seem to receive any collection event for video_01 stream, and it ends up with video_00 and audio_01 streams being selected, where nothing is being pushed to video_00 since it was used for the first period.
As a result, the pipeline keeps playing only audio from the new period, and no video is being played at all.
Note that if I change the pipeline to play only video, the next period is played just fine: (So the issue isn't suspected to be with the video stream itself)
`gst-launch-1.0 -v uridecodebin3 uri=https://dash.akamaized.net/dash264/TestCases/5a/nomor/4.mpd name=decodebin connection-speed=250 caps="video/x-h264;audio/x-raw" decodebin.video_0 ! h264parse config-interval=-1 ! video/x-h264,stream-format=byte-stream ! rtph264pay ! udpsink host=host.docker.internal port=55006`
Logs attached with GST_DEBUG level is set to 3,*dash*:5,*soup*:4,gstadaptivedemux:4,*decodebin*:5,*parsebin*:5
[gst-main-debug.log](/uploads/4a73452a8f72ad57072db52076c5e1ee/gst-main-debug.log)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1672[uridecodebin3][dashdemux] Video is not playing when dashdemux switch to next...2021-10-05T10:34:13ZShlomi Amit[uridecodebin3][dashdemux] Video is not playing when dashdemux switch to next period in mpdHi.
I'm using the following pipeline to play a dash where the mpd is having 2 periods. (gstreamer v1.18.4)
`gst-launch-1.0 -v uridecodebin3 uri=https://dash.akamaized.net/dash264/TestCases/5a/nomor/4.mpd name=decodebin connection-speed=...Hi.
I'm using the following pipeline to play a dash where the mpd is having 2 periods. (gstreamer v1.18.4)
`gst-launch-1.0 -v uridecodebin3 uri=https://dash.akamaized.net/dash264/TestCases/5a/nomor/4.mpd name=decodebin connection-speed=250 caps="video/x-h264;audio/x-raw" decodebin.video_0 ! h264parse config-interval=-1 ! video/x-h264,stream-format=byte-stream ! rtph264pay ! udpsink host=host.docker.internal port=55006 decodebin.audio_0 ! audioconvert ! audioresample ! opusenc ! rtpopuspay ! udpsink host=host.docker.internal port=55008`
Both audio and video are playing fine, but after ~4m when dashdemux advance to the next period, I see the following:
new audio_01 src pad is created
new video_01 src pad is created
decodebin3 automatically selects properly audio_01, but it doesn't seem to receive any collection event for video_01 stream, and it ends up with video_00 and audio_01 streams being selected, where nothing is being pushed to video_00 since it was used for the first period.
As a result, the pipeline keeps playing only audio from the new period, and no video is being played at all.
Note that if I change the pipeline to play only video, the next period is played just fine: (So the issue isn't suspected to be with the video stream itself)
`gst-launch-1.0 -v uridecodebin3 uri=https://dash.akamaized.net/dash264/TestCases/5a/nomor/4.mpd name=decodebin connection-speed=250 caps="video/x-h264;audio/x-raw" decodebin.video_0 ! h264parse config-interval=-1 ! video/x-h264,stream-format=byte-stream ! rtph264pay ! udpsink host=host.docker.internal port=55006`
Logs attached with GST_DEBUG level is set to 3,*dash*:5,*soup*:4,gstadaptivedemux:4,*decodebin*:5,*parsebin*:5
[gst-main-debug.log](/uploads/13ee8fb0d5d46b26417f023511494337/gst-main-debug.log)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1671h264parse: Fragmented mp4 causes Nal units to be wrongly parsed as Nal type ...2021-10-04T14:52:27Zpointcontrolsh264parse: Fragmented mp4 causes Nal units to be wrongly parsed as Nal type 0, ref_idc 0![movie_data_new_cat](/uploads/a302a629e5d6ef47094ae0bb5055582b/movie_data_new_cat.mp4)
Version: 1.18.5
`gst-launch-1.0 playbin uri=file://attached_file.mp4` causes
> Setting pipeline to PAUSED ...
>Pipeline is PREROLLING ...
>Got co...![movie_data_new_cat](/uploads/a302a629e5d6ef47094ae0bb5055582b/movie_data_new_cat.mp4)
Version: 1.18.5
`gst-launch-1.0 playbin uri=file://attached_file.mp4` causes
> Setting pipeline to PAUSED ...
>Pipeline is PREROLLING ...
>Got context from element 'vaapisink0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\ vaapidisplayglx0";
>ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstVaapiDecodeBin:vaapidecodebin0/GstVaapiDecode
vaapidecode0: No valid frames decoded before end of stream
>Additional debug info:
>gstvideodecoder.c(1161): gst_video_decoder_sink_event_default ():/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstVaapiDecodeBin:vaapidecodebin0/GstVaapiDecode:>vaapidecode0:
>no valid frames found
>ERROR: pipeline doesn't want to preroll.
>Setting pipeline to NULL ...
>Freeing pipeline ...
After enabling logs, it can be seen:
`h264parse gsth264parse.c:2653:gst_h264_parse_set_caps:<h264parse0> profile 4d0001
0:00:00.373674118 28356 0x7f5c541c6230 DEBUG h264parse gsth264parse.c:2661:gst_h264_parse_set_caps:<h264parse0> nal length size 4
0:00:00.373678870 28356 0x7f5c541c6230 DEBUG codecparsers_h264 gsth264parser.c:242:gst_h264_parse_nalu_header: Nal type 0, ref_idc 0
0:00:00.373683925 28356 0x7f5c541c6230 DEBUG h264parse gsth264parse.c:722:gst_h264_parse_process_nal:<h264parse0> processing nal of type 0 Unknown, size 22
0:00:00.373688216 28356 0x7f5c541c6230 DEBUG codecparsers_h264 gsth264parser.c:242:gst_h264_parse_nalu_header: Nal type 0, ref_idc 0
`
This file is played normally with ffplay, vlc, chrome, firefox. FFMPEG gives no warnings about incorrect mp4, and every Nal unit has the correct type when dumpedhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/933v4l2src output truncated after changing capture size2021-10-07T09:47:33ZDamian Hobson-Garciadamian@hobsong.comv4l2src output truncated after changing capture sizeWhen doing some testing with the vivid driver I noticed that if the v4l2src capture size is reduced
from the default, it can never be properly restored to its original size. This behaviour carries
across processes, so this problem exist...When doing some testing with the vivid driver I noticed that if the v4l2src capture size is reduced
from the default, it can never be properly restored to its original size. This behaviour carries
across processes, so this problem exists even when running `gst-launch` multiple times.
This only happens for devices that support the crop / compose API.
To reproduce:
```bash
$ sudo modprobe vivid n_devs=1 input_types=0x3
```
```
$ gst-launch-1.0 v4l2src ! video/x-raw, width=640, width=480 ! ximagesink
```
Output scaled down to 640x480 as expected
```
$ gst-launch-1.0 v4l2src ! ximagesink
```
Window size is 1280x720, but the image data is still 640x480 (right and bottom of image is black)
```
$ gst-launch-1.0 v4l2src ! video/x-raw, width=1280, width=720 ! ximagesink
```
Even explicitly setting the output size makes no difference. Image is still 640x480.
It seems like the problem is that the composition selection rectangle is reduced to 640x480 by the vivid driver, but is not
increased again when a larger capture buffer size is requested. This looks like valid driver behaviour according
to the spec, which doesn't require that the compose rectangle is reset on S_FMT.
I think that v4l2src would need to reset the compose rectangle to the default value when it does the format setting to avoid this
problem.
Does this sound correct?https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/346MSVC x86 build is shipping x86_64 pkg-config.exe binary2022-09-21T08:09:55ZSeungha Yangseungha@centricular.comMSVC x86 build is shipping x86_64 pkg-config.exe binaryso installed `pkg-config` binary is unusable for x86 packageso installed `pkg-config` binary is unusable for x86 packagehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/760sysprof dependency (via libsoup) does not build on Meson 0.59.22021-12-19T19:46:34ZMichael Farrellsysprof dependency (via libsoup) does not build on Meson 0.59.2I am unable to build gstreamer on Meson 0.59.2, because `sysprof` (included via `libsoup`) reports it cannot locate `config.h`. This is because the version of `sysprof` in the version of `libsoup` used by gstreamer [uses a deprecated Me...I am unable to build gstreamer on Meson 0.59.2, because `sysprof` (included via `libsoup`) reports it cannot locate `config.h`. This is because the version of `sysprof` in the version of `libsoup` used by gstreamer [uses a deprecated Meson macro, `meson.build_root`](https://gitlab.gnome.org/GNOME/sysprof/-/commit/d6aabaf1ff9fc24c7754feb1dcbb4f4285d4da8b).
This was fixed in sysprof a year ago: https://gitlab.gnome.org/GNOME/sysprof/-/commit/d6aabaf1ff9fc24c7754feb1dcbb4f4285d4da8b
And then this commit was included when libsoup updated: https://gitlab.gnome.org/GNOME/libsoup/-/commit/7a98acbda55edd69762bf1c4e18dc66a968e9969
However, gstreamer points at https://gitlab.gnome.org/GNOME/libsoup/-/commit/e190e70298be1186ad1a8a5dd0ac430463f76fee, [which references an old commit of sysprof](https://gitlab.gnome.org/GNOME/libsoup/-/blob/e190e70298be1186ad1a8a5dd0ac430463f76fee/subprojects/sysprof.wrap) that lacks the fix: https://gitlab.gnome.org/GNOME/sysprof/-/commit/1bb0eb7798f6a88667681229dde415ed663b1053
Please update to a current version of `libsoup`, or use a cherry-pick branch that includes this patch:
```
~/gstreamer/subprojects/sysprof$ git diff
diff --git a/meson.build b/meson.build
index 26f289f..98ea5a2 100644
--- a/meson.build
+++ b/meson.build
@@ -84,7 +84,7 @@ has_clockid = cc.has_member('struct perf_event_attr', 'clockid', prefix: '#inclu
config_h.set('HAVE_PERF_CLOCKID', has_use_clockid and has_clockid)
add_project_arguments([
- '-I' + meson.build_root(), # config.h
+ '-I' + meson.current_build_dir(), # config.h
], language: 'c')
global_c_args = [
```
Thanks!https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/93Failing to build Tutorial on iOS2021-10-06T09:17:38ZLoris PlassonFailing to build Tutorial on iOSHello, following the iOS tutorials, I'm trying to build and run the given code examples and having this error:
`clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of iOS 7 [-Wdeprecated]
ld: library...Hello, following the iOS tutorials, I'm trying to build and run the given code examples and having this error:
`clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of iOS 7 [-Wdeprecated]
ld: library not found for -lstdc++
clang: error: linker command failed with exit code 1 (use -v to see invocation)`
I'm running Xcode 13.0, any idea?
Thanks a lot!https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/758appsink: caps event error, caps still have parent2021-10-03T21:10:43ZMauriceappsink: caps event error, caps still have parentI have a pipeline where my capture source captures resizable windows. As a result, I will send arbitrary caps events down the pipe whenever a window is resized. My pipeline contains an appsink. Once the appsink receives the caps event [h...I have a pipeline where my capture source captures resizable windows. As a result, I will send arbitrary caps events down the pipe whenever a window is resized. My pipeline contains an appsink. Once the appsink receives the caps event [here](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-base/gst-libs/gst/app/gstappsink.c#L981), it first parses the caps and then tries to update some private data.
As we try to replace `last_caps` of the private data with the new caps [here](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-base/gst-libs/gst/app/gstappsink.c#L987). I get an error in the free_priv_data function of the gst_mini_object class [code](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gstreamer/gst/gstminiobject.c#L602). I presume this is because the caps stored in `priv->last_caps` still have `priv->sample` as parent.
I'm not sure but to resolve this issue it might be sufficient to move the call `gst_caps_replace (&priv->last_caps, caps);` below the other two lines, so that first the caps in the sample get replaced (which would remove the parent from `priv->last_caps` as can be seen [here](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gstreamer/gst/gstsample.c#L352)). Afterwards, `priv->last_caps` should be safe to unref.
I can create a PR for this if someone agrees that this is indeed a valid solution.
Best
Mauricehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/943[AppSink] caps event error, caps still have parent2021-10-03T19:16:26ZMaurice[AppSink] caps event error, caps still have parentI have a pipeline where my capture source captures resizable windows. As a result, I will send arbitrary caps events down the pipe whenever a window is resized. My pipeline contains an appsink. Once the appsink receives the caps event [h...I have a pipeline where my capture source captures resizable windows. As a result, I will send arbitrary caps events down the pipe whenever a window is resized. My pipeline contains an appsink. Once the appsink receives the caps event [here](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/gst-libs/gst/app/gstappsink.c#L981), it first parses the caps and then tries to update some private data.
As we try to replace `last_caps` of the private data with the new caps [here](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/gst-libs/gst/app/gstappsink.c#L987). I get an error in the free_priv_data function of the gst_mini_object class [code](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/1.18/gst/gstminiobject.c#L602). I presume this is because the caps stored in `priv->last_caps` still have `priv->sample` as parent.
I'm not sure but to resolve this issue it might be sufficient to move the call `gst_caps_replace (&priv->last_caps, caps);` below the other two lines, so that first the caps in the sample get replaced (which would remove the parent from `priv->last_caps` as can be seen [here](https://gitlab.freedesktop.org/gstreamer/gstreamer/blob/1.18.4/gst/gstsample.c#L352)). Afterwards, `priv->las_caps` should be safe to unref.
I can create a PR for this if someone agrees that this is indeed a valid solution.
Best
Maurice