On Fri, 26 Jan 2018 15:15:05 +0000 "Li, Zhong" <zhong...@intel.com> wrote:
> > From: libav-devel [mailto:libav-devel-boun...@libav.org] On Behalf Of Luca > > Barbato > > Sent: Tuesday, January 23, 2018 5:42 PM > > To: libav-devel@libav.org > > Subject: Re: [libav-devel] qsv: How about replace software parsers with > > MFXVideoDECODE_DecodeHeader > > > > On 22/01/2018 12:20, Li, Zhong wrote: > > > MSDK provides an API (MFXVideoDECODE_DecodeHeader) to parse video > > > parameters. Currently it hasn't been used. Instead, software parsers > > > are used. It works well for h264 decoder, and basically works well for > > > hevc decoder (some issues found by Mayxm due to width/height are > > > unaligned, I also found some hevc clips without setting profile can be > > > decoded by software but qsv failed) . More issues found on other > > > decoders such as VP8. The decoding conformance pass rate is low and > > > looks like it is due to some missing/incompatible header information > > > is passed to qsv decoder (though Mark provides a patch 182cf17 but > > > still something is missing). Similar issues happens on MJPEG decoding > > > which I am going to add. Maybe we can continue to work on software > > > parsers for qsv, but I believe replace software parser with > > > MFXVideoDECODE_DecodeHeader is a better choice: > > > > > > 1. It can remove the dependence on various software parsers, and > > > just need a unified interface for all codes. > > > > > > 2. It will be very easy to add new decoder such as MJPEG > > > decoding support without any software parser patches. > > > > > > 3. MFXVideoDECODE_DecodeHeader is used by MSDK sample > > decoder > > > (i.e: sample_decode), so it is reliable for MSDK decoder. (As my test, > > > it can effectively improve decoding conformance pass rate, especially > > > for vp8 decoding.) > > > > > > 4. CUVID decoder is using CUVID parser instead of software > > > parser, maybe qsv can align with it. > > > > No it is not, in Libav the CUVID support is implemented as hwaccel1, so it > > leverages the software decoder for the parsing and a little more. > > > > In my opinion it boils down to either have a uniform behavior in parsing and > > formatting the input with its many quirks or using more of the hwaccel/sdk. > > > > I do not have a strong opinion in this regard. > > > > lu > > Thank you all for the comments! > Currently I am inclined to keep current libavcodec parser (i.e; just like > wm4's suggested using as much libavcodec parsing functionality as possible). I didn't really suggest that, though. Sure, using the libavcodec parsers is a step up, but I was arguing that ideal behavior is only possible with a hwaccel approach, where libavcodec's built in decoders handle everything but actual slice decoding. _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
