Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Tobias Rapp]

On 13.01.2019 15:07, Gyan wrote:


On 13-01-2019 06:39 PM, Ronald S. Bultje wrote:

Hi,

On Sun, Jan 13, 2019 at 4:39 AM Gyan  wrote:


When someone submits a patch, it is implicit, unless stated otherwise,
that it is of their own initiative (and their own work), and thus they
are free to assign copyright. When work is performed for hire, the
copyright may belong to the employer. Such sponsored work cannot be
'donated' to the project


But we don't do copyright assignment.



No, the patch submitter (implicitly) does. Which is not a problem when 
the copyright holder and submitter are the same person. For sponsored 
code, they may not be.


Analogy:

Scenario 1

A 'vlogger' makes a video and uploads it as public to Youtube. Youtube 
then lets everyone see that video. No problem.


Scenario 2

Someone pays the vlogger to make a video. Vlogger uploads it to YT as 
public. There's a problem if the client did not allow that which makes 
it copyright infringement, Which is why YT has this clause in their T


"You affirm, represent, and warrant that you own or have the necessary 
licenses, rights, consents, and permissions to publish Content you 
submit; and you license to YouTube all patent, trademark, trade secret, 
copyright or other proprietary rights in and to such Content for 
publication on the Service pursuant to these Terms of Service."


So, we are YT in this case and the Content is the patch(es). The concern 
would be that the submitter doesn't have the right to license the code 
into ffmpeg, if the contract with the client doesn't allow them to do 
it. Only way to be sure is for the sponsor to affirm to it. And for 
that, we would have to know that there is a sponsor, to start with.


Isn't this what the "Signed-off-by" line in a commit already states? So 
to solve this (if actually deemed necessary) it would be better to 
request the commit author to signal that the copyright status has been 
clarified by always adding this Signed-off-by line instead.


Regards,
Tobias

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

[FFmpeg-devel] [PATCH] lavf/vaapi_deinterlace: return error if mode unsupported

[Zhong Li]

Signed-off-by: Fuwei Tang 
Signed-off-by: Zhong Li 
---
 libavfilter/vf_deinterlace_vaapi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavfilter/vf_deinterlace_vaapi.c 
b/libavfilter/vf_deinterlace_vaapi.c
index 97aee65..f67a1c8 100644
--- a/libavfilter/vf_deinterlace_vaapi.c
+++ b/libavfilter/vf_deinterlace_vaapi.c
@@ -113,6 +113,7 @@ static int deint_vaapi_build_filter_params(AVFilterContext 
*avctx)
 av_log(avctx, AV_LOG_ERROR, "Deinterlacing mode %d (%s) is "
"not supported.\n", ctx->mode,
deint_vaapi_mode_name(ctx->mode));
+return AVERROR(EINVAL);
 }
 }
 
-- 
2.7.4

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

[FFmpeg-devel] [PATCH v2] lavc/qsvenc: set BRCParamMultiplier to aviod BRC overflow

[Zhong Li]

Fix ticket #7663

Reviewed-by Carl Eugen Hoyos 
Reviewed-by Hendrik Leppkes 
Signed-off-by: Zhong Li 
---
 libavcodec/qsvenc.c | 41 +++--
 1 file changed, 27 insertions(+), 14 deletions(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index e3b5a72..ba9bcf1 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -158,8 +158,8 @@ static void dump_video_param(AVCodecContext *avctx, 
QSVEncContext *q,
 #endif
 ) {
 av_log(avctx, AV_LOG_VERBOSE,
-   "BufferSizeInKB: %"PRIu16"; InitialDelayInKB: %"PRIu16"; 
TargetKbps: %"PRIu16"; MaxKbps: %"PRIu16"\n",
-   info->BufferSizeInKB, info->InitialDelayInKB, info->TargetKbps, 
info->MaxKbps);
+   "BufferSizeInKB: %"PRIu16"; InitialDelayInKB: %"PRIu16"; 
TargetKbps: %"PRIu16"; MaxKbps: %"PRIu16"; BRCParamMultiplier: %"PRIu16"\n",
+   info->BufferSizeInKB, info->InitialDelayInKB, info->TargetKbps, 
info->MaxKbps, info->BRCParamMultiplier);
 } else if (info->RateControlMethod == MFX_RATECONTROL_CQP) {
 av_log(avctx, AV_LOG_VERBOSE, "QPI: %"PRIu16"; QPP: %"PRIu16"; QPB: 
%"PRIu16"\n",
info->QPI, info->QPP, info->QPB);
@@ -167,8 +167,8 @@ static void dump_video_param(AVCodecContext *avctx, 
QSVEncContext *q,
 #if QSV_HAVE_AVBR
 else if (info->RateControlMethod == MFX_RATECONTROL_AVBR) {
 av_log(avctx, AV_LOG_VERBOSE,
-   "TargetKbps: %"PRIu16"; Accuracy: %"PRIu16"; Convergence: 
%"PRIu16"\n",
-   info->TargetKbps, info->Accuracy, info->Convergence);
+   "TargetKbps: %"PRIu16"; Accuracy: %"PRIu16"; Convergence: 
%"PRIu16"; BRCParamMultiplier: %"PRIu16"\n",
+   info->TargetKbps, info->Accuracy, info->Convergence, 
info->BRCParamMultiplier);
 }
 #endif
 #if QSV_HAVE_LA
@@ -178,8 +178,8 @@ static void dump_video_param(AVCodecContext *avctx, 
QSVEncContext *q,
 #endif
  ) {
 av_log(avctx, AV_LOG_VERBOSE,
-   "TargetKbps: %"PRIu16"; LookAheadDepth: %"PRIu16"\n",
-   info->TargetKbps, co2->LookAheadDepth);
+   "TargetKbps: %"PRIu16"; LookAheadDepth: %"PRIu16"; 
BRCParamMultiplier: %"PRIu16"\n",
+   info->TargetKbps, co2->LookAheadDepth, 
info->BRCParamMultiplier);
 }
 #endif
 #if QSV_HAVE_ICQ
@@ -451,6 +451,8 @@ static int init_video_param(AVCodecContext *avctx, 
QSVEncContext *q)
avctx->sw_pix_fmt : avctx->pix_fmt;
 const AVPixFmtDescriptor *desc;
 float quant;
+int target_bitrate_kbps, max_bitrate_kbps, brc_param_multiplier;
+int buffer_size_in_kilobytes, initial_delay_in_kilobytes;
 int ret;
 mfxVersion ver;
 
@@ -552,16 +554,25 @@ static int init_video_param(AVCodecContext *avctx, 
QSVEncContext *q)
 if (ret < 0)
 return ret;
 
+//libmfx BRC parameters are 16 bits thus maybe overflow, then 
BRCParamMultiplier is needed
+buffer_size_in_kilobytes   = avctx->rc_buffer_size / 8000;
+initial_delay_in_kilobytes = avctx->rc_initial_buffer_occupancy / 1000;
+target_bitrate_kbps= avctx->bit_rate / 1000;
+max_bitrate_kbps   = avctx->rc_max_rate / 1000;
+brc_param_multiplier   = (FFMAX(FFMAX3(target_bitrate_kbps, 
max_bitrate_kbps, buffer_size_in_kilobytes),
+  initial_delay_in_kilobytes) + 0x1) / 
0x1;
+
 switch (q->param.mfx.RateControlMethod) {
 case MFX_RATECONTROL_CBR:
 case MFX_RATECONTROL_VBR:
 #if QSV_HAVE_VCM
 case MFX_RATECONTROL_VCM:
 #endif
-q->param.mfx.BufferSizeInKB   = avctx->rc_buffer_size / 8000;
-q->param.mfx.InitialDelayInKB = avctx->rc_initial_buffer_occupancy / 
1000;
-q->param.mfx.TargetKbps   = avctx->bit_rate / 1000;
-q->param.mfx.MaxKbps  = avctx->rc_max_rate / 1000;
+q->param.mfx.BufferSizeInKB   = buffer_size_in_kilobytes / 
brc_param_multiplier;
+q->param.mfx.InitialDelayInKB = initial_delay_in_kilobytes / 
brc_param_multiplier;
+q->param.mfx.TargetKbps   = target_bitrate_kbps / 
brc_param_multiplier;
+q->param.mfx.MaxKbps  = max_bitrate_kbps / 
brc_param_multiplier;
+q->param.mfx.BRCParamMultiplier = brc_param_multiplier;
 break;
 case MFX_RATECONTROL_CQP:
 quant = avctx->global_quality / FF_QP2LAMBDA;
@@ -573,15 +584,17 @@ static int init_video_param(AVCodecContext *avctx, 
QSVEncContext *q)
 break;
 #if QSV_HAVE_AVBR
 case MFX_RATECONTROL_AVBR:
-q->param.mfx.TargetKbps  = avctx->bit_rate / 1000;
+q->param.mfx.TargetKbps  = target_bitrate_kbps / brc_param_multiplier;
 q->param.mfx.Convergence = q->avbr_convergence;
 q->param.mfx.Accuracy= q->avbr_accuracy;
+q->param.mfx.BRCParamMultiplier = brc_param_multiplier;
 break;
 #endif
 #if QSV_HAVE_LA
 case MFX_RATECONTROL_LA:
-q->param.mfx.TargetKbps  = avctx->bit_rate / 1000;
+  

[FFmpeg-devel] [PATCH] lavc/vaapi_encode: add support for AVC Trellis

[Linjie Fu]

Add support for VAAPI AVC Trellis Quantization with limitation:
- VA-API version >= (1, 0, 0)

Use option "-trellis off/I/P/B" to disable or enable Trellis
quantization for I/P/B frames.

Signed-off-by: Linjie Fu 
---
 libavcodec/vaapi_encode.c  | 44 ++
 libavcodec/vaapi_encode.h  | 14 +--
 libavcodec/vaapi_encode_h264.c |  9 +++
 3 files changed, 65 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index eda8a36299..971c661a7d 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1442,6 +1442,44 @@ static av_cold int 
vaapi_encode_init_rate_control(AVCodecContext *avctx)
 return 0;
 }
 
+static av_cold int vaapi_encode_init_quantization(AVCodecContext *avctx)
+{
+#if VA_CHECK_VERSION(1, 0, 0)
+VAAPIEncodeContext *ctx = avctx->priv_data;
+VAStatus vas;
+VAConfigAttrib attr = { VAConfigAttribEncQuantization };
+int trellis = ctx->trellis;
+
+vas = vaGetConfigAttributes(ctx->hwctx->display,
+ctx->va_profile,
+ctx->va_entrypoint,
+, 1);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Failed to query quantization "
+   "config attribute: %d (%s).\n", vas, vaErrorStr(vas));
+return AVERROR_EXTERNAL;
+}
+
+if (attr.value == VA_ENC_QUANTIZATION_NONE) {
+av_log(avctx, AV_LOG_WARNING, "Trellis Quantization attribute is not "
+"supported: will use default quantization.\n");
+} else if (attr.value == VA_ENC_QUANTIZATION_TRELLIS_SUPPORTED){
+av_log(avctx, AV_LOG_VERBOSE, "Quantization Trellis supported.\n");
+
+ctx->quantization_params.misc.type = 
VAEncMiscParameterTypeQuantization;
+ctx->quantization_params.quantization.quantization_flags.value = 
trellis;
+
+vaapi_encode_add_global_param(avctx, >quantization_params.misc,
+  sizeof(ctx->quantization_params));
+}
+#else
+av_log(avctx, AV_LOG_WARNING, "The encode quantization option (Trellis) is 
"
+   "not supported with this VAAPI version.\n");
+#endif
+
+return 0;
+}
+
 static av_cold int vaapi_encode_init_gop_structure(AVCodecContext *avctx)
 {
 VAAPIEncodeContext *ctx = avctx->priv_data;
@@ -1888,6 +1926,12 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx)
 if (err < 0)
 goto fail;
 
+if (ctx->trellis) {
+err = vaapi_encode_init_quantization(avctx);
+if (err < 0)
+goto fail;
+}
+
 if (avctx->compression_level >= 0) {
 err = vaapi_encode_init_quality(avctx);
 if (err < 0)
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index 965fe65c0b..52da90d1f6 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -37,7 +37,7 @@ struct VAAPIEncodePicture;
 
 enum {
 MAX_CONFIG_ATTRIBUTES  = 4,
-MAX_GLOBAL_PARAMS  = 4,
+MAX_GLOBAL_PARAMS  = 5,
 MAX_PICTURE_REFERENCES = 2,
 MAX_REORDER_DELAY  = 16,
 MAX_PARAM_BUFFER_SIZE  = 1024,
@@ -150,6 +150,9 @@ typedef struct VAAPIEncodeContext {
 // Packed headers which will actually be sent.
 unsigned intva_packed_headers;
 
+// Quantization mode
+int trellis;
+
 // Configuration attributes to use when creating va_config.
 VAConfigAttrib  config_attributes[MAX_CONFIG_ATTRIBUTES];
 int  nb_config_attributes;
@@ -197,7 +200,14 @@ typedef struct VAAPIEncodeContext {
 VAEncMiscParameterBufferQualityLevel quality;
 } quality_params;
 #endif
-
+#if VA_CHECK_VERSION(1, 0, 0)
+// Packed memory aligment to point uint32_t data[]
+// in misc to the uint64_t quantization.
+struct {
+VAEncMiscParameterBuffer misc;
+VAEncMiscParameterQuantization quantization;
+} __attribute__((packed)) quantization_params;
+#endif
 // Per-sequence parameter structure (VAEncSequenceParameterBuffer*).
 void   *codec_sequence_params;
 
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index f9402992b8..4d411891fe 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -58,6 +58,7 @@ typedef struct VAAPIEncodeH264Context {
 int sei;
 int profile;
 int level;
+int trellis;
 
 // Derived settings.
 int mb_width;
@@ -981,6 +982,8 @@ static av_cold int vaapi_encode_h264_init(AVCodecContext 
*avctx)
 
 ctx->slice_block_height = ctx->slice_block_width = 16;
 
+ctx->trellis = priv->trellis;
+
 return ff_vaapi_encode_init(avctx);
 }
 
@@ -1009,6 +1012,12 @@ static const AVOption vaapi_encode_h264_options[] = {
 { "cabac", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 1 }, INT_MIN, INT_MAX, 
FLAGS, "coder" },
 { "vlc",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 0 }, INT_MIN, INT_MAX, 
FLAGS, "coder" },
 { "ac",NULL, 

Re: [FFmpeg-devel] [PATCH, v4] lavc/hevc_parser: cope with more leading_zero_8bits and update FATE

[Fu, Linjie]

> -Original Message-
> From: Fu, Linjie
> Sent: Friday, January 11, 2019 15:29
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie 
> Subject: [PATCH,v4] lavc/hevc_parser: cope with more leading_zero_8bits
> and update FATE
> 
> Given that leading_zero_8bits can be included many times at the beginning
> of a NAL unit, blindly taking the startcode as 3 bytes will leave 0x00
> in last frame.
> 
> When startcode is found, go back to find all leading_zero_8bits in
> current buffer and pc->buffer to cut correctly.
> 
> Update the FATE checksum for fate-hevc-bsf-mp4toannexb:
> The ref output has redundant 0x00 at the end of the SUFFIX_SEI:
> { 50 01 84 31 00 19 39 77 d0 7b 3f bd 1e 09 38 9a 79 41
> c0 16 11 da 18 aa 0a db 2b 19 fa 47 3f 0f 67 4a 91 9c a1
> 12 72 67 d6 f0 8f 66 ee 95 f9 e2 b9 ba 23 9a e8 80 00 }
> 
> To verify the output of FATE:
> ffmpeg -i hevc-conformance/WPP_A_ericsson_MAIN10_2.bit -c copy -flags \
> +bitexact hevc-mp4.mov
> ffmpeg -i hevc-mp4.mov -c:v copy -fflags +bitexact -f hevc hevc.out
> 
> Signed-off-by: Linjie Fu 
> ---
> [v2]: Update FATE checksum.
> [v3]: Cope with more leading_zero_8bits cases.
> [v4]: find leading_zero_8bits in pc->buffer to cut correctly.
> 
>  libavcodec/hevc_parser.c | 12 
>  tests/fate/hevc.mak  |  2 +-
>  2 files changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
> index 369d1338d0..f6df43a067 100644
> --- a/libavcodec/hevc_parser.c
> +++ b/libavcodec/hevc_parser.c
> @@ -267,8 +267,7 @@ static int
> hevc_find_frame_end(AVCodecParserContext *s, const uint8_t *buf,
>  if ((nut >= HEVC_NAL_VPS && nut <= HEVC_NAL_EOB_NUT) || nut ==
> HEVC_NAL_SEI_PREFIX ||
>  (nut >= 41 && nut <= 44) || (nut >= 48 && nut <= 55)) {
>  if (pc->frame_start_found) {
> -pc->frame_start_found = 0;
> -return i - 5;
> +goto found;
>  }
>  } else if (nut <= HEVC_NAL_RASL_R ||
> (nut >= HEVC_NAL_BLA_W_LP && nut <= HEVC_NAL_CRA_NUT)) {
> @@ -277,14 +276,19 @@ static int
> hevc_find_frame_end(AVCodecParserContext *s, const uint8_t *buf,
>  if (!pc->frame_start_found) {
>  pc->frame_start_found = 1;
>  } else { // First slice of next frame found
> -pc->frame_start_found = 0;
> -return i - 5;
> +goto found;
>  }
>  }
>  }
>  }
> 
>  return END_NOT_FOUND;
> +
> +found:
> +pc->frame_start_found = 0;
> +while (i - 6 >= 0 ? !buf[i - 6] : !pc->buffer[pc->index + i - 6])
> +i--;
> +return i - 5;
>  }
> 
>  static int hevc_parse(AVCodecParserContext *s, AVCodecContext *avctx,
> diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
> index db3ea19340..ab8da53535 100644
> --- a/tests/fate/hevc.mak
> +++ b/tests/fate/hevc.mak
> @@ -238,7 +238,7 @@ FATE_HEVC-$(call ALLYES, HEVC_DEMUXER
> MOV_DEMUXER HEVC_MP4TOANNEXB_BSF MOV_MUXER
>  fate-hevc-bsf-mp4toannexb: tests/data/hevc-mp4.mov
>  fate-hevc-bsf-mp4toannexb: CMD = md5 -i
> $(TARGET_PATH)/tests/data/hevc-mp4.mov -c:v copy -fflags +bitexact -f
> hevc
>  fate-hevc-bsf-mp4toannexb: CMP = oneline
> -fate-hevc-bsf-mp4toannexb: REF = 1873662a3af1848c37e4eb25722c8df9
> +fate-hevc-bsf-mp4toannexb: REF = 73019329ed7f81c24f9af67c34c640c0
> 
>  fate-hevc-skiploopfilter: CMD = framemd5 -skip_loop_filter nokey -i
> $(TARGET_SAMPLES)/hevc-conformance/SAO_D_Samsung_5.bit -sws_flags
> bitexact
>  FATE_HEVC += fate-hevc-skiploopfilter
> --
> 2.17.1
 
Ping for the latest update to find the correct frame end in both current buf 
and pc->buffer?

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

Re: [FFmpeg-devel] [PATCHv2] fate: add dst decoder test

[Michael Niedermayer]

On Sun, Dec 23, 2018 at 01:20:51PM +0100, Michael Niedermayer wrote:
> On Sun, Dec 23, 2018 at 09:41:48AM +1100, Peter Ross wrote:
> > the dst->dsd decoder is bit-exact, but uses ff_dsd2pcm_translate to
> > output pcm.
> > ---
> > thanks for spotting this michael. totally forgotten about the embedded
> > pcm converter.
> > 
> >  tests/fate/audio.mak   |  5 +
> >  tests/ref/fate/dsf-dst | 16 
> >  2 files changed, 21 insertions(+)
> >  create mode 100644 tests/ref/fate/dsf-dst
> 
> fails on mips
> TESTdsf-dst

this passes now with master

thx
[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Never trust a computer, one day, it may think you are the virus. -- Compn


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

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Ronald S. Bultje]

On Sun, Jan 13, 2019 at 9:38 AM Nicolas George  wrote:

> Derek Buitenhuis (12019-01-13):
> > This is a policy change, not a techncal change.
>
> Policy changes need to be motivated too.
>

Wait, what? *You* are suggesting a policy change, not me/us. There is no
burden of proof on me. You have to convince me (and us) that your problem
is important and your proposal solves the problem. I am not convinced.

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

Re: [FFmpeg-devel] [PATCH 4/6] avcodec/vp6: use ff_vp4_[hv]_loop_filter_12_c

[Michael Niedermayer]

On Mon, Jan 14, 2019 at 07:02:47AM +1100, Peter Ross wrote:
> ---
>  libavcodec/vp56.c| 10 ++
>  libavcodec/vp56.h|  1 +
>  libavcodec/vp56dsp.c | 19 ---
>  3 files changed, 11 insertions(+), 19 deletions(-)
> 
> diff --git a/libavcodec/vp56.c b/libavcodec/vp56.c
> index 27b4b8b944..c5c5a9fb65 100644
> --- a/libavcodec/vp56.c
> +++ b/libavcodec/vp56.c
> @@ -33,6 +33,8 @@
>  
>  void ff_vp56_init_dequant(VP56Context *s, int quantizer)
>  {
> +if (s->quantizer != quantizer)
> +ff_vp3dsp_set_bounding_values(s->bounding_values_array, 
> ff_vp56_filter_threshold[quantizer]);

maybe ive missed something but this fails to build

libavcodec/vp56.c: In function ‘ff_vp56_init_dequant’:
libavcodec/vp56.c:37:9: error: implicit declaration of function 
‘ff_vp3dsp_set_bounding_values’ [-Werror=implicit-function-declaration]
 ff_vp3dsp_set_bounding_values(s->bounding_values_array, 
ff_vp56_filter_threshold[quantizer]);
 ^
cc1: some warnings being treated as errors
make: *** [libavcodec/vp56.o] Error 1
make: *** Waiting for unfinished jobs


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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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

[FFmpeg-devel] yadif frame doubling - incorrect closed captioning

[Gabriel Blanchard]

When frame doubling using yadif/bwdif closed captioning gets copied to the
second frame - as a result the closed captioning text is garbage.

I've attached a very simple patch that fixes this issue. Very similar to
what vf_fps.c already does around line 253.

-Gabe
From 0f6d3c31842ae33eaa3d5d91600bcd80c9c0a6b9 Mon Sep 17 00:00:00 2001
From: Gabriel Blanchard 
Date: Sun, 13 Jan 2019 17:10:01 -0500
Subject: [PATCH 1/1] fix closed captioning when frame doubling

---
 libavfilter/yadif_common.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavfilter/yadif_common.c b/libavfilter/yadif_common.c
index a10cf7a17f..fbb4289b80 100644
--- a/libavfilter/yadif_common.c
+++ b/libavfilter/yadif_common.c
@@ -43,6 +43,9 @@ static int return_frame(AVFilterContext *ctx, int is_second)
 return AVERROR(ENOMEM);
 
 av_frame_copy_props(yadif->out, yadif->cur);
+// Don't copy Closed Captioning
+av_frame_remove_side_data(yadif->out, AV_FRAME_DATA_A53_CC);
+
 yadif->out->interlaced_frame = 0;
 if (yadif->current_field == YADIF_FIELD_BACK_END)
 yadif->current_field = YADIF_FIELD_END;
-- 
2.19.0

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

[FFmpeg-devel] [PATCH]lavf/mov: Do not fail hard for more mov atoms

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #7679.

Please comment, Carl Eugen
From ea6afa36d5ceb6e027176f051e7886f0648e3ac2 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 13 Jan 2019 23:07:06 +0100
Subject: [PATCH] lavf/mov: Do not fail hard for more invalid atoms.

This is what several other players do and what FFmpeg already does for the sidx atom.

Fixes ticket #7679.
---
 libavformat/mov.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 970cd87..50507cf 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4558,8 +4558,8 @@ static int mov_read_tfhd(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 break;
 }
 if (!trex) {
-av_log(c->fc, AV_LOG_ERROR, "could not find corresponding trex\n");
-return AVERROR_INVALIDDATA;
+av_log(c->fc, AV_LOG_WARNING, "could not find corresponding trex id %u\n", frag->track_id);
+return 0;
 }
 
 frag->base_data_offset = flags & MOV_TFHD_BASE_DATA_OFFSET ?
@@ -4639,8 +4639,8 @@ static int mov_read_tfdt(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 }
 }
 if (!st) {
-av_log(c->fc, AV_LOG_ERROR, "could not find corresponding track id %u\n", frag->track_id);
-return AVERROR_INVALIDDATA;
+av_log(c->fc, AV_LOG_WARNING, "could not find corresponding track id %u\n", frag->track_id);
+return 0;
 }
 sc = st->priv_data;
 if (sc->pseudo_stream_id + 1 != frag->stsd_id && sc->pseudo_stream_id != -1)
@@ -4686,8 +4686,8 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 }
 }
 if (!st) {
-av_log(c->fc, AV_LOG_ERROR, "could not find corresponding track id %u\n", frag->track_id);
-return AVERROR_INVALIDDATA;
+av_log(c->fc, AV_LOG_WARNING, "could not find corresponding track id %u\n", frag->track_id);
+return 0;
 }
 sc = st->priv_data;
 if (sc->pseudo_stream_id+1 != frag->stsd_id && sc->pseudo_stream_id != -1)
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH 5/6] avcodec/vp6: select idct based (loosely) on number of coefficients decoded

[Carl Eugen Hoyos]

2019-01-13 21:03 GMT+01:00, Peter Ross :
> ---
>  libavcodec/vp5.c  |  1 +
>  libavcodec/vp56.c | 30 --
>  libavcodec/vp56.h |  2 ++
>  libavcodec/vp6.c  | 14 ++
>  4 files changed, 41 insertions(+), 6 deletions(-)

Please add a sentence about the reason for this patch.

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

Re: [FFmpeg-devel] [PATCH 0/6] improved VP6 decoding

[Carl Eugen Hoyos]

2019-01-13 21:00 GMT+01:00, Peter Ross :
> These patches make FFmpeg match the output of the VP6 reference
> decoder. Collectively they fix 

But none of the commit messages mention the ticket;-(

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

Re: [FFmpeg-devel] [PATCH] matroskadec: Adjust content light side data check

[Michael Niedermayer]

On Sun, Jan 13, 2019 at 12:17:24PM -0500, Vittorio Giovara wrote:
> While in practice both fields are always initialized, this mimics
> what other tools like ffms2, and x265 do more closely.
> 
> This work has been sponsored by Tyrell Corporation, for a compensation
> of dozen of cents of US dollars.
> ---
>  libavformat/matroskadec.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

this  breaks fate-seek-mkv-codec-delay 

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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

Re: [FFmpeg-devel] [PATCH 4/6] avcodec/vp6: use ff_vp4_[hv]_loop_filter_12_c

[Carl Eugen Hoyos]

2019-01-13 21:02 GMT+01:00, Peter Ross :
> ---
>  libavcodec/vp56.c| 10 ++
>  libavcodec/vp56.h|  1 +
>  libavcodec/vp56dsp.c | 19 ---
>  3 files changed, 11 insertions(+), 19 deletions(-)
>
> diff --git a/libavcodec/vp56.c b/libavcodec/vp56.c
> index 27b4b8b944..c5c5a9fb65 100644
> --- a/libavcodec/vp56.c
> +++ b/libavcodec/vp56.c
> @@ -33,6 +33,8 @@
>
>  void ff_vp56_init_dequant(VP56Context *s, int quantizer)
>  {
> +if (s->quantizer != quantizer)
> +ff_vp3dsp_set_bounding_values(s->bounding_values_array,
> ff_vp56_filter_threshold[quantizer]);
>  s->quantizer = quantizer;
>  s->dequant_dc = ff_vp56_dc_dequant[quantizer] << 2;
>  s->dequant_ac = ff_vp56_ac_dequant[quantizer] << 2;
> @@ -320,9 +322,17 @@ static void vp56_add_predictors_dc(VP56Context *s,
> VP56Frame ref_frame)
>  static void vp56_deblock_filter(VP56Context *s, uint8_t *yuv,
>  ptrdiff_t stride, int dx, int dy)
>  {
> +if (s->avctx->codec->id == AV_CODEC_ID_VP5) {
>  int t = ff_vp56_filter_threshold[s->quantizer];
>  if (dx)  s->vp56dsp.edge_filter_hor(yuv + 10-dx , stride, t);
>  if (dy)  s->vp56dsp.edge_filter_ver(yuv + stride*(10-dy), stride, t);
> +} else {
> +int * bounding_values = s->bounding_values_array + 127;
> +if (dx)
> +ff_vp4_h_loop_filter_12_c(yuv + 10-dx, stride,
> bounding_values);
> +if (dy)
> +ff_vp4_v_loop_filter_12_c(yuv + stride*(10-dy), stride,
> bounding_values);
> +}
>  }

This is your code now but I wonder why it helps not to merge
this with 1/6.

>  static void vp56_mc(VP56Context *s, int b, int plane, uint8_t *src,
> diff --git a/libavcodec/vp56.h b/libavcodec/vp56.h
> index 70e1d38a83..9b3036895c 100644
> --- a/libavcodec/vp56.h
> +++ b/libavcodec/vp56.h
> @@ -170,6 +170,7 @@ struct vp56_context {
>  int filter_mode;
>  int max_vector_length;
>  int sample_variance_threshold;
> +DECLARE_ALIGNED(8, int, bounding_values_array)[256];
>
>  uint8_t coeff_ctx[4][64];  /* used in vp5 only */
>  uint8_t coeff_ctx_last[4]; /* used in vp5 only */

> diff --git a/libavcodec/vp56dsp.c b/libavcodec/vp56dsp.c
> index 9f299dc60f..e8d93d6680 100644
> --- a/libavcodec/vp56dsp.c
> +++ b/libavcodec/vp56dsp.c
> @@ -72,27 +72,8 @@ av_cold void ff_vp5dsp_init(VP56DSPContext *s)
>  #endif /* CONFIG_VP5_DECODER */
>
>  #if CONFIG_VP6_DECODER
> -static int vp6_adjust(int v, int t)
> -{
> -int V = v, s = v >> 31;
> -V ^= s;
> -V -= s;
> -if (V-t-1 >= (unsigned)(t-1))
> -return v;
> -V = 2*t - V;
> -V += s;
> -V ^= s;
> -return V;
> -}
> -
> -VP56_EDGE_FILTER(vp6, hor, 1, stride)
> -VP56_EDGE_FILTER(vp6, ver, stride, 1)
> -
>  av_cold void ff_vp6dsp_init(VP56DSPContext *s)
>  {
> -s->edge_filter_hor = vp6_edge_filter_hor;
> -s->edge_filter_ver = vp6_edge_filter_ver;

And why are the new functions called "_c" but
are not part of the context?
(Or do I misread the code?)

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

Re: [FFmpeg-devel] [PATCH 6/6] fate: update vp6 regression test data

[Carl Eugen Hoyos]

2019-01-13 21:03 GMT+01:00, Peter Ross :
> ---
>  tests/ref/fate/vp60| 202 +--
>  tests/ref/fate/vp61| 238 +++
>  tests/ref/fate/vp6a| 172 -
>  tests/ref/fate/vp6a-skip_alpha | 172 -
>  tests/ref/fate/vp6f| 342 -
>  5 files changed, 563 insertions(+), 563 deletions(-)

Please merge into the patch(es) that change the values.

This is a necessity, it was never intended differently.

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

[FFmpeg-devel] [PATCH 6/6] fate: update vp6 regression test data

[Peter Ross]

---
 tests/ref/fate/vp60| 202 +--
 tests/ref/fate/vp61| 238 +++
 tests/ref/fate/vp6a| 172 -
 tests/ref/fate/vp6a-skip_alpha | 172 -
 tests/ref/fate/vp6f| 342 -
 5 files changed, 563 insertions(+), 563 deletions(-)

diff --git a/tests/ref/fate/vp60 b/tests/ref/fate/vp60
index 4becf2a8e2..2381c2775a 100644
--- a/tests/ref/fate/vp60
+++ b/tests/ref/fate/vp60
@@ -18,114 +18,114 @@
 0, 12, 12,1,55296, 0xe76b7df7
 0, 13, 13,1,55296, 0x5a049f33
 0, 14, 14,1,55296, 0xc83d9b90
-0, 15, 15,1,55296, 0x567877b8
-0, 16, 16,1,55296, 0x334c7f6e
-0, 17, 17,1,55296, 0x9317945c
-0, 18, 18,1,55296, 0xf032831e
-0, 19, 19,1,55296, 0x7b6c8d2c
-0, 20, 20,1,55296, 0x37109fd6
-0, 21, 21,1,55296, 0xe9b0b61b
-0, 22, 22,1,55296, 0x7385dae8
-0, 23, 23,1,55296, 0x74a8a9f5
-0, 24, 24,1,55296, 0xbcd2e218
-0, 25, 25,1,55296, 0x0aa6c623
-0, 26, 26,1,55296, 0x2224d6d6
-0, 27, 27,1,55296, 0x8c8ee4d9
-0, 28, 28,1,55296, 0x0d4ceccc
-0, 29, 29,1,55296, 0x623f10c7
-0, 30, 30,1,55296, 0x13a61f8f
-0, 31, 31,1,55296, 0x5343fa8d
-0, 32, 32,1,55296, 0x21fef1b5
-0, 33, 33,1,55296, 0x380de6b4
-0, 34, 34,1,55296, 0x04bedfd3
-0, 35, 35,1,55296, 0x428cf510
-0, 36, 36,1,55296, 0xbca8c214
-0, 37, 37,1,55296, 0x947faa34
-0, 38, 38,1,55296, 0x70769f45
-0, 39, 39,1,55296, 0xcb9483ad
+0, 15, 15,1,55296, 0x464d77d6
+0, 16, 16,1,55296, 0x725d7fa2
+0, 17, 17,1,55296, 0xc30494d5
+0, 18, 18,1,55296, 0x5687839f
+0, 19, 19,1,55296, 0x38be8df5
+0, 20, 20,1,55296, 0x62afa0ca
+0, 21, 21,1,55296, 0x683ab733
+0, 22, 22,1,55296, 0xccbedc72
+0, 23, 23,1,55296, 0x43c4abc5
+0, 24, 24,1,55296, 0xf2f2e3f5
+0, 25, 25,1,55296, 0x5fb8c813
+0, 26, 26,1,55296, 0x7814d907
+0, 27, 27,1,55296, 0xbb87e71a
+0, 28, 28,1,55296, 0x41c6ef34
+0, 29, 29,1,55296, 0x3f041373
+0, 30, 30,1,55296, 0x14b62281
+0, 31, 31,1,55296, 0x9a41fddb
+0, 32, 32,1,55296, 0x8961f556
+0, 33, 33,1,55296, 0x98edea61
+0, 34, 34,1,55296, 0x434ae3dd
+0, 35, 35,1,55296, 0x0aa4fa23
+0, 36, 36,1,55296, 0x0b8bc77f
+0, 37, 37,1,55296, 0x79dfafbc
+0, 38, 38,1,55296, 0x199ea4da
+0, 39, 39,1,55296, 0xd270896d
 0, 40, 40,1,55296, 0xac4ea82b
-0, 41, 41,1,55296, 0xa3816977
-0, 42, 42,1,55296, 0xcfd54ec4
-0, 43, 43,1,55296, 0x97743f0e
-0, 44, 44,1,55296, 0x4cb4424d
-0, 45, 45,1,55296, 0x0b503c11
-0, 46, 46,1,55296, 0x879f333a
-0, 47, 47,1,55296, 0x6ff9eb8f
-0, 48, 48,1,55296, 0x7cd6e5af
-0, 49, 49,1,55296, 0x44e2c36f
-0, 50, 50,1,55296, 0x4e8993fb
-0, 51, 51,1,55296, 0xf0bb9664
-0, 52, 52,1,55296, 0xde608458
-0, 53, 53,1,55296, 0xb3017f01
-0, 54, 54,1,55296, 0x2e096579
-0, 55, 55,1,55296, 0xd7295790
-0, 56, 56,1,55296, 0xc40b81cb
-0, 57, 57,1,55296, 0x53a86e41
-0, 58, 58,1,55296, 0x74142f89
-0, 59, 59,1,55296, 0x2a1428ce
-0, 60, 60,1,55296, 0x5d0c2852
-0, 61, 61,1,55296, 0x162058a4
-0, 62, 62,1,

[FFmpeg-devel] [PATCH 4/6] avcodec/vp6: use ff_vp4_[hv]_loop_filter_12_c

[Peter Ross]

---
 libavcodec/vp56.c| 10 ++
 libavcodec/vp56.h|  1 +
 libavcodec/vp56dsp.c | 19 ---
 3 files changed, 11 insertions(+), 19 deletions(-)

diff --git a/libavcodec/vp56.c b/libavcodec/vp56.c
index 27b4b8b944..c5c5a9fb65 100644
--- a/libavcodec/vp56.c
+++ b/libavcodec/vp56.c
@@ -33,6 +33,8 @@
 
 void ff_vp56_init_dequant(VP56Context *s, int quantizer)
 {
+if (s->quantizer != quantizer)
+ff_vp3dsp_set_bounding_values(s->bounding_values_array, 
ff_vp56_filter_threshold[quantizer]);
 s->quantizer = quantizer;
 s->dequant_dc = ff_vp56_dc_dequant[quantizer] << 2;
 s->dequant_ac = ff_vp56_ac_dequant[quantizer] << 2;
@@ -320,9 +322,17 @@ static void vp56_add_predictors_dc(VP56Context *s, 
VP56Frame ref_frame)
 static void vp56_deblock_filter(VP56Context *s, uint8_t *yuv,
 ptrdiff_t stride, int dx, int dy)
 {
+if (s->avctx->codec->id == AV_CODEC_ID_VP5) {
 int t = ff_vp56_filter_threshold[s->quantizer];
 if (dx)  s->vp56dsp.edge_filter_hor(yuv + 10-dx , stride, t);
 if (dy)  s->vp56dsp.edge_filter_ver(yuv + stride*(10-dy), stride, t);
+} else {
+int * bounding_values = s->bounding_values_array + 127;
+if (dx)
+ff_vp4_h_loop_filter_12_c(yuv + 10-dx, stride, 
bounding_values);
+if (dy)
+ff_vp4_v_loop_filter_12_c(yuv + stride*(10-dy), stride, 
bounding_values);
+}
 }
 
 static void vp56_mc(VP56Context *s, int b, int plane, uint8_t *src,
diff --git a/libavcodec/vp56.h b/libavcodec/vp56.h
index 70e1d38a83..9b3036895c 100644
--- a/libavcodec/vp56.h
+++ b/libavcodec/vp56.h
@@ -170,6 +170,7 @@ struct vp56_context {
 int filter_mode;
 int max_vector_length;
 int sample_variance_threshold;
+DECLARE_ALIGNED(8, int, bounding_values_array)[256];
 
 uint8_t coeff_ctx[4][64];  /* used in vp5 only */
 uint8_t coeff_ctx_last[4]; /* used in vp5 only */
diff --git a/libavcodec/vp56dsp.c b/libavcodec/vp56dsp.c
index 9f299dc60f..e8d93d6680 100644
--- a/libavcodec/vp56dsp.c
+++ b/libavcodec/vp56dsp.c
@@ -72,27 +72,8 @@ av_cold void ff_vp5dsp_init(VP56DSPContext *s)
 #endif /* CONFIG_VP5_DECODER */
 
 #if CONFIG_VP6_DECODER
-static int vp6_adjust(int v, int t)
-{
-int V = v, s = v >> 31;
-V ^= s;
-V -= s;
-if (V-t-1 >= (unsigned)(t-1))
-return v;
-V = 2*t - V;
-V += s;
-V ^= s;
-return V;
-}
-
-VP56_EDGE_FILTER(vp6, hor, 1, stride)
-VP56_EDGE_FILTER(vp6, ver, stride, 1)
-
 av_cold void ff_vp6dsp_init(VP56DSPContext *s)
 {
-s->edge_filter_hor = vp6_edge_filter_hor;
-s->edge_filter_ver = vp6_edge_filter_ver;
-
 s->vp6_filter_diag4 = ff_vp6_filter_diag4_c;
 
 if (ARCH_ARM)
-- 
2.17.1

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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

[FFmpeg-devel] [PATCH 5/6] avcodec/vp6: select idct based (loosely) on number of coefficients decoded

[Peter Ross]

---
 libavcodec/vp5.c  |  1 +
 libavcodec/vp56.c | 30 --
 libavcodec/vp56.h |  2 ++
 libavcodec/vp6.c  | 14 ++
 4 files changed, 41 insertions(+), 6 deletions(-)

diff --git a/libavcodec/vp5.c b/libavcodec/vp5.c
index cb08cec33f..49988b8b76 100644
--- a/libavcodec/vp5.c
+++ b/libavcodec/vp5.c
@@ -252,6 +252,7 @@ static int vp5_parse_coeff(VP56Context *s)
 for (i=coeff_idx; i<=ctx_last; i++)
 s->coeff_ctx[ff_vp56_b6to4[b]][i] = 5;
 s->above_blocks[s->above_block_idx[b]].not_null_dc = 
s->coeff_ctx[ff_vp56_b6to4[b]][0];
+s->idct_selector[b] = 63;
 }
 return 0;
 }
diff --git a/libavcodec/vp56.c b/libavcodec/vp56.c
index c5c5a9fb65..1227bc3a81 100644
--- a/libavcodec/vp56.c
+++ b/libavcodec/vp56.c
@@ -406,6 +406,24 @@ static void vp56_mc(VP56Context *s, int b, int plane, 
uint8_t *src,
 }
 }
 
+static void vp56_idct_put(VP56Context *s, uint8_t * dest, ptrdiff_t stride, 
int16_t *block, int selector)
+{
+if (selector > 10 || selector == 1)
+s->vp3dsp.idct_put(dest, stride, block);
+else
+ff_vp3dsp_idct10_put_c(dest, stride, block);
+}
+
+static void vp56_idct_add(VP56Context *s, uint8_t * dest, ptrdiff_t stride, 
int16_t *block, int selector)
+{
+if (selector > 10)
+s->vp3dsp.idct_add(dest, stride, block);
+else if (selector > 1)
+ff_vp3dsp_idct10_add_c(dest, stride, block);
+else
+s->vp3dsp.idct_dc_add(dest, stride, block);
+}
+
 static av_always_inline void vp56_render_mb(VP56Context *s, int row, int col, 
int is_alpha, VP56mb mb_type)
 {
 int b, ab, b_max, plane, off;
@@ -426,8 +444,8 @@ static av_always_inline void vp56_render_mb(VP56Context *s, 
int row, int col, in
 case VP56_MB_INTRA:
 for (b=0; bvp3dsp.idct_put(frame_current->data[plane] + 
s->block_offset[b],
-s->stride[plane], s->block_coeff[b]);
+vp56_idct_put(s, frame_current->data[plane] + 
s->block_offset[b],
+s->stride[plane], s->block_coeff[b], 
s->idct_selector[b]);
 }
 break;
 
@@ -439,8 +457,8 @@ static av_always_inline void vp56_render_mb(VP56Context *s, 
int row, int col, in
 s->hdsp.put_pixels_tab[1][0](frame_current->data[plane] + off,
  frame_ref->data[plane] + off,
  s->stride[plane], 8);
-s->vp3dsp.idct_add(frame_current->data[plane] + off,
-s->stride[plane], s->block_coeff[b]);
+vp56_idct_add(s, frame_current->data[plane] + off,
+  s->stride[plane], s->block_coeff[b], 
s->idct_selector[b]);
 }
 break;
 
@@ -457,8 +475,8 @@ static av_always_inline void vp56_render_mb(VP56Context *s, 
int row, int col, in
 plane = ff_vp56_b2p[b+ab];
 vp56_mc(s, b, plane, frame_ref->data[plane], s->stride[plane],
 16*col+x_off, 16*row+y_off);
-s->vp3dsp.idct_add(frame_current->data[plane] + 
s->block_offset[b],
-s->stride[plane], s->block_coeff[b]);
+vp56_idct_add(s, frame_current->data[plane] + 
s->block_offset[b],
+  s->stride[plane], s->block_coeff[b], 
s->idct_selector[b]);
 }
 break;
 }
diff --git a/libavcodec/vp56.h b/libavcodec/vp56.h
index 9b3036895c..84b2f6c94b 100644
--- a/libavcodec/vp56.h
+++ b/libavcodec/vp56.h
@@ -105,6 +105,7 @@ typedef struct VP56Macroblock {
 typedef struct VP56Model {
 uint8_t coeff_reorder[64];   /* used in vp6 only */
 uint8_t coeff_index_to_pos[64];  /* used in vp6 only */
+uint8_t coeff_index_to_idct_selector[64]; /* used in vp6 only */
 uint8_t vector_sig[2];   /* delta sign */
 uint8_t vector_dct[2];   /* delta coding types */
 uint8_t vector_pdi[2][2];/* predefined delta init */
@@ -157,6 +158,7 @@ struct vp56_context {
 VP56mb mb_type;
 VP56Macroblock *macroblocks;
 DECLARE_ALIGNED(16, int16_t, block_coeff)[6][64];
+int idct_selector[6];
 
 /* motion vectors */
 VP56mv mv[6];  /* vectors for each block in MB */
diff --git a/libavcodec/vp6.c b/libavcodec/vp6.c
index 645fc5c690..977fcb7076 100644
--- a/libavcodec/vp6.c
+++ b/libavcodec/vp6.c
@@ -194,6 +194,18 @@ static void vp6_coeff_order_table_init(VP56Context *s)
 for (pos=1; pos<64; pos++)
 if (s->modelp->coeff_reorder[pos] == i)
 s->modelp->coeff_index_to_pos[idx++] = pos;
+
+for (idx = 0; idx < 64; idx++) {
+int max = 0;
+for (i = 0; i <= idx; i++) {
+int v = s->modelp->coeff_index_to_pos[i];
+if (v > max)
+max = v;
+}
+if (s->sub_version > 6)
+max++;
+

[FFmpeg-devel] [PATCH 3/6] avcodec/vp6: use rounded shift for chroma motion vector calculation

[Peter Ross]

---
 libavcodec/vp56.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/libavcodec/vp56.c b/libavcodec/vp56.c
index b69fe6c176..27b4b8b944 100644
--- a/libavcodec/vp56.c
+++ b/libavcodec/vp56.c
@@ -196,12 +196,8 @@ static void vp56_decode_4mv(VP56Context *s, int row, int 
col)
 s->macroblocks[row * s->mb_width + col].mv = s->mv[3];
 
 /* chroma vectors are average luma vectors */
-if (s->avctx->codec->id == AV_CODEC_ID_VP5) {
-s->mv[4].x = s->mv[5].x = RSHIFT(mv.x,2);
-s->mv[4].y = s->mv[5].y = RSHIFT(mv.y,2);
-} else {
-s->mv[4] = s->mv[5] = (VP56mv) {mv.x/4, mv.y/4};
-}
+s->mv[4].x = s->mv[5].x = RSHIFT(mv.x,2);
+s->mv[4].y = s->mv[5].y = RSHIFT(mv.y,2);
 }
 
 static VP56mb vp56_decode_mv(VP56Context *s, int row, int col)
-- 
2.17.1

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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

[FFmpeg-devel] [PATCH 2/6] avcodec/vp3dsp: add 10 coefficient version of the vp3 idct

[Peter Ross]

---
 libavcodec/vp3dsp.c | 152 
 libavcodec/vp3dsp.h |   3 +
 2 files changed, 155 insertions(+)

diff --git a/libavcodec/vp3dsp.c b/libavcodec/vp3dsp.c
index f049953356..8204188aa8 100644
--- a/libavcodec/vp3dsp.c
+++ b/libavcodec/vp3dsp.c
@@ -195,6 +195,158 @@ static av_always_inline void idct(uint8_t *dst, ptrdiff_t 
stride,
 }
 }
 
+static av_always_inline void idct10(uint8_t *dst, ptrdiff_t stride,
+int16_t *input, int type)
+{
+int16_t *ip = input;
+
+int A, B, C, D, Ad, Bd, Cd, Dd, E, F, G, H;
+int Ed, Gd, Add, Bdd, Fd, Hd;
+
+int i;
+
+/* Inverse DCT on the rows now */
+for (i = 0; i < 4; i++) {
+/* Check for non-zero values */
+if (ip[0 * 8] | ip[1 * 8] | ip[2 * 8] | ip[3 * 8]) {
+A =  M(xC1S7, ip[1 * 8]);
+B =  M(xC7S1, ip[1 * 8]);
+C =  M(xC3S5, ip[3 * 8]);
+D = -M(xC5S3, ip[3 * 8]);
+
+Ad = M(xC4S4, (A - C));
+Bd = M(xC4S4, (B - D));
+
+Cd = A + C;
+Dd = B + D;
+
+E = M(xC4S4, ip[0 * 8]);
+F = E;
+
+G = M(xC2S6, ip[2 * 8]);
+H = M(xC6S2, ip[2 * 8]);
+
+Ed = E - G;
+Gd = E + G;
+
+Add = F + Ad;
+Bdd = Bd - H;
+
+Fd = F - Ad;
+Hd = Bd + H;
+
+/* Final sequence of operations over-write original inputs */
+ip[0 * 8] = Gd + Cd;
+ip[7 * 8] = Gd - Cd;
+
+ip[1 * 8] = Add + Hd;
+ip[2 * 8] = Add - Hd;
+
+ip[3 * 8] = Ed + Dd;
+ip[4 * 8] = Ed - Dd;
+
+ip[5 * 8] = Fd + Bdd;
+ip[6 * 8] = Fd - Bdd;
+
+}
+
+ip += 1;
+}
+
+ip = input;
+
+for (i = 0; i < 8; i++) {
+/* Check for non-zero values (bitwise or faster than ||) */
+if (ip[0] | ip[1] | ip[2] | ip[3]) {
+A =  M(xC1S7, ip[1]);
+B =  M(xC7S1, ip[1]);
+C =  M(xC3S5, ip[3]);
+D = -M(xC5S3, ip[3]);
+
+Ad = M(xC4S4, (A - C));
+Bd = M(xC4S4, (B - D));
+
+Cd = A + C;
+Dd = B + D;
+
+E = M(xC4S4, ip[0]);
+if (type == 1)
+E += 16 * 128;
+F = E;
+
+G = M(xC2S6, ip[2]);
+H = M(xC6S2, ip[2]);
+
+Ed = E - G;
+Gd = E + G;
+
+Add = F + Ad;
+Bdd = Bd - H;
+
+Fd = F - Ad;
+Hd = Bd + H;
+
+Gd += 8;
+Add += 8;
+Ed += 8;
+Fd += 8;
+
+/* Final sequence of operations over-write original inputs. */
+if (type == 1) {
+dst[0 * stride] = av_clip_uint8((Gd + Cd) >> 4);
+dst[7 * stride] = av_clip_uint8((Gd - Cd) >> 4);
+
+dst[1 * stride] = av_clip_uint8((Add + Hd) >> 4);
+dst[2 * stride] = av_clip_uint8((Add - Hd) >> 4);
+
+dst[3 * stride] = av_clip_uint8((Ed + Dd) >> 4);
+dst[4 * stride] = av_clip_uint8((Ed - Dd) >> 4);
+
+dst[5 * stride] = av_clip_uint8((Fd + Bdd) >> 4);
+dst[6 * stride] = av_clip_uint8((Fd - Bdd) >> 4);
+} else {
+dst[0 * stride] = av_clip_uint8(dst[0 * stride] + ((Gd + Cd) 
>> 4));
+dst[7 * stride] = av_clip_uint8(dst[7 * stride] + ((Gd - Cd) 
>> 4));
+
+dst[1 * stride] = av_clip_uint8(dst[1 * stride] + ((Add + Hd) 
>> 4));
+dst[2 * stride] = av_clip_uint8(dst[2 * stride] + ((Add - Hd) 
>> 4));
+
+dst[3 * stride] = av_clip_uint8(dst[3 * stride] + ((Ed + Dd) 
>> 4));
+dst[4 * stride] = av_clip_uint8(dst[4 * stride] + ((Ed - Dd) 
>> 4));
+
+dst[5 * stride] = av_clip_uint8(dst[5 * stride] + ((Fd + Bdd) 
>> 4));
+dst[6 * stride] = av_clip_uint8(dst[6 * stride] + ((Fd - Bdd) 
>> 4));
+}
+} else {
+if (type == 1) {
+dst[0*stride] =
+dst[1*stride] =
+dst[2*stride] =
+dst[3*stride] =
+dst[4*stride] =
+dst[5*stride] =
+dst[6*stride] =
+dst[7*stride] = 128;
+}
+}
+
+ip += 8;
+dst++;
+}
+}
+
+void ff_vp3dsp_idct10_put_c(uint8_t *dest, ptrdiff_t stride, int16_t *block)
+{
+idct10(dest, stride, block, 1);
+memset(block, 0, sizeof(*block) * 64);
+}
+
+void ff_vp3dsp_idct10_add_c(uint8_t *dest, ptrdiff_t stride, int16_t *block)
+{
+idct10(dest, stride, block, 2);
+memset(block, 0, sizeof(*block) * 64);
+}
+
 static void vp3_idct_put_c(uint8_t *dest /* align 8 */, ptrdiff_t stride,
int16_t *block /* align 16 */)
 {
diff --git a/libavcodec/vp3dsp.h b/libavcodec/vp3dsp.h
index 

[FFmpeg-devel] [PATCH 1/6] avcodec/vp3dsp: add 12 pixel loop filter functions

[Peter Ross]

---

This is a reposting of my earlier 12-pixel loop filter for VP4.

 libavcodec/vp3dsp.c | 28 
 libavcodec/vp3dsp.h |  5 +
 2 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/libavcodec/vp3dsp.c b/libavcodec/vp3dsp.c
index 4e08ee0b8f..f049953356 100644
--- a/libavcodec/vp3dsp.c
+++ b/libavcodec/vp3dsp.c
@@ -228,14 +228,14 @@ static void vp3_idct_dc_add_c(uint8_t *dest /* align 8 
*/, ptrdiff_t stride,
 block[0] = 0;
 }
 
-static void vp3_v_loop_filter_c(uint8_t *first_pixel, ptrdiff_t stride,
-int *bounding_values)
+static av_always_inline void vp3_v_loop_filter_c(uint8_t *first_pixel, 
ptrdiff_t stride,
+ int *bounding_values, int 
count)
 {
 unsigned char *end;
 int filter_value;
 const ptrdiff_t nstride = -stride;
 
-for (end = first_pixel + 8; first_pixel < end; first_pixel++) {
+for (end = first_pixel + count; first_pixel < end; first_pixel++) {
 filter_value = (first_pixel[2 * nstride] - first_pixel[stride]) +
(first_pixel[0] - first_pixel[nstride]) * 3;
 filter_value = bounding_values[(filter_value + 4) >> 3];
@@ -245,13 +245,13 @@ static void vp3_v_loop_filter_c(uint8_t *first_pixel, 
ptrdiff_t stride,
 }
 }
 
-static void vp3_h_loop_filter_c(uint8_t *first_pixel, ptrdiff_t stride,
-int *bounding_values)
+static av_always_inline void vp3_h_loop_filter_c(uint8_t *first_pixel, 
ptrdiff_t stride,
+ int *bounding_values, int 
count)
 {
 unsigned char *end;
 int filter_value;
 
-for (end = first_pixel + 8 * stride; first_pixel != end; first_pixel += 
stride) {
+for (end = first_pixel + count * stride; first_pixel != end; first_pixel 
+= stride) {
 filter_value = (first_pixel[-2] - first_pixel[1]) +
(first_pixel[ 0] - first_pixel[-1]) * 3;
 filter_value = bounding_values[(filter_value + 4) >> 3];
@@ -261,6 +261,18 @@ static void vp3_h_loop_filter_c(uint8_t *first_pixel, 
ptrdiff_t stride,
 }
 }
 
+#define LOOP_FILTER(prefix, dim, count) \
+void prefix##_##dim##_loop_filter_##count##_c(uint8_t *first_pixel, ptrdiff_t 
stride, \
+int *bounding_values) \
+{ \
+vp3_##dim##_loop_filter_c(first_pixel, stride, bounding_values, count); \
+}
+
+static LOOP_FILTER(vp3, v, 8)
+static LOOP_FILTER(vp3, h, 8)
+LOOP_FILTER(ff_vp4, v, 12)
+LOOP_FILTER(ff_vp4, h, 12)
+
 static void put_no_rnd_pixels_l2(uint8_t *dst, const uint8_t *src1,
  const uint8_t *src2, ptrdiff_t stride, int h)
 {
@@ -285,8 +297,8 @@ av_cold void ff_vp3dsp_init(VP3DSPContext *c, int flags)
 c->idct_put  = vp3_idct_put_c;
 c->idct_add  = vp3_idct_add_c;
 c->idct_dc_add   = vp3_idct_dc_add_c;
-c->v_loop_filter = vp3_v_loop_filter_c;
-c->h_loop_filter = vp3_h_loop_filter_c;
+c->v_loop_filter = vp3_v_loop_filter_8_c;
+c->h_loop_filter = vp3_h_loop_filter_8_c;
 
 if (ARCH_ARM)
 ff_vp3dsp_init_arm(c, flags);
diff --git a/libavcodec/vp3dsp.h b/libavcodec/vp3dsp.h
index f55a7f834f..fe77d69ebf 100644
--- a/libavcodec/vp3dsp.h
+++ b/libavcodec/vp3dsp.h
@@ -43,8 +43,13 @@ typedef struct VP3DSPContext {
 void (*idct_dc_add)(uint8_t *dest, ptrdiff_t stride, int16_t *block);
 void (*v_loop_filter)(uint8_t *src, ptrdiff_t stride, int 
*bounding_values);
 void (*h_loop_filter)(uint8_t *src, ptrdiff_t stride, int 
*bounding_values);
+void (*v_loop_filter_12)(uint8_t *src, ptrdiff_t stride, int 
*bounding_values);
+void (*h_loop_filter_12)(uint8_t *src, ptrdiff_t stride, int 
*bounding_values);
 } VP3DSPContext;
 
+void ff_vp4_v_loop_filter_12_c(uint8_t *first_pixel, ptrdiff_t stride, int 
*bounding_values);
+void ff_vp4_h_loop_filter_12_c(uint8_t *first_pixel, ptrdiff_t stride, int 
*bounding_values);
+
 void ff_vp3dsp_init(VP3DSPContext *c, int flags);
 void ff_vp3dsp_init_arm(VP3DSPContext *c, int flags);
 void ff_vp3dsp_init_ppc(VP3DSPContext *c, int flags);
-- 
2.17.1

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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

[FFmpeg-devel] [PATCH 0/6] improved VP6 decoding

[Peter Ross]

These patches make FFmpeg match the output of the VP6 reference
decoder. Collectively they fix 

Bugs fixed:

* Chroma motion vector calculation was sometimes off by 1.

* Loop filter differences. The VP6 loop filter is the same as the VP4 one.

* IDCT drift. the VP3/4/5/6 reference decoders all use three IDCT versions:
  one for the DC-only case, another for blocks with more than 10 coefficients,
  and an optimised one for blocks with up to 10 AC coefficents. VP6 relies
  on the sparse 10 coefficient version, and without it, picture quality goes
  to custard. VP3/4/5 does not seem to share this problem.

Output is bit identical to vp6vfw.dll for all my test streams.
Please note the On2 enables post-processing by default, and this must be
disabled for accurate comparisions with mplayer, etc.

I would like to get these patches signed off. Can somebody else test them
and report back :)

Peter Ross (6):
  avcodec/vp3dsp: add 12 pixel loop filter functions
  avcodec/vp3dsp: add 10 coefficient version of the vp3 idct
  avcodec/vp6: use rounded shift for chroma motion vector calculation
  avcodec/vp6: use ff_vp4_[hv]_loop_filter_12_c
  avcodec/vp6: select idct based (loosely) on number of coefficients
decoded
  fate: update vp6 regression test data

 libavcodec/vp3dsp.c| 180 -
 libavcodec/vp3dsp.h|   8 +
 libavcodec/vp5.c   |   1 +
 libavcodec/vp56.c  |  48 +++--
 libavcodec/vp56.h  |   3 +
 libavcodec/vp56dsp.c   |  19 --
 libavcodec/vp6.c   |  14 ++
 tests/ref/fate/vp60| 202 +--
 tests/ref/fate/vp61| 238 +++
 tests/ref/fate/vp6a| 172 -
 tests/ref/fate/vp6a-skip_alpha | 172 -
 tests/ref/fate/vp6f| 342 -
 12 files changed, 797 insertions(+), 602 deletions(-)

-- 
2.17.1

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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

Re: [FFmpeg-devel] [PATCH 1/4] vp3: ref_frame/ref_frames are only required when HAVE_THREADS=1

[Carl Eugen Hoyos]

2019-01-06 8:42 GMT+01:00, Peter Ross :
> squelch another warning
> ---
>  libavcodec/vp3.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
> index 9df2fda49d..a5d8c2ed0b 100644
> --- a/libavcodec/vp3.c
> +++ b/libavcodec/vp3.c
> @@ -1961,6 +1961,7 @@ fail:
>  return ret;
>  }
>
> +#if HAVE_THREADS
>  static int ref_frame(Vp3DecodeContext *s, ThreadFrame *dst, ThreadFrame
> *src)
>  {
>  ff_thread_release_buffer(s->avctx, dst);
> @@ -1979,7 +1980,6 @@ static int ref_frames(Vp3DecodeContext *dst,
> Vp3DecodeContext *src)
>  return 0;
>  }
>
> -#if HAVE_THREADS
>  static int vp3_update_thread_context(AVCodecContext *dst, const
> AVCodecContext *src)
>  {
>  Vp3DecodeContext *s = dst->priv_data, *s1 = src->priv_data;

No review necessary if tested.

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

Re: [FFmpeg-devel] [PATCH 1/4] vp3: ref_frame/ref_frames are only required when HAVE_THREADS=1

[Peter Ross]

On Sun, Jan 06, 2019 at 06:42:50PM +1100, Peter Ross wrote:
> squelch another warning
> ---
>  libavcodec/vp3.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

If no one objects, I will apply this warnings-fix patch in a day or so.

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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

Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference

[Derek Buitenhuis]

On 13/01/2019 18:24, James Almer wrote:
> I thought i had amended the patch, but guess not...
> 
> I can revert and reapply with the amended commit message if you want,
> but it will kinda litter the tree for not a lot of gain. Then again, the
> tree is already a mess with all the merges.

Not worth it, no.

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

Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference

[James Almer]

On 1/13/2019 3:18 PM, Derek Buitenhuis wrote:
> On 13/01/2019 18:01, James Almer wrote:
>> Pushes as is then. Thanks.
> 
> Er.
> 
> You didn't add the actual description of the problem/fix
> to the commit message.

I thought i had amended the patch, but guess not...

I can revert and reapply with the amended commit message if you want,
but it will kinda litter the tree for not a lot of gain. Then again, the
tree is already a mess with all the merges.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter: add colorhold filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi  | 14 ++
 libavfilter/Makefile  |  1 +
 libavfilter/allfilters.c  |  1 +
 libavfilter/vf_colorkey.c | 93 ++-
 4 files changed, 108 insertions(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index d06dfe089f..2aa122cc77 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -6533,6 +6533,20 @@ ffmpeg -i background.png -i video.mp4 -filter_complex 
"[1:v]colorkey=0x3BBD1E:0.
 @end example
 @end itemize
 
+@section colorhold
+Remove all color information for all RGB colors except for certain one.
+
+The filter accepts the following options:
+
+@table @option
+@item color
+The color which will not be replaced with neutral gray.
+
+@item similarity
+Similarity percentage with the above color.
+0.01 matches only the exact key color, while 1.0 matches everything.
+@end table
+
 @section colorlevels
 
 Adjust video input frames using levels.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 8283389f6e..5925b4bb03 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -176,6 +176,7 @@ OBJS-$(CONFIG_CODECVIEW_FILTER)  += 
vf_codecview.o
 OBJS-$(CONFIG_COLORBALANCE_FILTER)   += vf_colorbalance.o
 OBJS-$(CONFIG_COLORCHANNELMIXER_FILTER)  += vf_colorchannelmixer.o
 OBJS-$(CONFIG_COLORKEY_FILTER)   += vf_colorkey.o
+OBJS-$(CONFIG_COLORHOLD_FILTER)  += vf_colorkey.o
 OBJS-$(CONFIG_COLORLEVELS_FILTER)+= vf_colorlevels.o
 OBJS-$(CONFIG_COLORMATRIX_FILTER)+= vf_colormatrix.o
 OBJS-$(CONFIG_COLORSPACE_FILTER) += vf_colorspace.o colorspace.o 
colorspacedsp.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index b91cff2ce7..0e0e12a5e0 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -165,6 +165,7 @@ extern AVFilter ff_vf_codecview;
 extern AVFilter ff_vf_colorbalance;
 extern AVFilter ff_vf_colorchannelmixer;
 extern AVFilter ff_vf_colorkey;
+extern AVFilter ff_vf_colorhold;
 extern AVFilter ff_vf_colorlevels;
 extern AVFilter ff_vf_colormatrix;
 extern AVFilter ff_vf_colorspace;
diff --git a/libavfilter/vf_colorkey.c b/libavfilter/vf_colorkey.c
index 3d65e59d42..ea54e367b7 100644
--- a/libavfilter/vf_colorkey.c
+++ b/libavfilter/vf_colorkey.c
@@ -34,6 +34,9 @@ typedef struct ColorkeyContext {
 uint8_t colorkey_rgba[4];
 float similarity;
 float blend;
+
+int (*do_slice)(AVFilterContext *ctx, void *arg,
+int jobnr, int nb_jobs);
 } ColorkeyContext;
 
 static uint8_t do_colorkey_pixel(ColorkeyContext *ctx, uint8_t r, uint8_t g, 
uint8_t b)
@@ -77,15 +80,64 @@ static int do_colorkey_slice(AVFilterContext *avctx, void 
*arg, int jobnr, int n
 return 0;
 }
 
+static int do_colorhold_slice(AVFilterContext *avctx, void *arg, int jobnr, 
int nb_jobs)
+{
+AVFrame *frame = arg;
+
+const int slice_start = (frame->height * jobnr) / nb_jobs;
+const int slice_end = (frame->height * (jobnr + 1)) / nb_jobs;
+
+ColorkeyContext *ctx = avctx->priv;
+
+int o, x, y;
+
+for (y = slice_start; y < slice_end; ++y) {
+for (x = 0; x < frame->width; ++x) {
+int t, r, g, b;
+
+o = frame->linesize[0] * y + x * 4;
+r = frame->data[0][o + ctx->co[0]];
+g = frame->data[0][o + ctx->co[1]];
+b = frame->data[0][o + ctx->co[2]];
+
+t = do_colorkey_pixel(ctx, r, g, b);
+
+if (t > 0) {
+int a = (r + g + b) / 3;
+
+frame->data[0][o + ctx->co[0]] = a;
+frame->data[0][o + ctx->co[1]] = a;
+frame->data[0][o + ctx->co[2]] = a;
+}
+}
+}
+
+return 0;
+}
+
+static av_cold int init_filter(AVFilterContext *avctx)
+{
+ColorkeyContext *ctx = avctx->priv;
+
+if (!strcmp(avctx->filter->name, "colorkey")) {
+ctx->do_slice = do_colorkey_slice;
+} else {
+ctx->do_slice = do_colorhold_slice;
+}
+
+return 0;
+}
+
 static int filter_frame(AVFilterLink *link, AVFrame *frame)
 {
 AVFilterContext *avctx = link->dst;
+ColorkeyContext *ctx = avctx->priv;
 int res;
 
 if (res = av_frame_make_writable(frame))
 return res;
 
-if (res = avctx->internal->execute(avctx, do_colorkey_slice, frame, NULL, 
FFMIN(frame->height, ff_filter_get_nb_threads(avctx
+if (res = avctx->internal->execute(avctx, ctx->do_slice, frame, NULL, 
FFMIN(frame->height, ff_filter_get_nb_threads(avctx
 return res;
 
 return ff_filter_frame(avctx->outputs[0], frame);
@@ -163,7 +215,46 @@ AVFilter ff_vf_colorkey = {
 .priv_size = sizeof(ColorkeyContext),
 .priv_class= _class,
 .query_formats = query_formats,
+.init  = init_filter,
 .inputs= colorkey_inputs,
 .outputs   = colorkey_outputs,
 .flags = AVFILTER_FLAG_SUPPORT_TIMELINE_GENERIC | 

Re: [FFmpeg-devel] [PATCH] avfilter: add colorhold filter

[Paul B Mahol]

On 1/13/19, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi  | 14 ++
>  libavfilter/Makefile  |  1 +
>  libavfilter/allfilters.c  |  1 +
>  libavfilter/vf_colorkey.c | 93 ++-
>  4 files changed, 108 insertions(+), 1 deletion(-)
>

Forgot to write in commit log:

This work is obviously sponsored by Carl Eugen Hoyos, by 50 $.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference

[Derek Buitenhuis]

On 13/01/2019 18:01, James Almer wrote:
> Pushes as is then. Thanks.

Er.

You didn't add the actual description of the problem/fix
to the commit message.

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

Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference

[James Almer]

On 1/13/2019 12:55 PM, Derek Buitenhuis wrote:
> On 13/01/2019 15:45, James Almer wrote:
>> If there is, i don't know it.
>>
>> Float based fate tests have been fine tuned before when different
>> architectures proved a certain stddev value was not lax enough, so this
>> one could be increased if needed as well, but if you prefer i can use a
>> big enough multiple of FLT_EPSILON instead.
> 
> Don't really have a strong opinion on it, no.
> 
> - Derek

Pushes as is then. Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Nicolas George]

James Almer (12019-01-13):
> A temporal ban for first time offenders and such could maybe work. But
> then we're back to the CoC discussion that went nowhere.

And look who blocked this...

> And again, you think requesting the disclosure of the incentive behind
> the patch will make a difference on the behavior of a person questioned
> for ignoring reviews?

So you think they would outright lie about their sponsorships?

I am more optimistic: I believe there is a core of honesty and
attachment to good code in most contributors, and that making them aware
of their bias would be enough to convince them to try to do better, at
least a start.

But if you think they are actually dishonest and neglectful, then I
concur with your conclusions: they have no business having commit
rights.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/gdv: Optimize and factorize scaling loops

[Michael Niedermayer]

On Sat, Jan 12, 2019 at 04:49:40PM +0100, Carl Eugen Hoyos wrote:
> 2019-01-12 16:46 GMT+01:00, Michael Niedermayer :
> > On Sat, Jan 12, 2019 at 04:07:42PM +0100, Carl Eugen Hoyos wrote:
> >> 2019-01-04 20:22 GMT+01:00, Michael Niedermayer :
> >>
> >> > +static void scaledown(uint8_t *dst, const uint8_t *src, int w)
> >> > +{
> >> > +int x;
> >> > +for (x = 0; x < w - 7; x+=8) {
> >> > +dst[x + 0] = src[2*x + 0];
> >> > +dst[x + 1] = src[2*x + 2];
> >> > +dst[x + 2] = src[2*x + 4];
> >> > +dst[x + 3] = src[2*x + 6];
> >> > +dst[x + 4] = src[2*x + 8];
> >> > +dst[x + 5] = src[2*x +10];
> >> > +dst[x + 6] = src[2*x +12];
> >> > +dst[x + 7] = src[2*x +14];
> >>
> >> Could you add to the commit message the information
> >> which compiler is able to optimize this?
> >> (Assuming this is a reason for the speedup)
> >
> > if what you ask for is "which compiler turns this into SIMD"
> > i do not know, and i suspect mine does not from the limited
> > increase in performance
> > I think the speedup is primarly from simply unrolling the trivial loop
> >
> > is there something you want me to change in the commit message still ?
> 
> No, I am a little surprised that unrolling without SIMD makes
> a difference.

will apply

thx


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

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.


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

Re: [FFmpeg-devel] [PATCH] avcodec/tests/rangecoder: initialize array to avoid valgrind warning

[Michael Niedermayer]

On Sun, Jan 13, 2019 at 04:21:14PM +0800, Steven Liu wrote:
> 
> 
> > On Jan 12, 2019, at 22:49, Michael Niedermayer  
> > wrote:
> > 
> > On Fri, Jan 04, 2019 at 02:46:29AM +0100, Michael Niedermayer wrote:
> >> Found-by: jamrial
> >> Signed-off-by: Michael Niedermayer 
> >> ---
> >> libavcodec/tests/rangecoder.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > i intend to apply this soon unless there are more comments, i did not
> > understand the only comment :(
> Hi Michael,
> 
> Sorry for my comment, i think you are right,
> i mean the r should initialized too, but it have been initialized 
> completely a few lines later.

will apply

thx

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

Avoid a single point of failure, be that a person or equipment.


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

Re: [FFmpeg-devel] [PATCH] avcodec: fix some docstrings

[Michael Niedermayer]

On Sun, Jan 13, 2019 at 12:15:55AM +0100, Nicolas Granger wrote:
> Hello,
> 
> This fixes an erroneous reference and missing links in the API documentation.
> 
> Best regards,
> 
> Nicolas Granger
> 
> ---
> libavcodec/avcodec.h | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 4414853e84..64ba039be2 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -4892,7 +4892,8 @@ int avcodec_send_packet(AVCodecContext *avctx, const 
> AVPacket *avpkt);
> * @param frame This will be set to a reference-counted video or audio
> * frame (depending on the decoder type) allocated by the
> * decoder. Note that the function will always call
> - * av_frame_unref(frame) before doing anything else.
> + * @ref av_frame_unref "av_frame_unref(frame)" before doing
> + * anything else.

this patch is corrupted and will not apply automatically

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

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


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

Re: [FFmpeg-devel] [PATCH] matroskadec: Adjust content light side data check

[Paul B Mahol]

On 1/13/19, Vittorio Giovara  wrote:
> While in practice both fields are always initialized, this mimics
> what other tools like ffms2, and x265 do more closely.
>
> This work has been sponsored by Tyrell Corporation, for a compensation
> of dozen of cents of US dollars.
> ---
>  libavformat/matroskadec.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>

Please do not commit jokes to the tree.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] matroskadec: Adjust content light side data check

[Carl Eugen Hoyos]

2019-01-13 18:17 GMT+01:00, Vittorio Giovara :
> While in practice both fields are always initialized, this mimics
> what other tools like ffms2, and x265 do more closely.

> This work has been sponsored by Tyrell Corporation, for a compensation
> of dozen of cents of US dollars.

Please remove this.

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

Re: [FFmpeg-devel] [PATCH] matroskadec: Adjust content light side data check

[James Almer]

On 1/13/2019 2:17 PM, Vittorio Giovara wrote:
> While in practice both fields are always initialized, this mimics
> what other tools like ffms2, and x265 do more closely.
> 
> This work has been sponsored by Tyrell Corporation, for a compensation
> of dozen of cents of US dollars.
> ---
>  libavformat/matroskadec.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 4ad99db7db..3ff3516c24 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -1877,7 +1877,7 @@ static int mkv_parse_video_color(AVStream *st, const 
> MatroskaTrack *track) {
>  avcodec_chroma_pos_to_enum((color->chroma_siting_horz - 1) << 7,
> (color->chroma_siting_vert - 1) << 7);
>  }
> -if (color->max_cll && color->max_fall) {
> +if (color->max_cll || color->max_fall) {
>  size_t size = 0;
>  int ret;
>  AVContentLightMetadata *metadata = 
> av_content_light_metadata_alloc();
> @@ -1891,6 +1891,9 @@ static int mkv_parse_video_color(AVStream *st, const 
> MatroskaTrack *track) {
>  }
>  metadata->MaxCLL  = color->max_cll;
>  metadata->MaxFALL = color->max_fall;
> +av_log(NULL, AV_LOG_INFO, "Content Light Level Metadata, "
> +   "MaxCLL=%d, MaxFALL=%d",
> +   metadata->MaxCLL, metadata->MaxFALL);

This is unnecessary. av_dump_format() already prints side data information.

>  }
>  
>  if (has_mastering_primaries || has_mastering_luminance) {
> @@ -3552,6 +3555,8 @@ static int matroska_read_seek(AVFormatContext *s, int 
> stream_index,
>  AVStream *st = s->streams[stream_index];
>  int i, index, index_min;
>  
> +flags ^= AVSEEK_FLAG_ANY;

Unrelated change?

> +
>  /* Parse the CUES now since we need the index data to seek. */
>  if (matroska->cues_parsing_deferred > 0) {
>  matroska->cues_parsing_deferred = 0;
> 

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

[FFmpeg-devel] [PATCH] matroskadec: Adjust content light side data check

[Vittorio Giovara]

While in practice both fields are always initialized, this mimics
what other tools like ffms2, and x265 do more closely.

This work has been sponsored by Tyrell Corporation, for a compensation
of dozen of cents of US dollars.
---
 libavformat/matroskadec.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 4ad99db7db..3ff3516c24 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1877,7 +1877,7 @@ static int mkv_parse_video_color(AVStream *st, const 
MatroskaTrack *track) {
 avcodec_chroma_pos_to_enum((color->chroma_siting_horz - 1) << 7,
(color->chroma_siting_vert - 1) << 7);
 }
-if (color->max_cll && color->max_fall) {
+if (color->max_cll || color->max_fall) {
 size_t size = 0;
 int ret;
 AVContentLightMetadata *metadata = 
av_content_light_metadata_alloc();
@@ -1891,6 +1891,9 @@ static int mkv_parse_video_color(AVStream *st, const 
MatroskaTrack *track) {
 }
 metadata->MaxCLL  = color->max_cll;
 metadata->MaxFALL = color->max_fall;
+av_log(NULL, AV_LOG_INFO, "Content Light Level Metadata, "
+   "MaxCLL=%d, MaxFALL=%d",
+   metadata->MaxCLL, metadata->MaxFALL);
 }
 
 if (has_mastering_primaries || has_mastering_luminance) {
@@ -3552,6 +3555,8 @@ static int matroska_read_seek(AVFormatContext *s, int 
stream_index,
 AVStream *st = s->streams[stream_index];
 int i, index, index_min;
 
+flags ^= AVSEEK_FLAG_ANY;
+
 /* Parse the CUES now since we need the index data to seek. */
 if (matroska->cues_parsing_deferred > 0) {
 matroska->cues_parsing_deferred = 0;
-- 
2.20.1

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

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Nicolas George]

Michael Niedermayer (12019-01-13):
> You should add yourself to
> https://ffmpeg.org/consulting.html
> 
> I have no doubt code you would write for money would be of high quality.
> And more paid developers equal more contributions which is a good thing.

I thank you for your praise, but I will pass.

Like... absolutely every adult in the developed world, my relation to
money is deeply neurotic, and I do not want to subject myself to the
conflicting urges that it would cause. This is one of the main reasons I
want to keep my livelihood to come from teaching as a public servant:
doing my job well does not lower my income.

The world at large would be much better if people were to realize how
neurotic their relation with money is.

But this is getting far from the topic of this list.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] Video codec design for very low-end decoder

[Paul B Mahol]

On 1/13/19, Lauri Kasanen  wrote:
> On Mon, 7 Jan 2019 12:37:01 -0500
> "Ronald S. Bultje"  wrote:
>
>> On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen  wrote:
>> > "Ronald S. Bultje"  wrote:
>> >
>> > > Have you considered vp8? It may sound weird but this is basically what
>> > > vp8 was great at: being really simple to decode.
>> >
>> > VP8 has a reputation of being slow, so I didn't consider it. Benchmarks
>> > show it as decoding slower than h264.
>>
>> It is faster than h264 when comparing ffh264 vs. ffvp8
>
> I tried VP8 on the target platform (libvpx 1.7.0). It took 32% longer
> to decode the test vid than xvid, and given xvid was already a bit
> under realtime, VP8 is out.
>
> Curiously, VP8 also added very objectionable artifacts. Some blocks
> *moved* around in frames. That looked very bad, neither xvid nor h264
> caused that, they were just blocky or blurry. VP8 also looked worst of
> the three, by eye.
>
> x264 "everything disabled AFAICT" actually looks very good for the
> bitrate. Too bad I can't use H.264 due to the patent situation, so not
> going to spend time benching it either.
>
> Settings used:
>
> vpxenc -p 2 --profile=3 --target-bitrate=250 --best --end-usage=vbr
> --codec=vp8 --min-q=0 --max-q=60 --ivf
>
> mencoder -ovc x264 -x264encopts
> preset=veryslow:pass=2:bitrate=250:tune=fastdecode:profile=baseline
>
> (tune=fastdecode disables deblocking, the result file confirms all
> heavy options are off)

Just use mencoder, it is good business decision.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2] api-h264-slice-test: fix arguments and help

[Rafaël Carré]

This patch also changes the call to api-h264-slice-test.

v1 was done during a working day but was not requested by the direction.

v2 was done on sunday.

I think it's fair to say I was not paid for this, and to reassure you,
both times I put a minimum amount of effort.
>From 7a84425ea60b4f185b57b44fb2463033993c53f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rafa=C3=ABl=20Carr=C3=A9?= 
Date: Thu, 10 Jan 2019 12:00:27 +0100
Subject: [PATCH] api-h264-slice-test: fix arguments and help

This program only takes 2 arguments
Remove comment that was never right
---
 tests/api/api-h264-slice-test.c | 6 ++
 tests/fate/api.mak  | 2 +-
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/tests/api/api-h264-slice-test.c b/tests/api/api-h264-slice-test.c
index b893737bca..dee93b8349 100644
--- a/tests/api/api-h264-slice-test.c
+++ b/tests/api/api-h264-slice-test.c
@@ -22,8 +22,6 @@
 
 #define MAX_SLICES 8
 
-// ./fate 2 ./crew_cif out.y4m
-
 #include "config.h"
 
 #include 
@@ -121,8 +119,8 @@ int main(int argc, char **argv)
 int nals = 0, ret = 0;
 char *p;
 
-if (argc < 4) {
-fprintf(stderr, "Usage: %s   \n", argv[0]);
+if (argc < 3) {
+fprintf(stderr, "Usage: %s  \n", argv[0]);
 return -1;
 }
 
diff --git a/tests/fate/api.mak b/tests/fate/api.mak
index 132c38f2c2..3714f900bd 100644
--- a/tests/fate/api.mak
+++ b/tests/fate/api.mak
@@ -14,7 +14,7 @@ fate-api-h264: CMD = run $(APITESTSDIR)/api-h264-test $(TARGET_SAMPLES)/h264-con
 
 FATE_API_SAMPLES_LIBAVFORMAT-$(call DEMDEC, H264, H264) += fate-api-h264-slice
 fate-api-h264-slice: $(APITESTSDIR)/api-h264-slice-test$(EXESUF)
-fate-api-h264-slice: CMD = run $(APITESTSDIR)/api-h264-slice-test 2 $(TARGET_SAMPLES)/h264/crew_cif.nal api-h264-slice.h264
+fate-api-h264-slice: CMD = run $(APITESTSDIR)/api-h264-slice-test 2 $(TARGET_SAMPLES)/h264/crew_cif.nal
 
 FATE_API_LIBAVFORMAT-$(call DEMDEC, FLV, FLV) += fate-api-seek
 fate-api-seek: $(APITESTSDIR)/api-seek-test$(EXESUF) fate-lavf-flv_fmt
-- 
2.19.1

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

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[James Almer]

On 1/13/2019 1:29 PM, Nicolas George wrote:
> James Almer (12019-01-13):
>> (1) is not an issue,
> 
> It is an issue because it makes the rest possible. After all, people
> whose main motivation is code quality would want their code reviewed.
> 
>>  (2) and (3) are the issue, and depending on the
>> developer's reaction at reviews and request for fixes, it should result
>> in the removal of commit rights.
> 
> I was not ready to go that way, but since you put that on the tale, be
> aware that I will hold you to it.

And what was your idea, if not that? You complain about people
potentially forcefully pushing patches after ignoring NAKs or request
for fixes. If the person can't be convinced to stop doing that, what
else can you do to stop them?
A temporal ban for first time offenders and such could maybe work. But
then we're back to the CoC discussion that went nowhere.

> 
>> Does
>> the recent patch by Paul that prompted this abomination of a patch fit
>> the above criteria?
> 
> If they happened in the future and not in the past (decisions should not
> be retroactive), I would consider this:
> 
> https://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/237979.html
> https://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/238166.html
> 
> (I notice that you did call him out on the second, and I appreciate it)
> to count as strikes one and two.
> 
>> And (5) is completely irrelevant for the above. Bad code is bad code,
>> and bad behavior is bad behavior, regardless of the incentive behind it.
> 
> I am not very surprised to see technical types ignoring sociological
> evidence, but it is saddening.

And again, you think requesting the disclosure of the incentive behind
the patch will make a difference on the behavior of a person questioned
for ignoring reviews? On top of being unacceptable in its current form,
this patch is evidently misguided.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Michael Niedermayer]

On Fri, Jan 11, 2019 at 07:21:07PM +0100, Nicolas George wrote:
> Rationale:
> 
> * This requirement should offset a little the incentive to neglect
>   design, code quality and politeness during the review process when
>   done for money.
> 
> * The review process itself and future maintenance burden cost efforts
>   to the whole project; knowing that sponsorship has been given, to an
>   individual or to the whole project, helps evaluating if the benefits
>   match the costs.
> 
> * Inclusion in FFmpeg implies implicit endorsement by the project;
>   we owe to our users to disclose when this endorsement is not genuine;
>   this is to relate to mandatory flagging of advertisement in mass media.
> 
> * Systematic disclosure and transparency make a stronger position
>   against accusations of bias or conflict of interest for difficult
>   policy decisions.
> 
> * Documenting bounties may give an incentive to new contributors
>   who may not be aware of these opportunities.
> 
> Signed-off-by: Nicolas George 
> ---
>  doc/developer.texi | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 5c342c9106..1d77250083 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -420,6 +420,13 @@ your name after it.
>  If at some point you no longer want to maintain some code, then please help 
> in
>  finding a new maintainer and also don't forget to update the 
> @file{MAINTAINERS} file.
>  
> +@subheading Disclose sponsors and other remunerations
> +If the patch is the result of sponsored work, expects a bounty or benefited
> +from any kind of specific remuneration or payment, include the identity of
> +the sponsors, the identity of the recipients (if it is not exactly the
> +author of the patch) and the amount (or an approximation if it is not
> +possible to define it exactly) in the commit message.
> +
>  We think our rules are not too hard. If you have comments, contact us.
>  
>  @chapter Code of conduct
> @@ -664,6 +671,9 @@ are notoriously left unchecked, which is a serious 
> problem.
>  @item
>  Test your code with valgrind and or Address Sanitizer to ensure it's free
>  of leaks, out of array accesses, etc.
> +
> +@item
> +Did you disclose any sponsorship in the commit message?
>  @end enumerate
>  
>  @chapter Patch review process

You should add yourself to
https://ffmpeg.org/consulting.html

I have no doubt code you would write for money would be of high quality.
And more paid developers equal more contributions which is a good thing.

Also iam not sure how this change would interact with the GDPR or a NDA
iam no lawyer  

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.


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

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Nicolas George]

James Almer (12019-01-13):
> (1) is not an issue,

It is an issue because it makes the rest possible. After all, people
whose main motivation is code quality would want their code reviewed.

>   (2) and (3) are the issue, and depending on the
> developer's reaction at reviews and request for fixes, it should result
> in the removal of commit rights.

I was not ready to go that way, but since you put that on the tale, be
aware that I will hold you to it.

>  Does
> the recent patch by Paul that prompted this abomination of a patch fit
> the above criteria?

If they happened in the future and not in the past (decisions should not
be retroactive), I would consider this:

https://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/237979.html
https://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/238166.html

(I notice that you did call him out on the second, and I appreciate it)
to count as strikes one and two.

> And (5) is completely irrelevant for the above. Bad code is bad code,
> and bad behavior is bad behavior, regardless of the incentive behind it.

I am not very surprised to see technical types ignoring sociological
evidence, but it is saddening.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] Video codec design for very low-end decoder

[Lauri Kasanen]

On Mon, 7 Jan 2019 12:37:01 -0500
"Ronald S. Bultje"  wrote:

> On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen  wrote:
> > "Ronald S. Bultje"  wrote:
> >
> > > Have you considered vp8? It may sound weird but this is basically what
> > > vp8 was great at: being really simple to decode.
> >
> > VP8 has a reputation of being slow, so I didn't consider it. Benchmarks
> > show it as decoding slower than h264.
> 
> It is faster than h264 when comparing ffh264 vs. ffvp8

I tried VP8 on the target platform (libvpx 1.7.0). It took 32% longer
to decode the test vid than xvid, and given xvid was already a bit
under realtime, VP8 is out.

Curiously, VP8 also added very objectionable artifacts. Some blocks
*moved* around in frames. That looked very bad, neither xvid nor h264
caused that, they were just blocky or blurry. VP8 also looked worst of
the three, by eye.

x264 "everything disabled AFAICT" actually looks very good for the
bitrate. Too bad I can't use H.264 due to the patent situation, so not
going to spend time benching it either.

Settings used:

vpxenc -p 2 --profile=3 --target-bitrate=250 --best --end-usage=vbr
--codec=vp8 --min-q=0 --max-q=60 --ivf

mencoder -ovc x264 -x264encopts
preset=veryslow:pass=2:bitrate=250:tune=fastdecode:profile=baseline

(tune=fastdecode disables deblocking, the result file confirms all
heavy options are off)

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

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[James Almer]

On 1/13/2019 12:57 PM, Nicolas George wrote:
> James Almer (12019-01-13):
>> And kill the project by reducing development speed to crawl? Unreviewed
> 
> That is indeed the problem.
> 
>> and unchallenged patches by long time devs with commit rights can and
>> will still be pushed after enough time and ping attempts have been made.
>> Expecting anything else will take ffmpeg through the same road libav
>> found itself in.
>> Bad commits that were ignored but noticed after the fact have been
>> reverted in the past. They will inevitably crash under the weight of its
>> own crappiness. That will not change.
>>
>> Rewrite this patch, make it palatable, and then the rest of the project
>> will consider it. Stop wasting your and everyone's time by insisting on
>> a patch everyone NAKed.
> 
> You keep saying that, but you waltz around the problem. So let me state
> it plainly:
> 
> If there is somebody (1) who repeatedly pushes patches without review
> (because it is new code or because it is over code that they maintain by
> self-appointment), (2) whose patches frequently cause regressions, some
> of them detected by Coverity, (3) when they get a review and it requires
> more work from them, are rude and unhelpful, and possibly ignore the
> comments, (4) as a result from that rudeness receive even less reviews,
> and (5) all this seems to be motivated by sponsorship, can you tell what
> course of action you propose?

(1) is not an issue, (2) and (3) are the issue, and depending on the
developer's reaction at reviews and request for fixes, it should result
in the removal of commit rights.
Have you seen something forcefully pushed after reviews or concerns were
ignored by the committer because they capriciously didn't like said
reviews or reviewer, that wasn't eventually reverted or adapted? Does
the recent patch by Paul that prompted this abomination of a patch fit
the above criteria?

And (5) is completely irrelevant for the above. Bad code is bad code,
and bad behavior is bad behavior, regardless of the incentive behind it.
This patch of yours pretends to magically fix (2) to (4) by assuming
tackling (5) will have any effect.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Kieran O Leary]

On Sun, 13 Jan 2019, 15:57 Nicolas George  James Almer (12019-01-13):
> > And kill the project by reducing development speed to crawl? Unreviewed
>
> That is indeed the problem.
>
> > and unchallenged patches by long time devs with commit rights can and
> > will still be pushed after enough time and ping attempts have been made.
> > Expecting anything else will take ffmpeg through the same road libav
> > found itself in.
> > Bad commits that were ignored but noticed after the fact have been
> > reverted in the past. They will inevitably crash under the weight of its
> > own crappiness. That will not change.
> >
> > Rewrite this patch, make it palatable, and then the rest of the project
> > will consider it. Stop wasting your and everyone's time by insisting on
> > a patch everyone NAKed.
>
> You keep saying that, but you waltz around the problem. So let me state
> it plainly:
>
> If there is somebody (1) who repeatedly pushes patches without review
> (because it is new code or because it is over code that they maintain by
> self-appointment), (2) whose patches frequently cause regressions, some
> of them detected by Coverity, (3) when they get a review and it requires
> more work from them, are rude and unhelpful, and possibly ignore the
> comments, (4) as a result from that rudeness receive even less reviews,
> and (5) all this seems to be motivated by sponsorship, can you tell what
> course of action you propose?
>

How would declaring the sponsorship help in this regard,when the real issue
is your points 1 to 4?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Nicolas George]

James Almer (12019-01-13):
> And kill the project by reducing development speed to crawl? Unreviewed

That is indeed the problem.

> and unchallenged patches by long time devs with commit rights can and
> will still be pushed after enough time and ping attempts have been made.
> Expecting anything else will take ffmpeg through the same road libav
> found itself in.
> Bad commits that were ignored but noticed after the fact have been
> reverted in the past. They will inevitably crash under the weight of its
> own crappiness. That will not change.
> 
> Rewrite this patch, make it palatable, and then the rest of the project
> will consider it. Stop wasting your and everyone's time by insisting on
> a patch everyone NAKed.

You keep saying that, but you waltz around the problem. So let me state
it plainly:

If there is somebody (1) who repeatedly pushes patches without review
(because it is new code or because it is over code that they maintain by
self-appointment), (2) whose patches frequently cause regressions, some
of them detected by Coverity, (3) when they get a review and it requires
more work from them, are rude and unhelpful, and possibly ignore the
comments, (4) as a result from that rudeness receive even less reviews,
and (5) all this seems to be motivated by sponsorship, can you tell what
course of action you propose?

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference

[Derek Buitenhuis]

On 13/01/2019 15:45, James Almer wrote:
> If there is, i don't know it.
> 
> Float based fate tests have been fine tuned before when different
> architectures proved a certain stddev value was not lax enough, so this
> one could be increased if needed as well, but if you prefer i can use a
> big enough multiple of FLT_EPSILON instead.

Don't really have a strong opinion on it, no.

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

Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference

[James Almer]

On 1/13/2019 11:32 AM, Derek Buitenhuis wrote:
> On 13/01/2019 02:44, James Almer wrote:
>> Michael suggested 1000*FLT_EPSILON but IMO that's too big and may hide
>> errors in future implementations.
>> The value i used is the smallest value i found that didn't fail after
>> several runs. 6.1e-05 for example fails.
> 
> I figured that's how it was chosen (though not documented). I thought there
> be a way to calculate it properly instead of empirically.

If there is, i don't know it.

Float based fate tests have been fine tuned before when different
architectures proved a certain stddev value was not lax enough, so this
one could be increased if needed as well, but if you prefer i can use a
big enough multiple of FLT_EPSILON instead.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[James Almer]

On 1/13/2019 12:24 PM, Nicolas George wrote:
> James Almer (12019-01-13):
>> How is that related to sponsored work? If a patch was ignored, then the
>> extra line in the commit message would have been ignored as much as the
>> actual code.
> 
> Without sponsoring, most reasons for developing code are positively
> correlated with code quality. Not perfectly, but at least some.
> 
> Sponsorship, on the other hand, is a motivation for developing code that
> has little to do with code quality.
> 
> For that reason, sponsored code should be examined much more carefully.
> 
> Of course, if your stance were that no new code should go in without
> proper review, then I would support you totally, and possibly drop this
> proposal. Is it?

And kill the project by reducing development speed to crawl? Unreviewed
and unchallenged patches by long time devs with commit rights can and
will still be pushed after enough time and ping attempts have been made.
Expecting anything else will take ffmpeg through the same road libav
found itself in.
Bad commits that were ignored but noticed after the fact have been
reverted in the past. They will inevitably crash under the weight of its
own crappiness. That will not change.

Rewrite this patch, make it palatable, and then the rest of the project
will consider it. Stop wasting your and everyone's time by insisting on
a patch everyone NAKed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Nicolas George]

James Almer (12019-01-13):
> How is that related to sponsored work? If a patch was ignored, then the
> extra line in the commit message would have been ignored as much as the
> actual code.

Without sponsoring, most reasons for developing code are positively
correlated with code quality. Not perfectly, but at least some.

Sponsorship, on the other hand, is a motivation for developing code that
has little to do with code quality.

For that reason, sponsored code should be examined much more carefully.

Of course, if your stance were that no new code should go in without
proper review, then I would support you totally, and possibly drop this
proposal. Is it?

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[James Almer]

On 1/13/2019 12:06 PM, Nicolas George wrote:
> James Almer (12019-01-13):
>> If no one challenges, then either no one looked at it, or everyone that
>> looked at it was fine with it. Where is the issue then?
> 
> If nobody looked, how can we know there is no obvious security issue?

How is that related to sponsored work? If a patch was ignored, then the
extra line in the commit message would have been ignored as much as the
actual code.

> 
>> You're looking for a solution for a problem that doesn't exist.
> 
> Tell that to the people who have been insulted for raising valid
> objections on sponsored work.
> 
>> Sponsored work has been disclosed before without any kind of guidelines.
> 
> Not all of it.

And that is not going to change no matter how many lines with absurd and
unenforceable intrusive requirements you try to add to a file nobody
ever reads.

> 
>> If you want something people will not NAK on sight, write one where you
>> require to double check who the copyright belongs to in case of
>> sponsorship to prevent wrong commit authorship, and to *suggest* stating
>> sponsorship status if the copyright ultimately belongs to the developer.
>> Drop any mention about remuneration disclosure if it was not public to
>> begin with, and then it can be discussed.
> 
> Re-read the rationale in the proposed patch: copyright is only one of
> them.

And none of them change anything of what i said. You will not magically
generate new or better reviews for patches that otherwise would have not
gotten any.

The patch is unacceptable as is. Rewrite it into something closer to
what i mentioned above that encourages developers instead of disturb,
disgust and scare them away, and you'll be met with more amenability
from other developers in the project.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Nicolas George]

Derek Buitenhuis (12019-01-13):
> On 13/01/2019 14:52, Nicolas George wrote:
> > Therefore, I ask reasons: if you do not want to disclose your
> > sponsorships, please explain why?
> 
> https://en.wikipedia.org/wiki/Nothing_to_hide_argument

Exactly: the "nothing to hide" argument has good refutations in many
cases.

So please, give the refutations for this case.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Nicolas George]

James Almer (12019-01-13):
> If no one challenges, then either no one looked at it, or everyone that
> looked at it was fine with it. Where is the issue then?

If nobody looked, how can we know there is no obvious security issue?

> You're looking for a solution for a problem that doesn't exist.

Tell that to the people who have been insulted for raising valid
objections on sponsored work.

> Sponsored work has been disclosed before without any kind of guidelines.

Not all of it.

> If you want something people will not NAK on sight, write one where you
> require to double check who the copyright belongs to in case of
> sponsorship to prevent wrong commit authorship, and to *suggest* stating
> sponsorship status if the copyright ultimately belongs to the developer.
> Drop any mention about remuneration disclosure if it was not public to
> begin with, and then it can be discussed.

Re-read the rationale in the proposed patch: copyright is only one of
them.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Nicolas George]

Hendrik Leppkes (12019-01-13):
> You can't ask for arguments then dismiss the ones you are given based
> on your opinions.

I dismiss an opinion based on an opinion. Proof of the fact:

> I consider my finances and employment my own business, and will never
  ^^
> disclose it on *public* mailing list.

I do not remember the references, but I have seen at least one, possibly
several, serious studies showing that secrecy about salaries caused an
overall decrease in salaries and worsening in workplace interaction. It
is a management technique of the "divide and conquer" type to avoid
workers from organizing to get decent salaries.

The only people who should be attached to salary secrecy are the people
who at some level realize that they are payed way more than they deserve
(finance, marketing, etc.). For people whose work has actual value, like
you, this attachment is only the result of propaganda and detrimental to
yourself.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[James Almer]

On 1/13/2019 11:06 AM, Nicolas George wrote:
> James Almer (12019-01-13):
>> Be the change you want in the world and post your day job income here
>> for all to see. Otherwise drop this absurd obsession of yours and let
>> people have a peaceful weekend.
> 
> Of course:
> 
> All that I have received related to my work on FFmpeg is:
> 
> - coverage of my expanses to attend the VDD;
> 
> - some t-shirts and a few goodies.
> 
> The money that I would have received for mentoring in GSoC 2015 was
> given to the project.
> 
> Note that I do not make a point of pride of not having gotten much of
> street value from my work on this project, this is not the reason I do
> it. But you asked.
> 
> And to prove I really do not consider this a matter of privacy, I can
> add my income from not-FFmpeg related: I am a public servant of the
> French Éducation nationale in the PRAG corps at the salary step 9 with
> as little overtime as accepted (0-2 hours depending on the year) plus
> one hour of oral interrogation in prépa and a few yearly hours of
> coordination with a project. The monetary amounts for all this is of
> public record.
> 
>> A patch pushed without review, if it gets challenged after the fact,
>> will get reverted unless fixed/addressed, like it happened plenty of
>> times.
> 
> And who will do the challenging, since we already do not have enough
> time to review the patches in the first place?

If no one challenges, then either no one looked at it, or everyone that
looked at it was fine with it. Where is the issue then?

You're looking for a solution for a problem that doesn't exist. If a
patch is disliked, it will be challenged, regardless of the incentive
behind it. If a patch is not challenged, then it was either ignored or
liked, and likewise, the incentive behind it had no relevance. This
patch you propose will not change that.

Sponsored work has been disclosed before without any kind of guidelines.
This patch, in its current form, is both unnecessary and completely
unacceptable.
If you want something people will not NAK on sight, write one where you
require to double check who the copyright belongs to in case of
sponsorship to prevent wrong commit authorship, and to *suggest* stating
sponsorship status if the copyright ultimately belongs to the developer.
Drop any mention about remuneration disclosure if it was not public to
begin with, and then it can be discussed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Derek Buitenhuis]

On 13/01/2019 14:52, Nicolas George wrote:
> Therefore, I ask reasons: if you do not want to disclose your
> sponsorships, please explain why?

https://en.wikipedia.org/wiki/Nothing_to_hide_argument

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

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Hendrik Leppkes]

On Sun, Jan 13, 2019 at 2:40 PM Nicolas George  wrote:
>
> James Almer (12019-01-13):
> > I seem to remember the famous votes count voices, if one were to be called.
>
> You should check again, the rules state that mails without arguments do
> not count.
>
> > Nicolas, no one is in favor of this thing. It's an invasion of privacy
>
> I do not consider this specific point worthy of privacy protection.
>

You can't ask for arguments then dismiss the ones you are given based
on your opinions.
I consider my finances and employment my own business, and will never
disclose it on *public* mailing list.

Therefor, such a policy is entirely unacceptable.

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

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Nicolas George]

Derek Buitenhuis (12019-01-13):
> No, I don't think that, and I think it's offensive to the people who you
> accuse of that.

I do not accuse them of that, but I find the lack of reasons highly
suspicious. Most times somebody wants something but does not give a
reason, it happens that the reason is rather bad.

Therefore, I ask reasons: if you do not want to disclose your
sponsorships, please explain why?

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Derek Buitenhuis]

On 13/01/2019 14:38, Nicolas George wrote:
> Any unmotivated objection can be interpreted as "I push bad code for a
> quick buck and do not intend to stop", do you not think?

No, I don't think that, and I think it's offensive to the people who you
accuse of that.

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

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Nicolas George]

Derek Buitenhuis (12019-01-13):
> This is a policy change, not a techncal change.

Policy changes need to be motivated too.

Any unmotivated objection can be interpreted as "I push bad code for a
quick buck and do not intend to stop", do you not think?

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Derek Buitenhuis]

On 13/01/2019 13:18, Nicolas George wrote:
> I seem to remember that arguments count, not voices. I have given
> several arguments in the commit message, almost none of them were
> addressed and the dissenting arguments were feeble at best.

This is a policy change, not a techncal change.

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

Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference

[Derek Buitenhuis]

On 13/01/2019 02:44, James Almer wrote:
> Michael suggested 1000*FLT_EPSILON but IMO that's too big and may hide
> errors in future implementations.
> The value i used is the smallest value i found that didn't fail after
> several runs. 6.1e-05 for example fails.

I figured that's how it was chosen (though not documented). I thought there
be a way to calculate it properly instead of empirically.

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

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Gyan]

On 13-01-2019 06:39 PM, Ronald S. Bultje wrote:

Hi,

On Sun, Jan 13, 2019 at 4:39 AM Gyan  wrote:


When someone submits a patch, it is implicit, unless stated otherwise,
that it is of their own initiative (and their own work), and thus they
are free to assign copyright. When work is performed for hire, the
copyright may belong to the employer. Such sponsored work cannot be
'donated' to the project


But we don't do copyright assignment.



No, the patch submitter (implicitly) does. Which is not a problem when 
the copyright holder and submitter are the same person. For sponsored 
code, they may not be.


Analogy:

Scenario 1

A 'vlogger' makes a video and uploads it as public to Youtube. Youtube 
then lets everyone see that video. No problem.


Scenario 2

Someone pays the vlogger to make a video. Vlogger uploads it to YT as 
public. There's a problem if the client did not allow that which makes 
it copyright infringement, Which is why YT has this clause in their T


"You affirm, represent, and warrant that you own or have the necessary 
licenses, rights, consents, and permissions to publish Content you 
submit; and you license to YouTube all patent, trademark, trade secret, 
copyright or other proprietary rights in and to such Content for 
publication on the Service pursuant to these Terms of Service."


So, we are YT in this case and the Content is the patch(es). The concern 
would be that the submitter doesn't have the right to license the code 
into ffmpeg, if the contract with the client doesn't allow them to do 
it. Only way to be sure is for the sponsor to affirm to it. And for 
that, we would have to know that there is a sponsor, to start with.


Gyan

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

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Nicolas George]

James Almer (12019-01-13):
> Be the change you want in the world and post your day job income here
> for all to see. Otherwise drop this absurd obsession of yours and let
> people have a peaceful weekend.

Of course:

All that I have received related to my work on FFmpeg is:

- coverage of my expanses to attend the VDD;

- some t-shirts and a few goodies.

The money that I would have received for mentoring in GSoC 2015 was
given to the project.

Note that I do not make a point of pride of not having gotten much of
street value from my work on this project, this is not the reason I do
it. But you asked.

And to prove I really do not consider this a matter of privacy, I can
add my income from not-FFmpeg related: I am a public servant of the
French Éducation nationale in the PRAG corps at the salary step 9 with
as little overtime as accepted (0-2 hours depending on the year) plus
one hour of oral interrogation in prépa and a few yearly hours of
coordination with a project. The monetary amounts for all this is of
public record.

> A patch pushed without review, if it gets challenged after the fact,
> will get reverted unless fixed/addressed, like it happened plenty of
> times.

And who will do the challenging, since we already do not have enough
time to review the patches in the first place?

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Nicolas George]

James Almer (12019-01-13):
> I seem to remember the famous votes count voices, if one were to be called.

You should check again, the rules state that mails without arguments do
not count.

> Nicolas, no one is in favor of this thing. It's an invasion of privacy

I do not consider this specific point worthy of privacy protection.

> and has no way to be enforced.

Are you assuming that the contributors, especially the sponsored ones,
are usually dishonest? I do not. The way to "enforce" this is to remind
people when something suggests they might have neglected to do it, and
expect honesty from them.

If you consider the contributors dishonest, a much stronger measure is
necessary, I hope you agree.

>It will potentially deter contributions

And it will potentially attract contributions.

> and generate bias among reviewers if the patch states it's sponsored
> nature.

And correct the bias among submitters when it is.

> The last thing this project needs is more walls and more
> aggressiveness.
> 
> You and you alone want this in, and everyone else so far doesn't. It's
> not making it in.

Then I will ask you, and everybody who objects, this:

How do you propose to address the conflict of interest of a sponsored
contributor pushing a patch without review?

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[James Almer]

On 1/13/2019 10:18 AM, Nicolas George wrote:
> Ronald S. Bultje (12019-01-13):
>> But we don't do copyright assignment.
> 
> There have been efforts of relicensing in the past.²
> 
>> Anyway, like several others, I'm against this proposal.
> 
> I seem to remember that arguments count, not voices.

I seem to remember the famous votes count voices, if one were to be called.

> I have given
> several arguments in the commit message, almost none of them were
> addressed and the dissenting arguments were feeble at best.

Nicolas, no one is in favor of this thing. It's an invasion of privacy
and has no way to be enforced. It will potentially deter contributions
and generate bias among reviewers if the patch states it's sponsored
nature. The last thing this project needs is more walls and more
aggressiveness.

You and you alone want this in, and everyone else so far doesn't. It's
not making it in.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Paul B Mahol]

On 1/13/19, Nicolas George  wrote:
> Ronald S. Bultje (12019-01-13):
>> But we don't do copyright assignment.
>
> There have been efforts of relicensing in the past.²
>
>> Anyway, like several others, I'm against this proposal.
>
> I seem to remember that arguments count, not voices. I have given
> several arguments in the commit message, almost none of them were
> addressed and the dissenting arguments were feeble at best.

Patch looks very good to me to get applied.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Nicolas George]

Ronald S. Bultje (12019-01-13):
> But we don't do copyright assignment.

There have been efforts of relicensing in the past.²

> Anyway, like several others, I'm against this proposal.

I seem to remember that arguments count, not voices. I have given
several arguments in the commit message, almost none of them were
addressed and the dissenting arguments were feeble at best.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Ronald S. Bultje]

Hi,

On Sun, Jan 13, 2019 at 4:39 AM Gyan  wrote:

> When someone submits a patch, it is implicit, unless stated otherwise,
> that it is of their own initiative (and their own work), and thus they
> are free to assign copyright. When work is performed for hire, the
> copyright may belong to the employer. Such sponsored work cannot be
> 'donated' to the project
>

But we don't do copyright assignment.

Anyway, like several others, I'm against this proposal.

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

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Nicolas George]

Gyan (12019-01-13):
> One angle that I haven't seen brought up is legal encumbrance.
> 
> When someone submits a patch, it is implicit, unless stated otherwise, that
> it is of their own initiative (and their own work), and thus they are free
> to assign copyright. When work is performed for hire, the copyright may
> belong to the employer. Such sponsored work cannot be 'donated' to the
> project unless the employer agrees to it - it is not for the patch submitter
> to decide. In such a scenario, the project should know who holds the
> copyright and under what terms are they willing to submit a patch.

Thanks, I had not thought of that. I added this in the commit message:

* This information is sometimes necessary to determine exactly who 
  owns the copyright for the new code.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH v6] libswscale/ppc: VSX-optimize 9-16 bit yuv2planeX

[Lauri Kasanen]

./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt 
yuv420p16be \
-s 1920x1728 -f null -vframes 100 -v error -nostats -

9-14 bit funcs get about 6x speedup, 16-bit gets about 15x.
Fate passes, each format tested with an image to video conversion.

Only POWER8 includes 32-bit vector multiplies, so POWER7 is locked out
of the 16-bit function. This includes the vec_mulo/mule functions too,
not just vmuluwm.

With TIMER_REPORT skips disabled:
yuv420p9le
  12412 UNITS in planarX,  131072 runs,  0 skips
  73136 UNITS in planarX,  131072 runs,  0 skips
yuv420p9be
  12481 UNITS in planarX,  131072 runs,  0 skips
  73410 UNITS in planarX,  131072 runs,  0 skips
yuv420p10le
  12322 UNITS in planarX,  131072 runs,  0 skips
  72546 UNITS in planarX,  131072 runs,  0 skips
yuv420p10be
  12291 UNITS in planarX,  131072 runs,  0 skips
  72935 UNITS in planarX,  131072 runs,  0 skips
yuv420p12le
  12316 UNITS in planarX,  131072 runs,  0 skips
  72708 UNITS in planarX,  131072 runs,  0 skips
yuv420p12be
  12319 UNITS in planarX,  131072 runs,  0 skips
  72577 UNITS in planarX,  131072 runs,  0 skips
yuv420p14le
  12259 UNITS in planarX,  131072 runs,  0 skips
  72516 UNITS in planarX,  131072 runs,  0 skips
yuv420p14be
  12440 UNITS in planarX,  131072 runs,  0 skips
  72962 UNITS in planarX,  131072 runs,  0 skips
yuv420p16le
  10548 UNITS in planarX,  131072 runs,  0 skips
  73429 UNITS in planarX,  131072 runs,  0 skips
yuv420p16be
  10634 UNITS in planarX,  131072 runs,  0 skips
 150959 UNITS in planarX,  131072 runs,  0 skips

Signed-off-by: Lauri Kasanen 
---
 libswscale/ppc/swscale_ppc_template.c |   4 +-
 libswscale/ppc/swscale_vsx.c  | 186 +-
 2 files changed, 184 insertions(+), 6 deletions(-)

v6: No patch changes, updated bench numbers without skips.

diff --git a/libswscale/ppc/swscale_ppc_template.c 
b/libswscale/ppc/swscale_ppc_template.c
index 00e4b99..11decab 100644
--- a/libswscale/ppc/swscale_ppc_template.c
+++ b/libswscale/ppc/swscale_ppc_template.c
@@ -21,7 +21,7 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
-static void FUNC(yuv2planeX_16)(const int16_t *filter, int filterSize,
+static void FUNC(yuv2planeX_8_16)(const int16_t *filter, int filterSize,
   const int16_t **src, uint8_t *dest,
   const uint8_t *dither, int offset, int x)
 {
@@ -88,7 +88,7 @@ static void FUNC(yuv2planeX)(const int16_t *filter, int 
filterSize,
 yuv2planeX_u(filter, filterSize, src, dest, dst_u, dither, offset, 0);
 
 for (i = dst_u; i < dstW - 15; i += 16)
-FUNC(yuv2planeX_16)(filter, filterSize, src, dest + i, dither,
+FUNC(yuv2planeX_8_16)(filter, filterSize, src, dest + i, dither,
   offset, i);
 
 yuv2planeX_u(filter, filterSize, src, dest, dstW, dither, offset, i);
diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index 70da6ae..f6c7f1d 100644
--- a/libswscale/ppc/swscale_vsx.c
+++ b/libswscale/ppc/swscale_vsx.c
@@ -83,6 +83,8 @@
 #include "swscale_ppc_template.c"
 #undef FUNC
 
+#undef vzero
+
 #endif /* !HAVE_BIGENDIAN */
 
 static void yuv2plane1_8_u(const int16_t *src, uint8_t *dest, int dstW,
@@ -180,6 +182,76 @@ static void yuv2plane1_nbps_vsx(const int16_t *src, 
uint16_t *dest, int dstW,
 yuv2plane1_nbps_u(src, dest, dstW, big_endian, output_bits, i);
 }
 
+static void yuv2planeX_nbps_u(const int16_t *filter, int filterSize,
+  const int16_t **src, uint16_t *dest, int dstW,
+  int big_endian, int output_bits, int start)
+{
+int i;
+int shift = 11 + 16 - output_bits;
+
+for (i = start; i < dstW; i++) {
+int val = 1 << (shift - 1);
+int j;
+
+for (j = 0; j < filterSize; j++)
+val += src[j][i] * filter[j];
+
+output_pixel([i], val);
+}
+}
+
+static void yuv2planeX_nbps_vsx(const int16_t *filter, int filterSize,
+const int16_t **src, uint16_t *dest, int dstW,
+int big_endian, int output_bits)
+{
+const int dst_u = -(uintptr_t)dest & 7;
+const int shift = 11 + 16 - output_bits;
+const int add = (1 << (shift - 1));
+const int clip = (1 << output_bits) - 1;
+const uint16_t swap = big_endian ? 8 : 0;
+const vector uint32_t vadd = (vector uint32_t) {add, add, add, add};
+const vector uint32_t vshift = (vector uint32_t) {shift, shift, shift, 
shift};
+const vector uint16_t vswap = (vector uint16_t) {swap, swap, swap, swap, 
swap, swap, swap, swap};
+const vector uint16_t vlargest = (vector uint16_t) {clip, clip, clip, 
clip, clip, clip, clip, clip};
+const vector int16_t vzero = vec_splat_s16(0);
+const vector uint8_t vperm = (vector uint8_t) {0, 1, 8, 9, 2, 3, 10, 11, 
4, 

Re: [FFmpeg-devel] [PATCH] avcodec/tests/rangecoder: initialize array to avoid valgrind warning

[Steven Liu]

> On Jan 12, 2019, at 22:49, Michael Niedermayer  wrote:
> 
> On Fri, Jan 04, 2019 at 02:46:29AM +0100, Michael Niedermayer wrote:
>> Found-by: jamrial
>> Signed-off-by: Michael Niedermayer 
>> ---
>> libavcodec/tests/rangecoder.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> i intend to apply this soon unless there are more comments, i did not
> understand the only comment :(
Hi Michael,

Sorry for my comment, i think you are right,
i mean the r should initialized too, but it have been initialized 
completely a few lines later.


> 
> [...]
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> "I am not trying to be anyone's saviour, I'm trying to think about the
> future and not be sad" - Elon Musk
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks
Steven





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