[Bug 794544] rtpbuffer: expose gst_rtp_buffer_initialize_header function

[GStreamer (GNOME Bugzilla)]

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

--- Comment #10 from Mathieu Duponchelle <mduponchelle1 at gmail.com> ---
(In reply to Olivier Crête from comment #9)
> GstRTPBaseAudioPayload is for formats where the payload is a multiple of a
> fixed size, so it's exactly for this! Anything with variable bitrates can't
> use it anyway.

Heh, I didn't know that, nice, then we can probably put the optimization there
direcly, it will however require more testing on my end, I kind of don't want
to break all the subclasses except pcma :)

> 
> > > (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 :)
> 
> from the comments in gst_rtp_buffer_map
> 
> /* the header must be completely in the first buffer */
> 
> But this comment is from 0.10, it shoudl actually be all in the first
> memory. The extensions should all be in the same block or in just one more
> block.
> 
> /* all extension bytes must be in this block */
> 
> The layout of the dats is indeed not fixed, but that doesn't really matter
> for the GstRtpBuffer* functionis as they only operate on the header.

Yes, there are indeed *some* constraints, we could maybe enforce that in the
initialize_header function by simply requiring the buffer to have a single
memory, what do you think?

I'll attach the pcma pool WIP patch here for reference

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