After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 745251 - glvideomixer: corrupt video frames
glvideomixer: corrupt video frames
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-02-26 20:07 UTC by Vasilis Liaskovitis
Modified: 2015-04-22 00:18 UTC
See Also:
GNOME target: ---
GNOME version: ---

screenshot of messed output (136.56 KB, image/png)
2015-02-27 09:36 UTC, Topolsky
test app (19.34 KB, text/x-csrc)
2015-03-02 02:15 UTC, Vasilis Liaskovitis
videodecoder test: ignore reconfigure (1.17 KB, patch)
2015-03-03 00:21 UTC, Vasilis Liaskovitis
none Details | Review

Description Vasilis Liaskovitis 2015-02-26 20:07:25 UTC
gst-launch-1.0 playbin uri=file:///opt/Videos/test.avi video-stream-combiner=glvideomixer

Result: Output video frames are corrupt (green lines across video)

This does not happen with default video-stream-combiner or with other video-stream-combiner element (e.g. compositor works fine). It also does not depend on video-sink (happens with glimagesink, xvimagesink or default sink picked by playbin)

Tested with master from 26/5/2015

This behaviour is also reproducible with an application prototype (not shared here because it's long, but maybe i could reduce it to a smaller test case if needed). The application seamlessly plays video files, dynamically connecting the next files's uridecodebin/queue pipeline to glvideomixer, when the prefious file/pipeline has finished. In the application the corrupt frames are observed afer the fist switch (so first file plays correctly, and only after switching to 2nd file do we get the corrupt frames).
Comment 1 Vasilis Liaskovitis 2015-02-27 09:34:21 UTC
There was a typo, I mean tested with master repos from 26/2/2015
Comment 2 Topolsky 2015-02-27 09:35:15 UTC
Same behaviour for me with playbin and glvideomixer and different file (mp4).
I will attach screenshot of corrupted output.

Tested with git master from 24/2/2015
Comment 3 Topolsky 2015-02-27 09:36:29 UTC
Created attachment 298068 [details]
screenshot of messed output

Output window from given gst-launch pipeline
Comment 4 Nicolas Dufresne (ndufresne) 2015-02-27 13:28:49 UTC
That's will all video size, or specific video sizes ?
Comment 5 Topolsky 2015-02-27 13:36:22 UTC
I tested with these videos:

Video: h264 (High), yuv420p, 1280x720, 2363 kb/s, 25 fps, 25 tbr, 50 tbn, 50 tbc

Video: h264 (Constrained Baseline), yuv420p, 480x360, 262 kb/s, 29.97 fps, 29.97 tbr, 60k tbn, 59.94 tbc

Video: h264 (Constrained Baseline), yuv420p, 640x360 [PAR 1:1 DAR 16:9], 350 kb/s, 25 fps, 25 tbr, 25 tbn, 50 tbc
Comment 6 Topolsky 2015-02-27 13:46:02 UTC
Tested with this video for example:
Comment 7 Nicolas Dufresne (ndufresne) 2015-02-27 14:02:59 UTC
I can indeed reproduce here.
Comment 8 Matthew Waters (ystreet00) 2015-02-28 01:50:01 UTC
I can't reproduce outside playbin which leads me to believe its something weird in the memory configuration between glvideomixer and avdec and the way video-stream-combiner works.
Comment 9 Vasilis Liaskovitis 2015-03-02 02:15:50 UTC
Created attachment 298244 [details]
test app

I am attaching a C test app (originally provided by Centricular, here considerably narrowed down for video only) that also exhibits the problem. The app plays video files back to back, connecting a per-file uridecodebin pipeline into glvideomixer:

./playout file1 file2
(or ./playout -s 2000 file1 file2 to force switching to file2 after 2000msecs of file1 playback)

The corrupt frames only happen when switching to the second file. When the switch happens, gst_video_decoder_allocate_output_frame() sends an allocation query to glvideomixer, and gst_gl_mixer_propose_allocation() is called, creating a bufferpool.  

- should an allocation query be sent to glvideomixer from avdec? This query is not sent for the first file. This allocation query is also sent in the playbin pipeline from the initial problem description, but I believe it is not sent from e.g. a "gst-launch-1.0 uridecodebin ! glvideomixer ! xvimagesink" pipeline.

- can there be a race between GLUpload's call to _upload_find_method() and the call to gst_gl_mixer_propose_allocation()/ gst_gl_buffer_pool_new()? In some cases (e.g. several runs where the app uses a glimagesink instead of an xvimagesink) the propose_allocation has already been called before upload_find_method(), and the frames look ok. When the corrupt frames appear, the bufferpool/allocation proposal happens always after _upload_find_method() is called.

Sorry if these are not helpful, i am only getting familiar with the code. I hope something provides a hint. I can also provide logs/backtraces from the above app or from playbin/gst-launch-1.0 runs.
Comment 10 Vasilis Liaskovitis 2015-03-03 00:21:28 UTC
Created attachment 298356 [details] [review]
videodecoder test: ignore reconfigure

If the videodecoder ignores the reconfigure flag in gst_video_decoder_output_frame, all tests work fine, i.e. no corrupt frames.

Not sure if this is a superfluous reconfigure event. There are some older tickets about clearing reconfigure flag if negotiate succeeds in order not to send allocation queries twice. (unresolved)

There is likely still a glvideomixer or videodecoder/glvideomixer bug here - the (possibly redundant) renegotiation doesn't break other elements.
Comment 11 Sebastian Dröge (slomo) 2015-03-06 13:49:21 UTC
Might also be related to bug #745730
Comment 12 Sebastian Dröge (slomo) 2015-03-07 09:41:23 UTC
The fix for bug #745705 did not solve this btw. It looks like a stride issue to me.
Comment 13 Nicolas Dufresne (ndufresne) 2015-03-07 19:46:38 UTC
I confirm it didn't fix that particular issue. If I build the pipeline staticly instead of inside playbin, I can't produce.

Note that I have added a thread safety fixme that I notice. This may or may not be related. I think next step will be to track in which order things get configured.
Comment 14 Rene Kolarik 2015-04-21 20:59:34 UTC
Hello, I have successfuly replicated this issue on commit 4521524... However in the latest HEAD the bug is not present.
Comment 15 Matthew Waters (ystreet00) 2015-04-22 00:18:26 UTC
Thanks for testing.

This was fixed by the changes in bug #743974