I hope to revamp LIVE555’s buffering mechanism someday - but not for free. It
is part of the “funded project” that includes IPv6 support:
http://live555.com/funded-projects/live555_ipv6.html
> Hey Ross. I don't think I ever asked, what is your stance on someone forking
> live555 for some of t
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 v
> 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
authe
On Feb 22, 2019, at 8:46 AM, Kevin Bailey wrote:
>
> My plan was to just add a layer ontop of live555 like libsodium to handle my
> encryption.
There’s more to security protocol design than just blindly running everything
through AES-128.
Cisco’s released an SRTP implementation on GitHub unde
I promise I won't feel entitled to any sort of encryption with RTSP. Like I
said I'll implement it manually with libsodium. That being said, isn't the
extra copy unavoidable? It seems that before any h264 NAL unit is passed to
RTP, it first needs to be encrypted and have some sort of authentication
> I suspect Ross wouldn’t immediately turn down an implementation of SRTP, if
> one were offered under a suitable license.
Actually, I have already implemented SRTP; I use this in our WebRTC demo.
However, I won’t be releasing this - at least, not right now - because:
1/ It's inefficient, requi
My plan was to just add a layer ontop of live555 like libsodium to handle
my encryption. They also have options for handling dropped packets,
something UDP is very susceptible to.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live5
On Feb 21, 2019, at 4:42 PM, Kevin Bailey wrote:
>
> the amount of data being encrypted needs to match the amount of data received
> on the client end. Or at the very least the number of packets going out and
> coming in need to be the same. I found that neither is the case.
I believe you’re t
> What is the best way to actually encrypt my h264 stream with live555?
Using SRTP. However, we do not support SRTP, because its use has not been
defined (standardized) for RTSP 1.0. (It has been defined for RTSP 2.0, but
almost nobody - including us - implements that.)
Sorry.
Ross Finlay
I am trying to encrypt my h264 packets sent with live555 using a pretty
basic stream cipher. One of the main requirements of a stream cipher is
that after a portion of a key is consumed to encrypt a bit of data that
portion can never be used again. So because of this the amount of data
being encryp
10 matches
Mail list logo
