After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 765713 - compositor: Crashes on Windows with ORC when doing pixel-aspect-ratio conversion
compositor: Crashes on Windows with ORC when doing pixel-aspect-ratio conversion
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: orc
git master
Other Windows
: Normal critical
: 1.9.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-04-28 09:56 UTC by Sebastian Dröge (slomo)
Modified: 2016-10-31 14:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Sebastian Dröge (slomo) 2016-04-28 09:56:36 UTC 
gst-launch-1.0 videotestsrc ! "video/x-raw,width=720,height=576,pixel-aspect-ratio=59/54" ! compositor ! "video/x-raw,width=786,height=576,pixel-aspect-ratio=1/1" ! fakesink

Works fine with videoscale, fails with compositor. Works with ORC_CODE=backup. Works on Linux on the exactly same machine.

Orc 0.4.25 - integrated testing tool
Active backend: sse
L1 cache: 32768
L2 cache: 262144
L3 cache: 8388608
Family/Model/Stepping: 6/60/3
CPU name: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
Compiler options: sse2 sse3 ssse3 sse41 sse42 64bit
Opcode test:
No errors detected.


(gdb) bt

+ Trace 236213

  • #0 ??
  • #1 ??
  • #2 ??
  • #3 ??
  • #4 video_orc_resample_h_multaps3_u8_lq
    at tmp-orc.c line 23672
  • #5 video_scale_h_ntap_u8
    at video-scaler.c line 696
  • #6 _fu150__gst_debug_min
    at video-scaler.c line 1475
  • #7 convert_plane_hv
    at video-converter.c line 3915
  • #8 convert_scale_planes
    at video-converter.c line 3929
  • #9 _fu48__gst_debug_min
    at compositor.c line 562
  • #10 _fu149__gst_debug_min
    at gstaggregator.c line 380
  • #11 gst_videoaggregator_do_aggregate
    at gstvideoaggregator.c line 1321
  • #12 _fu81__gst_debug_min
    at gstvideoaggregator.c line 1527
  • #13 _fu172__gst_debug_min
    at gstaggregator.c line 816
  • #14 gst_task_func
    at gsttask.c line 332
  • #15 g_thread_pool_thread_proxy
    at gthreadpool.c line 307
  • #16 g_thread_proxy
    at gthread.c line 778
  • #17 g_thread_win32_proxy
    at gthread-win32.c line 450
  • #18 msvcrt!_beginthreadex
    from C:\Windows\system32\msvcrt.dll
  • #19 ??
  • #20 ?? 






Comment 1


Sebastian Dröge (slomo)





          2016-08-24 16:19:01 UTC
        



commit bec7ebea1935c112f5b4b30fc3c47626ac99c940
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Wed Aug 24 19:11:18 2016 +0300

    orcx86: Fix generation of ModR/M / SIB bytes for the EBP, R12, R13 registers
    
    See http://wiki.osdev.org/X86-64_Instruction_Encoding#ModR.2FM
    
    ESP and R12 are to be handled exactly the same, that is the addressing is
    done with SIB instead of directly.
    
    EBP and R13 have a special case for Mod 00, where they're expecting RIP/EIP
    plus 32 bit displacement. If we handle them like all other registers, we would
    instead of addressing offset 0, address something relative to the instruction
    pointer and make part of the following instruction the 32 bit displacement.
    
    Instead of using Mod 00 for offset 0 like for all other registers, we use Mod
    01 and a 8 bit displacement of 0.
    
    On Windows this rather low-level bug caused problems at a rather
    high-level in the ORC video conversion code, where a movdqu was eating the
    following paddw instruction and tried to load data from a rather random memory
    location.
    
    For whatever reason this didn't cause any other big problems in other ORC
    generated code, and it also only seemed to have caused problems on Windows.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=765713