GNOME Bugzilla – Bug 684991
videobox: sometimes incorrectly crops producing visual artifacts, and green instead of black border
Last modified: 2012-12-03 19:24:29 UTC
I was unable to capture a screenshot, but the following gst-launch invocation consistently produces a video where the top (black) border quickly fills with color, a region the same height as the top border and directly below it becomes stripey, and the entire video color scheme goes off. gst-launch-1.0 filesrc location=~/Videos/TimeScapes4K2560p.mp4 ! decodebin ! videobox top=-110 bottom=901 right=961 left=961 ! xvimagesink The video in question is a freely available QuadHD teaser video, which may, or may not, have something to do with the cause of the bug. It can be downloaded here: http://red.cachefly.net/TimeScapes4K2560p.mp4
This works fine for me now after fixing the border fill colour. There have been some other commits since you filed this bug, which have probably taken care of the other issue (which sounds stride-related): commit efaa80fbc6700e2f02cbac3a5f8b66e24cdab934 Author: Tim-Philipp Müller <tim@centricular.net> Date: Sat Nov 24 19:32:51 2012 +0000 videobox: fix border filling for planar YUV formats We would get a green border instead of a black one, for example. https://bugzilla.gnome.org/show_bug.cgi?id=684991 commit 3ef7c8ab93fade5ab5a0410d6ab3ec580f3e3656 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Wed Oct 17 09:36:50 2012 +0200 videobox: use out_info for out properties commit 63716151ef873cb992718c409a327fcf50705683 Author: Michael Smith <msmith@rdio.com> Date: Tue Sep 18 10:34:03 2012 -0700 videobox: Fix U/V strides for a number of cases.
Testing videobox with GStreamer 1.0.2, I do see major improvements, but there are still use cases I have that show strange cropping artifacts. One example I just ran across is this: gst-launch-1.0 filesrc location=~/Videos/BigBuckBunny1080p.avi ! decodebin ! videobox top=0 bottom=540 right=959 left=-2 ! xvimagesink This produces a color-distorted image with diagonal stripes of bright color across the image. My debug dump shows that I420 is the image format being cropped. Here is an ffprobe of my copy of BigBuckBunny, in case that is useful: Input #0, avi, from '~/Videos/BigBuckBunny1080p.avi': Metadata: encoder : AVI-Mux GUI 1.17.7, Aug 8 2006 20:59:17 JUNK : Duration: 00:09:56.45, start: 0.000000, bitrate: 12455 kb/s Stream #0:0: Video: mpeg4 (Simple Profile) (FMP4 / 0x34504D46), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 24 tbr, 24 tbn, 24 tbc Stream #0:1: Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, 5.1(side), s16, 448 kb/s Big Buck Bunny can be freely downloaded here, if you don't already have a copy. http://www.bigbuckbunny.org/index.php/download/
... and now I found a use case that actually crashes videobox with a segmentation fault: Same video, cropping Left:27, Right:995, Top:575, Bottom:0
I should add that my commit not only fixed the colour, but also possibly invalid memory access (memset for u/v planes was done with double the number of bytes and might hence write beyond the end of the allocate image).
I have re-tested that bigbuckbunny clip with the pipeline and configurations you mentioned, and it works fine for me now. It's also valgrind-clean, so I think the issues you were seeing were caused by the invalid memory access that I fixed. Closing again. Please re-open if you still have problems with git master or 1.0.4, once it's out. (It is possible to build the GStreamer stack in an uninstalled setup for testing purposes, for what it's worth).
I built the latest GStreamer from Git over the weekend and ran some tests, and was still able to get video corruption, green borders, and even crashes with videobox. I'll try to comment with some specific examples today.
Hrm, ok. Maybe you could provide some valgrind logs (with G_SLICE=always-malloc)?
I spent the morning building the lastest GStreamer from git and narrowing down the parameters which caused video corruption and/or segfaults. To my surprise, it turned out it WASN'T videocrop or videobox that were the culprits, but xvimagesink. It seems that when it decides to rescale a video to a window, sometimes it fails spectacularly. So, you can close this bug, and I will go and post a bug against xvimagesink.
Cool, thanks.