rtpL16depay failing to do depay in place

[Sebastian Dröge]

On Mon, 2016-10-31 at 15:32 +0100, Petr Kulhavy wrote:
> Hi,
> 
> it seems that rtpL16depay (and I guess also other rtp-depay
> functions) is failing to depayload in place. It allways allocates a
> new buffer and copies the payload.
> Before opening a bugtracking entry I'm trying to understand why. I
> don't see anything that should prevent to use the buffer in place.
> 
> [...]
> 
> And this is the command:
> GST_DEBUG=9 gst-launch-1.0 audiotestsrc is-live=true wave=silence
> samplesperbuffer=48 ! "audio/x-
> raw,format=(string)S16BE,rate=(int)48000,channels=(int)2,channel-
> mask=(int)0x3" ! rtpL16pay ! rtpL16depay ! fakesink 
> 2>&1 | grep -B 5 copy
> 
> It happens in gst_audio_buffer_reorder_channels() when mapping the
> buffer read-write.
> Why is the buffer read-only? It doesn't really matter what the source
> is, the same happens with udpsrc.

It's read-only because something else still has a reference to it. At
least the RTP buffer has (of which the payload buffer is a
"subbuffer"). Changing this would require to get rid of the RTP buffer
reference before trying to map the payload buffer writeable.

This should get a bug report, but see below

> The other thing here is that in my particular case the channels don't
> have to be reordered at all so the memcpy is completely redundant.

That part should be relatively easy to fix. Can you file a bug (one for
both issues here), ideally with a patch for this part at least?

https://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gst-plugins-good

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20161102/7229346d/attachment.sig>