GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T13:31:55Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/299avidemux: h264 variant itu, regression from 0.102021-09-24T13:31:55ZBugzilla Migration Useravidemux: h264 variant itu, regression from 0.10## Submitted by Nicola `@drakkan`
**[Link to original bug (#771707)](https://bugzilla.gnome.org/show_bug.cgi?id=771707)**
## Description
I have an avi with h264 variant itu, here are the caps:
video/x-h264, variant=(string)itu,...## Submitted by Nicola `@drakkan`
**[Link to original bug (#771707)](https://bugzilla.gnome.org/show_bug.cgi?id=771707)**
## Description
I have an avi with h264 variant itu, here are the caps:
video/x-h264, variant=(string)itu, framerate=(fraction)120/1, width=(int)320, height=(int)240, codec_data=(buffer)2000000127644014ac2b40a0fd8088000003000800000301e42000000128ee1f2c0000000000000000000000000000000000
this file works fine in 0.10 but in 1.0 give not negotiated, in 0.10 ffdec_h264 show sink caps as:
SINK template: 'sink'
Availability: Always
Capabilities:
video/x-h264
width: [ 16, 4096 ]
height: [ 16, 4096 ]
framerate: [ 0/1, 2147483647/1 ]
while in 1.0 the format are restricted:
SINK template: 'sink'
Availability: Always
Capabilities:
video/x-h264
alignment: au
stream-format: { avc, byte-stream }
if I change avdec_h264 so that gst-inspect shows this:
SINK template: 'sink'
Availability: Always
Capabilities:
video/x-h264
then the file plays fine,
is this acceptable? Do you have other suggestions for a better patch?https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/298Adding additional tags to FLV header2021-09-24T13:31:55ZBugzilla Migration UserAdding additional tags to FLV header## Submitted by Sudhir Kesti
**[Link to original bug (#771650)](https://bugzilla.gnome.org/show_bug.cgi?id=771650)**
## Description
Created attachment 335848
Newly added tags
Few CDNs recommend to have following tags in FLV h...## Submitted by Sudhir Kesti
**[Link to original bug (#771650)](https://bugzilla.gnome.org/show_bug.cgi?id=771650)**
## Description
Created attachment 335848
Newly added tags
Few CDNs recommend to have following tags in FLV headers, in rtmp stream.
• videocodecid
• audiocodecid
• audioonly
• videoonly
• stereo
• width
• height
• videodatarate
• audiodatarate
• audiosamplerate
• audiosamplesize
• audiochannels
• framerate
• avcprofile
• avclevel
• aacaot
But current flvmux do not have few of them. I have added missing tags, and validated it. Seems to be working, please find patch in the attachment.
Can some one review the patch ??
One can use following pipeline for testing:
gst-launch-1.0 videotestsrc is-live=1 ! video/x-raw,width=176,height=144,framerate=25/1 ! x264enc ! flvmux streamable=true name=mux ! fakesink audiotestsrc ! audio/x-raw,rate=48000,channels=2,format="S16LE" ! voaacenc bitrate=24000 ! mux. --gst-debug=*flv*:5
~~**Patch 335848**~~, "Newly added tags":
[patch.c](/uploads/4e0350deb747b97d0669a829fdcd9218/patch.c)
Version: 1.9.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/297mp4mux: add to support eac3 muxing2021-09-24T13:31:54ZBugzilla Migration Usermp4mux: add to support eac3 muxing## Submitted by Wonchul Lee
**[Link to original bug (#771087)](https://bugzilla.gnome.org/show_bug.cgi?id=771087)**
## Description
We found most of muxer has not been providing eac3 audio muxing, so I added to support eac3 muxing on...## Submitted by Wonchul Lee
**[Link to original bug (#771087)](https://bugzilla.gnome.org/show_bug.cgi?id=771087)**
## Description
We found most of muxer has not been providing eac3 audio muxing, so I added to support eac3 muxing on mp4mux for the first step referred to the A/52:2012.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/296rtpssrcdemux: Fix race condition in clear-ssrc signal handler2021-09-24T13:31:54ZBugzilla Migration Userrtpssrcdemux: Fix race condition in clear-ssrc signal handler## Submitted by GstBlub
**[Link to original bug (#770766)](https://bugzilla.gnome.org/show_bug.cgi?id=770766)**
## Description
Created attachment 334666
rtpssrcdemux: Fix race condition in clear-ssrc signal handler
I sometime...## Submitted by GstBlub
**[Link to original bug (#770766)](https://bugzilla.gnome.org/show_bug.cgi?id=770766)**
## Description
Created attachment 334666
rtpssrcdemux: Fix race condition in clear-ssrc signal handler
I sometimes run into a critical error like this:
GStreamer-CRITICAL **: Padname src_1119852695 is not unique in element rtpssrcdemux2, not adding
This is because of a race condition with clear-ssrc and another rtp/rtcp packet with the same ssrc coming in, which could cause a new pad with the same name to be added before the one being cleared was actually removed.
~~**Patch 334666**~~, "rtpssrcdemux: Fix race condition in clear-ssrc signal handler":
[0001-rtpssrcdemux-Fix-race-condition-in-clear-ssrc-signal.patch](/uploads/123f02e7c3b2c6d316ac117f83681220/0001-rtpssrcdemux-Fix-race-condition-in-clear-ssrc-signal.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/295qtdemux: Not considering sample size when calculating size of chunk.2021-09-24T13:31:54ZBugzilla Migration Userqtdemux: Not considering sample size when calculating size of chunk.## Submitted by wes..@..il.com
**[Link to original bug (#770678)](https://bugzilla.gnome.org/show_bug.cgi?id=770678)**
## Description
The size of chunk is not taking into account the size of samples. Some mp4 files have stream->samp...## Submitted by wes..@..il.com
**[Link to original bug (#770678)](https://bugzilla.gnome.org/show_bug.cgi?id=770678)**
## Description
The size of chunk is not taking into account the size of samples. Some mp4 files have stream->sample_size != 1. When this occurs they will not play audio. If stream->sample_size is 1 the current code works.
What I'm proposing is a change here to lines: 7799/7800
if (stream->samples_per_frame * stream->bytes_per_frame) {
cur->size =
- (stream->samples_per_chunk * stream->n_channels) /
- stream->samples_per_frame * stream->bytes_per_frame;
+ ((stream->samples_per_chunk * stream->n_channels) /
+ stream->samples_per_frame) * stream->bytes_per_frame * stream->sample_size;
} else {
cur->size = stream->samples_per_chunk;
}https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/294aacparse converts mpeg2 aac to mpeg4 aac unconditionally2021-09-24T13:31:53ZBugzilla Migration Useraacparse converts mpeg2 aac to mpeg4 aac unconditionally## Submitted by Baby octopus
**[Link to original bug (#770469)](https://bugzilla.gnome.org/show_bug.cgi?id=770469)**
## Description
Created attachment 334261
TS file with mpeg2 aac audio
aacparse element always converts mpeg2...## Submitted by Baby octopus
**[Link to original bug (#770469)](https://bugzilla.gnome.org/show_bug.cgi?id=770469)**
## Description
Created attachment 334261
TS file with mpeg2 aac audio
aacparse element always converts mpeg2 aac to mpeg4 aac though it should support mpeg2aac parsing as per the src & sink caps.
I have attahced the file. Following gst-launch pipeline demonstrates it on 1.9.1 on windows
e:\gstreamer\1.0\x86\bin>gst-launch-1.0.exe filesrc location=c:/temp/out.ts ! tsdemux ! aacparse ! fakesink -v
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstAacParse:aacparse0.GstPad:sink: caps = audio/mpeg, mpegversion=(int)2, stream-format=(string)adts
/GstPipeline:pipeline0/GstAacParse:aacparse0.GstPad:src: caps = audio/mpeg, framed=(boolean)true, mpegversion=(int)4, level=(string)2, base-profile=(string)lc, profile=(s
tring)lc, rate=(int)48000, channels=(int)2, stream-format=(string)adts
/GstPipeline:pipeline0/GstFakeSink:fakesink0.GstPad:sink: caps = audio/mpeg, framed=(boolean)true, mpegversion=(int)4, level=(string)2, base-profile=(string)lc, profile=(
string)lc, rate=(int)48000, channels=(int)2, stream-format=(string)adts
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.013933636
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
**Attachment 334261**, "TS file with mpeg2 aac audio":
[out.ts](/uploads/c214ba8ccc41430073331ac2a24228ad/out.ts)
Version: 1.9.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/293flacenc: Implement flushing2021-09-24T13:31:53ZBugzilla Migration Userflacenc: Implement flushing## Submitted by GstBlub
**[Link to original bug (#770461)](https://bugzilla.gnome.org/show_bug.cgi?id=770461)**
## Description
Created attachment 334249
flacenc: Implement flushing
This allows flacenc to flush its internal st...## Submitted by GstBlub
**[Link to original bug (#770461)](https://bugzilla.gnome.org/show_bug.cgi?id=770461)**
## Description
Created attachment 334249
flacenc: Implement flushing
This allows flacenc to flush its internal state when requested to do so. This is useful when placed into a pipeline to transcode and a seek is performed on that pipeline. Currently, a seek would lead to an error (+ assertion) like this:
WARN: gstaudioencoder.c:gst_audio_encoder_finish_frame:1028: error: received more encoded samples 4608 than provided 684 as inputs
~~**Patch 334249**~~, "flacenc: Implement flushing":
[0001-flacenc-Implement-flushing.patch](/uploads/0df576da05dbbf7e35037ddd0418babf/0001-flacenc-Implement-flushing.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/292rtpsession: Add property "stats-min-interval"2021-09-24T13:31:52ZBugzilla Migration Userrtpsession: Add property "stats-min-interval"## Submitted by Håvard Graff (hgr)
**[Link to original bug (#770291)](https://bugzilla.gnome.org/show_bug.cgi?id=770291)**
## Description
Created attachment 334026
patch
Add property to throttle the rate at which rtpsession n...## Submitted by Håvard Graff (hgr)
**[Link to original bug (#770291)](https://bugzilla.gnome.org/show_bug.cgi?id=770291)**
## Description
Created attachment 334026
patch
Add property to throttle the rate at which rtpsession notifies about
"stats".
With any incoming RTCP potentially triggering this callback, things like RTX and APP messages might effectively spam you with stats, so this is a simple mechanism to make sure they are throttled.
**Patch 334026**, "patch":
[rtpsession-stats-min-interval.patch](/uploads/c2a576f8cd2a1e4873d937162a8472de/rtpsession-stats-min-interval.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/291multiudpsink: Add round-robin property2021-09-24T13:31:52ZBugzilla Migration Usermultiudpsink: Add round-robin property## Submitted by GstBlub
**[Link to original bug (#770150)](https://bugzilla.gnome.org/show_bug.cgi?id=770150)**
## Description
Created attachment 333643
multiudpsink: Add round-robin property
This new property allows changing...## Submitted by GstBlub
**[Link to original bug (#770150)](https://bugzilla.gnome.org/show_bug.cgi?id=770150)**
## Description
Created attachment 333643
multiudpsink: Add round-robin property
This new property allows changing the way lists of buffers are being sent out. If enabled, instead of sending n buffers to each client at a time, it sends the first buffer to all clients before iterating to the next buffer. This avoids bursts of packets to each endpoint, which can get overwhelmed reading large number of packets, which eventually leads to dropped packets once the socket receive buffer fills up due to such bursts.
**Patch 333643**, "multiudpsink: Add round-robin property":
[0001-multiudpsink-Add-round-robin-property.patch](/uploads/a8c973a0624faea99c86b805bd2140c7/0001-multiudpsink-Add-round-robin-property.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/289rtpmanager: Reduce the number of upstream GstRTPRetransmissionRequest events.2021-09-24T13:31:52ZBugzilla Migration Userrtpmanager: Reduce the number of upstream GstRTPRetransmissionRequest events.## Submitted by GstBlub
**[Link to original bug (#769769)](https://bugzilla.gnome.org/show_bug.cgi?id=769769)**
## Description
Created attachment 333145
rtpmanager: Reduce the number of upstream GstRTPRetransmissionRequest events....## Submitted by GstBlub
**[Link to original bug (#769769)](https://bugzilla.gnome.org/show_bug.cgi?id=769769)**
## Description
Created attachment 333145
rtpmanager: Reduce the number of upstream GstRTPRetransmissionRequest events.
Rather than sending one GstRTPRetransmissionRequest upstream event for each sequence number from a RR, send one per FCI entry. Should reduce upstream events significantly in high packet loss situations.
**Patch 333145**, "rtpmanager: Reduce the number of upstream GstRTPRetransmissionRequest events.":
[0001-rtpmanager-Reduce-the-number-of-upstream-GstRTPRetra.patch](/uploads/9b5f26eb99046c78d3e594b2f5266854/0001-rtpmanager-Reduce-the-number-of-upstream-GstRTPRetra.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/288splitmuxsink add property with start file id2021-09-24T13:31:51ZBugzilla Migration Usersplitmuxsink add property with start file id## Submitted by m][sko
**[Link to original bug (#769008)](https://bugzilla.gnome.org/show_bug.cgi?id=769008)**
## Description
Created attachment 331840
add_start_file_id_property
I made patch that add property with start file...## Submitted by m][sko
**[Link to original bug (#769008)](https://bugzilla.gnome.org/show_bug.cgi?id=769008)**
## Description
Created attachment 331840
add_start_file_id_property
I made patch that add property with start file id
Fill free to refactor name, code,...
**Patch 331840**, "add_start_file_id_property":
[0001-splitmuxsink-new-property-start-file-id.patch](/uploads/c7986edd8df7ccbdbbe107e794f6ece5/0001-splitmuxsink-new-property-start-file-id.patch)
Version: 1.9.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/287qtdemux: Use upstream framerate if available2021-09-24T13:31:51ZBugzilla Migration Userqtdemux: Use upstream framerate if available## Submitted by Seungha Yang
**[Link to original bug (#768901)](https://bugzilla.gnome.org/show_bug.cgi?id=768901)**
## Description
In case of dash streaming, dashdemux provides framerate.
So, let's use it rather than calculate it...## Submitted by Seungha Yang
**[Link to original bug (#768901)](https://bugzilla.gnome.org/show_bug.cgi?id=768901)**
## Description
In case of dash streaming, dashdemux provides framerate.
So, let's use it rather than calculate it in order to prevent noisy
caps event which results from slightly varying calculated framerate.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/286rtpjitterbuffer: Considers packets too late due to wraparound2021-09-24T13:31:50ZBugzilla Migration Userrtpjitterbuffer: Considers packets too late due to wraparound## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#768715)](https://bugzilla.gnome.org/show_bug.cgi?id=768715)**
## Description
https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtpmanager/gstrtpjitter...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#768715)](https://bugzilla.gnome.org/show_bug.cgi?id=768715)**
## Description
https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtpmanager/gstrtpjitterbuffer.c?id=5328378132c7c100b8a17818862a3124affef1f8#n2829
This check will also trigger if more than 2**15 packets are queued up in the jitterbuffer, as the latest packet we received will then be considered as a wraparound close to the latest packet we popped.
The check will have to be made more correct somehow, or removed completely (why is it there at all?). It was added in commit eaa23fd4 in 2008 :)
We could probably just add the number of queued up packets to the last popped sequence number, and use that for comparison. It's not going to be 100% correct (there might be missing packets), but it should be far less than 2**15 (otherwise we would've reset already).
Any better ideas?
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/285avidemux: do not increase num_streams when parse_stream fail2021-09-24T13:31:49ZBugzilla Migration Useravidemux: do not increase num_streams when parse_stream fail## Submitted by Seoungil Kang
**[Link to original bug (#768467)](https://bugzilla.gnome.org/show_bug.cgi?id=768467)**
## Description
Created attachment 330929
patch for this issue.
Failure handling code in the function "gst_a...## Submitted by Seoungil Kang
**[Link to original bug (#768467)](https://bugzilla.gnome.org/show_bug.cgi?id=768467)**
## Description
Created attachment 330929
patch for this issue.
Failure handling code in the function "gst_avi_demux_parse_stream()"
increases num_streams of avi context. It's causing SIGSEGV because the
stream data structure indexed by num_streams is not updated after
initializing to 0 or NULL.
~~**Patch 330929**~~, "patch for this issue.":
[0001-avidemux-do-not-increase-num_streams-when-parse-fail.patch](/uploads/5fc8afc8a6317de5d76b226934545792/0001-avidemux-do-not-increase-num_streams-when-parse-fail.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/284amrparse: Sticky event misordering, got caps before stream-start warning2021-09-24T13:31:49ZBugzilla Migration Useramrparse: Sticky event misordering, got caps before stream-start warning## Submitted by Lyon
**[Link to original bug (#768166)](https://bugzilla.gnome.org/show_bug.cgi?id=768166)**
## Description
Created attachment 330523
the amr clip for test
When I was test amr clip, it will always print warnin...## Submitted by Lyon
**[Link to original bug (#768166)](https://bugzilla.gnome.org/show_bug.cgi?id=768166)**
## Description
Created attachment 330523
the amr clip for test
When I was test amr clip, it will always print warning:
(gst-launch-1.0:937): GStreamer-WARNING **: ../../gstreamer-1.8.1/gst/gstpad.c:5052:store_sticky_event:<amrparse0:src> Sticky event misordering, got 'caps' before 'stream-start
This issue could be always found on low cpufrequency board, and sometimes on high cpu frequency environment.
The command line:
gst-launch-1.0 playbin uri=file://`pwd`/N1_8_1_4.75_crescent_Country1.amr
Is there any related issue for this case
I saw some similar ticket:
https://bugzilla.gnome.org/show_bug.cgi?id=699894
https://bugzilla.gnome.org/show_bug.cgi?id=699895
https://bugzilla.gnome.org/show_bug.cgi?id=766359
**Attachment 330523**, "the amr clip for test":
[N1_8_1_4.75_crescent_Country1.amr](/uploads/3c3cc929f6373faa3536a98796da4de3/N1_8_1_4.75_crescent_Country1.amr)
Version: 1.8.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/283rtspsrc: Occasional crash on start/stop cycles2021-09-24T13:31:48ZBugzilla Migration Userrtspsrc: Occasional crash on start/stop cycles## Submitted by Jonathan Roy
**[Link to original bug (#768140)](https://bugzilla.gnome.org/show_bug.cgi?id=768140)**
## Description
Created attachment 330484
gst_rtspsrc_cleanup patch against concurrent access to streams
Cycl...## Submitted by Jonathan Roy
**[Link to original bug (#768140)](https://bugzilla.gnome.org/show_bug.cgi?id=768140)**
## Description
Created attachment 330484
gst_rtspsrc_cleanup patch against concurrent access to streams
Cyclically starting and stopping RTSP stream using rtspsrc may result in crash due to concurrency issue in cleanup method. Attached patch fixes the issue.
**Patch 330484**, "gst_rtspsrc_cleanup patch against concurrent access to streams":
[0001-libgstrtsp-start-stop-crash.patch](/uploads/1b472f51a4ff299c43fbd9af16c98fc4/0001-libgstrtsp-start-stop-crash.patch)
Version: 1.8.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/282flvdemux: Gets confused when fed with different streams2021-09-24T13:31:48ZBugzilla Migration Userflvdemux: Gets confused when fed with different streams## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#768005)](https://bugzilla.gnome.org/show_bug.cgi?id=768005)**
## Description
Using the files from here:
https://ahiru.eu/~vivia/parts1to7.tar
$ gst-launch...## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#768005)](https://bugzilla.gnome.org/show_bug.cgi?id=768005)**
## Description
Using the files from here:
https://ahiru.eu/~vivia/parts1to7.tar
$ gst-launch-1.0 splitmuxsrc location="part*.flv" name=d d.video ! queue ! h264parse ! matroskamux name=m ! queue ! filesink location=allparts2.mkv d.audio ! aacparse ! queue ! m.
This works fine.
[fish syntax warning]
$ env GST_DEBUG=\*:3 gst-launch-1.0 multifilesrc location="part%02d.flv" start-index=1 stop-index=7 ! queue ! flvdemux name=d d.video ! queue ! h264parse ! matroskamux name=m ! queue ! filesink location=allparts1.mkv d.audio ! aacparse ! queue ! m.
[...]
0:00:01.216200161 22013 0xfbf320 WARN flvdemux gstflvdemux.c:1307:gst_flv_demux_video_negotiate:`<d>` unsupported video codec tag 8
0:00:01.216265742 22013 0xfbf320 WARN flvdemux gstflvdemux.c:1311:gst_flv_demux_video_negotiate:`<d>` failed creating caps for video pad
0:00:01.216353327 22013 0xfbf320 WARN queue gstqueue.c:1541:gst_queue_loop:`<queue0>` error: Internal data flow error.
0:00:01.216420933 22013 0xfbf320 WARN queue gstqueue.c:1541:gst_queue_loop:`<queue0>` error: streaming task paused, reason error (-5)
ERROR: from element /GstPipeline:pipeline0/GstQueue:queue0: Internal data flow error.
Additional debug info:
gstqueue.c(1541): gst_queue_loop (): /GstPipeline:pipeline0/GstQueue:queue0:
streaming task paused, reason error (-5)
The video codec tag 8 is completely bogus, the file is H264, like all the previous ones. gst-discoverer and gst-play agree with me, as well as the first example.
$ gst-launch-1.0 multifilesrc location="part%02d.flv" start-index=2 stop-index=7 ! queue ! flvdemux name=d d.video ! queue ! h264parse ! matroskamux name=m ! queue ! filesink location=allparts1.mkv d.audio ! aacparse ! queue ! m.
The resulting file is valid, but it only contains the contents of part02.flv .https://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.