[Bug 790752] msdk: supports bufferpool

[GStreamer (GNOME Bugzilla)]

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

--- Comment #105 from Hyunjun Ko <zzoon at igalia.com> ---
(In reply to sreerenj from comment #99)
> (In reply to Hyunjun Ko from comment #96)
> > (In reply to sreerenj from comment #93)
> > > Review of attachment 368118 [details] [review] [review] [review]:
> > > 
> > > Assume we have vpp.
> > > 
> > > How about the pipeline: msdkh264dec ! msdkvpp ! textoverlay ! msdkvpp".
> > > 
> > > Here is decoder is supposed to create a child session, but it won't I
> > > believe. WDT?
> > 
> > As per my undestanding, the decoder in this pipeline doesn't need to join
> > the session from vpp but just share it, does it?
> 
> The decoder tries to find a context from downstream first. right?
> So it could be receiving a context from downstream (2nd vpp) element.

Right.

> Please correct me if I am wrong, Only one dec, enc & vpp are allowed in a
> single session. So, the decoder and first vpp should join the session by
> creating its own child.

Yes, it's correct and then only vpp1 created a child context with joined
session by this patch. So you're saying that decoder should do the same as
vpp1?
I'm not sure about it.

> 
> > But for vpps in this pipeline, seems it should create its own session
> > seperately because there is an element that should be using system memory
> > while the patch doesn't do that.
> 
> textoverlay will try to map, and we do the vaDeriveImgae internally.
> Is there anything to do with session sharing here?

Ah sorry. Forget about this comment plz. I was confused with other thing.

> 
> > 
> > Can we think about this kind of complexed pipelines later or we should
> > handle this in this thread too?
> 
> This is something related to the fundamental design. I don't want to
> re-write the whole thing when we add VPP. So just trying to make sure that
> we understand the possible use cases :)
> If you think it can handle the complex pipelines with this approach then it
> is more than enough for now. Implementation can be done later of course
> (after the release of 1.14).

Yeah, current way is so simple and I don't belive it can handle all cases.
Let's see what happens.

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