NMOS supports compressed video streams; at the most basic via the media_type attribute in the Flow and the media_types capability in the Receiver.
Since IS-04 v1.3, we can register new Flow attributes, and with BCP-004-01 Receiver Capabilities and the Capabilities register, new Receiver capabilities. For example, for JPEG XS (see #177), it was agreed that bit rate is an important characteristic to add (as well as being able to indicate color (sub-)sampling for coded video Flows via the same components attribute used for raw video Flows).
The nmos-cpp sdp module is generic and extensible.
However, the nmos-cpp nmos/sdp_utils.h module and the nmos::sdp_parameters structure it defines are not.
I propose we extend the nmos::sdp_parameters and related functions to provide SDP read/write for additional media types. If it cannot be done maintaining backward compatibility we can do something alongside instead.
There may be no point making something fully generic if it wouldn't provide any abstraction over the lower level sdp namespace functions.
Top priorities are to support video/jxsv, video/H264, video/H265, video/VP9, video/AV1 and audio/AM824 (which doesn't appear to have an IANA registration...).
I feel the nmos::sdp_parameters structure should expose all the required and optional format-specific parameters of these media types as first-class values. There are currently a few missing even for video/raw (when used as per ST 2110-20) such as CMAX (noted in the code).
NMOS supports compressed video streams; at the most basic via the
media_typeattribute in the Flow and themedia_typescapability in the Receiver.Since IS-04 v1.3, we can register new Flow attributes, and with BCP-004-01 Receiver Capabilities and the Capabilities register, new Receiver capabilities. For example, for JPEG XS (see #177), it was agreed that bit rate is an important characteristic to add (as well as being able to indicate color (sub-)sampling for coded video Flows via the same
componentsattribute used for raw video Flows).The nmos-cpp sdp module is generic and extensible.
However, the nmos-cpp nmos/sdp_utils.h module and the
nmos::sdp_parametersstructure it defines are not.I propose we extend the
nmos::sdp_parametersand related functions to provide SDP read/write for additional media types. If it cannot be done maintaining backward compatibility we can do something alongside instead.There may be no point making something fully generic if it wouldn't provide any abstraction over the lower level
sdpnamespace functions.Top priorities are to support
video/jxsv,video/H264,video/H265,video/VP9,video/AV1andaudio/AM824(which doesn't appear to have an IANA registration...).I feel the
nmos::sdp_parametersstructure should expose all the required and optional format-specific parameters of these media types as first-class values. There are currently a few missing even forvideo/raw(when used as per ST 2110-20) such asCMAX(noted in the code).