[FFmpeg-devel] [PATCH] avutil: add API for mb_types
Ronald S. Bultje
rsbultje at gmail.com
Sun Nov 12 03:44:29 EET 2017
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.
> + /**
> + * 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.
For a lot of this, I think we want to be more specific and explicit how
these magic numbers (255, 254, -127) are mapped to concepts in
hevc/h264/av1/vp9. People using this API will want to use it for codecs
that are popular now. If we don't specify what it means for these codecs,
it'll be obsolete and useless before it's even introduced.
Ronald
More information about the ffmpeg-devel
mailing list