Bug 1537675 Comment 4 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Digging in further it looks like the bitstream in the file has the width and height backwards, so we're when we reach a keyframe and use this data we get the behaviour we're seeing.

Here's my working:
- Use MKVToolNix to open the file and get info on it.
- Inspect the cluster at offset 144779, this cluster has the keyframe just before 7 seconds that causes the shift.
- See that the first block contains the keyframe in question and that the frame starts at offset 144802.
- Dump the hex for that frame and walk it by hand

The relevant hex we need to walk is `a2 49 83 42 00 07 7e 05 9e` and we can pull it apart with the [bitstream spec](https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf).

- First byte (a2): frame marker = 0b10, version = 1, show exisiting frame = 0, frame type = 0 (keyframe), show frame = 1, error resilient mode = 0
- Second (49), third (83), and fourth (42) bytes are expected frame sync codes.
- Fifth byte (00): We end up reading 7 bits here. 3 bytes for color space = 0 (not CS_RGB which is 7), 1 for color range, then 1 for each subsampling x, subsampling y, and a reserved bit.
- Since we didn't read all of the fifth byte, and since we're about to read our size, the last bit of the fifth byte becomes part of our size. Size is two 16 bit values, first width, then height.
- Taking the hex starting at the fifth byte `00 07 7e 05 9e` and shifting it about so we're reading from the last bit of the fifth byte we get `03 bf 02 cf` (trimming to 4 bytes).
- If we convert each set of 16 bits to decimal we get 959 and 719. Our width and height minus 1.

So the values in the VP9 bitstream are bad here. Not sure if there's anything we can sensibly do here, as this seems like an encoder problem. jya, thoughts?
Digging further into the bitstream:

Here's my working:
- Use MKVToolNix to open the file and get info on it.
- Inspect the cluster at offset 144779, this cluster has the keyframe just before 7 seconds that causes the shift.
- See that the first block contains the keyframe in question and that the frame starts at offset 144802.
- Dump the hex for that frame and walk it by hand

The relevant hex we need to walk is `a2 49 83 42 00 07 7e 05 9e` and we can pull it apart with the [bitstream spec](https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf).

- First byte (a2): frame marker = 0b10, version = 1, show exisiting frame = 0, frame type = 0 (keyframe), show frame = 1, error resilient mode = 0
- Second (49), third (83), and fourth (42) bytes are expected frame sync codes.
- Fifth byte (00): We end up reading 7 bits here. 3 bytes for color space = 0 (not CS_RGB which is 7), 1 for color range, then 1 for each subsampling x, subsampling y, and a reserved bit.
- Since we didn't read all of the fifth byte, and since we're about to read our size, the last bit of the fifth byte becomes part of our size. Size is two 16 bit values, first width, then height.
- Taking the hex starting at the fifth byte `00 07 7e 05 9e` and shifting it about so we're reading from the last bit of the fifth byte we get `03 bf 02 cf` (trimming to 4 bytes).
- If we convert each set of 16 bits to decimal we get 959 and 719. Our width and height minus 1.
Digging further into the bitstream, here's my working:

- Use MKVToolNix to open the file and get info on it.
- Inspect the cluster at offset 144779, this cluster has the keyframe just before 7 seconds that causes the shift.
- See that the first block contains the keyframe in question and that the frame starts at offset 144802.
- Dump the hex for that frame and walk it by hand

The relevant hex we need to walk is `a2 49 83 42 00 07 7e 05 9e` and we can pull it apart with the [bitstream spec](https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf).

- First byte (a2): frame marker = 0b10, version = 1, show exisiting frame = 0, frame type = 0 (keyframe), show frame = 1, error resilient mode = 0
- Second (49), third (83), and fourth (42) bytes are expected frame sync codes.
- Fifth byte (00): We end up reading 7 bits here. 3 bytes for color space = 0 (not CS_RGB which is 7), 1 for color range, then 1 for each subsampling x, subsampling y, and a reserved bit.
- Since we didn't read all of the fifth byte, and since we're about to read our size, the last bit of the fifth byte becomes part of our size. Size is two 16 bit values, first width, then height.
- Taking the hex starting at the fifth byte `00 07 7e 05 9e` and shifting it about so we're reading from the last bit of the fifth byte we get `03 bf 02 cf` (trimming to 4 bytes).
- If we convert each set of 16 bits to decimal we get 959 and 719. Our width and height minus 1.

Back to Bug 1537675 Comment 4