[libav-devel] qsv: How about replace software parsers with MFXVideoDECODE_DecodeHeader
nfxjfg at googlemail.com
Mon Jan 22 14:57:45 CET 2018
On Mon, 22 Jan 2018 14:52:00 +0100
wm4 <nfxjfg at googlemail.com> wrote:
> > Appreciated for any comment. If we are agree with that, patches will be sent soon (about following next two weeks).
> I don't know how qsvdec works in particular (doesn't it pretty much
> parse all the codec stream in MFX?). But if you look how it went for
> cuvid vs. nvdec, using as much parsing functionality from libavcodec as
> possible is superior.
> Cuvid/nvdec are nvidia's decoder wrappers as they are named in FFmpeg.
> (They don't necessarily match with the naming nvidia itself uses.) Cuvid
> is a "full stream" decoder, which lets nvidia's software parse the full
> stream. nvdec is a hwaccel, using nvidia's low level API on top of
> libavcodec's own decoders, and which gets only slices
Sorry, accidentally hit sent. Here's the rest:
... nvdec is a hwaccel, using nvidia's low level API on top of
libavcodec's own decoders, and which gets only slices plus some
metadata. nvdec is actually pretty much like the dxva2/d3d11va API.
When I tried cuvid vs. nvdec myself, I found nvdec superior, because it
integrated so much better into libavcodec. It supported parsing all the
metadata libavcodec did, it avoided some weird nvidia (or cuvid
wrapper) issues, and it was faster, because it used libavcodec's native
data flow instead of having to go over weird FIFOs. Also, nvdec is
essentially feature complete (except missing deinterlacing), while
cuvid still misses exporting some metadata. With cuvid we'd be busy
adding support to export new types of metadata every time, while nvdec
simply benefits from development of the native libavcodec decoders.
I get that Intel devs probably prefer qsvdec over dxva2/vaapi/etc.
because they develop libmfx, but for libavcodec the hwaccel approach
will always be superior.
(I.e. basically what Mark said.)
More information about the libav-devel