GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2023-07-06T16:32:47Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2780gi.repository.Gst is no dict2023-07-06T16:32:47ZBugzilla Migration Usergi.repository.Gst is no dict## Submitted by Fnoop
**[Link to original bug (#776573)](https://bugzilla.gnome.org/show_bug.cgi?id=776573)**
## Description
Platform: Ubuntu 16.04 arm7l
Gstreamer 1.10.2 compiled from source into custom location (/srv/maverick...## Submitted by Fnoop
**[Link to original bug (#776573)](https://bugzilla.gnome.org/show_bug.cgi?id=776573)**
## Description
Platform: Ubuntu 16.04 arm7l
Gstreamer 1.10.2 compiled from source into custom location (/srv/maverick/software/gstreamer) with usual bunch of plugins (good/bad/ugly/libav). All plugins work except python:
Total count: 175 plugins (1 blacklist entry not shown), 1261 features
Blacklisted files:
libgstpythonplugin.so
Configure:
```
PKG_CONFIG_PATH=/srv/maverick/software/gstreamer/lib/pkgconfig LDFLAGS=-Wl,-rpath,/srv/maverick/software/gstreamer/lib ./autogen.sh --with-libpython-dir=/usr/lib/arm-linux-gnueabihf --prefix=/srv/maverick/software/gstreamer
```
Typelib set in
```
GI_TYPELIB_PATH=/srv/maverick/software/gstreamer/lib/girepository-1.0:/usr/lib/girepository-1.0
```
Result of `gst-inspect-1.0 --gst-disable-registry-update --gst-debug=4 /srv/maverick/software/gstreamer/lib/gstreamer-1.0/libgstpythonplugin.so`:
```
0:00:00.001112829 12755 0x37280 INFO GST_INIT gstmessage.c:126:_priv_gst_message_initialize: init messages
0:00:00.003132362 12755 0x37280 INFO GST_INIT gstcontext.c:83:_priv_gst_context_initialize: init contexts
0:00:00.004453232 12755 0x37280 INFO GST_PLUGIN_LOADING gstplugin.c:316:_priv_gst_plugin_initialize: registering 0 static plugins
0:00:00.004800606 12755 0x37280 INFO GST_PLUGIN_LOADING gstplugin.c:224:gst_plugin_register_static: registered static plugin "static
elements"
0:00:00.004834814 12755 0x37280 INFO GST_PLUGIN_LOADING gstplugin.c:226:gst_plugin_register_static: added static plugin "staticeleme
nts", result: 1
0:00:00.004906564 12755 0x37280 INFO GST_REGISTRY gstregistry.c:1738:ensure_current_registry: reading registry cache: /srv/maverick/
.cache/gstreamer-1.0/registry.armv7l.bin
0:00:00.005417853 12755 0x37280 INFO GST_REGISTRY gstregistrybinary.c:537:priv_gst_registry_binary_read_cache: Unable to mmap file /
srv/maverick/.cache/gstreamer-1.0/registry.armv7l.bin : Failed to open file '/srv/maverick/.cache/gstreamer-1.0/registry.armv7l.bin': open() failed: No such file or direct
ory
0:00:00.005471145 12755 0x37280 INFO GST_REGISTRY gstregistrybinary.c:547:priv_gst_registry_binary_read_cache: Unable to read file /
srv/maverick/.cache/gstreamer-1.0/registry.armv7l.bin : Failed to open file '/srv/maverick/.cache/gstreamer-1.0/registry.armv7l.bin': No such file or directory
0:00:00.005501561 12755 0x37280 INFO GST_REGISTRY gstregistry.c:1594:scan_and_update_registry: Validating plugins from registry cach
e: /srv/maverick/.cache/gstreamer-1.0/registry.armv7l.bin
** (gst-plugin-scanner:12756): CRITICAL **: gi.repository.Gst is no dict
0:00:01.728468407 12755 0x37280 INFO GST_REGISTRY gstregistry.c:1705:scan_and_update_registry: Registry cache changed. Writing new r
egistry cache
0:00:01.728540032 12755 0x37280 INFO GST_REGISTRY gstregistrybinary.c:368:priv_gst_registry_binary_write_cache: Building binary regi
stry cache image
0:00:01.920471827 12755 0x37280 INFO GST_REGISTRY gstregistrybinary.c:400:priv_gst_registry_binary_write_cache: Writing binary regis
try cache
0:00:02.137670728 12755 0x37280 INFO GST_REGISTRY gstregistrybinary.c:261:gst_registry_binary_cache_finish: Wrote binary registry ca
che
0:00:02.137935226 12755 0x37280 INFO GST_REGISTRY gstregistry.c:1714:scan_and_update_registry: Registry cache written successfully
0:00:02.137977060 12755 0x37280 INFO GST_REGISTRY gstregistry.c:1773:ensure_current_registry: registry reading and updating done, re
sult = 1
0:00:02.138021643 12755 0x37280 INFO GST_INIT gst.c:720:init_post: GLib runtime version: 2.48.1
0:00:02.138071184 12755 0x37280 INFO GST_INIT gst.c:722:init_post: GLib headers version: 2.48.1
0:00:02.138114517 12755 0x37280 INFO GST_INIT gst.c:723:init_post: initialized GStreamer successfully
** (gst-inspect-1.0:12755): CRITICAL **: gi.repository.Gst is no dict
0:00:02.337317658 12755 0x37280 WARN GST_PLUGIN_LOADING gstplugin.c:526:gst_plugin_register_func: plugin "/srv/maverick/software/
gstreamer/lib/gstreamer-1.0/libgstpythonplugin.so" failed to initialise
Could not load plugin file: File "/srv/maverick/software/gstreamer/lib/gstreamer-1.0/libgstpythonplugin.so" appears to be a GStreamer plugin, but it failed to initialize
```
Version: 1.10.xhttps://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/30test-multicast: Does not seem to work work2021-09-24T11:03:50ZBugzilla Migration Usertest-multicast: Does not seem to work work## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#773182)](https://bugzilla.gnome.org/show_bug.cgi?id=773182)**
## Description
I can playback on master stream hosted by test-multicast. It seems to work with tes...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#773182)](https://bugzilla.gnome.org/show_bug.cgi?id=773182)**
## Description
I can playback on master stream hosted by test-multicast. It seems to work with test-multicast2. Client is gst-play-1.0
Some warnings I see:
0:00:04.784753182 6718 0x1291540 WARN rtspmedia rtsp-media.c:3606:gst_rtsp_media_suspend: media 0x7f80c403e180 was not prepared
0:00:04.801068498 6718 0x1291540 WARN rtspmedia rtsp-media.c:3867:gst_rtsp_media_set_state: media 0x7f80c403e180 was not preparedhttps://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/18Client network loss causes stream freeze with UDP streams and a shared pipeline2021-09-24T11:03:54ZBugzilla Migration UserClient network loss causes stream freeze with UDP streams and a shared pipeline## Submitted by clo..@..il.com
**[Link to original bug (#761100)](https://bugzilla.gnome.org/show_bug.cgi?id=761100)**
## Description
If a client suddenly loses network connectivity, then it can cause other clients to disconnect or ...## Submitted by clo..@..il.com
**[Link to original bug (#761100)](https://bugzilla.gnome.org/show_bug.cgi?id=761100)**
## Description
If a client suddenly loses network connectivity, then it can cause other clients to disconnect or their streams to freeze IF any one client us utilizing UDP.
This only happens on a shared pipeline, and with UDP as the only set transport.
Steps to reproduce:
1) In gst-rtsp-server/examples/test-video.c, insert "gst_rtsp_media_factory_set_shared(factory, TRUE);" to line 136, and "gst_rtsp_media_factory_set_protocols(factory, GST_RTSP_LOWER_TRANS_UDP);" to line 137.
2) Recompile the gst-rtsp-server examples (navigate to the root directory, and run make)
3) Navigate to the example directory, and run the "test-video" shell script
4) use ifconfig to get your eth0/wlan0 IP address
5) Run the following command in a new terminal: "gst-launch-1.0 rtspsrc location=rtsp://<eth0/wlan0 IP address>:8554/test protocols=0x1 ! fakesink"
6) Open a VLC client, and connect to the localhost IP address - rtsp://127.0.0.1:8554/test
7) In another terminal, execute the following command: "sudo ip link set <eth0/wlan0> down"
This should cause the VLC client to quickly freeze it's current stream. The gst-launch-1.0 client will take some time before it disconnects, but during that time if you reconnect the VLC client to the localhost IP, the stream will continue.
There appears to be an issue with how UDP handles multiple clients on a shared pipeline. I can run any combination of UDP and TCP clients, and experience the issue if ANY one client loses their connection, even if that client is a TCP client. However, if the server is configured to only allow TCP connections, this issue never occurs.
Version: 1.6.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/395osxvideosink crashes on start, OSX 10.13 Beta (17A330h)2021-09-24T13:32:32ZBugzilla Migration Userosxvideosink crashes on start, OSX 10.13 Beta (17A330h)## Submitted by Kirill Novichikhin
**[Link to original bug (#786047)](https://bugzilla.gnome.org/show_bug.cgi?id=786047)**
## Description
Created attachment 357262
High Sierra crash workaround
Crash in _CFRunLoopSetCurrent wh...## Submitted by Kirill Novichikhin
**[Link to original bug (#786047)](https://bugzilla.gnome.org/show_bug.cgi?id=786047)**
## Description
Created attachment 357262
High Sierra crash workaround
Crash in _CFRunLoopSetCurrent when running osxvideosink on last MacOS beta
Assert "Attempting to deallocate CFRunLoop outside of thread destructor -- this is likely an over-release of the run loop"
Apparently releasing previous runloop outside of thread destructor is now frowned upon.
Workaround: retain previous thread runloop before switching (see patch)
$ lldb -- gst-launch-1.0 tcpserversrc port=5001 ! gdpdepay ! h264parse ! avdec_h264 ! osxvideosink
(lldb) target create "gst-launch-1.0"
ruCurrent executable set to 'gst-launch-1.0' (x86_64).
(lldb) settings set -- target.run-args "tcpserversrc" "port=5001" "!" "gdpdepay" "!" "h264parse" "!" "avdec_h264" "!" "osxvideosink"
(lldb) run
Process 33630 launched: '/usr/local/bin/gst-launch-1.0' (x86_64)
Setting pipeline to PAUSED ...
Process 33630 stopped
```
* thread #4, stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
frame #0: 0x00007fff29b73fe5 CoreFoundation`__CFRunLoopDeallocate + 485
CoreFoundation`__CFRunLoopDeallocate:
-> 0x7fff29b73fe5 <+485>: ud2
0x7fff29b73fe7 <+487>: nopw (%rax,%rax)
```
CoreFoundation`__CFRunLoopCleanseSources:
```
0x7fff29b73ff0 <+0>: pushq %rbp
0x7fff29b73ff1 <+1>: movq %rsp, %rbp
Target 0: (gst-launch-1.0) stopped.
(lldb) bt
* thread #4, stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
* frame #0: 0x00007fff29b73fe5 CoreFoundation`__CFRunLoopDeallocate + 485
frame #1: 0x00007fff29c08f9c CoreFoundation`_CFRelease + 300
frame #2: 0x00007fff29b505a6 CoreFoundation`_CFRunLoopSetCurrent + 134
frame #3: 0x00000001007de83e libgstosxvideo.so`-[GstOSXVideoSinkObject nsAppThread] + 30
frame #4: 0x00007fff2bc6c4f8 Foundation`__NSThread__start__ + 1197
frame #5: 0x00007fff517ae6c1 libsystem_pthread.dylib`_pthread_body + 340
frame #6: 0x00007fff517ae56d libsystem_pthread.dylib`_pthread_start + 377
frame #7: 0x00007fff517adc5d libsystem_pthread.dylib`thread_start + 13
0x7fff29b73fd7 <+471>: leaq 0x310d5e(%rip), %rax ; "Attempting to deallocate CFRunLoop outside of thread destructor -- this is likely an over-release of the run loop"
0x7fff29b73fde <+478>: movq %rax, 0x5a372ac3(%rip) ; gCRAnnotations + 8
-> 0x7fff29b73fe5 <+485>: ud2
0x7fff29b73fe7 <+487>: nopw (%rax,%rax)
```
**Patch 357262**, "High Sierra crash workaround":
[runloop.patch](/uploads/a95cbe24c3f19c28ebd6c7ac7adf1644/runloop.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/327user-agent duplicated in rtspsrc header2021-09-24T13:32:04ZBugzilla Migration Useruser-agent duplicated in rtspsrc header## Submitted by Stuart
**[Link to original bug (#774806)](https://bugzilla.gnome.org/show_bug.cgi?id=774806)**
## Description
Created attachment 340464
Quick work around fix
The commit from:
https://bugzilla.gnome.org/sh...## Submitted by Stuart
**[Link to original bug (#774806)](https://bugzilla.gnome.org/show_bug.cgi?id=774806)**
## Description
Created attachment 340464
Quick work around fix
The commit from:
https://bugzilla.gnome.org/show_bug.cgi?id=750101
causes rtspsrc to add two 'user-agents' to the rtsp header.
This causes problems with some rtsp servers (tested with Panasonic cameras) as they reply back 400 (Bad Request) and hence the stream does not connect (viewable in logs as well as wireshark).
I've tested with v1.6, however, believe the issue to remain in master (I'll try and get round to testing with master when I can!).
It appears that gst_rtsp_ext_list_before_send() does not check whether any initialisation has been done already and hence just adds what it gets from the iface.
So far I've just added some code to check if there's multiple GST_RTSP_HDR_USER_AGENT's in the message header in gst_rtspsrc_try_send() and remove the header value if needed. A better solution would be to add functionality to either have gst_rtsp_ext_list_before_send() check whether something has been already initialised, or check against rtsp_headers[] to see if there are multiples of headers when there shouldn't be and remove the latest.
Any pointers would be helpful on where best to implement this!
Cheers,
Stu
**Patch 340464**, "Quick work around fix":
[GstRTSPSrc_Remove_Dup_UserData.patch](/uploads/eff43e2eb8c3d4965c992fafd35c15cb/GstRTSPSrc_Remove_Dup_UserData.patch)
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/666ksvideosrc: Device Monitor shows "video/x-raw,format=(string)H264" caps inste...2021-09-24T14:36:08ZBugzilla Migration Userksvideosrc: Device Monitor shows "video/x-raw,format=(string)H264" caps instead of "video/x-h264" for Logitech C920## Submitted by Marcos Kintschner
**[Link to original bug (#793939)](https://bugzilla.gnome.org/show_bug.cgi?id=793939)**
## Description
I'm using a webcam (Logitech C920) on Windows 10. Device monitor shows some caps containing "vi...## Submitted by Marcos Kintschner
**[Link to original bug (#793939)](https://bugzilla.gnome.org/show_bug.cgi?id=793939)**
## Description
I'm using a webcam (Logitech C920) on Windows 10. Device monitor shows some caps containing "video/x-raw, format(string)=H264", which AFAIK is not valid (it should be "video/x-h264").
Here are the full caps I got from device monitor:
___
gst-device-monitor-1.0.exe
Probing devices...
Device found:
name : HD Pro Webcam C920
class : Video/Source
caps : video/x-raw, format=(string)YUY2, width=(int)640, height=(int)480, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)160, height=(int)90, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)160, height=(int)120, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)176, height=(int)144, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)12/11;
video/x-raw, format=(string)YUY2, width=(int)320, height=(int)180, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)320, height=(int)240, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)352, height=(int)288, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)12/11;
video/x-raw, format=(string)YUY2, width=(int)432, height=(int)240, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)640, height=(int)360, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)800, height=(int)448, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)800, height=(int)600, framerate=(fraction)[ 5/1, 24/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)864, height=(int)480, framerate=(fraction)[ 5/1, 24/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)960, height=(int)720, framerate=(fraction)[ 5/1, 15/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)1024, height=(int)576, framerate=(fraction)[ 5/1, 15/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)1280, height=(int)720, framerate=(fraction)[ 5/1, 10/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)1600, height=(int)896, framerate=(fraction)[ 5/1, 15/2 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)1920, height=(int)1080, framerate=(fraction)5/1, pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)2304, height=(int)1296, framerate=(fraction)2/1, pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)2304, height=(int)1536, framerate=(fraction)2/1, pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)640, height=(int)480, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)160, height=(int)90, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)160, height=(int)120, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)176, height=(int)144, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)12/11;
video/x-raw, format=(string)H264, width=(int)320, height=(int)180, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)320, height=(int)240, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)352, height=(int)288, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)12/11;
video/x-raw, format=(string)H264, width=(int)432, height=(int)240, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)640, height=(int)360, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)800, height=(int)448, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)800, height=(int)600, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)864, height=(int)480, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)960, height=(int)720, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)1024, height=(int)576, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)1280, height=(int)720, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)1600, height=(int)896, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)1920, height=(int)1080, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)640, height=(int)480, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)160, height=(int)90, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)160, height=(int)120, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)176, height=(int)144, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)12/11;
image/jpeg, width=(int)320, height=(int)180, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)320, height=(int)240, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)352, height=(int)288, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)12/11;
image/jpeg, width=(int)432, height=(int)240, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)640, height=(int)360, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)800, height=(int)448, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)800, height=(int)600, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)864, height=(int)480, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)960, height=(int)720, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)1024, height=(int)576, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)1280, height=(int)720, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)1600, height=(int)896, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)1920, height=(int)1080, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
gst-launch-1.0 ksvideosrc device-path="\\\\\?\\usb\#vid_046d\&pid_082d\&mi_00\#7\&38a25b45\&0\&0000\#\{6994ad05-93ef-11d0-a3cc-00a0c9223196\}\\global" ! ...
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/385adaptivedemux: Provide API for being able to set properties on internal HTTP ...2021-09-24T14:34:20ZBugzilla Migration Useradaptivedemux: Provide API for being able to set properties on internal HTTP (and other) sources## Submitted by pot..@..ty.com
**[Link to original bug (#765986)](https://bugzilla.gnome.org/show_bug.cgi?id=765986)**
## Description
I hope you will forgive me that I'm not good at English.
I have been using the version 1.8.0 ...## Submitted by pot..@..ty.com
**[Link to original bug (#765986)](https://bugzilla.gnome.org/show_bug.cgi?id=765986)**
## Description
I hope you will forgive me that I'm not good at English.
I have been using the version 1.8.0 of gstreamer.
Now, I am building a pipeline to play the Http Live Streaming(HLS) video.
the http protocol can play on this pipeline.
gst-launch-1.0 souphttpsrc location=http://path/to/hls.m3u8 ! decodebin ! videoconvert ! autovideosink
but, https protocol can't play.
gst-launch-1.0 souphttpsrc ssl-strict=false location=https://path/to/hls.m3u8 ! decodebin ! videoconvert ! autovideosink
By the way, in the case of the mp4 can be played on http protocol.
gst-launch-1.0 souphttpsrc ssl-strict=false location=https://path/to/movie.mp4 ! decodebin ! videoconvert ! autovideosink
Please pointed out if there is a mistake to building a pipeline.
Version: 1.8.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/36subparse: add support for external SSA/ASS subtitles2021-09-24T13:20:11ZBugzilla Migration Usersubparse: add support for external SSA/ASS subtitles## Submitted by Ilya K
**[Link to original bug (#625113)](https://bugzilla.gnome.org/show_bug.cgi?id=625113)**
## Description
Can't open subtitles in gstreamer (totem mostly) because of this error. There are similar bugs here: https...## Submitted by Ilya K
**[Link to original bug (#625113)](https://bugzilla.gnome.org/show_bug.cgi?id=625113)**
## Description
Can't open subtitles in gstreamer (totem mostly) because of this error. There are similar bugs here: https://bugzilla.gnome.org/show_bug.cgi?id=587704 and here: https://bugs.launchpad.net/gst-plugins-base/+bug/402221
Running latest GStreamer and totem on ubuntu maverick
That's the full log of what happens when I run Totem with debug level 2:
(totem:2989): GLib-GObject-WARNING **: value "10752000" of type `guint' is invalid or out of range for property `connection-speed' of type `guint'
0:00:08.900728007 2989 0x8ac5080 WARN decodebin2 gstdecodebin2.c:1916:type_found:<decodebin21> error: Этот файл является текстовым
0:00:08.900758696 2989 0x8ac5080 WARN decodebin2 gstdecodebin2.c:1916:type_found:<decodebin21> error: decodebin2 cannot decode plain text files
0:00:08.901170990 2989 0x8ea76e0 WARN basesrc gstbasesrc.c:2550:gst_base_src_loop:<source> error: Внутренняя ошибка передачи данных.
0:00:08.901193324 2989 0x8ea76e0 WARN basesrc gstbasesrc.c:2550:gst_base_src_loop:<source> error: streaming task paused, reason not-linked (-1)
0:00:08.906839287 2989 0x8ef7a10 WARN qtdemux qtdemux_types.c:170:qtdemux_type_get: unknown QuickTime node type iods
0:00:08.906880790 2989 0x8ef7a10 WARN qtdemux qtdemux_types.c:170:qtdemux_type_get: unknown QuickTime node type avc1
0:00:08.906894991 2989 0x8ef7a10 WARN qtdemux qtdemux_types.c:170:qtdemux_type_get: unknown QuickTime node type avcC
0:00:08.906908383 2989 0x8ef7a10 WARN qtdemux qtdemux_types.c:170:qtdemux_type_get: unknown QuickTime node type btrt
0:00:08.906928473 2989 0x8ef7a10 WARN qtdemux qtdemux_types.c:170:qtdemux_type_get: unknown QuickTime node type chpl
0:00:08.909919508 2989 0x8ef7a10 WARN qtdemux qtdemux.c:5810:qtdemux_parse_trak:<qtdemux1> unknown version 00000000
0:00:08.958753741 2989 0x8ac5080 WARN totem bacon-video-widget-gst-0.10.c:2093:bvw_bus_message_cb: Warning message: warning message from element 'decodebin21': GstMessageWarning, gerror=(GError)NULL, debug=(string)"gstdecodebin2.c\(1916\):\ type_found\ \(\):\ /GstPlayBin2:play/GstURIDecodeBin:uridecodebin1/GstDecodeBin2:decodebin21:\012decodebin2\ cannot\ decode\ plain\ text\ files";
0:00:08.981539951 2989 0x8f4f330 WARN pulse pulsesink.c:558:gst_pulsering_stream_underflow_cb:<autoaudiosink2-actual-sink-pulse> Got underflow
0:00:08.984938230 2989 0x8f4f330 WARN pulse pulsesink.c:558:gst_pulsering_stream_underflow_cb:<autoaudiosink2-actual-sink-pulse> Got underflow
0:00:08.985001837 2989 0x8f4f330 WARN pulse pulsesink.c:558:gst_pulsering_stream_underflow_cb:<autoaudiosink2-actual-sink-pulse> Got underflow
0:00:08.985043041 2989 0x8f4f330 WARN pulse pulsesink.c:558:gst_pulsering_stream_underflow_cb:<autoaudiosink2-actual-sink-pulse> Got underflow
0:00:08.985081469 2989 0x8f4f330 WARN pulse pulsesink.c:558:gst_pulsering_stream_underflow_cb:<autoaudiosink2-actual-sink-pulse> Got underflow
0:00:09.054364084 2989 0x8ac5080 WARN totem bacon-video-widget-gst-0.10.c:1604:bvw_handle_element_message: Unhandled element message playbin2-stream-changed from play: element message from element 'play': playbin2-stream-changed, uri=(string)".../video.mp4", suburi=(string)".../video.ass";
(cut off the paths as they're too long)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2802mpegtsmux: mux private data streams2023-10-01T20:31:56ZBugzilla Migration Usermpegtsmux: mux private data streams## Submitted by Martijn Grendelman
**[Link to original bug (#673582)](https://bugzilla.gnome.org/show_bug.cgi?id=673582)**
## Description
Mpegtsdemux is capable of demuxing private data streams, like subtitles and teletext, but mpeg...## Submitted by Martijn Grendelman
**[Link to original bug (#673582)](https://bugzilla.gnome.org/show_bug.cgi?id=673582)**
## Description
Mpegtsdemux is capable of demuxing private data streams, like subtitles and teletext, but mpegtsmux is not capable of muxing them. So, if you want to transcode a TS, but keep all non-audio/video streams as-is, this is not possible.
This is a request to add private data stream support to mpegtsmux.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2742qtdemux: Support chapters and provide a GstToc2023-07-01T19:20:38ZBugzilla Migration Userqtdemux: Support chapters and provide a GstToc## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#540887)](https://bugzilla.gnome.org/show_bug.cgi?id=540887)**
## Description
There's currently no chapters support in qtdemux. This could be used to browse in files ...## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#540887)](https://bugzilla.gnome.org/show_bug.cgi?id=540887)**
## Description
There's currently no chapters support in qtdemux. This could be used to browse in files such as:
http://downloads.oreilly.com/make/MAKE_2005-07-18.m4b
### Depends on
* [Bug 540890](https://bugzilla.gnome.org/show_bug.cgi?id=540890)
### Blocking
* [Bug 163546](https://bugzilla.gnome.org/show_bug.cgi?id=163546)
* [Bug 328298](https://bugzilla.gnome.org/show_bug.cgi?id=328298)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2655uridecodebin: Add properties and documentation for better control over buffering2023-08-03T12:52:05ZBugzilla Migration Useruridecodebin: Add properties and documentation for better control over buffering## Submitted by Carlos Rafael Giani
**[Link to original bug (#762125)](https://bugzilla.gnome.org/show_bug.cgi?id=762125)**
## Description
Created attachment 321347
uridecodebin patch for enhanced buffering control
Currently,...## Submitted by Carlos Rafael Giani
**[Link to original bug (#762125)](https://bugzilla.gnome.org/show_bug.cgi?id=762125)**
## Description
Created attachment 321347
uridecodebin patch for enhanced buffering control
Currently, there are only two properties for controlling the buffering: buffer-size and buffer-duration. Properties for the low/high percentage thresholds are missing. Also, the default value for buffer-size and buffer-duration is -1, which means "automatic/default". It is not obvious what this exactly means, and relies on hardcoded internal values.
Furthermore, buffer-duration conflates two distinct concepts: its value is used both for bitrate-based and for input data rate based buffer size estimation. As a result, a buffer-duration value of for example 5 seconds can either mean a buffer size of bitrate*5 seconds , or in case of slow connections, in-data-rate*5 seconds, whichever is lower. In many cases, it is desirable to use only one of these two estimations.
The exact way how buffering behaves, how the properties work, and how it should be used is not documented.
This is the first version of a patch that deprecates buffer-size and buffer-duration in favor of three new properties: max-buffer-size, max-buffering-duration, and buffer-estimate-duration.
The new properties work as follows:
* max-buffer-size: The upper limit for the buffer size, in bytes; this value is passed to the internal queue/decodebin as the "max-size-bytes" property; default value is 10 MB
* max-buffering-duration: The in-data-rate*duration estimate mentioned above; this value is passed to the internal queue/decodebin as the "max-size-time" property, but it is *not* used for bitrate based estimations; default value is 0 (= disables data rate based estimates)
* buffer-estimate-duration: The bitrate*duration estimate mentioned above; this value is not passed to the internal queue, and used only if a bitrate tag is encountered; default value is 6.5 seconds
Out of these three, the lowest size (in bytes) is picked.
The patch also makes it possible to set these property during playback; the buffer size will be readjusted on the fly.
Properties for low/high percentage are also introduced. Default values are: low 5%, high 5%. Together with the default values for the other three properties, this means buffering messages will reach 100% once 1.5 seconds are buffered. During playback, if the source can deliver data faster than realtime, additional 5 second can be buffered on the fly. This makes streaming playback more robust against network bandwidth drops without having to let the user wait too long for buffering to finish.
gtkdoc documentation for how to use these new properties and how configuring buffer size works is also added.
Also, a new "will-post-buffering" signal is added. This is emitted whenever uridecodebin sets the "use-buffering" property of an internal queue to TRUE. This is useful for applications to let them know that they should *not* switch to PLAYING just yet, because buffering messages *will* be posted soon. This prevents the possibility that the PLAYING state is reached, playback goes on briefly, and then the application receives the first BUFFERING message, and pauses playback again.
In subsequent patches, playbin could also get these new properties (they'd be forwarded to uridecodebin just like buffer-size and buffer-duration are now), and the new signal. Another planned addition is a "current-buffer-level" property; however, this first requires a patch for multiqueue, since it doesn't have any property like that (queue2 does have "current-level-bytes"). Also, several parsers such as flacparse, wavparse, aiffparse have been found to not push bitrate tags downstream, and therefore also require patching to further improve buffering behavior.
**Patch 321347**, "uridecodebin patch for enhanced buffering control":
[0001-uridecodebin-Add-properties-and-signals-for-better-c.patch](/uploads/dab7fd226cd0303c015cf427dd222271/0001-uridecodebin-Add-properties-and-signals-for-better-c.patch)Edward HerveyEdward Herveyhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1645Opus: playback gain always relative to EBU R128 level (-23db LUFS), must be p...2023-01-04T00:28:23ZBugzilla Migration UserOpus: playback gain always relative to EBU R128 level (-23db LUFS), must be played 5db louder to match ReplayGain level (-18db LUFS) when using ReplayGain## Submitted by Nikolaus Waxweiler `@madig`
**[Link to original bug (#753275)](https://bugzilla.gnome.org/show_bug.cgi?id=753275)**
## Description
(not sure if this is the correct place to ask for this)
I use Clementine (GStrea...## Submitted by Nikolaus Waxweiler `@madig`
**[Link to original bug (#753275)](https://bugzilla.gnome.org/show_bug.cgi?id=753275)**
## Description
(not sure if this is the correct place to ask for this)
I use Clementine (GStreamer-based) and ReplayGain all my music. I noticed that while playing around with the new Opus format, those files are played much quieter than music in other formats. After digging around, I found: Opus files are by design always normalized to -23db LUFS (R128), while ReplayGain defaults to -18db LUFS. Foobar2000 seems to simply preamp these files +5db when playing. Could GStreamer do the same? Or maybe take an argument of what reference level to use so players can set and forget it?
(Maybe related: [Bug 751534](https://bugzilla.gnome.org/show_bug.cgi?id=751534))https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/74vaapipostproc: Does not maintain aspect ratio when scaling2021-09-24T12:23:08ZBugzilla Migration Uservaapipostproc: Does not maintain aspect ratio when scaling## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#790149)](https://bugzilla.gnome.org/show_bug.cgi?id=790149)**
## Description
When vaapipostproc is being used (notably through vaapidecodebin), the vaapipostpro...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#790149)](https://bugzilla.gnome.org/show_bug.cgi?id=790149)**
## Description
When vaapipostproc is being used (notably through vaapidecodebin), the vaapipostproc may endup scaling the video. The problem is that the scaling does not maintain the aspect ratio, which is totally unexpected default behaviour. On can illustrace this with a non scaling display sink.
gst-launch-1.0 videotestsrc ! video/x-raw,width=320,height=240 ! vaapipostproc ! ximagesink
In comparison with:
gst-launch-1.0 videotestsrc ! video/x-raw,width=320,height=240 ! videoscale ! ximagesinkhttps://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/69vaapi H.264 decode intra-refresh doesn't work2021-09-24T12:23:06ZBugzilla Migration Uservaapi H.264 decode intra-refresh doesn't work## Submitted by hol..@..ob.com
**[Link to original bug (#787261)](https://bugzilla.gnome.org/show_bug.cgi?id=787261)**
## Description
If vaapih264dec is used to decode a low-latency stream with intra-refresh all frames are dropped. ...## Submitted by hol..@..ob.com
**[Link to original bug (#787261)](https://bugzilla.gnome.org/show_bug.cgi?id=787261)**
## Description
If vaapih264dec is used to decode a low-latency stream with intra-refresh all frames are dropped.
Following quick hack works but may break all other things (gstvaapidecoder_h264.c).
.....
priv->decoder_state |= sps_pi->state;
if (!(priv->decoder_state & GST_H264_VIDEO_STATE_GOT_I_FRAME)) {
/* removed don't wait for a valid I-Frame (intra refresh problem)
if (priv->decoder_state & GST_H264_VIDEO_STATE_GOT_P_SLICE)
goto drop_frame;
*/
.....https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/497multiudpsink not works properly2021-09-24T13:33:10ZBugzilla Migration Usermultiudpsink not works properly## Submitted by Mike
**[Link to original bug (#796939)](https://bugzilla.gnome.org/show_bug.cgi?id=796939)**
## Description
gst-launch-1.0 uridecodebin uri=\"file:///home/user/file.mp3\" ! tee name=t ! queue ! volume name=localVol !...## Submitted by Mike
**[Link to original bug (#796939)](https://bugzilla.gnome.org/show_bug.cgi?id=796939)**
## Description
gst-launch-1.0 uridecodebin uri=\"file:///home/user/file.mp3\" ! tee name=t ! queue ! volume name=localVol ! autoaudiosink sync=false t. ! queue ! audioconvert ! rtpL16pay ! multiudpsink clients=192.168.0.58:7000
This pipeline fails In case of 192.168.0.58 is switched off instead of sounds just to autoaudiosink as tee.
In case 192.168.0.58 is online, even if receiving pipeline if switched off - local sink (autoaudiosink) sounds as expected.
This problem is observed in Gstreamer 1.14.1 as well in 1.14.2, However in 1.8.3 there is no such issue.
Version: 1.14.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/435flacenc: add md5 checksum to STREAMINFO header2021-09-24T13:32:51ZBugzilla Migration Userflacenc: add md5 checksum to STREAMINFO header## Submitted by hzt..@..il.com
**[Link to original bug (#792985)](https://bugzilla.gnome.org/show_bug.cgi?id=792985)**
## Description
I'm using Sound-Juicer on Fedora 27 with GStreamer Core Library version 1.12.4. The created FLAC f...## Submitted by hzt..@..il.com
**[Link to original bug (#792985)](https://bugzilla.gnome.org/show_bug.cgi?id=792985)**
## Description
I'm using Sound-Juicer on Fedora 27 with GStreamer Core Library version 1.12.4. The created FLAC files are missing the MD5 signature in their header, tested with flac 1.3.2, see below:
>flac -t Disc_1_-_01_-_Waiting_for_a_Break.flac
>Disc_1_-_01_-_Waiting_for_a_Break.flac: WARNING, cannot check MD5 signature since it was unset in the STREAMINFO
>ok
Apparently, this was already reported in the past, but not fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=961881
https://bugzilla.gnome.org/show_bug.cgi?id=727802
https://bugzilla.gnome.org/show_bug.cgi?id=785558
Version: 1.12.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/340matroska-mux: produces corrupted files with empty tracks2022-02-17T13:23:04ZBugzilla Migration Usermatroska-mux: produces corrupted files with empty tracks## Submitted by sancane
**[Link to original bug (#776902)](https://bugzilla.gnome.org/show_bug.cgi?id=776902)**
## Description
It seems that there is a bug when generating the muxer headers when an EOS is received and not media has ...## Submitted by sancane
**[Link to original bug (#776902)](https://bugzilla.gnome.org/show_bug.cgi?id=776902)**
## Description
It seems that there is a bug when generating the muxer headers when an EOS is received and not media has been processed previously.
You can try this issue with gst-launch:
$GST_DEBUG=2 gst-launch-1.0 videotestsrc num-buffers=0 ! x264enc ! .video_0 matroskamux ! filesink sync=FALSE async=FALSE location="file.mkv"
0:00:00.032486501 30736 0x24c3370 WARN matroskamux matroska-mux.c:3333:gst_matroska_mux_finish:0x24c4a00 unable to get final track duration
The resulting file.mkv is a not playable file:
$gst-play-1.5 file.mkv
Press 'k' to see a list of keyboard shortcuts.
Now playing /home/sancane/twilio/sources/vms-media-server/build/file.mkv
0:00:00.026630030 30784 0x7fae40130990 ERROR ebmlread ebml-read.c:152:gst_ebml_peek_id_length:`<matroskademux0>` Invalid EBML ID size tag (0x0) at position 244 (0xf4)
0:00:00.026777265 30784 0x7fae40130990 ERROR decodebin gstdecodebin2.c:3069:no_more_pads_cb:`<decodebin0>` can't find group for element
ffprobe gives next info:
$ ffprobe file.mkv
ffprobe version 2.8.10-0ubuntu0.16.04.1 Copyright (c) 2007-2016 the FFmpeg developers
built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.4) 20160609
configuration: --prefix=/usr --extra-version=0ubuntu0.16.04.1 --build-suffix=-ffmpeg --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --cc=cc --cxx=g++ --enable-gpl --enable-shared --disable-stripping --disable-decoder=libopenjpeg --disable-decoder=libschroedinger --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzvbi --enable-openal --enable-opengl --enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzmq --enable-frei0r --enable-libx264 --enable-libopencv
libavutil 54. 31.100 / 54. 31.100
libavcodec 56. 60.100 / 56. 60.100
libavformat 56. 40.101 / 56. 40.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 40.101 / 5. 40.101
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.101 / 1. 2.101
libpostproc 53. 3.100 / 53. 3.100
[matroska,webm @ 0x17e9c80] Read error at pos. 245 (0xf5)
[matroska,webm @ 0x17e9c80] Duplicate element
[matroska,webm @ 0x17e9c80] Read error at pos. 77 (0x4d)
[matroska,webm @ 0x17e9c80] Read error at pos. 105 (0x69)
[matroska,webm @ 0x17e9c80] Duplicate element
[matroska,webm @ 0x17e9c80] Read error at pos. 245 (0xf5)
[matroska,webm @ 0x17e9c80] Duplicate element
Last message repeated 1 times
file.mkv: End of file
I'm not familiarized with matroska, but perhaps one could expect not to display anything when trying to play a video like this instead of getting this amount of errors, I mean, an empty media file should not have to end up with these errors, they simply should play nothing because they contain nothing. Don't they?https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/270alpha: doesn't correctly work with black or white in custom mode2021-09-24T13:31:42ZBugzilla Migration Useralpha: doesn't correctly work with black or white in custom mode## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#766060)](https://bugzilla.gnome.org/show_bug.cgi?id=766060)**
## Description
reference command - replace yellow bar in test pattern 0 with circles from other video...## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#766060)](https://bugzilla.gnome.org/show_bug.cgi?id=766060)**
## Description
reference command - replace yellow bar in test pattern 0 with circles from other videotestsrc, works as expected:
gst-launch-1.0 videotestsrc ! alpha method=3 target-r=255 target-g=255 target-b=0 ! videomixer sink_0::zorder=1 sink_1::zorder=0 name=mixer ! videoconvert ! gtksink videotestsrc pattern=11 ! mixer.
test-commands, white stripe is supposed to be transparent, in fact all others are :)
gst-launch-1.0 videotestsrc ! alpha method=3 target-r=255 target-g=255 target-b=255 ! videomixer sink_0::zorder=1 sink_1::zorder=0 name=mixer ! videoconvert ! gtksink videotestsrc pattern=11 ! mixer.
same exact symptom with black:
gst-launch-1.0 videotestsrc ! alpha method=3 target-r=0 target-g=0 target-b=0 ! videomixer sink_0::zorder=1 sink_1::zorder=0 name=mixer ! videoconvert ! gtksink videotestsrc pattern=11 ! mixer.
slomo suggested it may have something to do with alpha's internal HSV conversion. this sounds likely since pure black and white don't have a defined hue value. i'll take a look
Version: 1.8.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/102qtdemux: Memory usage is proportional to the time duration of m4a files.2021-09-24T13:30:24ZBugzilla Migration Userqtdemux: Memory usage is proportional to the time duration of m4a files.## Submitted by lei..@..il.com
**[Link to original bug (#722639)](https://bugzilla.gnome.org/show_bug.cgi?id=722639)**
## Description
QuickTime stores media data in samples. The number of a samples in m4a
files are huge. For exam...## Submitted by lei..@..il.com
**[Link to original bug (#722639)](https://bugzilla.gnome.org/show_bug.cgi?id=722639)**
## Description
QuickTime stores media data in samples. The number of a samples in m4a
files are huge. For example, a 6hr m4a file has about 950,000 samples.
Because qtdemux.c creates a sample table whose size is proportional to
the number of samples, the sample table could be very big. For an m4a file
6:11:46 long, I got:
"qtdemux qtdemux.c:6306:qtdemux_stbl_init:`<qtdemux0>` allocating
n_samples 960669 * 32 (29.32 MB)"
Indeed, qtdemux has a cap of 50MB for this table:
/* if the sample index is larger than this, something is likely wrong */
#define QTDEMUX_MAX_SAMPLE_INDEX_SIZE (50*1024*1024)
The current design has two problems for m4a files:
1. m4a files with duration greater than 12hrs won't play:
qtdemux qtdemux.c:6306:qtdemux_stbl_init:`<qtdemux0>` allocating
n_samples 1921335 * 32 (58.63 MB)
qtdemux qtdemux.c:6312:qtdemux_stbl_init:`<qtdemux0>` not allocating
index of 1921335 samples, would be larger than 50MB (broken file?)
Such a file can be downloaded at: https://dl.dropboxusercontent.com/u/54923483/White_Noise_320kbps_14Hour.m4a
2. It may impose a memory burden for embedded systems.
Could somebody take a look at this issue and improve qtdemux?
Discussions of this issue can be found at : http://lists.freedesktop.org/archives/gstreamer-devel/2014-January/045660.htmlhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/18[PLUGIN-MOVE] Move assrender to gst-plugins-good2023-10-06T13:25:08ZBugzilla Migration User[PLUGIN-MOVE] Move assrender to gst-plugins-good## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#604067)](https://bugzilla.gnome.org/show_bug.cgi?id=604067)**
## Description
See summary. The plugin is mature now, and together with latest git of gst-plugins-base ...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#604067)](https://bugzilla.gnome.org/show_bug.cgi?id=604067)**
## Description
See summary. The plugin is mature now, and together with latest git of gst-plugins-base it will be automatically used for ASS/SSA subtitles and provides much better visual results because it supports all ASS/SSA features.
There's no test for it and I don't know how one should look, documentation will come in the next days but that won't contain much interesting information (because the element is meant to be automatically used).
### Depends on
* [Bug 610857](https://bugzilla.gnome.org/show_bug.cgi?id=610857)
* [Bug 610904](https://bugzilla.gnome.org/show_bug.cgi?id=610904)
* [Bug 610906](https://bugzilla.gnome.org/show_bug.cgi?id=610906)