Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ARG mux proposal #30

Open
wants to merge 4 commits into
base: v1.0.x
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions APIs/schemas/constraint_set.json
Original file line number Diff line number Diff line change
Expand Up @@ -20,6 +20,13 @@
"description": "This value indicates whether a Constraint Set is available to use immediately (true) or whether this is an offline capability which can be activated via some unspecified configuration mechanism (false). When the attribute is omitted its value is assumed to be true.",
"type": "boolean",
"default": true
},
"urn:x-nmos:substreams": {
Copy link
Contributor Author

@garethsb garethsb Oct 30, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've discussed that in order to maintain BCP-004-01 v1.0 compatibility this cannot be urn:x-nmos:cap:substreams because of the pattern property below. But not clear whether urn:x-nmos:substreams name is precise enough.

"description": "This exposes any substream constraints.",
"type": "array",
"items": {
"$ref": "substream_constraints.json"
}
}
},
"patternProperties": {
Expand Down
39 changes: 39 additions & 0 deletions APIs/schemas/substream_constraints.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
{
"$schema": "http://json-schema.org/draft-04/schema#",
"description": "Describes substream constraints",
"title": "Constraint Set",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"title": "Constraint Set",
"title": "Substream Constraints",

"type": "object",
"minProperties": 1,
"properties": {
"description": {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Each constraint set uses URN attribute names, since the parameter constraints in each set are intended to be extensible, and the metadata attributes therefore also have URNs, like urn:x-nmos:cap:meta:label.

Here it probably does make sense to use "simple" attribute names, like format and count (or minimum tbc). Should this one be description or label?

"description": "Substream group description",
"type": "string"
},
"format": {
"description": "Substream format",
"type": "string",
"anyOf": [
{
"enum": [
"urn:x-nmos:format:video",
"urn:x-nmos:format:audio",
"urn:x-nmos:format:data"
]
},
{
"pattern": "^urn:x-nmos:format:(?!mux$)"
}
]
},
"count": {
"$ref": "param_constraint_number.json"
},
Comment on lines +28 to +30
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've discussed that most/all mux Receivers are capable of discarding substreams they are not interested in. Therefore we started discussing whether a minimum attribute could be simpler and sufficient?

E.g. something like

Suggested change
"count": {
"$ref": "param_constraint_number.json"
},
"minimum": {
"type": "integer",
"default": 1,
"minimum": 0
},

"constraint_sets": {
"description": "Substream constraint sets",
"type": "array",
"items": {
"$ref": "constraint_set.json"
}
}
}
}
57 changes: 57 additions & 0 deletions docs/Examples.md
Original file line number Diff line number Diff line change
Expand Up @@ -236,3 +236,60 @@ For example, Type N receivers can be expected to correctly receive a stream orig

[TR-05]: https://www.videoservicesforum.org/download/technical_recommendations/VSF_TR-05_2018-06-23.pdf
"VSF TR-05: Essential Formats and Descriptions for Interoperability of SMPTE ST 2110-20 Video Signals"

### Substreams

The following example shows a mux MPEG 2 transport stream Receiver exposing substream constraints.

```json
{
"id": "9dd002e2-76a0-4edc-88ef-7d4aff4b2d26",
"transport": "rtp",
"format": "mux",
"caps": {
"media_types": [
"video/MP2T"
],
"constraint_sets": [
{
"urn:x-nmos:substreams": [
{
"description": "hi-res video profile",
"format": "urn:x-nmos:format:video",
"count": {
"enum": [
1
]
},
"constraint_sets": [...]
},
{
"description": "proxy video profile",
"format": "urn:x-nmos:format:video",
"count": {
"minimum": 0,
"maximum": 1
},
"constraint_sets": [...]
},
{
"description": "audio profile",
"format": "urn:x-nmos:format:audio",
"count": {
"enum": [
0,
2,
4
]
},
"constraint_sets": [...]
}
]
},
{
"urn:x-nmos:substreams": [...]
}
]
}
}
```
26 changes: 25 additions & 1 deletion docs/Receiver Capabilities.md
Original file line number Diff line number Diff line change
Expand Up @@ -46,6 +46,7 @@ Manufacturers MAY use their own namespaces to indicate Parameter Constraints whi
### Parameter Constraint Types

The specification defines the JSON value type to which the constraint relates, which MUST be one of:

* `string`
* `integer`
* `number`
Expand Down Expand Up @@ -87,6 +88,7 @@ It could therefore be better to explicitly constrain the target parameter to all
### Common Constraint Keywords

The following attributes are allowed for all constraint types:

* `enum` as an array value with one or more elements of the specified type

### String Constraint Keywords
Expand Down Expand Up @@ -162,6 +164,28 @@ A Controller MUST NOT take into consideration a Constraint Set that has this att

If a Constraint Set is enabled or the Receiver does not support offline capabilities then this attribute MAY be omitted.

### Substreams

The `urn:x-nmos:substreams` attribute allows mux Receivers to indicate per substream constraints.

The substreams are represented as a JSON array containing substream JSON objects.

Each substream object includes the following attributes:

* a description
* the format of the substream
* a count which specifies how many instances of this substream are required (both min, max or enum attributes can be used for this)
* constraint_sets for this particular substream. These constraint sets are defined in the same way as constraints defined for single essence flows [see Constraint Sets](#constraint-sets).

A Constraint Set using the `substreams` attribute is satisfied if **all of** its Substream Parameter Constraints are satisfied in the quantities specified by each `count` attribute.
This implies that if **any of** the Substream Parameter Constraints are _not_ satisfied in the quantities specified by each `count` attribute, the Constraint Set as a whole is not satisfied.

Substream Parameter Constraints are matched against parent Flow and source attributes. Each parent Flow can only be used to satisfy one Substream Parameter Constraints. The following diagram shows this matching workflow.

| ![Substreams](images/substreams.png) |
|:--:|
| _**Substreams**_ |

### Listing Constraint Sets

The Receiver advertises a list of Constraint Sets as a JSON array of these objects, using the key `constraint_sets` in the `caps` object.
Expand Down Expand Up @@ -198,7 +222,7 @@ The Receiver MUST reflect any change in its capabilities by updating the `caps`

## Behaviour: Controllers

Controllers are strongly RECOMMENDED to support all Parameter Constraints listed in the Capabilities register in the [NMOS Parameter Registers][] that are applicable for the kinds of Receiver with which they interact.
Controllers are strongly RECOMMENDED to support all Parameter Constraints, including [per-substream](#substreams) Parameter Contraints, listed in the Capabilities register in the [NMOS Parameter Registers][] that are applicable for the kinds of Receiver with which they interact.
However, Controllers MAY ignore individual Parameter Constraints whose unique identifiers they do not recognize.
Some Parameter Constraints are only relevant to specific `transport` and `format` values or to particular IANA media types.
When a Controller cannot evaluate any of the Parameter Constraints in a Constraint Set, that Constraint Set SHOULD be considered to be satisfied, but the Controller MAY distinguish this case for a user.
Expand Down
Binary file added docs/images/substreams.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.