On Wed, 2020-09-02 at 04:32 +0000, Soft Works wrote:
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
> > Soft Works
> > Sent: Wednesday, September 2, 2020 6:13 AM
> > To: FFmpeg development discussions and patches <ffmpeg-
> > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvdec: allow qsv decoders
> > to use
> > initialized device
> >
> > >
> > > > -----Original Message-----
> > > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf
> > > > Of
> > > > Dmitry Rogozhkin
> > > > Sent: Wednesday, September 2, 2020 4:44 AM
> > > > To: ffmpeg-devel@ffmpeg.org
> > > > Cc: Dmitry Rogozhkin <dmitry.v.rogozh...@intel.com>
> > > > Subject: [FFmpeg-devel] [PATCH] lavc/qsvdec: allow qsv decoders
> > > > to
> > > > use initialized device
> > > >
> > > > qsv decoders did not allow to use devices explicitly
> > > > initialized on
> > > > the command line and actually were using default device. This
> > > > starts
> > > > to cause confusion with intel discrete GPUs since in this case
> > > > decoder might run on default integrated GPU device
> > > > (/dev/dri/renderD128) and encoder on the device specified on
> > > > the
> > > > command line
> > >
> > > (/dev/dri/renderD129).
> > > >
> > > > Example:
> > > > ffmpeg -init_hw_device vaapi=va:/dev/dri/renderD129
> > > > -init_hw_device
> > > > qsv=hw@va \
> > > > -c:v h264_qsv -i input.h264 -c:v hevc_qsv -y output.h264
> > I apologize, I picked the wrong thing. The qsv_device parameter is
> > what
> > allows setting the device for a QSV decoder:
> >
> > fmpeg -qsv_device /dev/dri/renderD128 -c:v:0 h264_qsv -hwaccel:v:0
> > qsv -i
> > INPUT ....
> >
> > Kind regards,
> > softworkz
>
> Here's the commit where the parameter had been added:
> https://github.com/FFmpeg/FFmpeg/commit/1a79b8f8d2b5d26c60c237d6e585873238e46914
I am aware of this option.
> -qsv_device /dev/dri/renderD129
By itself this don’t work. Both decoder and encoder will run on
/dev/dri/renderD128 instead.
> -hwaccel qsv -qsv_device /dev/dri/renderD129
Adding -hwaccel helps. This works. However, to me this is non-
intuitive: why qsv_device should be used instead of hwaccel_device
while ffmpeg help gives a different hint:
-hwaccel hwaccel name use HW accelerated decoding
-hwaccel_device devicename select a device for HW acceleration
From this perspective Haihao’s patch which is currently on the mailing
list makes sense to me it just simplifies things.
Unfortunately ffmpeg device selection options are quite confusing. One
of the problems with -qsv_device is that the following pure encoding
won’t work:
ffmpeg -hwaccel qsv -qsv_device /dev/dri/renderD129 -f rawvideo
-pix_fmt yuv420p -s:v 1920x1080 -r 30 -i a.yuv -c:v h264_qsv out.h264
Execution will happen on /dev/dri/renderD128 instead. To make it work
on 129 you will need to run something like the following:
ffmpeg -init_hw_device vaapi=va:/dev/dri/renderD129 -init_hw_device
qsv=hw@va -f rawvideo -pix_fmt yuv420p -s:v 1920x1080 -r 30 -i a.yuv
-c:v h264_qsv out.h264
This will work. But returning back to transcoding case: there are 2
significantly different command lines which should be used for
transcoding and encoding to make things run on /dev/dri/renderD129.
This is inconvenient to handle… And additionally there is also
-filter_hw_device which also contributes to the complication. Also
there are special marks in documentation for the qsv “Unlike most other
values, this option does not enable accelerated decoding (that is used
automatically whenever a qsv decoder is selected), but accelerated
transcoding, without copying the frames into the system memory. For it
to work, both the decoder and the encoder must support QSV acceleration
and no filters must be used.”
One missing thing seems to be documentation on the scope of
-init_hw_device option applicability. This seems to be a global option,
but in the example from the commit message encoder actually takes
device from it, but decoder just ignores it and goes with default
device. Why? This does not seem to be right.
Can someone, please, shine the light on how all these device selection
options were supposed to work? /Eventually my patch tries to fix
behavior in accordance with my understanding of the supposed behavior./
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
