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 > <https://git.libav.org/?p=libav.git;a=commit;h=fff90422d181744cd75dbf011687ee7095f02875>) > 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
