[Bug 794544] rtpbuffer: expose gst_rtp_buffer_initialize_header function

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=794544

--- Comment #8 from Mathieu Duponchelle <mduponchelle1 at gmail.com> ---
(In reply to Olivier Crête from comment #7)
> (In reply to Mathieu Duponchelle from comment #4)
> > The use case for this is:
> > 
> > alawenc ! rtppcmapay , where the payloader provides a buffer pool, creating
> > buffers with gst_buffer_new_allocate , with a single memory, then setting
> > the memory offset to header_len, which means the encoder will write right
> > after the header and no allocation of GstMemory will occur at gst_buffer_map
> > time, gst_rtp_buffer_new_allocate doesn't really work for this.
> 
> I don't understand why it doesn't work? You can do
> gst_buffer_new_allocate(payload_len), then do
> gst_buffer_resize(offset=header_len), and then if the buffer comes back as
> expected, then you can just size it back?

Just checked again, this might work, but this would make the implementation of
the pool in pcmapay more complicated, as there is actually no memory layout
requirement for "RTP buffers" I figure this API is valid and helpful :)

> 
> Are you planning to do this in GstRTPBaseAudioPayload ?
> 

I don't know, this is only really valid for formats with fixed payload sizes,
such as PCMA, I figure we could start with PCMA then put that upper in the
class hierarchy once we have a better idea of how to make something more
generic.

> 
> (In reply to Sebastian Dröge (slomo) from comment #6)
> > (In reply to Olivier Crête from comment #3)
> > > As we required to header to be in only one memory block, the header layout
> > > is fixed.
> > 
> > I also thought this first but it's not true fortunately.
> 
> In which case is it not true?

Take a look at gst_rtp_buffer_map, it does not actually require a specific
memory layout :)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.