<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#CCCCCC" text="#000000">
Ross,<br>
<br>
Thank you for your detailed response! I have responded inline.<br>
<br>
<div class="moz-cite-prefix">On 10/8/13 3:11 PM, Ross Finlayson
wrote:<br>
</div>
<blockquote
cite="mid:B0F818F8-F7AE-44D1-9C0F-AD1A464EC3A0@live555.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>You don't have to do that. The LIVE555 code automatically
takes care of fragmenting large NAL units into appropriate-sized
RTP packets.</div>
<div><br>
</div>
<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, in addition to other large nals for which the opposite is
true? I've just naively reduced the size of all nals because I
didn't know any better.<br>
<blockquote
cite="mid:B0F818F8-F7AE-44D1-9C0F-AD1A464EC3A0@live555.com"
type="cite">The "ByteStreamMemoryBufferSource" (sic) class is used
to implement a memory buffer that acts like a file - i.e., with
bytes that are read from it sequentially, until it reaches its
end. You could, in theory, use this to implement your H.264
streaming, feeding it into a "H264VideoStreamFramer" (i.e., in
your "createNewStreamSource()" implementation). However, the fact
that the buffer is a fixed size is a problem. If you haven't
created all of your NAL units in advance, then that's a problem.
You could instead just use an OS pipe as input, and read it using
a regular "ByteStreamFileSource". However, because the size of
the NAL units (created by you) are known in advance, it would be
more efficient to have your own memory buffer - that contains just
a single NAL unit at a time - and feed it into a
"H264VideoStreamDiscreteFramer" (*not* a "H264VideoStreamFramer".
(Note that each NAL unit that you feed into
a "H264VideoStreamDiscreteFramer" must *not* begin with a 0x000001
'start code'.)</blockquote>
<br>
So myFramedSource will be responsible for passing individual nals up
to the DiscreteFramer, via deliverFrame, 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), or.. I can see how in DeviceSource how we
return without writing in the event that there is nothing to ship
out, but I don't see where we continue to get back into deliverFrame
if there is more data to write. My encoder thread either... waits
till all nals have been consumed and then continues? Or leaves the
nals somewhere where live555 can continue to consume them at its
leisure?<br>
<br>
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>
<br>
Again, thank you very much for your responses, and I appreciate your
time.<br>
<br>
<pre class="moz-signature" cols="72">--
Joshua Kordani
LSA Autonomy</pre>
</body>
</html>