GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T13:31:48Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/281qtdemux/mux: Add support for the sampling field in JPEG2000 caps2021-09-24T13:31:48ZBugzilla Migration Userqtdemux/mux: Add support for the sampling field in JPEG2000 caps## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#767905)](https://bugzilla.gnome.org/show_bug.cgi?id=767905)**
## Description
This should be stored somewhere in the stream, or be restricted to be unambiguous be the...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#767905)](https://bugzilla.gnome.org/show_bug.cgi?id=767905)**
## Description
This should be stored somewhere in the stream, or be restricted to be unambiguous be the JPEG2000 MOV/MP4 spec.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/280splitmuxsink: infinite change_state loop2021-09-24T13:31:47ZBugzilla Migration Usersplitmuxsink: infinite change_state loop## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#767666)](https://bugzilla.gnome.org/show_bug.cgi?id=767666)**
## Description
I override GstElementClass::change_state() in the parent GstBin containing splitmuxs...## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#767666)](https://bugzilla.gnome.org/show_bug.cgi?id=767666)**
## Description
I override GstElementClass::change_state() in the parent GstBin containing splitmuxsink. Since 1.8.2 (was not in 1.8.1) I see that it's being called in loop with transition PAUSED to PLAYING.
Reverting a97face and f2872ee fix the problem.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/279splitmuxsink: Deadlock on serialized queries2021-09-24T13:31:47ZBugzilla Migration Usersplitmuxsink: Deadlock on serialized queries## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#767461)](https://bugzilla.gnome.org/show_bug.cgi?id=767461)**
## Description
If a serialized query arrives into the splitmuxsink on the reference pad while buffe...## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#767461)](https://bugzilla.gnome.org/show_bug.cgi?id=767461)**
## Description
If a serialized query arrives into the splitmuxsink on the reference pad while buffers are queued, it will deadlock because the source is blocked and the query will never go out.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/277jpegdec: Internal parser map/unmap the same buffer multiple time2021-09-24T13:31:46ZBugzilla Migration Userjpegdec: Internal parser map/unmap the same buffer multiple time## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#767350)](https://bugzilla.gnome.org/show_bug.cgi?id=767350)**
## Description
The parse in jpegdec rely on gst_adapter_masked_scan_uint32() to find few 2 bytes s...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#767350)](https://bugzilla.gnome.org/show_bug.cgi?id=767350)**
## Description
The parse in jpegdec rely on gst_adapter_masked_scan_uint32() to find few 2 bytes sequences in the stream. The problem is that the adapter variant of this function will, for every call, map/unmap the GstBuffer. If you combined with a non-sysmem memory (like dmabuf) this will cause a huge performance hit. With 720p@30 video, I get a full i7 core being used with (if I force parsing obviously):
v4l2src ! jpegdec ! fakesink
I didn't look how to fix it really, one could map the buffer in the adapter before using that function. This would bring the performance to what the byte_scanner version would give. Though, there is probably something even smarter we could do.
Version: 1.8.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/276qtdemux: Various SEGMENT event related fixes, including regression fixes2021-09-24T13:31:44ZBugzilla Migration Userqtdemux: Various SEGMENT event related fixes, including regression fixes## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#767071)](https://bugzilla.gnome.org/show_bug.cgi?id=767071)**
## Description
See commit messages
### See also
* [Bug 765669](https://bugzilla.gnome.org/show_bug...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#767071)](https://bugzilla.gnome.org/show_bug.cgi?id=767071)**
## Description
See commit messages
### See also
* [Bug 765669](https://bugzilla.gnome.org/show_bug.cgi?id=765669)
* [Bug 763165](https://bugzilla.gnome.org/show_bug.cgi?id=763165)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/275isomp4: Use 64bit variables for elst2021-09-24T13:31:44ZBugzilla Migration Userisomp4: Use 64bit variables for elst## Submitted by Seungha Yang
**[Link to original bug (#766760)](https://bugzilla.gnome.org/show_bug.cgi?id=766760)**
## Description
isomp4: Use 64bit variables for elst
EditListBox can support 64bit variables based on the versi...## Submitted by Seungha Yang
**[Link to original bug (#766760)](https://bugzilla.gnome.org/show_bug.cgi?id=766760)**
## Description
isomp4: Use 64bit variables for elst
EditListBox can support 64bit variables based on the version box.
More specifically, version 1 of this box uses 64bit values for
segment_duration and media_time. Otherwise, 32bit values are used.
### See also
* [Bug 766301](https://bugzilla.gnome.org/show_bug.cgi?id=766301)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/274souhttpsrc: Handle redirects to non-HTTP URLs2021-09-24T13:31:43ZBugzilla Migration Usersouhttpsrc: Handle redirects to non-HTTP URLs## Submitted by Carlos Rafael Giani
**[Link to original bug (#766555)](https://bugzilla.gnome.org/show_bug.cgi?id=766555)**
## Description
Sometimes, HTTP URLs might respond with 302/303 redirect to a non-HTTP URL. Some radio statio...## Submitted by Carlos Rafael Giani
**[Link to original bug (#766555)](https://bugzilla.gnome.org/show_bug.cgi?id=766555)**
## Description
Sometimes, HTTP URLs might respond with 302/303 redirect to a non-HTTP URL. Some radio stations do this to redirect to mms:// URLs for example. In such cases, souphttpsrc does not redirect properly. Add code to post a redirect message in case of non-HTTP URLs.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/273rtpmp4adepay: Should reject caps without codec configuration2021-09-24T13:31:43ZBugzilla Migration Userrtpmp4adepay: Should reject caps without codec configuration## Submitted by Peter Maersk-Moller
**[Link to original bug (#766267)](https://bugzilla.gnome.org/show_bug.cgi?id=766267)**
## Description
Trying to RTP stream AAC audio fails. The modules aacparse, avdec_aac or decodebin all fails ...## Submitted by Peter Maersk-Moller
**[Link to original bug (#766267)](https://bugzilla.gnome.org/show_bug.cgi?id=766267)**
## Description
Trying to RTP stream AAC audio fails. The modules aacparse, avdec_aac or decodebin all fails to output packets. Probable cause is something with rtpmp4apay/rtpmp4adepay.
Scripts documenting the problem:
Sender (one of the following):
$ AUDIO='audio/x-raw,rate=48000,channels=2'
$ gst-launch-1.0 -v audiotestsrc is-live=1 ! $AUDIO ! faac ! queue ! rtpmp4apay ! udpsink host=127.0.0.1 port=14002
$ gst-launch-1.0 -v audiotestsrc is-live=1 ! $AUDIO ! avenc_aac ! queue ! rtpmp4apay ! udpsink host=127.0.0.1 port=14002
$ gst-launch-1.0 -v audiotestsrc is-live=1 ! $AUDIO ! avenc_aac compliance=-2 ! queue ! rtpmp4apay ! udpsink host=127.0.0.1 port=14002
Receiver:
$ gst-launch-1.0 -v udpsrc port=14002 caps="application/x-rtp,media=audio,payload=96,clock-rate=48000,encoding-name=MP4A-LATM" do-timestamp=1 ! rtpmp4adepay ! aacparse ! identity silent=0 ! fakesink
At the receiver end you will see no packets coming from aacparse. You can replace aacparse with avdec_aac or decodebin and get same result.
Regards
Peterhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/272qtdemux: fragmented seek fails and goes unnoticed2021-09-24T13:31:42ZBugzilla Migration Userqtdemux: fragmented seek fails and goes unnoticed## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#766084)](https://bugzilla.gnome.org/show_bug.cgi?id=766084)**
## Description
When seeking on a fragmented file without proper seeking information, qtdemu...## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#766084)](https://bugzilla.gnome.org/show_bug.cgi?id=766084)**
## Description
When seeking on a fragmented file without proper seeking information, qtdemux will return TRUE to the seek event but when it actually tries to seek from the streaming thread it fails.
It ignored this failure, pushes a new segment event with the seek requested parameters and then goes pushing data from the same position where it was.
gst-integration-testsuites/medias/defaults/mp4/fragmented_nonseekable_sink.mp4
file from our validate tests.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/271v4l2videodec: Implement a minimal jpeg parser2021-09-24T13:31:42ZBugzilla Migration Userv4l2videodec: Implement a minimal jpeg parser## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#766076)](https://bugzilla.gnome.org/show_bug.cgi?id=766076)**
## Description
Until https://bugzilla.gnome.org/show_bug.cgi?id=626531 get addressed, it is requir...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#766076)](https://bugzilla.gnome.org/show_bug.cgi?id=766076)**
## Description
Until https://bugzilla.gnome.org/show_bug.cgi?id=626531 get addressed, it is required that all jpeg decoder can at least split the jpeg data into single frame. For this reason, v4l2videodec need to implement parsing when jpeg is selected.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/270alpha: doesn't correctly work with black or white in custom mode2021-09-24T13:31:42ZBugzilla Migration Useralpha: doesn't correctly work with black or white in custom mode## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#766060)](https://bugzilla.gnome.org/show_bug.cgi?id=766060)**
## Description
reference command - replace yellow bar in test pattern 0 with circles from other video...## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#766060)](https://bugzilla.gnome.org/show_bug.cgi?id=766060)**
## Description
reference command - replace yellow bar in test pattern 0 with circles from other videotestsrc, works as expected:
gst-launch-1.0 videotestsrc ! alpha method=3 target-r=255 target-g=255 target-b=0 ! videomixer sink_0::zorder=1 sink_1::zorder=0 name=mixer ! videoconvert ! gtksink videotestsrc pattern=11 ! mixer.
test-commands, white stripe is supposed to be transparent, in fact all others are :)
gst-launch-1.0 videotestsrc ! alpha method=3 target-r=255 target-g=255 target-b=255 ! videomixer sink_0::zorder=1 sink_1::zorder=0 name=mixer ! videoconvert ! gtksink videotestsrc pattern=11 ! mixer.
same exact symptom with black:
gst-launch-1.0 videotestsrc ! alpha method=3 target-r=0 target-g=0 target-b=0 ! videomixer sink_0::zorder=1 sink_1::zorder=0 name=mixer ! videoconvert ! gtksink videotestsrc pattern=11 ! mixer.
slomo suggested it may have something to do with alpha's internal HSV conversion. this sounds likely since pure black and white don't have a defined hue value. i'll take a look
Version: 1.8.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/269pulse: default volume should be the last from the stream2021-09-24T13:31:41ZBugzilla Migration Userpulse: default volume should be the last from the stream## Submitted by Victor Toso `@victortoso`
**[Link to original bug (#766020)](https://bugzilla.gnome.org/show_bug.cgi?id=766020)**
## Description
When I use pulseaudio backend in Spice, I retrieve the last volume from the stream usin...## Submitted by Victor Toso `@victortoso`
**[Link to original bug (#766020)](https://bugzilla.gnome.org/show_bug.cgi?id=766020)**
## Description
When I use pulseaudio backend in Spice, I retrieve the last volume from the stream using pa_ext_stream_restore_read[0] and I can sync volume between machines before any audio starts.
[0] http://b045.isibrno.cz/share/doc/pulseaudio-libs-devel-0.9.21/html/ext-stream-restore_8h.html#a3e83c1723e241f9e308be4097e1d3973
With pulsesink/pulsesrc, if I try to get the volume before the stream has started, I'll get the default "1.0" [1].
[1] https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/ext/pulse/pulsesink.c#n2612
I think we could use pa_ext_stream_restore if we have the stream-name and return that instead of 100%https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/266qtdemux: Ensure stream duration by using stts box2021-09-24T13:31:39ZBugzilla Migration Userqtdemux: Ensure stream duration by using stts box## Submitted by Seungha Yang
**[Link to original bug (#764637)](https://bugzilla.gnome.org/show_bug.cgi?id=764637)**
## Description
qtdemux: Ensure stream duration by using stts box
Some files have incorrect stream duration val...## Submitted by Seungha Yang
**[Link to original bug (#764637)](https://bugzilla.gnome.org/show_bug.cgi?id=764637)**
## Description
qtdemux: Ensure stream duration by using stts box
Some files have incorrect stream duration value in mdhd box
So, we need to double check the stream duration.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/265splitmuxsink: deadlock when reference stream has low framerate2021-09-24T13:31:38ZBugzilla Migration Usersplitmuxsink: deadlock when reference stream has low framerate## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#764635)](https://bugzilla.gnome.org/show_bug.cgi?id=764635)**
## Description
I'm using splitmuxsink with matroskamux and filesink.
I've got 3 input streams:...## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#764635)](https://bugzilla.gnome.org/show_bug.cgi?id=764635)**
## Description
I'm using splitmuxsink with matroskamux and filesink.
I've got 3 input streams:
- video: 8 jpeg frames per sec, so all buffers are keyframes
- audio: normal mp4a
- subtitle: 1 buffer every second
1) During the 1s it waits for a subtitle buffer, check_queue_length() allows audio/video queues to grow because the subtitle queued_bufs is empty, see the /* If another stream is starving, grow */ case. The 7th GOP arrives at t=875ms.
2) At t=900ms (so between 2 GOPs), the subtitle buf arrives, it's blocked in handle_mq_input() waiting for the next GOP to complete, because max_in_running_time=875ms.
3) At t=1000ms the 8th GOP arrives, max_in_running_time is set to 1000ms.
4) The subtitle buffer enters the queue but cannot go out yet because max_out_running_time is still 875ms because audio/subtitle streams didn't catchup to 1000ms yet.
5) Since the subtitle queued_bufs is not empty anymore, the audio queue is not allowed to grow anymore. So next audio buffer needed to catchup to 1000ms are blocked because its queue is full.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/262GstRtpBin and RTPSession ssrc-related signals should have ::ssrc detail2021-09-24T13:31:37ZBugzilla Migration UserGstRtpBin and RTPSession ssrc-related signals should have ::ssrc detail## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#763373)](https://bugzilla.gnome.org/show_bug.cgi?id=763373)**
## Description
For signals such as on-ssrc-active, on-ssrc-sdes, on-timeout, and many more, a commo...## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#763373)](https://bugzilla.gnome.org/show_bug.cgi?id=763373)**
## Description
For signals such as on-ssrc-active, on-ssrc-sdes, on-timeout, and many more, a common pattern is to only check when a specific SSRC is active, has timed out, etc. It would be quite useful to be able to pre-filter by specifying the SSRC in the signal detail itself.
So, for instance, you'd do:
void
on_new_ssrc (GstElement * rtpbin, guint session, guint ssrc, ...)
{
gchar *detailed_signal = g_strdup_printf ("on-ssrc-active::%u", ssrc);
g_signal_connect (rtpbin, detailed_signal, on_our_ssrc_active, NULL);
}
g_signal_connect (rtpbin, "on-new-ssrc", on_new_ssrc, NULL);
Instead of having a filter inside on_our_ssrc_active() which would have to check whether we're handling that specific SSRC.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/261scaletempo: Allow setting playback rate through the "rate" property2022-11-29T16:22:30ZBugzilla Migration Userscaletempo: Allow setting playback rate through the "rate" property## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#763025)](https://bugzilla.gnome.org/show_bug.cgi?id=763025)**
## Description
Currently the rate property is read only, but it could be writable so that the use...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#763025)](https://bugzilla.gnome.org/show_bug.cgi?id=763025)**
## Description
Currently the rate property is read only, but it could be writable so that the user could change the playback rate setting the property avoiding the need to send a seek event for that.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/259Adding MIDI playback into GStreamer2021-09-24T13:31:36ZBugzilla Migration UserAdding MIDI playback into GStreamer## Submitted by George Yunaev
**[Link to original bug (#762578)](https://bugzilla.gnome.org/show_bug.cgi?id=762578)**
## Description
I have just pushed the portable MIDI sequencer based on Sonivox library - the one used on Android. ...## Submitted by George Yunaev
**[Link to original bug (#762578)](https://bugzilla.gnome.org/show_bug.cgi?id=762578)**
## Description
I have just pushed the portable MIDI sequencer based on Sonivox library - the one used on Android. Unlike the rest of supported MIDI sequencers, this one:
- has built-in wavetable, so can render MIDI without any patches, soundfonts etc with good quality;
- is a relatively small (300Kb);
- Is used in Android, so it is supported (and I am using it in my karaokeplayer project so I intend to support it anyway);
- Builds on and works on Win/Lin/Mac
- Licensed under Apache license, so can be included into -good.
So this could be used to have built-in MIDI support in GStreamer everywhere by default without requiring external software and data files such as patches/soundfonts.
It is available here: http://github.com/gyunaev/libsonivox - there is also a test example which takes MIDI file as argument, and writes down WAV.
Unfortunately I know nothing yet about GStreamer plugins, and how "parsemidi" interacts with MIDI sequencers, so I can't create a plugin out of it. Is anyone interested?https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/258gstrtpjitterbuffer GST_QUERY_POSITION reports position and not stream_time2021-09-24T13:31:35ZBugzilla Migration Usergstrtpjitterbuffer GST_QUERY_POSITION reports position and not stream_time## Submitted by Sergio Torres Soldado (zenx)
**[Link to original bug (#762326)](https://bugzilla.gnome.org/show_bug.cgi?id=762326)**
## Description
rtpjitterbuffer reports the segment position instead of stream time for a position q...## Submitted by Sergio Torres Soldado (zenx)
**[Link to original bug (#762326)](https://bugzilla.gnome.org/show_bug.cgi?id=762326)**
## Description
rtpjitterbuffer reports the segment position instead of stream time for a position query.
in pop_and_push_next() we see that:
1) pts is set with gst_segment_to_position()
2) last_out_time is set with the pts
3) gst_rtp_jitter_buffer_src_query responds to a GST_QUERY_POSITION using npt_start and last_out_time.
Version: 1.6.3https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/257deadlock when calling rtpbin.emit("get-internal-session", 0) from python2021-09-24T13:31:34ZBugzilla Migration Userdeadlock when calling rtpbin.emit("get-internal-session", 0) from python## Submitted by Ben
**[Link to original bug (#762135)](https://bugzilla.gnome.org/show_bug.cgi?id=762135)**
## Description
Created attachment 321363
gdb output when the app deadlock
I have a python3 app that push RTP and RTCP...## Submitted by Ben
**[Link to original bug (#762135)](https://bugzilla.gnome.org/show_bug.cgi?id=762135)**
## Description
Created attachment 321363
gdb output when the app deadlock
I have a python3 app that push RTP and RTCP packets through appsrc to rtpbin.
When adding and removing rtp sources fast enough, the app deadlock at sending the gst-internal-session.
slomo comment on the irc channel:
it's ssrc_demux_pad_removed, the free_stream() thing there is doing state changes and stuff with the lock held
self.rtpbin.connect("pad-added", self.on_pad_added)
def on_pad_added(self, element, pad):
session = self.rtpbin.emit("get-internal-session", 0)
**Attachment 321363**, "gdb output when the app deadlock":
[gdb.txt](/uploads/ea806eba4d72f46c0f6a9ec6487c0259/gdb.txt)
Version: 1.6.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/254videocrop: Access violation reading2023-10-13T15:38:48ZBugzilla Migration Uservideocrop: Access violation reading## Submitted by Zakhar
**[Link to original bug (#761163)](https://bugzilla.gnome.org/show_bug.cgi?id=761163)**
## Description
1. DESCRIPTION:
If set properties (left, top, right, bottom) for videocrop while pipeline playing, it cr...## Submitted by Zakhar
**[Link to original bug (#761163)](https://bugzilla.gnome.org/show_bug.cgi?id=761163)**
## Description
1. DESCRIPTION:
If set properties (left, top, right, bottom) for videocrop while pipeline playing, it crashes sometimes with "Access violation reading".
2. HOW TO REPRODUCE:
I ofen reproduce this bug with next several elements:
videotestsrc ! video/x-raw, framerate=25/1, width=1920, height=1088 ! videocrop ! autovideosink
When the pipeline is on PLAYING state I set random values for videocrop properties (left, top, right, bottom) several times per second. After some time program crashes with "Access violation reading".
It can be reproduced only with one setting while playing. But that rarely happens.
It is reproduced on RGB and YUV frame format both.
3. STACK
msvcrt.dll!000007fefea511be()
libgstvideocrop.dll!00000000150e1e1c()
libgstvideo-1.0-0.dll!000000006d41d61f()
libgstbase-1.0-0.dll!00000000198e6930()
libgstbase-1.0-0.dll!00000000198e63ba()
libgstreamer-1.0-0.dll!0000000061481054()
libgstbase-1.0-0.dll!00000000198e638d()
libgstreamer-1.0-0.dll!0000000061481054()
libgstbase-1.0-0.dll!00000000198e2436()
libgstreamer-1.0-0.dll!00000000614af514()
libglib-2.0-0.dll!00000000686154b5()
libglib-2.0-0.dll!0000000068614cc9()
libglib-2.0-0.dll!000000006863103a()
[External Code]
Version: 1.6.3