Re: [Cellar] AV1 mapping Matroska

[Steve Lhomme <[e-mail]>]

2018-06-27 11:30 GMT+02:00 Steve Lhomme <[e-mail]>:
> 2018-06-27 10:58 GMT+02:00 Moritz Bunkus <moritz=[e-mail]>:
>> Hey,
>>
>> I've only had time to skim over it. It's definitely understandable.
>>
>> For me the most important thing is to have the mapping in Matroska and WebM
>> be identical. As the reference encoder already produces WebM files, I
>> highly suggest we communicate with their developers regarding the
>> mapping. I cannot find a document for AV1/WebM bindings at the moment,
>> though…
>
> Ah I didn't know that. Now I can see the code. Especially webmenc.c
> with a TODO for Frank Galligan in there.
>
> It way for some Wip In Progress code, because I have been appointed by
> the powers that be at AOM to do the proper/official mapping.
>
> At least this code doesn't write any CodecPrivate which could work,
> except, as for VP9 we wouldn't know the decoding profile just from
> reading the TrackEntry which is a major problem to select the proper
> hardware decoder. And the MP4 mapping also integrates a kind of
> CodecProvate with the Sequence Header OBU in there.
>
>>> I will dig deeper but we may have to tweak CodecDelay to make it signed.
>>
>> You cannot change the type of an existing element. It would potentially
>> break the interpretation of existing files created with the old
>> semantics. Let's take the value 144, which as an unsigned EBML integer
>> would be stored as 0x81 0x90. If you read that back as a signed EBML
>> integer, you'd get the value -128.
>
> Given a codec delay sounds like some time the codec needs when fed
> data before it outputs data. So I have hope it matches and I did the
> math wrong.
>
> In any case I don't know if we should include the flags like MP4 does.
> Because it seems very MP4 specific (and it's a draft and may go away).
> Unlike the rest of their "Codec Private" it should not be fed to the
> decoder (the OBUs we have can be fed as-is to the decoder).

In page 20 of https://aomediacodec.github.io/av1-spec/av1-spec.pdf
there's a pseudo-code on how to handle the
[initial_display_delay_present_flag]. The values to use may differ for
each "operating point" (An operating point specifies which spatial and
temporal layers should be decoded).

It doesn't say clearly in the MP4 draft but the delay (in frame count)
means it should be the maximum delay of all operating points. Which
also means it will add too much delay for some operating points. So
IMO it's not good.

An hypotethical delay in Matroska would also use something similar,
but again it won't be a correct delay in some cases. It's really an
internal codec thing. So I think we should not handle it at all or say
that [initial_display_delay_present_flag] SHOULD be 0.

Let alone the fact that it's expressed in number of frames that may
not all have the same duration.

And finally in MP4 it starts with these bits that are mostly copied
from the Sequence Header OBU that just right after. So IMO it's
unnecessary in that case, adds more data and is prone to errors...

>> Kind regards,
>> mosu
>>
>> _______________________________________________
>> Cellar mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cellar
>
>
>
> --
> Steve Lhomme
> Matroska association Chairman



-- 
Steve Lhomme
Matroska association Chairman