International organisation for standardisation

8.3Summary of discussions

m17294 Two issues with movie fragments (part 12)

The first issue, thank you. We could really do with some feedback from others who have used this defaulting (if any), and a sample file. Let’s see what putting it into the amendment brings out.

The second problem is understood, but we are aware that there are a number of ways to solve this problem (some under discussion in other bodies), and there is an issue with what happens if (for example) we want to ‘splice in’ a new fragment, or we want to start ‘dropping’ fragments into a new recording file. Either of these would mean that the absolute times that are indicated here would need to be adjusted. We’ll put this paragraph into the amendment text, in order to provoke comment and further feedback.

m17297 Two minor issues with the proposed amendment to Part 12

The first issue is further discussed in the 17298; the proposed solution here (relying on ordering) is not good, as current protect/de-protect loops know of no such rule.

The second issue, agreed; editors to integrate.

m17298Study on file format video requirements (part 12)

Thank you; we will make clear that the method is optional. And indeed, allowing the scheme information (SEI) without the 4CC transform documents the behavior without breaking backward compatibility.

Alas, existing protection programs don’t know that they should encapsulate existing ‘sinf’s any more than they know they should order them (as proposed in 297). We need to use a different code for the restricted info box (other than ‘sinf’, maybe ‘rinf’).

The concern about various methods possibly being used seems to be handled by the format; all those SEIs should be in the SEI information box. But it answers this open question:

The SEI message here [should/must] [not?] be also stored either in the bitstream or in the AVC Configuration Record.

with: yes, they should be if the stream is an AVC stream, as then they are in the right place (for example, if the stereo method changes in stream — which is probably not a good idea!).

Thank you for the careful read, thought, and recommendations.

m17320 Video Track Selection and Switching based on Temporal Subsets (part 12 or 15)

We are pleased to note that we think this is currently supported by part 15, for AVC. An application would define that it permits sample entry type ‘avc2’ for use with AVC bitstreams, define a brand code that required that support and also support for the ‘SVCExtractor’ toolset. Then this technique can be done either:

a) having a ‘full’ bitstream at the full frame rate, and extracting out the subset lower frame rate tracks; or

b) having the lowest frame rate track, and then extracting those frames into the next higher – a track that also has the additional frames needed – and so on.

This is also supported in one track, by the new sub-track selection mechanism in the upcoming part 12 (using sample groups). Each subset of frames in the one track is identified as a separate sample group, each sub-track is defined as one or more sample groups (e.g. group 1, 1+2, 1+2+3), and then they can be selected or switched between.