search

mypopydev / FFmpeg

mirror of git://source.ffmpeg.org/ffmpeg.git
http://ffmpeg.org
Other
2 stars 1 forks source link

[ffmpeg-vaapi][h264 decode]fate-h264-lossless test cases failed When Using ffmpeg-vaapi #4

Open sungn opened 6 years ago

sungn commented 6 years ago

command

./ffmpeg -nostdin -nostats -cpuflags all -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -hwaccel_flags allow_profile_mismatch -threads 1 -thread_type frame+slice -i ./fate-suite//h264/lossless.h264 -pix_fmt yuv420p -flags +bitexact -fflags +bitexact -f framecrc -

backtrace

--- ./tests/ref/fate/h264-lossless 2018-06-07 14:32:26.688501113 +0800 +++ tests/data/fate/h264-lossless 2018-07-10 16:39:20.176783101 +0800 @@ -3,13 +3,13 @@

codec_id 0: rawvideo

dimensions 0: 640x480

sar 0: 0/1

-0, 0, 0, 1, 460800, 0x7731dd2f -0, 2, 2, 1, 460800, 0x944b8c64 -0, 3, 3, 1, 460800, 0xbe833041 -0, 4, 4, 1, 460800, 0xbe95d96a -0, 5, 5, 1, 460800, 0xfe7ea5e6 -0, 6, 6, 1, 460800, 0x381743c7 -0, 7, 7, 1, 460800, 0x63fcc2e9 -0, 8, 8, 1, 460800, 0x79574960 -0, 9, 9, 1, 460800, 0xdab9e18a -0, 10, 10, 1, 460800, 0xd88e8fe8 +0, 0, 0, 1, 460800, 0x4b65b7ac +0, 2, 2, 1, 460800, 0xf257dc01 +0, 3, 3, 1, 460800, 0x48767109 +0, 4, 4, 1, 460800, 0xc5db95ec +0, 5, 5, 1, 460800, 0x011141c5 +0, 6, 6, 1, 460800, 0x3b79ba35 +0, 7, 7, 1, 460800, 0xe87b24ec +0, 8, 8, 1, 460800, 0xad8fbdb1 +0, 9, 9, 1, 460800, 0x80a258a6 +0, 10, 10, 1, 460800, 0x03528f17 Test h264-lossless failed. Look at tests/data/fate/h264-lossless.err for details. ffmpeg version N-91236-ge4006a474f Copyright (c) 2000-2018 the FFmpeg developers built with gcc 7 (Ubuntu 7.2.0-8ubuntu3.2) configuration: --enable-libx264 --enable-gpl --enable-libx265 --disable-doc --disable-stripping --disable-optimizations --enable-libvpx --samples=fate-suite libavutil 56. 18.102 / 56. 18.102 libavcodec 58. 19.105 / 58. 19.105 libavformat 58. 17.100 / 58. 17.100 libavdevice 58. 4.100 / 58. 4.100 libavfilter 7. 25.100 / 7. 25.100 libswscale 5. 2.100 / 5. 2.100 libswresample 3. 2.100 / 3. 2.100 libpostproc 55. 2.100 / 55. 2.100 Input #0, h264, from '/home/intel/sungn/0607/FFmpeg/fate-suite//h264/lossless.h264': Duration: N/A, bitrate: N/A Stream #0:0: Video: h264 (High 4:4:4 Predictive), yuv420p(progressive), 640x480, 60 fps, 60 tbr, 1200k tbn, 120 tbc Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> rawvideo (native)) [h264 @ 0x55ea1209db40] Using possibly-incompatible profile 100 instead. Last message repeated 1 times Output #0, framecrc, to 'pipe:': Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 640x480, q=2-31, 221184 kb/s, 60 fps, 60 tbn, 60 tbc Metadata: encoder : Lavc rawvideo frame= 10 fps=0.0 q=-0.0 Lsize= 1kB time=00:00:00.18 bitrate= 29.6kbits/s speed=3.74x
video:4500kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown tests/Makefile:225: recipe for target 'fate-h264-lossless' failed make: *** [fate-h264-lossless] Error 1

sungn commented 6 years ago

rootcause：The frame_crc_write_packet function in the framecrcenc.c file has a problem with the calculation of the value of crc.

The reason for the problem is that when hw is decoded, data acquisition is required through the syncsurface operation. At present, the data data[0] after surface synchronization is still empty.

sungn commented 6 years ago

See the following information from the tag of the code (from the description of the VAImage structure in the va.h file)

Image data will be stored in a buffer of type VAImageBufferType. The buffer will be Created by the DdiMedia_CreateImage function. This buffer is managed by the library implementation, and accessed by the client through the buffer DdiMedia_MapBuffer/DdiMedia_UnmapBuffer functions.

Found the problem as follows

1: There is a problem that the DdiMedia_GetBufferFromVABufferID function is called multiple times in DdiMedia_GetImage, and it is determined that there is logical redundancy and needs to be corrected. 2: Through gdb debugging, when the data is acquired through DdiMedia_MapBuffer, the pData field data of the buffer is empty. Since the management of the buffer is implemented by the lib library, there is no way to understand its implementation, so the problem cannot be tracked. PS: Use the passed test case to verify that the pData field of the buffer obtained by DdiMedia_MapBuffer is not empty. (Command expansion: ./ffmpeg -nostdin -nostats -cpuflags all -vsync drop -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -hwaccel_flags allow_profile_mismatch -threads 1 -thread_type frame+slice -i ./fate-suite/h264-conformance /AUD_MW_E.264 -pix_fmt yuv420p -flags +bitexact -fflags +bitexact -f framecrc)