<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=iso-8859-2">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
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.<br>
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.<br>
<br>
This is the log I'm seeing:<br>
<br>
0:00:13.489419481 1060 0x1ec5150 DEBUG rtpL16depay
gstrtpL16depay.c:243:gst_rtp_L16_depay_process:<rtpl16depay0>
got payload of 192 bytes<br>
0:00:13.489596481 1060 0x1ec5150 LOG GST_BUFFER
gstbuffer.c:798:gst_buffer_new: new 0x75c05370<br>
0:00:13.489760981 1060 0x1ec5150 LOG GST_BUFFER
gstbuffer.c:2038:gst_buffer_copy_region: new region copy 0x75c05370
of 0x75c054b0 12-192<br>
0:00:13.490969772 1060 0x1ec5150 LOG GST_BUFFER
gstbuffer.c:514:gst_buffer_copy_into: copy 0x75c054b0 to 0x75c05370,
offset 12-192/204<br>
--<br>
0:00:13.493352979 1060 0x1ec5150 TRACE GST_LOCKING
gstminiobject.c:177:gst_mini_object_lock: lock 0x1ecb690: state
00020000, access_mode 3<br>
0:00:13.493546312 1060 0x1ec5150 DEBUG GST_LOCKING
gstminiobject.c:212:gst_mini_object_lock: lock failed 0x1ecb690:
state 00020000, access_mode 3<br>
0:00:13.493717020 1060 0x1ec5150 DEBUG GST_MEMORY
gstmemory.c:317<b>:gst_memory_map</b>: mem 0x1ecb690:<b> lock 3
failed</b><br>
0:00:13.493910270 1060 0x1ec5150 TRACE GST_REFCOUNTING
gstobject.c:249:gst_object_ref:<allocatorsysmem0> 0x1ddc010
ref 6->7<br>
0:00:13.494091270 1060 0x1ec5150 DEBUG GST_MEMORY
gstmemory.c:138:gst_memory_init: <b>new memory</b> 0x1ecb578,
maxsize:195 offset:0 <b>size:192</b><br>
0:00:13.494364978 1060 0x1ec5150 DEBUG GST_PERFORMANCE
gstallocator.c:462:<b>_sysmem_copy: memcpy 192</b> memory 0x1ecb690
-> 0x1ecb578<br>
<br>
<br>
And this is the command:<br>
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 <br>
2>&1 | grep -B 5 copy<br>
<br>
It happens in gst_audio_buffer_reorder_channels() when mapping the
buffer read-write.<br>
Why is the buffer read-only? It doesn't really matter what the
source is, the same happens with udpsrc.<br>
<br>
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.<br>
<br>
Any light shed onto this is appreciated.<br>
<br>
Thanks<br>
Petr<br>
</body>
</html>