Skipped frames when displaying RTP / H.264 stream

[jean-philippe]

Update.

Using Wireshark, I have noticed that the RTP packet containing the 128th IDR
NALU does not have its Marker bit set, like the others. This is expected
since there is another RTP packet following with the Filler NALU that
belongs to the same timestamp. But the final RTP packet that contains the
Filler NALU does not have its Marker bit set either.

The Market bit (M) is described in section "5.1.  RTP Header Usage" of
https://tools.ietf.org/html/rfc6184#page-10.

So it seems rtph264pay does not set the Marker bit for Filler NALUs.

However, it seems rtph264depay may rely on the Marker bit to complete the
depacketising and produce a buffer.  My theory is that it waits until the
next Access-Delimiter NALU and at that point flushes the buffer out. 

If this is so, this would be a problem as explained in the spec:
"Decoders MAY use this bit as an early indication of the last packet of an
access unit but MUST NOT rely on this property."

Does this sound like a plausible theory? I am looking at the implementation
of rtph264pay and rtph264depay, but it will take me a while before I can
prove or disprove it.

Did anyone have time to run unit tests with the GOP I sent earlier?
 
To be clear, here is the sequence (Access Delimiters are generated every
33ms):
Access Delimiter
SPS
PPS
IDR (Marker bit set) -> Buffer generated by rtph264depay
Access Delimiter
SPS
PPS
IDR (Marker bit set) -> Buffer generated by rtph264depay
Access Delimiter
SPS
PPS
*IDR (Marker bit NOT set)-> No buffer generated by rtph264depay*
Filler
Access Delimiter
SPS
PPS
IDR -(Marker bit set) > Buffer generated by rtph264depay





--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/