> On Tue, Mar 25, 2014 at 3:48 PM, wm4 <nfxjfg at googlemail.com> wrote:
> > On Tue, 25 Mar 2014 15:31:49 +0100
> > Vittorio Giovara <vittorio.giovara at gmail.com> wrote:
> >
> >
> >> +
> >> + /**
> >> + * An AV_PKT_DATA_ROTATION side data packet contains further spatial
> >> information
> >> + * to be applied to the decoded video.
> >> + */
> >> + AV_PKT_DATA_DISPLAYORIENTATION,
> >> };
> >
> > Completely lacks documentation in what format the data is. It can be
> > easily inferred from the rest of the patch, but an API user reading
> > avcodec.h can't.
> >
> >
>
> True, I'll amend that.
>
> >> +/**
> >> + * Spatial transformation information that should be applied to video
> >> + * after decoding.
> >> + *
> >> + * Note that these values are not mutually exclusive.
> >> + *
> >> + * The size of this struct is a part of the public ABI.
> >> + */
> >> +typedef struct AVDisplayOrientation {
> >> + /**
> >> + * Video should be orizontally flipped.
> >> + */
> >> + int hflip;
> >> + /**
> >> + * Video should be vertically flipped.
> >> + */
> >> + int vflip;
> >> + /**
> >> + * Rotation angle to be applied in degrees.
> >> + */
> >> + int32_t rotation;
> >> +} AVDisplayOrientation;
> >
> > So, why not just export the full matrix?
>
> Overkill and HardMath imho.
If you do it like that, you need to document the order in which to process the
struct fields.
Also, when only exposing a reduced set of transform operations, why not be
consequent and reduce it as much as possible? A hflip can be expressed as a
vflip+180 rotation.
I still think something like this would be nicer:
enum {
transform_vflip,
transform_hflip,
transform_transpose, //obscure
transform_anti_transpose, //obscure
transform_rotate //use angle field
} transform_t;
typedef struct AVDisplayOrientation {
transform_t transform;
int32_t angle;
} AVDisplayOrientation;
> Vittorio
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
