GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2018-11-05T10:40:16Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/81Bug in GStreamer, mark MessageRef::get_src() unsafe?2018-11-05T10:40:16ZSebastian DrögeBug in GStreamer, mark MessageRef::get_src() unsafe?*Created by: rikte88*
When running a playbin, It turns out that messages exist on the bus where the message src pointer is invalid. (already freed or something)
Checking if msg.get_src() == pipeline sometimes causes memory corruption...*Created by: rikte88*
When running a playbin, It turns out that messages exist on the bus where the message src pointer is invalid. (already freed or something)
Checking if msg.get_src() == pipeline sometimes causes memory corruption that will crash the program at a later time.
This is of course not a problem with this excellent library, but possibly MessageRef::get_src() should be unsafe with a warning until this gets fixed in GStreamer?
This is the reason for the bug that i filed earlier:
https://github.com/sdroege/gstreamer-rs/issues/70
I managed to work around this limitation in the following way:
```
// let msg_from_pipeline = msg.get_src().unwrap() == pipeline; // DON'T DO THIS
let msg_from_pipeline = unsafe { // WORKAROUND
use glib::translate::ToGlibPtr;
use gstreamer_sys::{GstElement, GstPipeline};
let pipeline_ptr: *const GstPipeline = pipeline.to_glib_none().0;
let msg_src_ptr = (*msg.as_ptr()).src as *const GstElement;
pipeline_ptr as *const GstElement == msg_src_ptr
};
```
With the workaround, all problems go away and it works flawlessly.
Tested on Fedora 27 with:
[karlri@localhost ~]$ gst-launch-1.0 --version
gst-launch-1.0 version 1.12.4
GStreamer 1.12.4
http://download.fedoraproject.org
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/438rtph264depay broken in some cases when stream-format=avc2023-07-06T10:22:50ZBugzilla Migration Userrtph264depay broken in some cases when stream-format=avc## Submitted by Sean-Der
**[Link to original bug (#793374)](https://bugzilla.gnome.org/show_bug.cgi?id=793374)**
## Description
Created attachment 368244
FLV with 1 H264 track showing error
The following H264 is corrupted aft...## Submitted by Sean-Der
**[Link to original bug (#793374)](https://bugzilla.gnome.org/show_bug.cgi?id=793374)**
## Description
Created attachment 368244
FLV with 1 H264 track showing error
The following H264 is corrupted after depayloading, it only seems to happen when AVC is requested. The following pipeline demonstrates, you will get errors from libav and visible corruption.
```
gst-launch-1.0 filesrc location=bad.flv ! flvdemux ! h264parse ! video/x-h264, stream-format=avc ! rtph264pay
! rtph264depay ! video/x-h264, stream-format=avc ! decodebin ! autovideosink
```
I am still investigating, this is from a git build (~12 hrs old). Would love to fix this myself, but if anyone has quick fixes/ideas would love to know.
thanks!
**Attachment 368244**, "FLV with 1 H264 track showing error":
[bad-mini.flv](/uploads/bff1e390f488552856bfde3a5028fb38/bad-mini.flv)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/655Crashing on iOS: [ALAssetRepresentation release]: message sent to deallocated...2021-09-24T14:36:05ZBugzilla Migration UserCrashing on iOS: [ALAssetRepresentation release]: message sent to deallocated instance, [GstAssetsLibrary .cxx_destruct] XCode 9.2, iOS 11.2 (15C107)## Submitted by Louis Le
**[Link to original bug (#793383)](https://bugzilla.gnome.org/show_bug.cgi?id=793383)**
## Description
I'm stuck on crashing issue: message sent to deallocated instance zombie object with GStreamer tutorial ...## Submitted by Louis Le
**[Link to original bug (#793383)](https://bugzilla.gnome.org/show_bug.cgi?id=793383)**
## Description
I'm stuck on crashing issue: message sent to deallocated instance zombie object with GStreamer tutorial project for iOS with this version of XCode, the app crashes when trying to unref the player or pipeline after playing a AVI file saved in Camera Roll using ALAsset with prefix:
assets-library://asset/asset.AVI?id=ID_OF_AVI_FILE&ext=AVI.
Crash point: typefind:sink -> [GstAssetsLibrary .cxx_destruct]
Crash callStackSymbols
`<_NSCallStackArray 0x604000452180>`(
```
0 ??? 0x00000001226dbf1c 0x0 + 4872584988,
1 Tutorial 5 0x0000000103211300 main + 0,
2 libobjc.A.dylib 0x000000010bbb6912 _ZL27object_cxxDestructFromClassP11objc_objectP10objc_class + 127,
3 libobjc.A.dylib 0x000000010bbc21a4 objc_destructInstance + 124,
4 libobjc.A.dylib 0x000000010bbc21db object_dispose + 22,
5 AssetsLibrary 0x00000001088a6acd -[ALAssetsLibrary dealloc] + 98,
6 libobjc.A.dylib 0x000000010bbcca2e _ZN11objc_object17sidetable_releaseEb + 202,
7 libobjc.A.dylib 0x000000010bbcd178 _ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv + 860,
8 libobjc.A.dylib 0x000000010bbce31b _ZN12_GLOBAL__N_119AutoreleasePoolPage11tls_deallocEPv + 127,
9 libsystem_pthread.dylib 0x000000010ca0f27e _pthread_tsd_cleanup + 534,
10 libsystem_pthread.dylib 0x000000010ca0efbd _pthread_exit + 79,
11 libsystem_pthread.dylib 0x000000010ca0d6cc pthread_sigmask + 0,
12 libsystem_pthread.dylib 0x000000010ca0d56d _pthread_body + 0,
13 libsystem_pthread.dylib 0x000000010ca0cc5d thread_start + 13
)
```
>https://github.com/sdroege/gst-player
>https://github.com/GStreamer/gst-docs/tree/master/examples/tutorials/xcode%20iOS
Version: 1.12.3https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/656lv2: Parameter metadata is not supported2021-09-24T14:36:06ZBugzilla Migration Userlv2: Parameter metadata is not supported## Submitted by Wellington Wallace
**[Link to original bug (#793384)](https://bugzilla.gnome.org/show_bug.cgi?id=793384)**
## Description
Hi GStreamer developers! I would like to use the convolver from Linux Studio Plugins http://ls...## Submitted by Wellington Wallace
**[Link to original bug (#793384)](https://bugzilla.gnome.org/show_bug.cgi?id=793384)**
## Description
Hi GStreamer developers! I would like to use the convolver from Linux Studio Plugins http://lsp-plug.in/?page=manuals§ion=impulse_responses_stereo in my application https://github.com/wwmm/pulseeffects. But although the plugin is successfully loaded by GStreamer there are two parameters that are not show in the output of gst-inspect-1.0. The ones used to load the impulse response file for each channel. In the plugin ttl file they are defined as:
lsp_p:ifn0
a lv2:Parameter ;
rdfs:label "Impulse file 1" ;
rdfs:range atom:Path
.
lsp_p:ifn1
a lv2:Parameter ;
rdfs:label "Impulse file 2" ;
rdfs:range atom:Path
I took a look at the lv2 plugin sources and it seems that there is no support for lv2:Parameter. So this may be the reason why they are not shown in the output of gst-inspect-1.0.
Although I would like to help I just don't have the knowledge to do that yet. I have never worked at GStreamer lower levels and I know nothing about the LV2 api.
I am open to alternative solutions in case this is a feature we can't have any time soon.
Best regards,
Wellington
Version: 1.12.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/439autosrc: Port to GstDeviceMonitor2021-09-24T13:32:52ZBugzilla Migration Userautosrc: Port to GstDeviceMonitor## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#793405)](https://bugzilla.gnome.org/show_bug.cgi?id=793405)**
## Description
The autoaudiosrc and audiovideosrc works a bit by chance as they assume no setup is...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#793405)](https://bugzilla.gnome.org/show_bug.cgi?id=793405)**
## Description
The autoaudiosrc and audiovideosrc works a bit by chance as they assume no setup is requirement on the elements. As an example, if you have pipewire installed and activate the deamon, autovideosrc no longer works because then it picks pipewiresrc but with the default path, which is invalid.
https://github.com/PipeWire/pipewire/issues/55
Why I'm proposing to use GstDeviceMonitor internally is because that API provide a "configured" element to use, which would solve this kind of issue.. With that in place we'll be able to do fency fallback when a camera is unplugged. We could also expose the monitor, letting the application select a camera, handling the dynamic switch within the element itself.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/657msdk: avoid explicit sync2021-09-24T14:36:06ZBugzilla Migration Usermsdk: avoid explicit sync## Submitted by Hyunjun Ko `@zzoon`
**[Link to original bug (#793411)](https://bugzilla.gnome.org/show_bug.cgi?id=793411)**
## Description
Avoiding Explicit Sync if there are back to back msdk plugins in a pipeline might improve per...## Submitted by Hyunjun Ko `@zzoon`
**[Link to original bug (#793411)](https://bugzilla.gnome.org/show_bug.cgi?id=793411)**
## Description
Avoiding Explicit Sync if there are back to back msdk plugins in a pipeline might improve performonce of the pipeline.
We can think about this way and do benchmarking at least.
### Blocking
* [Bug 789886](https://bugzilla.gnome.org/show_bug.cgi?id=789886)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/658msdk: refactor removing duplicated code in encoder and decoder.2021-09-24T14:36:07ZBugzilla Migration Usermsdk: refactor removing duplicated code in encoder and decoder.## Submitted by Hyunjun Ko `@zzoon`
**[Link to original bug (#793414)](https://bugzilla.gnome.org/show_bug.cgi?id=793414)**
## Description
There are some duplicate code and can be placed in one place, so called, gstmsdkutil.c.
...## Submitted by Hyunjun Ko `@zzoon`
**[Link to original bug (#793414)](https://bugzilla.gnome.org/show_bug.cgi?id=793414)**
## Description
There are some duplicate code and can be placed in one place, so called, gstmsdkutil.c.
Let's refactor and clean it up.
### Blocking
* [Bug 789886](https://bugzilla.gnome.org/show_bug.cgi?id=789886)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/659msdk (vaapi/x264/etc): encode: renaming the target-usage to speed-preset2021-09-24T14:36:07ZBugzilla Migration Usermsdk (vaapi/x264/etc): encode: renaming the target-usage to speed-preset## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#793495)](https://bugzilla.gnome.org/show_bug.cgi?id=793495)**
## Description
This is for discussing the unification of speed-quality-tradeoff property in differ...## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#793495)](https://bugzilla.gnome.org/show_bug.cgi?id=793495)**
## Description
This is for discussing the unification of speed-quality-tradeoff property in different encoders which could be most commonly used tuning option for general users.
The current msdk encoders have a property "target-usage":
target-usage : 1: Best quality, 4: Balanced, 7: Best speed
flags: readable, writable
Unsigned Integer. Range: 1 - 7 Default: 4
The same thing in gstreamer-vaapi is:
quality-level : Encoding Quality Level (lower value means higher-quality/slow-encode, higher value means lower-quality/fast-encode)
flags: readable, writable
Unsigned Integer. Range: 1 - 7 Default: 4
x264enc has this:
speed-preset : Preset name for speed/quality tradeoff options (can affect decode compatibility - impose restrictions separately for your target decoder)
flags: readable, writable
Enum "GstX264EncPreset" Default: 6, "medium"
(0): None - No preset
(1): ultrafast - ultrafast
(2): superfast - superfast
(3): veryfast - veryfast
(4): faster - faster
(5): fast - fast
(6): medium - medium
(7): slow - slow
(8): slower - slower
(9): veryslow - veryslow
(10): placebo - placebo
Does it make sense to use the same property for all?
It could break the backward compatibility for gstreamr-vaapi and x264.
But for msdk, this seems to be the right time for a change like this.
I would like to get some general opinion on this.
Version: 1.13.1
### Blocking
* [Bug 789886](https://bugzilla.gnome.org/show_bug.cgi?id=789886)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/419theora_parse_chain segfaults on zero length buffer (gsttheoraparse.c)2021-09-24T13:23:34ZBugzilla Migration Usertheora_parse_chain segfaults on zero length buffer (gsttheoraparse.c)## Submitted by Cy
**[Link to original bug (#793500)](https://bugzilla.gnome.org/show_bug.cgi?id=793500)**
## Description
I'm not sure why gst_pad_push_data is pushing an empty 0-length buffer to theora_parse_chain, but the latter f...## Submitted by Cy
**[Link to original bug (#793500)](https://bugzilla.gnome.org/show_bug.cgi?id=793500)**
## Description
I'm not sure why gst_pad_push_data is pushing an empty 0-length buffer to theora_parse_chain, but the latter fails to deal with it properly, segfaulting instead of ignoring it, or erroring out. theora_parse_chain calls gst_buffer_map without checking the return value, then tries to access map.data[0] without checking whether map.data is NULL.
gst_buffer_map itself returns FALSE when the buffer's length is zero (in g_return_val_if_fail) and then checks again for some reason, zeroing out the GstMapInfo structure if the buffer's length is zero, then returning TRUE. I'm not sure if the second code branch is ever reached under any circumstances, but it'd probably be good to check if mem.data is NULL, even if gst_buffer_map returns TRUE.
Version: 1.12.4https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2773rtspsrc: protocols=http doesn't work with gst-rtsp-server examples2023-07-06T10:18:15ZBugzilla Migration Userrtspsrc: protocols=http doesn't work with gst-rtsp-server examples## Submitted by Göran Jönsson
**[Link to original bug (#793502)](https://bugzilla.gnome.org/show_bug.cgi?id=793502)**
## Description
Created attachment 368399
logs from server
If running
gst-launch-1.0 -e rtspsrc protocols...## Submitted by Göran Jönsson
**[Link to original bug (#793502)](https://bugzilla.gnome.org/show_bug.cgi?id=793502)**
## Description
Created attachment 368399
logs from server
If running
gst-launch-1.0 -e rtspsrc protocols=http location="rtsp://127.0.0.1:8554/test" ! fakesink
against an (gst-rtsp-server/examples) example (test-video) server does not work.
If using protocols tcp or default it works.
Attach logs from server(test-video) and client(rtspsrc protocols=http)
**Attachment 368399**, "logs from server":
[test-video_log.txt](/uploads/179cedbabfb20303dcbb8c8bb4809d7e/test-video_log.txt)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/440rtspsrc: protocols=http doesn't work with gst-rtsp-server examples2023-07-06T10:18:16ZBugzilla Migration Userrtspsrc: protocols=http doesn't work with gst-rtsp-server examples## Submitted by Göran Jönsson
**[Link to original bug (#793502)](https://bugzilla.gnome.org/show_bug.cgi?id=793502)**
## Description
Created attachment 368399
logs from server
If running
gst-launch-1.0 -e rtspsrc protocols...## Submitted by Göran Jönsson
**[Link to original bug (#793502)](https://bugzilla.gnome.org/show_bug.cgi?id=793502)**
## Description
Created attachment 368399
logs from server
If running
gst-launch-1.0 -e rtspsrc protocols=http location="rtsp://127.0.0.1:8554/test" ! fakesink
against an (gst-rtsp-server/examples) example (test-video) server does not work.
If using protocols tcp or default it works.
Attach logs from server(test-video) and client(rtspsrc protocols=http)
**Attachment 368399**, "logs from server":
[test-video_log.txt](/uploads/88852235b98588373694eaf9662654ec/test-video_log.txt)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/441rtpbin, jitterbuffer: ts-offset on RFC7273 synchronized streams2021-09-24T13:32:52ZBugzilla Migration Userrtpbin, jitterbuffer: ts-offset on RFC7273 synchronized streams## Submitted by Michael Tretter `@m.tretter`
**[Link to original bug (#793513)](https://bugzilla.gnome.org/show_bug.cgi?id=793513)**
## Description
The rtpbin sets the ts-offset on rtpjitterbuffer to synchronize multiple SSRC for on...## Submitted by Michael Tretter `@m.tretter`
**[Link to original bug (#793513)](https://bugzilla.gnome.org/show_bug.cgi?id=793513)**
## Description
The rtpbin sets the ts-offset on rtpjitterbuffer to synchronize multiple SSRC for one CNAME based on the timestamps in the SR. The offset is added to the buffer pts after the pts has been calculated from the rtptime.
However, I use RFC7273 to already synchronize RTP streams between multiple clients and the rtpjitterbuffers already calculate a synchronized pts. The additional offset breaks the synchronization again. Therefore, I don't want the rtpbin to add a ts-offset to the streams if the pts is already in sync.
I added a check in the rtpbin, if rfc7273-sync is set and skip the synchronization in these cases and with this change, my streams are in sync. However this is not really a fix, because the rfc7273-sync can be also set if the SDP does not announce an RFC7273 clock. In this case, the rtpbin should synchronize the streams.
If there is only one SSRC, there not an issue, because then the rtpbin does not add the offset, but I want separate streams for audio and video to avoid the additional latency for muxing and demuxing.
Maybe we can add a property to the rtpjitterbuffer if the produced pts are already synchronous to a wall clock or if the rtpbin should take care of synchronization.
Any thoughts?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/660vc1parse: parsing issues with vc1 streams encoded in non-WMV containers2019-11-11T22:19:33ZBugzilla Migration Uservc1parse: parsing issues with vc1 streams encoded in non-WMV containers## Submitted by Ishmael Visayana Sameen
**[Link to original bug (#793551)](https://bugzilla.gnome.org/show_bug.cgi?id=793551)**
## Description
Currently, msdk / mfx VC1 decoder plugins require vc1parse to work properly with VC1 stre...## Submitted by Ishmael Visayana Sameen
**[Link to original bug (#793551)](https://bugzilla.gnome.org/show_bug.cgi?id=793551)**
## Description
Currently, msdk / mfx VC1 decoder plugins require vc1parse to work properly with VC1 streams. There are issues however when dealing with VC1 streams encoded in non-WMV containers such as Matroska (.mkv) or MP4, for e.g., executing the simple pipeline using a sample clip (https://www.techpowerup.com/download/hd-dvd-demo-1080p-vc-1-ddplus-5-1/):
gst-launch-1.0 filesrc location=/path/to/hddvd_demo_1080p.mkv ! matroskademux ! vc1parse ! fakesink
This bug was previously reported in https://github.com/intel/gstreamer-media-SDK/issues/65 but the solution employed is hack-ish.
Version: 1.13.xhttps://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/38rtsp-session:Remove the adding of five seconds to timeout value2023-10-17T16:53:44ZBugzilla Migration Userrtsp-session:Remove the adding of five seconds to timeout value## Submitted by Joakim Johansson
**[Link to original bug (#793590)](https://bugzilla.gnome.org/show_bug.cgi?id=793590)**
## Description
Created attachment 368550
Patch with a FIXME for 2.0
There are applications / features th...## Submitted by Joakim Johansson
**[Link to original bug (#793590)](https://bugzilla.gnome.org/show_bug.cgi?id=793590)**
## Description
Created attachment 368550
Patch with a FIXME for 2.0
There are applications / features that are dependent on that the timeout
is received when it is supposed to occur and not 5s later.
For example failover recording which will record the latest 60s (if timeout
value is set to 60s), then will there be a gap of 5s if rtsp-session adds
5s to the timeout.
Suggest to remove the extra add in RTSP 2.0.
**Patch 368550**, "Patch with a FIXME for 2.0":
[0001-rtsp-session-Add-a-FIXME-for-the-timeout-value.patch](/uploads/7ce80b7060753ebc9a39a17ab0aa9041/0001-rtsp-session-Add-a-FIXME-for-the-timeout-value.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/276aggregator: flushing state never resets with a tee2019-07-19T18:22:00ZBugzilla Migration Useraggregator: flushing state never resets with a tee## Submitted by Florian Zwoch `@fzwoch`
**[Link to original bug (#793607)](https://bugzilla.gnome.org/show_bug.cgi?id=793607)**
## Description
Actually I noticed with 1.12.4 - But looking at the code makes me belief this affects 1.1...## Submitted by Florian Zwoch `@fzwoch`
**[Link to original bug (#793607)](https://bugzilla.gnome.org/show_bug.cgi?id=793607)**
## Description
Actually I noticed with 1.12.4 - But looking at the code makes me belief this affects 1.13.x as well.
I'm not 100% sure how flushing works in detail, so maybe help me out here. But I made an element based on GstAggregator and it works just fine so far. I noticed that seeking is broken when I attach a tee element downstream to the aggregator.
The basic use case is to listen on the bus for an EOS, and then seeking back to the start (with flushing). But I think it also happened when I tried a regular seek while in PAUSED.
The result is that the aggregator is processing data just fine but does not output any more data after the first seek.
A little bit of tracing lead me to this code:
(gstaggregator.c:1985)
if (flush) {
priv->pending_flush_start = TRUE;
priv->flush_seeking = TRUE;
}
[..]
(gstaggregator.c:2004)
if (!evdata.result || !evdata.one_actually_seeked) {
GST_OBJECT_LOCK (self);
priv->flush_seeking = FALSE;
priv->pending_flush_start = FALSE;
GST_OBJECT_UNLOCK (self);
}
So when I have a tee downstream I do get two seek events (correct?). The first one seems to work just fine - the second one however has much less debug log (not doing any flushing?).
Basically the second seek was a success (evdata.result == 1) but I think evdata.one_actually_seeked was also 1 because after that point I kept hitting this:
(gstaggregator.c:555)
GST_INFO_OBJECT (self, "Not pushing (active: %i, flushing: %i)",
self->priv->flush_seeking, gst_pad_is_active (self->srcpad));
with "active: 1, flushing: 1". Which indicates that "priv->flush_seeking = FALSE;" was not hit again, leaving its state in flush_seeking.
To verify I boldly moved the "priv->flush_seeking = FALSE;" line out of the brackets so it gets set regardless of the results and it did "fix" my original problem.
Surely this is not the correct fix, but maybe your understanding is much better and you already have an idea what may cause this behavior in case a tee is present downstream?
I can attach some traces for this particular case - just lacking access to the right machine.
Version: 1.13.1https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/83vaapipostproc: if dmabuf then disable deinterlace2019-01-14T09:13:08ZBugzilla Migration Uservaapipostproc: if dmabuf then disable deinterlace## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#793678)](https://bugzilla.gnome.org/show_bug.cgi?id=793678)**
## Description
dmabuf can contain interlaced content, but, as far as I understand, the sink...## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#793678)](https://bugzilla.gnome.org/show_bug.cgi?id=793678)**
## Description
dmabuf can contain interlaced content, but, as far as I understand, the sink
should have the mechanism to deinterlace dmabuf-based buffers. For example,
when using EGL_EXT_image_dma_buf_import[1], two EGLImages should be generated
from one dmabuf-based buffer.
1. https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txthttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/442splitmuxsink: add a property "location-format-type" to allow filenames with v...2023-07-02T16:37:01ZBugzilla Migration Usersplitmuxsink: add a property "location-format-type" to allow filenames with values other than fragment index## Submitted by Abhinav
**[Link to original bug (#793681)](https://bugzilla.gnome.org/show_bug.cgi?id=793681)**
## Description
At present, location property only accepts "%d" format specifier which represents fragment-index. In many...## Submitted by Abhinav
**[Link to original bug (#793681)](https://bugzilla.gnome.org/show_bug.cgi?id=793681)**
## Description
At present, location property only accepts "%d" format specifier which represents fragment-index. In many cases, it would be helpful to allow specifying other values such as first buffer PTS in filenames.
An additional property for splitmuxsink, called "location-format-type" can be added to specify value type represented by format specifier in location string pattern. For e.g. if user wants to have first buffer's time in filenames, he should be able to specify the same by following property values :
e.g.
max-size-time=120000000000
location=video_%Y-%m-%d_%H:%M:%S
location-format-type=2
Where, location-format-type can specify different format types such as
(1): fragment-index - Fragment Index(Default)
(2): first-buffer-pts - First Buffer PTS
.. and so on
Note:
In plugin version 1.12, a new signal location-format-full was added, which is flexible to support above mentioned requirement, but it requires users to do signal handling stuff. While "first buffer's time" as part of filenames, is a very common requirement, it should be possible to specify by simple configuration, than complex signal handling stuff. This should justify above enhancement proposal.
Version: 1.10.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/420gstclockoverlay: Add ability to specify which time to be displayed by GstCloc...2021-09-24T13:23:35ZBugzilla Migration Usergstclockoverlay: Add ability to specify which time to be displayed by GstClockOverlay## Submitted by Abhinav
**[Link to original bug (#793683)](https://bugzilla.gnome.org/show_bug.cgi?id=793683)**
## Description
Created attachment 368688
Patch for adding ability to specify time to be displayed by GstClockOverlay ...## Submitted by Abhinav
**[Link to original bug (#793683)](https://bugzilla.gnome.org/show_bug.cgi?id=793683)**
## Description
Created attachment 368688
Patch for adding ability to specify time to be displayed by GstClockOverlay
GstClockOverlay presently displays buffer arrival time as default. In certain scenarios, users would like to display buffer's timestamp, rather than buffer arrival time - to avoid any gaps caused by latency between frame source and clockoverlay element in pipeline.
I propose to add property called "time-mode", where users should be able to specify what time to show. So other than current default, there can be another option for time-mode say "buffer-time", to indicate that clockoverlay will be using buffer's time for display.
Example element configuration can look like following :
clockoverlay halignment=right valignment=bottom time-format="%Y-%m-%d %H:%M:%S" time-mode=1
Where time-mode=1 represents "buffer-time".
Attached is the implementation for the same.
Note: GstTimeOverlay uses buffer time, but that doesn't have capability to display in clock format. Since clockoverlay is used to display text in clock format, it was found more suitable for said requirement.
**Patch 368688**, "Patch for adding ability to specify time to be displayed by GstClockOverlay":
[0001-gstclockoverlay-add-time-mode-property-to-specify-wh.patch](/uploads/df1e6b1c23d46b7b913d6173e0e8a506/0001-gstclockoverlay-add-time-mode-property-to-specify-wh.patch)
Version: 1.10.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/84Unneeded BLIT operation when target is encoder (ex: vaapih264enc)2023-06-06T10:46:13ZBugzilla Migration UserUnneeded BLIT operation when target is encoder (ex: vaapih264enc)## Submitted by phi..@..el.com
**[Link to original bug (#793686)](https://bugzilla.gnome.org/show_bug.cgi?id=793686)**
## Description
This operation
12.4/gstreamer-vaapi-1.12.4/gst-libs/gst/vaapi/gstvaapifilter.c: pipeline_param...## Submitted by phi..@..el.com
**[Link to original bug (#793686)](https://bugzilla.gnome.org/show_bug.cgi?id=793686)**
## Description
This operation
12.4/gstreamer-vaapi-1.12.4/gst-libs/gst/vaapi/gstvaapifilter.c: pipeline_param->output_background_color = 0xff000000;
force BLIT usage (visible with Vtune or intel_gpu_top) - or this is only needed when target is Display... useless when target is encoder (where Alpha is ignored)
This cause extra HW resource usage that can be prevented as this operation is not needed in encoder cases
Can we make this output_background_color configurable (or skip this operation in encode pipeline) ?
Version: 1.12.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/661srtpenc/srtpdec force application/x-srtp even when encryption disabled2021-09-24T14:36:07ZBugzilla Migration Usersrtpenc/srtpdec force application/x-srtp even when encryption disabled## Submitted by David Woodhouse
**[Link to original bug (#793704)](https://bugzilla.gnome.org/show_bug.cgi?id=793704)**
## Description
Created attachment 368731
Use application/x-rtp caps when decryption is disabled
See https...## Submitted by David Woodhouse
**[Link to original bug (#793704)](https://bugzilla.gnome.org/show_bug.cgi?id=793704)**
## Description
Created attachment 368731
Use application/x-rtp caps when decryption is disabled
See https://bugs.freedesktop.org/show_bug.cgi?id=105193
The FarStream fsrtpconference creates srtpenc/srtpdec elements unconditionally. If no encryption is negotiated, they pass RTP packets through with no effect. But the negotiated caps are still application/x-srtp, not application/x-rtp which is what's actually being sent.
This works OK when the transmitter is some UDP network thing which accepts anything and doesn't care.
However, in my case I do care, because I'm connecting fsrtpconference up to my own RTP depayload which really does need it to be correctly labelled as application/x-rtp.
Here's a half-baked attempt at making it work, which might work for srtpenc but has certainly broken srtpdec.
**Patch 368731**, "Use application/x-rtp caps when decryption is disabled":
[srtp-allow-rtp.patch](/uploads/3f0d7f96cc776fac0ed47fcc3791469e/srtp-allow-rtp.patch)
Version: 1.x