[Live-devel] H264VideoFramer truncating frames

[Robert Smith]

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 source's maxFrameSize() will fit. My 
input source has a default implementation of maxFrameSize(), e.g, 
returns zero indicating 'unlimited/unknown'.

I can 'fix' the problem of truncated frames 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 a value for maxFrameSize().

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 which returns 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.