[FFmpeg-devel] [PATCH 1/2 V2] libavcodec/qsvdec: Fix the QSV decoder can't work when using system memory

[wm4]

On Tue, 17 Jan 2017 14:53:31 +0800
"Huang, Zhengxu" <zhengxu.maxwell at gmail.com> wrote:

> 在 2017/1/12 5:00, Mark Thompson 写道:
> 
> > On 09/01/17 02:05, Huang, Zhengxu wrote:  
> >>  From 37629f14294125c7396e5e12970d75e895b1caba Mon Sep 17 00:00:00 2001
> >> From: Zhengxu <zhengxu.maxwell at gmail.com>
> >> Date: Mon, 19 Dec 2016 01:27:06 -0500
> >> Subject: [PATCH 1/2] libavcodec/qsvdec: Fix the QSV decoder can't work when
> >>   using system memory
> >>
> >> Description: ./ffmpeg -c:v h264_qsv -i in -c:v h264 output.h264 does not
> >> work because the qsv decode will failed.  
> > Yes it does!  (Or at least, it works for me?)  In the absence of a provided device handle the dispatcher finds a device to use.  
> Our test environment is the MSS 16.5 PV1 and the decode indeed can't 
> work in the system memory.
> >
> > Now I can see that it is likely to run into exactly the same device-selection issues as were being fixed in other patch, but I don't see how this is fixing it.  You are not passing anything to av_hwdevice_ctx_create(), so it will be going through exactly the same set of possible device nodes as ffmpeg did and will therefore fail to find the device in exactly the same way.
> > So, to properly fix the problem I think you are having (but correct me if this is wrong), you really want the -qsv_device option added to ffmpeg to apply to this case in libavcodec as well?  That is, we get the qsv_device in ffmpeg into libavcodec somehow and then use it with the code below.  (Patch itself implementing that looks mostly fine, but I would prefer to get the methodology resolved first.  Similarly for the matching patch to the encoder.)  
> yes, you are right!  We do need to add the qsv_device for the 
> encode/decode to choose a device handle.  The user can assign the device 
> using the
> below command:
> 
> /./ffmpeg -qsv_dev device -c:v h264_qsv -i in -c:v h264 output.h264/
> 
> / ./ffmpeg -c:v h264 -i in  -qsv_dev device-c:v h264_qsv  output.h264/
> 
> Using the qsv_dev inorder to avoid conflicting with the global option 
> "qsv_device".

That seems to go very much into the wrong direction.

This should probably wait until we have a field for the
AVHWDeviceContext in AVCodecContext, instead of adding absurd hacks
adding slightly differently named option to disambiguate it.