[Live-devel] Encrypting rtp stream

[Jeff Shanab]

I have experimented with a few ideas for buffer mgmnt in live555,
Admittedly mostly as a client not a server.

New GetNextFrame implementations.
  Pass in a ref to a vector and let it resize and fill in the data member.
Worked well, not sure how efficient.
  Pass in a pointer to a struct that has void* and size and instead of
truncating, realloc and update struct. .
     I added an argument defaulted to null so that it could be used both
ways.
     With plain C style we can get away with this as long as we don't cross
the dll boundary. He who allocates must deallocate.
  Aquire from pool, use ref counting, resize if no other choice and let ref
count trigger return to pool.
  Use a buffer container of fixed size pages that are pooled. container is
only a list of pointers, this allows inserting before, but not located
contiguously so poorer performance.

  Somewhere I once saw an interesting "trick" that I thought might work for
a buffer mgmnt if you know the amount you are going to insert up front.
  Similar/in conjunction with a pointer to a struct, Macros were used to
access metadata about the buffer. The buffer was allocated as size+struct
size and address + struct size is returned as the start of the buffer.
Becasue of this the raw pointer to the area to write the data, it can be
passed without changing intermediate classes. Only at the two ends do you
use the macro's to reference the raw pointer - the size of the added
metadata struct to use the new functionality, ref-count, pool pointer,
capacity, current size.

  In one case, and I liked this, I passed a pointer to a buffer class cast
to void* in the GetNextFrame
  Then I dynamic_cast back to the class and if it succeeds I know I have a
smart client calling GetNextFrame so I can call the classes interface
  ...
    size_t size = {number calculated in ->use()}
    void* buffer = nullptr;
    buffer = GetBuffer(size);

   if (buffer)
       memcpy from reorderbuffer into client buffer
 ...

I do realize that in modern computers, the locality of the data is a
critical indicator in the copy performance, so tricks can be used to take
advantage of that.

Hey Ross. I don't think I ever asked, what is your stance on someone
forking live555 for some of these non-standard requests.







On Fri, Feb 22, 2019 at 4:36 PM Ross Finlayson <finlayson at live555.com>
wrote:

>
>
> >  That being said, isn't the extra copy unavoidable?
>
> Obviously a RTP packet payload needs to be ‘copied’ (read through) in
> order to be encrypted.  What I was referring to was the fact that - given
> our current buffer implementation - we currently need to make an extra copy
> to add a SRTP authentication header.
>
> In any case, as I’ve noted before, LIVE555 does not, and will not, support
> encryption, because RTSP 1.0 does not support encryption.  So this issue is
> moot.
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20190222/fc8ca042/attachment.html>