GNOME Bugzilla – Bug 648548
videoscale broken with orc 0.4.13
Last modified: 2011-04-25 01:23:58 UTC
An orc bug most likely: gst-launch-0.10 videotestsrc ! video/x-raw-yuv,width=639,height=431 ! ffmpegcolorspace ! videoscale ! ximagesink Resizing ximagesink leads to images that have very little to do with the input image: sometimes it's basically all white with two horizontal blue bars of different darkness at the bottom, and a single scanline at the very top that looks like the videotest image. The vertical size seems to make all the difference, not the horizontal size. Depending on the vertical size it basically gives the original image with white lines in the middle, and how much white lines there are varies. $ orc-bugreport Orc 0.4.13 - integrated testing tool Active backend: sse L1 cache: 32768 L2 cache: 3145728 L3 cache: 0 Family/Model/Stepping: 6/23/6 CPU name: Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz Compiler options: sse2 sse3 ssse3 sse41 64bit Opcode test: No errors detected.
I assume that 'orc-bugreport gstvideoscaleorc.orc' passes? Do you get the same result with ORC_CODE=-sse41 ? (And also, what magic fix do you have that allows '... videoscale ! ximagesink' to handle resizing again?)
> I assume that 'orc-bugreport gstvideoscaleorc.orc' passes? Yes. > Do you get the same result with ORC_CODE=-sse41 ? Yes. > (And also, what magic fix do you have that allows '... videoscale ! ximagesink' > to handle resizing again?) This is with clean git of all modules. Why wouldn't this let videoscale handle resizing?
commit 7c0b702e14f81b68dd341109af9efcbd714dbf32 Author: David Schleef <ds@schleef.org> Date: Sun Apr 24 18:16:20 2011 -0700 videoscale: Fix ARGB bilinear scaling Fixes #648548. Orc generates bad code for gst_videoscale_orc_resample_merge_bilinear_u32, so we'll use the slightly slower two-stage process. I'd fix Orc, but it's hard to get excited about fixing a feature that I'm planning to deprecate and replace.