diff mbox series

[FFmpeg-devel] ffmpeg_qsv: use -hwaccel_device to specify a device for VAAPI backend

Message ID 20200902040103.85196-1-haihao.xiang@intel.com
State New
Headers show
Series [FFmpeg-devel] ffmpeg_qsv: use -hwaccel_device to specify a device for VAAPI backend
Related show

Checks

Context Check Description
andriy/default pending
andriy/make success Make finished
andriy/make_fate success Make fate finished

Commit Message

Haihao Xiang Sept. 2, 2020, 4:01 a.m. UTC
According to the FFmpeg documentation, -hwaccel_device can be used to
select a device for hardware acceleration

Example:
ffmpeg -hwaccel qsv -hwaccel_device /dev/dri/renderD129 -c:v h264_qsv \
-i in.h264 -c:v hevc_qsv out.h265
---
 fftools/ffmpeg_qsv.c | 8 ++++++++
 1 file changed, 8 insertions(+)

Comments

Soft Works Sept. 2, 2020, 4:20 a.m. UTC | #1
> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Haihao Xiang
> Sent: Wednesday, September 2, 2020 6:01 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Haihao Xiang <haihao.xiang@intel.com>
> Subject: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device to
> specify a device for VAAPI backend
> 
> According to the FFmpeg documentation, -hwaccel_device can be used to
> select a device for hardware acceleration
> 
> Example:
> ffmpeg -hwaccel qsv -hwaccel_device /dev/dri/renderD129 -c:v h264_qsv \ -i
> in.h264 -c:v hevc_qsv out.h265

No. The docs say about hwaccel_device

It can either refer to an existing device created with 
-init_hw_device by name, 

=> /dev/dri/renderD129 is not an existing device name

or it can create a new device as if ‘-init_hw_device’ 
type:hwaccel_device were called immediately before.

=> /dev/dri/renderD129 is not a valid string for init_hw_device


Hence, the patch doesn't make sense.

Kind regards,
softworkz
Haihao Xiang Sept. 2, 2020, 4:28 a.m. UTC | #2
On Wed, 2020-09-02 at 04:20 +0000, Soft Works wrote:
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > Haihao Xiang
> > Sent: Wednesday, September 2, 2020 6:01 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Haihao Xiang <haihao.xiang@intel.com>
> > Subject: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device to
> > specify a device for VAAPI backend
> > 
> > According to the FFmpeg documentation, -hwaccel_device can be used to
> > select a device for hardware acceleration
> > 
> > Example:
> > ffmpeg -hwaccel qsv -hwaccel_device /dev/dri/renderD129 -c:v h264_qsv \ -i
> > in.h264 -c:v hevc_qsv out.h265
> 
> No. The docs say about hwaccel_device
> 
> It can either refer to an existing device created with 
> -init_hw_device by name, 
> 
> => /dev/dri/renderD129 is not an existing device name
> 
> or it can create a new device as if ‘-init_hw_device’ 
> type:hwaccel_device were called immediately before.
> 
> => /dev/dri/renderD129 is not a valid string for init_hw_device
> 
> 
> Hence, the patch doesn't make sense.

in https://trac.ffmpeg.org/wiki/Hardware/VAAPI, 

If only one stream is being used, -hwaccel_device can also accept a device path
directly

ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i ...

I think it can be applied to qsv too.



> 
> Kind regards,
> softworkz
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Rogozhkin, Dmitry V Sept. 2, 2020, 7 a.m. UTC | #3
On Wed, 2020-09-02 at 04:28 +0000, Xiang, Haihao wrote:
> On Wed, 2020-09-02 at 04:20 +0000, Soft Works wrote:
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > > Haihao Xiang
> > > Sent: Wednesday, September 2, 2020 6:01 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Haihao Xiang <haihao.xiang@intel.com>
> > > Subject: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device
> > > to
> > > specify a device for VAAPI backend
> > > 
> > > According to the FFmpeg documentation, -hwaccel_device can be
> > > used to
> > > select a device for hardware acceleration
> > > 
> > > Example:
> > > ffmpeg -hwaccel qsv -hwaccel_device /dev/dri/renderD129 -c:v
> > > h264_qsv \ -i
> > > in.h264 -c:v hevc_qsv out.h265
> > 
> > No. The docs say about hwaccel_device
> > 
> > It can either refer to an existing device created with 
> > -init_hw_device by name, 
> > 
> > => /dev/dri/renderD129 is not an existing device name
> > 
> > or it can create a new device as if ‘-init_hw_device’ 
> > type:hwaccel_device were called immediately before.
> > 
> > => /dev/dri/renderD129 is not a valid string for init_hw_device

Well, it seems that's where documentation does not reflect the reality
since (as pointed by Haihao below) 
https://trac.ffmpeg.org/wiki/Hardware/VAAPI is full of contradictory
examples.

> > 
> > 
> > Hence, the patch doesn't make sense.
> 
> in https://trac.ffmpeg.org/wiki/Hardware/VAAPI, 
> 
> If only one stream is being used, -hwaccel_device can also accept a
> device path
> directly
> 
> ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i ...
> 
> I think it can be applied to qsv too.
> 

I agree. Part of ffmpeg help:
    -hwaccel hwaccel name  use HW accelerated decoding
    -hwaccel_device devicename  select a device for HW acceleration

To me specifying device via -hwaccel_device in the way it is being
suggest in commit is pretty intuitive and is better than explain people
that there is -qsv_device for that purpose. Niceness of -hwaccel_device
is that it is not tight to particular acceleration, hence easier to
work with for end users.

> 
> 
> > 
> > Kind regards,
> > softworkz
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > 
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-request@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-request@ffmpeg.org with subject "unsubscribe".
Soft Works Sept. 2, 2020, 7:31 a.m. UTC | #4
> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Rogozhkin, Dmitry V
> Sent: Wednesday, September 2, 2020 9:00 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device to
> specify a device for VAAPI backend
> 
> On Wed, 2020-09-02 at 04:28 +0000, Xiang, Haihao wrote:
> > On Wed, 2020-09-02 at 04:20 +0000, Soft Works wrote:
> > > > -----Original Message-----
> > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf
> Of
> > > > Haihao Xiang
> > > > Sent: Wednesday, September 2, 2020 6:01 AM
> > > > To: ffmpeg-devel@ffmpeg.org
> > > > Cc: Haihao Xiang <haihao.xiang@intel.com>
> > > > Subject: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device to
> > > > specify a device for VAAPI backend
> > > >
> > > > According to the FFmpeg documentation, -hwaccel_device can be used
> > > > to select a device for hardware acceleration
> > > >
> > > > Example:
> > > > ffmpeg -hwaccel qsv -hwaccel_device /dev/dri/renderD129 -c:v
> > > > h264_qsv \ -i
> > > > in.h264 -c:v hevc_qsv out.h265
> > >
> > > No. The docs say about hwaccel_device
> > >
> > > It can either refer to an existing device created with
> > > -init_hw_device by name,
> > >
> > > => /dev/dri/renderD129 is not an existing device name
> > >
> > > or it can create a new device as if ‘-init_hw_device’
> > > type:hwaccel_device were called immediately before.
> > >
> > > => /dev/dri/renderD129 is not a valid string for init_hw_device
> 
> Well, it seems that's where documentation does not reflect the reality since
> (as pointed by Haihao below) https://trac.ffmpeg.org/wiki/Hardware/VAAPI
> is full of contradictory examples.
> 
> > >
> > >
> > > Hence, the patch doesn't make sense.
> >
> > in https://trac.ffmpeg.org/wiki/Hardware/VAAPI,
> >
> > If only one stream is being used, -hwaccel_device can also accept a
> > device path directly
> >
> > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i ...
> >
> > I think it can be applied to qsv too.
> >
> 
> I agree. Part of ffmpeg help:
>     -hwaccel hwaccel name  use HW accelerated decoding
>     -hwaccel_device devicename  select a device for HW acceleration
> 
> To me specifying device via -hwaccel_device in the way it is being suggest in
> commit is pretty intuitive and is better than explain people that there is -
> qsv_device for that purpose. Niceness of -hwaccel_device is that it is not
> tight to particular acceleration, hence easier to work with for end users.

In case of QSV, the usage of hwaccel_device is already defined:

device selects a value in ‘MFX_IMPL_*’. Allowed values are:
auto sw  hw  auto_any hw_any hw2 hw3 hw4

I agree that it would be more intuitive, but you can't just give it a
different meaning from one day to another and break functionality.

Kind regards,
softworkz
Rogozhkin, Dmitry V Sept. 2, 2020, 1:54 p.m. UTC | #5
On Wed, 2020-09-02 at 07:31 +0000, Soft Works wrote:
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > Rogozhkin, Dmitry V
> > Sent: Wednesday, September 2, 2020 9:00 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device
> > to
> > specify a device for VAAPI backend
> > 
> > On Wed, 2020-09-02 at 04:28 +0000, Xiang, Haihao wrote:
> > > On Wed, 2020-09-02 at 04:20 +0000, Soft Works wrote:
> > > > > -----Original Message-----
> > > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On
> > > > > Behalf
> > 
> > Of
> > > > > Haihao Xiang
> > > > > Sent: Wednesday, September 2, 2020 6:01 AM
> > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > Cc: Haihao Xiang <haihao.xiang@intel.com>
> > > > > Subject: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use
> > > > > -hwaccel_device to
> > > > > specify a device for VAAPI backend
> > > > > 
> > > > > According to the FFmpeg documentation, -hwaccel_device can be
> > > > > used
> > > > > to select a device for hardware acceleration
> > > > > 
> > > > > Example:
> > > > > ffmpeg -hwaccel qsv -hwaccel_device /dev/dri/renderD129 -c:v
> > > > > h264_qsv \ -i
> > > > > in.h264 -c:v hevc_qsv out.h265
> > > > 
> > > > No. The docs say about hwaccel_device
> > > > 
> > > > It can either refer to an existing device created with
> > > > -init_hw_device by name,
> > > > 
> > > > => /dev/dri/renderD129 is not an existing device name
> > > > 
> > > > or it can create a new device as if ‘-init_hw_device’
> > > > type:hwaccel_device were called immediately before.
> > > > 
> > > > => /dev/dri/renderD129 is not a valid string for init_hw_device
> > 
> > Well, it seems that's where documentation does not reflect the
> > reality since
> > (as pointed by Haihao below) 
> > https://trac.ffmpeg.org/wiki/Hardware/VAAPI
> > is full of contradictory examples.
> > 
> > > > 
> > > > 
> > > > Hence, the patch doesn't make sense.
> > > 
> > > in https://trac.ffmpeg.org/wiki/Hardware/VAAPI,
> > > 
> > > If only one stream is being used, -hwaccel_device can also accept
> > > a
> > > device path directly
> > > 
> > > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i ...
> > > 
> > > I think it can be applied to qsv too.
> > > 
> > 
> > I agree. Part of ffmpeg help:
> >     -hwaccel hwaccel name  use HW accelerated decoding
> >     -hwaccel_device devicename  select a device for HW acceleration
> > 
> > To me specifying device via -hwaccel_device in the way it is being
> > suggest in
> > commit is pretty intuitive and is better than explain people that
> > there is -
> > qsv_device for that purpose. Niceness of -hwaccel_device is that it
> > is not
> > tight to particular acceleration, hence easier to work with for end
> > users.
> 
> In case of QSV, the usage of hwaccel_device is already defined:
> 
> device selects a value in ‘MFX_IMPL_*’. Allowed values are:
> auto sw  hw  auto_any hw_any hw2 hw3 hw4
> 
> I agree that it would be more intuitive, but you can't just give it a
> different meaning from one day to another and break functionality.

Adding new values does not break functionality! No one  suggests to
drop existing set of values (sw, hw, etc.) - these are remaining. But
basically suggestion is to extend allowed set to accept drm device
specification on Linux, that's it. Honestly, I don't see problem here.
Some background story: hw,hw2,hw3 allows to select adapter for msdk
library on Windows, but they don't allow to do that on Linux. On Linux
all these hw options are basically the same for the reason that device
is being specified externally via SetHandle call. On Linux only sw/hw
makes a difference (other story that sw msdk library is not actually
released currently on Linux). That's the origin of the request: we need
a good way to specify adapter on Linux.

> 
> Kind regards,
> softworkz
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Soft Works Sept. 2, 2020, 2:04 p.m. UTC | #6
> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Rogozhkin, Dmitry V
> Sent: Wednesday, September 2, 2020 3:54 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device to
> specify a device for VAAPI backend
> 
> On Wed, 2020-09-02 at 07:31 +0000, Soft Works wrote:
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > > Rogozhkin, Dmitry V
> > > Sent: Wednesday, September 2, 2020 9:00 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device
> > > to specify a device for VAAPI backend
> > >
> > > On Wed, 2020-09-02 at 04:28 +0000, Xiang, Haihao wrote:
> > > > On Wed, 2020-09-02 at 04:20 +0000, Soft Works wrote:
> > > > > > -----Original Message-----
> > > > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On
> Behalf
> > >
> > > Of
> > > > > > Haihao Xiang
> > > > > > Sent: Wednesday, September 2, 2020 6:01 AM
> > > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > > Cc: Haihao Xiang <haihao.xiang@intel.com>
> > > > > > Subject: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use
> > > > > > -hwaccel_device to specify a device for VAAPI backend
> > > > > >
> > > > > > According to the FFmpeg documentation, -hwaccel_device can be
> > > > > > used to select a device for hardware acceleration
> > > > > >
> > > > > > Example:
> > > > > > ffmpeg -hwaccel qsv -hwaccel_device /dev/dri/renderD129 -c:v
> > > > > > h264_qsv \ -i
> > > > > > in.h264 -c:v hevc_qsv out.h265
> > > > >
> > > > > No. The docs say about hwaccel_device
> > > > >
> > > > > It can either refer to an existing device created with
> > > > > -init_hw_device by name,
> > > > >
> > > > > => /dev/dri/renderD129 is not an existing device name
> > > > >
> > > > > or it can create a new device as if ‘-init_hw_device’
> > > > > type:hwaccel_device were called immediately before.
> > > > >
> > > > > => /dev/dri/renderD129 is not a valid string for init_hw_device
> > >
> > > Well, it seems that's where documentation does not reflect the
> > > reality since (as pointed by Haihao below)
> > > https://trac.ffmpeg.org/wiki/Hardware/VAAPI
> > > is full of contradictory examples.
> > >
> > > > >
> > > > >
> > > > > Hence, the patch doesn't make sense.
> > > >
> > > > in https://trac.ffmpeg.org/wiki/Hardware/VAAPI,
> > > >
> > > > If only one stream is being used, -hwaccel_device can also accept
> > > > a device path directly
> > > >
> > > > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i ...
> > > >
> > > > I think it can be applied to qsv too.
> > > >
> > >
> > > I agree. Part of ffmpeg help:
> > >     -hwaccel hwaccel name  use HW accelerated decoding
> > >     -hwaccel_device devicename  select a device for HW acceleration
> > >
> > > To me specifying device via -hwaccel_device in the way it is being
> > > suggest in commit is pretty intuitive and is better than explain
> > > people that there is - qsv_device for that purpose. Niceness of
> > > -hwaccel_device is that it is not tight to particular acceleration,
> > > hence easier to work with for end users.
> >
> > In case of QSV, the usage of hwaccel_device is already defined:
> >
> > device selects a value in ‘MFX_IMPL_*’. Allowed values are:
> > auto sw  hw  auto_any hw_any hw2 hw3 hw4
> >
> > I agree that it would be more intuitive, but you can't just give it a
> > different meaning from one day to another and break functionality.
> 
> Adding new values does not break functionality! No one  suggests to drop
> existing set of values (sw, hw, etc.) - these are remaining. But basically
> suggestion is to extend allowed set to accept drm device specification on
> Linux, that's it. Honestly, I don't see problem here.
> Some background story: hw,hw2,hw3 allows to select adapter for msdk
> library on Windows, but they don't allow to do that on Linux. On Linux all
> these hw options are basically the same for the reason that device is being
> specified externally via SetHandle call. On Linux only sw/hw makes a
> difference (other story that sw msdk library is not actually released currently
> on Linux). That's the origin of the request: we need a good way to specify
> adapter on Linux.

As mentioned, there are cases where both needs to be specified on Windows:
hw, hw2, hw3,.. plus adapter number. 

'qsv_device' is for specifying adapter number on Windows and DRI on Linux
'hwaccel_device' is for specifying hw, hw2, hw3 (everywhere)

I see no reason to start mixing that and allowing to specify DRI via 'hwaccel_device' parameter.

That would make things just worse instead of improving anything.

That's how I see it. I would be really interested what others think...

Kind regards,
softworkz

The adapter number is specified via 'qsv_device' a
Haihao Xiang Sept. 3, 2020, 1:21 a.m. UTC | #7
On Wed, 2020-09-02 at 14:04 +0000, Soft Works wrote:
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > Rogozhkin, Dmitry V
> > Sent: Wednesday, September 2, 2020 3:54 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device to
> > specify a device for VAAPI backend
> > 
> > On Wed, 2020-09-02 at 07:31 +0000, Soft Works wrote:
> > > > -----Original Message-----
> > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > > > Rogozhkin, Dmitry V
> > > > Sent: Wednesday, September 2, 2020 9:00 AM
> > > > To: ffmpeg-devel@ffmpeg.org
> > > > Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device
> > > > to specify a device for VAAPI backend
> > > > 
> > > > On Wed, 2020-09-02 at 04:28 +0000, Xiang, Haihao wrote:
> > > > > On Wed, 2020-09-02 at 04:20 +0000, Soft Works wrote:
> > > > > > > -----Original Message-----
> > > > > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On
> > 
> > Behalf
> > > > 
> > > > Of
> > > > > > > Haihao Xiang
> > > > > > > Sent: Wednesday, September 2, 2020 6:01 AM
> > > > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > > > Cc: Haihao Xiang <haihao.xiang@intel.com>
> > > > > > > Subject: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use
> > > > > > > -hwaccel_device to specify a device for VAAPI backend
> > > > > > > 
> > > > > > > According to the FFmpeg documentation, -hwaccel_device can be
> > > > > > > used to select a device for hardware acceleration
> > > > > > > 
> > > > > > > Example:
> > > > > > > ffmpeg -hwaccel qsv -hwaccel_device /dev/dri/renderD129 -c:v
> > > > > > > h264_qsv \ -i
> > > > > > > in.h264 -c:v hevc_qsv out.h265
> > > > > > 
> > > > > > No. The docs say about hwaccel_device
> > > > > > 
> > > > > > It can either refer to an existing device created with
> > > > > > -init_hw_device by name,
> > > > > > 
> > > > > > => /dev/dri/renderD129 is not an existing device name
> > > > > > 
> > > > > > or it can create a new device as if ‘-init_hw_device’
> > > > > > type:hwaccel_device were called immediately before.
> > > > > > 
> > > > > > => /dev/dri/renderD129 is not a valid string for init_hw_device
> > > > 
> > > > Well, it seems that's where documentation does not reflect the
> > > > reality since (as pointed by Haihao below)
> > > > https://trac.ffmpeg.org/wiki/Hardware/VAAPI
> > > > is full of contradictory examples.
> > > > 
> > > > > > 
> > > > > > 
> > > > > > Hence, the patch doesn't make sense.
> > > > > 
> > > > > in https://trac.ffmpeg.org/wiki/Hardware/VAAPI,
> > > > > 
> > > > > If only one stream is being used, -hwaccel_device can also accept
> > > > > a device path directly
> > > > > 
> > > > > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i ...
> > > > > 
> > > > > I think it can be applied to qsv too.
> > > > > 
> > > > 
> > > > I agree. Part of ffmpeg help:
> > > >     -hwaccel hwaccel name  use HW accelerated decoding
> > > >     -hwaccel_device devicename  select a device for HW acceleration
> > > > 
> > > > To me specifying device via -hwaccel_device in the way it is being
> > > > suggest in commit is pretty intuitive and is better than explain
> > > > people that there is - qsv_device for that purpose. Niceness of
> > > > -hwaccel_device is that it is not tight to particular acceleration,
> > > > hence easier to work with for end users.
> > > 
> > > In case of QSV, the usage of hwaccel_device is already defined:
> > > 
> > > device selects a value in ‘MFX_IMPL_*’. Allowed values are:
> > > auto sw  hw  auto_any hw_any hw2 hw3 hw4
> > > 
> > > I agree that it would be more intuitive, but you can't just give it a
> > > different meaning from one day to another and break functionality.
> > 
> > Adding new values does not break functionality! No one  suggests to drop
> > existing set of values (sw, hw, etc.) - these are remaining. But basically
> > suggestion is to extend allowed set to accept drm device specification on
> > Linux, that's it. Honestly, I don't see problem here.
> > Some background story: hw,hw2,hw3 allows to select adapter for msdk
> > library on Windows, but they don't allow to do that on Linux. On Linux all
> > these hw options are basically the same for the reason that device is being
> > specified externally via SetHandle call. On Linux only sw/hw makes a
> > difference (other story that sw msdk library is not actually released
> > currently
> > on Linux). That's the origin of the request: we need a good way to specify
> > adapter on Linux.
> 
> As mentioned, there are cases where both needs to be specified on Windows:
> hw, hw2, hw3,.. plus adapter number. 
> 
> 'qsv_device' is for specifying adapter number on Windows and DRI on Linux
> 'hwaccel_device' is for specifying hw, hw2, hw3 (everywhere)

According to https://trac.ffmpeg.org/ticket/7649, -qsv_device was added to
workaround device selection on Linux.

On Windows, we should not use another option to specify the adapter number, the
adapter is 1:1 mapped to the hw impl. I think we should fix it if the current
QSV depends on -qsv_device on Window.

https://github.com/Intel-Media-SDK/MediaSDK/blob/master/samples/sample_decode/src/pipeline_decode.cpp#L245-L264

> 
> I see no reason to start mixing that and allowing to specify DRI via
> 'hwaccel_device' parameter.
> 
> That would make things just worse instead of improving anything.

From user's perspective, we may use the same device selection for both QSV and
VAAPI on Linux. It is easy for user to move from QSV to VAAPI or inverse. 

> 
> That's how I see it. I would be really interested what others think...
> 
> Kind regards,
> softworkz
> 
> The adapter number is specified via 'qsv_device' a
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
mypopy@gmail.com Sept. 3, 2020, 4:59 a.m. UTC | #8
On Thu, Sep 3, 2020 at 9:21 AM Xiang, Haihao <haihao.xiang@intel.com> wrote:
>
> On Wed, 2020-09-02 at 14:04 +0000, Soft Works wrote:
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > > Rogozhkin, Dmitry V
> > > Sent: Wednesday, September 2, 2020 3:54 PM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device to
> > > specify a device for VAAPI backend
> > >
> > > On Wed, 2020-09-02 at 07:31 +0000, Soft Works wrote:
> > > > > -----Original Message-----
> > > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > > > > Rogozhkin, Dmitry V
> > > > > Sent: Wednesday, September 2, 2020 9:00 AM
> > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device
> > > > > to specify a device for VAAPI backend
> > > > >
> > > > > On Wed, 2020-09-02 at 04:28 +0000, Xiang, Haihao wrote:
> > > > > > On Wed, 2020-09-02 at 04:20 +0000, Soft Works wrote:
> > > > > > > > -----Original Message-----
> > > > > > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On
> > >
> > > Behalf
> > > > >
> > > > > Of
> > > > > > > > Haihao Xiang
> > > > > > > > Sent: Wednesday, September 2, 2020 6:01 AM
> > > > > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > > > > Cc: Haihao Xiang <haihao.xiang@intel.com>
> > > > > > > > Subject: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use
> > > > > > > > -hwaccel_device to specify a device for VAAPI backend
> > > > > > > >
> > > > > > > > According to the FFmpeg documentation, -hwaccel_device can be
> > > > > > > > used to select a device for hardware acceleration
> > > > > > > >
> > > > > > > > Example:
> > > > > > > > ffmpeg -hwaccel qsv -hwaccel_device /dev/dri/renderD129 -c:v
> > > > > > > > h264_qsv \ -i
> > > > > > > > in.h264 -c:v hevc_qsv out.h265
> > > > > > >
> > > > > > > No. The docs say about hwaccel_device
> > > > > > >
> > > > > > > It can either refer to an existing device created with
> > > > > > > -init_hw_device by name,
> > > > > > >
> > > > > > > => /dev/dri/renderD129 is not an existing device name
> > > > > > >
> > > > > > > or it can create a new device as if ‘-init_hw_device’
> > > > > > > type:hwaccel_device were called immediately before.
> > > > > > >
> > > > > > > => /dev/dri/renderD129 is not a valid string for init_hw_device
> > > > >
> > > > > Well, it seems that's where documentation does not reflect the
> > > > > reality since (as pointed by Haihao below)
> > > > > https://trac.ffmpeg.org/wiki/Hardware/VAAPI
> > > > > is full of contradictory examples.
> > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hence, the patch doesn't make sense.
> > > > > >
> > > > > > in https://trac.ffmpeg.org/wiki/Hardware/VAAPI,
> > > > > >
> > > > > > If only one stream is being used, -hwaccel_device can also accept
> > > > > > a device path directly
> > > > > >
> > > > > > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i ...
> > > > > >
> > > > > > I think it can be applied to qsv too.
> > > > > >
> > > > >
> > > > > I agree. Part of ffmpeg help:
> > > > >     -hwaccel hwaccel name  use HW accelerated decoding
> > > > >     -hwaccel_device devicename  select a device for HW acceleration
> > > > >
> > > > > To me specifying device via -hwaccel_device in the way it is being
> > > > > suggest in commit is pretty intuitive and is better than explain
> > > > > people that there is - qsv_device for that purpose. Niceness of
> > > > > -hwaccel_device is that it is not tight to particular acceleration,
> > > > > hence easier to work with for end users.
> > > >
> > > > In case of QSV, the usage of hwaccel_device is already defined:
> > > >
> > > > device selects a value in ‘MFX_IMPL_*’. Allowed values are:
> > > > auto sw  hw  auto_any hw_any hw2 hw3 hw4
> > > >
> > > > I agree that it would be more intuitive, but you can't just give it a
> > > > different meaning from one day to another and break functionality.
> > >
> > > Adding new values does not break functionality! No one  suggests to drop
> > > existing set of values (sw, hw, etc.) - these are remaining. But basically
> > > suggestion is to extend allowed set to accept drm device specification on
> > > Linux, that's it. Honestly, I don't see problem here.
> > > Some background story: hw,hw2,hw3 allows to select adapter for msdk
> > > library on Windows, but they don't allow to do that on Linux. On Linux all
> > > these hw options are basically the same for the reason that device is being
> > > specified externally via SetHandle call. On Linux only sw/hw makes a
> > > difference (other story that sw msdk library is not actually released
> > > currently
> > > on Linux). That's the origin of the request: we need a good way to specify
> > > adapter on Linux.
> >
> > As mentioned, there are cases where both needs to be specified on Windows:
> > hw, hw2, hw3,.. plus adapter number.
> >
> > 'qsv_device' is for specifying adapter number on Windows and DRI on Linux
> > 'hwaccel_device' is for specifying hw, hw2, hw3 (everywhere)
>
> According to https://trac.ffmpeg.org/ticket/7649, -qsv_device was added to
> workaround device selection on Linux.
>
> On Windows, we should not use another option to specify the adapter number, the
> adapter is 1:1 mapped to the hw impl. I think we should fix it if the current
> QSV depends on -qsv_device on Window.
>
> https://github.com/Intel-Media-SDK/MediaSDK/blob/master/samples/sample_decode/src/pipeline_decode.cpp#L245-L264
>
> >
> > I see no reason to start mixing that and allowing to specify DRI via
> > 'hwaccel_device' parameter.
> >
> > That would make things just worse instead of improving anything.
>
> From user's perspective, we may use the same device selection for both QSV and
> VAAPI on Linux. It is easy for user to move from QSV to VAAPI or inverse.
>
Which case want to mix the  QSV and VAAPI in one FFmpeg pipeline? Do
you have a real case for this?

I know we used  VAAPI as decoder and QSV as encoder before when QSV
decoder have some limitation in FFmpeg

But I think we are better to fix QSV decoder in FFmpeg part or MSDK,
do you have any other case to mix VAAPI and QSV?
Haihao Xiang Sept. 3, 2020, 6:41 a.m. UTC | #9
On Thu, 2020-09-03 at 12:59 +0800, mypopy@gmail.com wrote:
> On Thu, Sep 3, 2020 at 9:21 AM Xiang, Haihao <haihao.xiang@intel.com> wrote:
> > 
> > On Wed, 2020-09-02 at 14:04 +0000, Soft Works wrote:
> > > > -----Original Message-----
> > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > > > Rogozhkin, Dmitry V
> > > > Sent: Wednesday, September 2, 2020 3:54 PM
> > > > To: ffmpeg-devel@ffmpeg.org
> > > > Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device to
> > > > specify a device for VAAPI backend
> > > > 
> > > > On Wed, 2020-09-02 at 07:31 +0000, Soft Works wrote:
> > > > > > -----Original Message-----
> > > > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > > > > > Rogozhkin, Dmitry V
> > > > > > Sent: Wednesday, September 2, 2020 9:00 AM
> > > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > > Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device
> > > > > > to specify a device for VAAPI backend
> > > > > > 
> > > > > > On Wed, 2020-09-02 at 04:28 +0000, Xiang, Haihao wrote:
> > > > > > > On Wed, 2020-09-02 at 04:20 +0000, Soft Works wrote:
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On
> > > > 
> > > > Behalf
> > > > > > 
> > > > > > Of
> > > > > > > > > Haihao Xiang
> > > > > > > > > Sent: Wednesday, September 2, 2020 6:01 AM
> > > > > > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > > > > > Cc: Haihao Xiang <haihao.xiang@intel.com>
> > > > > > > > > Subject: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use
> > > > > > > > > -hwaccel_device to specify a device for VAAPI backend
> > > > > > > > > 
> > > > > > > > > According to the FFmpeg documentation, -hwaccel_device can be
> > > > > > > > > used to select a device for hardware acceleration
> > > > > > > > > 
> > > > > > > > > Example:
> > > > > > > > > ffmpeg -hwaccel qsv -hwaccel_device /dev/dri/renderD129 -c:v
> > > > > > > > > h264_qsv \ -i
> > > > > > > > > in.h264 -c:v hevc_qsv out.h265
> > > > > > > > 
> > > > > > > > No. The docs say about hwaccel_device
> > > > > > > > 
> > > > > > > > It can either refer to an existing device created with
> > > > > > > > -init_hw_device by name,
> > > > > > > > 
> > > > > > > > => /dev/dri/renderD129 is not an existing device name
> > > > > > > > 
> > > > > > > > or it can create a new device as if ‘-init_hw_device’
> > > > > > > > type:hwaccel_device were called immediately before.
> > > > > > > > 
> > > > > > > > => /dev/dri/renderD129 is not a valid string for init_hw_device
> > > > > > 
> > > > > > Well, it seems that's where documentation does not reflect the
> > > > > > reality since (as pointed by Haihao below)
> > > > > > https://trac.ffmpeg.org/wiki/Hardware/VAAPI
> > > > > > is full of contradictory examples.
> > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Hence, the patch doesn't make sense.
> > > > > > > 
> > > > > > > in https://trac.ffmpeg.org/wiki/Hardware/VAAPI,
> > > > > > > 
> > > > > > > If only one stream is being used, -hwaccel_device can also accept
> > > > > > > a device path directly
> > > > > > > 
> > > > > > > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i ...
> > > > > > > 
> > > > > > > I think it can be applied to qsv too.
> > > > > > > 
> > > > > > 
> > > > > > I agree. Part of ffmpeg help:
> > > > > >     -hwaccel hwaccel name  use HW accelerated decoding
> > > > > >     -hwaccel_device devicename  select a device for HW acceleration
> > > > > > 
> > > > > > To me specifying device via -hwaccel_device in the way it is being
> > > > > > suggest in commit is pretty intuitive and is better than explain
> > > > > > people that there is - qsv_device for that purpose. Niceness of
> > > > > > -hwaccel_device is that it is not tight to particular acceleration,
> > > > > > hence easier to work with for end users.
> > > > > 
> > > > > In case of QSV, the usage of hwaccel_device is already defined:
> > > > > 
> > > > > device selects a value in ‘MFX_IMPL_*’. Allowed values are:
> > > > > auto sw  hw  auto_any hw_any hw2 hw3 hw4
> > > > > 
> > > > > I agree that it would be more intuitive, but you can't just give it a
> > > > > different meaning from one day to another and break functionality.
> > > > 
> > > > Adding new values does not break functionality! No one  suggests to drop
> > > > existing set of values (sw, hw, etc.) - these are remaining. But
> > > > basically
> > > > suggestion is to extend allowed set to accept drm device specification
> > > > on
> > > > Linux, that's it. Honestly, I don't see problem here.
> > > > Some background story: hw,hw2,hw3 allows to select adapter for msdk
> > > > library on Windows, but they don't allow to do that on Linux. On Linux
> > > > all
> > > > these hw options are basically the same for the reason that device is
> > > > being
> > > > specified externally via SetHandle call. On Linux only sw/hw makes a
> > > > difference (other story that sw msdk library is not actually released
> > > > currently
> > > > on Linux). That's the origin of the request: we need a good way to
> > > > specify
> > > > adapter on Linux.
> > > 
> > > As mentioned, there are cases where both needs to be specified on Windows:
> > > hw, hw2, hw3,.. plus adapter number.
> > > 
> > > 'qsv_device' is for specifying adapter number on Windows and DRI on Linux
> > > 'hwaccel_device' is for specifying hw, hw2, hw3 (everywhere)
> > 
> > According to https://trac.ffmpeg.org/ticket/7649, -qsv_device was added to
> > workaround device selection on Linux.
> > 
> > On Windows, we should not use another option to specify the adapter number,
> > the
> > adapter is 1:1 mapped to the hw impl. I think we should fix it if the
> > current
> > QSV depends on -qsv_device on Window.
> > 
> > 
https://github.com/Intel-Media-SDK/MediaSDK/blob/master/samples/sample_decode/src/pipeline_decode.cpp#L245-L264
> > 
> > > 
> > > I see no reason to start mixing that and allowing to specify DRI via
> > > 'hwaccel_device' parameter.
> > > 
> > > That would make things just worse instead of improving anything.
> > 
> > From user's perspective, we may use the same device selection for both QSV
> > and
> > VAAPI on Linux. It is easy for user to move from QSV to VAAPI or inverse.
> > 
> 
> Which case want to mix the  QSV and VAAPI in one FFmpeg pipeline? Do
> you have a real case for this?
> 
> I know we used  VAAPI as decoder and QSV as encoder before when QSV
> decoder have some limitation in FFmpeg
> 
> But I think we are better to fix QSV decoder in FFmpeg part or MSDK,
> do you have any other case to mix VAAPI and QSV?

Sorry for misleading you. What I meant is to use VAAPI instead of QSV or
inverse. 

Thanks
Haihao


> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Rogozhkin, Dmitry V Sept. 3, 2020, 7:13 a.m. UTC | #10
On Thu, 2020-09-03 at 12:59 +0800, mypopy@gmail.com wrote:
> On Thu, Sep 3, 2020 at 9:21 AM Xiang, Haihao <haihao.xiang@intel.com>
> wrote:
> > 
> > On Wed, 2020-09-02 at 14:04 +0000, Soft Works wrote:
> > > > -----Original Message-----
> > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf
> > > > Of
> > > > Rogozhkin, Dmitry V
> > > > Sent: Wednesday, September 2, 2020 3:54 PM
> > > > To: ffmpeg-devel@ffmpeg.org
> > > > Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use
> > > > -hwaccel_device to
> > > > specify a device for VAAPI backend
> > > > 
> > > > On Wed, 2020-09-02 at 07:31 +0000, Soft Works wrote:
> > > > > > -----Original Message-----
> > > > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On
> > > > > > Behalf Of
> > > > > > Rogozhkin, Dmitry V
> > > > > > Sent: Wednesday, September 2, 2020 9:00 AM
> > > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > > Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use
> > > > > > -hwaccel_device
> > > > > > to specify a device for VAAPI backend
> > > > > > 
> > > > > > On Wed, 2020-09-02 at 04:28 +0000, Xiang, Haihao wrote:
> > > > > > > On Wed, 2020-09-02 at 04:20 +0000, Soft Works wrote:
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org>
> > > > > > > > > On
> > > > 
> > > > Behalf
> > > > > > 
> > > > > > Of
> > > > > > > > > Haihao Xiang
> > > > > > > > > Sent: Wednesday, September 2, 2020 6:01 AM
> > > > > > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > > > > > Cc: Haihao Xiang <haihao.xiang@intel.com>
> > > > > > > > > Subject: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use
> > > > > > > > > -hwaccel_device to specify a device for VAAPI backend
> > > > > > > > > 
> > > > > > > > > According to the FFmpeg documentation,
> > > > > > > > > -hwaccel_device can be
> > > > > > > > > used to select a device for hardware acceleration
> > > > > > > > > 
> > > > > > > > > Example:
> > > > > > > > > ffmpeg -hwaccel qsv -hwaccel_device
> > > > > > > > > /dev/dri/renderD129 -c:v
> > > > > > > > > h264_qsv \ -i
> > > > > > > > > in.h264 -c:v hevc_qsv out.h265
> > > > > > > > 
> > > > > > > > No. The docs say about hwaccel_device
> > > > > > > > 
> > > > > > > > It can either refer to an existing device created with
> > > > > > > > -init_hw_device by name,
> > > > > > > > 
> > > > > > > > => /dev/dri/renderD129 is not an existing device name
> > > > > > > > 
> > > > > > > > or it can create a new device as if ‘-init_hw_device’
> > > > > > > > type:hwaccel_device were called immediately before.
> > > > > > > > 
> > > > > > > > => /dev/dri/renderD129 is not a valid string for
> > > > > > > > init_hw_device
> > > > > > 
> > > > > > Well, it seems that's where documentation does not reflect
> > > > > > the
> > > > > > reality since (as pointed by Haihao below)
> > > > > > https://trac.ffmpeg.org/wiki/Hardware/VAAPI
> > > > > > is full of contradictory examples.
> > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Hence, the patch doesn't make sense.
> > > > > > > 
> > > > > > > in https://trac.ffmpeg.org/wiki/Hardware/VAAPI,
> > > > > > > 
> > > > > > > If only one stream is being used, -hwaccel_device can
> > > > > > > also accept
> > > > > > > a device path directly
> > > > > > > 
> > > > > > > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128
> > > > > > > -i ...
> > > > > > > 
> > > > > > > I think it can be applied to qsv too.
> > > > > > > 
> > > > > > 
> > > > > > I agree. Part of ffmpeg help:
> > > > > >     -hwaccel hwaccel name  use HW accelerated decoding
> > > > > >     -hwaccel_device devicename  select a device for HW
> > > > > > acceleration
> > > > > > 
> > > > > > To me specifying device via -hwaccel_device in the way it
> > > > > > is being
> > > > > > suggest in commit is pretty intuitive and is better than
> > > > > > explain
> > > > > > people that there is - qsv_device for that purpose.
> > > > > > Niceness of
> > > > > > -hwaccel_device is that it is not tight to particular
> > > > > > acceleration,
> > > > > > hence easier to work with for end users.
> > > > > 
> > > > > In case of QSV, the usage of hwaccel_device is already
> > > > > defined:
> > > > > 
> > > > > device selects a value in ‘MFX_IMPL_*’. Allowed values are:
> > > > > auto sw  hw  auto_any hw_any hw2 hw3 hw4
> > > > > 
> > > > > I agree that it would be more intuitive, but you can't just
> > > > > give it a
> > > > > different meaning from one day to another and break
> > > > > functionality.
> > > > 
> > > > Adding new values does not break functionality! No
> > > > one  suggests to drop
> > > > existing set of values (sw, hw, etc.) - these are remaining.
> > > > But basically
> > > > suggestion is to extend allowed set to accept drm device
> > > > specification on
> > > > Linux, that's it. Honestly, I don't see problem here.
> > > > Some background story: hw,hw2,hw3 allows to select adapter for
> > > > msdk
> > > > library on Windows, but they don't allow to do that on Linux.
> > > > On Linux all
> > > > these hw options are basically the same for the reason that
> > > > device is being
> > > > specified externally via SetHandle call. On Linux only sw/hw
> > > > makes a
> > > > difference (other story that sw msdk library is not actually
> > > > released
> > > > currently
> > > > on Linux). That's the origin of the request: we need a good way
> > > > to specify
> > > > adapter on Linux.
> > > 
> > > As mentioned, there are cases where both needs to be specified on
> > > Windows:
> > > hw, hw2, hw3,.. plus adapter number.
> > > 
> > > 'qsv_device' is for specifying adapter number on Windows and DRI
> > > on Linux
> > > 'hwaccel_device' is for specifying hw, hw2, hw3 (everywhere)
> > 
> > According to https://trac.ffmpeg.org/ticket/7649, -qsv_device was
> > added to
> > workaround device selection on Linux.
> > 
> > On Windows, we should not use another option to specify the adapter
> > number, the
> > adapter is 1:1 mapped to the hw impl. I think we should fix it if
> > the current
> > QSV depends on -qsv_device on Window.
> > 
> > https://github.com/Intel-Media-SDK/MediaSDK/blob/master/samples/sample_decode/src/pipeline_decode.cpp#L245-L264
> > 
> > > 
> > > I see no reason to start mixing that and allowing to specify DRI
> > > via
> > > 'hwaccel_device' parameter.
> > > 
> > > That would make things just worse instead of improving anything.
> > 
> > From user's perspective, we may use the same device selection for
> > both QSV and
> > VAAPI on Linux. It is easy for user to move from QSV to VAAPI or
> > inverse.
> > 
> 
> Which case want to mix the  QSV and VAAPI in one FFmpeg pipeline? Do
> you have a real case for this?
> 
> I know we used  VAAPI as decoder and QSV as encoder before when QSV
> decoder have some limitation in FFmpeg
> 
> But I think we are better to fix QSV decoder in FFmpeg part or MSDK,
> do you have any other case to mix VAAPI and QSV?

MSDK on Linux requires VAAPI device (same as on Windows it requires DX9
or DX11). For this reason VAAPI device can be used to initialized QSV
device in ffmpeg. So, this is not necessarily mixing QSV and VAAPI
components in the pipeline (though should be possible, not talking why
though), but just a way to initialize QSV device...

> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Mark Thompson Sept. 6, 2020, 6:01 p.m. UTC | #11
On 03/09/2020 05:59, mypopy@gmail.com wrote:
> On Thu, Sep 3, 2020 at 9:21 AM Xiang, Haihao <haihao.xiang@intel.com> wrote:
>> On Wed, 2020-09-02 at 14:04 +0000, Soft Works wrote:
>>>> -----Original Message-----
>>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
>>>> Rogozhkin, Dmitry V
>>>> Sent: Wednesday, September 2, 2020 3:54 PM
>>>> To: ffmpeg-devel@ffmpeg.org
>>>> Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device to
>>>> specify a device for VAAPI backend
>>>>
>>>> On Wed, 2020-09-02 at 07:31 +0000, Soft Works wrote:
>>>>>> -----Original Message-----
>>>>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
>>>>>> Rogozhkin, Dmitry V
>>>>>> Sent: Wednesday, September 2, 2020 9:00 AM
>>>>>> To: ffmpeg-devel@ffmpeg.org
>>>>>> Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device
>>>>>> to specify a device for VAAPI backend
>>>>>>
>>>>>> On Wed, 2020-09-02 at 04:28 +0000, Xiang, Haihao wrote:
>>>>>>> On Wed, 2020-09-02 at 04:20 +0000, Soft Works wrote:
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On
>>>>
>>>> Behalf
>>>>>>
>>>>>> Of
>>>>>>>>> Haihao Xiang
>>>>>>>>> Sent: Wednesday, September 2, 2020 6:01 AM
>>>>>>>>> To: ffmpeg-devel@ffmpeg.org
>>>>>>>>> Cc: Haihao Xiang <haihao.xiang@intel.com>
>>>>>>>>> Subject: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use
>>>>>>>>> -hwaccel_device to specify a device for VAAPI backend
>>>>>>>>>
>>>>>>>>> According to the FFmpeg documentation, -hwaccel_device can be
>>>>>>>>> used to select a device for hardware acceleration
>>>>>>>>>
>>>>>>>>> Example:
>>>>>>>>> ffmpeg -hwaccel qsv -hwaccel_device /dev/dri/renderD129 -c:v
>>>>>>>>> h264_qsv \ -i
>>>>>>>>> in.h264 -c:v hevc_qsv out.h265
>>>>>>>>
>>>>>>>> No. The docs say about hwaccel_device
>>>>>>>>
>>>>>>>> It can either refer to an existing device created with
>>>>>>>> -init_hw_device by name,
>>>>>>>>
>>>>>>>> => /dev/dri/renderD129 is not an existing device name
>>>>>>>>
>>>>>>>> or it can create a new device as if ‘-init_hw_device’
>>>>>>>> type:hwaccel_device were called immediately before.
>>>>>>>>
>>>>>>>> => /dev/dri/renderD129 is not a valid string for init_hw_device
>>>>>>
>>>>>> Well, it seems that's where documentation does not reflect the
>>>>>> reality since (as pointed by Haihao below)
>>>>>> https://trac.ffmpeg.org/wiki/Hardware/VAAPI
>>>>>> is full of contradictory examples.
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hence, the patch doesn't make sense.
>>>>>>>
>>>>>>> in https://trac.ffmpeg.org/wiki/Hardware/VAAPI,
>>>>>>>
>>>>>>> If only one stream is being used, -hwaccel_device can also accept
>>>>>>> a device path directly
>>>>>>>
>>>>>>> ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i ...
>>>>>>>
>>>>>>> I think it can be applied to qsv too.
>>>>>>>
>>>>>>
>>>>>> I agree. Part of ffmpeg help:
>>>>>>      -hwaccel hwaccel name  use HW accelerated decoding
>>>>>>      -hwaccel_device devicename  select a device for HW acceleration
>>>>>>
>>>>>> To me specifying device via -hwaccel_device in the way it is being
>>>>>> suggest in commit is pretty intuitive and is better than explain
>>>>>> people that there is - qsv_device for that purpose. Niceness of
>>>>>> -hwaccel_device is that it is not tight to particular acceleration,
>>>>>> hence easier to work with for end users.
>>>>>
>>>>> In case of QSV, the usage of hwaccel_device is already defined:
>>>>>
>>>>> device selects a value in ‘MFX_IMPL_*’. Allowed values are:
>>>>> auto sw  hw  auto_any hw_any hw2 hw3 hw4
>>>>>
>>>>> I agree that it would be more intuitive, but you can't just give it a
>>>>> different meaning from one day to another and break functionality.
>>>>
>>>> Adding new values does not break functionality! No one  suggests to drop
>>>> existing set of values (sw, hw, etc.) - these are remaining. But basically
>>>> suggestion is to extend allowed set to accept drm device specification on
>>>> Linux, that's it. Honestly, I don't see problem here.
>>>> Some background story: hw,hw2,hw3 allows to select adapter for msdk
>>>> library on Windows, but they don't allow to do that on Linux. On Linux all
>>>> these hw options are basically the same for the reason that device is being
>>>> specified externally via SetHandle call. On Linux only sw/hw makes a
>>>> difference (other story that sw msdk library is not actually released
>>>> currently
>>>> on Linux). That's the origin of the request: we need a good way to specify
>>>> adapter on Linux.
>>>
>>> As mentioned, there are cases where both needs to be specified on Windows:
>>> hw, hw2, hw3,.. plus adapter number.
>>>
>>> 'qsv_device' is for specifying adapter number on Windows and DRI on Linux
>>> 'hwaccel_device' is for specifying hw, hw2, hw3 (everywhere)
>>
>> According to https://trac.ffmpeg.org/ticket/7649, -qsv_device was added to
>> workaround device selection on Linux.
>>
>> On Windows, we should not use another option to specify the adapter number, the
>> adapter is 1:1 mapped to the hw impl. I think we should fix it if the current
>> QSV depends on -qsv_device on Window.
>>
>> https://github.com/Intel-Media-SDK/MediaSDK/blob/master/samples/sample_decode/src/pipeline_decode.cpp#L245-L264
>>
>>>
>>> I see no reason to start mixing that and allowing to specify DRI via
>>> 'hwaccel_device' parameter.
>>>
>>> That would make things just worse instead of improving anything.
>>
>>  From user's perspective, we may use the same device selection for both QSV and
>> VAAPI on Linux. It is easy for user to move from QSV to VAAPI or inverse.
>>
> Which case want to mix the  QSV and VAAPI in one FFmpeg pipeline? Do
> you have a real case for this?
> 
> I know we used  VAAPI as decoder and QSV as encoder before when QSV
> decoder have some limitation in FFmpeg
> 
> But I think we are better to fix QSV decoder in FFmpeg part or MSDK,
> do you have any other case to mix VAAPI and QSV?

Benefits of internal accelerated decoder:
- No need to find determine specific codec and support separately.
- Automatic software fallback for incomplete hardware implementations (like H.264 10-bit).
- Common metadata handling (HDR, 3D, closed captions, timecodes, ...).
- Decode-only setup does not change based on the device manufacturer.

Benefits of external offload decoder:
- Slightly easier command lines for fixed simple cases.
- Per-device ad-hoc tuning can be applied elsewhere, in a way that would be hard inside libavcodec (e.g. of decoder output delay for maximising single-stream throughput).

IMO the first set of benefits are more valuable to most users.

- Mark
diff mbox series

Patch

diff --git a/fftools/ffmpeg_qsv.c b/fftools/ffmpeg_qsv.c
index 960c88b69d..b7e7ab0e53 100644
--- a/fftools/ffmpeg_qsv.c
+++ b/fftools/ffmpeg_qsv.c
@@ -55,6 +55,14 @@  static int qsv_device_init(InputStream *ist)
             return err;
     }
 
+#if CONFIG_VAAPI
+    else if (ist->hwaccel_device && !strncmp(ist->hwaccel_device, "/dev/dri/", 9)) {
+        err = av_dict_set(&dict, "child_device", ist->hwaccel_device, 0);
+        if (err < 0)
+            return err;
+    }
+#endif
+
     err = av_hwdevice_ctx_create(&hw_device_ctx, AV_HWDEVICE_TYPE_QSV,
                                  ist->hwaccel_device, dict, 0);
     if (err < 0) {