[gstreamer-bugs] [Bug 590669] [API] need GstByteWriter or GstChunkWriter

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=590669
  GStreamer | gstreamer (core) | git

--- Comment #4 from Sebastian Dröge <slomo at circular-chaos.org> 2009-10-03 12:34:12 UTC ---
(In reply to comment #3)
> Nice, thanks for implementing this.
> 
> Random unconsidered comments/questions:
> 
>  - would it make sense for GstByteWriter to derive from GstByteReader, so that
> writers can also go back and read things, or is that not really needed?

I don't think that's needed, usually you should know what you're writing :)

>  - would be nice to allow for the byte writer structure to be stack allocated
> as well

Right, I'll add that

>  - would be nice to allow for a fixed-size mode where the caller passes in a
> chunk of pre-allocated memory; the byte writer wouldn't be able to grow then of
> course, but since the functions already return TRUE/FALSE anyway, that should
> be easy to add

Ok, I'll add that too. A gst_byte_reader_new_fixed_size() would make sense in
that regard too.

>  - would it be more efficient to maintain current/end pointers so that you
> don't have to do start+current_pos for each write? (Does it matter? Do we care?
> Was just wondering the same thing about the byte reader the other day)

I don't know :)

>  - one could merge gst_byte_writer_take_data() and gst_byte_writer_free()
> g_string_free()-style (ie. with a do_free boolean and a return value). Not sure
> if it's prettier or more desirable, just mentioning it for completeness. It
> takes care of the fact that the byte writer will be unusable (or empty again)
> after using _take_data(), so avoids misunderstandings (Arguably, that should be
> kind of obvious though, so isn't really an issue)
>
>  - _to_buffer() should be renamed/changed so that it's clearer what happens
> with the byte writer data IMHO. Maybe it should be _take_data_as_buffer()?
> (Unless we decide to go for byte_writer_free(),
> byte_writer_free_and_take_data(), and _free_and_take_buffer() or so).

I guess I'll go with _free(), _free_and_take_data() and _free_and_take_buffer()
then.

>  - how do we best use this when writing something like ASF or quicktime headers
> or RIFF chunks (or even the binary registry)? Ie. where we want to write chunks
> and nest them. Rely on higher API that then uses GstByteWriter? Or would it
> make sense to embed this somehow? (Not sure how or what would be needed, mabe a
> parent_chunk pointer or some such, and a hook to update the parent_chunk when a
> child chunk is finalised). So I guess the question is if we want to cater for
> this: if we do, then another layer of indirection might be needed (so that e.g.
> instead of growing the current writer you in fact grow and write to the memory
> allocation of the parent_chunk or somesuch).

Could you give a real example how this API should look like and what exactly it
should do and how it would be used? :)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.