GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-05-17T15:37:55Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/696cheese-WARNING **: 11:11:42.653: Internal GStreamer error: code not implemented.2021-05-17T15:37:55ZCorrado Venturinicheese-WARNING **: 11:11:42.653: Internal GStreamer error: code not implemented.```
corrado@corrado-x6-ii-0501:~$ cheese
(cheese:4401): Gdk-WARNING **: 11:11:40.272: Native Windows taller than 65535 pixels are not supported
(cheese:4401): cheese-WARNING **: 11:11:42.653: Internal GStreamer error: code not implemen...```
corrado@corrado-x6-ii-0501:~$ cheese
(cheese:4401): Gdk-WARNING **: 11:11:40.272: Native Windows taller than 65535 pixels are not supported
(cheese:4401): cheese-WARNING **: 11:11:42.653: Internal GStreamer error: code not implemented. Please file a bug at https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/new.: ../gst-libs/gst/video/gstvideofilter.c(296): gst_video_filter_transform (): /GstCameraBin:camerabin/GstViewfinderBin:vf-bin/GstVideoConvert:vfbin-csp:
invalid video buffer received
corrado@corrado-x6-ii-0501:~$ apt policy cheese
cheese:
Installed: 3.38.0-3
Candidate: 3.38.0-3
Version table:
*** 3.38.0-3 500
500 http://archive.ubuntu.com/ubuntu impish/main amd64 Packages
100 /var/lib/dpkg/status
corrado@corrado-x6-ii-0501:~$ inxi -Fx
System: Host: corrado-x6-ii-0501 Kernel: 5.11.0-16-generic x86_64 bits: 64 compiler: gcc
v: 10.2.1 Desktop: GNOME 3.38.4 Distro: Ubuntu 21.10 (Impish Indri)
Machine: Type: Desktop Mobo: ASRock model: H110M-G/M.2 serial: <superuser required>
UEFI: American Megatrends v: P1.10 date: 05/11/2017
CPU: Info: Dual Core model: Intel Core i3-7100 bits: 64 type: MT MCP arch: Kaby Lake
rev: 9 L2 cache: 3 MiB
flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 31199
Speed: 800 MHz min/max: 800/3900 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800
Graphics: Device-1: Intel HD Graphics 630 vendor: ASRock driver: i915 v: kernel
bus ID: 00:02.0
Device-2: ARC USB 2.0 Camera type: USB driver: uvcvideo bus ID: 1-2:3
Display: wayland server: X.Org 1.21.1.1 compositor: gnome-shell driver:
loaded: i915 note: n/a (using device driver) resolution: 1920x1080~60Hz
OpenGL: renderer: Mesa Intel HD Graphics 630 (KBL GT2) v: 4.6 Mesa 21.0.1
direct render: Yes
Audio: Device-1: Intel 100 Series/C230 Series Family HD Audio vendor: ASRock
driver: snd_hda_intel v: kernel bus ID: 00:1f.3
Device-2: Logitech QuickCam Pro 9000 type: USB driver: snd-usb-audio,uvcvideo
bus ID: 1-1:2
Sound Server: ALSA v: k5.11.0-16-generic
Network: Device-1: Intel Ethernet I219-V vendor: ASRock driver: e1000e v: kernel port: f040
bus ID: 00:1f.6
IF: enp0s31f6 state: up speed: 100 Mbps duplex: full mac: 70:85:c2:44:7b:86
Device-2: D-Link DWA-121 802.11n Wireless N 150 Pico Adapter [Realtek RTL8188CUS]
type: USB driver: rtl8192cu bus ID: 1-5:5
IF: wlx48ee0c2322b8 state: down mac: 48:ee:0c:23:22:b8
Drives: Local Storage: total: 2.05 TiB used: 8.21 GiB (0.4%)
ID-1: /dev/nvme0n1 vendor: Kingston model: SKC2000M8250G size: 232.89 GiB
temp: 28.9 C
ID-2: /dev/sda vendor: Toshiba model: DT01ACA100 size: 931.51 GiB
ID-3: /dev/sdb vendor: Hitachi model: HDS721010CLA332 size: 931.51 GiB
Partition: ID-1: / size: 31.25 GiB used: 8.2 GiB (26.3%) fs: ext4 dev: /dev/nvme0n1p6
ID-2: /boot/efi size: 252 MiB used: 5.2 MiB (2.1%) fs: vfat dev: /dev/nvme0n1p1
Swap: ID-1: swap-1 type: partition size: 8 GiB used: 0 KiB (0.0%) dev: /dev/sda2
Sensors: System Temperatures: cpu: 44.5 C mobo: N/A
Fan Speeds (RPM): N/A
Info: Processes: 232 Uptime: 4m Memory: 7.48 GiB used: 1.79 GiB (23.9%) Init: systemd
runlevel: 5 Compilers: gcc: N/A Packages: 1804 Shell: Bash v: 5.1.8 inxi: 3.3.01
corrado@corrado-x6-ii-0501:~$
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/695textoverlay: shaded-background=true does not work on windows2022-11-10T09:21:06Zvt-smxtextoverlay: shaded-background=true does not work on windowsHy,
I tried on windows 10 x64 following command:
`gst-launch-1.0 videotestsrc ! textoverlay font-desc="Sans 24" text="TEST" shaded-background=true ! autovideosink`
The shaded background is not shown.
See screenshot:
![2021-05-14_08_4...Hy,
I tried on windows 10 x64 following command:
`gst-launch-1.0 videotestsrc ! textoverlay font-desc="Sans 24" text="TEST" shaded-background=true ! autovideosink`
The shaded background is not shown.
See screenshot:
![2021-05-14_08_40_41-Direct3D11_renderer](/uploads/446fbc8b7a129bbff826d490474ca86d/2021-05-14_08_40_41-Direct3D11_renderer.png)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/886rtspsrc location length problem2023-07-02T16:43:56Z末末rtspsrc location length problem`gst-launch-1.0 rtspsrc location="rtsp://183.59.160.61/PLTV/88888895/224/3221226767/00000100000000060000000000268440_0.smil?rrsip=125.88.70.140,rrsip=125.88.104.45&zoneoffset=480&icpid=szmg&accounttype=1&limitflux=-1&limitdur=-1&accounti...`gst-launch-1.0 rtspsrc location="rtsp://183.59.160.61/PLTV/88888895/224/3221226767/00000100000000060000000000268440_0.smil?rrsip=125.88.70.140,rrsip=125.88.104.45&zoneoffset=480&icpid=szmg&accounttype=1&limitflux=-1&limitdur=-1&accountinfo=%7E%7EV2.0%7Ekws5JFgGn-zqVXihML1ujg%7E9rXSI7IeLpF-Iy8tIn5TfxK58x4Z8vevaDBINizpo5FcfEW667kl4l1Ui7NwFD0d09dwbRwtTeqi-3mg1V5El-iYjXauSVB_dL9sI8VG9wg~ExtInfoWNHSPSTb+3AG0FnUkYLPMw==%3A20190726130336%2C21858133%2C183.15.205.163%2C20190726130336%2C11000100000000050000000000000148%2C2185813320190726130335%2C-1%2C0%2C1%2C%2C%2C2%2C%2C%2C%2C2%2CEND&GuardEncType=2&tenantId=8601" ! queue ! rtph264depay ! h264parse ! mpegtsmux ! hlssink target-duration=2 playlist-length=20 max-files=20 playlist-location="/www/1/1.m3u8" location="/www/1/1_%05d.ts"`
The above command reports an error because the location is too long
![image](/uploads/d9c5178377322ccd79ecde1b015bd432/image.png)
When I reduce the length of the location, it is normal, because the missing parameter is reported as 403
`gst-launch-1.0 rtspsrc location="rtsp://183.59.160.61/PLTV/88888895/224/3221226767/00000100000000060000000000268440_0.smil?rrsip=125.88.70.140,rrsip=125.88.104.45&zoneoffset=480&icpid=szmg&accounttype=1&limitflux=-1&limitdur=-1&accountinfo=%7E%7EV2.0%7Ekws5JFgGn-zqVXihML1ujg%7E9rXSI7IeLpF-Iy8tIn5TfxK58x4Z8vevaDBINizpo5FcfEW667kl4l1Ui7NwFD0d09dwbRwtTeqi-3mg1V5El-iYjXauSVB_dL9sI8VG9wg~ExtInfoWNHSPSTb+3AG0FnUkYLPMw==%3A20190726130336%2C21858133%2C183.15.205.163%2C20190726130336%2C11000100000000050000000000000148%2C2185813320190726130335%2C-1%2C0%2C1%2C%2C%2C2%2C%2C%2C%2C2%2CEND&GuardEncType=" ! queue ! rtph264depay ! h264parse ! mpegtsmux ! hlssink target-duration=2 playlist-length=20 max-files=20 playlist-location="/www/1/1.m3u8" location="/www/1/1_%05d.ts"`
![image](/uploads/bedefc78111653d45f52fe7fda402fc4/image.png)
version:1.16.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/150meson reconfigure triggers a full GST Rust rebuild2021-06-01T13:01:51ZStéphane Cerveauscerveau@igalia.commeson reconfigure triggers a full GST Rust rebuildI first enabled GST rust plugin and start build everything from scratch (external traits and Gstreamer libs).
Then I changed something in on meson.build from gst-plugins-base (install a tool) and it triggers a full build of rust again.
...I first enabled GST rust plugin and start build everything from scratch (external traits and Gstreamer libs).
Then I changed something in on meson.build from gst-plugins-base (install a tool) and it triggers a full build of rust again.
It triggers a build of GStreamer rust libraries again.
It is something expected ?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1591srt: Setting "uri" property overrides other properties set earlier2021-09-24T14:39:21ZMart Raudseppsrt: Setting "uri" property overrides other properties set earlierThe `gst_srt_object_set_uri` implementation recreates the `application/x-srt-params` structure, losing all previously set values, including those not set in the URI.
So for example this code:
```c
g_object_set(srtsink, "latency", 300, NU...The `gst_srt_object_set_uri` implementation recreates the `application/x-srt-params` structure, losing all previously set values, including those not set in the URI.
So for example this code:
```c
g_object_set(srtsink, "latency", 300, NULL);
g_object_set(srtsink, "uri", "srt://127.0.0.1:7001", NULL);
```
or this:
```c
g_object_set(srtsink,
"latency", 300,
"uri", "srt://127.0.0.1:7001",
NULL);
```
will end up using default latency of 125, not what it explicitly set up here, as the URI setting will lose this with the `srtobject->parameters` recreation.
To fix this, we need to make sure uri is set first separately or in the same call:
```c
g_object_set(srtsink, "uri", "srt://127.0.0.1:7001", NULL);
g_object_set(srtsink, "latency", 300, NULL);
```
or
```c
g_object_set(srtsink,
"uri", "srt://127.0.0.1:7001",
"latency", 300,
NULL);
```
But if for some reason the URI needs to be set later in code flow (before going READY), all the previously set properties would need to be retrieved first and then set again after e.g. changing the IP address.
Any other property handled via srtobject->parameters is likely broken the same way if `uri` is set afterwards.
It would be nice to at least know about this behaviour via `"uri"` property description for a start, but of course ideally the URI setting shouldn't override properties that aren't overridden via GET parameters of the URI.
Edit: Earlier I claimed that this always happens when "uri" and "latency" are set up in the same g_object_set varargs, but this only happens if "uri" comes later in the vararg - it seemed to have been due to uri being handled via g_object_bind_property but latency via manual code making the behaviour be as latency set before the property bound uri when set in the same g_object_set call on the GstBin.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/694Performance degradation of videoscale element on Ubuntu18.2022-11-10T09:21:06ZAlexey BelyakovPerformance degradation of videoscale element on Ubuntu18.> gst-launch-1.0 filesrc location=video-examples/person-bicycle-car-detection_1920_1080-2min.mp4 ! qtdemux ! avdec_h264 max-threads=1 ! videoscale n-threads=1 ! videoconvert n-threads=1 ! video/x-raw,format=BGRx,width=100,height=100 ! gv...> gst-launch-1.0 filesrc location=video-examples/person-bicycle-car-detection_1920_1080-2min.mp4 ! qtdemux ! avdec_h264 max-threads=1 ! videoscale n-threads=1 ! videoconvert n-threads=1 ! video/x-raw,format=BGRx,width=100,height=100 ! gvafpscounter ! fakesink async=false
Output with GStreamer **1.16.2**:
FPSCounter(average): total=251.41 fps, number-streams=1, per-stream=251.41 fps
Execution ended after 0:00:10.338461396
Output with GStreamer **1.18.4**:
FPSCounter(average): total=238.40 fps, number-streams=1, per-stream=238.40 fps
Execution ended after 0:00:10.899746688https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/902video-converter: Consider fast-paths for some 10-bit formats2021-09-24T13:26:20ZRafał Dzięgielvideo-converter: Consider fast-paths for some 10-bit formatsOne of the more popular 10-bit format is `I420_10LE`, unfortunately VAAPI cannot do 10-bit AVC decoding. Right now video-converter is missing 10-bit and higher fast-paths. It would be nice if it could do fast-path for e.g. `I420_10LE` ->...One of the more popular 10-bit format is `I420_10LE`, unfortunately VAAPI cannot do 10-bit AVC decoding. Right now video-converter is missing 10-bit and higher fast-paths. It would be nice if it could do fast-path for e.g. `I420_10LE` -> `P010_10LE` with bits only conversion for noticeable performance boost, as VAAPI cannot decode it and format `I420_10LE` is not supported by GL sinks.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/693The "gst_clock_id_wait_async()" function invokes its callback thousands of ti...2021-05-13T19:32:10ZAbleBaconThe "gst_clock_id_wait_async()" function invokes its callback thousands of times back-to-back at first.Using version `1.19.0.1` on Windows 10, the following testcase causes the `test_func()` callback function to be called thousands of times back-to-back at first, despite the interval being set to 1 second. After these rapid consecutive ca...Using version `1.19.0.1` on Windows 10, the following testcase causes the `test_func()` callback function to be called thousands of times back-to-back at first, despite the interval being set to 1 second. After these rapid consecutive calls, the callback begins to function appropriately, being called once per second.
```
#include <gst/gst.h>
static gboolean test_func(GstClock* clock, GstClockTime time, GstClockID id, gpointer ctx) {
static gulong i = 0;
g_print("Test func called! %d\n", i++);
return TRUE;
}
int main() {
// Init 'gstreamer', launch a pipeline, and start the pipeline "PLAYING".
gst_init(NULL, NULL);
GstElement* pipeline = gst_parse_launch("fakesrc ! fakesink", NULL);
GMainLoop* main_loop = g_main_loop_new(NULL, FALSE);
gst_element_set_state(pipeline, GST_STATE_PLAYING);
// Set up the periodic callback based on a clock in the pipeline that was launched.
GstClock* clock = gst_pipeline_get_clock(GST_PIPELINE_CAST(pipeline));
GstClockID periodic_id = gst_clock_new_periodic_id(clock, 0, 1'000'000'000);
GstClockReturn clock_return = gst_clock_id_wait_async(periodic_id, (GstClockCallback)test_func, NULL, NULL);
gst_object_unref(clock);
// Run the main loop and then unref everything afterwards.
g_main_loop_run(main_loop);
gst_element_set_state(pipeline, GST_STATE_NULL);
g_object_unref(pipeline);
}
```https://gitlab.freedesktop.org/gstreamer/gst-examples/-/issues/41libnice-CRITICAL **: 18:48:03.873: nice_agent_parse_remote_candidate_sdp: ass...2021-05-14T05:22:09ZRamil Zaynulinlibnice-CRITICAL **: 18:48:03.873: nice_agent_parse_remote_candidate_sdp: assertion 'sdp != NULL' failed I try to handle sdp massage. But have a problem. \\\
(python3.6:22843): libnice-CRITICAL **: 18:48:03.873: nice_agent_parse_remote_candidate_sdp: assertion 'sdp != NULL' failed
```
SDP:
v=0
o=mozilla...THIS_IS_SDPARTA-88.0 7971567773001... I try to handle sdp massage. But have a problem. \\\
(python3.6:22843): libnice-CRITICAL **: 18:48:03.873: nice_agent_parse_remote_candidate_sdp: assertion 'sdp != NULL' failed
```
SDP:
v=0
o=mozilla...THIS_IS_SDPARTA-88.0 7971567773001479151 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 54:BA:72:5E:A5:45:C7:5E:C1:F3:B1:2E:9B:33:3D:4D:76:6D:86:A7:CD:EF:11:9D:4E:FA:22:A9:50:DB:A6:9D
a=ice-options:trickle
a=msid-semantic:WMS *
m=video 9 UDP/TLS/RTP/SAVPF 97
c=IN IP4 0.0.0.0
a=recvonly
a=fmtp:97 max-fs=12288;max-fr=60
a=ice-pwd:6a2c9d135064881c4fe3bc57c205ebb9
a=ice-ufrag:786dc185
a=mid:video0
a=rtcp-fb:97 nack pli
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:97 VP8/90000
a=setup:active
a=ssrc:128964465 cname:{51fad488-e29f-4fc2-8cdf-9f99ed71c1e3}
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/885rtspsrc: set-parameter / get-parameter action signals assume parameter values...2021-09-24T13:34:28ZNirbheek Chauhannirbheek.chauhan@gmail.comrtspsrc: set-parameter / get-parameter action signals assume parameter values are text"set-parameter" takes four params:
`const char *name` (the name of the param)
`const char *value` (the value of the param)
`const char *content_type` (text/parameters, etc)
`GstPromise * promise` (to get notified when the action com..."set-parameter" takes four params:
`const char *name` (the name of the param)
`const char *value` (the value of the param)
`const char *content_type` (text/parameters, etc)
`GstPromise * promise` (to get notified when the action completes)
And then it just does:
> `g_string_append_printf (req->body, "%s: %s\r\n", name, value);`
This means you can't send arbitrary data (via media type negotiation); all you can send is content-type "text/<something>". This does not match all the possibilities listed in the spec: https://datatracker.ietf.org/doc/html/rfc7826#section-13.9
Interestingly, the "handle-request" signal is correctly implemented, and you can receive arbitrary data in "SET_PARAMETER".
The same problem also exists for "get-parameter". We should probably rework these and add new signals that allow sending / receiving GBytes.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1590vp9dec: error: Failed to decode frame2022-03-04T21:38:48ZNazar Mokrynskyivp9dec: error: Failed to decode frameI just pulled latest changes with VP9 alpha channel support and got errors when stopping pipeline that can be reproduced with this simple pipeline:
```
GST_DEBUG=3 gst-launch-1.0 \
filesrc location=colour_hearts_720p.webm ! \
mat...I just pulled latest changes with VP9 alpha channel support and got errors when stopping pipeline that can be reproduced with this simple pipeline:
```
GST_DEBUG=3 gst-launch-1.0 \
filesrc location=colour_hearts_720p.webm ! \
matroskademux ! \
decodebin ! \
identity eos-after=100 ! \
fakesink
```
The output is:
<details>
```
Setting pipeline to PAUSED ...
0:00:00.007848676 367 0x564edc6bd0d0 WARN basesrc gstbasesrc.c:3688:gst_base_src_start_complete:<filesrc0> pad not activated yet
Pipeline is PREROLLING ...
0:00:00.008178500 367 0x564edc6ba920 WARN ebmlread ebml-read.c:622:gst_ebml_read_utf8:<matroskademux0> Invalid UTF-8 string at offset 551
(gst-launch-1.0:367): GStreamer-WARNING **: 12:13:53.821: Trying to set string on taglist field 'extended-comment', but string is not valid UTF-8. Please file a bug.
0:00:00.009806388 367 0x564edc6ba920 WARN matroskareadcommon matroska-read-common.c:711:gst_matroska_read_common_parse_skip:<matroskademux0:sink> Unknown CueTrackPositions subelement 0xf0 - ignoring
0:00:00.009814994 367 0x564edc6ba920 WARN matroskareadcommon matroska-read-common.c:711:gst_matroska_read_common_parse_skip:<matroskademux0:sink> Unknown CueTrackPositions subelement 0xf0 - ignoring
0:00:00.009820555 367 0x564edc6ba920 WARN matroskareadcommon matroska-read-common.c:711:gst_matroska_read_common_parse_skip:<matroskademux0:sink> Unknown CueTrackPositions subelement 0xf0 - ignoring
0:00:00.009825514 367 0x564edc6ba920 WARN matroskareadcommon matroska-read-common.c:711:gst_matroska_read_common_parse_skip:<matroskademux0:sink> Unknown CueTrackPositions subelement 0xf0 - ignoring
0:00:00.010654361 367 0x564edc6baf60 FIXME videodecoder gstvideodecoder.c:1106:gst_video_decoder_drain_out:<vp9dec0> Sub-class should implement drain()
0:00:00.010659160 367 0x7f1538092000 FIXME videodecoder gstvideodecoder.c:1106:gst_video_decoder_drain_out:<vp9dec1> Sub-class should implement drain()
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
0:00:00.098265413 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4505:_gst_video_decoder_error:<vp9dec0> error: Failed to decode frame
0:00:00.098278938 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4507:_gst_video_decoder_error:<vp9dec0> error: corrupt frame
0:00:00.098295239 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4505:_gst_video_decoder_error:<vp9dec0> error: Failed to decode frame
0:00:00.098298425 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4507:_gst_video_decoder_error:<vp9dec0> error: corrupt frame
0:00:00.098320968 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4505:_gst_video_decoder_error:<vp9dec0> error: Failed to decode frame
0:00:00.098324815 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4507:_gst_video_decoder_error:<vp9dec0> error: corrupt frame
0:00:00.098363548 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4505:_gst_video_decoder_error:<vp9dec0> error: Failed to decode frame
0:00:00.098367105 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4507:_gst_video_decoder_error:<vp9dec0> error: corrupt frame
0:00:00.098378937 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4505:_gst_video_decoder_error:<vp9dec0> error: Failed to decode frame
0:00:00.098383606 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4507:_gst_video_decoder_error:<vp9dec0> error: corrupt frame
0:00:00.098434242 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4505:_gst_video_decoder_error:<vp9dec0> error: Failed to decode frame
0:00:00.098437568 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4507:_gst_video_decoder_error:<vp9dec0> error: corrupt frame
0:00:00.098447787 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4505:_gst_video_decoder_error:<vp9dec0> error: Failed to decode frame
0:00:00.098450773 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4507:_gst_video_decoder_error:<vp9dec0> error: corrupt frame
0:00:00.098470440 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4505:_gst_video_decoder_error:<vp9dec0> error: Failed to decode frame
0:00:00.098473276 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4507:_gst_video_decoder_error:<vp9dec0> error: corrupt frame
0:00:00.098489626 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4505:_gst_video_decoder_error:<vp9dec0> error: Failed to decode frame
0:00:00.098492271 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4507:_gst_video_decoder_error:<vp9dec0> error: corrupt frame
0:00:00.098523871 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4505:_gst_video_decoder_error:<vp9dec0> error: Failed to decode frame
0:00:00.098527418 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4507:_gst_video_decoder_error:<vp9dec0> error: corrupt frame
0:00:00.098538228 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4505:_gst_video_decoder_error:<vp9dec0> error: Failed to decode frame
0:00:00.098540984 367 0x564edc6baf60 WARN videodecoder gstvideodecoder.c:4507:_gst_video_decoder_error:<vp9dec0> error: corrupt frame
ERROR: from element /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstVp9AlphaDecodeBin:vp9alphadecodebin0/GstVP9Dec:vp9dec0: Failed to decode frame
Additional debug info:
../ext/vpx/gstvpxdec.c(718): gst_vpx_dec_handle_frame (): /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstVp9AlphaDecodeBin:vp9alphadecodebin0/GstVP9Dec:vp9dec0:
corrupt frame
Execution ended after 0:00:00.084791963
Setting pipeline to NULL ...
0:00:00.098637235 367 0x564edc6ba920 WARN matroskademux matroska-demux.c:6049:gst_matroska_demux_loop:<matroskademux0> error: Internal data stream error.
0:00:00.098645150 367 0x564edc6ba920 WARN matroskademux matroska-demux.c:6049:gst_matroska_demux_loop:<matroskademux0> error: streaming stopped, reason error (-5)
ERROR: from element /GstPipeline:pipeline0/GstMatroskaDemux:matroskademux0: Internal data stream error.
Additional debug info:
../gst/matroska/matroska-demux.c(6049): gst_matroska_demux_loop (): /GstPipeline:pipeline0/GstMatroskaDemux:matroskademux0:
streaming stopped, reason error (-5)
Freeing pipeline ...
```
</details>
Example file with VP9 and alpha channel:
![colour_hearts_720p](/uploads/676724f9274f099b16adc76ecb93538f/colour_hearts_720p.webm)Nicolas DufresneNicolas Dufresnehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/884v4l2convert: race condition of group_released_handler2021-09-24T13:34:27ZKevin Songv4l2convert: race condition of group_released_handlerWe found below WARNING when run v4l2convert. How can we ensure group_released_handler don't disconnect in gst_v4l2_buffer_pool_stop when gst_v4l2_buffer_pool_resurrect_buffer()?
gst-launch-1.0 videotestsrc num-buffers=50 ! video/x-raw,f...We found below WARNING when run v4l2convert. How can we ensure group_released_handler don't disconnect in gst_v4l2_buffer_pool_stop when gst_v4l2_buffer_pool_resurrect_buffer()?
gst-launch-1.0 videotestsrc num-buffers=50 ! video/x-raw,format=BGRx,width=640,height=480 ! v4l2convert ! video/x-raw,format=RGB16 ! waylandsink sync=false
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.807843250
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
(gst-launch-1.0:5105): GLib-GObject-WARNING **: 20:17:06.169: ../glib-2.60.7/gobject/gsignal.c:2641: instance '0xffff94011200' has no handler with id '16'
Setting pipeline to NULL ...
Total showed frames (51), playing for (0:00:00.808691125), fps (63.065).
Freeing pipeline ...https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1589Follow-up from "openaptx: Fix to v0.2.0 due to license change"2022-02-16T04:55:46ZNicolas DufresneFollow-up from "openaptx: Fix to v0.2.0 due to license change"The following discussion from !2235 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2235#note_913180): (+1 comment)
> Maybe instead we want to simp...The following discussion from !2235 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2235#note_913180): (+1 comment)
> Maybe instead we want to simply bundle the code of the last properly-licensed version? That seems more future proof and it's not actually a huge amount of code, and doesn't seem to see many changes anyway.https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/327Disable openssl2021-05-12T06:51:32ZNiuCYDisable opensslI created an ios application embedded with GStreamer, but GStreamer's openssl conflicts with other frameworks. How to disable openssl module or remove openssl from GStreamer.I created an ios application embedded with GStreamer, but GStreamer's openssl conflicts with other frameworks. How to disable openssl module or remove openssl from GStreamer.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/692Registry cache for separate users?2022-11-10T09:21:06ZRobert RosengrenRegistry cache for separate users?The generated registry ends up in a file with restricted access where only current user may read/write (i.e. 0600). The registry should be able to be shared between different Gstreamer applications, on a desktop where one user logs in an...The generated registry ends up in a file with restricted access where only current user may read/write (i.e. 0600). The registry should be able to be shared between different Gstreamer applications, on a desktop where one user logs in and uses different applications this will work with current setup.
From an embedded system perspective where different daemons runs with separate users the restricted permissions on the registry will force all daemons to create their own cache. We would like them to be able to share the registry to save both storage and CPU performance.
Is there a special reasoning behind setting up the registry cache as non-readable by group and others? Anyone remembers reasoning behind https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/5cdcdaee07c1f81a0abdd3885050118474e6c079 ?
The simplest idea of sharing registry between different users is to setup the file as readable by all. If so, all users can read current registry to check if still valid and if so use it. If not valid, the user may regenerate the cache and write the new file which would work since the user does not write directly into existing file (that it lacks permissions to do), instead replaces it with a new file.
Here is quick patch for changing the permissions when file is replaced. Would this be OK?
https://gitlab.freedesktop.org/robberos/gstreamer/-/commit/c34f2b38366525ef5b44e2f0b36606dcf941d62e
Any insights, ideas, thoughts?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/691I need to Cross Compile 1.18.4 gstreamer for arm-dey-linux2021-05-10T08:32:36ZAbhishek MRI need to Cross Compile 1.18.4 gstreamer for arm-dey-linuxI need help to cross compile gstreamer 1.18.4 for ARM linux board , How i can change CC-FLAGS , so on
How to compile source ising arm-dey-linux tool chain , rather than generic linux commands .I need help to cross compile gstreamer 1.18.4 for ARM linux board , How i can change CC-FLAGS , so on
How to compile source ising arm-dey-linux tool chain , rather than generic linux commands .https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/335Cross-compilation (host ubuntu 18.04 x86_64 - target x86_64-pc-windows-gnu)2021-05-10T07:49:17ZAlex ViCross-compilation (host ubuntu 18.04 x86_64 - target x86_64-pc-windows-gnu)```
cargo clean && cargo build --target x86_64-pc-windows-gnu
Compiling proc-macro2 v1.0.26
Compiling unicode-xid v0.2.2
Compiling syn v1.0.72
Compiling serde v1.0.125
Compiling unicode-segmentation v1.7.1
Compiling ver...```
cargo clean && cargo build --target x86_64-pc-windows-gnu
Compiling proc-macro2 v1.0.26
Compiling unicode-xid v0.2.2
Compiling syn v1.0.72
Compiling serde v1.0.125
Compiling unicode-segmentation v1.7.1
Compiling version-compare v0.0.10
Compiling strum v0.18.0
Compiling pkg-config v0.3.19
Compiling autocfg v1.0.1
Compiling version_check v0.9.3
Compiling libc v0.2.94
Compiling proc-macro-hack v0.5.19
Compiling proc-macro-nested v0.1.7
Compiling futures-core v0.3.14
Compiling anyhow v1.0.40
Compiling pin-project-lite v0.2.6
Compiling futures-task v0.3.14
Compiling slab v0.4.3
Compiling pin-utils v0.1.0
Compiling either v1.6.1
Compiling bitflags v1.2.1
Compiling gstreamer v0.16.7
Compiling once_cell v1.7.2
Compiling pretty-hex v0.2.1
Compiling paste v1.0.5
Compiling cfg-if v1.0.0
Compiling muldiv v0.2.1
Compiling heck v0.3.2
Compiling proc-macro-error-attr v1.0.4
Compiling proc-macro-error v1.0.4
Compiling num-traits v0.2.14
Compiling num-integer v0.1.44
Compiling num-rational v0.3.2
Compiling futures-channel v0.3.14
Compiling itertools v0.9.0
Compiling quote v1.0.9
Compiling toml v0.5.8
Compiling proc-macro-crate v0.1.5
Compiling thiserror-impl v1.0.24
Compiling strum_macros v0.18.0
Compiling futures-macro v0.3.14
Compiling glib-macros v0.10.1
Compiling futures-util v0.3.14
Compiling thiserror v1.0.24
Compiling system-deps v1.3.2
Compiling glib-sys v0.10.1
Compiling gobject-sys v0.10.0
Compiling gstreamer-sys v0.9.1
Compiling futures-executor v0.3.14
Compiling glib v0.10.3
Compiling gst_t v0.1.0 (/home/vi/gst_t)
error: linking with `x86_64-w64-mingw32-gcc` failed: exit code: 1
|
= note: "x86_64-w64-mingw32-gcc" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-Wl,--dynamicbase" "-Wl,--disable-auto-image-base" "-m64" "-Wl,--high-entropy-va" "/home/vi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/rsbegin.o" "-L" "/home/vi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/gst_t-6f1c0cab31f7a9d4.16h4s3bsf6aol8gr.rcgu.o" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/gst_t-6f1c0cab31f7a9d4.1a318mrfahqqbabd.rcgu.o" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/gst_t-6f1c0cab31f7a9d4.1ik7v8iw6mvku6re.rcgu.o" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/gst_t-6f1c0cab31f7a9d4.28zvcajmxw9sd0xq.rcgu.o" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/gst_t-6f1c0cab31f7a9d4.2slcq5nka52jj5tl.rcgu.o" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/gst_t-6f1c0cab31f7a9d4.3lsbjcb86fkv2l7z.rcgu.o" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/gst_t-6f1c0cab31f7a9d4.4foo9ovvj92myjxi.rcgu.o" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/gst_t-6f1c0cab31f7a9d4.4nmp54ygcoxbk9w3.rcgu.o" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/gst_t-6f1c0cab31f7a9d4.4v321l8yzkk0fuo1.rcgu.o" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/gst_t-6f1c0cab31f7a9d4.5fkhyjgx2brmi6rg.rcgu.o" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/gst_t-6f1c0cab31f7a9d4.5s7l6nwkewuxtfw.rcgu.o" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/gst_t-6f1c0cab31f7a9d4.amzjupw8sv12dwz.rcgu.o" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/gst_t-6f1c0cab31f7a9d4.k17vgys95sxknct.rcgu.o" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/gst_t-6f1c0cab31f7a9d4.wcqhu95jhn7fs78.rcgu.o" "-o" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/gst_t-6f1c0cab31f7a9d4.exe" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/gst_t-6f1c0cab31f7a9d4.29ccv3s3nf7wpwkz.rcgu.o" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps" "-L" "/home/vi/gst_t/target/debug/deps" "-L" "/home/vi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib" "-Wl,-Bstatic" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/libgstreamer-8366206bae392833.rlib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/libpretty_hex-27f1667b589cb63a.rlib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/libmuldiv-8a38383014a5fed3.rlib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/libnum_rational-3fb05bcd36fcda13.rlib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/libnum_integer-51a9e5fe927005b6.rlib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/libnum_traits-10955afa85e0abc0.rlib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/libglib-e92a423633e84ed6.rlib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/libfutures_executor-5afe1fc2428bec0c.rlib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/libfutures_util-c20531009002991b.rlib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/libslab-1469822c67c239b2.rlib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/libpin_project_lite-165eb23315324cfe.rlib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/libpin_utils-384f7fa068411a8a.rlib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/libfutures_task-c32ba0da06249a20.rlib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/libfutures_channel-ba385aef148d7043.rlib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/libfutures_core-b1b02fa6d24c6bf5.rlib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/libgstreamer_sys-21622a92891648b0.rlib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/libgobject_sys-9dac48de806e7e74.rlib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/libglib_sys-271ebffff8200a9d.rlib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/libthiserror-f0b01ad6118b07a7.rlib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/libonce_cell-dd38839d2b33c20a.rlib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/liblibc-e5eb55dfd82e458e.rlib" "/home/vi/gst_t/target/x86_64-pc-windows-gnu/debug/deps/libbitflags-3120a49cd0e0c4c7.rlib" "-Wl,--start-group" "/home/vi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libstd-1a1d18e5744c6379.rlib" "/home/vi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libpanic_unwind-4bde1911f054536f.rlib" "/home/vi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libobject-614a77c171773b3c.rlib" "/home/vi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libaddr2line-472c2827890847b2.rlib" "/home/vi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libgimli-6aac5570e0b34d14.rlib" "/home/vi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/librustc_demangle-eb9b3f47d09e5be2.rlib" "/home/vi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libhashbrown-83d13ab4538ae61d.rlib" "/home/vi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/librustc_std_workspace_alloc-458c601c447a067d.rlib" "/home/vi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libunwind-b5d38d85c2fbbb53.rlib" "/home/vi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libcfg_if-57a81f2e06c83b8c.rlib" "/home/vi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/liblibc-939fa3eadd9934ed.rlib" "/home/vi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/liballoc-1c015d0d9b027a00.rlib" "/home/vi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/librustc_std_workspace_core-a07415189aa29170.rlib" "/home/vi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libcore-7118a8c755bc581d.rlib" "-Wl,--end-group" "/home/vi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libcompiler_builtins-298e27714a09df4c.rlib" "-Wl,-Bdynamic" "-lgstreamer-1.0" "-lgobject-2.0" "-lglib-2.0" "-lgobject-2.0" "-lglib-2.0" "-lglib-2.0" "-ladvapi32" "-lws2_32" "-luserenv" "-lgcc_eh" "-l:libpthread.a" "-lmsvcrt" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-luser32" "-lkernel32" "/home/vi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/rsend.o"
= note: /usr/bin/x86_64-w64-mingw32-ld: cannot find -lgstreamer-1.0
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lgobject-2.0
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lglib-2.0
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lgobject-2.0
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lglib-2.0
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lglib-2.0
collect2: error: ld returned 1 exit status
```
```
[dependencies]
gst = { package = "gstreamer", version = "*" }
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/901glimagesinkbin: GBM: wrong colors (something instead of RGBA) on Raspberry Pi 4B2024-02-10T13:26:40ZCarl-Daniel Hailfingerglimagesinkbin: GBM: wrong colors (something instead of RGBA) on Raspberry Pi 4BEnvironment:
- Raspberry Pi 4B with 4GB RAM
- Raspberry Pi OS (Debian armhf), no X server running
- Screen resolution via HDMI is 1280x720, single screen attached
- GStreamer 1.19 from git 2021-04-05, same problem also happens with GStre...Environment:
- Raspberry Pi 4B with 4GB RAM
- Raspberry Pi OS (Debian armhf), no X server running
- Screen resolution via HDMI is 1280x720, single screen attached
- GStreamer 1.19 from git 2021-04-05, same problem also happens with GStreamer 1.14.
Running the following command results in a blue-green checker pattern, but it should result in a red-green checker pattern.
`gst-launch-1.0 gltestsrc pattern=checkers-8 ! "video/x-raw(memory:GLMemory),width=1280,height=720,framerate=25/1" ! glimagesinkelement`
Verified against the following command which is working as expected
`gst-launch-1.0 gltestsrc pattern=checkers-8 ! "video/x-raw(memory:GLMemory),width=1280,height=720,framerate=25/1" ! glcolorconvert ! gldownload ! kmssink`
I first suspected there was a mixup between RGBA and BGRA, however subsequent tests became even weirder with colors mixed up more creatively and even neighboring pixels swapped.
At the native resolution of 1280x720, not only red/blue are swapped, but every 16 pixels in horizontal direction two pixel columns are swapped and every 16 pixels in vertical direction, two pixel rows are swapped.
`gst-launch-1.0 gltestsrc pattern=checkers-8 ! "video/x-raw(memory:GLMemory),width=1280,height=720,framerate=25/1" ! glimagesink`
The following command has red and blue switched like in the example above, but additionally the right bar in the lower row next to the changing black-and-white noise is pink instead of gray.
`gst-launch-1.0 videotestsrc ! video/x-raw,width=1280,height=720,framerate=25/1 ! glupload ! glimagesink`
The pattern should look identical to the one from the following command:
`gst-launch-1.0 videotestsrc ! video/x-raw,width=1280,height=720,framerate=25/1 ! kmssink`
I have no idea whether this is a GStreamer bug or a Raspberry Pi 4B graphics driver bug, but it is really weird.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1586Follow-up from "wpe: Minor fixes to property handling"2021-09-24T14:39:19ZJan Alexander SteffensFollow-up from "wpe: Minor fixes to property handling"The following discussion from !2222 should be addressed:
- [ ] @thiblahute started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2222#note_909115):
> I wonder if consuming the bytes is th...The following discussion from !2222 should be addressed:
- [ ] @thiblahute started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2222#note_909115):
> I wonder if consuming the bytes is the right thing to do here though (orthogonal to your patch though).https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/883gtk: "pixel-aspect-ratio" change not effective after creation2022-01-12T14:33:30ZBastien Noceragtk: "pixel-aspect-ratio" change not effective after creationChanging the "pixel-aspect-ratio" property doesn't seem to have any effects after its initial (default) setting, as `_calculate_par()` is never called again.
This could be important to implement support for screens with non-square pixel...Changing the "pixel-aspect-ratio" property doesn't seem to have any effects after its initial (default) setting, as `_calculate_par()` is never called again.
This could be important to implement support for screens with non-square pixels, as totem supports:
https://gitlab.gnome.org/GNOME/totem/-/blob/gnome-3-38/src/backend/bacon-video-widget.c#L422-467
I'm not certain it's a very important feature, but it also begs the question of what this property if useful for if it doesn't work as expected...
I have a very crude patch that schedules a `_queue_draw` idle callback when the property changes, which seems to change the ratio as expected.