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

2018-04-06 Thread Rostislav Pehlivanov
On 6 April 2018 at 17:59, Vittorio Giovara 
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@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.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

2018-04-06 Thread Vittorio Giovara
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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel