Re: [FFmpeg-devel] [PATCH]lavc/utvideo: Use "&" instead of "&&" in expressions with "~"

[Ronald S. Bultje]

Hi,

On Sat, Oct 7, 2017 at 7:05 PM, Carl Eugen Hoyos  wrote:

> Hi!
>
> Attached patch silences two warnings when compiling with gcc-7:
> libavcodec/utvideodec.c:242:107: warning: ‘~’ on a boolean expression
> [-Wbool-operation]
>  const int cmask = c->interlaced ? ~(1 + 2 * (!plane_no &&
> c->avctx->pix_fmt == AV_PIX_FMT_YUV420P)) : ~(!plane_no &&
> c->avctx->pix_fmt == AV_PIX_FMT_YUV420P);
>
> Please comment, Carl Eugen
>

I personally think the warning is dumb... But I guess that's just me.

(I understand why it exists for javascript developers dipping their toes in
My First Pony C. But we're not these kind of developers.)

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

Re: [FFmpeg-devel] [RFC]lavu/opt: Use && instead of * in boolean expression

[Ronald S. Bultje]

Hi,

On Sat, Oct 7, 2017 at 7:14 PM, Carl Eugen Hoyos  wrote:

> 2017-05-05 1:32 GMT+02:00 Carl Eugen Hoyos :
> > Hi!
> >
> > It may be better to disable the warning.
>
> Ping, one of the two patches should be applied,
> we currently have one vote for each.
>

I'd go for && since it's boolean. No strong opinion though.

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

Re: [FFmpeg-devel] [RFC]lavu/opt: Use && instead of * in boolean expression

[Carl Eugen Hoyos]

2017-05-05 1:32 GMT+02:00 Carl Eugen Hoyos :
> Hi!
>
> It may be better to disable the warning.

Ping, one of the two patches should be applied,
we currently have one vote for each.

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

[FFmpeg-devel] [PATCH]lavc/utvideo: Use "&" instead of "&&" in expressions with "~"

[Carl Eugen Hoyos]

Hi!

Attached patch silences two warnings when compiling with gcc-7:
libavcodec/utvideodec.c:242:107: warning: ‘~’ on a boolean expression
[-Wbool-operation]
 const int cmask = c->interlaced ? ~(1 + 2 * (!plane_no &&
c->avctx->pix_fmt == AV_PIX_FMT_YUV420P)) : ~(!plane_no &&
c->avctx->pix_fmt == AV_PIX_FMT_YUV420P);

Please comment, Carl Eugen
From 5fa1b443d1603d7d2d4860d43a7aefa7196c3cdb Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 8 Oct 2017 01:02:01 +0200
Subject: [PATCH] lavc/utvideo: Use "&" instead of "&&" in expressions with
 "~".

Silences two warnings with gcc-7:
warning: "~" on a boolean expression
---
 libavcodec/utvideodec.c |2 +-
 libavcodec/utvideoenc.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/utvideodec.c b/libavcodec/utvideodec.c
index 40c1277..101b3a6 100644
--- a/libavcodec/utvideodec.c
+++ b/libavcodec/utvideodec.c
@@ -239,7 +239,7 @@ static int decode_plane(UtvideoContext *c, int plane_no,
 VLC vlc;
 GetBitContext gb;
 int prev, fsym;
-const int cmask = c->interlaced ? ~(1 + 2 * (!plane_no && c->avctx->pix_fmt == AV_PIX_FMT_YUV420P)) : ~(!plane_no && c->avctx->pix_fmt == AV_PIX_FMT_YUV420P);
+const int cmask = c->interlaced ? ~(1 + 2 * (!plane_no && c->avctx->pix_fmt == AV_PIX_FMT_YUV420P)) : ~(!plane_no & c->avctx->pix_fmt == AV_PIX_FMT_YUV420P);
 
 if (build_huff(src, &vlc, &fsym)) {
 av_log(c->avctx, AV_LOG_ERROR, "Cannot build Huffman codes\n");
diff --git a/libavcodec/utvideoenc.c b/libavcodec/utvideoenc.c
index 840742c..96607d8 100644
--- a/libavcodec/utvideoenc.c
+++ b/libavcodec/utvideoenc.c
@@ -409,7 +409,7 @@ static int encode_plane(AVCodecContext *avctx, uint8_t *src,
 HuffEntry he[256];
 
 uint32_t offset = 0, slice_len = 0;
-const int cmask = ~(!plane_no && avctx->pix_fmt == AV_PIX_FMT_YUV420P);
+const int cmask = ~(!plane_no & avctx->pix_fmt == AV_PIX_FMT_YUV420P);
 int  i, sstart, send = 0;
 int  symbol;
 int  ret;
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter

[Michael Niedermayer]

On Sat, Oct 07, 2017 at 11:39:40AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Sat, Oct 7, 2017 at 6:25 AM, Michael Niedermayer 
> wrote:
> 
> > On Sat, Oct 07, 2017 at 12:12:15PM +0200, Michael Niedermayer wrote:
> > > > > On Fri, Oct 06, 2017 at 10:03:16AM -0400, Ronald S. Bultje wrote:
> > > > >> I'm open to any alternative method you suggest.
> >
>  [..]
> 
> > > About a solution, I didnt write alot about solutions as iam really fine
> > > with any solution. There are many possible solutions ...
> > > The libavfilter/af_astats.c filter i mentioned outputs statistics
> > > via metadata
> >
> [..]
> 
> > > There are other possibilities. Also Hendriks suggestion about
> > > turning metadata via some other application option into a file sounds
> > > pretty good to me
> >
> 
> psnr/ssim/vmafmotion indeed use per-frame metadata, but that unfortunately
> doesn't address the use case of using ffmpeg to quickly dump some per-frame
> stats to a file (or stdout) for quick comparison/verification (e.g. compare
> against Netflix' vmaf code reference scores) since we don't print frame
> metadata anywhere.
> 
> If someone does what Hendrik suggests (turning metadata into a file or into
> a log) then indeed there is no problem.
> 
> 
> > > or av_log as 2 alternatives to direct file write.
> >
> 
> av_log would be simpler, yes.
> 
> yet another solution (if people dislike all suggestions so far) would
> > be adding a flag to filters which are safe to use with untrusted
> > parameters. Or a flag to options which are unsafe so they are blocked
> > from being set from an untrusted input string
> >
> 
> I actually considered this myself, but didn't want to propose it because I
> personally thought it was a little hacky... I'm not against it, though.
> 
> Of these, I probably like the first one best (having some way of writing
> per-frame metadata generically to stdout or to a file, without explicit
> options), but it may also be the most complex one. Any takers to implement
> this?

if theres some consensus on what to implement, iam volunteering to
help implementing it.

(a)metadata as paul mentioned is not a complete solution as it itself
turns a filter parameter into a path to write to.

We can also leave this all as it is and just document that the filter
graph description string and some filter parameters must not be from
untrusted sources if people want to allow/support/have filters that
write to user specified pathes directly.

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/yuv4mpeg: add gray9/10/12 support

[Paul B Mahol]

On 10/7/17, Mateusz  wrote:
> Lately ffmpeg supports gray9/10/12 pixel formats.
>
> This patch adds gray9/10/12 pixel formats to y4m.
>
> It also moves gray16 to 'strict -1' section.
>
> Please review.
>
> Mateusz
>
>

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

Re: [FFmpeg-devel] [PATCH]lavf/protocols: Add a cast to silence a warning

[Carl Eugen Hoyos]

2017-10-02 14:38 GMT+02:00 Carl Eugen Hoyos :
> Hi!
>
> Attached patch fixes the following warning:
> libavformat/protocols.c:100:7: warning: assignment discards ‘const’
> qualifier from pointer target type

Ping, better suggestions very welcome.

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

[FFmpeg-devel] [PATCH] avformat/yuv4mpeg: add gray9/10/12 support

[Mateusz]

Lately ffmpeg supports gray9/10/12 pixel formats.

This patch adds gray9/10/12 pixel formats to y4m.

It also moves gray16 to 'strict -1' section.

Please review.

Mateusz

From f2b31ef66931e02a355e3140d47b17f0d307dec7 Mon Sep 17 00:00:00 2001
From: Mateusz 
Date: Sat, 7 Oct 2017 19:05:53 +0200
Subject: [PATCH] avformat/yuv4mpeg: add gray9/10/12 support

Signed-off-by: Mateusz Brzostek 
---
 libavformat/yuv4mpegdec.c |  6 ++
 libavformat/yuv4mpegenc.c | 23 ---
 2 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/libavformat/yuv4mpegdec.c b/libavformat/yuv4mpegdec.c
index 462b823860..ff0125e4cf 100644
--- a/libavformat/yuv4mpegdec.c
+++ b/libavformat/yuv4mpegdec.c
@@ -126,6 +126,12 @@ static int yuv4_read_header(AVFormatContext *s)
 pix_fmt = AV_PIX_FMT_YUV444P;
 } else if (strncmp("mono16", tokstart, 6) == 0) {
 pix_fmt = AV_PIX_FMT_GRAY16;
+} else if (strncmp("mono12", tokstart, 6) == 0) {
+pix_fmt = AV_PIX_FMT_GRAY12;
+} else if (strncmp("mono10", tokstart, 6) == 0) {
+pix_fmt = AV_PIX_FMT_GRAY10;
+} else if (strncmp("mono9", tokstart, 5) == 0) {
+pix_fmt = AV_PIX_FMT_GRAY9;
 } else if (strncmp("mono", tokstart, 4) == 0) {
 pix_fmt = AV_PIX_FMT_GRAY8;
 } else {
diff --git a/libavformat/yuv4mpegenc.c b/libavformat/yuv4mpegenc.c
index b4dc6e9ef6..44f40bbad9 100644
--- a/libavformat/yuv4mpegenc.c
+++ b/libavformat/yuv4mpegenc.c
@@ -69,6 +69,15 @@ static int yuv4_generate_header(AVFormatContext *s, char* 
buf)
 case AV_PIX_FMT_GRAY8:
 colorspace = " Cmono";
 break;
+case AV_PIX_FMT_GRAY9:
+colorspace = " Cmono9";
+break;
+case AV_PIX_FMT_GRAY10:
+colorspace = " Cmono10";
+break;
+case AV_PIX_FMT_GRAY12:
+colorspace = " Cmono12";
+break;
 case AV_PIX_FMT_GRAY16:
 colorspace = " Cmono16";
 break;
@@ -184,6 +193,9 @@ static int yuv4_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 case AV_PIX_FMT_YUV422P:
 case AV_PIX_FMT_YUV444P:
 break;
+case AV_PIX_FMT_GRAY9:
+case AV_PIX_FMT_GRAY10:
+case AV_PIX_FMT_GRAY12:
 case AV_PIX_FMT_GRAY16:
 case AV_PIX_FMT_YUV420P9:
 case AV_PIX_FMT_YUV422P9:
@@ -213,7 +225,8 @@ static int yuv4_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 ptr += frame->linesize[0];
 }
 
-if (st->codecpar->format != AV_PIX_FMT_GRAY8 &&
+if (st->codecpar->format != AV_PIX_FMT_GRAY8 && st->codecpar->format != 
AV_PIX_FMT_GRAY9 &&
+st->codecpar->format != AV_PIX_FMT_GRAY10 && st->codecpar->format != 
AV_PIX_FMT_GRAY12 &&
 st->codecpar->format != AV_PIX_FMT_GRAY16) {
 // Adjust for smaller Cb and Cr planes
 av_pix_fmt_get_chroma_sub_sample(st->codecpar->format, &h_chroma_shift,
@@ -255,11 +268,14 @@ static int yuv4_write_header(AVFormatContext *s)
"stream, some mjpegtools might not work.\n");
 break;
 case AV_PIX_FMT_GRAY8:
-case AV_PIX_FMT_GRAY16:
 case AV_PIX_FMT_YUV420P:
 case AV_PIX_FMT_YUV422P:
 case AV_PIX_FMT_YUV444P:
 break;
+case AV_PIX_FMT_GRAY9:
+case AV_PIX_FMT_GRAY10:
+case AV_PIX_FMT_GRAY12:
+case AV_PIX_FMT_GRAY16:
 case AV_PIX_FMT_YUV420P9:
 case AV_PIX_FMT_YUV422P9:
 case AV_PIX_FMT_YUV444P9:
@@ -291,7 +307,8 @@ static int yuv4_write_header(AVFormatContext *s)
"yuv444p10, yuv422p10, yuv420p10, "
"yuv444p12, yuv422p12, yuv420p12, "
"yuv444p14, yuv422p14, yuv420p14, "
-   "yuv444p16, yuv422p16, yuv420p16 "
+   "yuv444p16, yuv422p16, yuv420p16, "
+   "gray9, gray10, gray12 "
"and gray16 pixel formats. "
"Use -pix_fmt to select one.\n");
 return AVERROR(EIO);
-- 
2.14.2.windows.1

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

Re: [FFmpeg-devel] [PATCH]configure: Add -Wno-main

[Carl Eugen Hoyos]

2017-10-07 16:04 GMT+02:00 James Almer :
> On 10/7/2017 11:02 AM, Carl Eugen Hoyos wrote:
>> One possibility attached.
>>
>> Please comment, Carl Eugen
>>
>>
>> 0001-lavfi-Rename-local-variables-main-as-master.patch
>>
>>
>> From 0876a93917c8fe06a3d9b748c39e4f643c2ecd02 Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Sat, 7 Oct 2017 15:59:22 +0200
>> Subject: [PATCH] lavfi: Rename local variables "main" as "master".
>>
>> Silences several warnings:
>> main is usually a function
>> ---
>>  libavfilter/vf_lut3d.c  |8 
>>  libavfilter/vf_paletteuse.c |   10 +-
>>  libavfilter/vf_psnr.c   |   14 +++---
>>  libavfilter/vf_ssim.c   |   12 ++--
>>  4 files changed, 22 insertions(+), 22 deletions(-)
>
> LGTM

Patch applied.

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

Re: [FFmpeg-devel] [PATCH]lavf/sdp: Fix MIME-type for big-endian G.726 audio.

[Carl Eugen Hoyos]

2017-10-07 17:19 GMT+02:00 Michael Niedermayer :
> On Sat, Aug 26, 2017 at 11:53:46AM +0200, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch follows RFC 3551, a followup patch adds little-endian
>> G.726 with the old MIME-type.
>>
>> Please comment, Carl Eugen
>
>>  sdp.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 764023f2cf781b005fba6baf777543fe298eca9f  
>> 0001-lavf-sdp-Fix-MIME-type-for-big-endian-G.726.patch
>> From 6ee9178dfad75c4fdb1556e929a59c9d80f0976d Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Sat, 26 Aug 2017 11:46:18 +0200
>> Subject: [PATCH 1/2] lavf/sdp: Fix MIME-type for big-endian G.726.
>>
>> RFC 3551 defines "AAL2-G726" for big-endian ("left-justified") G.726
>> and "G726" for little-endian ("right-justified") G.726.
>
> if thats what the rfc says then its obviously ok
>
> the micro version should be bumped for every muxer fix

Done and pushed with slightly changed commit message.

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

Re: [FFmpeg-devel] [PATCH]lavf/rtpenc: Add support for little-endian G.726

[Carl Eugen Hoyos]

2017-10-07 17:20 GMT+02:00 Michael Niedermayer :
> On Sat, Aug 26, 2017 at 11:55:00AM +0200, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch adds little-endian G.726 support to rtpenc, using the
>> MIME-type suggested by RFC 3551.
>>
>> Please comment, Carl Eugen
>
>>  rtpenc.c |2 ++
>>  sdp.c|8 
>>  2 files changed, 10 insertions(+)
>> 78e9d392d1aa04b837fd97c6f8a08254039f7d5e  
>> 0002-lavf-rtpenc-Add-support-for-little-endian-G.726.patch
>> From 5834684eb2692fbc10f9e70ced66cedab661a828 Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Sat, 26 Aug 2017 11:49:46 +0200
>> Subject: [PATCH 2/2] lavf/rtpenc: Add support for little-endian G.726.
>
> if thats what the rfc says then its oviously ok

Patch applied with version bump and Changelog entry.

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter

[Paul B Mahol]

On 10/7/17, Ronald S. Bultje  wrote:
> Hi,
>
> On Sat, Oct 7, 2017 at 6:25 AM, Michael Niedermayer 
> wrote:
>
>> On Sat, Oct 07, 2017 at 12:12:15PM +0200, Michael Niedermayer wrote:
>> > > > On Fri, Oct 06, 2017 at 10:03:16AM -0400, Ronald S. Bultje
>> > > > wrote:
>> > > >> I'm open to any alternative method you suggest.
>>
>  [..]
>
>> > About a solution, I didnt write alot about solutions as iam really fine
>> > with any solution. There are many possible solutions ...
>> > The libavfilter/af_astats.c filter i mentioned outputs statistics
>> > via metadata
>>
> [..]
>
>> > There are other possibilities. Also Hendriks suggestion about
>> > turning metadata via some other application option into a file sounds
>> > pretty good to me
>>
>
> psnr/ssim/vmafmotion indeed use per-frame metadata, but that unfortunately
> doesn't address the use case of using ffmpeg to quickly dump some per-frame
> stats to a file (or stdout) for quick comparison/verification (e.g. compare
> against Netflix' vmaf code reference scores) since we don't print frame
> metadata anywhere.
>
> If someone does what Hendrik suggests (turning metadata into a file or into
> a log) then indeed there is no problem.

There is (a)metadata filter.

>
>
>> > or av_log as 2 alternatives to direct file write.
>>
>
> av_log would be simpler, yes.
>
> yet another solution (if people dislike all suggestions so far) would
>> be adding a flag to filters which are safe to use with untrusted
>> parameters. Or a flag to options which are unsafe so they are blocked
>> from being set from an untrusted input string
>>
>
> I actually considered this myself, but didn't want to propose it because I
> personally thought it was a little hacky... I'm not against it, though.
>
> Of these, I probably like the first one best (having some way of writing
> per-frame metadata generically to stdout or to a file, without explicit
> options), but it may also be the most complex one. Any takers to implement
> this?
>
> Ronald
> ___
> 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] libavcodec/proresdec : add qmat dsp with SSE2, AVX2 simd

[Ronald S. Bultje]

Hi Martin,

On Sat, Oct 7, 2017 at 11:49 AM, Martin Vignali 
wrote:

> 2017-10-07 17:30 GMT+02:00 Ronald S. Bultje :
> > On Sat, Oct 7, 2017 at 10:22 AM, Martin Vignali <
> martin.vign...@gmail.com>
> > wrote:
> > > Patch in attach add a new dsp
> > > for manipulation of qmat
> > >
> > > for now, i move this code inside
> > >
> > > for (i = 0; i < 64; i++) {
> > > qmat_luma_scaled  [i] = ctx->qmat_luma  [i] * qscale;
> > > qmat_chroma_scaled[i] = ctx->qmat_chroma[i] * qscale;
> > > }
> > >
> > > i add a special case for qscale == 1
> > > and SSE2, AVX2 optimization
> >
> > This loop only executes once per slice. We typically do not SIMD-optimize
> > at that level, because it won't give significant speed gains...
>
> Ok didn't know that.
> I mostly follow, what there are already done, like in blockdsp.clear_block
>

Right, so consider that blockdsp is done per block (16x16 pixels), not per
slice.

You could remove this entirely from the slice processing code by simply
pre-calculating the values in the init function once for the whole stream,
there's only 224 qscale values so it's 224*64*2 multiplications, which is
(in the context of prores) virtually negligible.

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

Re: [FFmpeg-devel] libavcodec/proresdec : add qmat dsp with SSE2, AVX2 simd

[Martin Vignali]

2017-10-07 17:30 GMT+02:00 Ronald S. Bultje :

> Hi Martin,
>
> On Sat, Oct 7, 2017 at 10:22 AM, Martin Vignali 
> wrote:
>
> > Hello,
> >
> > Patch in attach add a new dsp
> > for manipulation of qmat
> >
> > for now, i move this code inside
> >
> > for (i = 0; i < 64; i++) {
> > qmat_luma_scaled  [i] = ctx->qmat_luma  [i] * qscale;
> > qmat_chroma_scaled[i] = ctx->qmat_chroma[i] * qscale;
> > }
> >
> > i add a special case for qscale == 1
> > and SSE2, AVX2 optimization
> >
>
> This loop only executes once per slice. We typically do not SIMD-optimize
> at that level, because it won't give significant speed gains...
>

Ok didn't know that.
I mostly follow, what there are already done, like in blockdsp.clear_block,
is not call so often in a frame, and the speed gain (when the simd is not
slower (see
the discussion libavcodec/blockdsp : add clear_blocks_prores
) is not very sensitive with some compiler (even with checkasm)

Drop this patch in any case


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

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter

[Ronald S. Bultje]

Hi,

On Sat, Oct 7, 2017 at 6:25 AM, Michael Niedermayer 
wrote:

> On Sat, Oct 07, 2017 at 12:12:15PM +0200, Michael Niedermayer wrote:
> > > > On Fri, Oct 06, 2017 at 10:03:16AM -0400, Ronald S. Bultje wrote:
> > > >> I'm open to any alternative method you suggest.
>
 [..]

> > About a solution, I didnt write alot about solutions as iam really fine
> > with any solution. There are many possible solutions ...
> > The libavfilter/af_astats.c filter i mentioned outputs statistics
> > via metadata
>
[..]

> > There are other possibilities. Also Hendriks suggestion about
> > turning metadata via some other application option into a file sounds
> > pretty good to me
>

psnr/ssim/vmafmotion indeed use per-frame metadata, but that unfortunately
doesn't address the use case of using ffmpeg to quickly dump some per-frame
stats to a file (or stdout) for quick comparison/verification (e.g. compare
against Netflix' vmaf code reference scores) since we don't print frame
metadata anywhere.

If someone does what Hendrik suggests (turning metadata into a file or into
a log) then indeed there is no problem.


> > or av_log as 2 alternatives to direct file write.
>

av_log would be simpler, yes.

yet another solution (if people dislike all suggestions so far) would
> be adding a flag to filters which are safe to use with untrusted
> parameters. Or a flag to options which are unsafe so they are blocked
> from being set from an untrusted input string
>

I actually considered this myself, but didn't want to propose it because I
personally thought it was a little hacky... I'm not against it, though.

Of these, I probably like the first one best (having some way of writing
per-frame metadata generically to stdout or to a file, without explicit
options), but it may also be the most complex one. Any takers to implement
this?

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter

[Ronald S. Bultje]

Hi,

On Sat, Oct 7, 2017 at 5:09 AM, Nicolas George  wrote:

> Le quintidi 15 vendémiaire, an CCXXVI, Ronald S. Bultje a écrit :
> > The same mechanism is present in ssim/psnr filters.
>
> This is true. But how do you think it came to happen?
>

Calm down guys, I said in the next sentence I'm open to alternatives. I
meant that if we fix it here, we need to fix it in the others also. I'd
like the method chosen in each metric filter to be consistent.

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

Re: [FFmpeg-devel] libavcodec/proresdec : add qmat dsp with SSE2, AVX2 simd

[Ronald S. Bultje]

Hi Martin,

On Sat, Oct 7, 2017 at 10:22 AM, Martin Vignali 
wrote:

> Hello,
>
> Patch in attach add a new dsp
> for manipulation of qmat
>
> for now, i move this code inside
>
> for (i = 0; i < 64; i++) {
> qmat_luma_scaled  [i] = ctx->qmat_luma  [i] * qscale;
> qmat_chroma_scaled[i] = ctx->qmat_chroma[i] * qscale;
> }
>
> i add a special case for qscale == 1
> and SSE2, AVX2 optimization
>

This loop only executes once per slice. We typically do not SIMD-optimize
at that level, because it won't give significant speed gains...

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

Re: [FFmpeg-devel] [PATCH]lavf/rtpenc: Add support for little-endian G.726

[Michael Niedermayer]

On Sat, Aug 26, 2017 at 11:55:00AM +0200, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch adds little-endian G.726 support to rtpenc, using the
> MIME-type suggested by RFC 3551.
> 
> Please comment, Carl Eugen

>  rtpenc.c |2 ++
>  sdp.c|8 
>  2 files changed, 10 insertions(+)
> 78e9d392d1aa04b837fd97c6f8a08254039f7d5e  
> 0002-lavf-rtpenc-Add-support-for-little-endian-G.726.patch
> From 5834684eb2692fbc10f9e70ced66cedab661a828 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sat, 26 Aug 2017 11:49:46 +0200
> Subject: [PATCH 2/2] lavf/rtpenc: Add support for little-endian G.726.

if thats what the rfc says then its oviously ok

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/sdp: Fix MIME-type for big-endian G.726 audio.

[Michael Niedermayer]

On Sat, Aug 26, 2017 at 11:53:46AM +0200, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch follows RFC 3551, a followup patch adds little-endian
> G.726 with the old MIME-type.
> 
> Please comment, Carl Eugen

>  sdp.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 764023f2cf781b005fba6baf777543fe298eca9f  
> 0001-lavf-sdp-Fix-MIME-type-for-big-endian-G.726.patch
> From 6ee9178dfad75c4fdb1556e929a59c9d80f0976d Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sat, 26 Aug 2017 11:46:18 +0200
> Subject: [PATCH 1/2] lavf/sdp: Fix MIME-type for big-endian G.726.
> 
> RFC 3551 defines "AAL2-G726" for big-endian ("left-justified") G.726
> and "G726" for little-endian ("right-justified") G.726.

if thats what the rfc says then its obviously ok

the micro version should be bumped for every muxer fix

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/proresdec : add qmat dsp with SSE2, AVX2 simd

[Carl Eugen Hoyos]

2017-10-07 16:52 GMT+02:00 Martin Vignali :
> 2017-10-07 16:30 GMT+02:00 Carl Eugen Hoyos :
>
>> 2017-10-07 16:22 GMT+02:00 Martin Vignali :
>>
>> > Patch in attach add a new dsp
>> > for manipulation of qmat
>>
>> Is there a measurable effect on overall decoding?
>
> No. I have too much variation using benchmark, to measure a little
> optimization.

> But i make this, because prores is a widely use codec, and there
> is already some litlle optimization inside this decoder

I did not want to imply that above is necessary.

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

Re: [FFmpeg-devel] libavcodec/hap : add HapAlphaOnly decoding/encoding

[Carl Eugen Hoyos]

2017-10-07 16:32 GMT+02:00 Martin Vignali :
>>
>> > IMO, the ffmpeg support is mostly interesting to convert hap
>> > file to something else or to check what we can encode with
>> > the ffmpeg hap encoder.
>>
>> I don't disagree (on the contrary), I believe we should make it
>> as easy as possible for users to work with it:
>> Do you believe that it would be easier for users if HAP alpha only
>> is represented as FFmpeg RGBA or gray?
>
> IMHO, from a compositing point of view, alpha only and gray is
> the same thing.
> It's common (in cgi compositing for example), to use alpha (or
> matte) as separate gray only file.

If this is what you believe, I don't think an RGBA representation
should be committed.

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

Re: [FFmpeg-devel] libavcodec/proresdec : add qmat dsp with SSE2, AVX2 simd

[Martin Vignali]

2017-10-07 16:30 GMT+02:00 Carl Eugen Hoyos :

> 2017-10-07 16:22 GMT+02:00 Martin Vignali :
>
> > Patch in attach add a new dsp
> > for manipulation of qmat
>
> Is there a measurable effect on overall decoding?
>
> No. I have too much variation using benchmark, to measure a little
optimization.
But i make this, because prores is a widely use codec, and there is already
some litlle optimization inside this decoder
(like blockdsp)

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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Carl Eugen Hoyos]

2017-10-01 18:23 GMT+02:00 Carl Eugen Hoyos :
> 2017-09-27 18:08 GMT+02:00 Carl Eugen Hoyos :
>
>> The existing amr demuxer does not allow reading streams,
>> it requires the 3GPP-conforming file header.
>> Attached patch allows reading amrnb and amrwb from (live)
>> streams, fixes ticket #6678.
>
> New patch with auto-detection attached, passes probecheck.

Simplified patch attached that does not duplicate two small arrays
in the object file that are already duplicated in the source code.
The uninitialized variable is also fixed.

I intend to apply soon, Carl Eugen
From 0f6592b1b7e3d01dd5c853b3269c4d47d49fed9f Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 7 Oct 2017 16:50:55 +0200
Subject: [PATCH] lavf/amr: Add amrnb and amrwb demuxers.

Fixes ticket #6678.
---
 libavformat/Makefile |2 +
 libavformat/allformats.c |2 +
 libavformat/amr.c|  116 ++
 libavformat/version.h|4 +-
 4 files changed, 112 insertions(+), 12 deletions(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index df709c29..c4c8713 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -87,6 +87,8 @@ OBJS-$(CONFIG_AIFF_MUXER)+= aiffenc.o id3v2enc.o
 OBJS-$(CONFIG_AIX_DEMUXER)   += aixdec.o
 OBJS-$(CONFIG_AMR_DEMUXER)   += amr.o
 OBJS-$(CONFIG_AMR_MUXER) += amr.o
+OBJS-$(CONFIG_AMRNB_DEMUXER) += amr.o
+OBJS-$(CONFIG_AMRWB_DEMUXER) += amr.o
 OBJS-$(CONFIG_ANM_DEMUXER)   += anm.o
 OBJS-$(CONFIG_APC_DEMUXER)   += apc.o
 OBJS-$(CONFIG_APE_DEMUXER)   += ape.o apetag.o img2.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 405ddb5..dc8984e 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -63,6 +63,8 @@ static void register_all(void)
 REGISTER_MUXDEMUX(AIFF, aiff);
 REGISTER_DEMUXER (AIX,  aix);
 REGISTER_MUXDEMUX(AMR,  amr);
+REGISTER_DEMUXER (AMRNB,amrnb);
+REGISTER_DEMUXER (AMRWB,amrwb);
 REGISTER_DEMUXER (ANM,  anm);
 REGISTER_DEMUXER (APC,  apc);
 REGISTER_DEMUXER (APE,  ape);
diff --git a/libavformat/amr.c b/libavformat/amr.c
index b5194a2..da2e28b 100644
--- a/libavformat/amr.c
+++ b/libavformat/amr.c
@@ -38,6 +38,14 @@ typedef struct {
 static const char AMR_header[]   = "#!AMR\n";
 static const char AMRWB_header[] = "#!AMR-WB\n";
 
+static const uint8_t amrnb_packed_size[16] = {
+13, 14, 16, 18, 20, 21, 27, 32, 6, 1, 1, 1, 1, 1, 1, 1
+};
+static const uint8_t amrwb_packed_size[16] = {
+18, 24, 33, 37, 41, 47, 51, 59, 61, 6, 1, 1, 1, 1, 1, 1
+};
+
+
 #if CONFIG_AMR_MUXER
 static int amr_write_header(AVFormatContext *s)
 {
@@ -126,17 +134,9 @@ static int amr_read_packet(AVFormatContext *s, AVPacket *pkt)
 mode = (toc >> 3) & 0x0F;
 
 if (par->codec_id == AV_CODEC_ID_AMR_NB) {
-static const uint8_t packed_size[16] = {
-12, 13, 15, 17, 19, 20, 26, 31, 5, 0, 0, 0, 0, 0, 0, 0
-};
-
-size = packed_size[mode] + 1;
+size = amrnb_packed_size[mode];
 } else if (par->codec_id == AV_CODEC_ID_AMR_WB) {
-static const uint8_t packed_size[16] = {
-18, 24, 33, 37, 41, 47, 51, 59, 61, 6, 6, 0, 0, 0, 1, 1
-};
-
-size = packed_size[mode];
+size = amrwb_packed_size[mode];
 }
 
 if (!size || av_new_packet(pkt, size))
@@ -176,6 +176,102 @@ AVInputFormat ff_amr_demuxer = {
 };
 #endif
 
+#if CONFIG_AMRNB_DEMUXER
+static int amrnb_probe(AVProbeData *p)
+{
+int mode, i = 0, valid = 0;
+const uint8_t *b = p->buf;
+
+while (i < p->buf_size) {
+mode = b[i] >> 3 & 0x0F;
+if (mode < 9 && (b[i] & 0x4) == 0x4) {
+i += amrnb_packed_size[mode];
+valid++;
+} else {
+valid = 0;
+i++;
+}
+}
+if (valid > 100)
+return AVPROBE_SCORE_EXTENSION / 2 + 1;
+return 0;
+}
+
+static int amrnb_read_header(AVFormatContext *s)
+{
+AVStream *st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+st->codecpar->codec_tag  = MKTAG('s', 'a', 'm', 'r');
+st->codecpar->codec_id   = AV_CODEC_ID_AMR_NB;
+st->codecpar->sample_rate= 8000;
+st->codecpar->channels   = 1;
+st->codecpar->channel_layout = AV_CH_LAYOUT_MONO;
+st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
+avpriv_set_pts_info(st, 64, 1, 8000);
+
+return 0;
+}
+
+AVInputFormat ff_amrnb_demuxer = {
+.name   = "amrnb",
+.long_name  = NULL_IF_CONFIG_SMALL("raw AMR-NB"),
+.priv_data_size = sizeof(AMRContext),
+.read_probe = amrnb_probe,
+.read_header= amrnb_read_header,
+.read_packet= amr_read_packet,
+.flags  = AVFMT_GENERIC_INDEX,
+};
+#endif
+
+#if CONFIG_AMRWB_DEMUXER
+static int amrwb_p

Re: [FFmpeg-devel] libavcodec/hap : add HapAlphaOnly decoding/encoding

[Martin Vignali]

>
> > IMO, the ffmpeg support is mostly interesting to convert hap
> > file to something else or to check what we can encode with
> > the ffmpeg hap encoder.
>
> I don't disagree (on the contrary), I believe we should make it
> as easy as possible for users to work with it:
> Do you believe that it would be easier for users if HAP alpha only
> is represented as FFmpeg RGBA or gray?
>
> 
>

IMHO, from a compositing point of view, alpha only and gray is the same
thing.
It's common (in cgi compositing for example), to use alpha (or matte) as
separate gray only file.

But like the maintainer of the hapdec/enc in ffmpeg doesn't want this way
of interpreting
the HAP alpha only codec, (and like i doesn't want to fight on this point)
we can make some example in the doc, using filter, to help user to work
with that codec

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

Re: [FFmpeg-devel] libavcodec/proresdec : add qmat dsp with SSE2, AVX2 simd

[Carl Eugen Hoyos]

2017-10-07 16:22 GMT+02:00 Martin Vignali :

> Patch in attach add a new dsp
> for manipulation of qmat

Is there a measurable effect on overall decoding?

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

[FFmpeg-devel] libavcodec/proresdec : add qmat dsp with SSE2, AVX2 simd

[Martin Vignali]

Hello,

Patch in attach add a new dsp
for manipulation of qmat

for now, i move this code inside

for (i = 0; i < 64; i++) {
qmat_luma_scaled  [i] = ctx->qmat_luma  [i] * qscale;
qmat_chroma_scaled[i] = ctx->qmat_chroma[i] * qscale;
}

i add a special case for qscale == 1
and SSE2, AVX2 optimization

I use a new dsp for that, because we can probably use the same idea
for a similar use in proresenc_ks
and probably also for dnxhd (dec/enc), (need another func
because dnxhd, doesn't seems to use the same range for values)


I set two test in the checkasm, to test qscale == 1
and qscale != 1 (3 in my test)

this is my result (Kaby Lake, ox10.12)

qmatdsp.qmat2_scale_prores1_c: 20.3
qmatdsp.qmat2_scale_prores1_sse2: 15.5
qmatdsp.qmat2_scale_prores1_avx2: 10.3
qmatdsp.qmat2_scale_prores3_c: 24.3
qmatdsp.qmat2_scale_prores3_sse2: 20.3
qmatdsp.qmat2_scale_prores3_avx2: 14.8

Pass fate test for me (x86_64, osx)

Martin


0005-libavcodec-proresdec2-add-qmat-dsp-with-SSE2-AVX2-si.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]configure: Add -Wno-main

[James Almer]

On 10/7/2017 11:02 AM, Carl Eugen Hoyos wrote:
> One possibility attached.
> 
> Please comment, Carl Eugen
> 
> 
> 0001-lavfi-Rename-local-variables-main-as-master.patch
> 
> 
> From 0876a93917c8fe06a3d9b748c39e4f643c2ecd02 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sat, 7 Oct 2017 15:59:22 +0200
> Subject: [PATCH] lavfi: Rename local variables "main" as "master".
> 
> Silences several warnings:
> main is usually a function
> ---
>  libavfilter/vf_lut3d.c  |8 
>  libavfilter/vf_paletteuse.c |   10 +-
>  libavfilter/vf_psnr.c   |   14 +++---
>  libavfilter/vf_ssim.c   |   12 ++--
>  4 files changed, 22 insertions(+), 22 deletions(-)

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

Re: [FFmpeg-devel] [PATCH]configure: Add -Wno-main

[Carl Eugen Hoyos]

One possibility attached.

Please comment, Carl Eugen
From 0876a93917c8fe06a3d9b748c39e4f643c2ecd02 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 7 Oct 2017 15:59:22 +0200
Subject: [PATCH] lavfi: Rename local variables "main" as "master".

Silences several warnings:
main is usually a function
---
 libavfilter/vf_lut3d.c  |8 
 libavfilter/vf_paletteuse.c |   10 +-
 libavfilter/vf_psnr.c   |   14 +++---
 libavfilter/vf_ssim.c   |   12 ++--
 4 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/libavfilter/vf_lut3d.c b/libavfilter/vf_lut3d.c
index 39cd73f..c9b7224 100644
--- a/libavfilter/vf_lut3d.c
+++ b/libavfilter/vf_lut3d.c
@@ -752,16 +752,16 @@ static int update_apply_clut(FFFrameSync *fs)
 {
 AVFilterContext *ctx = fs->parent;
 AVFilterLink *inlink = ctx->inputs[0];
-AVFrame *main, *second, *out;
+AVFrame *master, *second, *out;
 int ret;
 
-ret = ff_framesync_dualinput_get(fs, &main, &second);
+ret = ff_framesync_dualinput_get(fs, &master, &second);
 if (ret < 0)
 return ret;
 if (!second)
-return ff_filter_frame(ctx->outputs[0], main);
+return ff_filter_frame(ctx->outputs[0], master);
 update_clut(ctx->priv, second);
-out = apply_lut(inlink, main);
+out = apply_lut(inlink, master);
 return ff_filter_frame(ctx->outputs[0], out);
 }
 
diff --git a/libavfilter/vf_paletteuse.c b/libavfilter/vf_paletteuse.c
index ffd37bf..79a0672 100644
--- a/libavfilter/vf_paletteuse.c
+++ b/libavfilter/vf_paletteuse.c
@@ -967,25 +967,25 @@ static int load_apply_palette(FFFrameSync *fs)
 AVFilterContext *ctx = fs->parent;
 AVFilterLink *inlink = ctx->inputs[0];
 PaletteUseContext *s = ctx->priv;
-AVFrame *main, *second, *out;
+AVFrame *master, *second, *out;
 int ret;
 
 // writable for error diffusal dithering
-ret = ff_framesync_dualinput_get_writable(fs, &main, &second);
+ret = ff_framesync_dualinput_get_writable(fs, &master, &second);
 if (ret < 0)
 return ret;
-if (!main || !second) {
+if (!master || !second) {
 ret = AVERROR_BUG;
 goto error;
 }
 if (!s->palette_loaded) {
 load_palette(s, second);
 }
-out = apply_palette(inlink, main);
+out = apply_palette(inlink, master);
 return ff_filter_frame(ctx->outputs[0], out);
 
 error:
-av_frame_free(&main);
+av_frame_free(&master);
 av_frame_free(&second);
 return ret;
 }
diff --git a/libavfilter/vf_psnr.c b/libavfilter/vf_psnr.c
index adf1644..493a501 100644
--- a/libavfilter/vf_psnr.c
+++ b/libavfilter/vf_psnr.c
@@ -146,21 +146,21 @@ static int do_psnr(FFFrameSync *fs)
 {
 AVFilterContext *ctx = fs->parent;
 PSNRContext *s = ctx->priv;
-AVFrame *main, *ref;
+AVFrame *master, *ref;
 double comp_mse[4], mse = 0;
 int ret, j, c;
 AVDictionary **metadata;
 
-ret = ff_framesync_dualinput_get(fs, &main, &ref);
+ret = ff_framesync_dualinput_get(fs, &master, &ref);
 if (ret < 0)
 return ret;
 if (!ref)
-return ff_filter_frame(ctx->outputs[0], main);
-metadata = &main->metadata;
+return ff_filter_frame(ctx->outputs[0], master);
+metadata = &master->metadata;
 
-compute_images_mse(s, (const uint8_t **)main->data, main->linesize,
+compute_images_mse(s, (const uint8_t **)master->data, master->linesize,
   (const uint8_t **)ref->data, ref->linesize,
-  main->width, main->height, comp_mse);
+  master->width, master->height, comp_mse);
 
 for (j = 0; j < s->nb_components; j++)
 mse += comp_mse[j] * s->planeweight[j];
@@ -222,7 +222,7 @@ static int do_psnr(FFFrameSync *fs)
 fprintf(s->stats_file, "\n");
 }
 
-return ff_filter_frame(ctx->outputs[0], main);
+return ff_filter_frame(ctx->outputs[0], master);
 }
 
 static av_cold int init(AVFilterContext *ctx)
diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c
index 40f09ad..4dcdc05 100644
--- a/libavfilter/vf_ssim.c
+++ b/libavfilter/vf_ssim.c
@@ -286,22 +286,22 @@ static int do_ssim(FFFrameSync *fs)
 {
 AVFilterContext *ctx = fs->parent;
 SSIMContext *s = ctx->priv;
-AVFrame *main, *ref;
+AVFrame *master, *ref;
 AVDictionary **metadata;
 float c[4], ssimv = 0.0;
 int ret, i;
 
-ret = ff_framesync_dualinput_get(fs, &main, &ref);
+ret = ff_framesync_dualinput_get(fs, &master, &ref);
 if (ret < 0)
 return ret;
 if (!ref)
-return ff_filter_frame(ctx->outputs[0], main);
-metadata = &main->metadata;
+return ff_filter_frame(ctx->outputs[0], master);
+metadata = &master->metadata;
 
 s->nb_frames++;
 
 for (i = 0; i < s->nb_components; i++) {
-c[i] = s->ssim_plane(&s->dsp, main->data[i], main->linesize[i],
+c[i] = s->ssim_plane(&s->dsp, master->data[i], master->linesize[i],
  

Re: [FFmpeg-devel] [PATCH] Fix for paletteuse to support transparency

[Carl Eugen Hoyos]

2017-10-06 23:23 GMT+02:00 Carl Eugen Hoyos :
> 2017-10-06 22:59 GMT+02:00 Bjorn Roche :
>
>>  libavfilter/vf_paletteuse.c | 175
>
> Works fine for me

I had tested with the sample from ticket #503 yesterday.

Using the following sample:
http://samples.ffmpeg.org/FLV/flash_with_alpha/300x180-Scr-f8-056alpha.flv
I get less nice results:
$ ffmpeg -i 300x180-Scr-f8-056alpha.flv -vframes 1 -vf palettegen pal.png
$ ffmpeg -i 300x180-Scr-f8-056alpha.flv -i pal.png -lavfi paletteuse
-vframes 1 out.png
Transparency in the output file is not correct, I wonder if the line
"if (c1[0] == 0 && c2[0] == 0" should be more something like
"if (c1[0] < 128 && c2[0] < 128)" (or with a threshold variable).

The results get worse with more frames and apng output:
Large blocks "disappear" from the output file, this looks
quite nice without your patch (but without transparency).

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

Re: [FFmpeg-devel] Infrastructure: patchwork.ffmpeg.org SSL certificate

[Michael Niedermayer]

On Sat, Oct 07, 2017 at 12:04:02AM +0200, Michael Niedermayer wrote:
> On Thu, Oct 05, 2017 at 01:37:27PM +0200, Matthias Hunstock wrote:
> > There is still a StartCom certificate in place, which is refused from
> > Chrome and soon other browsers.
> > 
> > Any help appreciated to also move that machine to Let's Encrypt?
> 
> I thought reimar would update it. I dont know the way by which the
> other servers update their certs.

fixed by reimar


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix for paletteuse to support transparency

[Clément Bœsch]

On Sat, Oct 07, 2017 at 01:48:16PM +0200, Clément Bœsch wrote:
> > Subject: Re: [FFmpeg-devel] [PATCH] Fix for paletteuse to support 
> > transparency
> 
> "lavf/paletteuse: add support for transparency"
> 

Sorry, "lavfi", not "lavf".

Also, can you add the trac ticket reference for this?

[...]

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix for paletteuse to support transparency

[Clément Bœsch]

> Subject: Re: [FFmpeg-devel] [PATCH] Fix for paletteuse to support transparency

"lavf/paletteuse: add support for transparency"

On Fri, Oct 06, 2017 at 04:59:55PM -0400, Bjorn Roche wrote:
> ---
>  libavfilter/vf_paletteuse.c | 175 
> 
>  1 file changed, 112 insertions(+), 63 deletions(-)
> 
> diff --git a/libavfilter/vf_paletteuse.c b/libavfilter/vf_paletteuse.c
> index ffd37bf1da..4203543843 100644
> --- a/libavfilter/vf_paletteuse.c
> +++ b/libavfilter/vf_paletteuse.c
> @@ -56,7 +56,7 @@ enum diff_mode {
>  };
>  
>  struct color_node {
> -uint8_t val[3];
> +uint8_t val[4];
>  uint8_t palette_id;
>  int split;
>  int left_id, right_id;
> @@ -86,6 +86,7 @@ typedef struct PaletteUseContext {
>  struct cache_node cache[CACHE_SIZE];/* lookup cache */
>  struct color_node map[AVPALETTE_COUNT]; /* 3D-Tree (KD-Tree with K=3) 
> for reverse colormap */
>  uint32_t palette[AVPALETTE_COUNT];
> +int transparency_index; /* index in the palette of transparency. -1 if 
> there isn't a transparency. */
>  int palette_loaded;
>  int dither;
>  int new;
> @@ -108,6 +109,7 @@ typedef struct PaletteUseContext {
>  #define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
>  static const AVOption paletteuse_options[] = {
>  { "dither", "select dithering mode", OFFSET(dither), AV_OPT_TYPE_INT, 
> {.i64=DITHERING_SIERRA2_4A}, 0, NB_DITHERING-1, FLAGS, "dithering_mode" },

> +{ "none","no dither",
>   0, AV_OPT_TYPE_CONST, {.i64=DITHERING_NONE},
> INT_MIN, INT_MAX, FLAGS, "dithering_mode" },

I think none is already supported as builtin in AVOption, isn't it? In any
case, this should probably be in a separated patch if deemed useful.

>  { "bayer",   "ordered 8x8 bayer dithering (deterministic)",  
>   0, AV_OPT_TYPE_CONST, {.i64=DITHERING_BAYER},   
> INT_MIN, INT_MAX, FLAGS, "dithering_mode" },
>  { "heckbert","dithering as defined by Paul Heckbert in 1982 
> (simple error diffusion)", 0, AV_OPT_TYPE_CONST, {.i64=DITHERING_HECKBERT},   
>  INT_MIN, INT_MAX, FLAGS, "dithering_mode" },
>  { "floyd_steinberg", "Floyd and Steingberg dithering (error 
> diffusion)",   0, AV_OPT_TYPE_CONST, 
> {.i64=DITHERING_FLOYD_STEINBERG}, INT_MIN, INT_MAX, FLAGS, "dithering_mode" },
> @@ -157,7 +159,8 @@ static int query_formats(AVFilterContext *ctx)
>  
>  static av_always_inline int dither_color(uint32_t px, int er, int eg, int 
> eb, int scale, int shift)
>  {
> -return av_clip_uint8((px >> 16 & 0xff) + ((er * scale) / (1< 16

> +return av_clip_uint8((px >> 24 & 0xff)  ) << 
> 24

Here and several times later, I believe you can drop the `& 0xff`.

> + | av_clip_uint8((px >> 16 & 0xff) + ((er * scale) / (1< 16
>   | av_clip_uint8((px >>  8 & 0xff) + ((eg * scale) / (1<  8
>   | av_clip_uint8((px   & 0xff) + ((eb * scale) / (1<  }
> @@ -165,10 +168,18 @@ static av_always_inline int dither_color(uint32_t px, 
> int er, int eg, int eb, in
>  static av_always_inline int diff(const uint8_t *c1, const uint8_t *c2)
>  {
>  // XXX: try L*a*b with CIE76 (dL*dL + da*da + db*db)
> -const int dr = c1[0] - c2[0];
> -const int dg = c1[1] - c2[1];
> -const int db = c1[2] - c2[2];
> -return dr*dr + dg*dg + db*db;
> +const static int max_diff = 255*255 + 255*255 + 255*255;
> +const int dr = c1[1] - c2[1];
> +const int dg = c1[2] - c2[2];
> +const int db = c1[3] - c2[3];
> +
> +if (c1[0] == 0 && c2[0] == 0) {
> +return 0;
> +} else if (c1[0] == c2[0]) {
> +return dr*dr + dg*dg + db*db;
> +} else {
> +return max_diff;
> +}

So if both alpha are 0, you consider the color identical, and otherwise if
both alpha are different, you consider the color completely different?

I guess that's OK. Please inline 255*255 + 255*255 + 255*255 in the return
though, I don't trust compilers into optimizing that static int.

>  }
>  
>  static av_always_inline uint8_t colormap_nearest_bruteforce(const uint32_t 
> *palette, const uint8_t *rgb)
> @@ -179,18 +190,20 @@ static av_always_inline uint8_t 
> colormap_nearest_bruteforce(const uint32_t *pale
>  const uint32_t c = palette[i];
>  
>  if ((c & 0xff00) == 0xff00) { // ignore transparent entry
> -const uint8_t palrgb[] = {
> +const uint8_t palargb[] = {
> +palette[i]>>24 & 0xff,

according to the condition just above, this is always 0xff. Is this what
you want?

>  palette[i]>>16 & 0xff,
>  palette[i]>> 8 & 0xff,
>  palette[i] & 0xff,
>  };
> -const int d = diff(palrgb, rgb);
> +const int d = diff(palargb, rgb);
>  if (d < min_dist) 

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter

[Michael Niedermayer]

On Sat, Oct 07, 2017 at 12:12:15PM +0200, Michael Niedermayer wrote:
> On Sat, Oct 07, 2017 at 10:09:45AM +0200, Paul B Mahol wrote:
> > On 10/7/17, James Almer  wrote:
> > > On 10/6/2017 7:09 PM, wm4 wrote:
> > >> On Fri, 6 Oct 2017 18:02:44 -0300
> > >> James Almer  wrote:
> > >>
> > >>> On 10/6/2017 5:44 PM, Paul B Mahol wrote:
> >  On 10/6/17, Michael Niedermayer  wrote:
> > > On Fri, Oct 06, 2017 at 10:03:16AM -0400, Ronald S. Bultje wrote:
> > >> Hi,
> > >>
> > >> On Thu, Oct 5, 2017 at 7:52 PM, Michael Niedermayer
> > >> 
> > >> wrote:
> > >>
> > >>> On Sat, Sep 30, 2017 at 03:51:41PM +, Ashish Singh wrote:
> >  ffmpeg | branch: master | Ashish Singh  | Sat
> >  Sep
> > >>> 16 02:35:58 2017 +0530| [148c8e88c43cfbabd6aee9f01ef30942cee9d359] |
> > >>> committer: Ronald S. Bultje
> > 
> >  avfilter: add vmafmotion filter
> > 
> >  Signed-off-by: Ashish Singh 
> >  Signed-off-by: Ronald S. Bultje 
> > 
> > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=
> > >>> 148c8e88c43cfbabd6aee9f01ef30942cee9d359
> >  ---
> > 
> >   Changelog   |   1 +
> >   doc/filters.texi|  14 ++
> >   libavfilter/Makefile|   1 +
> >   libavfilter/allfilters.c|   1 +
> >   libavfilter/vf_vmafmotion.c | 365 ++
> > >>> ++
> >   libavfilter/vmaf_motion.h   |  58 +++
> >   6 files changed, 440 insertions(+)
> > >>> [...]
> >  +static av_cold int init(AVFilterContext *ctx)
> >  +{
> >  +VMAFMotionContext *s = ctx->priv;
> >  +
> >  +if (s->stats_file_str) {
> >  +if (!strcmp(s->stats_file_str, "-")) {
> > >>>
> >  +s->stats_file = stdout;
> > >>>
> > >>> Using stdout can interfere with the user application using the 
> > >>> filter
> > >>>
> > >>>
> >  +} else {
> > >>>
> >  +s->stats_file = fopen(s->stats_file_str, "w");
> > >>>
> > >>> Opening a filter parameter provided string for writing is a 
> > >>> dangerous
> > >>> way to output data. It allows one with access to the parameters to
> > >>> overwrite any writable file
> > >>>
> > >>> data should only be output in a safe way
> > >>>
> > >>
> > >> The same mechanism is present in ssim/psnr filters. I'm open to any
> > >> alternative method you suggest. These are only settable using 
> > >> explicit
> > >> user
> > >> interaction (and are disabled by default) so I don't particularly see
> > >> the
> > >> problem.
> > >
> > > With this a filter graph can never be taken from an untrusted source
> > >
> > > One filter that outputs statistics without writing to a user specified
> > > filename is libavfilter/af_astats.c
> > 
> >  So what? Get over it.
> > >>>
> > >>> What kind of reply is this? What made you think it's justified?
> > >>> He literally gave an example of an alternative method as Ronald
> > >>> requested.
> > >>>
> > >>> Some of you people need to chill out already when discussing patches.
> > >>
> > >> Michael apparently just comes up randomly with this stuff to block
> > >> patches...
> > >
> > > Nobody comes up "randomly" with concerns. Especially not to block
> > > patches for the sake of blocking, because if they were bullshit
> > > arguments then they would be easy to counter and discard.
> > >
> > > At this point you're just expressing frustration over having negative
> > > reviews or blocking concerns on patches. Sure, it would be great to
> > > finish writing something, sending it to the ML and always get a LGTM as
> > > reply, but if it doesn't happen then you shouldn't chalk it up to
> > > pedantry from the other side.
> > >
> > > So again, chill out, and discuss/argue. Ask for other devs to chime in
> > > if necessary to tip the scales. But please, stop heating up every single
> > > thread.
> > >
> > 
> > Sorry but Michael is just trolling around. Several filters already have 
> > support
> > for writting to output file, also he does not provide solution at all,
> > he is just
> > blocking progress for without reason.
> 
> You do realize that the patch discussed here was applied long before
> my comments about the arbitrary file write access ?
> Theres nothing thats blocked by this as the code in question is
> already applied.
> 
> About a solution, I didnt write alot about solutions as iam really fine
> with any solution. There are many possible solutions ...
> The libavfilter/af_astats.c filter i mentioned outputs statistics
> via metadata or av_log as 2 alternatives to direct file write.
> There are other possibilities. Also Hendriks suggestion about
> turning metadata via some other application option into a file sounds
> pre

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter

[Michael Niedermayer]

On Sat, Oct 07, 2017 at 10:09:45AM +0200, Paul B Mahol wrote:
> On 10/7/17, James Almer  wrote:
> > On 10/6/2017 7:09 PM, wm4 wrote:
> >> On Fri, 6 Oct 2017 18:02:44 -0300
> >> James Almer  wrote:
> >>
> >>> On 10/6/2017 5:44 PM, Paul B Mahol wrote:
>  On 10/6/17, Michael Niedermayer  wrote:
> > On Fri, Oct 06, 2017 at 10:03:16AM -0400, Ronald S. Bultje wrote:
> >> Hi,
> >>
> >> On Thu, Oct 5, 2017 at 7:52 PM, Michael Niedermayer
> >> 
> >> wrote:
> >>
> >>> On Sat, Sep 30, 2017 at 03:51:41PM +, Ashish Singh wrote:
>  ffmpeg | branch: master | Ashish Singh  | Sat
>  Sep
> >>> 16 02:35:58 2017 +0530| [148c8e88c43cfbabd6aee9f01ef30942cee9d359] |
> >>> committer: Ronald S. Bultje
> 
>  avfilter: add vmafmotion filter
> 
>  Signed-off-by: Ashish Singh 
>  Signed-off-by: Ronald S. Bultje 
> 
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=
> >>> 148c8e88c43cfbabd6aee9f01ef30942cee9d359
>  ---
> 
>   Changelog   |   1 +
>   doc/filters.texi|  14 ++
>   libavfilter/Makefile|   1 +
>   libavfilter/allfilters.c|   1 +
>   libavfilter/vf_vmafmotion.c | 365 ++
> >>> ++
>   libavfilter/vmaf_motion.h   |  58 +++
>   6 files changed, 440 insertions(+)
> >>> [...]
>  +static av_cold int init(AVFilterContext *ctx)
>  +{
>  +VMAFMotionContext *s = ctx->priv;
>  +
>  +if (s->stats_file_str) {
>  +if (!strcmp(s->stats_file_str, "-")) {
> >>>
>  +s->stats_file = stdout;
> >>>
> >>> Using stdout can interfere with the user application using the filter
> >>>
> >>>
>  +} else {
> >>>
>  +s->stats_file = fopen(s->stats_file_str, "w");
> >>>
> >>> Opening a filter parameter provided string for writing is a dangerous
> >>> way to output data. It allows one with access to the parameters to
> >>> overwrite any writable file
> >>>
> >>> data should only be output in a safe way
> >>>
> >>
> >> The same mechanism is present in ssim/psnr filters. I'm open to any
> >> alternative method you suggest. These are only settable using explicit
> >> user
> >> interaction (and are disabled by default) so I don't particularly see
> >> the
> >> problem.
> >
> > With this a filter graph can never be taken from an untrusted source
> >
> > One filter that outputs statistics without writing to a user specified
> > filename is libavfilter/af_astats.c
> 
>  So what? Get over it.
> >>>
> >>> What kind of reply is this? What made you think it's justified?
> >>> He literally gave an example of an alternative method as Ronald
> >>> requested.
> >>>
> >>> Some of you people need to chill out already when discussing patches.
> >>
> >> Michael apparently just comes up randomly with this stuff to block
> >> patches...
> >
> > Nobody comes up "randomly" with concerns. Especially not to block
> > patches for the sake of blocking, because if they were bullshit
> > arguments then they would be easy to counter and discard.
> >
> > At this point you're just expressing frustration over having negative
> > reviews or blocking concerns on patches. Sure, it would be great to
> > finish writing something, sending it to the ML and always get a LGTM as
> > reply, but if it doesn't happen then you shouldn't chalk it up to
> > pedantry from the other side.
> >
> > So again, chill out, and discuss/argue. Ask for other devs to chime in
> > if necessary to tip the scales. But please, stop heating up every single
> > thread.
> >
> 
> Sorry but Michael is just trolling around. Several filters already have 
> support
> for writting to output file, also he does not provide solution at all,
> he is just
> blocking progress for without reason.

You do realize that the patch discussed here was applied long before
my comments about the arbitrary file write access ?
Theres nothing thats blocked by this as the code in question is
already applied.

About a solution, I didnt write alot about solutions as iam really fine
with any solution. There are many possible solutions ...
The libavfilter/af_astats.c filter i mentioned outputs statistics
via metadata or av_log as 2 alternatives to direct file write.
There are other possibilities. Also Hendriks suggestion about
turning metadata via some other application option into a file sounds
pretty good to me

Thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter

[Paul B Mahol]

On 10/7/17, Hendrik Leppkes  wrote:
> On Sat, Oct 7, 2017 at 11:24 AM, Nicolas George  wrote:
>> Le sextidi 16 vendemiaire, an CCXXVI, Paul B Mahol a ecrit :
>>> There is metadata for each frame added and it can be used right now.
>>
>> Then we can remove that file-writing option. Thanks for the
>> clarification.
>>
>
> If there is a command line to write a stats file with similar
> information from this metadata - I don't think anyone would then
> object to that.

No. Existing features will not get remove because of silly "security" reasons.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter

[Hendrik Leppkes]

On Sat, Oct 7, 2017 at 11:24 AM, Nicolas George  wrote:
> Le sextidi 16 vendémiaire, an CCXXVI, Paul B Mahol a écrit :
>> There is metadata for each frame added and it can be used right now.
>
> Then we can remove that file-writing option. Thanks for the
> clarification.
>

If there is a command line to write a stats file with similar
information from this metadata - I don't think anyone would then
object to that.

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter

[Paul B Mahol]

On 10/7/17, Nicolas George  wrote:
> Le sextidi 16 vendemiaire, an CCXXVI, Paul B Mahol a ecrit :
>> No.
>
> Very constructive, thanks.

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter

[Nicolas George]

Le sextidi 16 vendémiaire, an CCXXVI, Paul B Mahol a écrit :
> No.

Very constructive, thanks.

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter

[Paul B Mahol]

On 10/7/17, Nicolas George  wrote:
> Le sextidi 16 vendemiaire, an CCXXVI, Paul B Mahol a ecrit :
>> There is metadata for each frame added and it can be used right now.
>
> Then we can remove that file-writing option. Thanks for the
> clarification.

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter

[Nicolas George]

Le sextidi 16 vendémiaire, an CCXXVI, Paul B Mahol a écrit :
> There is metadata for each frame added and it can be used right now.

Then we can remove that file-writing option. Thanks for the
clarification.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter

[Paul B Mahol]

On 10/7/17, Nicolas George  wrote:
> Le quintidi 15 vendemiaire, an CCXXVI, Ronald S. Bultje a ecrit :
>> The same mechanism is present in ssim/psnr filters.
>
> This is true. But how do you think it came to happen?
>
> It happened because somebody wanted some feature for their use and
> implemented it (so far, very good), and since it involved an unusual
> situation (a filter outputting non-audio-video data), they had to
> improvise and chose a quick-and-dirty solution.
>
> And it got in. It got in because the feature was useful. It got in
> because it was only one filter. It got in because maybe it was an
> internship thing. And most importantly, it got in because being the
> killjoy who always rejects quick-and-dirty solutions becomes tiring.
>
> Then somebody else implemented something with a slightly similar need,
> and they used the same quick-and-dirty solution. And since there was
> precedent, it got in even more easily.
>
> And that brings us now, we have many filters that interact with the
> outside using various quick-and-dirty solutions, with all the bad
> consequences for the project.
>
> Michael raises a concern about security, and he is right. Not because
> that feature is in itself a security concern, it is not, not really. But
> it is still communication with the outside: when building a sandbox to
> secure a service, you have to think about all communication channels,
> secure all of them. Maybe the sandboxing mechanism you use can secure
> most of them at the same time; key word: "maybe": you have to check.
> Every channel means more work, more potential attack surface.
>
> But the concerns are not all about security. By writing the information
> into a file, you make it unusable from within libavfilter, from within
> the same filter graph. Ideally, all statistics gathered by any filter
> could be used by another filter downgraph: boxblur on detected faces,
> strengthen postprocessing depending on PSNR, etc. We cannot do that at
> this time, but we want it. Unfortunately, if everybody always goes for
> the quick-and-dirty solution, we will never have it.

There is metadata for each frame added and it can be used right now.

>
> It is not unexpected that a beginner in the project would reuse a
> solution. But experienced and competent developers could be expected to
> have the big picture in mind, to stop and think ahead.
>
> Regards,
>
> --
>   Nicolas George
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi/avfilter.c: Correct guess_status_pts to account for differing link timebases.

[Nicolas George]

Le quintidi 15 vendémiaire, an CCXXVI, Sasi Inguva a écrit :
> Signed-off-by: Sasi Inguva 
> ---
>  libavfilter/avfilter.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Thanks, pushed.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Makefile: generate stripped CLI tools directly instead of copying unstripped ones first

[Marton Balint]

On Fri, 6 Oct 2017, James Almer wrote:


On 10/6/2017 8:20 PM, James Almer wrote:

On 10/6/2017 5:20 PM, Marton Balint wrote:

Signed-off-by: Marton Balint 
---
 Makefile | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 4a1253a052..adb8330fa0 100644
--- a/Makefile
+++ b/Makefile
@@ -97,8 +97,7 @@ include $(SRC_PATH)/doc/examples/Makefile
 libavcodec/utils.o libavformat/utils.o libavdevice/avdevice.o 
libavfilter/avfilter.o libavutil/utils.o libpostproc/postprocess.o 
libswresample/swresample.o libswscale/utils.o : libavutil/ffversion.h

 $(PROGS): %$(PROGSSUF)$(EXESUF): %$(PROGSSUF)_g$(EXESUF)
-   $(CP) $< $@
-   $(STRIP) $@
+   $(STRIP) -o $@ $<


LGTM. This is the best thing after stripping on install, which seems to
be disliked.


Actually, configure seems to consider cases where STRIP is something
else than binutils' strip.

I guess it's known and tested to work with the to-be-stripped binary as
the only argument, but would -o work with every potential strip program,
or for that matter binutils on every supported platform? I already got
bitten by MacOS's install not accepting -T.


With the v2 patch I sent, more cases are handled when strip is not a 
traditional strip command.


I did a quick check of online man pages, and it seems to me only some very 
uncommon or very old platforms does not support -o.


So I can either keep the patch as is, (with direct stripping turned on 
by default) and fix OS/platforms as fate detects them, or we can make it 
opt-in for the known platforms, if we are very afraid of breaking stuff.


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

[FFmpeg-devel] [PATCHv2] Makefile: generate stripped CLI tools directly instead of copying unstripped ones first

[Marton Balint]

Now works with --disable-stripping.

Signed-off-by: Marton Balint 
---
 Makefile  | 4 
 configure | 4 
 2 files changed, 8 insertions(+)

diff --git a/Makefile b/Makefile
index 4a1253a052..642651d4cc 100644
--- a/Makefile
+++ b/Makefile
@@ -97,8 +97,12 @@ include $(SRC_PATH)/doc/examples/Makefile
 libavcodec/utils.o libavformat/utils.o libavdevice/avdevice.o 
libavfilter/avfilter.o libavutil/utils.o libpostproc/postprocess.o 
libswresample/swresample.o libswscale/utils.o : libavutil/ffversion.h
 
 $(PROGS): %$(PROGSSUF)$(EXESUF): %$(PROGSSUF)_g$(EXESUF)
+ifeq ($(STRIPTYPE),direct)
+   $(STRIP) -o $@ $<
+else
$(CP) $< $@
$(STRIP) $@
+endif
 
 %$(PROGSSUF)_g$(EXESUF): $(FF_DEP_LIBS)
$(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(OBJS-$*) $(FF_EXTRALIBS)
diff --git a/configure b/configure
index 391c141e7a..3b685b0d24 100755
--- a/configure
+++ b/configure
@@ -3361,6 +3361,7 @@ x86asmexe_default="nasm"
 windres_default="windres"
 nvcc_default="nvcc"
 nvccflags_default="-gencode arch=compute_30,code=sm_30 -O2"
+striptype="direct"
 
 # OS
 target_os_default=$(tolower $(uname -s))
@@ -5087,6 +5088,7 @@ case $target_os in
 ;;
 os/2*)
 strip="lxlite -CS"
+striptype=""
 objformat="aout"
 add_cppflags -D_GNU_SOURCE
 add_ldflags -Zomf -Zbin-files -Zargs-wild -Zhigh-mem -Zmap
@@ -6824,6 +6826,7 @@ fi # test "$quiet" != "yes"
 test -e Makefile || echo "include $source_path/Makefile" > Makefile
 
 enabled stripping || strip="echo skipping strip"
+enabled stripping || striptype=""
 
 config_files="$TMPH ffbuild/config.mak doc/config.texi"
 
@@ -6867,6 +6870,7 @@ ARFLAGS=$arflags
 AR_O=$ar_o
 RANLIB=$ranlib
 STRIP=$strip
+STRIPTYPE=$striptype
 NVCC=$nvcc
 CP=cp -p
 LN_S=$ln_s
-- 
2.13.5

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter

[Nicolas George]

Le quintidi 15 vendémiaire, an CCXXVI, Ronald S. Bultje a écrit :
> The same mechanism is present in ssim/psnr filters.

This is true. But how do you think it came to happen?

It happened because somebody wanted some feature for their use and
implemented it (so far, very good), and since it involved an unusual
situation (a filter outputting non-audio-video data), they had to
improvise and chose a quick-and-dirty solution.

And it got in. It got in because the feature was useful. It got in
because it was only one filter. It got in because maybe it was an
internship thing. And most importantly, it got in because being the
killjoy who always rejects quick-and-dirty solutions becomes tiring.

Then somebody else implemented something with a slightly similar need,
and they used the same quick-and-dirty solution. And since there was
precedent, it got in even more easily.

And that brings us now, we have many filters that interact with the
outside using various quick-and-dirty solutions, with all the bad
consequences for the project.

Michael raises a concern about security, and he is right. Not because
that feature is in itself a security concern, it is not, not really. But
it is still communication with the outside: when building a sandbox to
secure a service, you have to think about all communication channels,
secure all of them. Maybe the sandboxing mechanism you use can secure
most of them at the same time; key word: "maybe": you have to check.
Every channel means more work, more potential attack surface.

But the concerns are not all about security. By writing the information
into a file, you make it unusable from within libavfilter, from within
the same filter graph. Ideally, all statistics gathered by any filter
could be used by another filter downgraph: boxblur on detected faces,
strengthen postprocessing depending on PSNR, etc. We cannot do that at
this time, but we want it. Unfortunately, if everybody always goes for
the quick-and-dirty solution, we will never have it.

It is not unexpected that a beginner in the project would reuse a
solution. But experienced and competent developers could be expected to
have the big picture in mind, to stop and think ahead.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd/decklink_dec: Do not claim to output transparency information

[Maksym Veremeyenko]

06.10.2017 22:10, Marton Balint пише:


On Thu, 5 Oct 2017, Maksym Veremeyenko wrote:


29.09.2017 0:20, Carl Eugen Hoyos пише:

Hi!

I don't have decklink hardware but I assume it never outputs actual
transparency.
Or does it?


it outputs or use internal keyer to put it over passthrow SDI signal.

in external keyer mode it accept BGRA frame and output two SDI 
signals: one for *fill* another one for *key*


That is true, but that is the feature of the decklink output device.

Is the decklink *input* device capable of capturing in RGBA with useful 
alpha? I'd say, probably not.


i would say that it is probably *yes* because of that feature (capturing 
fill&key signal) mentioned in press release:



https://www.blackmagicdesign.com/media/release/20150413-16
[...]
 get simultaneous fill and key capture and playback ... 


on other hand, if capturing RGB from HDMI returns transparent picture - 
then yes - this patch should be applied.


--
Maksym Veremeyenko

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: always init output stream before reaping filters

[Hendrik Leppkes]

On Wed, Oct 4, 2017 at 12:48 AM, Marton Balint  wrote:
> Otherwise the frame size of the codec is not set in the buffersink.
>
> Fixes ticket #6603 and the following simpler case:
>
> ffmpeg -c aac -filter_complex "sine=d=0.1,asetnsamples=1025" out.aac
>
> Signed-off-by: Marton Balint 
> ---
>  fftools/ffmpeg.c | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 1d248bc269..5be8788ea8 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -4528,6 +4528,15 @@ static int transcode_step(void)
>  }
>
>  if (ost->filter && ost->filter->graph->graph) {
> +if (!ost->initialized) {
> +char error[1024] = {0};
> +ret = init_output_stream(ost, error, sizeof(error));
> +if (ret < 0) {
> +av_log(NULL, AV_LOG_ERROR, "Error initializing output stream 
> %d:%d -- %s\n",
> +   ost->file_index, ost->index, error);
> +exit_program(1);
> +}
> +}
>  if ((ret = transcode_from_filter(ost->filter->graph, &ist)) < 0)
>  return ret;
>  if (!ist)

Doesn't this basically void all the work that was done to get proper
output frame information before initializing the output, so its
created with the proper info at all times?

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter

[Paul B Mahol]

On 10/7/17, James Almer  wrote:
> On 10/6/2017 7:09 PM, wm4 wrote:
>> On Fri, 6 Oct 2017 18:02:44 -0300
>> James Almer  wrote:
>>
>>> On 10/6/2017 5:44 PM, Paul B Mahol wrote:
 On 10/6/17, Michael Niedermayer  wrote:
> On Fri, Oct 06, 2017 at 10:03:16AM -0400, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Thu, Oct 5, 2017 at 7:52 PM, Michael Niedermayer
>> 
>> wrote:
>>
>>> On Sat, Sep 30, 2017 at 03:51:41PM +, Ashish Singh wrote:
 ffmpeg | branch: master | Ashish Singh  | Sat
 Sep
>>> 16 02:35:58 2017 +0530| [148c8e88c43cfbabd6aee9f01ef30942cee9d359] |
>>> committer: Ronald S. Bultje

 avfilter: add vmafmotion filter

 Signed-off-by: Ashish Singh 
 Signed-off-by: Ronald S. Bultje 

> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=
>>> 148c8e88c43cfbabd6aee9f01ef30942cee9d359
 ---

  Changelog   |   1 +
  doc/filters.texi|  14 ++
  libavfilter/Makefile|   1 +
  libavfilter/allfilters.c|   1 +
  libavfilter/vf_vmafmotion.c | 365 ++
>>> ++
  libavfilter/vmaf_motion.h   |  58 +++
  6 files changed, 440 insertions(+)
>>> [...]
 +static av_cold int init(AVFilterContext *ctx)
 +{
 +VMAFMotionContext *s = ctx->priv;
 +
 +if (s->stats_file_str) {
 +if (!strcmp(s->stats_file_str, "-")) {
>>>
 +s->stats_file = stdout;
>>>
>>> Using stdout can interfere with the user application using the filter
>>>
>>>
 +} else {
>>>
 +s->stats_file = fopen(s->stats_file_str, "w");
>>>
>>> Opening a filter parameter provided string for writing is a dangerous
>>> way to output data. It allows one with access to the parameters to
>>> overwrite any writable file
>>>
>>> data should only be output in a safe way
>>>
>>
>> The same mechanism is present in ssim/psnr filters. I'm open to any
>> alternative method you suggest. These are only settable using explicit
>> user
>> interaction (and are disabled by default) so I don't particularly see
>> the
>> problem.
>
> With this a filter graph can never be taken from an untrusted source
>
> One filter that outputs statistics without writing to a user specified
> filename is libavfilter/af_astats.c

 So what? Get over it.
>>>
>>> What kind of reply is this? What made you think it's justified?
>>> He literally gave an example of an alternative method as Ronald
>>> requested.
>>>
>>> Some of you people need to chill out already when discussing patches.
>>
>> Michael apparently just comes up randomly with this stuff to block
>> patches...
>
> Nobody comes up "randomly" with concerns. Especially not to block
> patches for the sake of blocking, because if they were bullshit
> arguments then they would be easy to counter and discard.
>
> At this point you're just expressing frustration over having negative
> reviews or blocking concerns on patches. Sure, it would be great to
> finish writing something, sending it to the ML and always get a LGTM as
> reply, but if it doesn't happen then you shouldn't chalk it up to
> pedantry from the other side.
>
> So again, chill out, and discuss/argue. Ask for other devs to chime in
> if necessary to tip the scales. But please, stop heating up every single
> thread.
>

Sorry but Michael is just trolling around. Several filters already have support
for writting to output file, also he does not provide solution at all,
he is just
blocking progress for without reason.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: always init output stream before reaping filters

[Paul B Mahol]

On 10/6/17, Marton Balint  wrote:
>
>
> On Wed, 4 Oct 2017, Marton Balint wrote:
>
>> Otherwise the frame size of the codec is not set in the buffersink.
>>
>> Fixes ticket #6603 and the following simpler case:
>>
>> ffmpeg -c aac -filter_complex "sine=d=0.1,asetnsamples=1025" out.aac
>>
>> Signed-off-by: Marton Balint 
>
> As this patch fixes a regression, this should also be in 3.4, so ping for
> this.
>
> Thanks,
> Marton
>
>> ---
>> fftools/ffmpeg.c | 9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
>> index 1d248bc269..5be8788ea8 100644
>> --- a/fftools/ffmpeg.c
>> +++ b/fftools/ffmpeg.c
>> @@ -4528,6 +4528,15 @@ static int transcode_step(void)
>> }
>>
>> if (ost->filter && ost->filter->graph->graph) {
>> +if (!ost->initialized) {
>> +char error[1024] = {0};
>> +ret = init_output_stream(ost, error, sizeof(error));
>> +if (ret < 0) {
>> +av_log(NULL, AV_LOG_ERROR, "Error initializing output
>> stream %d:%d -- %s\n",
>> +   ost->file_index, ost->index, error);
>> +exit_program(1);
>> +}
>> +}
>> if ((ret = transcode_from_filter(ost->filter->graph, &ist)) < 0)
>> return ret;
>> if (!ist)
>> --
>> 2.13.5
>>
>> ___
>> 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
>

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