[Live-devel] Handle multiple I/P slices

[Ross Finlayson]

> On Jan 28, 2023, at 7:24 AM, R, Ranjith via live-devel <live-devel at us.live555.com> wrote:
> 
>  We are using Live555 library as a RTSP client in our CCTV product.

That’s good to hear.  (Don’t forget your obligations under the GNU LGPL license: http://live555.com/liveMedia/faq.html#copyright-and-license )


> Recently we integrated a new camera where we are getting two I/P frames with the same timestamp.
>  When we further analyze, this specific camera is setting FU header end bit in middle of a frame.
> Suppose a single I frame is sent as 90 FUs, 45th FU end bit is set and again on 90th FU end bit is set and RTP header marker bit set.

RFC 6184 (which specifies the IETF RTP Payload Format for H.264 Video) explains that the FU end bit is set only for the last fragment of a NAL unit.  Therefore, to use your example, the first 45 fragments must make up one NAL unit, and the next 45 fragments must make up another (different) NAL unit.  You say that these make up “a single I frame”.  Therefore, to be compliant, these two NAL units would each have to be a ’slice’ of the I frame.

Having a single I frame be broken up into multiple slices (even just two slices) is a good thing, because it makes your stream more resilient to packet loss.  You can lose one of the slices without making the whole of your I frame unusable.  Your receiver should be able to handle (and render) one slice at a time.

If, however, your I frame consists of just a single NAL unit (rather than multiple ’slice’ NAL units), then your IP camera is not compliant with RFC 6184; you will need to ask the camera’s manufacturer to fix this bug.


> Can we set the fCurrentPacketCompletesFrame flag only if marker bit of RTP header is set ?

Not if you want your receiver to remain compliant (nor if you want to continue receiving support from this mailing list)


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