GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T13:31:06Zhttps://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/178vp8dec: add deadline option2021-09-24T13:31:05ZBugzilla Migration Uservp8dec: add deadline option## Submitted by Cecill Etheredge (ijsf)
**[Link to original bug (#747534)](https://bugzilla.gnome.org/show_bug.cgi?id=747534)**
## Description
Created attachment 301163
Patch that adds deadline option to gstvp8dec
This patch ...## Submitted by Cecill Etheredge (ijsf)
**[Link to original bug (#747534)](https://bugzilla.gnome.org/show_bug.cgi?id=747534)**
## Description
Created attachment 301163
Patch that adds deadline option to gstvp8dec
This patch adds support for a "deadline" option in vp8dec, similar to that in gstvp8dec.
This option is required to force the deadline to real-time (VPX_DL_REALTIME) in applications where real-time video is essential, e.g. in OpenWebRTC.
I have tested and verified that the calculated deadline is actually 0 in the case of OpenWebRTC, and should be 1. By adding this option, the deadline can be overruled from the application end.
**Patch 301163**, "Patch that adds deadline option to gstvp8dec":
[ijsf_gstvp8dec_deadline.patch](/uploads/d432b57c21bbaee3573a6da9c4dec770/ijsf_gstvp8dec_deadline.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/177qtmux/mp4mux can't change size after first buffer.2021-09-24T13:31:05ZBugzilla Migration Userqtmux/mp4mux can't change size after first buffer.## Submitted by Marcin Kolny `@loganek`
**[Link to original bug (#747184)](https://bugzilla.gnome.org/show_bug.cgi?id=747184)**
## Description
Created attachment 300752
test application
Hi,
I've udp video stream, which can ...## Submitted by Marcin Kolny `@loganek`
**[Link to original bug (#747184)](https://bugzilla.gnome.org/show_bug.cgi?id=747184)**
## Description
Created attachment 300752
test application
Hi,
I've udp video stream, which can change its resolution. I've noted, that qtmux/mp4mux fails, when video size is changed. I did simple application, which triggers this bug (see attachment).
I digged a little, and noted, that the problem is in method gst_qt_mux_video_sink_set_caps. At the beginning, function checks, whether previous caps are subset of new caps (gst_qtmux_caps_is_subset_full). It obviously isn't true, because caps have other size. I saw comment above - Does it mean, that there is no possibility to renegotiate caps in mp4mux/qtmux?
IMO it's a bug in a plugin, but have no idea how to fix it in a proper way.
**Attachment 300752**, "test application":
[muxtest.c](/uploads/1fff4d4074eb510bd28c7cb61a2868dc/muxtest.c)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/175rtpsource: Stats contain useless SR fields for receiver sources2021-09-24T13:31:05ZBugzilla Migration Userrtpsource: Stats contain useless SR fields for receiver sources## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#746743)](https://bugzilla.gnome.org/show_bug.cgi?id=746743)**
## Description
On the sender side, we currently have one rtpsource for sending, and then the N rtpsourc...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#746743)](https://bugzilla.gnome.org/show_bug.cgi?id=746743)**
## Description
On the sender side, we currently have one rtpsource for sending, and then the N rtpsources for all the receivers.
The receiver rtpsource will then get the RRs at some point, and generate stats from it, which can be retrieved with the "stats" property. However these stats contain lots of fields that are always going to be 0: sr-*, packets/octets-received/sent, etc.
The sr-* fields look like they should contain the values from the last SR that was sent, but that one comes from a different rtpsource and the receiver rtpsource never sees that.
The packets/octets-received/sent fields would only contain a value if this was a source that sends data, or receives data. So never the receiver sources on the sender side.
Is this all intended as is? Should the SR at the sender side also go to all the receiver sources so that they can know the SR that resulted in the RRs that are received?https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/174videorate: Should transform the caps in allocation2021-09-24T13:31:04ZBugzilla Migration Uservideorate: Should transform the caps in allocation## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#746657)](https://bugzilla.gnome.org/show_bug.cgi?id=746657)**
## Description
Videorate passthrough allocation query, but it does not transform the framerate in ...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#746657)](https://bugzilla.gnome.org/show_bug.cgi?id=746657)**
## Description
Videorate passthrough allocation query, but it does not transform the framerate in the allocation query caps. If downstream element prepare a pool base on the caps it got in set_format(), the caps won't match and it may fail. Videorate should probably transform the caps in the allocation query.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/172dvdemux: timecode displayed incorrectly2021-09-24T13:31:03ZBugzilla Migration Userdvdemux: timecode displayed incorrectly## Submitted by RaviKiran
**[Link to original bug (#746505)](https://bugzilla.gnome.org/show_bug.cgi?id=746505)**
## Description
gst_dvdemux_get_timecode() doesn't get the timecode correctly.
timecode information for seconds and m...## Submitted by RaviKiran
**[Link to original bug (#746505)](https://bugzilla.gnome.org/show_bug.cgi?id=746505)**
## Description
gst_dvdemux_get_timecode() doesn't get the timecode correctly.
timecode information for seconds and minutes are 0-6 bits, however
last bit is ignored.
This timecode is used for debug message only.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/171gstrtpmp4adepay cannot handle in band config2021-09-24T13:31:03ZBugzilla Migration Usergstrtpmp4adepay cannot handle in band config## Submitted by Nick Stoughton
**[Link to original bug (#746475)](https://bugzilla.gnome.org/show_bug.cgi?id=746475)**
## Description
The rtpmp4adepay module cannot handle payloads created by iOS which send the streamMuxConfig in-ba...## Submitted by Nick Stoughton
**[Link to original bug (#746475)](https://bugzilla.gnome.org/show_bug.cgi?id=746475)**
## Description
The rtpmp4adepay module cannot handle payloads created by iOS which send the streamMuxConfig in-band. The following extract is from the Apple "Bluetooth Accessory Design Guidelines for Apple Products":
> The AudioMuxElement is the same as the RTP payload in RFC 3016. It is defined in Section 1.7.3, Table
> 1.32 in ISO/IEC 13818-3:2005, subpart 1. The muxConfigPresent argument to the AudioMuxElement
> is set to 1 (in-band mode), as recommended in Section 4.1 of RFC 3016. As recommended in Section 4.3
> of RFC 3016, only one AudioMuxElement is put into each AVDTP packet
Further, Apple fail to implement RFC 3016 correct, in that they never set the Marker bit in the RTP header.
I don't have the bandwidth right now to come up with a patch, but will probably do so in the next few months unless someone else has something to offer!
Need a mechanism to say "assume every packet has the Marker set" (I might be able to do this in my source element), and to handle in-band config data.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/170souphttpsrc: Use proxy username/password from http_proxy2021-09-24T13:31:03ZBugzilla Migration Usersouphttpsrc: Use proxy username/password from http_proxy## Submitted by Rajat Verma
**[Link to original bug (#746382)](https://bugzilla.gnome.org/show_bug.cgi?id=746382)**
## Description
http_proxy variable may also contain proxy username & password in below format:
`<protocol>`://`...## Submitted by Rajat Verma
**[Link to original bug (#746382)](https://bugzilla.gnome.org/show_bug.cgi?id=746382)**
## Description
http_proxy variable may also contain proxy username & password in below format:
`<protocol>`://`<username>`:`<password>`@`<proxy ip>`:`<proxy port>`
souphttpsrc only sets proxy url (`<proxy ip>` & `<proxy port>`) is http_proxy variable is defined in environment but not proxy-id and proxy-pw.
Problem I am facing is "proxy authentication required 407" while testing MPEG-DASH, which plays a .mpd located outside my company network.
dashdemux, for fetching a segment, uses gst_element_make_from_uri(). Now I have no way to set proxy-id/proxy-pw on this particular souphttpsrc instance, due to which segment fetching fails.
If souphttpsrc may start parsing proxy-id/proxy-pw using below functions from soup library:
soup_uri_get_user()
soup_uri_get_password()
then my issue would be resolved.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/167rtpjitterbuffer: Does not handle bursts properly2021-09-24T13:31:01ZBugzilla Migration Userrtpjitterbuffer: Does not handle bursts properly## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#746035)](https://bugzilla.gnome.org/show_bug.cgi?id=746035)**
## Description
Created attachment 299099
Sample rtsp audio stream which yields duplicate timestam...## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#746035)](https://bugzilla.gnome.org/show_bug.cgi?id=746035)**
## Description
Created attachment 299099
Sample rtsp audio stream which yields duplicate timestamps with rtpjitterbuffer
When the attached gdp-payloaded file is run through rtpjitterbuffer, with mode=slave (the default), the output audio has buffers with duplicate pts, but not with mode=buffer/synced/none. Those buffers all seem to contain silence (see [bug 746032](https://bugzilla.gnome.org/show_bug.cgi?id=746032)).
Bad:
gst-launch-1.0 filesrc location=output-gdp-audio.bin ! gdpdepay ! rtpjitterbuffer ! rtpmp4adepay ! decodebin ! ...
Good:
gst-launch-1.0 filesrc location=output-gdp-audio.bin ! gdpdepay ! rtpjitterbuffer mode=buffer ! rtpmp4adepay ! decodebin ! ...
gst-launch-1.0 filesrc location=output-gdp-audio.bin ! gdpdepay ! rtpjitterbuffer mode=synced ! rtpmp4adepay ! decodebin ! ...
gst-launch-1.0 filesrc location=output-gdp-audio.bin ! gdpdepay ! rtpjitterbuffer mode=none ! rtpmp4adepay ! decodebin ! ...
All the incoming packets are sequential and evenly-spaced (captured from gst-rtsp-server over a link-local network), so in theory there shouldn't be a "discontinuity" like that.
~~**Attachment 299099**~~, "Sample rtsp audio stream which yields duplicate timestamps with rtpjitterbuffer":
[output-gdp-video.bin](/uploads/11eacf4143df56e805eb5563536fb67f/output-gdp-video.bin)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/166wavparse: support for partially unpositioned channels2021-09-24T13:31:01ZBugzilla Migration Userwavparse: support for partially unpositioned channels## Submitted by Ilya Konstantinov
**[Link to original bug (#745871)](https://bugzilla.gnome.org/show_bug.cgi?id=745871)**
## Description
Here's a sample:
http://www-mmsp.ece.mcgill.ca/documents/AudioFormats/WAVE/Samples/Microso...## Submitted by Ilya Konstantinov
**[Link to original bug (#745871)](https://bugzilla.gnome.org/show_bug.cgi?id=745871)**
## Description
Here's a sample:
http://www-mmsp.ece.mcgill.ca/documents/AudioFormats/WAVE/Samples/Microsoft/8_Channel_ID.wav
This is a file with 8 channels and the following speaker locations:
FL FR FC LF BL BR - -
(Only 6 allocated, the mask is 0x3f.)
As per spec:
"Should nChannels exceed the number of bits set in dwChannelMask, then the remaining channels are not assigned to any particular speaker location. An audio device would render the remaining channel data to output ports not in use." [1]
Since GstAudioChannelPositions requires channels to be either all positioned or all unpositioned, I think we should opt to offer caps of: channels:6, channel-mask:0x3f. (The remaining 2 channels can be only thrown away.)
Current GStreamer this warning out a few times, since wavparse produces 'channels:8, channel-mask:0x3f':
** (gst-launch-1.0:14286): WARNING **: Invalid channel positions
[1] https://msdn.microsoft.com/en-us/library/windows/hardware/dn653308(v=vs.85).aspxhttps://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/162osxaudio: AudioUnitGetProperty (..., kAudioUnitProperty_Latency, ...) takes time2021-09-24T13:31:00ZBugzilla Migration Userosxaudio: AudioUnitGetProperty (..., kAudioUnitProperty_Latency, ...) takes time## Submitted by Ilya Konstantinov
Assigned to **Ilya Konstantinov**
**[Link to original bug (#745078)](https://bugzilla.gnome.org/show_bug.cgi?id=745078)**
## Description
AudioUnitGetProperty (..., kAudioUnitProperty_Latency, ...)...## Submitted by Ilya Konstantinov
Assigned to **Ilya Konstantinov**
**[Link to original bug (#745078)](https://bugzilla.gnome.org/show_bug.cgi?id=745078)**
## Description
AudioUnitGetProperty (..., kAudioUnitProperty_Latency, ...) is showing up in the profiler as a time-waster. It doesn't actually change all that often, and can be detected with a property listener.
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/161souphttpsrc error handling doesn't differentiate "password needed"2021-09-24T13:30:59ZBugzilla Migration Usersouphttpsrc error handling doesn't differentiate "password needed"## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#744996)](https://bugzilla.gnome.org/show_bug.cgi?id=744996)**
## Description
In cf31a4284bcd87f4137bdd8f2dc1cf3cedf43ccb, souphttpsrc starting sending NOT_AUTHORIZED...## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#744996)](https://bugzilla.gnome.org/show_bug.cgi?id=744996)**
## Description
In cf31a4284bcd87f4137bdd8f2dc1cf3cedf43ccb, souphttpsrc starting sending NOT_AUTHORIZED when 401, 402, 403 and 407 HTTP codes are sent back. 401 and 407 are the only ones that should trigger password prompts, but there's no way to differentiate them.
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/160Some decoders need mp4's maximum sample size2021-09-24T13:30:59ZBugzilla Migration UserSome decoders need mp4's maximum sample size## Submitted by alf..@..al.com
**[Link to original bug (#744857)](https://bugzilla.gnome.org/show_bug.cgi?id=744857)**
## Description
Created attachment 297396
Patch for qtdemux.c
HW decoders re-use input buffers and in some ...## Submitted by alf..@..al.com
**[Link to original bug (#744857)](https://bugzilla.gnome.org/show_bug.cgi?id=744857)**
## Description
Created attachment 297396
Patch for qtdemux.c
HW decoders re-use input buffers and in some cases the size they use is too small because they try to minimize the (physical)memory resources employed when decoding. Therefore, some times it is needed to give them a good estimate of the maximum sample size to avoid decoding errors that happen when the input buffer size is smaller than the size of a sample.
This patch reads that information for iso mp4 containers, and complements the patch in [bug 737599](https://bugzilla.gnome.org/show_bug.cgi?id=737599) (https://bugzilla.gnome.org/show_bug.cgi?id=737599), which did the same for avi files.
The size is determined using the sample size field in stsz atom if set or searching the maximum sample size in the sample size table field (stsz too) otherwise. This is similar to what is done in the AOSP project:
http://androidxref.com/4.4.2_r1/xref/frameworks/av/media/libstagefright/MPEG4Extractor.cpp#1353
(See http://goo.gl/sp3S8V for information on the mp4 stsz atom.)
We are using "max-input-size" cap in out androidmedia/hybris decoder
http://goo.gl/qoYLkm ,
as we found some videos produce artefacts for some HW decoders in mobile SoCs.
**Patch 297396**, "Patch for qtdemux.c":
[0001-qtdemux-Set-maximum-sample-input-size-in-caps.patch](/uploads/9e9dcaf058779401433fcfdeab183d38/0001-qtdemux-Set-maximum-sample-input-size-in-caps.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/159rtspsrc: May stop sending keep alive due to buggy timeout in rtspconnection2021-09-24T13:30:59ZBugzilla Migration Userrtspsrc: May stop sending keep alive due to buggy timeout in rtspconnection## Submitted by loc..@..il.com
**[Link to original bug (#744209)](https://bugzilla.gnome.org/show_bug.cgi?id=744209)**
## Description
In 1.2.x, rtspsrc is sending out GET_PARAMETER every 75seconds, however , in 1.4.5/1.4.4, after th...## Submitted by loc..@..il.com
**[Link to original bug (#744209)](https://bugzilla.gnome.org/show_bug.cgi?id=744209)**
## Description
In 1.2.x, rtspsrc is sending out GET_PARAMETER every 75seconds, however , in 1.4.5/1.4.4, after the first GET_PARAMETER is sent out, there is no the second one.
Tested on win7 and mac os x
related post: http://gstreamer-devel.966125.n4.nabble.com/GStreamer-neither-keep-rtsp-alive-nor-re-connect-to-ip-camera-td4670632.html
Version: 1.4.5https://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-solutions