[Live-devel] CPU intensive on ARM using testH264VideoStreamer with TI encoder

[Ross Finlayson]

> I guess (and again it is ONLY a guess) the intensive cpu usage comes from
> the need to break the big h264 frames to MTU fragments (i.e. ~1450 B).

Because the high CPU usage (at least, what I observed when I streamed your file using "testH264VideoStreamer") occurred in bursts, rather than during the entire streaming of the file, I suspect that yes, indeed, your very large IDR picture frames (76950 bytes and 106365 bytes) are to blame.  Note that the fact that these frames need to be fragmented is not an issue; most of the overhead occurs from having to parse and copy the frames, regardless of whether they're being fragmented.  (In any case, it turns out that almost all of your frames end up being fragmented, because they're almost all larger than the MTU.)


> I can't reduce the size of the h264 frames because the stream bandwidth
> (8Mbps) must be retained (part of the requirements).

You might not be able to reduce the bandwidth of the stream, but you can reduce your NAL unit sizes, by getting your encoder to encode each IDR picture into multiple 'slice' NAL units.  This is a good idea, because if packets forming a 'slice' NAL unit get lost, then that will cause only that slice to be non-renderable.  On the other hand, if the IDR picture is a complete NAL unit, then the loss of *any* packet (and note that your 106365 byte picture will be sent in at least 70 RTP packets!) will cause the whole picture to be non-renderable.

Another thing that you can do to reduce overhead is read your NAL units from your decoder one at a time, and use "H264VideoStreamDiscreteFramer" rather than "H264VideoStreamFramer" to parse them.


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/20120802/30fb6de1/attachment.html>