22.1.215313 USNB Contribution: Request to begin work on transport and file format for MVC
We agree. We note that time is short (only the FDAM ballot remains, and study documents are being issued). Contributions, please!
22.1.315356 On MVC File Format
Thank you. This contribution seems to satisfy the requirements below, and is a good start. We like splitting the MVC stream into one view per track, as it gives us (among other things) an AVC-compatible base, and makes ‘view thinning’ easier. There are some areas that could usefully be explored:
are there reasons (and designs) to support N-views-per-track?
we might like to think about the sample dependency table, as it probably talks about dependency within one view. What about view-pictures that are not depended on in the same view, but are depended on by other views (do they exist?)?
we would like to ‘split’ the SEIs that talk about the entire set of views, so that the information for each view is in its track. This means that view-thinning would work. However, this means that the file format writer has to parse and decompose SEIs being emitted by the MVC encoder, which is also undesirable. Work is needed.
worked examples of view-thinning, time-based editing, and random access, would be good.
we should allow the alternate group to contain more tracks than just the single MVC view-set. This would allow e.g. SVC and MVC using the same AVC base!
the interaction with hinting should be explored; are (for example) track references ‘copied’ into the hint track(s)? There is a use-case in multicast here, where the client can selectively tune streams, and similarly in unicast, where the server can selectively ‘thin’ (given knowledge of which view the client is watching).
The view identifier box seems redundant and out of the spirit of the design; we probably don’t need it.
We accept this as WD 1.0 of the MVC file format amendment (with slight modifications as above).
