Re: [Cellar] AV1 mapping Matroska

I updated my pull request with these 2 changes.

2018-06-30 9:44 GMT+02:00 Steve Lhomme <slhomme@matroska.org>:
> Hi,
>
>
> 2018-06-30 0:09 GMT+02:00 Andreas Rheinhardt
> <andreas.rheinhardt@googlemail.com>:
>> Hello,
>>
>> I have only just started reading the specification, but I already have
>> some comments:
>>
>> 1. Your proposal says that DisplayHeight and DisplayWidth must be set so
>> that they agree with what is said in the CodecPrivate/in the bitstream
>> so that one can't use the Matroska fields anymore to override what is
>> set in the bitstream. If I am not mistaken, then AV1 would be unique in
>> this regard among all the video codecs that are allowed in Matroska. I
>> don't see a reason for this at all and propose that there shouldn't be a
>> special treatment for DisplayHeight and DisplayWidth in AV1.
>
> 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.
>
>> 2. Two sequence header OBUs with the same [seq_profile],
>> [high_bitdepth], [seq_level_idx] and [color_range] can still differ in
>> the [BitDepth] derived from them due to [twelve_bit]. Therefore I wonder
>> if this is the right restriction. Wouldn't it be better if it is
>> demanded that the derived [BitDepth] coincide for every sequence header OBU?
>
> It depends if it influences the output of the decoder or the decoder
> that can be used. My main concern here is that we have the necessary
> information to setup the decoder to start playback and be done with
> the duration of the Segment. Otherwise that means the CodecPrivate is
> sufficient.
>
> There's a fine line between being too restrictive and forcing multiple
> Segment for a simple internal change in the codec. So we don't want to
> restrict too many field from the Sequence Header. But on the other
> hand we want to ensure a Segment is consistent, especially regarding
> seeking.
>
> That being said, you're right [high_bitdepth] and [twelve_bit] are the
> ones needed to make up the actual [BitDepth] so I will change that.
>
>> 3. Given that AV1 seems to only use one Sequence Header OBU at a time
>> couldn't one use the CodecState and CueCodecState elements to designate
>> where the currently active Sequence Header OBU can be found so that one
>> doesn't need to repeat the Sequence Header with every keyframe?
>
> Yes, that would be a good use for when seeking is used. But these
> elements were ruled out as deprecated because they were of no use
> until now. I know VLC doesn't read them for example.
>
>> (Btw: There are currently conflicting recommendations regarding the
>> existence of Sequence Header OBU if there is actually only one Sequence
>> Header OBU. On the one hand, they should be omitted, on the other hand
>> every block marked as keyframe should start with a Sequence Header OBU.)
>
> 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
> stored in the bitstream (which is frozen) but could be extra data we
> put in the CodecPrivate.
>
>> Andreas Rheinhardt/mkver
>>
>> PS: This is my first mail to this list and I hope that it will be
>> presented as a reply to Steve Lhomme's proposed AV1 mapping in Matroska,
>> but given the fact that I only subscribed today I can't simply reply,
>> but had to explicitly set the "In-Reply-To" field. Hope it works.
>
> It worked perfectly. Thanks for taking the time to review this !
>
>> _______________________________________________
>> Cellar mailing list
>> Cellar@ietf.org
>> https://www.ietf.org/mailman/listinfo/cellar
>
>
>
> --
> Steve Lhomme
> Matroska association Chairman

-- 
Steve Lhomme
Matroska association Chairman