Opened 4 years ago
Last modified 2 years ago
#8076 new defect
QSV HW Context types mismach
|Reported by:||fortman||Owned by:|
|Blocking:||Reproduced by developer:||no|
|Analyzed by developer:||no|
Summary of the bug:
When reviewing the conde of the QSV HW Context I discovered a mismatch between the "handle_types" and "supported_handle_types". These variables are used to defined the surfaces for the context: D3D11, D3D9, VAAPI, etc.
However, the values are defined multiple times, instead of just one time:
- libavcodec/qsv.c: handle_types https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/qsv.c#L625
- libavfilter/qsvvpp.c: handle_types https://github.com/FFmpeg/FFmpeg/blob/e62f625163f8cde794ebe02bc228735b4e65c772/libavfilter/qsvvpp.c#L71
- libavfilter/vf_scale_qsv.c: handle_types https://github.com/FFmpeg/FFmpeg/blob/dd662bbdd26e09957b3e67d3cde07b9468931e15/libavfilter/vf_scale_qsv.c#L271
- libavfilter/vf_deinterlace_qsv.c: handle_types https://github.com/FFmpeg/FFmpeg/blob/165eabf19bf21d235e1b5254314ba2ba5c627454/libavfilter/vf_deinterlace_qsv.c#L164
- libavutil/hwcontext_qsv.c: supported_handle_types https://github.com/FFmpeg/FFmpeg/blob/b3b7523feb5acbe1a3376104616fca389e1aaeca/libavutil/hwcontext_qsv.c#L92
As a consequence, when for example a new surface is created in Windows, the surface selected is D3D9, instead of D3D11. But when some other filter creates a context with a D3D11 surface and this surface is passed to the QSV HW Context, the surface is used without any problem.
So I request to refactor the code and eliminate the multiple declarations. And then to initialize first to D3D11 surfaces in Windows.
Change History (3)
comment:1 by , 4 years ago
comment:2 by , 2 years ago
if you use command line, the handler for enc, dec and vpp are got from the same session. This session is stored in device_ctx which is shared by enc, dec and vpp, so the handler should be the same.
comment:3 by , 2 years ago