[Live-devel] H264VideoFramer truncating frames

Robert Smith smith at cognitec.com
Mon Mar 9 04:12:36 PDT 2015


I am using Live555 to stream H264 video via RTP from an embedded system.

The system is designed to be used on local area network's with 
relatively high bandwidth video, hence we have some large frames 
delivered from the encoder.

The encoder unfortunately only supplies frames in Annex B byte stream 
format requiring the frames to be parsed. Previously I was using my own 
class to identify the NAL unit's in conjunction with the 
H264VideoDiscreteFramer which worked fine but it's heavy on the CPU. So 
I've been trying to use the H264VideoFramer and just pass the full 
frames in which works ok and is faster than my solution except that I'm 
seeing a lot of truncated frames.

Having looked into the code it appears to be caused by the behaviour of 
the StreamParser class; specifically the ensureValidBytes1() method 
which calls getNextFrame() on my source with maxSize = BANK_SIZE - 
fTotNumValidBytes. The method switches banks to ensure that the larger 
of numBytesNeeded or the input sources maxFrameSize() will fit.

I can 'fix' the problem by increasing BANK_SIZE and implementing 
maxFrameSize() on my source but I'm not totally happy with this solution 
because I would prefer not to modify the library source and I'm just 
guessing for the maxFrameSize() value.

I was wondering whether it's possible to return a partial frame from my 
video source? I'm guessing it's not a good idea though.

Is there a recommended solution to my problem?

As a side note: it would be great if I could stream the video without 
having to parse the frames but I guess this just isn't possible with 
RTP/H264.

Also, I think any input source that uses the default maxFrameSize() 
implementation returning zero will truncate frames with the 
H264VideoFramer because in this case the StreamParser is always able to 
ask for numBytesNeeded which could be much less than the actual frame 
size, It doesn't take into account that zero means unlimited.

Thanks,

Robert Smith.


More information about the live-devel mailing list