[Bug 762509] vaapidecoder: h264: decoder stores too many pictures in the DPB before output

[GStreamer (GNOME Bugzilla)]

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

--- Comment #39 from Matt Staples <staples255 at gmail.com> ---
(In reply to Víctor Manuel Jáquez Leal from comment #38)
> Review of attachment 353187 [details] [review]:
> 
> Overall the proposal, from my point of view, is bit convoluted. I guess it
> can be done simpler by just installing properties, with a function pointer
> in decoders map structure, at class_init()
> 
> ::: gst-libs/gst/vaapi/gstvaapiencoder_h264.c
> @@ +2164,2 @@
>    guint num_roi;
> +#endif
> 
That's what I initially thought too.  I ran into several problems though:

First, the various decoder classes derive from GstVaapiMiniObject instead of
GObject, so the normal property registration scheme doesn't work for them.

Second, the decoder object doesn't get constructed when the GstVaapiDecode is
constructed.  Instead, that's delayed until caps are negotiated.  Also, the
decoders class_init isn't called until the first object is created. 

So if properties were installed in the h264 decoder's class_init, then they
wouldn't be available to gst-inspect or gst-launch.  That's why I added the
decoder-specific install_props function.

A related problem is that gst-launch will set properties before the pipeline is
linked together and playing. Hence the addition of the GstVaapiDecoderProps
class.  That allows codec-specific properties to get configured before the
runtime caps negotiation that eventually creates the codec-specific Decoder
object.  When the Decoder object is created, the 'props' object gets passed to
its constructor to initialize it.

So it's definitely more involved than I had originally envisioned, but I
couldn't think of anything simpler that would work with the existing design. 
I'm totally open to suggestions though.


> This changeset is unrelated with the purpose of the patch.

Yes, I wasn't sure of the procedure for thaat. This, and two other bugs (732265
and 732266) need to add codec-specific properties, but there's no framework in
place to support that yet.  Maybe a new bug (feature request) should be opened,
and all three bugs could reference that as a dependency?  Then this last patch
could be moved there to keep this thread focused on the original bug?

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