[Live-devel] H.264 streaming -- Not receiving all packets

[Georges Côté]

If my H/W encoder is single-slice, am I doomed? Seems to be working well 
on a reliable network for 1080i @ 5 Mb/s. Anything higher (10 Mb/s) is 
not as stable but I haven't had time investigating why.

For the reference frames, the codec generates a buffer containing 3 NAL 
units (SPS, PPS and the reference frame) but since SPS and PPS NAL units 
are so small, I don't bother sending them by themselves. The other 
buffers contain 1 NAL unit also.

Thank you!

Georges

Ross Finlayson wrote:
>> The way I understand it and read the code the 
>> currentNALUnitEndsAccessUnit() method returning true marks the end of 
>> a frame not a a NAL unit. (remember NAL unit does not always equal 
>> frame).
>
> Yes, "currentNALUnitEndsAccessUnit()" should return True iff (if and 
> only if) the most recently-delivered NAL unit marks the end of a video 
> frame (i.e., a complete screen).
>
>
>> question; if you have a NAL unit that can't fit in the buffer 
>> provided in doGetNextFrame() can you hold on to the part of the NAL 
>> unit that didn't fit and pass it in the next time doGetNextFrame() is 
>> called?
>
> No.  Each NAL unit must fit completely in the output buffer (at the 
> server end), and the input buffer (at the receiving end).  (Our 
> software takes care of fragmenting a large NAL unit across several 
> *network* (RTP) packets, and reassembling at the receiver end, so you 
> don't need to concern yourself with this.  However, each NAL unit must 
> fit completely within an output (and input) buffer.
>
> Very large NAL units are not a good idea, because they get sent in 
> several consecutive RTP packets, and if any one of these packets gets 
> lost, then the whole NAL unit will (effectlvely) be lost.  Therefore, 
> if possible, you should reduce the size of your NAL units - e.g., 
> using slices.
>