GNOME Bugzilla – Bug 732351
Bogus bottom line when decoding using xvimagesink
Last modified: 2018-11-03 12:56:24 UTC
When playing a video file, sometimes the bottom line of the video shows bogus data. It depends on the resolution being used and it only happens with xvimagesink. To reproduce: 1) Create a 16x16 h264 file: gst-launch-1.0 videotestsrc pattern=white num-buffers=1000 ! \ "video/x-raw, format=(string)I420, width=(int)16, height=(int)16, \ framerate=(fraction)1/1" ! x264enc ! qtmux ! filesink location=/tmp/test.mov 2) Play this file: gst-launch-1.0 playbin uri="file:///tmp/test.ogg" video-sink=xvimagesink 3) Check the bottom line (This scenario also shows the right column with bogus data Details I found out so far about this: If I manually disable direct rendering in libav gstviddec it doesn't happen. It doesn't happen with 480x320 resolution (and some others). I'm marking this as being in gst-libav for now but I'm not sure, could be in libav itself and I also saw it happening with theoradec but with different resolutions.
It seems to be a x264enc thing: gst-launch-1.0 videotestsrc pattern=6 ! "video/x-raw, format=(string)I420, width=(int)16, height=(int)16,framerate=(fraction)1/1" ! x264enc ! avdec_h264 ! xvimagesink I see a grey square with colored right/bottom lines. Without the enc/dec, I see a filled blue square. With gst-launch-1.0 videotestsrc pattern=6 num-buffers=1000 ! "video/x-raw, format=(string)I420, width=(int)16, height=(int)16,framerate=(fraction)1/1" ! x264enc ! qtmux ! filesink location=/tmp/test-16x16.mov the file plays back as grey with both ffplay and gst (pattern=6 is solid blue). Not sure why this does not happen with ximagesink, however. It is unlikely to be different clipping since it's 16x16.
In fact, two issues, I think. If I use the snow pattern to make sure frames change, and use 18x18, I get frames, but with a hue coloration on the right and bottom frames. So one bug of hue leaking on the edges, and one bug of frames being missing.
Commenting out a safety check early out in gst-libav fixes the missing frames: gst-libs/ext/libav/libavcodec/mpegvideo_enc.c if(s->pb.buf_end - s->pb.buf - (put_bits_count(&s->pb)>>3) < MAX_MB_BYTES){ av_log(s->avctx, AV_LOG_ERROR, "encoded frame too large\n"); //return -1; } So this means this really is a second issue, in fact unrelated to this bug, apart from the fact that it is triggered by the same test case. I'll open another bug for this one then.
Last time I investigated this I could not see anything wrong with the decoded image (from looking at the bytes in hexdump) so I think I concluded it was a problem with how xvimagesink scales the image.
Having had another look at this, this happens only for I420. The only code that is format dependent runs the same code for I420 and YV12, and the latter looks fine. Additionally, trying to memset the planes to 0x80, including the dead space, does not change anything. AFAICT this happens also without scaling. Playing the file with mplayer -vo xv shows the expected image (though I'm not sure if it uses I420 or not).
-- 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-libav/issues/13.