rtpL16depay failing to do depay in place
Petr Kulhavy
brain at jikos.cz
Mon Oct 31 14:32:20 UTC 2016
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.
This is the log I'm seeing:
0:00:13.489419481 1060 0x1ec5150 DEBUG rtpL16depay
gstrtpL16depay.c:243:gst_rtp_L16_depay_process:<rtpl16depay0> got
payload of 192 bytes
0:00:13.489596481 1060 0x1ec5150 LOG GST_BUFFER
gstbuffer.c:798:gst_buffer_new: new 0x75c05370
0:00:13.489760981 1060 0x1ec5150 LOG GST_BUFFER
gstbuffer.c:2038:gst_buffer_copy_region: new region copy 0x75c05370 of
0x75c054b0 12-192
0:00:13.490969772 1060 0x1ec5150 LOG GST_BUFFER
gstbuffer.c:514:gst_buffer_copy_into: copy 0x75c054b0 to 0x75c05370,
offset 12-192/204
--
0:00:13.493352979 1060 0x1ec5150 TRACE GST_LOCKING
gstminiobject.c:177:gst_mini_object_lock: lock 0x1ecb690: state
00020000, access_mode 3
0:00:13.493546312 1060 0x1ec5150 DEBUG GST_LOCKING
gstminiobject.c:212:gst_mini_object_lock: lock failed 0x1ecb690: state
00020000, access_mode 3
0:00:13.493717020 1060 0x1ec5150 DEBUG GST_MEMORY
gstmemory.c:317*:gst_memory_map*: mem 0x1ecb690:*lock 3 failed*
0:00:13.493910270 1060 0x1ec5150 TRACE GST_REFCOUNTING
gstobject.c:249:gst_object_ref:<allocatorsysmem0> 0x1ddc010 ref 6->7
0:00:13.494091270 1060 0x1ec5150 DEBUG GST_MEMORY
gstmemory.c:138:gst_memory_init: *new memory* 0x1ecb578, maxsize:195
offset:0 *size:192*
0:00:13.494364978 1060 0x1ec5150 DEBUG GST_PERFORMANCE
gstallocator.c:462:*_sysmem_copy: memcpy 192* memory 0x1ecb690 -> 0x1ecb578
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.
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.
Any light shed onto this is appreciated.
Thanks
Petr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20161031/2ae9c0b3/attachment.html>
More information about the gstreamer-devel
mailing list