GNOME Bugzilla – Bug 745251
glvideomixer: corrupt video frames
Last modified: 2015-04-22 00:18:26 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).
There was a typo, I mean tested with master repos from 26/2/2015
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
Created attachment 298068 [details] screenshot of messed output Output window from given gst-launch pipeline
That's will all video size, or specific video sizes ?
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
Tested with this video for example: http://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_480p_stereo.avi
I can indeed reproduce here.
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.
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.
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. https://bugzilla.gnome.org/show_bug.cgi?id=719684 https://bugzilla.gnome.org/show_bug.cgi?id=720597 (unresolved) There is likely still a glvideomixer or videodecoder/glvideomixer bug here - the (possibly redundant) renegotiation doesn't break other elements.
Might also be related to bug #745730
The fix for bug #745705 did not solve this btw. It looks like a stride issue to me.
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.
Hello, I have successfuly replicated this issue on commit 4521524... However in the latest HEAD the bug is not present.
Thanks for testing. This was fixed by the changes in bug #743974