[Live-devel] H264 problem with StreamParser leak

[Ross Finlayson]

>We have things working now by avoiding the issue by creating our own 
>customized DiscreteFramer. It avoids the problem by directly using 
>the output buffer and does not touch the Bank buffers. I suspect 
>there is a problem with the H264VideoStreamFramer.

No, I think it's OK.  However, it expects to be able to read a large 
(and arbitrary-sized) chunk of data from its input source.  Usually 
the input source is a file, in which case that's not a problem. 
However, in your case, the input source was delivering just a short 
chunk of data (an individual NAL unit) each time.  That was 
apparently (somehow) upsetting the stream buffering/parsing code.

That's why "H264VideoStreamDiscreteFramer" is the appropriate 
'framer' class for you.


>BTW, does it conflict with the H264 standard if the data being 
>passed through the discrete framer *does* contain the startcodes?

The start codes are not supposed to be present in outgoing RTP 
packets (according to the H/264 RTP payload format specification), so 
our "H264VideoRTPSink" class (which the 'framer' class feeds into) 
can't accept NAL units that begin with the start code.  (In 
principle, we *could* strip these out - in either "H264VideoRTPSink" 
or "H264VideoStreamDiscreteFramer" - if we see them, but that would 
require doing an extra memcpy(), which would be inefficient.  So it's 
better to not allow the start codes at all.)

Your best solution, IMHO, would be to fix your encoder source to 
*not* include the start code at the beginning of each NAL unit that 
it delivers.  Then you could just use our (unmodified) 
"H264VideoStreamDiscreteFramer".
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/