GNOME Bugzilla – Bug 326875
[0.11] Define meaning of GST_FLOW_RESEND or drop it
Last modified: 2011-12-06 13:26:40 UTC
This new functionality has not yet been implemented to Gstqueue element, but it might be useful in some cases. I'm attaching patch that adds the functionality for resending the buffer if next element requests that.
Created attachment 57291 [details] [review] Patch for gstqueue element where GST_FLOW_RESEND is handled.
There's 2 problems with this patch: 1) Copying the buffer is completely wrong - that will copy the data too, which is a huge unecessary overhead especially (for example) for HD video frames, each of which is several megabytes. 2) Noone except Wim seems to know what he intended GST_FLOW_RESEND for, and I'm not sure it means Queue should just push it again. CC'ing wim for comment.
> 1) Copying the buffer is completely wrong - that will copy the data too, which > is a huge unecessary overhead especially (for example) for HD video frames, > each of which is several megabytes. The copy operation is done, because in case the next element alters the data that buffer contains. If it then requests same buffer again, it gets the original data. Are there any specific rule in this case, can element alter the buffer data and then request resending the buffer? If not, then it's quite small change to drop the copy operation from the queue patch. > 2) Noone except Wim seems to know what he intended GST_FLOW_RESEND for, and > I'm not sure it means Queue should just push it again. For our understanding, this is the case. But let's hear Wim's comments.
It's sufficient to hold a reference to a buffer to ensure that noone else modifies it - before an element modifies any buffer that it didn't create, the element needs to check gst_buffer_is_writable, or call gst_buffer_make_writable. gst_buffer_is_writable is FALSE whenever the refcount is > 1 (or when the data pointer is read-only), ie when the caller isn't the sole owner of the buffer data. So, either way, the unconditional buffer copy can and should be avoided.
I originally envisioned _RESEND in the case where you have a PAUSED videoscale ! videosink and you resize the video window. The prerolled frame would be returned to the videoscale with a _RESEND return value, videoscale would resend the buffer after resizing it to the new size (which it then gets from alloc_buffer).
Is this bug still valid then? Should queue handle _RESEND somehow?
Change target milestone to 0.11.x
Dropped in 0.11