> Surely the answer is to test the frame-size from the encoder before passing > it into Live555
Unfortunately not, because we don't know the frame size in advance; we can figure it out only by parsing/copying the data, looking for the next 'start code'. And it's this that's overflowing our stream parsing code. On reflection, however, I think I can fix our H.264 parsing code to avoid this problem (the fix would be for H.264 parsing only). However, you also should reconsider generating such huge NAL units. The problem with NAL units this size is that if you stream them, then each such NAL unit will get fragmented over multiple RTP packets. That's OK, but the loss of just one of these packets will cause the entire NAL unit to be undecodable by the receiver. And the larger the NAL unit, the more likely that that will happen. If you have control over your encoder, it would be far better to have it generate such large frames as multiple 'slices' - i.e., one NAL unit per slice, rather than as one NAL unit for the whole frame. Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
