[Bug 790752] msdk: supports bufferpool

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Tue Dec 12 03:05:39 UTC 2017


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

--- Comment #51 from Hyunjun Ko <zzoon at igalia.com> ---
(In reply to sreerenj from comment #50)
> @Hynjun: I just want to clarify a few things.
> 
> IIUC, you are trying to get all buffer pools stuffs implemented with system
> memory first, right?

Right

> I am a bit afraid that there could be rewrite needed in
> the way we treating memory create/map/unmap once there is VIDEO_MEMORY
> support.

This is also what I'm worried about since I'm still not an expert of msdk.

> But honestly, I am not a pro in msdk, so could be mistaken too. :)
> 
> We need to consider a number of things for designing the buffer pool.
> Mainly,
> 
> 1: It requires vasurface & vaimage handling (gstreamer-vaapi code in a
> simplified way if possible) for VIDEO_MEMORY support.

Right.

> 
> 2: Tasks can be submitted together if they share contexts (joined sessions).
> 

Not sure about this. If you mean mfxThreadTask and XXXFrameSubmit, this is for
mfx plugin writer iiuc. Are these necessary to be considered in gstreamer?


> 3. There is a third memory type called "opaque memory". We might not need
> this for our use cases though.

Since you mentioned this in the last meeting, I looked into mfx opaque memory.
Basically it doesn't fit gstreamer design imho. 
But I guess we could use this memory in the current encoder sicne vpp feature
landed in encoder. (Using opaque surface in VPP output and encoder input)

Anyway, why don't we focus on handling SYSTEM/VIDEO memory first?

> 
> Just wondering what could be the best way to proceed here.
> 
> Option 1: Just focus on system memory in this bug and implement all pool
> sharing between decoder+vpp+encoder. Later we can do/discuss(rewrite needed
> most probably) all video memory stuffs in a separate bug.
> 
> Option2: Discuss all features (videomory, task session sharing, and dmabuf
> support too) as a part of this bug itself and do all development in a
> separate branch before pushing to master.

I'd choose the number 2 since handling video memory by gstbufferpool was
original goal of this issue actually. I can work on my github branch.

What do you (and others) think?

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


More information about the gstreamer-bugs mailing list