gst-plugins-good issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues2021-09-24T13:31:09Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/191New element to clip streams in order to void initial gaps2021-09-24T13:31:09ZBugzilla Migration UserNew element to clip streams in order to void initial gaps## Submitted by Frédéric Sureau (sfred)
**[Link to original bug (#750794)](https://bugzilla.gnome.org/show_bug.cgi?id=750794)**
## Description
From: http://lists.freedesktop.org/archives/gstreamer-devel/2015-June/053159.html
I ...## Submitted by Frédéric Sureau (sfred)
**[Link to original bug (#750794)](https://bugzilla.gnome.org/show_bug.cgi?id=750794)**
## Description
From: http://lists.freedesktop.org/archives/gstreamer-devel/2015-June/053159.html
I am facing lipsync problems while muxing live sources into an mp4 file.
Here is the pipeline:
gst-launch-1.0 -ev mp4mux name=mux ! filesink location=test.mp4
v4l2src device=/dev/v4l/by-path/ipu1-capture io-mode=dmabuf !
"video/x-raw,format=NV12,width=1280,height=720,framerate=50/1" !
v4l2h264enc device=/dev/v4l/by-path/vpu-encoder
output-io-mode=dmabuf-import !
h264parse ! queue ! mux.
alsasrc device=hw:sndcard0,0 ! "audio/x-raw, rate=48000" ! faac !
aacparse ! queue ! mux.
The v4l2src element takes some time to initialize, so the first buffer
arrives after 300ms or 400ms.
Timestamps start accordingly around 0:00:00.300
Timestamps are conserved after the encoder element (checked using identity)
Sound start immediately at 0
Audio/video sync is OK when using matroskamux, flvmux or tsmux but
desynchronized when using mp4mux. This is weird because *video* is late,
as if the real lateness was compensated 2 times.
I fixed the problem by removing calls to update_edit_list function
in the qtmux element:
https://gitlab.com/veo-labs/gst-plugins-good/commit/1febe4fc6fe2fe1322d5ae5c062da2903990680ahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/190firfilter shall support individual filters per channel2021-09-24T13:31:09ZBugzilla Migration Userfirfilter shall support individual filters per channel## Submitted by tob..@..oo.com
**[Link to original bug (#750518)](https://bugzilla.gnome.org/show_bug.cgi?id=750518)**
## Description
Created attachment 304726
git patch
The audiofirfilter supports so far only applying one fi...## Submitted by tob..@..oo.com
**[Link to original bug (#750518)](https://bugzilla.gnome.org/show_bug.cgi?id=750518)**
## Description
Created attachment 304726
git patch
The audiofirfilter supports so far only applying one filter for all audio channels. For several applications as e.g. digital room correction (DRC) it makes sense to support one filter kernel per channel to allow for channel specific correction due to e.g. unsymmetrical speaker placement.
The attached patches implement the multichannel feature to the FIR filter in a way of a new interface which is fully backward compatible and works even simultaneously with the original interface (one code path for both). This was done for time domain filtering as well as frequency domain.
The unit test got updated to test all interfaces and their interaction too as well as the time and frequency domain application.
I attached the patches and stored everything in my fork on github:
https://github.com/TheBigW/gst-plugins-good.git
in the multi_channel_fir branch
The DRC plugin project for rhythmbox already uses this feature (successful :) ) and depends on it : https://github.com/TheBigW/DRC.git.
~~**Attachment 304726**~~, "git patch":
[firfilter-multichannel.zip](/uploads/29afa2ce9bc6d968aa86227d6bf59a9f/firfilter-multichannel.zip)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/187videocrop: Make videocrop controllable2021-03-13T12:57:20ZBugzilla Migration Uservideocrop: Make videocrop controllable## Submitted by Lazar Claudiu
**[Link to original bug (#749916)](https://bugzilla.gnome.org/show_bug.cgi?id=749916)**
## Description
Useful for video effect
### Depends on
* [Bug 740502](https://bugzilla.gnome.org/show_bug.cgi?id...## Submitted by Lazar Claudiu
**[Link to original bug (#749916)](https://bugzilla.gnome.org/show_bug.cgi?id=749916)**
## Description
Useful for video effect
### Depends on
* [Bug 740502](https://bugzilla.gnome.org/show_bug.cgi?id=740502)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/186deinterleave: allow switching between 1 channel configs2019-01-28T23:39:22ZBugzilla Migration Userdeinterleave: allow switching between 1 channel configs## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#749434)](https://bugzilla.gnome.org/show_bug.cgi?id=749434)**
## Description
Created attachment 303424
deinterleave: allow switching between 1 channel configs...## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#749434)](https://bugzilla.gnome.org/show_bug.cgi?id=749434)**
## Description
Created attachment 303424
deinterleave: allow switching between 1 channel configs
This patch allows changing between configs that have positioning information if both are 1 channel, where positioning doesn't matter.
One could argue that upstream should not include any positioning, and this this patch should not be merged, so I'm putting it here.
**Attachment 303424**, "deinterleave: allow switching between 1 channel configs":
[0001-deinterleave-allow-switching-between-1-channel-confi.patch](/uploads/e84e21476417c1868d94fe0ceece7226/0001-deinterleave-allow-switching-between-1-channel-confi.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/182ximagesrc: add uri handler interface2021-09-24T13:31:07ZBugzilla Migration Userximagesrc: add uri handler interface## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#748042)](https://bugzilla.gnome.org/show_bug.cgi?id=748042)**
## Description
Created attachment 301819
add xwin uri handler to ximagesrc
add a uri handler
...## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#748042)](https://bugzilla.gnome.org/show_bug.cgi?id=748042)**
## Description
Created attachment 301819
add xwin uri handler to ximagesrc
add a uri handler
xwin://.....
~~**Patch 301819**~~, "add xwin uri handler to ximagesrc":
[19_Add-x-uri-handler-to-ximagesrc.patch](/uploads/42209e80898bbdb01a58ef7e2c433615/19_Add-x-uri-handler-to-ximagesrc.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/179v4l2: adding cropping and compose functionality2021-09-24T13:31:06ZBugzilla Migration Userv4l2: adding cropping and compose functionality## Submitted by Dimitrios Katsaros
**[Link to original bug (#747606)](https://bugzilla.gnome.org/show_bug.cgi?id=747606)**
## Description
This patch adds cropping and composition to the v4l2src. The reason for limiting the patch to ...## Submitted by Dimitrios Katsaros
**[Link to original bug (#747606)](https://bugzilla.gnome.org/show_bug.cgi?id=747606)**
## Description
This patch adds cropping and composition to the v4l2src. The reason for limiting the patch to the source is the lack of a v4l2 output device to test on. The device available also only supports cropping, so composition also requires additional testing
This patch has been developed with the current master branch, commit id: 8cfebfec8c6ca7a47dd064c8f5d3e587973f31a1https://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/173rtpsession: Add property to set minimum time between regular RTCP and early RTCP2021-09-24T13:31:04ZBugzilla Migration Userrtpsession: Add property to set minimum time between regular RTCP and early RTCP## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#746542)](https://bugzilla.gnome.org/show_bug.cgi?id=746542)**
## Description
Currently we allow to send an early RTCP packet immediately after the previous regular R...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#746542)](https://bugzilla.gnome.org/show_bug.cgi?id=746542)**
## Description
Currently we allow to send an early RTCP packet immediately after the previous regular RTCP packet. This will be suboptimal if we have reasons to send another early RTCP packet soon afterwards... as that one would now have to wait until the next regular RTCP packet could be sent (and the next regular RTCP packet is now also delayed in the future because of the early one we just sent).
It would be better in some situations if we set some minimum delay from the previous regular RTCP packet. That way we would allow for other feedback to be accumulated into the same early feedback RTCP packet more likely.
The delay could either be specified in milliseconds, or as a relative value relative to the regular RTCP scheduling interval we currently decided to use. Not sure which one is better.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/169qtdemux: Support for gapless playback for .m4a files2021-09-24T13:31:02ZBugzilla Migration Userqtdemux: Support for gapless playback for .m4a files## Submitted by Carlos Rafael Giani
**[Link to original bug (#746109)](https://bugzilla.gnome.org/show_bug.cgi?id=746109)**
## Description
Hello,
I am currently investigating how to enable gapless playback for .m4a files. From ...## Submitted by Carlos Rafael Giani
**[Link to original bug (#746109)](https://bugzilla.gnome.org/show_bug.cgi?id=746109)**
## Description
Hello,
I am currently investigating how to enable gapless playback for .m4a files. From what I gathered, the primary way is to read out the information from the iTunSMPB tag. If it is not present, the Nero method can be used/assumed as fallback (which is, drop the first frame, usually 1024 samples for AAC LC).
The former has been introduced by Apple for iTunes. The latter is commonly done by FAAC/FAAD and Nero AAC software.
Looking at the qtdemux code, one approach that seems promising is to modify the segment in gst_qtdemux_activate_segment() prior to sending the newsegment event. That is, the data in stream->segment would *not* be modified; instead, the segment structure would be copied, the copy modified, and passed over to gst_event_new_segment(). This way, downstream sees a segment with the base/start/stop/duration values adjusted to exclude the padding samples. (The reason why this is done in a local copy is to prevent early buffer clipping in qtdemux itself; clipping needs to be applied on the decoded samples).
I'll come up with a patch that implement it and post it here, but in the meantime, if somebody knows a good reason why it shouldn't be done like that, it would be great to hear about it.
### Depends on
* [Bug 753631](https://bugzilla.gnome.org/show_bug.cgi?id=753631)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/168v4l2: enumerate output ports and add a property to select input/output2021-09-24T13:31:02ZBugzilla Migration Userv4l2: enumerate output ports and add a property to select input/output## Submitted by Aurélien Zanelli
**[Link to original bug (#746080)](https://bugzilla.gnome.org/show_bug.cgi?id=746080)**
## Description
V4L2 device can have multiple input/output port and they expose them through ENUMINPUT/ENUMOUTPU...## Submitted by Aurélien Zanelli
**[Link to original bug (#746080)](https://bugzilla.gnome.org/show_bug.cgi?id=746080)**
## Description
V4L2 device can have multiple input/output port and they expose them through ENUMINPUT/ENUMOUTPUT ioctls. But currently we only enumerate input whatever device is a capture one or an output one. I think, we should enumerate according to the device type.
Also I think it can be useful to enable user to select which input/output they want to use. To solve this I propose to add a property to v4l2object to let user select input/output.
I found this while playing with Vivid which have multiple input/output port.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/164rtpsession: Implement RFC 27622021-09-24T13:31:00ZBugzilla Migration Userrtpsession: Implement RFC 2762## Submitted by sancane
**[Link to original bug (#745586)](https://bugzilla.gnome.org/show_bug.cgi?id=745586)**
## Description
Created attachment 298511
patch generated using git format-patch
rtpsession declares an array of m...## Submitted by sancane
**[Link to original bug (#745586)](https://bugzilla.gnome.org/show_bug.cgi?id=745586)**
## Description
Created attachment 298511
patch generated using git format-patch
rtpsession declares an array of maps to store srrcs but only the
the key 0 is being used. This patch replaces the array of maps
for just one map and remove useless parameters in rtpsession
**Patch 298511**, "patch generated using git format-patch":
[0001-rtpsession-Do-not-use-an-array-of-maps-if-they-are-n.patch](/uploads/d67acf1b4732cc695d88adcfec21430d/0001-rtpsession-Do-not-use-an-array-of-maps-if-they-are-n.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/163v4l2: expose memory:DMABuf capsfeature2021-09-24T13:31:00ZBugzilla Migration Userv4l2: expose memory:DMABuf capsfeature## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#745459)](https://bugzilla.gnome.org/show_bug.cgi?id=745459)**
## Description
This is a follow-up to [bug 743345](https://bugzilla.gnome.org/show_bug.cgi?id=743345) w...## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#745459)](https://bugzilla.gnome.org/show_bug.cgi?id=745459)**
## Description
This is a follow-up to [bug 743345](https://bugzilla.gnome.org/show_bug.cgi?id=743345) where it became apparent that some memory:dmabuf capsfeature could be useful for both negotiation purposes, but also probable optimization wins.
Though, the initial intent here is only to help negotiation of elements.
### Depends on
* [Bug 759358](https://bugzilla.gnome.org/show_bug.cgi?id=759358)
### Blocking
* [Bug 755072](https://bugzilla.gnome.org/show_bug.cgi?id=755072)
### See also
* [Bug 743345](https://bugzilla.gnome.org/show_bug.cgi?id=743345)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/158scaletempo: add mode for speech speed algorithm from libsonic2021-09-24T13:30:58ZBugzilla Migration Userscaletempo: add mode for speech speed algorithm from libsonic## Submitted by Frédéric Wang
**[Link to original bug (#744062)](https://bugzilla.gnome.org/show_bug.cgi?id=744062)**
## Description
I'm opening this bug as I plan to create a plugin for libsonic:
https://raw.githubusercontent....## Submitted by Frédéric Wang
**[Link to original bug (#744062)](https://bugzilla.gnome.org/show_bug.cgi?id=744062)**
## Description
I'm opening this bug as I plan to create a plugin for libsonic:
https://raw.githubusercontent.com/waywardgeek/sonic/master/README
For now, the closest I found is the "scaletempo" element (WSOLA/SoundTouch). Here is how Sonic's author compares his algorithm with WSOLA/SoundTouch:
https://github.com/waywardgeek/sonic/blob/master/doc/index.md#comparison-to-other-solutionshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/156rtpjitterbuffer: add "do-deadline" property2021-09-24T13:30:58ZBugzilla Migration Userrtpjitterbuffer: add "do-deadline" property## Submitted by Miguel París Díaz `@mparisdiaz`
**[Link to original bug (#743945)](https://bugzilla.gnome.org/show_bug.cgi?id=743945)**
## Description
Created attachment 296048
Patch v1
I have noticed that gstjitterbuffer add...## Submitted by Miguel París Díaz `@mparisdiaz`
**[Link to original bug (#743945)](https://bugzilla.gnome.org/show_bug.cgi?id=743945)**
## Description
Created attachment 296048
Patch v1
I have noticed that gstjitterbuffer adds an initial delay of "latency" in ms retaining the firsts packets.
This behaviour can be useful in some cases, but not in others cases where the time of the media establishment is too important.
To solve this, I have added a new property to configure the behaviour of the jitter buffer: "do-deadline".
By default it has the value of TRUE, so the element has the same behaviour that until now.
**Patch 296048**, "Patch v1":
[0001-gstrtpjitterbuffer-add-do-deadline-property.patch](/uploads/98adfb83a4986a1d1c41d56236324cde/0001-gstrtpjitterbuffer-add-do-deadline-property.patch)
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/152v4l2: support radio devices in device monitor2021-09-24T13:30:56ZBugzilla Migration Userv4l2: support radio devices in device monitor## Submitted by bud..@..il.com
**[Link to original bug (#743108)](https://bugzilla.gnome.org/show_bug.cgi?id=743108)**
## Description
I want to create a filter to monitored v4l2 radio device in my system using GstDeviceMonitor.
Wi...## Submitted by bud..@..il.com
**[Link to original bug (#743108)](https://bugzilla.gnome.org/show_bug.cgi?id=743108)**
## Description
I want to create a filter to monitored v4l2 radio device in my system using GstDeviceMonitor.
With actual API, can monitor a v4l2 device with tv tuner but do not know if it is possible to create a filter for radio tuner.
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/150isomp4: Add support for Opus2023-06-02T10:31:29ZBugzilla Migration Userisomp4: Add support for Opus## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#742643)](https://bugzilla.gnome.org/show_bug.cgi?id=742643)**
## Description
It's official now: http://www.mp4ra.org/codecs.html
https://www.opus-codec.org/docs...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#742643)](https://bugzilla.gnome.org/show_bug.cgi?id=742643)**
## Description
It's official now: http://www.mp4ra.org/codecs.html
https://www.opus-codec.org/docs/opus_in_isobmff.htmlhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/146qtmux: handle overlapping subtitle buffers properly2021-09-24T13:30:53ZBugzilla Migration Userqtmux: handle overlapping subtitle buffers properly## Submitted by Matej `@Knopp`
**[Link to original bug (#741306)](https://bugzilla.gnome.org/show_bug.cgi?id=741306)**
## Description
Overlapping subtitle buffers (buffers that start before previous buffer ends) are legal in many co...## Submitted by Matej `@Knopp`
**[Link to original bug (#741306)](https://bugzilla.gnome.org/show_bug.cgi?id=741306)**
## Description
Overlapping subtitle buffers (buffers that start before previous buffer ends) are legal in many containers (i.e. MKV), but can not be represented in MP4. Trying to remux such file currently results in invalid file, because timestamp delta between buffer end time and next buffer start time is negative
In order to handle this well, the muxer should split and combine buffers in a way so that no information is lost. I.e. Two overlapping input buffers should be muxed as three separate buffers, with second buffer combining content from both input buffers.
[=======Buffer In 1========]
[=======Buffer In 2========]
[Buffer Out 1][Buffer Out 2][Buffer Out 3]
Sample MKV file with overlapped subtitles
https://s3.amazonaws.com/MatejK/Samples/OverlappedSubtitles.mkv
Remuxed file without the patch
https://s3.amazonaws.com/MatejK/Samples/OverlappedSubtitlesWithoutPatch.mp4
Remuxed file with the patch
https://s3.amazonaws.com/MatejK/Samples/OverlappedSubtitlesWithPatch.mp4https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/143rtspsrc, rtpjitterbuffer: cpu optimization2019-05-30T15:30:04ZBugzilla Migration Userrtspsrc, rtpjitterbuffer: cpu optimization## Submitted by Nicola `@drakkan`
**[Link to original bug (#740149)](https://bugzilla.gnome.org/show_bug.cgi?id=740149)**
## Description
Created attachment 290741
basesrc: workaround to save CPU in udpsrc
This bug is to keep ...## Submitted by Nicola `@drakkan`
**[Link to original bug (#740149)](https://bugzilla.gnome.org/show_bug.cgi?id=740149)**
## Description
Created attachment 290741
basesrc: workaround to save CPU in udpsrc
This bug is to keep track of this discussion and the patch
http://gstreamer-devel.966125.n4.nabble.com/rtspsrc-cpu-optimization-td4668972.html
**Patch 290741**, "basesrc: workaround to save CPU in udpsrc":
[0001-basesrc-workaround-to-save-CPU-in-udpsrc.patch](/uploads/3cbb47d6fbc8414821ea7377900352a7/0001-basesrc-workaround-to-save-CPU-in-udpsrc.patch)
Version: 1.4.4
### Depends on
* [Bug 751636](https://bugzilla.gnome.org/show_bug.cgi?id=751636)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/141multifilesink: Add a property to disable writing streamheaders on new files2023-10-13T15:06:04ZBugzilla Migration Usermultifilesink: Add a property to disable writing streamheaders on new files## Submitted by clo..@..il.com
**[Link to original bug (#739979)](https://bugzilla.gnome.org/show_bug.cgi?id=739979)**
## Description
Currently, the multifilesink will check its GstCaps for a "streamheader" value. If this value exi...## Submitted by clo..@..il.com
**[Link to original bug (#739979)](https://bugzilla.gnome.org/show_bug.cgi?id=739979)**
## Description
Currently, the multifilesink will check its GstCaps for a "streamheader" value. If this value exists, it will then generate a header for each file.
However, there are several instances where being able to treat each file generated by the multifilesink as a continuation of the previous file.
In no particular order, and this is not an exhaustive list:
1 - splitfilesrc playback. This element treats a set of files as one large contiguous file. Unfortunately, headers mess up a variety of demuxers.
2 - moving files between file systems. For example, FAT32, common on SDCards, is limited to 4GB files. Being able to binary concatenate files together when transferred to a file system without such a limit would be very useful.
To solve this, I propose adding a "write-stream-headers" property, whose default is "true" (to preserve current behavior), but when set to "false" will not write "streamheader" information from GstCaps into the resulting files.
Version: 1.4.3https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/133souphttpsrc: add 'pause-mode' property2021-09-24T13:30:47ZBugzilla Migration Usersouphttpsrc: add 'pause-mode' property## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#738298)](https://bugzilla.gnome.org/show_bug.cgi?id=738298)**
## Description
The DLNA CVP-2 spec defines different 'pause' modes regarding the way client shou...## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#738298)](https://bugzilla.gnome.org/show_bug.cgi?id=738298)**
## Description
The DLNA CVP-2 spec defines different 'pause' modes regarding the way client should handle the HTTP connection when being paused:
- stalling pause: keep the connection open and just stop reading from it. When resuming just resume reading from the connection. This is the current behavior in souphttpsrc.
- time/range pause: close the HTTP connection when pausing. When resuming re-establish a new HTTP connection and perform a time or range seek request to the server.
In order to support this new mode, we need some API controlling the behaviour of souphttpsrc when pausing.