GNOME Bugzilla – Bug 742619
videodecoder: Should not renegotiate at start of finish_frame()
Last modified: 2018-11-03 11:33:59 UTC
It has always been this way, there is obvious way to workaround it, but it make very little sense to reconfigure on finish frame. On finish frame, it is too late to negotiate the allocation. In fact, this case only get triggered when we are already configured and may cause more arm then good. In most cases, the frame holds a buffer allocated from the previously negotiated pool. The old pool cannot be stopped or reconfigured, since it has outstanding buffers. I think we should drop this check. If there is a video decoder not using one of: gst_video_decoder_allocate_output_buffer() gst_video_decoder_allocate_output_frame() gst_video_decoder_negotiate () It should most likely call gst_video_decoder_negotiate() (if it can renegotiate). Any known decoder triggers this case ? If so, do it work well ?
Probably we should add a gst_video_decoder_maybe_negotiate(); that does basically what the checks in the finish and allocate functions do.
It probably makes sense to move the renegotiation at the end of finish_frame(). That way we would be renegotiated afterwards and could make use of that information immediately when the next frame arrives. IIRC it is in finish_frame() to ensure that we are also renegotiated before the next allocate_buffer() call. As allocate_buffer() might also be too late.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/152.