Opened 6 years ago
Last modified 6 years ago
#7404 new defect
[ffmpeg-qsv][vc1_decode]some frames error in dump file on iHD driver.
Reported by: | a | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | undetermined |
Version: | unspecified | Keywords: | qsv vc1 |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Summary of the bug:
ffmpeg qsv vc1 decode, use 7yuv open dump.yuv , some frames are full of green, the other frames are normal.
environment
SKL OS: ubuntu 16.04 kernel: 4.15.0 libva b6c50dad4d7d14c507108d9f468662e2d7ae1c4d https://github.com/01org/libva.git VPG_Driver ed04556a6676fd77ff845508bc54bfc60915450c https://github.com/intel/media-driver libva-utils 9a10ad663349732decd668a426cfc349b0010d1d https://github.com/01org/libva-utils.git Mediasdk 7ea683585f0f84f1bea035a405855312c92c46c0 https://github.com/Intel-Media-SDK/MediaSDK FFMPEG 56f68a099cc607658118e00cad30569103ae3751 https://git.ffmpeg.org/ffmpeg.git
How to reproduce:
1.build env as above lists 2.ffmpeg -hwaccel qsv -hwaccel_device /dev/dri/renderD128 -v verbose -c:v vc1_qsv -i /media//yami_vc1/SA00049.vc1 -vf hwdownload,format=nv12 -pix_fmt yuv420p -f rawvideo -vsync 0 -y ./dump.yuv 3.7yuv open dump.yuv
command line run message
Error while decoding stream #0:0: Invalid argument [rawvideo @ 0x16bcd80] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 30 >= 0 [rawvideo @ 0x16bcd80] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 31 >= 31 Error while decoding stream #0:0: Invalid argument [vc1_qsv @ 0x16bc900] A decode call did not consume any data: expect more data at input (-10) Error while decoding stream #0:0: Invalid argument [vc1_qsv @ 0x16bc900] A decode call did not consume any data: expect more data at input (-10) [rawvideo @ 0x16bcd80] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 31 >= 31 [vc1_qsv @ 0x16bc900] A decode call did not consume any data: expect more data at input (-10) [rawvideo @ 0x16bcd80] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 31 >= 31 [vc1_qsv @ 0x16bc900] A decode call did not consume any data: expect more data at input (-10) No more output streams to write to, finishing. frame= 28 fps=0.0 q=-0.0 Lsize= 3150kB time=00:00:01.28 bitrate=20160.0kbits/s speed=45.7x video:3150kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000% Input file #0 (/media//yami_vc1/SA00049.vc1):
Attachments (2)
Change History (5)
by , 6 years ago
Attachment: | SA00049.PNG added |
---|
comment:1 by , 6 years ago
by , 6 years ago
Attachment: | SA00049.vc1 added |
---|
comment:2 by , 6 years ago
The libmfx decoder seems to have lost some of the output?
Decoding with VAAPI on the iHD driver agrees with software output:
$ LIBVA_DRIVER_NAME=iHD ./ffmpeg -y -vsync 0 -hwaccel qsv -c:v vc1_qsv -i SA00049.vc1 -vf 'hwdownload,format=nv12,format=yuv420p' out_mfx.yuv ... $ LIBVA_DRIVER_NAME=iHD ./ffmpeg -y -vsync 0 -hwaccel vaapi -hwaccel_output_format vaapi -i SA00049.vc1 -vf 'hwdownload,format=nv12,format=yuv420p' out_va.yuv ... $ ./ffmpeg -y -vsync 0 -i SA00049.vc1 -vf 'format=yuv420p' out_ref.yuv ... $ md5sum out_*.yuv 41092ad3043fa245cd6f7edab7252a67 out_mfx.yuv aed9984f8a6e57cc563390a3e188f600 out_ref.yuv aed9984f8a6e57cc563390a3e188f600 out_va.yuv $ du -b out_*.yuv 3225600 out_mfx.yuv 3456000 out_ref.yuv 3456000 out_va.yuv
(That file does not have complete timestamps, hence -vsync 0.)
comment:3 by , 6 years ago
vc1_qsv decoder drops frames, but works if set the async_depth to 1.
It seems something to do with the buffer mode and cause the issue of display frame order.
Files an issue in MSDK:
https://github.com/Intel-Media-SDK/MediaSDK/issues/1146
Note:
See TracTickets
for help on using tickets.
Can you share the input file for this?
Also, please try decoding with VAAPI directly on the iHD driver. The libmfx decoder wrappers should probably be considered deprecated, since the platform hwaccel implementations in each case (DXVA2, D3D11VA, VAAPI) are better is essentially all respects (and also support mapping to libmfx surfaces if that's needed for some later operation).