Opened 2 months ago

Closed 9 days ago

Last modified 9 days ago

#7399 closed defect (fixed)

[ffmpeg-qsv][h264_ffmpeg]decode drop frames on iHD driver.

Reported by: zhuqingliang Owned by:
Priority: normal Component: avcodec
Version: git-master Keywords: qsv
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:

ffmpeg-qsv decode reinit-large_420_8-to-small_420_8.h264 show 93 frame, but yamidecode this file show totally 100 frames.

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 -y -c:v h264_qsv -i /media//ffmpeg_h264/reinit-large_420_8-to-small_420_8.h264 -vf hwdownload,format=nv12 -pix_fmt yuv420p -f rawvideo -y dump.yuv -vsync 0
3.  check message:
frame=   93 fps=0.0 q=-0.0 Lsize=   13810kB time=00:00:04.40 bitrate=25712.6kbits/s speed=62.2x
4. yamidecode -i /media//ffmpeg_h264/reinit-large_420_8-to-small_420_8.h264 -m 0
5. check message:
100 frame decoded, fps = 3571.43. fps after 5 frames = 3653.85.

Change History (5)

comment:1 Changed 2 months ago by cehoyos

  • Keywords qsv added; ffmpeg-qsv h264 decode drop frame removed

comment:2 Changed 2 months ago by jkqxz

libmfx doesn't seem to be producing exact output here, though it does look visually correct? Using VAAPI with iHD does get the expected result, so it's only a problem with libmfx and not the iHD driver.

I get:

$ LIBVA_DRIVER_NAME=iHD ./ffmpeg -y -hwaccel qsv -c:v h264_qsv -i reinit-large_420_8-to-small_420_8.h264 -vf 'hwdownload,format=nv12,format=yuv420p' out_mfx.yuv
...
$ LIBVA_DRIVER_NAME=iHD ./ffmpeg -y -hwaccel vaapi -hwaccel_output_format vaapi -i reinit-large_420_8-to-small_420_8.h264 -vf 'hwdownload,format=nv12,format=yuv420p' out_va.yuv
...
$ ./ffmpeg -y -i reinit-large_420_8-to-small_420_8.h264 out_ref.yuv
...
$ md5sum out_*.yuv
eee1a8af32fc9ae651356f88da040e7a  out_mfx.yuv
151bf4fac480ad53d8f62ed6cd43b55c  out_ref.yuv
151bf4fac480ad53d8f62ed6cd43b55c  out_va.yuv

comment:3 Changed 7 weeks ago by fulinjie

The frame dropping issue was caused by the reinitialization of the input stream.(In this stream,first 50 frames: 352x288,last 50 frames: 240x 196)The reinitialization drops all the buffered pkts in libmfx.

Provided a patch to cache the first frame causing the reinit and decode zero-size pkt to flush the buffered pkt before reinit. After all thebuffered pkts being flushed, resume to reinit and decode.

commit id: 505679cb6d2cd0e7c1714e28e05a6b9cdc917991
https://patchwork.ffmpeg.org/patch/10515/
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-September/234703.html

Tested and got the same result with vaapi and ffmpeg ref:

$ ffmpeg -y -loglevel debug -hwaccel qsv -c:v h264_qsv -i reinit-large_420_8-to-small_420_8.h264 -vf 'hwdownload,format=nv12,format=yuv420p' out_mfx.yuv
...
$ md5sum out_mfx.yuv
151bf4fac480ad53d8f62ed6cd43b55c  out_mfx.yuv

comment:4 Changed 9 days ago by lizhong1008

  • Resolution set to fixed
  • Status changed from new to closed

comment:5 Changed 9 days ago by cehoyos

  • Component changed from undetermined to avcodec
  • Version changed from unspecified to git-master
Note: See TracTickets for help on using tickets.