GNOME Bugzilla – Bug 624784
rtph264pay has wrong keyframe checks?
Last modified: 2010-07-20 10:57:53 UTC
#define IS_ACCESS_UNIT(x) (((x) > 0x00) && ((x) < 0x06)) Reading from the spec, normal frames should be marked with 1, and in fact only IDR frames can be considered keyframes, so: #define IS_ACCESS_UNIT(x) ((x) == 5) I wonder why it works at all.
(In reply to comment #0) > #define IS_ACCESS_UNIT(x) (((x) > 0x00) && ((x) < 0x06)) > > Reading from the spec, normal frames should be marked with 1, and in fact only > IDR frames can be considered keyframes, so: > > #define IS_ACCESS_UNIT(x) ((x) == 5) > Spec (RFC 3984) says: ---- Marker bit (M): 1 bit Set for the very last packet of the access unit indicated by the RTP timestamp, in line with the normal use of the M bit in video formats, to allow an efficient playout buffer handling. For aggregation packets (STAP and MTAP), the marker bit in the RTP header MUST be set to the value that the marker bit of the last NAL unit of the aggregation packet would have been if it were transported in its own RTP packet. Decoders MAY use this bit as an early indication of the last packet of an access unit, but MUST NOT rely on this property. ---- Where does that say anything about keyframe-ness? In particular, the above check is indeed a rough check as to whether current NAL (fragment) terminates Access Unit (in simple cases at least). > I wonder why it works at all. See above, because it is only an indication, not to be relied upon anyway. AFAICS, rtph264depay does not even consider it.
Ok, Olivier filed a bug in Nokia's internal bugzilla about gst-dsp encoder not returning keyframes, although it turns out the keyframes were there, just not marked as IDR, but I guess it doesn't even matter.
The reason I need keyframes is that "config-interval" puts the SPS/PPS just before a keyframe. Just after "nalType == IDR_TYPE_ID" (which is 5).
What is the context here? What is "needing keyframes"? And what is actually the bug/problem with rtph264pay? Is is the DELTA_UNIT marking of its output buffers or ... ? [Guess: "needing keyframes" means one needs IDR-NALUs from the encoder (as opposed to e.g. NIDR-I so rtph264pay can do its config-interval insertion. If so, this seems to have nothing to do with rtph264pay and not a discussion to have here ...]
(In reply to comment #3) > The reason I need keyframes is that "config-interval" puts the SPS/PPS just > before a keyframe. Just after "nalType == IDR_TYPE_ID" (which is 5). Oh, now I see. A bit off-topic, but why is the SPS/PPS needed?
(In reply to comment #4) > What is the context here? What is "needing keyframes"? > And what is actually the bug/problem with rtph264pay? > Is is the DELTA_UNIT marking of its output buffers or ... ? > > [Guess: "needing keyframes" means one needs IDR-NALUs from the encoder (as > opposed to e.g. NIDR-I so rtph264pay can do its config-interval insertion. > If so, this seems to have nothing to do with rtph264pay and not a discussion to > have here ...] Right, that's why I put a question mark in the title of this bug. Closing.
Very offtopic: The SPS and PPS are needed to be able to decode the stream... And if we send RTP over UDP, then we want to rsend them in case they are lost (also useful if someone wants to join mid-stream).