<div dir="ltr"><div>I have experimented with a few ideas for buffer mgmnt in live555, Admittedly mostly as a client not a server. <br></div><div><br></div><div>New GetNextFrame implementations.<br></div><div> Pass in a ref to a vector and let it resize and fill in the data member. Worked well, not sure how efficient.<br></div><div> Pass in a pointer to a struct that has void* and size and instead of truncating, realloc and update struct. .</div><div> I added an argument defaulted to null so that it could be used both ways. <br></div><div> 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.<br></div><div> Aquire from pool, use ref counting, resize if no other choice and let ref count trigger return to pool.</div><div> 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.</div><div> <br></div><div> 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. <br></div><div> 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.</div><div><br></div><div> In one case, and I liked this, I passed a pointer to a buffer class cast to void* in the GetNextFrame <br></div><div> 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</div><div> ...<br></div><div> size_t size = {number calculated in ->use()}</div><div> void* buffer = nullptr;<br></div><div> buffer = GetBuffer(size); <br></div><div><br></div><div> if (buffer) <br></div><div> memcpy from reorderbuffer into client buffer</div><div> ...</div><div><br></div><div>
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.
</div><div> </div><div>Hey Ross. I don't think I ever asked, what is your stance on someone forking live555 for some of these non-standard requests.<br></div><div></div><div> <br></div><div> <br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 22, 2019 at 4:36 PM Ross Finlayson <<a href="mailto:finlayson@live555.com">finlayson@live555.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> That being said, isn't the extra copy unavoidable?<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
Ross Finlayson<br>
Live Networks, Inc.<br>
<a href="http://www.live555.com/" rel="noreferrer" target="_blank">http://www.live555.com/</a><br>
<br>
<br>
_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com" target="_blank">live-devel@lists.live555.com</a><br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" rel="noreferrer" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
</blockquote></div>