GNOME Bugzilla – Bug 689566
xvimagesink causes image distortion while resizing.
Last modified: 2013-10-07 12:41:07 UTC
I suspect this bug is related to #689563, and might actually be the same. I'm working on a video-wall application, so I am cropping videos and showing each piece on a separate 1920x1080 monitor. Note that I'm running raw X sessions on these monitors -- no window manager. That seems to matter as xvimagesink doesn't display this bug if I use display=:0 (my main desktop display). I am guessing its because of the particulars of the resize operation. This is with the lastest version of GStreamer, built from git this morning. The failing command is: gst-launch-1.0 filesrc location=~/Videos/perform-this-way-5-secs.flv ! decodebin ! videobox right=443 top=253 bottom=-4 ! xvimagesink display=:2 The video, a 5-second clip of Weird Al's "Perform This Way" video can be downloaded from here: https://docs.google.com/open?id=0BwCOnjTaGreON1RvU1FGU3NhaGs Because I imagine this bug may be difficult to reproduce, I've captured a debug-log of the crash with GST_DEBUG=*:6. You can grab it here: https://docs.google.com/open?id=0BwCOnjTaGreOcWlEZEE2OUwyVUE
Sorry, wrong clip. This one is 'perform-this-way' https://docs.google.com/open?id=0BwCOnjTaGreORGVscmF1WEVlTW8
Do you happen to have a stack trace with full debugging symbols as well by any chance?
Sorry, wrong bug. No crash here.
Does this still happen with latest git master? There were some related changes in the last months
(In reply to comment #4) > Does this still happen with latest git master? There were some related changes > in the last months I recently had to reformat my server, so its taking me a few days to rebuild my dev system to the point at which I can check to see if the bug is fixed. I'll let you know as soon as I can
Sorry for the delay. In any case, I just retried the above command using the latest version of gstreamer from git, and I still get the exact same problem: color distortion and green diagonal lines on top of the video.
Olivier confirmed this bug in https://bugzilla.gnome.org/show_bug.cgi?id=689563#add_comment
Nevermind, he *can't* reproduce it.
Do you also get these distortions when not using videobox? The resizing of the xvimagesink window content otoh is completely handled inside the XV driver, GStreamer does not even notice anything of that. So I'm guessing that your driver has some problems here... which one is it?
(In reply to comment #9) > Do you also get these distortions when not using videobox? No, the only way I've every found to produce these distortions is to ask videobox to add a border to a video with an strange height or width. > The resizing of the xvimagesink window content otoh is completely handled > inside the XV driver, GStreamer does not even notice anything of that. So I'm > guessing that your driver has some problems here... which one is it? As for driver, I'm using the commercial version of the SMSC Zero Client Driver for Linux (which I happen to be the maintainer for). I'm not going to say it COULDN'T be our driver, but I think its far more likely that its a data path through videobox that our driver exercises that yours didn't. Possibly as a result of different negotiated output encoding. I'm going to see if I can figure out what the negotiated output is, and try to capture some frames to display in other ways. That will tell us if the frames are already distorted before going into our driver or not.
(In reply to comment #10) > (In reply to comment #9) > > As for driver, I'm using the commercial version of the SMSC Zero Client Driver > for Linux (which I happen to be the maintainer for). > > I'm not going to say it COULDN'T be our driver, but I think its far more likely > that its a data path through videobox that our driver exercises that yours > didn't. Possibly as a result of different negotiated output encoding. > > I'm going to see if I can figure out what the negotiated output is, and try to > capture some frames to display in other ways. That will tell us if the frames > are already distorted before going into our driver or not. Okay, the tests seem to implicate our driver. I've been able to get the distortion by simply scaling the video to a strange size before putting it into our driver, and without involving videobox at all. I guess you guys should claim its an upstream bug, and I'll put it into our own bugzilla for me to fix. Sorry for the waste of your time.