[gst-devel] fixing Gstbuffer

[vishnu at pobox.com]

On Thu, Sep 27, 2001 at 01:08:13PM -0700, Erik Walthinsen wrote:
> On Thu, 27 Sep 2001 vishnu at pobox.com wrote:
> > Attached is a perl script which renames GST_BUFFER_DATA & GST_BUFFER_SIZE.
> > The new inline static prototypes are:
> >
> >   void   gst_buffer_set_data (GstBuffer *, gpointer, size_t);
> >   char * gst_buffer_get_data (GstBuffer *);
> >   size_t gst_buffer_get_size (GstBuffer *);
> >
> > The diff is about 182k, so i won't include it here.
> 
> I still fail to see what this gains us.  These functions must be defined
> 'extern inline' in gstbuffer.h for them to be actually inlined in every
> use so we get the benefits of inline.

Yes, exactly.  This enforces more strictness and discipline in
buffer usage without any optimized performance penalty.

> Why will this help solve problems with buffer usage in elements?  What
> problems have you seen, anyway?

Oh, just trying to compile the converted code will show up bogosities.
For example:

@@ -275,11 +275,9 @@ gst_ffmpegenc_chain_audio (GstPad *pad, 
     memcpy (ffmpegenc->buffer + ffmpegenc->buffer_pos, data, frame_size - ffmpegenc->buffer_pos);
 
     outbuf = gst_buffer_new ();
-    GST_BUFFER_SIZE (outbuf) = frame_size;
-    GST_BUFFER_DATA (outbuf) = g_malloc (frame_size);
-
-    GST_BUFFER_SIZE (outbuf) = avcodec_encode_audio (ffmpegenc->context, GST_BUFFER_DATA (outbuf),
-  				GST_BUFFER_SIZE (outbuf), (const short *)ffmpegenc->buffer);
+    gst_buffer_get_size (outbuf) = frame_size;
+    gst_buffer_set_data (outbuf, g_malloc (frame_size), avcodec_encode_audio (ffmpegenc->context, gst_buffer_get_data (outbuf),
+  				gst_buffer_get_size (outbuf), (const short *)ffmpegenc->buffer));
 
     gst_pad_push (ffmpegenc->srcpad, outbuf);
 
> Setting data and size simultaneously is possible in some cases, but not in
> others.

Another API can be added, if it is really necessary to set them
separately.  i want to trying setting them together because
it seems like setting one without the other could be a bug.
So i want that to break the compile during conversion for a
closer examination.

>  There are also performance considerations:
> 
>   buf = gst_buffer_new();
>   data = malloc(size);
>   /* fill data into data */
>   gst_buffer_set_data(buf,data,size);
> 
> That will end up copying the data pointer around, whereas:
> 
>   buf = gst_buffer_new();
>   GST_BUFFER_DATA(buf) = malloc(size);
>   /* fill data into GST_BUFFER_DATA(buf) */
>   GST_BUFFER_SIZE(buf) = size;
> 
> ..is more efficient in that it will actually let the compiler be optimal.
> Granted, that's small potatoes, but I always think in these terms <g>

Uh, i fail to see any difference.  i posted assembly output yesterday
proving that inline & macros produce exactly the same code.  Now it's
your turn to prove me wrong with a real example.  Pseudo code doesn't
cut it.

> Please provide examples (code) where the element "does it wrong" and
> explain what the set_data() function would look like and what advantages
> it would provide.

i'm already explained it enough times: safer code with no optimized
performance penalty.

-- 
Victory to the Divine Mother!!
  http://sahajayoga.org