tweak: speedup SRTP transport

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



SRTP is a _generic_ module that needs to handle audio and video from
many sources and the upper layers hands over a buffer pointer and the 
length of the payload. If you decrease the encoder output size,
the encoder would forward the payload length IMHO, not the length of
the buffer.

SRTP does not know if the buffer it gets has space to append the 
authentication code. Even if you decrease the encoder output size: 
how could the SRTP module know this and that the encoder left some space
after the payload that it can use? Also, depending on the negotiated
SRTP setting, the authentication code may differ in length.

SRTP is the nearly the last step before the data hits the wire, upper
layers usually do not now or don't care if SRTP is active or not, thus
they allocate buffers according to their requirements only and not 
taking lower layer requirements into account.


Werner


Am 16.05.2014 07:34, schrieb Eeri Kask:
> On Thu, 15 May 2014 08:33:50 +0200, Werner Dittmann wrote:
> 
>> I have not looked into the code in detail. However, the SRTP protect
>> usually appends some data to the exisiting buffer: the authentication
>> code. Thus it is usually necessary to copy the incoming data into
>> a bigger buffer to have room to add the authentication code.
> 
> 
> Then the solution is to decrease the encoder output buffer accordingly,
> which PJSIP also seems to do ('enc_mtu' in pjmedia_vid_codec_param).  :-)
> 
> (In time-critical use cases only a signal processing step justifies a
> buffer copy which is then part of a transform like where a pixel at
> location 'i' depends on neighbouring pixel values at 'i+/-j'; e.g.
> scaling, denoising, etc.  Smart video encoders include image scaling
> from capture size to transport size (decoders scale from transport right
> into render canvas) and some denoising algorithms.)
> 
> (Though image processing steps are best accomplished at capture or
> render level, not man-in-the-middle in-transit.)
> 
>     Eeri Kask
> 
> 
>> Am 14.05.2014 16:35, schrieb Eeri Kask:
>>> Hello,
>>>
>>> it looks like SRTP-transport (pjmedia/src/pjmedia/transport_srtp.c)
>>> copies the whole outgoing communication (video+audio) in RAM from
>>> location A to B without any easily apparent purpose; e.g. for video this
>>> is cir 32 Kbyte/sec traffic if ffmpeg-encoder bitrate is set to 256Kbit.
>>>  Is it feasible to avoid this overhead?
>>>
>>> (In contrast, incoming communication is not copied, "srtp_unprotect()"
>>> operates directly on packet-buffer 'pkt'.)
>>>
>>>     Eeri Kask
> 
> 
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
> 
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
> 

-- 
Werner Dittmann
email: Werner.Dittmann at t-online.de
cell:  +49 173 44 37 659
PGP key: 82EF5E8B



[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux