Re: [FFmpeg-devel] [PATCH] avfilter/vf_rotate: add >8 bit depth support

[Muhammad Faiz]

On Mon, Jun 27, 2016 at 2:59 PM, Muhammad Faiz  wrote:
> On Sun, Jun 26, 2016 at 4:20 PM, Muhammad Faiz  wrote:
>> On Sun, Jun 26, 2016 at 3:22 PM, Paul B Mahol  wrote:
>>> On 6/26/16, Muhammad Faiz  wrote:
 On Sun, Jun 26, 2016 at 2:30 PM, Paul B Mahol  wrote:
> On 6/26/16, Carl Eugen Hoyos  wrote:
>> Muhammad Faiz  gmail.com> writes:
>>
>>> I think it's not because of bit-exact problem.
>>> But because fate probes supported formats (with
>>> libavfilter/tests/filtfmts)
>>> On BE machine, code with native formats will generate error
>>> because fate-ref contains yuv*le entries but fate expects yuv*be

 Another problem is that drawutils only support LE format.

>>
>> We control the fate test, so we can require an additional
>> (bit-exact) conversion from BE to LE to make the fate
>> test pass.
>
> Really, even for pixfmts?
>
> I will apply this as is. Feel free to add your hacks if you want, after.

 In the perspective of code correctness, this should be OK.
 But performance on BE machine will be unoptimal because:
  - reading/writing in foreign endian is probably slower
  - I guess most decoders' output frame is native endian. This will
make unnecessary format conversion
  - some other filters only support native endian formats. This will
also make unnecessary format conversion.

 Of course, the problem is not in your patch.
>>>
>>> Yes. BE is dead.
>>
>> The problem is in drawutils. I think, it should support native endian
>> or support both little/big endian.
>>
>> Thank's
>
> See https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195930.html
>
> Thank's

See also https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195941.html

Thank's
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_rotate: add >8 bit depth support

[Muhammad Faiz]

On Sun, Jun 26, 2016 at 4:20 PM, Muhammad Faiz  wrote:
> On Sun, Jun 26, 2016 at 3:22 PM, Paul B Mahol  wrote:
>> On 6/26/16, Muhammad Faiz  wrote:
>>> On Sun, Jun 26, 2016 at 2:30 PM, Paul B Mahol  wrote:
 On 6/26/16, Carl Eugen Hoyos  wrote:
> Muhammad Faiz  gmail.com> writes:
>
>> I think it's not because of bit-exact problem.
>> But because fate probes supported formats (with
>> libavfilter/tests/filtfmts)
>> On BE machine, code with native formats will generate error
>> because fate-ref contains yuv*le entries but fate expects yuv*be
>>>
>>> Another problem is that drawutils only support LE format.
>>>
>
> We control the fate test, so we can require an additional
> (bit-exact) conversion from BE to LE to make the fate
> test pass.

 Really, even for pixfmts?

 I will apply this as is. Feel free to add your hacks if you want, after.
>>>
>>> In the perspective of code correctness, this should be OK.
>>> But performance on BE machine will be unoptimal because:
>>>  - reading/writing in foreign endian is probably slower
>>>  - I guess most decoders' output frame is native endian. This will
>>>make unnecessary format conversion
>>>  - some other filters only support native endian formats. This will
>>>also make unnecessary format conversion.
>>>
>>> Of course, the problem is not in your patch.
>>
>> Yes. BE is dead.
>
> The problem is in drawutils. I think, it should support native endian
> or support both little/big endian.
>
> Thank's

See https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195930.html

Thank's
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_rotate: add >8 bit depth support

[Muhammad Faiz]

On Sun, Jun 26, 2016 at 3:22 PM, Paul B Mahol  wrote:
> On 6/26/16, Muhammad Faiz  wrote:
>> On Sun, Jun 26, 2016 at 2:30 PM, Paul B Mahol  wrote:
>>> On 6/26/16, Carl Eugen Hoyos  wrote:
 Muhammad Faiz  gmail.com> writes:

> I think it's not because of bit-exact problem.
> But because fate probes supported formats (with
> libavfilter/tests/filtfmts)
> On BE machine, code with native formats will generate error
> because fate-ref contains yuv*le entries but fate expects yuv*be
>>
>> Another problem is that drawutils only support LE format.
>>

 We control the fate test, so we can require an additional
 (bit-exact) conversion from BE to LE to make the fate
 test pass.
>>>
>>> Really, even for pixfmts?
>>>
>>> I will apply this as is. Feel free to add your hacks if you want, after.
>>
>> In the perspective of code correctness, this should be OK.
>> But performance on BE machine will be unoptimal because:
>>  - reading/writing in foreign endian is probably slower
>>  - I guess most decoders' output frame is native endian. This will
>>make unnecessary format conversion
>>  - some other filters only support native endian formats. This will
>>also make unnecessary format conversion.
>>
>> Of course, the problem is not in your patch.
>
> Yes. BE is dead.

The problem is in drawutils. I think, it should support native endian
or support both little/big endian.

Thank's
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_rotate: add >8 bit depth support

[Paul B Mahol]

On 6/26/16, Muhammad Faiz  wrote:
> On Sun, Jun 26, 2016 at 2:30 PM, Paul B Mahol  wrote:
>> On 6/26/16, Carl Eugen Hoyos  wrote:
>>> Muhammad Faiz  gmail.com> writes:
>>>
 I think it's not because of bit-exact problem.
 But because fate probes supported formats (with
 libavfilter/tests/filtfmts)
 On BE machine, code with native formats will generate error
 because fate-ref contains yuv*le entries but fate expects yuv*be
>
> Another problem is that drawutils only support LE format.
>
>>>
>>> We control the fate test, so we can require an additional
>>> (bit-exact) conversion from BE to LE to make the fate
>>> test pass.
>>
>> Really, even for pixfmts?
>>
>> I will apply this as is. Feel free to add your hacks if you want, after.
>
> In the perspective of code correctness, this should be OK.
> But performance on BE machine will be unoptimal because:
>  - reading/writing in foreign endian is probably slower
>  - I guess most decoders' output frame is native endian. This will
>make unnecessary format conversion
>  - some other filters only support native endian formats. This will
>also make unnecessary format conversion.
>
> Of course, the problem is not in your patch.

Yes. BE is dead.

>
> Thank's
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_rotate: add >8 bit depth support

[Muhammad Faiz]

On Sun, Jun 26, 2016 at 2:30 PM, Paul B Mahol  wrote:
> On 6/26/16, Carl Eugen Hoyos  wrote:
>> Muhammad Faiz  gmail.com> writes:
>>
>>> I think it's not because of bit-exact problem.
>>> But because fate probes supported formats (with
>>> libavfilter/tests/filtfmts)
>>> On BE machine, code with native formats will generate error
>>> because fate-ref contains yuv*le entries but fate expects yuv*be

Another problem is that drawutils only support LE format.

>>
>> We control the fate test, so we can require an additional
>> (bit-exact) conversion from BE to LE to make the fate
>> test pass.
>
> Really, even for pixfmts?
>
> I will apply this as is. Feel free to add your hacks if you want, after.

In the perspective of code correctness, this should be OK.
But performance on BE machine will be unoptimal because:
 - reading/writing in foreign endian is probably slower
 - I guess most decoders' output frame is native endian. This will
   make unnecessary format conversion
 - some other filters only support native endian formats. This will
   also make unnecessary format conversion.

Of course, the problem is not in your patch.

Thank's
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_rotate: add >8 bit depth support

[Hendrik Leppkes]

On Sun, Jun 26, 2016 at 9:30 AM, Paul B Mahol  wrote:
> On 6/26/16, Carl Eugen Hoyos  wrote:
>> Muhammad Faiz  gmail.com> writes:
>>
>>> I think it's not because of bit-exact problem.
>>> But because fate probes supported formats (with
>>> libavfilter/tests/filtfmts)
>>> On BE machine, code with native formats will generate error
>>> because fate-ref contains yuv*le entries but fate expects yuv*be
>>
>> We control the fate test, so we can require an additional
>> (bit-exact) conversion from BE to LE to make the fate
>> test pass.
>
> Really, even for pixfmts?
>
> I will apply this as is. Feel free to add your hacks if you want, after.

You force a conversion before your filter now for everyone on BE, the
alternative is to make fate force a conversion after your filter and
only for fate (same conversion, just at a different point in the
filter graph)
Most high-bitdepth tests already do this, simply by requesting a
defined pixfmt in the fate test.

Clearly less forced conversions is better?

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_rotate: add >8 bit depth support

[Paul B Mahol]

On 6/26/16, Carl Eugen Hoyos  wrote:
> Muhammad Faiz  gmail.com> writes:
>
>> I think it's not because of bit-exact problem.
>> But because fate probes supported formats (with
>> libavfilter/tests/filtfmts)
>> On BE machine, code with native formats will generate error
>> because fate-ref contains yuv*le entries but fate expects yuv*be
>
> We control the fate test, so we can require an additional
> (bit-exact) conversion from BE to LE to make the fate
> test pass.

Really, even for pixfmts?

I will apply this as is. Feel free to add your hacks if you want, after.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_rotate: add >8 bit depth support

[Carl Eugen Hoyos]

Muhammad Faiz  gmail.com> writes:

> I think it's not because of bit-exact problem.
> But because fate probes supported formats (with libavfilter/tests/filtfmts)
> On BE machine, code with native formats will generate error
> because fate-ref contains yuv*le entries but fate expects yuv*be

We control the fate test, so we can require an additional 
(bit-exact) conversion from BE to LE to make the fate 
test pass.

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_rotate: add >8 bit depth support

[Muhammad Faiz]

On Sun, Jun 26, 2016 at 1:51 AM, Paul B Mahol  wrote:
> On 6/25/16, Carl Eugen Hoyos  wrote:
>> Paul B Mahol  gmail.com> writes:
>>
>>> >>+AV_PIX_FMT_YUV420P9LE, AV_PIX_FMT_YUVA420P9LE,
>>> >
>>> > Why not use native endian format?
>>>
>>> Because of fate test.
>>
>> Isn't the byte-swapping (that could be used for the
>> fate test) bit-exact? Or do I miss something?
>
> What? There is bilinear option that have nothing to do with byte swapping.
>

I think it's not because of bit-exact problem.
But because fate probes supported formats (with libavfilter/tests/filtfmts)
On BE machine, code with native formats will generate error
because fate-ref contains yuv*le entries but fate expects yuv*be

Thank's
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_rotate: add >8 bit depth support

[Paul B Mahol]

On 6/25/16, Carl Eugen Hoyos  wrote:
> Paul B Mahol  gmail.com> writes:
>
>> >>+AV_PIX_FMT_YUV420P9LE, AV_PIX_FMT_YUVA420P9LE,
>> >
>> > Why not use native endian format?
>>
>> Because of fate test.
>
> Isn't the byte-swapping (that could be used for the
> fate test) bit-exact? Or do I miss something?

What? There is bilinear option that have nothing to do with byte swapping.

>
> Carl Eugen
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_rotate: add >8 bit depth support

[Carl Eugen Hoyos]

Paul B Mahol  gmail.com> writes:

> >>+AV_PIX_FMT_YUV420P9LE, AV_PIX_FMT_YUVA420P9LE,
> >
> > Why not use native endian format?
> 
> Because of fate test.

Isn't the byte-swapping (that could be used for the 
fate test) bit-exact? Or do I miss something?

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_rotate: add >8 bit depth support

[Paul B Mahol]

On 6/25/16, Muhammad Faiz  wrote:
> On Sat, Jun 25, 2016 at 1:23 AM, Paul B Mahol  wrote:
>> Hi,
>>
>> patch attached.
>>
>
> >From 5b55c9c44ea103cdff3c34882dbcca29902728a4 Mon Sep 17 00:00:00 2001
>>From: Paul B Mahol 
>>Date: Fri, 24 Jun 2016 20:16:22 +0200
>>Subject: [PATCH] avfilter/vf_rotate: add >8 bit depth support
>>
>>Signed-off-by: Paul B Mahol 
>>---
>> libavfilter/vf_rotate.c  | 171
>> ++-
>> tests/ref/fate/filter-pixfmts-rotate |  14 +++
>> 2 files changed, 123 insertions(+), 62 deletions(-)
>>
>
>
>>+AV_PIX_FMT_YUV420P10LE, AV_PIX_FMT_YUVA420P10LE,
>>+AV_PIX_FMT_YUV444P10LE, AV_PIX_FMT_YUVA444P10LE,
>>+AV_PIX_FMT_YUV420P12LE,
>>+AV_PIX_FMT_YUV444P12LE,
>>+AV_PIX_FMT_YUV444P16LE, AV_PIX_FMT_YUVA444P16LE,
>>+AV_PIX_FMT_YUV420P16LE, AV_PIX_FMT_YUVA420P16LE,
>>+AV_PIX_FMT_YUV444P9LE, AV_PIX_FMT_YUVA444P9LE,
>>+AV_PIX_FMT_YUV420P9LE, AV_PIX_FMT_YUVA420P9LE,
>
> Why not use native endian format?

Because of fate test. ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_rotate: add >8 bit depth support

[Muhammad Faiz]

On Sat, Jun 25, 2016 at 1:23 AM, Paul B Mahol  wrote:
> Hi,
>
> patch attached.
>

>From 5b55c9c44ea103cdff3c34882dbcca29902728a4 Mon Sep 17 00:00:00 2001
>From: Paul B Mahol 
>Date: Fri, 24 Jun 2016 20:16:22 +0200
>Subject: [PATCH] avfilter/vf_rotate: add >8 bit depth support
>
>Signed-off-by: Paul B Mahol 
>---
> libavfilter/vf_rotate.c  | 171 ++-
> tests/ref/fate/filter-pixfmts-rotate |  14 +++
> 2 files changed, 123 insertions(+), 62 deletions(-)
>


>+AV_PIX_FMT_YUV420P10LE, AV_PIX_FMT_YUVA420P10LE,
>+AV_PIX_FMT_YUV444P10LE, AV_PIX_FMT_YUVA444P10LE,
>+AV_PIX_FMT_YUV420P12LE,
>+AV_PIX_FMT_YUV444P12LE,
>+AV_PIX_FMT_YUV444P16LE, AV_PIX_FMT_YUVA444P16LE,
>+AV_PIX_FMT_YUV420P16LE, AV_PIX_FMT_YUVA420P16LE,
>+AV_PIX_FMT_YUV444P9LE, AV_PIX_FMT_YUVA444P9LE,
>+AV_PIX_FMT_YUV420P9LE, AV_PIX_FMT_YUVA420P9LE,

Why not use native endian format?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/vf_rotate: add >8 bit depth support

[Paul B Mahol]

Hi,

patch attached.
From 5b55c9c44ea103cdff3c34882dbcca29902728a4 Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Fri, 24 Jun 2016 20:16:22 +0200
Subject: [PATCH] avfilter/vf_rotate: add >8 bit depth support

Signed-off-by: Paul B Mahol 
---
 libavfilter/vf_rotate.c  | 171 ++-
 tests/ref/fate/filter-pixfmts-rotate |  14 +++
 2 files changed, 123 insertions(+), 62 deletions(-)

diff --git a/libavfilter/vf_rotate.c b/libavfilter/vf_rotate.c
index 47dc01e..b37685a 100644
--- a/libavfilter/vf_rotate.c
+++ b/libavfilter/vf_rotate.c
@@ -60,7 +60,7 @@ enum var_name {
 VAR_VARS_NB
 };
 
-typedef struct {
+typedef struct RotContext {
 const AVClass *class;
 double angle;
 char *angle_expr_str;   ///< expression for the angle
@@ -77,6 +77,9 @@ typedef struct {
 double var_values[VAR_VARS_NB];
 FFDrawContext draw;
 FFDrawColor color;
+uint8_t *(*interpolate_bilinear)(uint8_t *dst_color,
+const uint8_t *src, int src_linesize, int src_linestep,
+int x, int y, int max_x, int max_y);
 } RotContext;
 
 typedef struct ThreadData {
@@ -142,6 +145,14 @@ static int query_formats(AVFilterContext *ctx)
 AV_PIX_FMT_YUV444P,  AV_PIX_FMT_YUVJ444P,
 AV_PIX_FMT_YUV420P,  AV_PIX_FMT_YUVJ420P,
 AV_PIX_FMT_YUVA444P, AV_PIX_FMT_YUVA420P,
+AV_PIX_FMT_YUV420P10LE, AV_PIX_FMT_YUVA420P10LE,
+AV_PIX_FMT_YUV444P10LE, AV_PIX_FMT_YUVA444P10LE,
+AV_PIX_FMT_YUV420P12LE,
+AV_PIX_FMT_YUV444P12LE,
+AV_PIX_FMT_YUV444P16LE, AV_PIX_FMT_YUVA444P16LE,
+AV_PIX_FMT_YUV420P16LE, AV_PIX_FMT_YUVA420P16LE,
+AV_PIX_FMT_YUV444P9LE, AV_PIX_FMT_YUVA444P9LE,
+AV_PIX_FMT_YUV420P9LE, AV_PIX_FMT_YUVA420P9LE,
 AV_PIX_FMT_NONE
 };
 
@@ -187,6 +198,93 @@ static const char * const func1_names[] = {
 NULL
 };
 
+#define FIXP (1<<16)
+#define FIXP2 (1<<20)
+#define INT_PI 3294199 //(M_PI * FIXP2)
+
+/**
+ * Compute the sin of a using integer values.
+ * Input is scaled by FIXP2 and output values are scaled by FIXP.
+ */
+static int64_t int_sin(int64_t a)
+{
+int64_t a2, res = 0;
+int i;
+if (a < 0) a = INT_PI-a; // 0..inf
+a %= 2 * INT_PI; // 0..2PI
+
+if (a >= INT_PI*3/2) a -= 2*INT_PI;  // -PI/2 .. 3PI/2
+if (a >= INT_PI/2  ) a = INT_PI - a; // -PI/2 ..  PI/2
+
+/* compute sin using Taylor series approximated to the fifth term */
+a2 = (a*a)/(FIXP2);
+for (i = 2; i < 11; i += 2) {
+res += a;
+a = -a*a2 / (FIXP2*i*(i+1));
+}
+return (res + 8)>>4;
+}
+
+/**
+ * Interpolate the color in src at position x and y using bilinear
+ * interpolation.
+ */
+static uint8_t *interpolate_bilinear8(uint8_t *dst_color,
+  const uint8_t *src, int src_linesize, int src_linestep,
+  int x, int y, int max_x, int max_y)
+{
+int int_x = av_clip(x>>16, 0, max_x);
+int int_y = av_clip(y>>16, 0, max_y);
+int frac_x = x&0x;
+int frac_y = y&0x;
+int i;
+int int_x1 = FFMIN(int_x+1, max_x);
+int int_y1 = FFMIN(int_y+1, max_y);
+
+for (i = 0; i < src_linestep; i++) {
+int s00 = src[src_linestep * int_x  + i + src_linesize * int_y ];
+int s01 = src[src_linestep * int_x1 + i + src_linesize * int_y ];
+int s10 = src[src_linestep * int_x  + i + src_linesize * int_y1];
+int s11 = src[src_linestep * int_x1 + i + src_linesize * int_y1];
+int s0 = (((1<<16) - frac_x)*s00 + frac_x*s01);
+int s1 = (((1<<16) - frac_x)*s10 + frac_x*s11);
+
+dst_color[i] = ((int64_t)((1<<16) - frac_y)*s0 + (int64_t)frac_y*s1) >> 32;
+}
+
+return dst_color;
+}
+
+/**
+ * Interpolate the color in src at position x and y using bilinear
+ * interpolation.
+ */
+static uint8_t *interpolate_bilinear16(uint8_t *dst_color,
+   const uint8_t *src, int src_linesize, int src_linestep,
+   int x, int y, int max_x, int max_y)
+{
+int int_x = av_clip(x>>16, 0, max_x);
+int int_y = av_clip(y>>16, 0, max_y);
+int frac_x = x&0x;
+int frac_y = y&0x;
+int i;
+int int_x1 = FFMIN(int_x+1, max_x);
+int int_y1 = FFMIN(int_y+1, max_y);
+
+for (i = 0; i < src_linestep; i+=2) {
+int s00 = AV_RL16([src_linestep * int_x  + i + src_linesize * int_y ]);
+int s01 = AV_RL16([src_linestep * int_x1 + i + src_linesize * int_y ]);
+int s10 = AV_RL16([src_linestep * int_x  + i + src_linesize * int_y1]);
+int s11 = AV_RL16([src_linestep * int_x1 + i + src_linesize * int_y1]);
+int s0 = (((1<<16) - frac_x)*s00 + frac_x*s01);
+int s1 = (((1<<16) - frac_x)*s10 + frac_x*s11);
+
+AV_WL16(_color[i], ((int64_t)((1<<16) - frac_y)*s0 + (int64_t)frac_y*s1) >> 32);
+}
+
+return