GNOME Bugzilla – Bug 793008
buffer: add GST_BUFFER_FLAG_NON_DROPPABLE
Last modified: 2018-01-31 12:35:25 UTC
This can be used to identify buffers that should not be dropped when reducing bandwidth, or for which a higher percentage of redundancy should be allocated when performing forward error correction.
Created attachment 367581 [details] [review] gstbuffer: add GST_BUFFER_FLAG_IMPORTANT
This is pretty vague. Do you have some upstream code going to use that, and if so how is that going to be used ?
(In reply to Nicolas Dufresne (stormer) from comment #2) > This is pretty vague. Do you have some upstream code going to use that, and > if so how is that going to be used ? Yes, please see the blocked bug (https://bugzilla.gnome.org/show_bug.cgi?id=792696)
It's still quite vague, why is this being generalized instead of just adding an RTP/FEC specific flag (or a name that is more descriptive) ? I'd like to understand how this flag is generally meaningful, how it should be interpreted, what's the boundary for it's usage.
This is also needed for another use case (dvd still frames), see bug #685279. Now the question is, what to call it! (I apologise). FLAG_IMPORTANT FLAG_NOT_DROPPABLE FLAG_DO_NOT_DROP I think I have a slight preference towards something like the last two because it's clearer what the meaning/implication is, and there's also a nice symmetry with FLAG_DROPPABLE then.
> It's still quite vague, why is this being generalized instead of just adding > an RTP/FEC specific flag (or a name that is more descriptive) ? I'd like to > understand how this flag is generally meaningful, how it should be > interpreted, what's the boundary for it's usage. Olivier suggested this should be a general flag in core instead of RTP specific flags, and re-use the existing DROPPABLE flag. And it's useful for another case as well, see previous comment.
I missed that dicussion. I like Tim's proposal to maintain a symmetry with the DROPPABLE flag, it's more precise. Is UNDROPPABLE a word ? Would GST_BUFFER_FLAG_KEEP be an option, or maybe I'm missing the sense ? I really think that "IMPORTANT" is not quite right.
As usual, naming stuff is hard :) I would go for NON_DROPPABLE to keep the symmetry, though "undroppable" exists on wiktionary it doesn't ring nice to my ears, apologies for the bike shedding but I didn't start it :P
I think we almost have a winner. Jan - which one sounds best to you? (NOT_DROPPABLE, NON_DROPPABLE, UNDROPPABLE)
NON_DROPPABLE gets my vote too
Created attachment 367644 [details] [review] gstbuffer: add GST_BUFFER_FLAG_NON_DROPPABLE This can be used to identify buffers that should not be dropped when reducing bandwidth, or for which a higher percentage of redundancy should be allocated when performing forward error correction.
Comment on attachment 367644 [details] [review] gstbuffer: add GST_BUFFER_FLAG_NON_DROPPABLE >This can be used to identify buffers that should not be dropped >when reducing bandwidth, or for which a higher percentage of >redundancy should be allocated when performing forward error >correction. I don't really understand the reference to 'when reducing bandwidth'. The phrase comes from the DROPPABLE flag description I guess, I just don't know if it needs to be kept around. >diff --git a/common b/common >index 3fa2c9e37..3f4aa969c 160000 >--- a/common >+++ b/common >@@ -1 +1 @@ >-Subproject commit 3fa2c9e372bceec30be91e67fb02b6cb05bed493 >+Subproject commit 3f4aa969cbe39584a649d98d4cf321d78bd73092 common submodule commit should be removed. >+ * @GST_BUFFER_FLAG_NON_DROPPABLE: the buffer can not be dropped without breaking the >+ * stream, for example to reduce bandwidth. I would remove the "for example to reduce bandwidth" bit here. How about "This buffer is important and should not be dropped. This can be used to mark important buffers, e.g. to flag RTP packets carrying keyframes or codec setup data for RTP Forward Error Correction purposes, or to prevent still video frames from being dropped by elements due to QoS." Or is this too much detail? Also let's add a "(Since: 1.14)" at the end of the description line. Lastly, should we move up the @NON_DROPPABLE in the docs chunk to be next to the DROPPABLE one? In any case, I think this is good to go in.
Created attachment 367649 [details] [review] gstbuffer: add GST_BUFFER_FLAG_NON_DROPPABLE This can be used to identify buffers for which a higher percentage of redundancy should be allocated when performing forward error correction, or to prevent still video frames from being dropped by elements due to QoS.
(In reply to Tim-Philipp Müller from comment #12) > I don't really understand the reference to 'when reducing bandwidth'. The > phrase comes from the DROPPABLE flag description I guess, I just don't know > if it needs to be kept around. Yep, that was just copy pasted > common submodule commit should be removed. my bad > Or is this too much detail? I don't think it's too much detail, giving examples is always useful > Lastly, should we move up the @NON_DROPPABLE in the docs chunk to be next to > the DROPPABLE one? I usually keep the same order for the fields and their documentation, don't really have a preference, just tell me if you do prefer doing it that way :)
Attachment 367649 [details] pushed as ebcdfd2 - gstbuffer: add GST_BUFFER_FLAG_NON_DROPPABLE