>>> 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/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
