[Bug 790752] msdk: supports bufferpool

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=790752

--- Comment #89 from sreerenj <bsreerenj at gmail.com> ---
(In reply to Hyunjun Ko from comment #84)
> (In reply to sreerenj from comment #77)
> > Review of attachment 368112 [details] [review] [review]:
> > 
> > ::: sys/msdk/gstmsdkallocator_libva.c
> > @@ +65,3 @@
> > +              MFX_MEMTYPE_VIDEO_MEMORY_PROCESSOR_TARGET)))
> > +    return MFX_ERR_UNSUPPORTED;
> > +
> > 
> > I am bit confused here. Could you please add some comments?
> > 
> > 1: Consider the pipeline: "videotestsrc ! msdkh264enc ", is it supposed to
> > fail (in won't in practice)? I am wondering why msdk has added
> > MFX_MEMTYPE_VIDEO_MEMORY_DECODER_TARGET into the req->type even if there is
> > no decoder in the pipeline! 
> 
> I'm not sure either, to be honest. :) 
> But I guess MFX_MEMTYPE_VIDEO_MEMORY_DECODER_TARGET is for both encoder and
> decoder, MFX_MEMTYPE_VIDEO_MEMORY_PROCESSOR_TARGET is for VPP, otherwise
> MFX_MEMTYPE_SYSTEM_MEMORY.
> 
> Regarding this, the document says that "The VA API does not define any
> surface types and the application can use either
> MFX_MEMTYPE_VIDEO_MEMORY_DECODER_TARGET or
> MFX_MEMTYPE_VIDEO_MEMORY_PROCESSOR_TARGET to indicate data in video memory."
> 
> I'll comment this out.
> 
> 
> > 
> > 2: According to my testing there is too much memory (number of surfaces)
> > allocation for a simple transcode pipeline (mfxh264dec async-depth=1 !
> > mfxh264enc async-depth=1).
> > You can test with the video.mp4 which I have sent recently :), It is
> > allocating 20+ surfaces (without counting the internal allocation)
> > 
> 
> That's normal if using video memory especially for h264/5 decoding (not
> encoding). I don't know why the driver requires that many surfaces.
> 

Strange!, We should compare with msdk sample applications.

I have a guess,  we don't do the "DecodeHeader" before querying for required IO
surface, instead, we just fill the mfxVideoParam manually and there could a
possibility that we are not providing all the information needed. But it is
fine for now, We can fix this later (both decoder and encoder require a bunch
of fixes I believe). Would be nice to file a bug to keep track of this.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.