[FFmpeg-devel] [PATCH] libavcodec/qsvenc_hevc: correction for QSV HEVC default plugin selection on Windows
zhong.li at intel.com
Thu Dec 6 07:21:46 EET 2018
> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf
> Of Landgraph
> Sent: Thursday, December 6, 2018 4:23 AM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc_hevc: correction for
> QSV HEVC default plugin selection on Windows
> Hi All,
> This is my first commit to ffmpeg, what should I do to merge it?
> Do we have any reasons to not merge this?
Will apply if nobody against now.
> 23.10.2018 10:14, Li, Zhong пишет:
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On
> >> Of Maxym Dmytrychenko
> >> Sent: Sunday, October 14, 2018 3:36 AM
> >> To: ffmpeg-devel at ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc_hevc:
> >> correction for QSV HEVC default plugin selection on Windows
> >> On Sat, Oct 13, 2018 at 6:43 PM Mark Thompson <sw at jkqxz.net> wrote:
> >>> On 06/10/18 07:21, Landgraph wrote:
> >>>> 1. Old logic meaned: everywhere, except Windows, ffmpeg has to use
> >>>> HW
> >>> acceleration, but on Windows ffmpeg has to use (unavailable)
> >>> software encode by default
> >>>> 2. Software encode is available only if you provide corresponding
> >>> software MediaSDK library, which isn't provided with ffmpeg. More
> >>> information could be found in
> >> e
> >>> adme-encode_linux.pdf
> >>>> 3. HW encode is available on Windows in the driver by default
> >>> This has been proposed before - I can't find the original discussion
> >>> (maybe it was on IRC), but I did find <
> >>> The reason for not doing it is that a subset of the Intel drivers
> >>> segfault immediately when the hardware plugin is loaded on some
> >>> platforms. That's a pain for anyone wanting to support diverse
> >>> systems, so the decision was to continue to load the sw plugin by
> >>> default so it doesn't crash (even if the software plugin isn't
> >>> present), and leave the non-default case as the crashing one so the
> >>> user
> >> has to do something to trigger it.
> >>> If you can characterise either the set of platforms it crashes on or
> >>> a set of platforms it definitely works on then maybe we could
> >>> conditionally change the default behaviour?
> >>> - Mark
> >> it was 2 years old discussion and with early drivers (we even had
> >> this development a bit ahead of general driver availability) now it
> >> should be working on most of the platforms - I would suggest to make a
> positive side.
> > Basically, HEVC HW encoding should be the default case if HW platform
> can support.
> > If crashed with some specified drivers, thus should be a driver issue instead
> of hiding it in ffmpeg level.
> > So, I agree with Maxym and the patch LGTM.
> > (Of course, if we can verified on the platforms which was crashed as
> > two years ago, that should be fine. However, IMHO this is not MUST. If
> > it is still crash, reporting a bug to the driver developer should be
> > the right way.)
More information about the ffmpeg-devel