On Tue, 23 Jan 2018 05:28:35 +0000 "Li, Zhong" <[email protected]> wrote:
> > 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?). > > If you check qsvdec.c, av_parser_parse2() is called. That is one thing > different from cuvid. > > 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.) > > Yes, basically speaking, cuvid vs nvdec is similar as qsv vs dxva2/vaapi. > For linux, I am open to vaapi and planning do some contribution on this. > But I think it should be another topic. > Using software parser (i.e. av_parser_parse2()) for qsvdec seems can't bring > too much advantage compared with using MSDK API, though it is stable for some > codecs since it is existed a while. Even if you call the parser, you have to duplicate the functionality of the native decoder by adding glue code, and it will always lag behind it. Not to mention things like transparent fallback to software or other hwaccels, and the fact that everything will get parsed at least twice. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
