[Bug 778690] New: Possible bug on gst-1.11 gst_element_seek

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

Bug ID: 778690
Summary: Possible bug on gst-1.11 gst_element_seek
Classification: Platform
Product: GStreamer
Version: 1.11.1
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gstreamer (core)
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@telenet.be
QA Contact: gstreamer-***@lists.freedesktop.org
GNOME version: ---

Created attachment 345845
--> https://bugzilla.gnome.org/attachment.cgi?id=345845&action=edit
media sample with problem.

Just found an issue when using :

example in code .

" if (!gst_element_seek (m_gst_playbin, m_currentTrickRatio,
GST_FORMAT_TIME, (GstSeekFlags)(GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_KEY_UNIT),
GST_SEEK_TYPE_SET, m_last_seek_pos,
GST_SEEK_TYPE_NONE, GST_CLOCK_TIME_NONE))"

By some media it always jump back to media start position. (while it for that
media works when using gstreamer-0.1 and same seek procedure is followed)
I also tried to add the flag GST_SEEK_FLAG_SNAP_AFTER , then it jumps to so
what 2/3 of the movie further (89 minutes). What is typic on the media is that
for example it has a video start segment at 41711111 while the audio start
segment is 0. When using flag GST_SEEK_FLAG_ACCURATE instead of KEY_UNIT it
works but to slow. A media example is : I added the torrent download tracker.
Note we are working on a stb so the basesink runs with sync and async false.

By gst-0.1 this problem does not occur.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #1 from christophe vr <***@telenet.be> ---
Note this problem also did not occured on gst version-1.8.2 has just been
reported to me.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

Sebastian Dröge (slomo) <***@coaxion.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
CC| |***@coaxion.net

--- Comment #2 from Sebastian Dröge (slomo) <***@coaxion.net> ---
Please provide a testcase and instructions to reproduce the behaviour.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #3 from christophe vr <***@telenet.be> ---
I just made a log. From the specific media start, then I did one jump which is
suposed to be 6 minutes further into the movie. I have here the combined log
application enigma2, stb is a GIGABLUE Quad(mips32) . gst release-1.11.1 .
I added extra debug output where You can see that we asked the jump in stb pts
and set the seek into nanoseconds position seek (is stb pts * 11111) is time in
nanoseconds. Instead of jumping to the requested position it restarted the
movie.

The movie self has for video a start position of 41711111 audio 0. h264 codec
and aac audio (they are all passtrough.)

Log included

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #4 from christophe vr <***@telenet.be> ---
Created attachment 345854
--> https://bugzilla.gnome.org/attachment.cgi?id=345854&action=edit
jump log

the log is made with GST_DEBUG=*:4,bin:1 the bin does have an very ugly debug
output with fixme something with cache. So intensif that it would make the log
unreadable and actually to big.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #5 from christophe vr <***@telenet.be> ---
actually its a requested jump off 89 seconds

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #6 from christophe vr <***@telenet.be> ---
Created attachment 345860
--> https://bugzilla.gnome.org/attachment.cgi?id=345860&action=edit
jump log 5 minutes jump.

actually here the jump log of 5 minutes further jump. only the jump here. But
as can be seen it creates a knew segment start movie.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #7 from christophe vr <***@telenet.be> ---
Ter info at this time I also can't reproduce it with the test player :
gst-play-1.0 since the funktion chapter jump should we have a mkv container
with chapter is not suported there, ok this last fragment is well m4v and
gstreamer can't parse the chapter info by MP4 so it would not work anyway. But
eventually add extra commands like for example jump of 60 seconds further in
movie or 9 key 5 minutes further or so could help. I will see see if that can
be added as extra function to gst-play-1.0. a couple of time jumps with
keyboard keys, that simulates a bit the chapter or movie resume points.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #8 from christophe vr <***@telenet.be> ---
Created attachment 345896
--> https://bugzilla.gnome.org/attachment.cgi?id=345896&action=edit
gst-player-jump patch

I for test builded the very last master git of gstreamer.
Then I created a jump-seek into gst-player-1.0. Now when gst-player-1.0 is
running , it is only made for and tested with player in normal play mode. You
can do a jump of 60 seconds with keyboard key 6 or 5 minutes with keyboard key
9.
This simulates the most common used jump mode for chapter jumps or movie resume
positions. And indeed with the movie sample I posted here it will always jump
to start of movie. But with other movies it works.

That is clearly a bug introduced in gstreamer between version 1.8.2 and the
current master. By gst-1.8.2 this movie jumps fine (is reported to me by
others) by gst-0.1 it also works fine.

But if You use this patch You have the tools to investigate in gst-play-1.0

It is clearly not a stb related issue since it's the same on ubuntu 16.04 pc.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

Jan Schmidt <***@noraisin.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@noraisin.net

--- Comment #9 from Jan Schmidt <***@noraisin.net> ---
If I've understood all the above correctly, this is a bug that is reproducable
by doing a KEY_UNIT seek in a specific MP4 file containing H.264 and AAC.

The most useful debug log is probably from qtdemux via GST_DEBUG=*qtdemux*:6

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #10 from christophe vr <***@telenet.be> ---
Hello, Yes indeed. I self I'm bussy with main e2 player for stb's, called a bit
odd servicemp3.cpp. Since on a stb we only can with sync false for video (stb
does not have enough cpu power to handle the vsync on streams higher then sd
resolutions) and the quit high audio queue mem (up to +60 seconds on aac audio)
and up to 90 seconds by some video codecs. We must work with sync false and
async false. Up on pausing media to avoid a to long wait on the state change of
the pipeline we do a such seek-flush a seek based on the real playposition
which is polled in the video mem by ioctl command. and audio mem for audio only
media.

But indeed it took me quit a while to find out why in some cases I had reports
of such strange issues with a movie restart or .. And then the discovering that
with gst-0.1 no problems.

But now I'm happy I self have a tool to investigate some working ways or
actions on ubuntu pc with last master git.
I will check with qtdemux, hope that in that log can be found why it does not
find a KEY_UNIT by some media , think it is related to the difference in video
start segment and audio start segment. By the media I posted here we do have a
video start segment of 41711111 and audio start segment off 0 .so here almost
42 ms difference. That is quit typic for a lot off HD media using h264 or h265
codecs.

up to gst-1.8.2 this was no problem at all, the problem must come from some
changes between 1.8.2 and the currently used master git.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #11 from christophe vr <***@telenet.be> ---
p.s. how can we again launch the debug whitout colors,

qtdemux 6 is to heavy but 5 ok then can be indeed seen that qtdemux does not
find the key.

I tried to run : to have a log instead of terminal output :

GST_DEBUG=*qtdemux*:5 gst-play-1.0 Arrival720pHD.m4v 2> problem-media.txt

But I must be rid of the colors how can I do that.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #12 from Jan Schmidt <***@noraisin.net> ---
(In reply to christophe vr from comment #11)

Post by "GStreamer" (GNOME Bugzilla)
p.s. how can we again launch the debug whitout colors,
qtdemux 6 is to heavy but 5 ok then can be indeed seen that qtdemux does not
find the key.
GST_DEBUG=*qtdemux*:5 gst-play-1.0 Arrival720pHD.m4v 2> problem-media.txt
But I must be rid of the colors how can I do that.

GST_DEBUG_NO_COLOR=1

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #13 from christophe vr <***@telenet.be> ---
Thanks , in the mean time I used --gst-debug-no-color worked also (I made a
mistake with that by using the one I used on stb for e2 whitout color) sorry
not used to debug gstreamer on pc.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

Tim-Philipp Müller <***@zen.co.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@zen.co.uk
Component|gstreamer (core) |gst-plugins-good
Summary|Possible bug on gst-1.11 |qtdemux: Possible bug on
|gst_element_seek |gst-1.11 gst_element_seek

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #14 from christophe vr <***@telenet.be> ---
Well I tried to make a log so short as possible on the media.

media start once it runs ok direct a jump of 5 minutes forward once it played
again (here with problem media it back to movie start) quit the gst-player. But
the log is still 305 Mb of size. It can't be opened with reqular gedit or so to
big. But think with vim in terminal it should work. Sin even copmpressed it is
29 Mb I can post it here but I put it on my drop box here the link.

Looks like the qtdemux has a general problem with indexing. for such media
type. So it will be quit common by a lot of HD media using h264 I gues.

link :

https://www.dropbox.com/s/2k66nu89gcbzj3u/problem-media-log.tar.bz2?dl=1

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #15 from christophe vr <***@telenet.be> ---
Created attachment 345933
--> https://bugzilla.gnome.org/attachment.cgi?id=345933&action=edit
problem-media-just-start

Hi improved the debug. first just the start log of media only until playing in
debug5 for stdemux.

And here the link of just a single jump from request till the media instead of
jumping restarted. This is stil big but now around 64 mb so You can already
work with it en emacds and even gedit.

https://www.dropbox.com/s/h5m1dc3aeftafxs/problem-media-just-jump-log.tar.gz?dl=1

the jump is one for 60 seconds which I requested.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

christophe vr <***@telenet.be> changed:

What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |major

--- Comment #16 from christophe vr <***@telenet.be> ---
I raised the level from normal to major, Since it breaks the use of a lot off
players installed on devices who all use the GST_SEEK_FLAG_KEY_UNIT and need to
do that. cause GST_SEEK_FLAG_ACCURATE is far to slow and cpu intensif for such
devices.

At least for hd media with several audio tracks sub tracks.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #17 from christophe vr <***@telenet.be> ---
Is it not time to change this bug into something else then need info ? It is a
very severe one and :

!!!!!
It was NEVER PRESENT ON gst VERSION UP TO 1.8.2 then it started.

I give really all you need + extra tools that every developer can test self
with gst-play-1.0 .

More I can't do . But that NEED INFO NOW IS REALLY WRONG and the bug IS REALLY
MAJOR (not critical since there is no crash , but seeing the logs self we are
on the edge of a sever crash)

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #18 from christophe vr <***@telenet.be> ---
As last This bug maybe not critical cause it does not crash the application and
or device. But it is 100 % critical up on use off any gstreamer version above
1.8.2 the day a stb image or any application based on gstreamer is going from
beta to final release phase. It is very very high in importance to solve this
asap (so important it had to be solved yesterday) So i'm very very insulted
that this bug is still on need info while I proved by 100 % it is true and a
very very very severe bug

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #19 from christophe vr <***@telenet.be> ---
Sorry but just cause the state in the mean time is still at info, While more
info as what I did can't be provided, but the info i give is 100 % true and it
proves by 100 % that there is a severe bug into gstreamer which came up between
version 1.8.2 and the current master it is still present I raised the level to
critical.

Quit simple a gstreamer versions which can't make a jump like it always has
done in the past is a unusable version.

The last descent gstreamer version is 1.8.2 concerning file media. off course
we then again face the problem that hls media almost does not work.

So yes I think I'm loosing my time in e2 images off stb's as gstreamer is has
very severe problems overall. In gst 1.8.2 the hls hardly works in gst1.11.1
the hls is ok but you can not jump anymore with GST_SEEK_FLAG_KEY_UNIT so ...
unusable gstreamer version .

**** WE ARE FACING A CRITICAL BUG IN GSTREAMER ***** !!!!!!!

and developers do nothing else then saying need info ??????

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

christophe vr <***@telenet.be> changed:

What |Removed |Added
----------------------------------------------------------------------------
Severity|major |critical

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #20 from christophe vr <***@telenet.be> ---
Well still no answer , ?

Do not make a effort anymore, I'll give up on gstreamer (like several persons
already told me since long its' true the gstreamer team makes bug on bug and
does only react with need info on every descent 100 % good documented and
explained report)

I indeed like they advised me since long will more study the use off ffmpeg.
Since the fact that this very severe report and true facts extremely high
documented and proved , causes the idiot reaction NEEDINFO ????? wel sorry but
on any version of gst 1.8.2 and below all media can handle this seek. Inclusive
the media I posted over here. I Also posted the tools since Mister Sebastian
asked instruction to reproduce, .... all this is done, and still ...... NOOP

As long this VERY VERY SEVERE BUG is not solved it does not make ANY ANY sence
to make an application using gstreamer as it always will suck on seek .

Sorry I was one of the biggest defenders of gstreamer in e2 but unfortunately
this extreme poor reaction on the bug report more documented and proved then
many others but it is a very very very critical issue in e2 and it will anyway
show up on the majority of devices in future is just a 100% NO GO for
gstreamer.

And should have been solved yesterday.

So yes finally merge to ffmpeg becomes a considerable option as long as such a
extremely important seek can't be done GST_SEEK_FLAG_KEY_UNIT .

And yes all other work should be suspend until this issue is solved so
important it is. It is just simply break down of main working off gst .

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

christophe vr <***@telenet.be> changed:

What |Removed |Added
----------------------------------------------------------------------------
Severity|critical |blocker

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #21 from christophe vr <***@telenet.be> ---
Again no answer for such a very extreme bug.

Note that the majority of devices do use a gstreamer version up or far below
1.8.2 and they DO NOT HAVE THIS VERY SEVERE ISSUE . So the day they upgrade for
example media resume will be broken by 100 % (for such media which worked very
well on gst-0.1 and ok til 1.8.2 !!!) Good luck in explaining why ......
without lies.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

Sebastian Dröge (slomo) <***@coaxion.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
Severity|blocker |normal

--- Comment #22 from Sebastian Dröge (slomo) <***@coaxion.net> ---
You do realize that what you get here is free support by volunteers in their
spare time? If this issue is very urgent for you, all the source code is
available for you to solve the problem yourself or you could contract someone
to solve it for you, in which case you can demand some fast response times
(depending on your actual contract then).

If you think your problems are important enough for myself or someone else to
immediately (or at all) spend their spare time on it, may I ask you to come
over and solve some things I wanted to get done in my apartment? No? Then
reconsider your tone in the future, why do you think you're entitled to someone
else's time? Are you sitting all day in front of your computer and just waiting
to jump on some problem some random stranger on the Internet is sending your
way?


I'm sure there's something broken here. But there are lots of other bugs in
Bugzilla that are equally important for whoever reported them as this specific
one is for you. Help to get some out of the way, fewer bugs means it's more
likely that someone gets interested in fixing yours.

Considering your behaviour so far you can however be glad if someone ever wants
to spend time on anything you report. Nonetheless I'm marking this bug as "NEW"
again, you provided the information that was asked for but I (and apparently
nobody else) did get to that since you provided that info.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #23 from Jan Schmidt <***@noraisin.net> ---
I think the problem with this stream is that qtdemux snaps the seek using the
earliest keyframe of all the streams, which ends up being time 0 because it
contains text subtitles.

The packets for those should probably be treated as all keyframes, or else
subtitle streams should be ignored entirely for the purposes of key-unit seeks.

I'm not sure why that's different to 1.8, but there were changes around how the
key-unit snapping is calculated in qtdemux so it's probably in there.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #24 from Jan Schmidt <***@noraisin.net> ---
My commit 107902ec is the root cause. That commit attempts to make sure that a
snapping seek actually starts at the start of a keyframe instead of in the
middle of one, but doesn't cope when streams are sparse or (as in this stream)
there's a track with a single JPEG image cover art "keyframe" that starts at
time 0 and covers the whole stream.

Revert 107902ec in gst-plugins-good for a workaround.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

Jan Schmidt <***@noraisin.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Target Milestone|git master |1.11.2

--- Comment #25 from Jan Schmidt <***@noraisin.net> ---
commit 488e8edba4527d7e8da9b45a42ffd3927f7ac449
Author: Jan Schmidt <***@centricular.com>
Date: Fri Feb 17 13:07:05 2017 +1100

Revert "qtdemux: Always snap to the start of the keyframe"

This reverts commit 107902ec514bd826aa29d2298107e2c091e1c779.

This commit intended to ensure that keyframe seeks land at the
start timestamp of a keyframe, rather than in the middle of one,
but they cause trouble on files with sparse streams, or with
JPEG 'cover art' tracks that have only one or a few JPEG samples
with very long durations.

That's still desirable for doing seamless cutting of videos,
but needs a rethink for implementation.

https://bugzilla.gnome.org/show_bug.cgi?id=778690

Leaving the bug open, because just reverting that commit breaks the seamless
cutting use case.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

Nicolas Dufresne (stormer) <***@ndufresne.ca> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #345896|none |rejected
status| |

--- Comment #26 from Nicolas Dufresne (stormer) <***@ndufresne.ca> ---
Review of attachment 345896:
--> (https://bugzilla.gnome.org/review?bug=778690&attachment=345896)

Please !! don't panic !!, I am just marking this patch, which purpose if for
testing, so we don't confuse it with patches to be reviewed and merged. Though,
if you feel like fixing this regression, this is the right way to submit patch.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

Jean-François Fortin Tam <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #27 from Jean-François Fortin Tam <***@gmail.com> ---
Christophe, you posted EIGHTEEN comments within the span of a day, some of them
offensive. Developers have a life too. This is not a chat room, and you're not
paying them on a support contract to answer your issues within the hour. What
you're doing here is *harassment*. Stop that and be respectful in the future,
or I'm pretty sure you will get banned. Premier et dernier avertissement.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #28 from christophe vr <***@telenet.be> ---
(In reply to Jean-François Fortin Tam from comment #27)

Post by "GStreamer" (GNOME Bugzilla)
Christophe, you posted EIGHTEEN comments within the span of a day, some of
them offensive. Developers have a life too. This is not a chat room, and
you're not paying them on a support contract to answer your issues within
the hour. What you're doing here is *harassment*. Stop that and be
respectful in the future, or I'm pretty sure you will get banned. Premier et
dernier avertissement.

Ok I did go to far on some points, but only 5 of the messages (this even does
not approach you're 18) are of the type which could be considered as spam. And
yes I do present my a apologies for it more I can't, I was wrong impatient and
unfortunately was so occupied with this issue that I could not sleep and posted
this after having spend over 48 hours non stop behind a keyboard.

I'll anyway will watch out to not post anything when I'm to tired.

But for the rest this bug report is a more then standard issue, it is really a
severe one.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #29 from christophe vr <***@telenet.be> ---
(In reply to Jan Schmidt from comment #25)

Post by "GStreamer" (GNOME Bugzilla)
commit 488e8edba4527d7e8da9b45a42ffd3927f7ac449
Date: Fri Feb 17 13:07:05 2017 +1100
Revert "qtdemux: Always snap to the start of the keyframe"
This reverts commit 107902ec514bd826aa29d2298107e2c091e1c779.
This commit intended to ensure that keyframe seeks land at the
start timestamp of a keyframe, rather than in the middle of one,
but they cause trouble on files with sparse streams, or with
JPEG 'cover art' tracks that have only one or a few JPEG samples
with very long durations.
That's still desirable for doing seamless cutting of videos,
but needs a rethink for implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=778690
Leaving the bug open, because just reverting that commit breaks the seamless
cutting use case.

I've investigated further, indeed it is not easy to solve here.
But Yes if a media sample does have a image/ codec track that image codec track
is like it told and in some cases is one single image one buffer and yes does
only have one key-unit holder which covers so what the whole media length.

Perhaps limit the keyframe seek only to the real audio:video tracks could
solve.
The audio/video needs somehow to be threaded together (at last the active ones)
think about for example dts audio does have two key frames for one video key
frame (or perhaps the opposed).

Also think it's best to exclude the subtitles complete from this key-unit seek,
there as well we do have key units which may differ from the one by video or
audio. It is even possible to have a pts on a srt sub which needs algnement on
frame 2 off the three frames some h264 may contain. for one pts. But well do a
kind of async seek on the subtitle which after all is an overlay.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

GStreamer system administrator <***@gstreamer.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |OBSOLETE

--- Comment #30 from GStreamer system administrator <***@gstreamer.net> ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/347.