GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-03-03T14:07:11Zhttps://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/762Dashsink mpd for dvbsrc is invalid as per https://conformance.dashif.org/2021-10-05T12:03:46ZvandanaDashsink mpd for dvbsrc is invalid as per https://conformance.dashif.org/The generated mpd file is not valid as per
https://conformance.dashif.org/
@dabrain34 Pls see
gstreamer pipeline:
`gst-launch-1.0 -v --gst-debug-no-color=1 dashsink name=dashsink mpd-baseurl=http://localhost/media/kls2iesj/ mpd-root-pat...The generated mpd file is not valid as per
https://conformance.dashif.org/
@dabrain34 Pls see
gstreamer pipeline:
`gst-launch-1.0 -v --gst-debug-no-color=1 dashsink name=dashsink mpd-baseurl=http://localhost/media/kls2iesj/ mpd-root-path=/var/www/localhost/media/kls2iesj mpd-filename=live.mpd target-duration=10 min-buffer-time=2 minimum-update-period=5 dynamic=true muxer=ts dvbsrc modulation=5 adapter=0 frequency=147000000 delsys=dvb-c-b ! queue ! tsdemux ! mpegvideoparse ! decodebin ! x264enc bitrate=1200 key-int-max=60 ! video/x-h264,stream-format=byte-stream,profile=main ! dashsink.video_0`
Generated mpd file is attached[live_fixed_high.mpd](/uploads/cb0d3a3a9ca126bb15e7bd938d4fde21/live_fixed_high.mpd)
Validated it here with dvb option checked
https://conformance.dashif.org/
The error logs is as follows:
```
Legend: Errors, Warnings, Information ***
Log No MPD Validation Report
1 0XLink resolving successful
2 MPD validation successful - DASH is valid!
3 Schematron validation successful - DASH is valid!
4 Warning for HbbTV-DVB DASH Validation Requirements check for DVB: Section 'MPD' - 'MPD@minimumUpdatePeriod has a lower value than 1 second.
5 ###'DVB check violated: Section E.2.1- The MPD SHALL indicate either or both of the following profiles: "urn:dvb:dash:profile:dvb-dash:2014" and "urn:hbbtv:dash:profile:isoff-live:2012"', specified profile could not be found.
6 Warning for DVB check: Section 11.1- 'All Representations that are intended to be decoded and presented by a DVB conformant Player SHOULD be such that they will be inferred to have an @profiles attribute that includes the profile name defined in clause 4.1 as well as either the one defined in 4.2.5 or the one defined in 4.2.8', found profiles: urn:mpeg:dash:profile:isoff-main:2011.
7 Warning for DVB check: Section 4.7.2- 'If the MPD is dynamic or if the MPD@availabilityStartTime is present then the MPD SHOULD countain at least one UTCTiming element with the @schemeIdUri attribute set to one of the following: urn:mpeg:dash:utc:ntp:2014, urn:mpeg:dash:utc:http-head:2014, urn:mpeg:dash:utc:http-xsdate:2014, urn:mpeg:dash:utc:http-iso:2014, urn:mpeg:dash:utc:http-ntp:2014 ', UTCTiming element could not be found in the provided MPD.
8 ###'DVB check violated: Section 4.4- For any Representation within an Adaptation Set with @contentType="video" @frameRate attribute SHALL be present if not in the AdaptationSet element', could not be found in neither Period 1 Adaptation Set 1 nor Period 1 Adaptation Set 1 Representation 1.
9 Warning for DVB check: Section 4.4- 'For any Representation within an Adaptation Set with @contentType="video" @sar attribute SHOULD be present or inherited from the Adaptation Set', could not be found in neither Period 1 Adaptation Set 1 nor Period 1 Adaptation Set 1 Representation 1.
10 ###'DVB check violated: Section 5.1.3- If (AVC video codec is) present the value of @codecs attribute SHALL be set in accordance with RFC 6381, clause 3.3', not found or not complete within Period 1 Adaptation Set 1.
11 Warning for DVB check: Section 4.4- 'For any Adaptation Sets with @contentType="video" @maxWidth attribute (or @width if all Representations have the same width) SHOULD be present', could not be found in Period 1 Adaptation Set 1.
12 Warning for DVB check: Section 4.4- 'For any Adaptation Sets with @contentType="video" @maxHeight attribute (or @height if all Representations have the same height) SHOULD be present', could not be found in Period 1 Adaptation Set 1.
13 Warning for DVB check: Section 4.4- 'For any Adaptation Sets with @contentType="video" @maxFrameRate attribute (or @frameRate if all Representations have the same frameRate) SHOULD be present', could not be found in Period 1 Adaptation Set 1.
14 Warning for DVB check: Section 4.4- 'For any Adaptation Sets with @contentType="video" @par attribute SHOULD be present', could not be found in Period 1 Adaptation Set 1.
```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
Mauricehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/932gstreamer1.0-qt5 package not available on Raspberry2021-10-06T07:05:26ZStefano Cottafavigstreamer1.0-qt5 package not available on RaspberryHi
I've tested the qmlsink example on my Linux desktop successfully, then I've crosscompiled and deployed it to my dev Raspberry Pi but can't get it to work.
Some investigation later turns out that gstreamer1.0-qt5 is not available for i...Hi
I've tested the qmlsink example on my Linux desktop successfully, then I've crosscompiled and deployed it to my dev Raspberry Pi but can't get it to work.
Some investigation later turns out that gstreamer1.0-qt5 is not available for installation on my Pi.
I'm using gstreamer1.0 (1.14.4) from Debian Buster apt.
Not sure if this is a bug or is expected?https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/931rtspsrc: pipeline struck after few minutes of streaming when `select-stream` ...2021-10-01T17:23:30ZDeep Patelrtspsrc: pipeline struck after few minutes of streaming when `select-stream` callback is enabledversion: 1.18.5
My callback function is as below:
```py
def select_stream_callback(self, rtspsrc, num, caps, udata):
media = caps.get_structure(0).get_value('media')
encoding = caps.get_structure(0).get_value('encoding-...version: 1.18.5
My callback function is as below:
```py
def select_stream_callback(self, rtspsrc, num, caps, udata):
media = caps.get_structure(0).get_value('media')
encoding = caps.get_structure(0).get_value('encoding-name')
# skip stream other than video
if media != 'video':
return False
return True
```
It is to be noted that the stream works fine if this signal is not enabled
Here is the debug logs
```log
0:04:26.241871000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.241877000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.241891000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.241901000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.241907000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.241921000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.241931000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.241962000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.241988000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.241997000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242012000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242035000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242046000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242248000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242286000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242298000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242312000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242385000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242398000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242414000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242440000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242450000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242465000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242488000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242497000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242512000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242535000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242545000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242560000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242583000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242592000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242607000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242630000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242639000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242654000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242728000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242740000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242756000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242780000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242789000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242805000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242828000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242837000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242853000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242876000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242886000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242900000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242922000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242931000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242946000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.243039000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.243052000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.243066000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
2021-10-01 17:18:14 INFO 1633108694.376356
0:04:26.533112000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533151000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533314000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.533391000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533410000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533429000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.533465000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533511000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533529000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.533558000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533567000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533585000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.533615000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533630000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533650000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.533689000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533703000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533714000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 950 on channel 0
0:04:26.533745000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533760000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533773000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.533799000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533811000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533823000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 777 on channel 0
0:04:26.673265000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.673296000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.673312000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 76 on channel 1
0:04:26.673430000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:04:28.069402000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 84 bytes RTCP
0:04:28.069475000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:04:30.960379000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:30.960410000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:30.960439000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 76 on channel 1
0:04:30.960504000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:04:32.167497000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 84 bytes RTCP
0:04:32.167569000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:04:35.578354000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:35.578386000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:35.578402000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 76 on channel 1
0:04:35.578450000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:04:35.716265000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 84 bytes RTCP
0:04:35.716330000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:04:39.466840000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:39.466873000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:39.466903000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 56 on channel 1
0:04:39.466959000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:04:40.946154000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 60 bytes RTCP
0:04:40.946293000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:04:44.898856000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:44.898895000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:44.898917000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 56 on channel 1
0:04:44.898968000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:04:45.429008000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 60 bytes RTCP
0:04:45.429091000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:04:49.466056000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 60 bytes RTCP
0:04:49.466136000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:04:49.743003000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:49.743039000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:49.743061000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 56 on channel 1
0:04:49.743113000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:04:53.399676000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 60 bytes RTCP
0:04:53.399758000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:04:55.208214000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:55.208252000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:55.208275000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 56 on channel 1
0:04:55.208325000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:04:57.821064000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 60 bytes RTCP
0:04:57.821148000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:05:00.858707000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:05:00.858746000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:05:00.858769000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 56 on channel 1
0:05:00.858923000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:05:03.120458000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 60 bytes RTCP
0:05:03.120543000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:05:06.542809000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:05:06.542842000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:05:06.542866000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 56 on channel 1
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1670teletext stream using application/x-teletext with mpegtsmux ? Showing wrong ...2023-07-11T10:52:18ZRobert Henselteletext stream using application/x-teletext with mpegtsmux ? Showing wrong type in DVBInspector and VLC Platback.Hi,
I'm using this pipeline below experimenting in attempt in producing a DVB compliant TS with a Teletext stream.
I'm using a windows batch file so I've taken out the '^' after each line for clarity. Once my pipeline is tested I'll fine...Hi,
I'm using this pipeline below experimenting in attempt in producing a DVB compliant TS with a Teletext stream.
I'm using a windows batch file so I've taken out the '^' after each line for clarity. Once my pipeline is tested I'll fine tune a little more then adapt the pipeline into a python app on linux for my DATV DVB-S transmitter project.
Issue I have is I'm sucking out the Teletext data from a TS file Program 4 on PID 1978 using the tsdemux plugin.
I'm pulling out the teletext data by selecting the correct pid attaching to pad private_0_07b ( 0=teletext PID =0x07b = Decimal 1978) from the **TSdemux**. These are so many Gstreamer pages on the web with conflicting information on correctly setting the stream and PID and the demux. Anyway, PES data flows through to be remuxed into **mpegtsmux** on the application/x-teletext pad PID of 1980.
Is seems to work however, I'd unable to show the correct teletext type=6?? Somehow it showing to be DVB subtitling in DVBInspector which isn't correct.
I'm using Gstreamer's recent windows build where all elements and plugins are version 1.19.1
I know there has been ongoing work in making **mpegtsmux** DVB and ATSC compliant which is a move forward and appreciative for all the work which goes into Gstreamer framework. I've tried **ffmpeg** however, I not sure how to go about muxing teletext data with ffmpeg as there naff all information I could find. Plenty on subtitling and actual plugin for such. sparse with actual teletext? I know there is the teletexdec plugin
Only 'if' there was a plugin for encoding teletextenc ??
Back on my issue:-
Is there a issue with mpegtsmux? or is it something I've done in my pipeline OR, plainly what I'm doing is not how you do it?
Attached is my Pipeline which encodes BigBuckBunny as RAW Video and audio to TS stream with Teletext encoding. I'd be working with live AV using fiffo's into gestreamer pipeline on the project. Teletext I hope to work on injecting these using **appsrc** however, more investigation and reseach on how to do buffer and PCR time stamping.. Has anyone out there has successfully done what I'm trying to do?
Pictures below show PID 1980 showing DVBSubtitling service (WRONG) in addition, VLC confirms such by advertising Subtitles however not the display Teletext.
gst-launch-1.0
mpegtsmux name=mux prog-map=program_map,sink_1000=10,sink_1001=10,sink_1980=10
! filesink location=C:/temp/meta1.ts ^
filesrc location=C:/Temp/big_buck_bunny_720p24.y4m
! decodebin name=vdec
! video/x-raw,format=I420,width=1280,height=720
! x264enc tune=zerolatency bitrate=5000 byte-stream=true threads=2 key-int-max=15 intra-refresh=true
! video/x-h264, profile=main
! queue
! mux.sink_1000
filesrc location=C:/Temp/BigBuckBunny-stereo.flac
! decodebin name=adec
! audioconvert
! voaacenc bitrate=128000
! aacparse
! queue
! mux.sink_1001
filesrc location=C:/temp/OC3.demo.ts
! tsdemux name=demux program-number=4 parse-private-sections=false
demux.private_0_07ba
! queue
! application/x-teletext
! mux.sink_1980
VLC codec information
![image](/uploads/5dfb335d4f4930fc9a5a6e30ec27857f/image.png)
DVB Inspector tables
![image](/uploads/3f7d6bfc487d279d2f97592f5fa04f6f/image.png)