Organisation internationale de normalisation

8.1.315591 Proposals for MVC File Format

Thank you. Lots of detailed work here. One overall question for the two contributions is to what extent we can use the same code points (e.g. track reference types) as SVC even if the 4 characters aren’t quite ‘right’ for MVC. Another is whether some use of extractors would enable building complete ‘cookbook’ tracks for a given (set of) view(s). (Tracks which were then essentially ‘complete’ could then be so marked).

Maybe in the case that there are both (a) multiple views per track and (b) multiple tracks, then the groups are mandatory (or else merging two tracks would require decoding NAL unit headers and perhaps slice headers, and SPSs). (Indeed, this is in the revised WD).

The use of alternate groups seems complex. Are the members of the group

different views from the same set of multiple views?

different multiple view groups?

alternative ‘simple video’ versions of particular views of a multiple view set?

Looks like the proposal covers this, with the major difference from SVC that (a) are not a group. We can use sample groups, track references, and track selection info however. We probably need a track selection entry that says “I differ by multi-view or view coding” (e.g. the same set of views with a different base).
Some concern about movie-level structures as they are fragile with respect to track addition or deletion. There is also some overlap here with track selection, but of course this is handling sets of tracks etc. But it’s not at all clear that this can be re-written as a ‘distributed program’ across the multiple tracks. One possible idea is to have tracks with the groups, meta-data and track references but no samples? Is there a place for all the data? What boxes in the sample table would be empty or missing? This needs thought. Indeed, such a track could have extractors to say how to make it (optionally) and indeed we could have a bit next to complete_rep that says whether the track knows how to build all the data for this view set. But that adds a ‘mode’ to the reader. More thought needed. This might mesh well with using track selection information, on first look.
We’re currently not using extractors, but it may be that there are some uses; perhaps for indicating ‘cookbook’ all the data for a set of views (including dependency). Indeed, in that case, where more than one view is wanted, the order of extractors and NAL units would be define at least partially the needed output order (but not fully)?
The maximum disparity might vary over time. Should this be in a temporal structure (e.g. sample groups)? The trouble is that it is a piece of information about the relationship between two views, which in turn might be in multiple tracks. Clearly at file level this can be the overall max_disparity, of course.
Do we need to say more about where parameter sets are stored (in the track closest to the base, following dependencies, of the views that need this parameter set?).
Do we go to PDAM? If it doesn’t make a difference to the completion date, no. The FF group also leans towards no, but the editor to check the calendar and systems plenary to decide.
[After the meeting: There isn’t time for a ballot now before Busan, so any FPDAM would be in Lausanne either way, so we hold off and do PDAM at Busan.]