[FFmpeg-devel] [PATCH] avutil: add API for mb_types

[Rostislav Pehlivanov]

On 12 November 2017 at 01:44, Ronald S. Bultje <rsbultje at gmail.com> wrote:

> Hi,
>
> On Sat, Nov 11, 2017 at 6:21 PM, Michael Niedermayer
> <michael at niedermayer.cc
> > wrote:
>
> > +    /**
> > +     * Width and height of the block.
> > +     */
> > +    uint8_t w, h;
> >
>
> av1 already has up to 128x128 block sizes, so I'm assuming this won't be
> enough for av2. Maybe that's Ok, but it's easy to make it (u)int16_t now.
>
> +    /**
> > +     * Quantization parameter, a value of -128 means lossless, 127 means
> > not applicable
> > +     */
> > +    int8_t qp;
> >
>
> vp8, vp9 and av1 have 256 quantizers.
>
>
I agree, I think this should be a uint16_t with 0 defined as lossless and
UINT16_MAX as N/A.
The range should be derived from the codec ID.




> > +    /**
> > +     * Direction of prediction, 0 is horizontal, 48 is vertical,
> > +     * values 0 to 95 follow clockwise direction.
> > +     * 254 means the block uses planar prediction
> > +     * 255 means that the block has no prediction direction.
> > +     */
> > +    uint8_t pred_direction;
> >
>
> Assuming this is intra - I think we want some more specificity here, e.g.
> is 255 DC? What about tm (vp8/9) or smooth_pred (av1). What about blocks
> that used mixed inter+intra pred (av1)?
>
> +    /**
> > +     * Direction of transform, 0 is horizontal, 48 is vertical,
> > +     * values 0 to 95 follow clockwise direction.
> > +     * 255 means that the block has no directional transform.
> > +     */
> > +    uint8_t transform_direction;
> >
>
> Av1, hevc and vp9 also have the concept of transform type.
>


Yeah, I think this should be renamed to "transform_type" and interpreted
based on codec ID.