rtpL16depay failing to do depay in place

Petr Kulhavy brain at jikos.cz
Wed Nov 2 14:46:40 UTC 2016


Hi Sebastian,

thank you for your reply. Bug created: 
https://bugzilla.gnome.org/show_bug.cgi?id=773833

I'm not sure what is the prefered way to fix the second part.
Ideally the remap read-write would be moved into 
gst_audio_buffer_reorder_channels(), but that might break some existing 
API/ABI ?
Otherwise this change has to be done in every affected depay...

Cheers
Petr


On 02/11/16 08:54, Sebastian Dröge wrote:
> 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
>




More information about the gstreamer-devel mailing list