On 12 November 2017 at 01:44, Ronald S. Bultje <rsbul...@gmail.com> wrote:
> Hi, > > On Sat, Nov 11, 2017 at 6:21 PM, Michael Niedermayer > <mich...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
