[Live-devel] Slow setup of h264 streams

Ross Finlayson finlayson at live555.com
Thu Sep 7 07:43:24 PDT 2017


>>> As a side note, this live555 mod was comitted/sent back as "minilive" around 2007/2009 according to my colleagues.
>>> 
>> 
>> I have no idea what you’re referring to here.  What “live555 mod”?  And the term “minilive" means nothing to me.
>> 
>> 
> It was a stripped down version of live555 only containing RTSP/RTCP/RTP. It modified the library code, and someone told me it was sent upstream, because of LGPL i assume. 

In any case, your company should review
	live555.com/liveMedia/faq.html#copyright-and-license
to check that you’re in compliance with the LGPL


>> Also, you should explain specifically what you mean by “slow setup” of streams.  Note that when you play a stream using RTSP, three separate commands are involved:
>> - DESCRIBE
>> - SETUP (one for each media track)
>> - PLAY
>> Where specifically is the delay (that you’re concerned about) occurring?
>> 
> It happens after PLAY, when the H264or5VideoRTPSink tries to read the input frames in doGetNextFrame(). According to the comments it is looking for a valid NAL frame.

I’m not sure specifically what part of the code you’re referring to, but perhaps you’re referring to the proxying of very large H.264 NAL units (‘key frames’) - which are fragmented across many (often dozens!) of RTP packets.  It’s important to understand that a receiver (whether its a proxy or a front-end client) must receive *all* of these RTP packets.  If even one of these fragments (RTP packets) is lost, then the whole NAL unit (‘key frame’) will be unusable, and will be discarded.  This has always been the case - and it’s why (to be streamed effectively) H.264 ‘key frames’ should be encoded as a series of ‘slice’ NAL units, rather than a single very large NAL unit.

But in any case, you’re going to have to be a *lot* more specific about what problems you’re having.  And once again, I care only about the latest, unmodified version of the code.  I couldn’t care less about very some old, heavily-modified version of the code that apparently existed only within your company (if at all).


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




More information about the live-devel mailing list