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
