[Bug 773833] New: rtpL16depay and rtpL24depay failing to do depay in place

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 773833
           Summary: rtpL16depay and rtpL24depay failing to do depay in
                    place
    Classification: Platform
           Product: GStreamer
           Version: 1.9.90
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: brain at jikos.cz
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

It seems that rtpL16depay, rtpL24depay (and I guess also other rtp-depay
functions) are failing to depayload in place. It always allocates a new buffer
and copies the payload.

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. It doesn't really matter what the source is, the same happens with
udpsrc.

--

The other thing here is that if the channels don't require reordering (like in
my case) the buffer shouldn't be remapped read-write. Otherwise the potential
buffer copy is redundant.

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