[Live-devel] using live555 with in memory data

[Ross Finlayson]

>> Nonetheless, small NAL units are still a good idea, because they reduce the effect of network packet loss.  It's always a good idea, for example, to break large 'I-frame' NAL units into multiple slices; they just don't need to be as small as a standard MTU (1500 bytes), because our software will take care of fragmenting them if they happen to be larger.
>> 
>> 
> As I was originally reading warnings from your framework in regards to my passing of oversized NALs (or at least, of large NALs that were encompassing an entire frame), and in anticipation that the software will be used in packet lossy environments,  I figured that I'd try to keep their size to a minimum.  Being new to both of these domains makes it hard to ask the right questions, so I guess I will try this, are there large nals that can be split by your software, for whom losing a slice does not result in the loss of the whole frame

No, assuming that by "loss of the whole frame", you meant to say "loss of the whole NAL unit (slice)".  Whenever a NAL unit exceeds the network MTU, it will be split (by our software, in accordance with the IETF RTP packet format for H.264) into multiple outgoing RTP packets.  However, if any one of these RTP packets is lost, then the whole NAL unit will be lost.

OTOH, presumably there is some cost/overhead involved in generating very small NAL units.  So, your decision will be to choose NAL unit (slice) sizes that are reasonably small, but not so small as to involve unreasonable overhead.


> So myFramedSource will be responsible for passing individual nals up to the DiscreteFramer, via deliverFrame

Yes.


> , but currently, after my encode call, I have quite a few nals that I need to send over.  I either need to call the triggerEvent function successively after loading each nal into the input memory location (which sounds like the wrong thing to do)

No, that's exactly the right thing to do.  The call to "triggerEvent()" simply informs the LIVE555 thread's event loop that there's a new event to be handled.

If course, you need to be aware that the LIVE555 thread will be executing the "deliverFrame()" function soon afterwards (to grab and deliver the data), so you need to make sure that any data structures that are shared by this function and your encoding thread (i.e., the thread that calls "triggerEvent()") are locked appropriately.


> Also, I'm not expecting the nals that I pass into live555 to represent full frames, does this change the suitability of the DiscreteFramer for this task?

No; it deals only with NAL units.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131008/71010c30/attachment.html>