On Mon, 22 Jan 2018 14:52:00 +0100 wm4 <[email protected]> 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.) _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
