> On Jan 28, 2023, at 7:24 AM, R, Ranjith via live-devel 
> <live-de...@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/


_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Reply via email to