[Bug 766184] Video distortion with VAAPI when using tee element

[GStreamer (GNOME Bugzilla)]

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

--- Comment #11 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
(In reply to Scott D Phillips from comment #10)
> (In reply to Nicolas Dufresne (stormer) from comment #9)
> > Review of attachment 329719 [details] [review] [review]:
> > 
> > No, not this way. The video meta being an extension, element that uses this
> > pool without video meta will now do the wrong thing. In correct
> > implementation of decide allocation, the meta should have been enabled if
> > possible, and the set_config should just keep failing if not supported.
> 
> If I'm understanding, this patch has the right behavior for set_config but
> you're saying decide_allocation should then notice that the video meta
> option got added, which isn't supported in its final query and then fail, is
> that right? The buffer pool code in patch 2 is similar to how v4l2's pool
> set_config works if I'm reading the code there right, specifically:
> 
> https://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/
> ?id=ba32cf10f3e8898f3700979796f8886852dd0b7f
> 
> Or do I have that wrong? Maybe it would be better to realize that the meta
> will be required earlier and put it in the caps instead of handling it with
> the allocation query?

It's a good point, still I'm wondering if this was right or not. In the end the
negotiation works if you check that the returned config is compatible with what
you support. With options like VideoMeta (which you must support if enabled)
it's tricky, because if you don't support video meta, you can't check if it's
present or not. My patch on v4l2 is probably breaking the case where an
upstream element receive that pool, but don't support video meta.

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