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

Master Header in WAVE and MPEG CMAF #27

Open
KilroyHughes opened this issue Oct 24, 2018 · 0 comments
Open

Master Header in WAVE and MPEG CMAF #27

KilroyHughes opened this issue Oct 24, 2018 · 0 comments

Comments

@KilroyHughes
Copy link

MPEG has added a proposal for a CMAF "Master Header" to Technology Under Consideration, in combination with CMAF specifying Presentation splicing, i.e. the WAVE use case of splicing multiple CMAF Presentations to make a continuous WAVE Program.

WAVE should consider adding the Master Header concept to the Content specification in some forward compatible way to allow for eventual standardization in MPEG CMAF.

Note that CMAF currently specifies a "Common Header" under Switching Set single initialization constraints. A Common Header applies to a single CMAF Switching Set. It basically requires that all parameters allowed to change between Tracks be signaled within each Fragment so a single Common Header can be used exclusively for media pipeline initialization that will be sufficient for all Tracks. The Common Header initializes a parser, decoder, decryptor, display buffer, display interface, etc., sufficient to render all Fragments in the Switching Set without reconfiguration/reinitialization when switching.

A Master Header extends the same principle to a sequence of CMAF Presentations obeying some TBD splice constraints, such as splices conforming to the initialized Media Profile (including subsets) and not mixing encryption schemes ('cenc'/'cbcs').

In addition, the presence of a Master Header could be a promise that the Program will contain continuous content for the duration of the Program that can be rendered by a device after initializing the Master Header, i.e. there will be a continuous sequence of Switching Sets that conform to specified Switching Set and splice constraints.

There could be additional Switching Sets in other Media Profiles that don't have continuity or a Master Header, e.g. a different codec, language, HD/UHD, SDR/HDR, etc. A likely use case would be Master Header continuity of some CMAF Presentation Profile, such as "CMFs" (AVC/AAC/'cbcs'), but some Presentations that include additional alternative Switching Sets e.g. encoded with HEVC at UHD resolution, possibly with different content such as HDR, different languages, different viewpoints, etc. Basic devices would be able to play the continuous CMFs Switching Sets continuously, and more advanced devices with multiple decoders or buffered decoder reconfiguration capability could play the additional Switching Sets without interruption (other than changes in content such as language, video quality, dynamic range, surround sound, etc.).

The Master Header addresses the common case of an unencrypted pre-roll ad followed by an encrypted show. The ad could be HD and 60 fps, while the show is UHD and 24 fps. The Master Header instructs a device to configure a pipeline with the necessary decryption and HDMI/HDCP secure path, and a 60+Hz EDID to handle refresh of both 60 and 24Hz video sample rate (without renegotiating EDID during playback). Without the Master Header, normal behavior would be to initialize an HD pipeline using the Header of the first Track selected (without decryption), then be forced to reinitialize the media pipeline for UHD decode and decryption with a secure video path.

Note that Master Header "single initialization" of the media pipeline is a separate concept from "CMAF single initialization constraints" within a CMAF Switching Set. Even if the associated Track Header is appended on every Track switch and/or Switching Sets don't conform to CMAF single initialization constraints with a Common Header, the Master Header allows a device to render the entire Program without resetting decryption, decoding, or display interface. Appending a Header on every Track switch (or not) is a separate issue whether parameters needed for adaptive switching are stored inband or in Headers, and how frequently Headers and Periods, etc. are needed to signal parameter changes.

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

2 participants