Subject: [Cellar] Matroska AlphaMode element

From: Jerome Martinez <[email-masked]>
Date: Fri, 12 May 2017 11:41:37 +0200

In Matroska specs, I read:

\Segment\Tracks\TrackEntry\Video\AlphaMode
"Alpha Video Mode. Presence of this Element indicates that the 
BlockAdditional Element could contain Alpha data."

for me, verb "could" here is disturbing: does it means that for any 
video entry, I can put this element whatever is the content (alpha or 
not, BlockAdditionalelement present or not)? does it mean that I can 
skip this element whatever is the content (alpha or not, 
BlockAdditionalelement present or not)?

I would like to have something more explicit about what is expected 
(when should this element be used) and what is valid (actually what is 
invalid), e.g which line below is valid or invalid when AlphaMode is 0 
(default if not present), and when AlphaMode is 1?
- BlockAdditional is not present and Block contains YUV content
- BlockAdditional is not present and Block contains YUVA content
- BlockAdditional is present and containing no alpha content (it 
contains something else)
- BlockAdditional is present and containing alpha (with or without 
something else)

Background: I am testing MKV/FFV1 output from FFmpeg with all 
colorspaces (pix_fmt), and AlphaMode is set to 1 with yuva420p pix_fmt 
(8-bit), this is the only one (e.g. no AlphaMode with yuv420 or 
yuva420p9), I find "53 C0 81 01" bytes in the resulting MKV, no 
BlockAdditional (when Alpha channel is present, it is in FFV1 bitstream) 
and I would like to know if it is valid or not before filling an FFmpeg 
ticket about the difference with AlphaMode between 8-bit and 9-bit 
content, and putting a test in MediaConch.
ffmpeg -f lavfi -i mandelbrot=s=4x4 -vf format=yuva420p -t 1 -c rawvideo 
-c:v ffv1 yuva420p.mkv

Jérôme

---

From: Steve Lhomme <[email-masked]>
Date: Tue, 16 May 2017 14:05:18 +0200

2017-05-12 11:41 GMT+02:00 Jerome Martinez <[email-masked]>:
> for me, verb "could" here is disturbing: does it means that for any video
> entry, I can put this element whatever is the content (alpha or not,
> BlockAdditionalelement present or not)? does it mean that I can skip this
> element whatever is the content (alpha or not, BlockAdditionalelement
> present or not)?

I had to search deep in my memory to find what this is. It is a flag
to indicate that one of the BlockAddtional ID corresponds to alpha
data for the main video Block. The block addition is interpreted by
the codec so it's up to the codec to know what to do with this ID and
how to interpret the BlockAdditional data.
So this flag is just informational to know if a particular track main
contain alpha data via BlockAddition parsing.

> I would like to have something more explicit about what is expected (when
> should this element be used) and what is valid (actually what is invalid),
> e.g which line below is valid or invalid when AlphaMode is 0 (default if not
> present), and when AlphaMode is 1?
> - BlockAdditional is present and containing no alpha content (it contains
> something else)
> - BlockAdditional is present and containing alpha (with or without something
> else)

IMO it should be 0 or 1. Or rather 0 or <BlockAddID that contains the
alpha data>. It doesn't matter the codec of the original content.

> Background: I am testing MKV/FFV1 output from FFmpeg with all colorspaces
> (pix_fmt), and AlphaMode is set to 1 with yuva420p pix_fmt (8-bit), this is
> the only one (e.g. no AlphaMode with yuv420 or yuva420p9), I find "53 C0 81
> 01" bytes in the resulting MKV, no BlockAdditional (when Alpha channel is
> present, it is in FFV1 bitstream) and I would like to know if it is valid or

If there's no BlockAdditional then it's used the wrong way. It's not a
flag to inform that the track contains alpha data.
On the other hand I doubt anyone uses it how it was meant to. So we
might as well use it as a flag to tell whether the video contains
alpha data.

> not before filling an FFmpeg ticket about the difference with AlphaMode
> between 8-bit and 9-bit content, and putting a test in MediaConch.
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar

-- 
Steve Lhomme
Matroska association Chairman

---

From: Jerome Martinez <[email-masked]>
Date: Tue, 16 May 2017 14:36:50 +0200

> might as well use it as a flag to tell whether the video contains

I don't think that indicating that the the video contains alpha data is 
useful as we don't indicate that it contains color planes or any other 
planes. and it would deeply change the meaning of the element.
So is it OK to explicitly say that this elements must (should?) not be 
present if there is no BlockAdditional or if there is no alpha in 
BlockAdditional?

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 21 May 2017 15:22:45 +0200

> useful as we don't indicate that it contains color planes or any other

Then we should deprecate it. It's most likely not used and there's
current no clean what do define what BlockAdditionID does for what
codec. In fact it's internal to the codec interpretation. So it
probably belongs in the codec mapping description. But not a
particular value in the file.

> present if there is no BlockAdditional or if there is no alpha in

I think it's OK to say it should never be present.