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

Video sample component range #40

Open
garethsb opened this issue Mar 2, 2022 · 2 comments
Open

Video sample component range #40

garethsb opened this issue Mar 2, 2022 · 2 comments

Comments

@garethsb
Copy link
Contributor

garethsb commented Mar 2, 2022

Should there be a [component_]range Flow attribute and a matching urn:x-nmos:cap:format:[component_]range Receiver parameter constraint, corresponding to the RANGE format-specific parameter defined in ST 2110-20 for video/raw and in RFC 9134 for video/jxsv?

See e.g. https://tools.ietf.org/html/rfc9134#section-7.1.

Following the general pattern for such questions...

  • If there are Receivers that can only correctly handle streams with a sub-set of the possible values of this parameter, then the answer is probably yes.
  • If it is only that Receivers need the value to correctly handle a given stream, then the presence of the RANGE format-specific parameter in the SDP data is probably enough.
@garethsb
Copy link
Contributor Author

@jonathan-r-thorpe points out that VSF TR-08 distinguishes between Full Range from limited range for two interoperability points in Capability Set C:
image
However, those interoperability points are also distinguished by other properties (e.g., frame height of 1200).

@garethsb
Copy link
Contributor Author

garethsb commented Dec 9, 2022

One other note is that ST 2110-20 and RFC 9134 define the default value differently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant