There are multiple ways a publisher can transmit a Track that does not conform to MOQT constraints. Such a Track is considered malformed. Some example conditions that constitute a malformed track when detected by a receiver include:
-
An Object with a particular Subgroup ID is received, but its Publisher Priority is different from that of the previous Object with the same Subgroup ID.
-
An Object is received whose Object ID is larger than the final Object in the Subgroup. The final Object in a Subgroup is the last Object received on a Subgroup stream before a FIN.
-
A Subgroup is received over multiple transport streams terminated by FIN with different final Objects.
-
An Object is received in a Group whose Object ID is larger than the final Object in the Group. The final Object in a Group is the Object with Status END_OF_GROUP, or the last Object before a FIN in a Subgroup which has the END_OF_GROUP bit set. If the end of a Group is implicitly determined via a gap in a FETCH response, the final Object in the Group remains unknown.
-
An Object is received whose Group and Object ID are larger than the final Object in the Track. The final Object in a Track is the Object with Status END_OF_TRACK or the last Object sent in a FETCH whose response indicated End of Track.
-
The same Object is received more than once with different Payload or other immutable properties.
-
An Object is received with a different Forwarding Preference than previously observed.
The above list of conditions is not considered exhaustive.
When a subscriber detects a Malformed Track, it MUST cancel any corresponding
subscription or fetches for that Track from that publisher
(see Section 6.4.2.3), and SHOULD deliver an error to the application.
If a relay detects a Malformed Track, it MUST immediately terminate downstream
subscriptions with PUBLISH_DONE and reset any fetch streams with
Status Code MALFORMED_TRACK. Object(s) triggering Malformed Track status
MUST NOT be cached.