GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2023-10-12T18:40:00Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3040ximagesrc: Support changing resolution at runtime2023-10-12T18:40:00ZBugzilla Migration Userximagesrc: Support changing resolution at runtime## Submitted by Snir Sheriber `@snir`
**[Link to original bug (#794761)](https://bugzilla.gnome.org/show_bug.cgi?id=794761)**
## Description
Changing resolution at runtime is not supported when using ximagesrc to create a screenshot...## Submitted by Snir Sheriber `@snir`
**[Link to original bug (#794761)](https://bugzilla.gnome.org/show_bug.cgi?id=794761)**
## Description
Changing resolution at runtime is not supported when using ximagesrc to create a screenshot video stream.
Is it possible to workaround this issue by using additional\alternative plugin?https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/320rtpL16depay, rtpL24depay: support depayloading in place2023-10-12T18:26:04ZBugzilla Migration UserrtpL16depay, rtpL24depay: support depayloading in place## Submitted by Petr Kulhavy
**[Link to original bug (#773833)](https://bugzilla.gnome.org/show_bug.cgi?id=773833)**
## Description
It seems that rtpL16depay, rtpL24depay (and I guess also other rtp-depay functions) are failing to d...## Submitted by Petr Kulhavy
**[Link to original bug (#773833)](https://bugzilla.gnome.org/show_bug.cgi?id=773833)**
## Description
It seems that rtpL16depay, rtpL24depay (and I guess also other rtp-depay functions) are failing to depayload in place. It always allocates a new buffer and copies the payload.
This is the log I'm seeing:
```
0:00:13.489419481 1060 0x1ec5150 DEBUG rtpL16depay gstrtpL16depay.c:243:gst_rtp_L16_depay_process:`<rtpl16depay0>` got payload of 192 bytes
0:00:13.489596481 1060 0x1ec5150 LOG GST_BUFFER gstbuffer.c:798:gst_buffer_new: new 0x75c05370
0:00:13.489760981 1060 0x1ec5150 LOG GST_BUFFER gstbuffer.c:2038:gst_buffer_copy_region: new region copy 0x75c05370 of 0x75c054b0 12-192
0:00:13.490969772 1060 0x1ec5150 LOG GST_BUFFER gstbuffer.c:514:gst_buffer_copy_into: copy 0x75c054b0 to 0x75c05370, offset 12-192/204
--
0:00:13.493352979 1060 0x1ec5150 TRACE GST_LOCKING gstminiobject.c:177:gst_mini_object_lock: lock 0x1ecb690: state 00020000, access_mode 3
0:00:13.493546312 1060 0x1ec5150 DEBUG GST_LOCKING gstminiobject.c:212:gst_mini_object_lock: lock failed 0x1ecb690: state 00020000, access_mode 3
0:00:13.493717020 1060 0x1ec5150 DEBUG GST_MEMORY gstmemory.c:317:gst_memory_map: mem 0x1ecb690: lock 3 failed
0:00:13.493910270 1060 0x1ec5150 TRACE GST_REFCOUNTING gstobject.c:249:gst_object_ref:`<allocatorsysmem0>` 0x1ddc010 ref 6->7
0:00:13.494091270 1060 0x1ec5150 DEBUG GST_MEMORY gstmemory.c:138:gst_memory_init: new memory 0x1ecb578, maxsize:195 offset:0 size:192
0:00:13.494364978 1060 0x1ec5150 DEBUG GST_PERFORMANCE gstallocator.c:462:_sysmem_copy: memcpy 192 memory 0x1ecb690 -> 0x1ecb578
```
And this is the command:
`GST_DEBUG=9 gst-launch-1.0 audiotestsrc is-live=true wave=silence samplesperbuffer=48 ! "audio/x-raw,format=(string)S16BE,rate=(int)48000,channels=(int)2,channel-mask=(int)0x3" ! rtpL16pay ! rtpL16depay ! fakesink
2>&1 | grep -B 5 copy`
It happens in gst_audio_buffer_reorder_channels() when mapping the buffer read-write. It doesn't really matter what the source is, the same happens with udpsrc.
--
The other thing here is that if the channels don't require reordering (like in my case) the buffer shouldn't be remapped read-write. Otherwise the potential buffer copy is redundant.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/303test-segment-seeks hangs on RPi2023-10-12T18:24:17ZBugzilla Migration Usertest-segment-seeks hangs on RPi## Submitted by Patrick
**[Link to original bug (#772066)](https://bugzilla.gnome.org/show_bug.cgi?id=772066)**
## Description
Created attachment 336368
Debug Log file
When using the latest master branch on RPi with Jessie, t...## Submitted by Patrick
**[Link to original bug (#772066)](https://bugzilla.gnome.org/show_bug.cgi?id=772066)**
## Description
Created attachment 336368
Debug Log file
When using the latest master branch on RPi with Jessie, the "test-segment-seek" test in "gst-plugins-good/tests/icles" stops updating the video after a couple of seeks.
To test this just start the test program with a h264 encoded video.
Tested with multiple different video files.
Attached is DEBUG output. I had to compress it, because it's to big otherwise.
**Attachment 336368**, "Debug Log file":
[Debug_log_6.txt.tar.gz](/uploads/b70ca91172a378e57c4c306fa1b87ab8/Debug_log_6.txt.tar.gz)
Version: 1.9.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/338gtk4: Add Gst (GL) Gtk4 plugin2023-10-12T18:18:40ZBugzilla Migration Usergtk4: Add Gst (GL) Gtk4 plugin## Submitted by Yannick Inizan
**[Link to original bug (#776649)](https://bugzilla.gnome.org/show_bug.cgi?id=776649)**
## Description
Created attachment 342658
[PATCH] Add Gst (GL) Gtk4 plugin
Since latest version of Gtk 4 wo...## Submitted by Yannick Inizan
**[Link to original bug (#776649)](https://bugzilla.gnome.org/show_bug.cgi?id=776649)**
## Description
Created attachment 342658
[PATCH] Add Gst (GL) Gtk4 plugin
Since latest version of Gtk 4 works correctly, we can build a plugin with this version.
**Patch 342658**, "[PATCH] Add Gst (GL) Gtk4 plugin":
[0001-Add-Gst-GL-Gtk4-plugin.patch](/uploads/c9ca16d576a27b9b20dc2dcfd7c565d3/0001-Add-Gst-GL-Gtk4-plugin.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/120avidemux: add support for DEFAULT and PERCENT formats to position query2023-10-12T18:08:31ZBugzilla Migration Useravidemux: add support for DEFAULT and PERCENT formats to position query## Submitted by Dirk Van Haerenborgh
**[Link to original bug (#731851)](https://bugzilla.gnome.org/show_bug.cgi?id=731851)**
## Description
Created attachment 278679
proposed patch
This patch adds support for FORMAT_DEFAULT a...## Submitted by Dirk Van Haerenborgh
**[Link to original bug (#731851)](https://bugzilla.gnome.org/show_bug.cgi?id=731851)**
## Description
Created attachment 278679
proposed patch
This patch adds support for FORMAT_DEFAULT and FORMAT_PERCENT in avidemux, and also properly sets the return value to false for other unsupported formats
**Patch 278679**, "proposed patch":
[avidemux_position.patch](/uploads/c583919133c9b6ea08ebf38c0dd00346/avidemux_position.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/176v4l2: Improve URI handler2023-10-12T18:07:37ZBugzilla Migration Userv4l2: Improve URI handler## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#746818)](https://bugzilla.gnome.org/show_bug.cgi?id=746818)**
## Description
Created attachment 300359
v4l2: add uri hander interface
patch against 1.4.5
Gs...## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#746818)](https://bugzilla.gnome.org/show_bug.cgi?id=746818)**
## Description
Created attachment 300359
v4l2: add uri hander interface
patch against 1.4.5
GstUri backported from git in core
~~**Patch 300359**~~, "v4l2: add uri hander interface":
[0001-v4l2-add-GstUri-interface-to-v4l2-elements.patch](/uploads/529f7b48ebdbb064e83eeee1311309fd/0001-v4l2-add-GstUri-interface-to-v4l2-elements.patch)
Version: 1.10.4
### Depends on
* [Bug 779765](https://bugzilla.gnome.org/show_bug.cgi?id=779765)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/194souphttpsrc: add cookie jar2023-10-12T18:04:35ZBugzilla Migration Usersouphttpsrc: add cookie jar## Submitted by Eunhae Choi
**[Link to original bug (#751371)](https://bugzilla.gnome.org/show_bug.cgi?id=751371)**
## Description
In case of adaptive streaming, there is a additional http src element in the adaptive demux to downlo...## Submitted by Eunhae Choi
**[Link to original bug (#751371)](https://bugzilla.gnome.org/show_bug.cgi?id=751371)**
## Description
In case of adaptive streaming, there is a additional http src element in the adaptive demux to download content fragments.
In some cases, user-agent and cookie is needed to set to connect the http server but there is no way to get the current user-agent and cookie data from souphttpsrc.
I think souphttpsrc should handle the custom query of user-agent and cookies.
### Blocking
* [Bug 751372](https://bugzilla.gnome.org/show_bug.cgi?id=751372)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/231libgstosxvideosink.so causes hangs on plugin load on OS X 10.62023-10-12T17:58:02ZBugzilla Migration Userlibgstosxvideosink.so causes hangs on plugin load on OS X 10.6## Submitted by Ryan Hendrickson `@rhendric`
**[Link to original bug (#756918)](https://bugzilla.gnome.org/show_bug.cgi?id=756918)**
## Description
(This is with the patch that I submitted in https://bugzilla.gnome.org/show_bug.cgi?...## Submitted by Ryan Hendrickson `@rhendric`
**[Link to original bug (#756918)](https://bugzilla.gnome.org/show_bug.cgi?id=756918)**
## Description
(This is with the patch that I submitted in https://bugzilla.gnome.org/show_bug.cgi?id=756154, for what it's worth.)
Any gst-launch, gst-inspect, etc. hangs on startup as long as libgstosxvideosink.so is in the plugin dir. When I manually remove it, problem goes away.
Version: 1.6.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/278qtdemux: early eos with totem-video-thumbnailer2023-10-12T17:54:26ZBugzilla Migration Userqtdemux: early eos with totem-video-thumbnailer## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#767406)](https://bugzilla.gnome.org/show_bug.cgi?id=767406)**
## Description
gstreamer1-plugins-bad-free-1.8.1-1.fc24.x86_64
gstreamer1-plugins-base-1.8.1-1.fc24.x...## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#767406)](https://bugzilla.gnome.org/show_bug.cgi?id=767406)**
## Description
gstreamer1-plugins-bad-free-1.8.1-1.fc24.x86_64
gstreamer1-plugins-base-1.8.1-1.fc24.x86_64
gstreamer1-plugins-good-1.8.1-1.fc24.x86_64
gstreamer1-libav-1.6.3-1.fc23.x86_64
gstreamer1-1.8.1-1.fc24.x86_64
With the file at:
https://people.gnome.org/~hadess/IMG_0205.MOV
$ ./totem-video-thumbnailer IMG_0205.MOV foo.png
** (totem-video-thumbnailer:26874): WARNING **: Could not take screenshot: failed to retrieve or convert video frame
** (totem-video-thumbnailer:26874): WARNING **: Could not take screenshot: failed to retrieve or convert video frame
** (totem-video-thumbnailer:26874): WARNING **: Could not take screenshot: failed to retrieve or convert video frame
** (totem-video-thumbnailer:26874): WARNING **: Could not take screenshot: failed to retrieve or convert video frame
** (totem-video-thumbnailer:26874): WARNING **: Could not take screenshot: failed to retrieve or convert video frame
totem-video-thumbnailer couldn't get a picture from 'IMG_0205.MOV'
This error happens when:
g_signal_emit_by_name (play, "convert-sample", to_caps, &sample);
returns a NULL sample.
Version: 1.8.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/388rtspsrc: reduce default latency from 2.0 secs to 0.5 secs2023-10-12T17:51:39ZBugzilla Migration Userrtspsrc: reduce default latency from 2.0 secs to 0.5 secs## Submitted by Tim Müller `@tpm`
**[Link to original bug (#784785)](https://bugzilla.gnome.org/show_bug.cgi?id=784785)**
## Description
Created attachment 355318
rtspsrc: reduce default latency from 2.0 secs to 0.5 secs
By d...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#784785)](https://bugzilla.gnome.org/show_bug.cgi?id=784785)**
## Description
Created attachment 355318
rtspsrc: reduce default latency from 2.0 secs to 0.5 secs
By default rtspsrc uses a fairly high default latency of 2 seconds.
I wonder if this really makes sense, and what this is based on.
If there's no Good Reason(tm) then perhaps we should reduce that drastically to something lower, maybe 500ms or even 250ms ?
People who are on very bad networks can still set this to something higher manually.
**Patch 355318**, "rtspsrc: reduce default latency from 2.0 secs to 0.5 secs":
[0001-rtspsrc-reduce-default-latency-from-2.0-secs-to-0.5-.patch](/uploads/f189ee328b755dcc3970016a9ac74065/0001-rtspsrc-reduce-default-latency-from-2.0-secs-to-0.5-.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/390when play a rstp mov, gstomxvideodec get no codec_data for first frame2023-10-12T17:49:50ZBugzilla Migration Userwhen play a rstp mov, gstomxvideodec get no codec_data for first frame## Submitted by leven
**[Link to original bug (#785432)](https://bugzilla.gnome.org/show_bug.cgi?id=785432)**
## Description
when play a rstp mov, omx h264 decoder failed because of gstomxvideodec without codec_data for first frame...## Submitted by leven
**[Link to original bug (#785432)](https://bugzilla.gnome.org/show_bug.cgi?id=785432)**
## Description
when play a rstp mov, omx h264 decoder failed because of gstomxvideodec without codec_data for first frame, it contains sps/pps, they lost!!!!
Version: 1.10.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/397gtkglsink: add "rotate-method" property2023-10-12T17:49:05ZBugzilla Migration Usergtkglsink: add "rotate-method" property## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#786991)](https://bugzilla.gnome.org/show_bug.cgi?id=786991)**
## Description
This should match the capabilities of glimagesink, this includes support for the AffineTr...## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#786991)](https://bugzilla.gnome.org/show_bug.cgi?id=786991)**
## Description
This should match the capabilities of glimagesink, this includes support for the AffineTransformationMeta and the image-orientation tag as well as manual rotation using the property.
I didn't do it in glsinkbin becausse the GL happens in the GTK thread in that case.
Version: 1.12.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/667VmRSS memory keep increasing for interlaced streams while decoding using gst-...2023-10-12T17:45:28Zkudas-swVmRSS memory keep increasing for interlaced streams while decoding using gst-v4l2 decoderFor a long duration interlaced stream, VmRSS memory keeps increasing during decoding.
We have tried in nvidia platform with below pipeline:
gst-launch-1.0 filesrc location = H264_15min_25.ts ! tsdemux ! h264parse ! nvv4l2decoder ! fakesi...For a long duration interlaced stream, VmRSS memory keeps increasing during decoding.
We have tried in nvidia platform with below pipeline:
gst-launch-1.0 filesrc location = H264_15min_25.ts ! tsdemux ! h264parse ! nvv4l2decoder ! fakesink sync = 0
Also tried with odroid board(samsung exynos) with below pipeline:
gst-launch-1.0 filesrc location = H264_15min_25.ts ! tsdemux ! h264parse ! v4l2video10videodec ! fakesink sync = 0
With both the above platform we are observing memory increase.
Logs: (Check RES values):
* PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
* 7897 nvidia 20 0 426256 35636 19720 S 31.2 0.9 0:00.95 gst-launch-1.0
* 7897 nvidia 20 0 426256 61672 19720 S 114.8 1.5 5:16.66 gst-launch-1.0
Probable cause would be that in case of interlaced streams frame->input_buffer(top field+bottom field) count is double w.r.t frame->output_buffer count, and in gstv4l2videodec.c we are doing unref of frames after frame->output_buffer is set, so we are doing unref half number of frames w.r.t actual number of frames.
Reference file:
https://github.com/GStreamer/gst-plugins-good/blob/b4b79a211fc487d4bae5962721ed812713e9a705/sys/v4l2/gstv4l2videodec.c#L749https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/399Memory leak in gstqtmux.c2023-10-12T17:45:20ZBugzilla Migration UserMemory leak in gstqtmux.c## Submitted by Anton Nikolaevsky
**[Link to original bug (#787144)](https://bugzilla.gnome.org/show_bug.cgi?id=787144)**
## Description
Created attachment 358954
proposed fix
Hello!
I have an application which takes vid...## Submitted by Anton Nikolaevsky
**[Link to original bug (#787144)](https://bugzilla.gnome.org/show_bug.cgi?id=787144)**
## Description
Created attachment 358954
proposed fix
Hello!
I have an application which takes video stream from IP camera and streams it as video/mp4 through web-server. The application uses the following pipeline to produce browsers-friendly mp4-stream:
appsrc -> h264parse -> qtmux -> appsink
The problem is the application leaks GstBuffer-s steadily. AddressSanitizer reports the following 2 stacks with direct leaks:
Direct leak of 43792 byte(s) in 161 object(s) allocated from:
` #0` 0x7f97ca5ba73f malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x5473f)
` #1` 0x7f978e613f16 in g_malloc glib-2.42.1/glib/gmem.c:97
` #2` 0x7f978e64b4ec in g_slice_alloc glib-2.42.1/glib/gslice.c:1007
` #3` 0x7f978edce8b3 in gst_buffer_new gstreamer-1.11.2/gst/gstbuffer.c:798
` #4` 0x7f978edcea05 in gst_buffer_new_allocate gstreamer-1.11.2/gst/gstbuffer.c:846
` #5` 0x7f97705743a8 in gst_h264_parse_wrap_nal gst-plugins-bad-1.11.2/gst/videoparsers/gsth264parse.c:424
` #6` 0x7f9770577c7b in gst_h264_parse_process_nal gst-plugins-bad-1.11.2/gst/videoparsers/gsth264parse.c:889
` #7` 0x7f977057a9e3 in gst_h264_parse_handle_frame gst-plugins-bad-1.11.2/gst/videoparsers/gsth264parse.c:1222
` #8` 0x7f9770863093 in gst_base_parse_handle_buffer gstreamer-1.11.2/libs/gst/base/gstbaseparse.c:2145
` #9` 0x7f977086ee72 in gst_base_parse_chain gstreamer-1.11.2/libs/gst/base/gstbaseparse.c:3227
` #10` 0x7f978ee6cd74 in gst_pad_chain_data_unchecked gstreamer-1.11.2/gst/gstpad.c:4205
` #11` 0x7f978ee6e76d in gst_pad_push_data gstreamer-1.11.2/gst/gstpad.c:4457
` #12` 0x7f978ee6f73c in gst_pad_push gstreamer-1.11.2/gst/gstpad.c:4576
` #13` 0x7f97708aed19 in gst_base_src_loop gstreamer-1.11.2/libs/gst/base/gstbasesrc.c:2843
` #14` 0x7f978eee4ede in gst_task_func gstreamer-1.11.2/gst/gsttask.c:335
` #15` 0x7f978eee6e4f in default_func gstreamer-1.11.2/gst/gsttaskpool.c:69
` #16` 0x7f978e667b9d in g_thread_pool_thread_proxy glib-2.42.1/glib/gthreadpool.c:307
` #17` 0x7f978e666eb6 in g_thread_proxy glib-2.42.1/glib/gthread.c:764
` #18` 0x7f97c3b05063 in start_thread /build/glibc-6V9RKT/glibc-2.19/nptl/pthread_create.c:309 (discriminator 2)
Direct leak of 8976 byte(s) in 33 object(s) allocated from:
` #0` 0x7f97ca5ba73f malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x5473f)
` #1` 0x7f978e613f16 in g_malloc glib-2.42.1/glib/gmem.c:97
` #2` 0x7f978e64b4ec in g_slice_alloc glib-2.42.1/glib/gslice.c:1007
` #3` 0x7f978edce8b3 in gst_buffer_new gstreamer-1.11.2/gst/gstbuffer.c:798
` #4` 0x7f97708d109f in gst_byte_writer_reset_and_get_buffer gstreamer-1.11.2/libs/gst/base/gstbytewriter.c:244
` #5` 0x7f9770581b0a in gst_h264_parse_handle_sps_pps_nals gst-plugins-bad-1.11.2/gst/videoparsers/gsth264parse.c:2306
` #6` 0x7f9770582ccf in gst_h264_parse_pre_push_frame gst-plugins-bad-1.11.2/gst/videoparsers/gsth264parse.c:2417
` #7` 0x7f9770866ead in gst_base_parse_push_frame gstreamer-1.11.2/libs/gst/base/gstbaseparse.c:2455
` #8` 0x7f9770865783 in gst_base_parse_handle_and_push_frame gstreamer-1.11.2/libs/gst/base/gstbaseparse.c:2337
` #9` 0x7f9770868e5a in gst_base_parse_finish_frame gstreamer-1.11.2/libs/gst/base/gstbaseparse.c:2678
` #10` 0x7f977057ac44 in gst_h264_parse_handle_frame gst-plugins-bad-1.11.2/gst/videoparsers/gsth264parse.c:1248
` #11` 0x7f9770863093 in gst_base_parse_handle_buffer gstreamer-1.11.2/libs/gst/base/gstbaseparse.c:2145
` #12` 0x7f977086ee72 in gst_base_parse_chain gstreamer-1.11.2/libs/gst/base/gstbaseparse.c:3227
` #13` 0x7f978ee6cd74 in gst_pad_chain_data_unchecked gstreamer-1.11.2/gst/gstpad.c:4205
` #14` 0x7f978ee6e76d in gst_pad_push_data gstreamer-1.11.2/gst/gstpad.c:4457
` #15` 0x7f978ee6f73c in gst_pad_push gstreamer-1.11.2/gst/gstpad.c:4576
` #16` 0x7f97708aed19 in gst_base_src_loop gstreamer-1.11.2/libs/gst/base/gstbasesrc.c:2843
` #17` 0x7f978eee4ede in gst_task_func gstreamer-1.11.2/gst/gsttask.c:335
` #18` 0x7f978eee6e4f in default_func gstreamer-1.11.2/gst/gsttaskpool.c:69
` #19` 0x7f978e667b9d in g_thread_pool_thread_proxy glib-2.42.1/glib/gthreadpool.c:307
` #20` 0x7f978e666eb6 in g_thread_proxy glib-2.42.1/glib/gthread.c:764
` #21` 0x7f97c3b05063 in start_thread /build/glibc-6V9RKT/glibc-2.19/nptl/pthread_create.c:309 (discriminator 2)
With help of additional logs in gst-plugins-good-1.11.2/gst/isomp4/gstqtmux.c it was noticed that the buffers leak when the pipeline is about to stop (on client disconnect) and there were some buffers in GstQTPad::fragment_buffers. Unfortunately, I was not able to find the easy way
to reproduce such conditions with simple gst-launch command line use-case (tried filesrc and rtspsrc).
The proposed fix is attached.
**Patch 358954**, "proposed fix":
[gstqtmux.patch](/uploads/7a1721b87238fc0ab05f385a7f3a1ae3/gstqtmux.patch)
Version: 1.11.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/554GPMF support in mp4mux2023-10-12T16:59:00ZErlend EriksenGPMF support in mp4muxGoPro has open sourced their format for embedding telemetry data into a track in their videos. The format is defined [here](https://github.com/gopro/gpmf-parser). To make use of this format, mp4mux needs to have support for writing the a...GoPro has open sourced their format for embedding telemetry data into a track in their videos. The format is defined [here](https://github.com/gopro/gpmf-parser). To make use of this format, mp4mux needs to have support for writing the additional track with the right moov atom fields.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/556v4l2: Add mapping for big-endian RGB565 (BGR16 in gst)2023-10-12T16:58:10ZNicolas Dufresnev4l2: Add mapping for big-endian RGB565 (BGR16 in gst)Mauro Carvalho Chehab (maintainer of linux-media) ask me why vim2m test driver wasn't detected by GStreamer. So I looked it up, and found a first issue, might only be the tip of the issue, but has to happen to get this test driver runnin...Mauro Carvalho Chehab (maintainer of linux-media) ask me why vim2m test driver wasn't detected by GStreamer. So I looked it up, and found a first issue, might only be the tip of the issue, but has to happen to get this test driver running. This driver only support one capture format, BGR16, which isn't mapped in the v4l2 glue.Nicolas DufresneNicolas Dufresnehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3039v4l2: Add mapping for big-endian RGB565 (BGR16 in gst)2023-10-12T16:58:10ZNicolas Dufresnev4l2: Add mapping for big-endian RGB565 (BGR16 in gst)Mauro Carvalho Chehab (maintainer of linux-media) ask me why vim2m test driver wasn't detected by GStreamer. So I looked it up, and found a first issue, might only be the tip of the issue, but has to happen to get this test driver runnin...Mauro Carvalho Chehab (maintainer of linux-media) ask me why vim2m test driver wasn't detected by GStreamer. So I looked it up, and found a first issue, might only be the tip of the issue, but has to happen to get this test driver running. This driver only support one capture format, BGR16, which isn't mapped in the v4l2 glue.Nicolas DufresneNicolas Dufresnehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/558rtph264depay: Segmentation fault2023-10-12T16:56:19ZJimmy Petterssonrtph264depay: Segmentation faultMy pipeline is as follows:
3 video pipelines with udpsrc are composed into one output frame displayed on the screen.
Simplified pipeline.
```
--[udpsrc]-->[rtpjitterbuffer]-->[decode]-->[queue]-->
--[udpsrc]-->[rtpjitterbuffer]-->[d...My pipeline is as follows:
3 video pipelines with udpsrc are composed into one output frame displayed on the screen.
Simplified pipeline.
```
--[udpsrc]-->[rtpjitterbuffer]-->[decode]-->[queue]-->
--[udpsrc]-->[rtpjitterbuffer]-->[decode]-->[queue]--> [compositor] --> [xvimagesink] ---->
--[udpsrc]-->[rtpjitterbuffer]-->[decode]-->[queue]-->
```
The sefaults happens after 0-10 minutes of running...
```.sh
Thread 20 "rtpjitterbuffer" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f77fff1d0 (LWP 32045)]
memcpy () at ../sysdeps/aarch64/memcpy.S:161
161 ../sysdeps/aarch64/memcpy.S: No such file or directory.
(gdb) bt
#0 memcpy () at ../sysdeps/aarch64/memcpy.S:161
#1 0x0000007fb7ee2938 in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) at /usr/include/aarch64-linux-gnu/bits/string3.h:53
#2 gst_buffer_fill (buffer=buffer@entry=0x7f7c01c570, offset=<optimized out>, offset@entry=0, src=src@entry=0x7f6403e09e, size=size@entry=4294967295) at gstbuffer.c:1840
#3 0x0000007fb1fdd2ec in gst_rtp_h264_depay_process (depayload=0x898860, rtp=0x7f77ffe428) at gstrtph264depay.c:1195
#4 0x0000007fb215329c in gst_rtp_base_depayload_handle_buffer (filter=0x898860, in=0x7f7c021990, bclass=<optimized out>, bclass=<optimized out>) at gstrtpbasedepayload.c:429
#5 0x0000007fb7f1fe04 in gst_pad_chain_data_unchecked (data=0x7f7c021990, type=4112, pad=0x8bcd50) at gstpad.c:4320
#6 gst_pad_push_data (pad=pad@entry=0x8bc1c0, type=type@entry=4112, data=data@entry=0x7f7c021990) at gstpad.c:4576
#7 0x0000007fb7f28a80 in gst_pad_push (pad=0x8bc1c0, buffer=buffer@entry=0x7f7c021990) at gstpad.c:4695
#8 0x0000007fb21b3830 in pop_and_push_next (jitterbuffer=jitterbuffer@entry=0x8bb350, seqnum=seqnum@entry=46479) at gstrtpjitterbuffer.c:3519
#9 0x0000007fb21b45ac in handle_next_buffer (jitterbuffer=0x8bb350) at gstrtpjitterbuffer.c:3618
#10 gst_rtp_jitter_buffer_loop (jitterbuffer=0x8bb350) at gstrtpjitterbuffer.c:4164
#11 0x0000007fb7f5a110 in gst_task_func (task=0x7fa40905f0) at gsttask.c:332
#12 0x0000007fb7d901a4 in ?? () from /lib/aarch64-linux-gnu/libglib-2.0.so.0
#13 0x0000007fb7e223c0 in __glib_assert_msg () from /lib/aarch64-linux-gnu/libglib-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3036The content of release tags differs from released tar files with the same tags2023-10-12T16:41:49ZOmar Al-WadiThe content of release tags differs from released tar files with the same tagsWe want to continually update/build gstreamer (1.22.0) in our Buildroot.
For this reason, we should describe the [gitlab site](https://gitlab.freedesktop.org/gstreamer/gstreamer) from which the repo should be downloaded to be built, but...We want to continually update/build gstreamer (1.22.0) in our Buildroot.
For this reason, we should describe the [gitlab site](https://gitlab.freedesktop.org/gstreamer/gstreamer) from which the repo should be downloaded to be built, but the [build script](https://github.com/buildroot/buildroot/blob/2023.05/package/gstreamer1/gstreamer1/gstreamer1.mk#L9) there is designed to build the source code from [the tar files](https://gstreamer.freedesktop.org/src/gstreamer).
* Why they are different?
* Can we use the monorepo of gstreamer to build each plugin separately?https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/630splitmuxsink / mp4mux creating invalid fMP4 files2023-10-12T16:36:11ZAaron Drewsplitmuxsink / mp4mux creating invalid fMP4 filesI've been trying to create adaptive HLS transcodes on a Jetson Nano and the HLS spec suggests fMP4 is the right container format for HEVC but it seems like 'moof' boxes aren't being output at all. I'm seeing what seems to be a corrupt 'd...I've been trying to create adaptive HLS transcodes on a Jetson Nano and the HLS spec suggests fMP4 is the right container format for HEVC but it seems like 'moof' boxes aren't being output at all. I'm seeing what seems to be a corrupt 'd ' box instead.
![Screen_Shot_2019-07-25_at_11.40.46_pm](/uploads/5069127ed03b57223903a5ee24fe0ae2/Screen_Shot_2019-07-25_at_11.40.46_pm.png)
I'm running a single decode with a set of video encodes and a copied audio track as follows:
```
/home/ubuntu/gst-1.16.0/bin/gst-launch-1.0 \
souphttpsrc is-live=true location="${URL}" ! \
tsparse set-timestamps=false ! tsdemux name=demux \
demux. ! queue2 ! mpegvideoparse ! omxmpeg2videodec ! tee name=vid \
demux. ! decodebin ! audioconvert ! avenc_ac3_fixed ! ac3parse ! tee name=audio \
splitmuxsink name=mux_1 location="${PREFIX}h265_1_%05d.mp4" max-size-time=2000000000 \
async-finalize=true muxer-factory=mp4mux muxer-properties="properties,streamable=true,fragment-duration=2000" send-keyframe-requests=true \
vid. ! nvvidconv ${RES} ! "video/x-raw(memory:NVMM), width=(int)1920, height=(int)1080" ! \
omxh265enc iframeinterval=60 control-rate=1 ! \
"video/x-h265, level=(string)high5" ! h265parse ! mux_1. \
audio. ! queue ! mux_1.audio_0
...
```
I have actually seen some valid files produced with moof boxes, but it's very rare.
Can anyone tell me if I'm doing anything wrong? Based on gstqtmux.c, I am suspecting the code is writing to a bad offset somewhere, but my container knowledge is quite limited.
![6.h265_1_00002__11_](/uploads/2f8ea070f428cda93efad2bdadd390f1/6.h265_1_00002__11_.mp4)