This problem also blocked QA's automation of jpeg decoding testing. Env: ------------------- Libva:(master)88ed1ebe960b1c4a7970e12f8df1ed7d7031352a Libva_intel_driver:(master)121e70d34028c5caa24b587988dda4b6b1335bf8 Gst_plugins_vaapi:(master)61f6cbffc657fbe0287301018e365cd85607565c Cmd: ------------------- export LD_PRELOAD=/root/media_tools/decoder/i965_drv_video_hook_op.so gst-launch-1.0 filesrc location=/root/media_tools/encoder/encoderbitstreams/SOCCER_704x576_30_orig_02.yuv ! videoparse format=i420 width=704 height=576 ! jpegenc ! vaapidecode ! vaapisink Log: ------------------- libva info: VA-API version 0.34.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /opt/X11R7/lib/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_34 libva info: va_openDriver() returns 0 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... frame_count = 1 used size = 608256 srcx = 0 srcy = 0 srcw = 704 srch = 576 destx = 0 desty = 0 destw = 704 desth = 576 i965_drv_video_hook_op.c, vaPutSurface, 70vaDeriveImage error gst-launch-1.0: i965_drv_video.c:1760: i965_MapBuffer: Assertion `obj_buffer && obj_buffer->buffer_store' failed. Aborted (core dumped)
Hi Zhenxiang: Fixing patch has been pushed to libva-intel-driver staging branch(on freedesktop. commit:9f9c505ed5212ae0704f71f45532b9716ac0bd51). Can you help to test it using lastest driver? Thanks Zhong
I tried with the latest commit, and got the following result: MOBILE_352x288_30_orig_01.yuv 0.999048 0.999238 0.482528 0.489278 0.482209 0.489039 301 301 0 command line: 1. + LD_PRELOAD=/root/media_tools/decoder/i965_drv_video_hook_op.so + gst-launch-1.0 filesrc location=/root/media_tools/encoder/encoderbitstreams/MOBILE_352x288_30_orig_01.yuv '!' videoparse format=i420 width=352 height=288 '!' jpegenc '!' jpegdec '!' vaapisink mv dump.yuv 1.yuv 2. + LD_PRELOAD=/root/media_tools/decoder/i965_drv_video_hook_op.so + gst-launch-1.0 filesrc location=/root/media_tools/encoder/encoderbitstreams/MOBILE_352x288_30_orig_01.yuv '!' videoparse format=i420 width=352 height=288 '!' jpegenc '!' vaapidecode '!' vaapisink mv dump.yuv 2.yuv 3. /root/media_tools/decoder/ssim_op 352 288 301 0 0 1.yuv 2.yuv Besides: If using filesink location=1.yuv instead, then the process caught SIGSEGV: Caught SIGSEGV accessing address 0x7f961c02b460 #0 0x00000033e02ea8fd in poll () from /lib64/libc.so.6 #1 0x00007f9634bc5086 in g_main_context_poll (n_fds=2, fds=0x2363540, #2 g_main_context_iterate (dispatch=1, block=<optimized out>, #3 g_main_context_iterate (context=0x2363300, block=<optimized out>, #4 0x00007f9634bc5415 in g_main_loop_run (loop=0x23215b0) at gmain.c:3928 #5 0x00007f9635563655 in gst_bus_poll (bus=bus@entry=0x23208d0, #6 0x0000000000403cb7 in event_loop (pipeline=0x23302d0, #7 0x0000000000403541 in main (argc=15, argv=0x7ffffdb5fcf8) (gdb) bt #0 0x00000033e0289c5b in __mempcpy_sse2 () from /lib64/libc.so.6 #1 0x00000033e0279249 in __GI__IO_default_xsputn () from /lib64/libc.so.6 #2 0x00000033e0277272 in __GI__IO_file_xsputn () from /lib64/libc.so.6 #3 0x00000033e026cc8d in fwrite () from /lib64/libc.so.6 #4 0x00007ffff0bfca96 in gst_file_sink_render (sink=0x7337e0, buffer=0x7fffe8004e70) at gstfilesink.c:654 #5 0x00007ffff09c19bb in gst_base_sink_chain_unlocked (basesink=basesink@entry=0x7337e0, pad=<optimized out>, obj=obj@entry=0x7fffe8004e70, is_list=0) at gstbasesink.c:3245 #6 0x00007ffff09c2f24 in gst_base_sink_chain_main (basesink=0x7337e0, pad=<optimized out>, obj=0x7fffe8004e70, is_list=<optimized out>) at gstbasesink.c:3353 #7 0x00007ffff7d66859 in gst_pad_chain_data_unchecked (data=0x7fffe8004e70, type=4112, pad=0x71b030) at gstpad.c:3655 #8 gst_pad_push_data (pad=0x71ae00, type=type@entry=4112, data=<optimized out>, data@entry=0x7fffe8004e70) at gstpad.c:3872 #9 0x00007ffff7d6cab6 in gst_pad_push (pad=<optimized out>, buffer=buffer@entry=0x7fffe8004e70) at gstpad.c:3975 #10 0x00007ffff0571fb9 in gst_video_decoder_clip_and_push_buf (decoder=decoder@entry=0x72e9b0, buf=buf@entry=0x7fffe8004e70) at gstvideodecoder.c:2519 #11 0x00007ffff0577adb in gst_video_decoder_finish_frame (decoder=decoder@entry=0x72e9b0, frame=0x0, frame@entry=0x7fffe00059d0) at gstvideodecoder.c:2434 #12 0x00007fffefcbfcff in gst_vaapidecode_push_decoded_frame (out_frame=0x7fffe00059d0, vdec=0x72e9b0) at gstvaapidecode.c:340 #13 gst_vaapidecode_decode_loop (decode=0x72e9b0) at gstvaapidecode.c:405 #14 0x00007ffff7d93bdf in gst_task_func (task=0x7505f0) at gsttask.c:316 #15 0x00007ffff73c8398 in g_thread_pool_thread_proxy (data=<optimized out>) at gthreadpool.c:307 #16 0x00007ffff73c7b35 in g_thread_proxy (data=0x7fffe80020a0) at gthread.c:764 #17 0x00000033e0a07c53 in start_thread () from /lib64/libpthread.so.0 #18 0x00000033e02f4ecd in clone () from /lib64/libc.so.6
Hi Zhengxiang: Two results depend on your information： 1. uv ssim value too low Could you check derive image format? I guess they are different format. 2.SIGSEGV error when filesink I think it is gst-vaapi issue. Zhong
QA will modify the hook.c to assure the jpeg format video can be dumped correctly.
According to my debug, I think the low uv ssim value should be derive image dump error. Diffrent from h264/vc1/mpeg2/vp8, image format is not always nv12, please note it.
after modify hook.c file, the video file can be dumped correctly. so closed it. fill another bug(https://bugzilla.gnome.org/show_bug.cgi?id=729802) to track the SIGSEGV error.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.