If you take a look at the RFC
@ Section 5.1. RTP Header Usage
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.
Informative note: Only one M bit is associated with an
aggregation packet carrying multiple NAL units. Thus, if a
gateway has re-packetized an aggregation packet into several
packets, it cannot reliably set the M bit of those packets.
In your example it's hard to say if that camera is incorrectly setting the marker or if the Timestamp is incorrectly set because I can't see the individual NAL units, it's also possible that the PayloadType of the frames / packets are different with the same
Timestamp, I simply can't tell by the picture.
This could be specifically allowed for in the RFC6184 class itself via additional marker properties and or by scanning the contained nal types to verify them, usually or typically I see the SPS and PPS out of band with a different PayloadType than that of the
main stream (sometimes indicated in the MediaDescription or not), when the SPS and PPS are in band in the same stream and use the same PayloadType or when a configuration is shared for multiple streams then it's possible that the inclusion of multiple Marker
packets is legitimate but would be more typically found in RFC6190 streams AFAIK.
I am pretty sure on most cameras this is configurable on the camera in some aspect of the configuration of the camera itself, play with some options until you see what effects this output. (Check for Bitrate, Profile, Packetization Mode / SPS, PSP, GOP / Keyframe
Let me know if you need anything else and thanks for bringing this up!
If you could leave a small Wireshark capture of the SDP and a few RTP Frames that exhibit this behavior I will do my best to include for it when developing further and possibly allow for it to be handled better if possible.