Re: [Cellar] AV1 mapping Matroska

[Steve Lhomme <[e-mail]>]

2018-06-30 15:54 GMT+02:00 Timothy B. Terriberry <[e-mail]>:
> Steve Lhomme wrote:
>>
>> You're right. This is a mistake on my part. Instead of MUST it's a
>> SHOULD. Because Matroska allows to override the codec internal values
>> to display this differently, including changing the aspect ratio or
>> forcing physical dimensions. I will change that.
>
>
> Keep in mind that "SHOULD" tends to have a somewhat stronger force in an
> IETF specification than in normal English. If you're going to use SHOULD and
> not MUST, it is a good idea to explain when someone might reasonably violate
> that SHOULD (if you can't because you can't think of a reason, then you want
> MUST; if you can't because there are too many reasons, then you want MAY).

I changed the DisplayWidth/DisplayHeight mapping to MAY because there
is no strong requirement needed. PixelWidth/PixelHeight should be
fixed for the whole Segment and are mandatory. But the display ones
can be edited even by a user to change the aspect ratio. Using MAY
just means that the default values should come from those bits
mentioned.

>> You mean in my document or the AV1 specs ? My understanding is that
>> the AV1 bitstream allow Sequence Header OBUs to be found within the
>> stream. And doesn't mention which elements are allowed to change or
>> not. Maybe there will be profiles for such restrictions. It won't be
>
>
> See Section 7.5 "Ordering of OBUs":
>
> "Sequence header OBUs may appear in any order within a coded video sequence.
> Within a particular coded video sequence, the contents of
> sequence_header_obu must be bit-identical each time the sequence header
> appears except for the contents of operating_parameters_info. A new coded
> video sequence is required if the sequence header parameters change."

Ah I kinda missed that part.

> So the question you want to answer is how what is stored in a Matroska file
> maps to a "coded video sequence". My opinion (as an individual) is that a
> single EBML Document should correspond to a single coded video sequence.

That would be a Segment in Matroska.

> That means that nothing in the sequence header can change (except for the
> operating_parameters_info).

Section 7.5 starts with this:

"A bitstream conforming to this specification consists of one or more
coded video sequences."

So there can be bitstreams with various coded video sequences, which
parameters may change as the text right after the one you pasted
suggests:

"A new coded video sequence is required if the sequence header
parameters change. Any sequence header in a bitstream which changes
the parameters must be contained in a temporal unit with temporal_id
equal to zero."

My understanding is that an AV1 bitstream can change a lot of
parameters for a whole stream. A coded video sequence is strict but so
much that people might tend to use more than one even in simple files
(although it would probably lose some of the codec efficiency). So
either we allow more than one coded video sequence (the direction I
took) and so we need to define what parameters must not change for all
the Sequence Header OBUs found. Or we only allow one coded video
sequence per Segment. It simplifies things a lot, but I fear we'll end
up with more than one Segment per "file" which is not what most people
use nowadays, even if it's legal to do so.

I'd like more input on this on what they expect the best practices for
"coded video sequence" will be. It's not obvious to me from just
reading the specs.

Looking at the term "coded video sequence" (CVS) in other codecs
(H.264 and H.265) it seems it's a common term. And for those codec one
Segment correspond to one CVS, with the parameters of that CVS stored
in the CodecPrivate (SPS + PPS for H.264 for example). So we should
probably go in that simple way.

>
>
> _______________________________________________
> Cellar mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cellar



-- 
Steve Lhomme
Matroska association Chairman