New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make AlphaMode mandatory #558
Conversation
For me a default of |
But that's not compatible with what the WebM spec says:
0, 1, 2, ..., 666, 667, ... all mean that the BlockAdditional element could contain alpha data. That would break compatibility with existing parsers. |
BTW Firefox, one of the browsers that can handle alpha in WebM, seems to use nestegg to parse WebM. https://github.com/mozilla/nestegg/blob/ec6adfbbf979678e3058cc4695257366f39e290b/src/nestegg.c#L2628 |
It seems to be the same in Chrome/chromium/Edge/etc. The internal read value is initialized to |
In both cases, the presence of the element is not sufficient to determine if the video track has an alpha channel.
We have 2 choices to match the rules discussed #501, remove the default value, or make it mandatory. In both cases we have to explain than only a value of I'd rather make it mandatory as done for all other elements with a default value of 0 in #557. |
This is a WebM thing loosely defined. Having just the presence of the element present to signal something is at odd with all other elements. The default value in this case has no use. And following the discussions in #501 elements with a default value would preferably be mandatory. But that's not possible with the "presence" signaling something. Both libavformat [1] and libwebm [2] write a value of 1 when they want to signal it. Chromium requires a value of 1 to consider the track has alpha [3]. Firefox consider there's no alpha value is 0 is stored [4]. [1] https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/matroskaenc.c#L1274 [2] https://aomedia.googlesource.com/aom/+/refs/heads/master/third_party/libwebm/mkvmuxer/mkvmuxer.cc#1522 [3] https://github.com/chromium/chromium/blob/72ceeed2ebcd505b8d8205ed7354e862b871995e/media/formats/webm/webm_video_client.cc#L149 [4] https://github.com/mozilla/nestegg/blob/ec6adfbbf979678e3058cc4695257366f39e290b/src/nestegg.c#L2627
This is how other flags are defined in the document. Both libavformat [1] and libwebm [2] write a value of 1 when they want to signal it. This is compatible with how Chromium (the reference) works. [1] https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/matroskaenc.c#L1274 [2] https://aomedia.googlesource.com/aom/+/refs/heads/master/third_party/libwebm/mkvmuxer/mkvmuxer.cc#1522
407cacc
to
4198532
Compare
Make mandatory as in #557 and define it as other flags (value 1 means defined). |
The BlockAddID of 1 must be considered as alpha data when the AlphaMode flag is set. That's how it's written by libavformat (only 1 is considered and it's alpha value) [1] [1] https://github.com/FFmpeg/FFmpeg/blob/e26c4d252faff4f7b1bf3087f609b699f20b47d3/libavcodec/libvpxdec.c#L238
a3f0ba0
to
9bed4a0
Compare
This is a WebM thing loosely defined. I'm not sure where the default value
came from.
Having just the presence of the element present to signal something is at odd
with all other elements. The default value in this case has no use. And
following the discussions in #501 elements with a default value would preferably
be mandatory. But that's not possible with the "presence" signaling something.
So just remove the default value.
Both libavformat [1] and libwebm [2] write a value of 1 when they want to signal
it.
[1] https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/matroskaenc.c#L1274
[2] https://aomedia.googlesource.com/aom/+/refs/heads/master/third_party/libwebm/mkvmuxer/mkvmuxer.cc#1522