<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div bgcolor="#CCCCCC" text="#000000"><blockquote cite="mid:B0F818F8-F7AE-44D1-9C0F-AD1A464EC3A0@live555.com" type="cite"><div>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.</div>
<div><br>
</div>
<div><br>
</div>
</blockquote>
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</div></blockquote><div><br></div>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.</div><div><br></div><div>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.</div><div><br></div><div><br><blockquote type="cite"><div bgcolor="#CCCCCC" text="#000000">So myFramedSource will be responsible for passing individual nals up
to the DiscreteFramer, via deliverFrame</div></blockquote><div><br></div>Yes.</div><div><br></div><div><br><blockquote type="cite"><div bgcolor="#CCCCCC" text="#000000">, 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)</div></blockquote><div><br></div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><blockquote type="cite"><div bgcolor="#CCCCCC" text="#000000">
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?<br></div></blockquote><div><br></div>No; it deals only with NAL units.</div><br><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Ross Finlayson<br>Live Networks, Inc.<br><a href="http://www.live555.com/">http://www.live555.com/</a></span></span>
</div>
<br></body></html>