[Gstreamer-bugs] [Bug 108297] Changed - repeat field for GstBuffer

[bugzilla-daemon at widget.gnome.org]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=108297

Changed by in7y118 at public.uni-hamburg.de.

--- shadow/108297	Thu Mar 13 08:57:28 2003
+++ shadow/108297.tmp.26381	Fri Mar 14 12:00:32 2003
@@ -29,6 +29,38 @@
 field as it is. An MPEG encoder, on the other hand, would process the frame
 N times (since the MPEG structure mostly doesn't allow for this type of
 behaviour, unless we're using I-frame only MPEG).
 
 Anyway, lots of text, the idea is simple: can we please get a repeat field
 in GstBuffer?
+
+------- Additional Comments From in7y118 at public.uni-hamburg.de  2003-03-14 12:00 -------
+We talked about this, but I'll present my reasons against it, which 
+are mostly maintenance/understandability reasons.
+1. increased complexity
+Buffers are a core structure of GStreamer and should as such be kept 
+as simple as possible. People learning about buffers should easily 
+understand it and the code handling buffers should not be too complex.
+2. little gain
+The only advantage of such a change would be increased performance. 
+While performance increases are a nice thing to have, I think we 
+shouldn't implement it before we are stable.
+3. handling of this feature
+The only workable long-term solution would be for every plugin to 
+check if it has to duplicate a buffer, which is lots of code and 
+overhead in lots of plugins. The solution of "let the scheduler do 
+this job" doesn't appeal to me either, because schedulers are hard 
+enough as it is and they should not care about the data they pass.
+4. significant work
+It's lots of time to implement this correctly everywhere, since it's 
+quite a big change.
+
+Proposed solution in the video case:
+In IRC the suggestion was to set the timestamp accordingly on the 
+next sent frame, so every plugin can detect if a frame was dropped 
+and react accordingly. Additionally it could be possible to specify a 
+caps property "constant framerate" wo indicate that this element 
+needs a constant framerate.
+
+So it should be possible to tackle this problem without changes to 
+GstBuffer but with better specifying the mimetype(s) "video/*".
+And it'd be still lots of work to do.