On Tue, 17 Jan 2017 14:53:31 +0800 "Huang, Zhengxu" <[email protected]> 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 <[email protected]> > >> 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. _______________________________________________ ffmpeg-devel mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
