Re: [FFmpeg-devel] [PATCH 00/24] Generic hardware device setup and miscellaneous related merges

2017-06-14 Thread Mark Thompson 
On 13/06/17 13:07, wm4 wrote:
> On Mon, 12 Jun 2017 23:40:17 +0100
> Mark Thompson  wrote:
> 
>> This merges a set of stuff from libav to do with hardware codecs/processing.
> 
> All patches LGTM. I don't think it makes sense to delay pushing those
> either.

Set applied (with some fixups from Michael).

Thanks,

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 00/24] Generic hardware device setup and miscellaneous related merges

2017-06-13 Thread James Almer 
On 6/12/2017 7:40 PM, Mark Thompson wrote:
> This merges a set of stuff from libav to do with hardware codecs/processing.
> 
> The two most interesting features of this are:
> 
> * Generic hardware device setup.  This finishes the uniform structure for 
> hardware device setup which has been in progress for a while, finally 
> deleting several of the ffmpeg_X.c hardware specific files.  Initially this 
> is working for VAAPI and VDPAU, with partial support for QSV.  A following 
> series by wm4 (start from 
> )
>  will add DXVA2/D3D11 support as well.
> 
> * Mapping between hardware APIs.  Initially this supports VAAPI/DXVA2 and 
> QSV, OpenCL integration with those is to follow.  The main use of this at the 
> moment to to allow use of the lavc decoder via a platform hwaccel and hence 
> avoid the nastiness of the specific  *_qsv decoders (for example: "./ffmpeg_g 
> -y -hwaccel vaapi -hwaccel_output_format vaapi -i in.mp4 -an -vf 
> 'hwmap=derive_device=qsv,format=qsv' -c:v h264_qsv -b 5M -maxrate 5M 
> -look_ahead 0 out.mp4", and similarly with DXVA2).
> 
> Other oddments:
> * Support for the VAAPI driver which wraps VDPAU.
> * Field rate output for the VAAPI deinterlacer.
> * hw_device_ctx support for QSV codecs using software frames (fixes some 
> current silly failure cases when using multiple independent instances 
> together).
> * Profile mismatch option for hwaccels (primarily to allow hardware decoding 
> of H.264 constrained baseline profile streams which erroneously fail to set 
> constraint_set1_flag).
> * Documentation for the hardware frame movement filters (hwupload, 
> hwdownload, hwmap).
> 
> VP9 VAAPI encode support would be here, but is not included because it 
> depends on the vp9_raw_reorder BSF, which is only written with the bitstream 
> API rather than with get_bits.  I know that was skipped earlier, but has 
> there been any more discussion on merging that?  Would it be easiest to just 
> convert the BSF?

It will be easier to just convert the BSF to use get_bits for now.
As mentioned in the thread where the new bitstream reader was skipped,
until it's confirmed there are no considerable regressions in speed on
some modules then we're not going to merge it.
In this case it should be a simple search & replace.

BitstreamContext -> GetBitContext
bitstream_read -> get_bits (Since all of them read <= 25 bits)
bitstream_read_bit -> get_bits1
bitstream_init8 -> init_get_bits8
etc.

> 
> Thanks,
> 
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 00/24] Generic hardware device setup and miscellaneous related merges

2017-06-13 Thread wm4 
On Mon, 12 Jun 2017 23:40:17 +0100
Mark Thompson  wrote:

> This merges a set of stuff from libav to do with hardware codecs/processing.

All patches LGTM. I don't think it makes sense to delay pushing those
either.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 00/24] Generic hardware device setup and miscellaneous related merges

2017-06-12 Thread Mark Thompson 
This merges a set of stuff from libav to do with hardware codecs/processing.

The two most interesting features of this are:

* Generic hardware device setup.  This finishes the uniform structure for 
hardware device setup which has been in progress for a while, finally deleting 
several of the ffmpeg_X.c hardware specific files.  Initially this is working 
for VAAPI and VDPAU, with partial support for QSV.  A following series by wm4 
(start from 
)
 will add DXVA2/D3D11 support as well.

* Mapping between hardware APIs.  Initially this supports VAAPI/DXVA2 and QSV, 
OpenCL integration with those is to follow.  The main use of this at the moment 
to to allow use of the lavc decoder via a platform hwaccel and hence avoid the 
nastiness of the specific  *_qsv decoders (for example: "./ffmpeg_g -y -hwaccel 
vaapi -hwaccel_output_format vaapi -i in.mp4 -an -vf 
'hwmap=derive_device=qsv,format=qsv' -c:v h264_qsv -b 5M -maxrate 5M 
-look_ahead 0 out.mp4", and similarly with DXVA2).

Other oddments:
* Support for the VAAPI driver which wraps VDPAU.
* Field rate output for the VAAPI deinterlacer.
* hw_device_ctx support for QSV codecs using software frames (fixes some 
current silly failure cases when using multiple independent instances together).
* Profile mismatch option for hwaccels (primarily to allow hardware decoding of 
H.264 constrained baseline profile streams which erroneously fail to set 
constraint_set1_flag).
* Documentation for the hardware frame movement filters (hwupload, hwdownload, 
hwmap).

VP9 VAAPI encode support would be here, but is not included because it depends 
on the vp9_raw_reorder BSF, which is only written with the bitstream API rather 
than with get_bits.  I know that was skipped earlier, but has there been any 
more discussion on merging that?  Would it be easiest to just convert the BSF?

Thanks,

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel