[gstreamer-bugs] [Bug 624784] rtph264pay has wrong keyframe checks?

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=624784
  GStreamer | gst-plugins-good | git

Mark Nauwelaerts <mnauw> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mnauw at users.sourceforge.net

--- Comment #1 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2010-07-20 09:26:05 UTC ---
(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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.