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)

SA00049.PNG (283.9 KB ) - added by a 6 years ago.
SA00049.vc1 (180.4 KB ) - added by Carl Eugen Hoyos 6 years ago.

Download all attachments as: .zip

Change History (5)

by a, 6 years ago

Attachment: SA00049.PNG added

comment:1 by jkqxz, 6 years ago

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).

by Carl Eugen Hoyos, 6 years ago

Attachment: SA00049.vc1 added

comment:2 by jkqxz, 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 Linjie.Fu, 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.