[FFmpeg-devel] [PATCH] avformat/rtpenc_chain: use the proper function to free AVFormatContext

Rostislav Pehlivanov atomnuker at gmail.com
Fri Apr 6 20:23:12 EEST 2018


On 6 April 2018 at 17:59, Vittorio Giovara <vittorio.giovara at gmail.com>
wrote:

> Yes the order of operations is a problem in a generic matrix, but for a
> display matrix the order is more or less consolidated in a defacto
> standard:
> check for flip first, then rotation. We have the same pattern in h264 and
> hevc decoder for the rotation side data.
>
> You are right that the description of the API does not convey the order
> and that it should be better documented, although I don't have a specific
> standard to quote (besides what is already mentioned in display.h).
>
> > > The "special cases" are also the most common operations that every
> player
> > > implements so I think it makes sense to have them readily available,
> with
> > > as few calls as possible.
> >
> > With what i suggest, not sure i explained it well enough
> > there would be a single call to provide a struct or array of 4 scalars
> > a 90 degree to the right rotation would for example have a
> > {90, 1, 1, 0} and could be checked for by memcmp() or a more specialized
> > function that returns a scalar "difference"
> > so testing for these common operations should be very simple and compact.
> > Testing for another angle of rotation or other transform would be
> similarly
> > simple.
>
>
> Well the only downside of that is that we are replacing a well-known set of
> instructions coded in a 3x3 matrix with a ffmpeg-only 4x1 array of
> integers.
> You would need special code and documentation to parse either the matrix or
> the array, so it kinda defies my attempt at simplifying the API: I feel
> like
> having a negative scale factor to represent a flip is as complex as having
> euclidean math to compute the rotation angle when the allowed orientations
> are just 4.
>
> On the other hand, I'm not strongly advocating for one way of another, if
> you could maybe point me to the right direction and share some code on how
> you mean the matrix parsing should be carried out I'll try to prepare a
> second version of this patch.
>
> Vittorio
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

I agree, I'd rather have a standard 3x3 matrix exposed than making
something new up.


More information about the ffmpeg-devel mailing list