webmproject / vp9-dash Goto Github PK

Sample string is missing a ".01" at the end AFAICT

If VPCodecConfigurationRecord box has a profile 2 and some samples are encoded with profile 1, this will not work on any hardware.

The level parameter is encoded as floating point number (x.y) with the period
omitted. Eg. Level 1 is encoded as "10", level 1.2 is encoded as "12". Valid values
for level may be found here.

I don't think it is a good idea to put hyperlinks in the specification. The link could be lost if the specification is converted to pdf. We should use foot note instead.

Also, this paragraph should be moved to the Semantics section:

level is an integer that specifies a VP codec level all samples conform
to. The value is 0 if a codec level is not specified. It is encoded as floating point
number (x.y) with the period omitted. Eg. Level 1 is encoded as "10", level 1.2
is encoded as "12". [1]

[1] VP9 Levels: https://www.webmproject.org/vp9/levels/

This is what the spec says currently:

A Suggested codecs parameter of VP codecs is:
<sample entry 4CC>.......

Numbers are expressed in decimal. The string may be truncated on any parameter in sequence following the sample entry, and missing values are indicated by a sequence of two periods with no parameter value between them.

None of the fields are required. When a field is optional, people tends to act lazy and omit optional fields. It also introduces inconsistency in codec strings. This is also not the same as other codecs, which has a fixed codec string format, e.g. avc1.XXXXXX for H.264.

We should consider revise this part of the specification and add enforceable requirements, e.g. require all fields to be present or at least, the first four fields: <sample entry 4CC>....

The spec is unclear about what 'level' should be filled with in streams that don't conform to a level.

From the spec:

Codecs Parameter String
DASH and other applications require defined values for the 'Codecs' parameter specified in RFC-6381 for ISO Media tracks. The codecs parameter string for the VP codec family is as follows:

<sample entry 4CC>.....
...

All parameter values are expressed as double-digit decimals. Their semantics are explained in the VPCodecConfigurationBox Semantics section above.

For example, codecs="vp09.02.10.10.01.09.16.09.01" represents VP9 profile 2, level 1, 10-bit YUV content, with 4:2:0 chroma subsampling, ITU-R BT.2020 primaries, ST 2084 EOTF, ITU-R BT.2020 non-constant luminance color matrix, and full-range chroma/luma encoding.

Mandatory Fields
sample entry 4CC, profile, level, and bitDepth are all mandatory fields. If any of these fields are empty, or not within their allowed range, the processing device SHALL treat it as an error.

So what should 'level' be filled with for streams that don't meet any level?
Same for vpcC?

profile level 1 cannot be 420.

Would someone like to merge/address the PRs here? I can do it if they're all desirable. @FrankGalligan, @tinskip ?

Probably we would like the 8-bit field to equal (level * 10).

We talked about this and decided that if someone wants to play a non-complaint vp9 level stream, then they should try and find the closest defined level to put in the codec string.

We should use the values defined in ISO/IEC 23001:8, instead of the values defined in the VP9 spec.

Change colorSpace to matrixCoefficients.
Change transferFunction to transferCharacteristics.

When encrypting superframes, the uncompressed headers of the displayed frame,
the uncompressed headers for all ALTREF frames, and the the superframe header
must be clear. The encrypted bytes of each frame within the superframe must be
block aligned so that the counter state can be computed for each frame within
the superframe. Block alignment is achieved by adjusting the size of the
unencrypted bytes that precede the encrypted bytes for that frame.

Right now the specification only requires encrypted bytes of the frames within the superframe to be block aligned. I think we should require encrypted bytes within non superframes to be aligned as well, for consistency.

Change colorSpace and transferFunction parameters defined in the codec string to matrixCoefficients and transferCharacteristics fields defined in ISO/IEC 23001-8:2016.

The example is codecs="vp09.01.01.02.01.01.00", which means:

• VP9
• 01 = Profile 1
• 01 = Level 1
• 02 = Bit depth 2 bits (??)
• 01 = Color Space Rec. ITU-R BT.601-7
• 01 = Chrome Subsampling 4:2:0 collocated with luma (0,0)
• 00 = Transfer Function Rec. ITU-R BT.709-6, Rec. ITU-R BT.601-7 525 or 625, Rec. ITU-R BT.2020.
• - Any value for full range flag.

I believe the example should be codecs="vp09.01.01.10.05.01.01.00"

Add Colour Primaries field defined by ISO/IEC 23001-8:2016 to VPCodecConfigurationRecord.

We have a specification for HDR metadata carriage in ISO BMFF boxes for VP9 here: https://docs.google.com/document/d/1GBHbczJOiT7M-6n0KaPbEUoo2POZ9O59gzvoyreVKvc/edit

This information should be owned and maintained in the WebM project, for example in this specification.

Change colorSpace and transferFunction parameters defined in the codec configuration box to matrixCoefficients and transferCharacteristics fields defined in ISO/IEC 23001-8:2016.

That is what the spec says right now:

level is an integer that specifies a VP codec level all samples conform to. The value is 0 if a codec level is not specified.

However, vp9 level is really a floating point: 1, 1.1, 2, 2.1, 3, 3.1, 4, 4.1, 5, 5.1, 5.2, 6, 6.1, 6.2.

The spec should make it clear how the floating point level is stored in "integer". WebM[1] wants to store level * 10 in the integer field. We should do the same in iso-bmff.

[1] http://doc/1Nn22IpMEOxBqRSVFfSvzmq1ZRL0s3d_1OTvWZx43GLE/#heading=h.7tt3k1mvygbn

Add Colour Primaries field defined by ISO/IEC 23001-8:2016 to codec string.