Re: [FFmpeg-devel] [PATCH] Support for zulu timezone format for PDT in HLS playlists

2019-11-14 Thread Steven Liu


> 在 2019年11月3日,20:14,Marton Balint  写道:
> 
> 
> 
> On Fri, 25 Oct 2019, Ole Andre Birkedal wrote:
> 
>> I think this is the best solution, with just one new flag +utc_pdt that will 
>> force timestamps of PDT to be in UTC with the format -MM-DDThh:mm:ssZ. 
>> Too many flags will be confusing, and the "zulu" name can be a bit confusing 
>> so I removed any mention of that.
> 
> Agreed.
> 
> +@item utc_pdt
> +Always use UTC timezone in @code{EXT-X-PROGRAM-DATE-TIME} tags with format
> +@code{#EXT-X-PROGRAM-DATE-TIME:}.
> +
> 
> The format is not entirely correct, miliseconds are also part of the output.

ping Ole Andre Birkedal

> 
> +// Generate correct offset string if we're not using UTC
> +if (!utc_pdt && !strftime(buf1, sizeof(buf1), "%z", tm) ||
> +buf1[1]<'0' || buf1[1]>'2') {
> 
> There seems to be an operator precedence issue here.
> 
> Other than that looks good, but Steven Liu is the maintainer of hls.
> 
> Regards,
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Thanks
Steven





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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/1] add without_captureblt option for libavdevice/gdigrab.c, when useing the bitblt function with CAPTUREBLT it caused the mouse cursor flicker. most time we dont need this flag

2019-11-14 Thread _ FgoDt
From: fgodt 

Signed-off-by: fgodt 
---
 libavdevice/gdigrab.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
index f406fa..0ab0cfed01 100644
--- a/libavdevice/gdigrab.c
+++ b/libavdevice/gdigrab.c
@@ -53,6 +53,8 @@ struct gdigrab {
 intoffset_x;/**< Capture x offset (private option) */
 intoffset_y;/**< Capture y offset (private option) */
 
+intwithout_captureblt; /**< capture without captureblt */
+
 HWND   hwnd;/**< Handle of the window for the grab */
 HDCsource_hdc;  /**< Source device context */
 HDCdest_hdc;/**< Destination, source-compatible DC */
@@ -542,6 +544,8 @@ static int gdigrab_read_packet(AVFormatContext *s1, 
AVPacket *pkt)
 
 int64_t curtime, delay;
 
+unsigned long flag;
+
 /* Calculate the time of the next frame */
 time_frame += INT64_C(100);
 
@@ -570,12 +574,16 @@ static int gdigrab_read_packet(AVFormatContext *s1, 
AVPacket *pkt)
 return AVERROR(ENOMEM);
 pkt->pts = curtime;
 
+flag = SRCCOPY;
+if(!gdigrab->without_captureblt)
+flag |= CAPTUREBLT;
+
 /* Blit screen grab */
 if (!BitBlt(dest_hdc, 0, 0,
 clip_rect.right - clip_rect.left,
 clip_rect.bottom - clip_rect.top,
 source_hdc,
-clip_rect.left, clip_rect.top, SRCCOPY | CAPTUREBLT)) {
+clip_rect.left, clip_rect.top, flag)) {
 WIN32_API_ERROR("Failed to capture image");
 return AVERROR(EIO);
 }
@@ -639,6 +647,7 @@ static const AVOption options[] = {
 { "video_size", "set video frame size", OFFSET(width), 
AV_OPT_TYPE_IMAGE_SIZE, {.str = NULL}, 0, 0, DEC },
 { "offset_x", "capture area x offset", OFFSET(offset_x), AV_OPT_TYPE_INT, 
{.i64 = 0}, INT_MIN, INT_MAX, DEC },
 { "offset_y", "capture area y offset", OFFSET(offset_y), AV_OPT_TYPE_INT, 
{.i64 = 0}, INT_MIN, INT_MAX, DEC },
+{ "without_captureblt", "capture without captureblt", 
OFFSET(without_captureblt), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, DEC },
 { NULL },
 };
 
-- 
2.23.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avdevice/decklink: add option to drop frames till timecode is seen

2019-11-14 Thread Gyan



On 15-11-2019 03:23 am, Marton Balint wrote:



On Wed, 13 Nov 2019, Gyan wrote:

As suggested in the review of an earlier patch*, this one drops 
frames till a TC is seen.





From 0932db9d14dea215c1b0e5dcac4eac16cd6a Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Mon, 9 Sep 2019 18:33:09 +0530
Subject: [PATCH] avdevice/decklink: add option to drop frames till 
timecode is

 seen

Option wait_for_tc only takes effect if tc_format is set
---
 libavdevice/decklink_common.h   |  1 +
 libavdevice/decklink_common_c.h |  1 +
 libavdevice/decklink_dec.cpp    | 12 
 libavdevice/decklink_dec_c.c    |  1 +
 4 files changed, 15 insertions(+)


Docs update is missing for the new option as well as micro version bump.


Added.




diff --git a/libavdevice/decklink_common.h 
b/libavdevice/decklink_common.h

index 921818ba41..35422a300b 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -149,6 +149,7 @@ struct decklink_ctx {

 int channels;
 int audio_depth;
+    unsigned long tc_seen;    // used with option wait_for_tc
 };

 typedef enum { DIRECTION_IN, DIRECTION_OUT} decklink_direction_t;
diff --git a/libavdevice/decklink_common_c.h 
b/libavdevice/decklink_common_c.h

index ca85ec2504..b78630b5fc 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -58,6 +58,7 @@ struct decklink_cctx {
 int copyts;
 int64_t timestamp_align;
 int timing_offset;
+    int wait_for_tc;
 };

 #endif /* AVDEVICE_DECKLINK_COMMON_C_H */
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 4da9122bff..69be37ed64 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -784,6 +784,8 @@ HRESULT 
decklink_input_callback::VideoInputFrameArrived(

 if (packed_metadata) {
 if (av_packet_add_side_data(, 
AV_PKT_DATA_STRINGS_METADATA, packed_metadata, metadata_len) < 0)

av_freep(_metadata);
+    else if (!ctx->tc_seen)
+    ctx->tc_seen = ctx->frameCount;
 }
 }
 }
@@ -793,6 +795,14 @@ HRESULT 
decklink_input_callback::VideoInputFrameArrived(

 }
 }

+    if (ctx->tc_format && cctx->wait_for_tc && !ctx->tc_seen) {
+
+    av_log(avctx, AV_LOG_WARNING, "No TC detected yet. 
wait_for_tc set. Dropping. \n");

+    av_log(avctx, AV_LOG_WARNING, "Frame received (#%lu) - "
+    "- Frames dropped %u\n", ctx->frameCount, 
++ctx->dropped);

+    return S_OK;
+    }
+
 pkt.pts = get_pkt_pts(videoFrame, audioFrame, wallclock, 
abs_wallclock, ctx->video_pts_source, ctx->video_st->time_base, 
_video_pts, cctx->copyts);

 pkt.dts = pkt.pts;

@@ -880,6 +890,8 @@ HRESULT 
decklink_input_callback::VideoInputFrameArrived(

 videoFrame->AddRef();

 if (avpacket_queue_put(>queue, ) < 0) {
+    if (ctx->tc_seen == ctx->frameCount)
+    ctx->tc_seen = 0;


I don't think this is needed, this can only happen in an ENOMEM case. 
Keep it if you feel strongly about it, but it looks a rather useless 
corner case to me.


Removed.


LGTM if docs is added.


Revised patch attached.

Thanks,
Gyan
From d76ed7ec1582a2050c9cfc755c243da22bb3c41a Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Mon, 9 Sep 2019 18:33:09 +0530
Subject: [PATCH v2] avdevice/decklink: add option to drop frames till timecode
 is seen

Option wait_for_tc only takes effect if tc_format is set
---
 doc/indevs.texi |  8 
 libavdevice/decklink_common.h   |  1 +
 libavdevice/decklink_common_c.h |  1 +
 libavdevice/decklink_dec.cpp| 10 ++
 libavdevice/decklink_dec_c.c|  1 +
 libavdevice/version.h   |  2 +-
 6 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/doc/indevs.texi b/doc/indevs.texi
index 14595774f3..bc791013f2 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -395,6 +395,14 @@ Either sync could go wrong by 1 frame or in a rarer case
 @option{timestamp_align} seconds.
 Defaults to @samp{0}.
 
+@item wait_for_tc (@emph{bool})
+Drop frames till a frame with timecode is received. Sometimes serial timecode
+isn't received with the first input frame. If that happens, the stored stream
+timecode will be inaccurate. If this option is set to @option{true}, input 
frames
+are dropped till a frame with timecode is received.
+Option @var{timecode_format} must have been set.
+Defaults to @option{false}.
+
 @end table
 
 @subsection Examples
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 921818ba41..35422a300b 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -149,6 +149,7 @@ struct decklink_ctx {
 
 int channels;
 int audio_depth;
+unsigned long tc_seen;// used with option wait_for_tc
 };
 
 typedef enum { 

Re: [FFmpeg-devel] [PATCH] avdevice/decklink: add option to drop frames till timecode is seen

2019-11-14 Thread Gyan



On 15-11-2019 03:02 am, Marton Balint wrote:



On Wed, 13 Nov 2019, Ilinca Tudose wrote:

My previous email was incorrect about "-wait_for_tc 1". The 2 
commands used

were:

(1)
ffmpeg -loglevel trace  -timecode_format rp188any  -wait_for_tc 1 -f
decklink -probesize 15M -analyzeduration 5M -i "DeckLink Quad (1)" -t 30
-preset veryfast output.mov

(2)
ffmpeg -loglevel trace  -timecode_format rp188any  -wait_for_tc 1 -f
decklink -i "DeckLink Quad (1)" -t 30 -preset veryfast output.mov

The second command is the one that produced 1 frame offset in 3 of the
captures. The first command had 0 frames offset for all files tried.


These two command lines are only different in probesize and
analyzeduration. I don't understand how these two options can make any
difference regarding the TC offset. Can you figure out which one 
actually causes the issue?


It's not related. Initially,before my patch, they were trying to capture 
TC with format_code set. Because of the lag, the probe limits would 
usually be exhausted before the TC arrived.
With my initial patch in July, which compensated for the lag, extended 
probe was still required. With the current one, it's not.


Ilinca can supply details but the offset occurs infrequently and on 
repeating the capture, would not show an offset. BM Decklink support has 
been unable to reproduce the issue with their capture utility.


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/scale: allow dynamic output via expressions

2019-11-14 Thread Gyan



On 15-11-2019 04:01 am, Michael Niedermayer wrote:

On Thu, Nov 14, 2019 at 11:12:23PM +0530, Gyan wrote:


On 14-11-2019 01:12 am, Michael Niedermayer wrote:

Moving and changing code at the same time makes it hard to see th difference.
Idealy all code moves should be seperate from changes to the code.

also more generally, spliting this patch up would simpify review

Split into two. First patch mostly moves code and keeps existing
functionality. 2nd patch introduces new features and requires the new eval
function.

Thanks,
Gyan
  Makefile   |4 -
  scale.c|   72 +-
  vf_scale.c |  192 
-
  3 files changed, 196 insertions(+), 72 deletions(-)
77579fdbd7add3be08bada5ee401df41f60ea236  
v2-0001-avfilter-scale-shift-ff_scale_eval_dimensions-inl.patch
 From 359f538703865c8ebeda16b5d1846d2cf1cf9c4d Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Thu, 14 Nov 2019 21:08:32 +0530
Subject: [PATCH v2 1/2] avfilter/scale: shift ff_scale_eval_dimensions inline

This is a perfunctory change in preparation of adding
direct animation support to scale and scale2ref filters
---
  libavfilter/Makefile   |   4 +-
  libavfilter/scale.c|  72 +---
  libavfilter/vf_scale.c | 192 -
  3 files changed, 196 insertions(+), 72 deletions(-)

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fce930360d..f1f6994574 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -358,12 +358,12 @@ OBJS-$(CONFIG_ROBERTS_OPENCL_FILTER) += 
vf_convolution_opencl.o opencl.o
  opencl/convolution.o
  OBJS-$(CONFIG_ROTATE_FILTER) += vf_rotate.o
  OBJS-$(CONFIG_SAB_FILTER)+= vf_sab.o
-OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o scale.o
+OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o
  OBJS-$(CONFIG_SCALE_CUDA_FILTER) += vf_scale_cuda.o 
vf_scale_cuda.ptx.o
  OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
  OBJS-$(CONFIG_SCALE_QSV_FILTER)  += vf_scale_qsv.o
  OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o 
vaapi_vpp.o
-OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale.o
+OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o
  OBJS-$(CONFIG_SCROLL_FILTER) += vf_scroll.o
  OBJS-$(CONFIG_SELECT_FILTER) += f_select.o
  OBJS-$(CONFIG_SELECTIVECOLOR_FILTER) += vf_selectivecolor.o
diff --git a/libavfilter/scale.c b/libavfilter/scale.c
index eaee95fac6..668aa04622 100644
--- a/libavfilter/scale.c
+++ b/libavfilter/scale.c
@@ -60,49 +60,6 @@ enum var_name {
  VARS_NB
  };
  
-/**

- * This must be kept in sync with var_names so that it is always a
- * complete list of var_names with the scale2ref specific names
- * appended. scale2ref values must appear in the order they appear
- * in the var_name_scale2ref enum but also be below all of the
- * non-scale2ref specific values.
- */
-static const char *const var_names_scale2ref[] = {
-"PI",
-"PHI",
-"E",
-"in_w",   "iw",
-"in_h",   "ih",
-"out_w",  "ow",
-"out_h",  "oh",
-"a",
-"sar",
-"dar",
-"hsub",
-"vsub",
-"ohsub",
-"ovsub",
-"main_w",
-"main_h",
-"main_a",
-"main_sar",
-"main_dar", "mdar",
-"main_hsub",
-"main_vsub",
-NULL
-};
-
-enum var_name_scale2ref {
-VAR_S2R_MAIN_W,
-VAR_S2R_MAIN_H,
-VAR_S2R_MAIN_A,
-VAR_S2R_MAIN_SAR,
-VAR_S2R_MAIN_DAR, VAR_S2R_MDAR,
-VAR_S2R_MAIN_HSUB,
-VAR_S2R_MAIN_VSUB,
-VARS_S2R_NB
-};
-
  int ff_scale_eval_dimensions(void *log_ctx,
  const char *w_expr, const char *h_expr,
  AVFilterLink *inlink, AVFilterLink *outlink,
@@ -115,16 +72,7 @@ int ff_scale_eval_dimensions(void *log_ctx,
  int factor_w, factor_h;
  int eval_w, eval_h;
  int ret;
-const char scale2ref = outlink->src->nb_inputs == 2 && 
outlink->src->inputs[1] == inlink;
-double var_values[VARS_NB + VARS_S2R_NB], res;
-const AVPixFmtDescriptor *main_desc;
-const AVFilterLink *main_link;
-const char *const *names = scale2ref ? var_names_scale2ref : var_names;
-
-if (scale2ref) {
-main_link = outlink->src->inputs[0];
-main_desc = av_pix_fmt_desc_get(main_link->format);
-}
+double var_values[VARS_NB], res;
  
  var_values[VAR_PI]= M_PI;

  var_values[VAR_PHI]   = M_PHI;
@@ -142,32 +90,20 @@ int ff_scale_eval_dimensions(void *log_ctx,
  var_values[VAR_OHSUB] = 1 << out_desc->log2_chroma_w;
  var_values[VAR_OVSUB] = 1 << out_desc->log2_chroma_h;
  
-if (scale2ref) {

-var_values[VARS_NB + VAR_S2R_MAIN_W] = main_link->w;
-var_values[VARS_NB + VAR_S2R_MAIN_H] = main_link->h;
-var_values[VARS_NB + VAR_S2R_MAIN_A] = (double) main_link->w / 
main_link->h;
-var_values[VARS_NB + 

Re: [FFmpeg-devel] [PATCH V1] lavfi/superfastblur: add superfastblur filter

2019-11-14 Thread myp...@gmail.com
On Fri, Nov 15, 2019 at 1:26 AM Michael Niedermayer
 wrote:
>
> On Wed, Nov 13, 2019 at 12:24:34AM +0100, Paul B Mahol wrote:
> > On 11/13/19, Michael Niedermayer  wrote:
> > > On Tue, Nov 12, 2019 at 12:48:09PM +0100, Paul B Mahol wrote:
> > >> If this filter is same speed or better than boxblur, it should replace
> > >> boxblur filter, as boxblur filter is GPL.
> > >
> > > relicensing boxblur should not be hard if someone needs the code to be
> > > under lgpl
> >
> > I do not think so, look at geq, lots of devs no longer contactable,
>
> who did you already contact about boxblur relicensing ?
> i looked at the log and at the changes and i see noone i think wouldnt
> reply whos change couldnt be rewritten in less than 5minutes
> maybe someone could be on vacation and not check their email for a month ...
>
> you know, just tell me who is the problem and which lines and ill either
> contact them, rewrite the code or just revert their change
>
> Thanks
>
I am OK if we can relicese the boxblur and drop this patch.

BTW: https://patchwork.ffmpeg.org/patch/16246/ is the other blur :)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] backport NULL pointer dereference fix / CVE-2019-17539 / 15733 clusterfuzz

2019-11-14 Thread Michael Niedermayer
On Thu, Nov 14, 2019 at 03:01:29PM -0500, James Boyle wrote:
> Hello,
> 
> This patch is nearly identical to commit
> 8df6884832ec413cf032dfaa45c23b1c7876670c, but is intended to backport
> the fix for CVE-2019-17539 to ffmpeg version 3.4.6, which is in use on
> RHEL 7 systems that get ffmpeg from rpmfusion.
> 
> https://github.com/FFmpeg/FFmpeg/commit/8df6884832ec413cf032dfaa45c23b1c7876670c
> 
> ---
>  libavcodec/utils.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

This and "[PATCH 2/2] backport out of array access fix / CVE-2019-17542 / 15919 
clusterfuzz"
and more than 200 other fixes 
will be part of the next release from the 3.4 branch
in fact i already have fixes for these 2 backported locally, just not pushed

ill try to get these pushed to the branch after a bit of sleep

Thanks

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

Observe your enemies, for they first find out your faults. -- Antisthenes


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/scale: allow dynamic output via expressions

2019-11-14 Thread Michael Niedermayer
On Thu, Nov 14, 2019 at 11:12:23PM +0530, Gyan wrote:
> 
> 
> On 14-11-2019 01:12 am, Michael Niedermayer wrote:
> >Moving and changing code at the same time makes it hard to see th difference.
> >Idealy all code moves should be seperate from changes to the code.
> >
> >also more generally, spliting this patch up would simpify review
> 
> Split into two. First patch mostly moves code and keeps existing
> functionality. 2nd patch introduces new features and requires the new eval
> function.
> 
> Thanks,
> Gyan

>  Makefile   |4 -
>  scale.c|   72 +-
>  vf_scale.c |  192 
> -
>  3 files changed, 196 insertions(+), 72 deletions(-)
> 77579fdbd7add3be08bada5ee401df41f60ea236  
> v2-0001-avfilter-scale-shift-ff_scale_eval_dimensions-inl.patch
> From 359f538703865c8ebeda16b5d1846d2cf1cf9c4d Mon Sep 17 00:00:00 2001
> From: Gyan Doshi 
> Date: Thu, 14 Nov 2019 21:08:32 +0530
> Subject: [PATCH v2 1/2] avfilter/scale: shift ff_scale_eval_dimensions inline
> 
> This is a perfunctory change in preparation of adding
> direct animation support to scale and scale2ref filters
> ---
>  libavfilter/Makefile   |   4 +-
>  libavfilter/scale.c|  72 +---
>  libavfilter/vf_scale.c | 192 -
>  3 files changed, 196 insertions(+), 72 deletions(-)
> 
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index fce930360d..f1f6994574 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -358,12 +358,12 @@ OBJS-$(CONFIG_ROBERTS_OPENCL_FILTER) += 
> vf_convolution_opencl.o opencl.o
>  opencl/convolution.o
>  OBJS-$(CONFIG_ROTATE_FILTER) += vf_rotate.o
>  OBJS-$(CONFIG_SAB_FILTER)+= vf_sab.o
> -OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o scale.o
> +OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o
>  OBJS-$(CONFIG_SCALE_CUDA_FILTER) += vf_scale_cuda.o 
> vf_scale_cuda.ptx.o
>  OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
>  OBJS-$(CONFIG_SCALE_QSV_FILTER)  += vf_scale_qsv.o
>  OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o 
> vaapi_vpp.o
> -OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale.o
> +OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o
>  OBJS-$(CONFIG_SCROLL_FILTER) += vf_scroll.o
>  OBJS-$(CONFIG_SELECT_FILTER) += f_select.o
>  OBJS-$(CONFIG_SELECTIVECOLOR_FILTER) += vf_selectivecolor.o
> diff --git a/libavfilter/scale.c b/libavfilter/scale.c
> index eaee95fac6..668aa04622 100644
> --- a/libavfilter/scale.c
> +++ b/libavfilter/scale.c
> @@ -60,49 +60,6 @@ enum var_name {
>  VARS_NB
>  };
>  
> -/**
> - * This must be kept in sync with var_names so that it is always a
> - * complete list of var_names with the scale2ref specific names
> - * appended. scale2ref values must appear in the order they appear
> - * in the var_name_scale2ref enum but also be below all of the
> - * non-scale2ref specific values.
> - */
> -static const char *const var_names_scale2ref[] = {
> -"PI",
> -"PHI",
> -"E",
> -"in_w",   "iw",
> -"in_h",   "ih",
> -"out_w",  "ow",
> -"out_h",  "oh",
> -"a",
> -"sar",
> -"dar",
> -"hsub",
> -"vsub",
> -"ohsub",
> -"ovsub",
> -"main_w",
> -"main_h",
> -"main_a",
> -"main_sar",
> -"main_dar", "mdar",
> -"main_hsub",
> -"main_vsub",
> -NULL
> -};
> -
> -enum var_name_scale2ref {
> -VAR_S2R_MAIN_W,
> -VAR_S2R_MAIN_H,
> -VAR_S2R_MAIN_A,
> -VAR_S2R_MAIN_SAR,
> -VAR_S2R_MAIN_DAR, VAR_S2R_MDAR,
> -VAR_S2R_MAIN_HSUB,
> -VAR_S2R_MAIN_VSUB,
> -VARS_S2R_NB
> -};
> -
>  int ff_scale_eval_dimensions(void *log_ctx,
>  const char *w_expr, const char *h_expr,
>  AVFilterLink *inlink, AVFilterLink *outlink,
> @@ -115,16 +72,7 @@ int ff_scale_eval_dimensions(void *log_ctx,
>  int factor_w, factor_h;
>  int eval_w, eval_h;
>  int ret;
> -const char scale2ref = outlink->src->nb_inputs == 2 && 
> outlink->src->inputs[1] == inlink;
> -double var_values[VARS_NB + VARS_S2R_NB], res;
> -const AVPixFmtDescriptor *main_desc;
> -const AVFilterLink *main_link;
> -const char *const *names = scale2ref ? var_names_scale2ref : var_names;
> -
> -if (scale2ref) {
> -main_link = outlink->src->inputs[0];
> -main_desc = av_pix_fmt_desc_get(main_link->format);
> -}
> +double var_values[VARS_NB], res;
>  
>  var_values[VAR_PI]= M_PI;
>  var_values[VAR_PHI]   = M_PHI;
> @@ -142,32 +90,20 @@ int ff_scale_eval_dimensions(void *log_ctx,
>  var_values[VAR_OHSUB] = 1 << out_desc->log2_chroma_w;
>  var_values[VAR_OVSUB] = 1 << out_desc->log2_chroma_h;
>  
> -if (scale2ref) {
> -var_values[VARS_NB + VAR_S2R_MAIN_W] = 

[FFmpeg-devel] [PATCH] avformat/mpegtsenc: do not write SDT for m2ts

2019-11-14 Thread Marton Balint
BDMV does not seem to use it.

Signed-off-by: Marton Balint 
---
 doc/muxers.texi | 3 ++-
 libavformat/mpegtsenc.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 4e76b40151..aa4bde518d 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1633,7 +1633,8 @@ is less than 100 ms is used for VBR streams.
 Maximum time in seconds between PAT/PMT tables. Default is @code{0.1}.
 
 @item sdt_period @var{duration}
-Maximum time in seconds between SDT tables. Default is @code{0.5}.
+Maximum time in seconds between SDT tables. Default is @code{0.5}. Regardless
+of this setting no SDT is written in m2ts mode.
 
 @item tables_version @var{integer}
 Set PAT, PMT and SDT version (default @code{0}, valid values are from 0 to 31, 
inclusively).
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index f37aa31915..a10a3e2450 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -1074,7 +1074,8 @@ static void retransmit_si_info(AVFormatContext *s, int 
force_pat, int force_sdt,
 ) {
 if (pcr != AV_NOPTS_VALUE)
 ts->last_sdt_ts = FFMAX(pcr, ts->last_sdt_ts);
-mpegts_write_sdt(s);
+if (!ts->m2ts_mode)
+mpegts_write_sdt(s);
 }
 if ((pcr != AV_NOPTS_VALUE && ts->last_pat_ts == AV_NOPTS_VALUE) ||
 (pcr != AV_NOPTS_VALUE && pcr - ts->last_pat_ts >= ts->pat_period) ||
-- 
2.16.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 4/4] swscale/swscale_unscaled: add AV_PIX_FMT_GBRAP10 for LE and BE conversion wrapper

2019-11-14 Thread Michael Niedermayer
On Thu, Nov 14, 2019 at 09:46:23PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang 
> 
> Signed-off-by: Limin Wang 
> ---
>  libswscale/swscale_unscaled.c | 2 ++
>  1 file changed, 2 insertions(+)

probably ok

thx

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 3/4] FATE: add a test for lut1d and lut3d

2019-11-14 Thread Michael Niedermayer
On Thu, Nov 14, 2019 at 09:46:22PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang 
> 
> Signed-off-by: Limin Wang 
> ---
> have tested with x86_64(apple darwin, linux gcc), x86_32(linux), mips

tested on mingw32/64, qemu arm/mips 

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avdevice/decklink: add option to drop frames till timecode is seen

2019-11-14 Thread Marton Balint



On Wed, 13 Nov 2019, Gyan wrote:

As suggested in the review of an earlier patch*, this one drops frames till a 
TC is seen.





From 0932db9d14dea215c1b0e5dcac4eac16cd6a Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Mon, 9 Sep 2019 18:33:09 +0530
Subject: [PATCH] avdevice/decklink: add option to drop frames till timecode is
 seen

Option wait_for_tc only takes effect if tc_format is set
---
 libavdevice/decklink_common.h   |  1 +
 libavdevice/decklink_common_c.h |  1 +
 libavdevice/decklink_dec.cpp| 12 
 libavdevice/decklink_dec_c.c|  1 +
 4 files changed, 15 insertions(+)


Docs update is missing for the new option as well as micro version bump.



diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 921818ba41..35422a300b 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -149,6 +149,7 @@ struct decklink_ctx {

 int channels;
 int audio_depth;
+unsigned long tc_seen;// used with option wait_for_tc
 };

 typedef enum { DIRECTION_IN, DIRECTION_OUT} decklink_direction_t;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index ca85ec2504..b78630b5fc 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -58,6 +58,7 @@ struct decklink_cctx {
 int copyts;
 int64_t timestamp_align;
 int timing_offset;
+int wait_for_tc;
 };

 #endif /* AVDEVICE_DECKLINK_COMMON_C_H */
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 4da9122bff..69be37ed64 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -784,6 +784,8 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
 if (packed_metadata) {
 if (av_packet_add_side_data(, 
AV_PKT_DATA_STRINGS_METADATA, packed_metadata, metadata_len) < 0)
 av_freep(_metadata);
+else if (!ctx->tc_seen)
+ctx->tc_seen = ctx->frameCount;
 }
 }
 }
@@ -793,6 +795,14 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
 }
 }

+if (ctx->tc_format && cctx->wait_for_tc && !ctx->tc_seen) {
+
+av_log(avctx, AV_LOG_WARNING, "No TC detected yet. wait_for_tc set. 
Dropping. \n");
+av_log(avctx, AV_LOG_WARNING, "Frame received (#%lu) - "
+"- Frames dropped %u\n", ctx->frameCount, 
++ctx->dropped);
+return S_OK;
+}
+
 pkt.pts = get_pkt_pts(videoFrame, audioFrame, wallclock, abs_wallclock, 
ctx->video_pts_source, ctx->video_st->time_base, _video_pts, 
cctx->copyts);
 pkt.dts = pkt.pts;

@@ -880,6 +890,8 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
 videoFrame->AddRef();

 if (avpacket_queue_put(>queue, ) < 0) {
+if (ctx->tc_seen == ctx->frameCount)
+ctx->tc_seen = 0;


I don't think this is needed, this can only happen in an ENOMEM case. Keep 
it if you feel strongly about it, but it looks a rather useless corner 
case to me.


LGTM if docs is added.

Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v1 2/2] configure: Fix for the configure failed for vmaf

2019-11-14 Thread Kyle Swanson
Hi,

On Wed, Nov 13, 2019 at 10:36 PM Limin Wang  wrote:
> Please ignore the patch, I haven't used the old version. As vmaf library use
> libvmaf.pc, it better to keep it filename same, so let waiting vmaf to fix
> it.

Merged your PR over on the VMAF repo. This FFmpeg patch should be ignored.

Thanks,
Kyle
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avdevice/decklink: add option to drop frames till timecode is seen

2019-11-14 Thread Marton Balint



On Wed, 13 Nov 2019, Ilinca Tudose wrote:


My previous email was incorrect about "-wait_for_tc 1". The 2 commands used
were:

(1)
ffmpeg -loglevel trace  -timecode_format rp188any  -wait_for_tc 1 -f
decklink -probesize 15M -analyzeduration 5M -i "DeckLink Quad (1)" -t 30
-preset veryfast output.mov

(2)
ffmpeg -loglevel trace  -timecode_format rp188any  -wait_for_tc 1 -f
decklink -i "DeckLink Quad (1)" -t 30 -preset veryfast output.mov

The second command is the one that produced 1 frame offset in 3 of the
captures. The first command had 0 frames offset for all files tried.


These two command lines are only different in probesize and
analyzeduration. I don't understand how these two options can make any
difference regarding the TC offset. Can you figure out which one actually 
causes the issue?


Thanks,
Marton




On Wed, Nov 13, 2019 at 6:30 PM Ilinca Tudose  wrote:


Hi,

We tested this with several types of tapes. The results are as follows:

Out of 58 captures on Betacam tapes 55 had 0 frame offset and 3 had an
offset of 1 frame. All 3 were captured using the flag "-wait_for_tc 1".
Out of the 58 captures roughly half were captured with and half without 
"-wait_for_tc
1".

Out of 26 HDCAM captures (50/50 with/without "-wait_for_tc 1") all 26 had
0 TC offset.

Let me know if there's any questions re testing. The testing setup is the
same as previously mentioned.

Thanks,
ilinca

On Wed, Nov 13, 2019 at 5:40 PM Gyan  wrote:


As suggested in the review of an earlier patch*, this one drops frames
till a TC is seen.

Testing results to follow.

Thanks,
Gyan

*https://patchwork.ffmpeg.org/patch/14081/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".







--

---
Ilinca Tudose | Technical Solutions Consultant, Digitization Operations |
go/digitops 
Google Germany GmbH
Erika-Mann-Str. 33
80636 München

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Diese E-Mail ist
vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese
bitte nicht weiter, informieren Sie den Absender und löschen Sie die E-Mail
und alle Anhänge. Vielen Dank. This e-mail is confidential. If you are not
the right addressee please do not forward it, please inform the sender, and
please erase this e-mail including any attachments. Thanks. Der Inhalt
dieser E-Mail spiegelt den derzeitigen Stand der Verhandlungen wider und
dient als Basis für weitere Gespräche. Er soll keine rechtlich verbindliche
Verpflichtung begründen. Eine solche Verpflichtung wird allein durch einen
zwischen allen beteiligten Parteien abgeschlossenen, schriftlichen Vertrag
geschaffen. The above terms reflect a potential business arrangement, are
provided solely as a basis for further discussion, and are not intended to
be and do not constitute a legally binding obligation. No legally binding
obligations will be created, implied, or inferred until an agreement in
final form is executed in writing by all parties involved.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Question re: CVE-2019-15942 and ffmpeg 3.4.6

2019-11-14 Thread Andreas Rheinhardt
On Thu, Nov 14, 2019 at 9:31 PM James Boyle  wrote:

> Hello,
>
> I was wondering if anyone can verify whether or not CVE-2019-15942
> affects ffmpeg version 3.4.6.  From trac ticket 8093
> (https://trac.ffmpeg.org/ticket/8093), it looks like it was a
> "regression since 992532ee3122d7938a7581988eea401b57de8189".  I'm not
> well versed with git, but running "git branch -r --contains
> 992532ee3122d7938a7581988eea401b57de8189" seems to suggest that that
> commit is only included in "origin/HEAD -> origin/master",
> "origin/master", and "origin/release/4.2".  Additionally, the commit
> that fixes the issue (af70bfbeadc0c9b9215cf045ff2a6a31e8ac3a71) seems to
> include a pointer for a struct defined in current ffmpeg that is nowhere
> to be found in ffmpeg 3.4.6 [static void alloc_rbsp_buffer(H2645RBSP
> *rbsp, unsigned int size, int use_ref)].
>
> I'm hopeful that all of this information adds up to CVE-2019-15942 not
> affecting ffmpeg 3.4.6, but would be grateful if someone familiar with
> the code would verify.
>
> Thanks much!
> --James
>

You are right: It was not even in 4.1. Or in any of the earlier releases.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] Question re: CVE-2019-15942 and ffmpeg 3.4.6

2019-11-14 Thread James Boyle
Hello,

I was wondering if anyone can verify whether or not CVE-2019-15942
affects ffmpeg version 3.4.6.  From trac ticket 8093
(https://trac.ffmpeg.org/ticket/8093), it looks like it was a
"regression since 992532ee3122d7938a7581988eea401b57de8189".  I'm not
well versed with git, but running "git branch -r --contains
992532ee3122d7938a7581988eea401b57de8189" seems to suggest that that
commit is only included in "origin/HEAD -> origin/master",
"origin/master", and "origin/release/4.2".  Additionally, the commit
that fixes the issue (af70bfbeadc0c9b9215cf045ff2a6a31e8ac3a71) seems to
include a pointer for a struct defined in current ffmpeg that is nowhere
to be found in ffmpeg 3.4.6 [static void alloc_rbsp_buffer(H2645RBSP
*rbsp, unsigned int size, int use_ref)].

I'm hopeful that all of this information adds up to CVE-2019-15942 not
affecting ffmpeg 3.4.6, but would be grateful if someone familiar with
the code would verify.

Thanks much!
--James





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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/cbs_vp9: Write frame data directly

2019-11-14 Thread Andreas Rheinhardt
Writing a unit (always a frame) in cbs_vp9 used an intermediate buffer
to write the frame header followed by the frame data that was copied
into said buffer. Afterwards, the final buffer for the frame was
allocated and everything copied into this buffer. But it is trivial to
compute the needed size of the final buffer after having written the
header, so one can allocate the final buffer immediately and copy the
frame data directly into it.

Also, given that the intermediate buffer now only needs to keep the
header, its size can be drastically reduced.

Signed-off-by: Andreas Rheinhardt 
---
I think that 1KB is still quite generous for the header; one could
probably even come up with a drastically lower bound upon reading the
spec (one could probably put the intermediate buffer on the stack and
remove the reallocation stuff).

Similar improvements can be done for the other cbs_*. vp9 is first
because it seems to be the easiest.

 libavcodec/cbs_vp9.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/libavcodec/cbs_vp9.c b/libavcodec/cbs_vp9.c
index bd172100fc..ebb4c573ea 100644
--- a/libavcodec/cbs_vp9.c
+++ b/libavcodec/cbs_vp9.c
@@ -526,12 +526,13 @@ static int cbs_vp9_write_unit(CodedBitstreamContext *ctx,
 {
 CodedBitstreamVP9Context *priv = ctx->priv_data;
 VP9RawFrame *frame = unit->content;
+size_t header_size, data_size;
 PutBitContext pbc;
 int err;
 
 if (!priv->write_buffer) {
-// Initial write buffer size is 1MB.
-priv->write_buffer_size = 1024 * 1024;
+// Initial write buffer size is 1KB.
+priv->write_buffer_size = 1024;
 
 reallocate_and_try_again:
 err = av_reallocp(>write_buffer, priv->write_buffer_size);
@@ -556,27 +557,26 @@ static int cbs_vp9_write_unit(CodedBitstreamContext *ctx,
 // Frame must be byte-aligned.
 av_assert0(put_bits_count() % 8 == 0);
 
-unit->data_size= put_bits_count() / 8;
+data_size = header_size = put_bits_count() / 8;
 unit->data_bit_padding = 0;
 flush_put_bits();
 
 if (frame->data) {
-if (unit->data_size + frame->data_size >
-priv->write_buffer_size) {
-priv->write_buffer_size *= 2;
-goto reallocate_and_try_again;
-}
+if (frame->data_size > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE
+   - header_size)
+return AVERROR(ENOMEM);
 
-memcpy(priv->write_buffer + unit->data_size,
-   frame->data, frame->data_size);
-unit->data_size += frame->data_size;
+data_size += frame->data_size;
 }
 
-err = ff_cbs_alloc_unit_data(ctx, unit, unit->data_size);
+err = ff_cbs_alloc_unit_data(ctx, unit, data_size);
 if (err < 0)
 return err;
 
-memcpy(unit->data, priv->write_buffer, unit->data_size);
+memcpy(unit->data, priv->write_buffer, header_size);
+
+if (frame->data)
+memcpy(unit->data + header_size, frame->data, frame->data_size);
 
 return 0;
 }
-- 
2.20.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] [libdav1d.c]: Add option to output all the spatial layers.

2019-11-14 Thread Thierry Foucu
On Thu, Nov 14, 2019 at 11:33 AM Ronald S. Bultje 
wrote:

> Hi,
>
> On Thu, Nov 14, 2019 at 2:12 PM Andrey Semashev  >
> wrote:
>
> > I think there needs to be some consistency across different lavc
> > decoders. If we consider that lavc should produce one decoded frame per
> > one encoded one, even if the encoded one contains multiple layers, then
> > that should be true for all decoders.
> >
>
> Yes. I think one thing that would help is if we had access to more samples
> with an expected behaviour. Right now we may have samples, but if all we do
> is check md5 without caring what it means, then it's kind of pointless.
>
>
> > Also, I think having decoded frames from all layers would also be
> > useful, but there should be a way to know which layer they belong to.
> > AFAIK, lavc currently doesn't provide that information. This mode of
> > operation (producing frames for all layers) should be optional.
>
>
> I agree.
>

I think this is what my second patch is doing.
Set by default to false to output all the layer and add an option to select
which operating point we want the decoder to output.


>
> Ronald
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/2] backport NULL pointer dereference fix / CVE-2019-17539 / 15733 clusterfuzz

2019-11-14 Thread James Boyle
Hello,

This patch is nearly identical to commit
8df6884832ec413cf032dfaa45c23b1c7876670c, but is intended to backport
the fix for CVE-2019-17539 to ffmpeg version 3.4.6, which is in use on
RHEL 7 systems that get ffmpeg from rpmfusion.

https://github.com/FFmpeg/FFmpeg/commit/8df6884832ec413cf032dfaa45c23b1c7876670c

---
 libavcodec/utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index ec03bdc..18b66d4 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1112,7 +1112,7 @@ end:

 return ret;
 free_and_end:
-if (avctx->codec &&
+if (avctx->codec && avctx->codec->close &&
 (avctx->codec->caps_internal & FF_CODEC_CAP_INIT_CLEANUP))
 avctx->codec->close(avctx);

-- 
2.21.0


Thanks,
--James
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/2] backport out of array access fix / CVE-2019-17542 / 15919 clusterfuzz

2019-11-14 Thread James Boyle
Hello,

This patch is nearly identical to commit
02f909dc24b1f05cfbba75077c7707b905e63cd2, but is intended to backport
the fix for CVE-2019-17542 to ffmpeg version 3.4.6, which is in use on
RHEL 7 systems that get ffmpeg from rpmfusion.

https://github.com/FFmpeg/FFmpeg/commit/02f909dc24b1f05cfbba75077c7707b905e63cd2

---
 libavcodec/vqavideo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/vqavideo.c b/libavcodec/vqavideo.c
index 0e70be1..b9743ab 100644
--- a/libavcodec/vqavideo.c
+++ b/libavcodec/vqavideo.c
@@ -147,7 +147,7 @@ static av_cold int vqa_decode_init(AVCodecContext
*avctx)
 }
 s->width = AV_RL16(>avctx->extradata[6]);
 s->height = AV_RL16(>avctx->extradata[8]);
-if ((ret = av_image_check_size(s->width, s->height, 0, avctx)) < 0) {
+if ((ret = ff_set_dimensions(avctx, s->width, s->height)) < 0) {
 s->width= s->height= 0;
 return ret;
 }
-- 
2.21.0


Thanks,
--James
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] [libdav1d.c]: Add option to output all the spatial layers.

2019-11-14 Thread Ronald S. Bultje
Hi,

On Thu, Nov 14, 2019 at 2:12 PM Andrey Semashev 
wrote:

> I think there needs to be some consistency across different lavc
> decoders. If we consider that lavc should produce one decoded frame per
> one encoded one, even if the encoded one contains multiple layers, then
> that should be true for all decoders.
>

Yes. I think one thing that would help is if we had access to more samples
with an expected behaviour. Right now we may have samples, but if all we do
is check md5 without caring what it means, then it's kind of pointless.


> Also, I think having decoded frames from all layers would also be
> useful, but there should be a way to know which layer they belong to.
> AFAIK, lavc currently doesn't provide that information. This mode of
> operation (producing frames for all layers) should be optional.


I agree.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] [libdav1d.c]: Add option to output all the spatial layers.

2019-11-14 Thread Andrey Semashev

On 2019-11-14 20:48, James Almer wrote:

On 11/14/2019 2:31 PM, Andrey Semashev wrote:

On 2019-11-14 20:19, James Almer wrote:

On 11/14/2019 2:15 PM, Thierry Foucu wrote:

Set the option to false by default, to match libaomdec wrapper.
---
   libavcodec/libdav1d.c | 4 
   1 file changed, 4 insertions(+)

diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index cf4b178f1d..5efa8eeb48 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -40,6 +40,7 @@ typedef struct Libdav1dContext {
   int tile_threads;
   int frame_threads;
   int apply_grain;
+    int all_layers;
   } Libdav1dContext;
     static const enum AVPixelFormat pix_fmt[][3] = {
@@ -134,6 +135,8 @@ static av_cold int libdav1d_init(AVCodecContext *c)
   if (dav1d->apply_grain >= 0)
   s.apply_grain = dav1d->apply_grain;
   +    s.all_layers = dav1d->all_layers;
+
   s.n_tile_threads = dav1d->tile_threads
    ? dav1d->tile_threads
    : FFMIN(floor(sqrt(threads)),
DAV1D_MAX_TILE_THREADS);
@@ -378,6 +381,7 @@ static const AVOption libdav1d_options[] = {
   { "tilethreads", "Tile threads", OFFSET(tile_threads),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, DAV1D_MAX_TILE_THREADS, VD },
   { "framethreads", "Frame threads", OFFSET(frame_threads),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, DAV1D_MAX_FRAME_THREADS, VD },
   { "filmgrain", "Apply Film Grain", OFFSET(apply_grain),
AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1, VD },
+    { "alllayers", "Output all spatial layers", OFFSET(all_layers),
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
   { NULL }
   };


IMO, we don't want to output all layers under any circumstance. It'll
result in a mix of frames with duplicate pts and different dimensions.


IIRC, for VP9 with spatial SVC lavc decoder worked exactly like that -
by returning a frame per spatial layer. Is this considered a bug?


I don't know if it's a bug, and never seen or tested vp9 svc samples
before. Ronald might know. But it sounds like having more than one video
"stream" per AVCodecContext, which i don't think was intended.


There is one stream, in which an encoded frame is a VP9 superframe that 
contains frames for each spatial layer. From the user's perspective, VP9 
superframe is one entity.



And if it was, then it would be up to the library user to figure what to
do with these frames.


I think there needs to be some consistency across different lavc 
decoders. If we consider that lavc should produce one decoded frame per 
one encoded one, even if the encoded one contains multiple layers, then 
that should be true for all decoders.


Also, I think having decoded frames from all layers would also be 
useful, but there should be a way to know which layer they belong to. 
AFAIK, lavc currently doesn't provide that information. This mode of 
operation (producing frames for all layers) should be optional.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] [libdav1d.c]: Add option to output all the spatial layers.

2019-11-14 Thread James Almer
On 11/14/2019 2:31 PM, Andrey Semashev wrote:
> On 2019-11-14 20:19, James Almer wrote:
>> On 11/14/2019 2:15 PM, Thierry Foucu wrote:
>>> Set the option to false by default, to match libaomdec wrapper.
>>> ---
>>>   libavcodec/libdav1d.c | 4 
>>>   1 file changed, 4 insertions(+)
>>>
>>> diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
>>> index cf4b178f1d..5efa8eeb48 100644
>>> --- a/libavcodec/libdav1d.c
>>> +++ b/libavcodec/libdav1d.c
>>> @@ -40,6 +40,7 @@ typedef struct Libdav1dContext {
>>>   int tile_threads;
>>>   int frame_threads;
>>>   int apply_grain;
>>> +    int all_layers;
>>>   } Libdav1dContext;
>>>     static const enum AVPixelFormat pix_fmt[][3] = {
>>> @@ -134,6 +135,8 @@ static av_cold int libdav1d_init(AVCodecContext *c)
>>>   if (dav1d->apply_grain >= 0)
>>>   s.apply_grain = dav1d->apply_grain;
>>>   +    s.all_layers = dav1d->all_layers;
>>> +
>>>   s.n_tile_threads = dav1d->tile_threads
>>>    ? dav1d->tile_threads
>>>    : FFMIN(floor(sqrt(threads)),
>>> DAV1D_MAX_TILE_THREADS);
>>> @@ -378,6 +381,7 @@ static const AVOption libdav1d_options[] = {
>>>   { "tilethreads", "Tile threads", OFFSET(tile_threads),
>>> AV_OPT_TYPE_INT, { .i64 = 0 }, 0, DAV1D_MAX_TILE_THREADS, VD },
>>>   { "framethreads", "Frame threads", OFFSET(frame_threads),
>>> AV_OPT_TYPE_INT, { .i64 = 0 }, 0, DAV1D_MAX_FRAME_THREADS, VD },
>>>   { "filmgrain", "Apply Film Grain", OFFSET(apply_grain),
>>> AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1, VD },
>>> +    { "alllayers", "Output all spatial layers", OFFSET(all_layers),
>>> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
>>>   { NULL }
>>>   };
>>
>> IMO, we don't want to output all layers under any circumstance. It'll
>> result in a mix of frames with duplicate pts and different dimensions.
> 
> IIRC, for VP9 with spatial SVC lavc decoder worked exactly like that -
> by returning a frame per spatial layer. Is this considered a bug?

I don't know if it's a bug, and never seen or tested vp9 svc samples
before. Ronald might know. But it sounds like having more than one video
"stream" per AVCodecContext, which i don't think was intended.
And if it was, then it would be up to the library user to figure what to
do with these frames.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/scale: allow dynamic output via expressions

2019-11-14 Thread Gyan



On 14-11-2019 01:12 am, Michael Niedermayer wrote:

Moving and changing code at the same time makes it hard to see th difference.
Idealy all code moves should be seperate from changes to the code.

also more generally, spliting this patch up would simpify review


Split into two. First patch mostly moves code and keeps existing 
functionality. 2nd patch introduces new features and requires the new 
eval function.


Thanks,
Gyan
From 359f538703865c8ebeda16b5d1846d2cf1cf9c4d Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Thu, 14 Nov 2019 21:08:32 +0530
Subject: [PATCH v2 1/2] avfilter/scale: shift ff_scale_eval_dimensions inline

This is a perfunctory change in preparation of adding
direct animation support to scale and scale2ref filters
---
 libavfilter/Makefile   |   4 +-
 libavfilter/scale.c|  72 +---
 libavfilter/vf_scale.c | 192 -
 3 files changed, 196 insertions(+), 72 deletions(-)

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fce930360d..f1f6994574 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -358,12 +358,12 @@ OBJS-$(CONFIG_ROBERTS_OPENCL_FILTER) += 
vf_convolution_opencl.o opencl.o
 opencl/convolution.o
 OBJS-$(CONFIG_ROTATE_FILTER) += vf_rotate.o
 OBJS-$(CONFIG_SAB_FILTER)+= vf_sab.o
-OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o scale.o
+OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o
 OBJS-$(CONFIG_SCALE_CUDA_FILTER) += vf_scale_cuda.o 
vf_scale_cuda.ptx.o
 OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
 OBJS-$(CONFIG_SCALE_QSV_FILTER)  += vf_scale_qsv.o
 OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o 
vaapi_vpp.o
-OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale.o
+OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o
 OBJS-$(CONFIG_SCROLL_FILTER) += vf_scroll.o
 OBJS-$(CONFIG_SELECT_FILTER) += f_select.o
 OBJS-$(CONFIG_SELECTIVECOLOR_FILTER) += vf_selectivecolor.o
diff --git a/libavfilter/scale.c b/libavfilter/scale.c
index eaee95fac6..668aa04622 100644
--- a/libavfilter/scale.c
+++ b/libavfilter/scale.c
@@ -60,49 +60,6 @@ enum var_name {
 VARS_NB
 };
 
-/**
- * This must be kept in sync with var_names so that it is always a
- * complete list of var_names with the scale2ref specific names
- * appended. scale2ref values must appear in the order they appear
- * in the var_name_scale2ref enum but also be below all of the
- * non-scale2ref specific values.
- */
-static const char *const var_names_scale2ref[] = {
-"PI",
-"PHI",
-"E",
-"in_w",   "iw",
-"in_h",   "ih",
-"out_w",  "ow",
-"out_h",  "oh",
-"a",
-"sar",
-"dar",
-"hsub",
-"vsub",
-"ohsub",
-"ovsub",
-"main_w",
-"main_h",
-"main_a",
-"main_sar",
-"main_dar", "mdar",
-"main_hsub",
-"main_vsub",
-NULL
-};
-
-enum var_name_scale2ref {
-VAR_S2R_MAIN_W,
-VAR_S2R_MAIN_H,
-VAR_S2R_MAIN_A,
-VAR_S2R_MAIN_SAR,
-VAR_S2R_MAIN_DAR, VAR_S2R_MDAR,
-VAR_S2R_MAIN_HSUB,
-VAR_S2R_MAIN_VSUB,
-VARS_S2R_NB
-};
-
 int ff_scale_eval_dimensions(void *log_ctx,
 const char *w_expr, const char *h_expr,
 AVFilterLink *inlink, AVFilterLink *outlink,
@@ -115,16 +72,7 @@ int ff_scale_eval_dimensions(void *log_ctx,
 int factor_w, factor_h;
 int eval_w, eval_h;
 int ret;
-const char scale2ref = outlink->src->nb_inputs == 2 && 
outlink->src->inputs[1] == inlink;
-double var_values[VARS_NB + VARS_S2R_NB], res;
-const AVPixFmtDescriptor *main_desc;
-const AVFilterLink *main_link;
-const char *const *names = scale2ref ? var_names_scale2ref : var_names;
-
-if (scale2ref) {
-main_link = outlink->src->inputs[0];
-main_desc = av_pix_fmt_desc_get(main_link->format);
-}
+double var_values[VARS_NB], res;
 
 var_values[VAR_PI]= M_PI;
 var_values[VAR_PHI]   = M_PHI;
@@ -142,32 +90,20 @@ int ff_scale_eval_dimensions(void *log_ctx,
 var_values[VAR_OHSUB] = 1 << out_desc->log2_chroma_w;
 var_values[VAR_OVSUB] = 1 << out_desc->log2_chroma_h;
 
-if (scale2ref) {
-var_values[VARS_NB + VAR_S2R_MAIN_W] = main_link->w;
-var_values[VARS_NB + VAR_S2R_MAIN_H] = main_link->h;
-var_values[VARS_NB + VAR_S2R_MAIN_A] = (double) main_link->w / 
main_link->h;
-var_values[VARS_NB + VAR_S2R_MAIN_SAR] = 
main_link->sample_aspect_ratio.num ?
-(double) main_link->sample_aspect_ratio.num / 
main_link->sample_aspect_ratio.den : 1;
-var_values[VARS_NB + VAR_S2R_MAIN_DAR] = var_values[VARS_NB + 
VAR_S2R_MDAR] =
-var_values[VARS_NB + VAR_S2R_MAIN_A] * var_values[VARS_NB + 
VAR_S2R_MAIN_SAR];
-var_values[VARS_NB + VAR_S2R_MAIN_HSUB] = 1 << 
main_desc->log2_chroma_w;
-

Re: [FFmpeg-devel] [PATCH] [libdav1d.c]: Add option to output all the spatial layers.

2019-11-14 Thread Andrey Semashev

On 2019-11-14 20:19, James Almer wrote:

On 11/14/2019 2:15 PM, Thierry Foucu wrote:

Set the option to false by default, to match libaomdec wrapper.
---
  libavcodec/libdav1d.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index cf4b178f1d..5efa8eeb48 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -40,6 +40,7 @@ typedef struct Libdav1dContext {
  int tile_threads;
  int frame_threads;
  int apply_grain;
+int all_layers;
  } Libdav1dContext;
  
  static const enum AVPixelFormat pix_fmt[][3] = {

@@ -134,6 +135,8 @@ static av_cold int libdav1d_init(AVCodecContext *c)
  if (dav1d->apply_grain >= 0)
  s.apply_grain = dav1d->apply_grain;
  
+s.all_layers = dav1d->all_layers;

+
  s.n_tile_threads = dav1d->tile_threads
   ? dav1d->tile_threads
   : FFMIN(floor(sqrt(threads)), DAV1D_MAX_TILE_THREADS);
@@ -378,6 +381,7 @@ static const AVOption libdav1d_options[] = {
  { "tilethreads", "Tile threads", OFFSET(tile_threads), AV_OPT_TYPE_INT, { 
.i64 = 0 }, 0, DAV1D_MAX_TILE_THREADS, VD },
  { "framethreads", "Frame threads", OFFSET(frame_threads), 
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, DAV1D_MAX_FRAME_THREADS, VD },
  { "filmgrain", "Apply Film Grain", OFFSET(apply_grain), AV_OPT_TYPE_BOOL, 
{ .i64 = -1 }, -1, 1, VD },
+{ "alllayers", "Output all spatial layers", OFFSET(all_layers), 
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
  { NULL }
  };


IMO, we don't want to output all layers under any circumstance. It'll
result in a mix of frames with duplicate pts and different dimensions.


IIRC, for VP9 with spatial SVC lavc decoder worked exactly like that - 
by returning a frame per spatial layer. Is this considered a bug?

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] [libdav1d.c]: Add options for spatial layers.

2019-11-14 Thread Thierry Foucu
Disable by default to output all the layers, to match libaomdec wrapper.
Add option to select the operating point for the spatial layers.
---
 libavcodec/libdav1d.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index cf4b178f1d..ea4ef641bf 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -40,6 +40,8 @@ typedef struct Libdav1dContext {
 int tile_threads;
 int frame_threads;
 int apply_grain;
+int operating_point;
+int all_layers;
 } Libdav1dContext;
 
 static const enum AVPixelFormat pix_fmt[][3] = {
@@ -134,6 +136,10 @@ static av_cold int libdav1d_init(AVCodecContext *c)
 if (dav1d->apply_grain >= 0)
 s.apply_grain = dav1d->apply_grain;
 
+s.all_layers = dav1d->all_layers;
+if (dav1d->operating_point >= 0)
+s.operating_point = dav1d->operating_point;
+
 s.n_tile_threads = dav1d->tile_threads
  ? dav1d->tile_threads
  : FFMIN(floor(sqrt(threads)), DAV1D_MAX_TILE_THREADS);
@@ -378,6 +384,8 @@ static const AVOption libdav1d_options[] = {
 { "tilethreads", "Tile threads", OFFSET(tile_threads), AV_OPT_TYPE_INT, { 
.i64 = 0 }, 0, DAV1D_MAX_TILE_THREADS, VD },
 { "framethreads", "Frame threads", OFFSET(frame_threads), AV_OPT_TYPE_INT, 
{ .i64 = 0 }, 0, DAV1D_MAX_FRAME_THREADS, VD },
 { "filmgrain", "Apply Film Grain", OFFSET(apply_grain), AV_OPT_TYPE_BOOL, 
{ .i64 = -1 }, -1, 1, VD },
+{ "oppoint",  "Select an operating point of the scalable bitstream", 
OFFSET(operating_point), AV_OPT_TYPE_INT, { .i64 = -1 }, 0, 31, VD },
+{ "alllayers", "Output all spatial layers", OFFSET(all_layers), 
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
 { NULL }
 };
 
-- 
2.24.0.432.g9d3f5f5b63-goog

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] [libdav1d.c]: Add option to output all the spatial layers.

2019-11-14 Thread Thierry Foucu
On Thu, Nov 14, 2019 at 9:20 AM James Almer  wrote:

> On 11/14/2019 2:15 PM, Thierry Foucu wrote:
> > Set the option to false by default, to match libaomdec wrapper.
> > ---
> >  libavcodec/libdav1d.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
> > index cf4b178f1d..5efa8eeb48 100644
> > --- a/libavcodec/libdav1d.c
> > +++ b/libavcodec/libdav1d.c
> > @@ -40,6 +40,7 @@ typedef struct Libdav1dContext {
> >  int tile_threads;
> >  int frame_threads;
> >  int apply_grain;
> > +int all_layers;
> >  } Libdav1dContext;
> >
> >  static const enum AVPixelFormat pix_fmt[][3] = {
> > @@ -134,6 +135,8 @@ static av_cold int libdav1d_init(AVCodecContext *c)
> >  if (dav1d->apply_grain >= 0)
> >  s.apply_grain = dav1d->apply_grain;
> >
> > +s.all_layers = dav1d->all_layers;
> > +
> >  s.n_tile_threads = dav1d->tile_threads
> >   ? dav1d->tile_threads
> >   : FFMIN(floor(sqrt(threads)),
> DAV1D_MAX_TILE_THREADS);
> > @@ -378,6 +381,7 @@ static const AVOption libdav1d_options[] = {
> >  { "tilethreads", "Tile threads", OFFSET(tile_threads),
> AV_OPT_TYPE_INT, { .i64 = 0 }, 0, DAV1D_MAX_TILE_THREADS, VD },
> >  { "framethreads", "Frame threads", OFFSET(frame_threads),
> AV_OPT_TYPE_INT, { .i64 = 0 }, 0, DAV1D_MAX_FRAME_THREADS, VD },
> >  { "filmgrain", "Apply Film Grain", OFFSET(apply_grain),
> AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1, VD },
> > +{ "alllayers", "Output all spatial layers", OFFSET(all_layers),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
> >  { NULL }
> >  };
>
> IMO, we don't want to output all layers under any circumstance. It'll
> result in a mix of frames with duplicate pts and different dimensions.
>
> What you could add is a new option "oppoint" that maps to Dav1dSettings
> operating_point. Set it to -1, and handle it the same way as filmgrain
> in libdav1d_init(), and then unconditionally set all_layers to 0.
>

I think to have an option to output all the layers is still a good idea if
you need to debug some layers issues.
especially  if you need to run some conformance testing and debug each
layer.

But i will add the other option to select the layer.


> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] libavcodec/amfenc_hevc.c: Fix Profile level option on AMF HEVC.

2019-11-14 Thread OvchinnikovDmitrii
Patch proposed by Sitan Liu 

---
 libavcodec/amfenc_hevc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/amfenc_hevc.c b/libavcodec/amfenc_hevc.c
index 7c9a33ab33..a9ccab168c 100644
--- a/libavcodec/amfenc_hevc.c
+++ b/libavcodec/amfenc_hevc.c
@@ -136,7 +136,7 @@ static av_cold int amf_encode_init_hevc(AVCodecContext 
*avctx)
 AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder, AMF_VIDEO_ENCODER_HEVC_TIER, 
ctx->tier);
 
 profile_level = avctx->level;
-if (profile_level == 0) {
+if (profile_level == FF_LEVEL_UNKNOWN) {
 profile_level = ctx->level;
 }
 if (profile_level != 0) {
@@ -144,7 +144,7 @@ static av_cold int amf_encode_init_hevc(AVCodecContext 
*avctx)
 }
 AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder, 
AMF_VIDEO_ENCODER_HEVC_QUALITY_PRESET, ctx->quality);
 // Maximum Reference Frames
-if (avctx->refs != 0) {
+if (avctx->refs != -1) {
 AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder, 
AMF_VIDEO_ENCODER_HEVC_MAX_NUM_REFRAMES, avctx->refs);
 }
 // Aspect Ratio
-- 
2.19.1.windows.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH V1] lavfi/superfastblur: add superfastblur filter

2019-11-14 Thread Michael Niedermayer
On Wed, Nov 13, 2019 at 12:24:34AM +0100, Paul B Mahol wrote:
> On 11/13/19, Michael Niedermayer  wrote:
> > On Tue, Nov 12, 2019 at 12:48:09PM +0100, Paul B Mahol wrote:
> >> If this filter is same speed or better than boxblur, it should replace
> >> boxblur filter, as boxblur filter is GPL.
> >
> > relicensing boxblur should not be hard if someone needs the code to be
> > under lgpl
> 
> I do not think so, look at geq, lots of devs no longer contactable,

who did you already contact about boxblur relicensing ?
i looked at the log and at the changes and i see noone i think wouldnt
reply whos change couldnt be rewritten in less than 5minutes
maybe someone could be on vacation and not check their email for a month ...

you know, just tell me who is the problem and which lines and ill either
contact them, rewrite the code or just revert their change

Thanks

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

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] [libdav1d.c]: Add option to output all the spatial layers.

2019-11-14 Thread James Almer
On 11/14/2019 2:15 PM, Thierry Foucu wrote:
> Set the option to false by default, to match libaomdec wrapper.
> ---
>  libavcodec/libdav1d.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
> index cf4b178f1d..5efa8eeb48 100644
> --- a/libavcodec/libdav1d.c
> +++ b/libavcodec/libdav1d.c
> @@ -40,6 +40,7 @@ typedef struct Libdav1dContext {
>  int tile_threads;
>  int frame_threads;
>  int apply_grain;
> +int all_layers;
>  } Libdav1dContext;
>  
>  static const enum AVPixelFormat pix_fmt[][3] = {
> @@ -134,6 +135,8 @@ static av_cold int libdav1d_init(AVCodecContext *c)
>  if (dav1d->apply_grain >= 0)
>  s.apply_grain = dav1d->apply_grain;
>  
> +s.all_layers = dav1d->all_layers;
> +
>  s.n_tile_threads = dav1d->tile_threads
>   ? dav1d->tile_threads
>   : FFMIN(floor(sqrt(threads)), DAV1D_MAX_TILE_THREADS);
> @@ -378,6 +381,7 @@ static const AVOption libdav1d_options[] = {
>  { "tilethreads", "Tile threads", OFFSET(tile_threads), AV_OPT_TYPE_INT, 
> { .i64 = 0 }, 0, DAV1D_MAX_TILE_THREADS, VD },
>  { "framethreads", "Frame threads", OFFSET(frame_threads), 
> AV_OPT_TYPE_INT, { .i64 = 0 }, 0, DAV1D_MAX_FRAME_THREADS, VD },
>  { "filmgrain", "Apply Film Grain", OFFSET(apply_grain), 
> AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1, VD },
> +{ "alllayers", "Output all spatial layers", OFFSET(all_layers), 
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
>  { NULL }
>  };

IMO, we don't want to output all layers under any circumstance. It'll
result in a mix of frames with duplicate pts and different dimensions.

What you could add is a new option "oppoint" that maps to Dav1dSettings
operating_point. Set it to -1, and handle it the same way as filmgrain
in libdav1d_init(), and then unconditionally set all_layers to 0.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] [libdav1d.c]: Add option to output all the spatial layers.

2019-11-14 Thread Thierry Foucu
Set the option to false by default, to match libaomdec wrapper.
---
 libavcodec/libdav1d.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index cf4b178f1d..5efa8eeb48 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -40,6 +40,7 @@ typedef struct Libdav1dContext {
 int tile_threads;
 int frame_threads;
 int apply_grain;
+int all_layers;
 } Libdav1dContext;
 
 static const enum AVPixelFormat pix_fmt[][3] = {
@@ -134,6 +135,8 @@ static av_cold int libdav1d_init(AVCodecContext *c)
 if (dav1d->apply_grain >= 0)
 s.apply_grain = dav1d->apply_grain;
 
+s.all_layers = dav1d->all_layers;
+
 s.n_tile_threads = dav1d->tile_threads
  ? dav1d->tile_threads
  : FFMIN(floor(sqrt(threads)), DAV1D_MAX_TILE_THREADS);
@@ -378,6 +381,7 @@ static const AVOption libdav1d_options[] = {
 { "tilethreads", "Tile threads", OFFSET(tile_threads), AV_OPT_TYPE_INT, { 
.i64 = 0 }, 0, DAV1D_MAX_TILE_THREADS, VD },
 { "framethreads", "Frame threads", OFFSET(frame_threads), AV_OPT_TYPE_INT, 
{ .i64 = 0 }, 0, DAV1D_MAX_FRAME_THREADS, VD },
 { "filmgrain", "Apply Film Grain", OFFSET(apply_grain), AV_OPT_TYPE_BOOL, 
{ .i64 = -1 }, -1, 1, VD },
+{ "alllayers", "Output all spatial layers", OFFSET(all_layers), 
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
 { NULL }
 };
 
-- 
2.24.0.432.g9d3f5f5b63-goog

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/5] vcodec/agm: Alloc based on coded dimensions

2019-11-14 Thread Paul B Mahol
LGTM

On 11/14/19, Michael Niedermayer  wrote:
> Fixes: out of array read
> Fixes:
> 18715/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5659333417500672
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/agm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/agm.c b/libavcodec/agm.c
> index 241e9eeb1b..628f324913 100644
> --- a/libavcodec/agm.c
> +++ b/libavcodec/agm.c
> @@ -827,7 +827,7 @@ static int decode_intra(AVCodecContext *avctx,
> GetBitContext *gb, AVFrame *frame
>  static int decode_motion_vectors(AVCodecContext *avctx, GetBitContext *gb)
>  {
>  AGMContext *s = avctx->priv_data;
> -int nb_mvs = ((avctx->height + 15) >> 4) * ((avctx->width + 15) >> 4);
> +int nb_mvs = ((avctx->coded_height + 15) >> 4) * ((avctx->coded_width +
> 15) >> 4);
>  int ret, skip = 0, value, map;
>
>  av_fast_padded_malloc(>mvectors, >mvectors_size,
> --
> 2.23.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH V1] lavfi/superfastblur: add superfastblur filter

2019-11-14 Thread Michael Niedermayer
On Wed, Nov 13, 2019 at 10:25:31AM +0800, Steven Liu wrote:
> 
> 
> > 在 2019年11月13日,09:02,myp...@gmail.com 写道:
> > 
> > On Wed, Nov 13, 2019 at 7:24 AM Paul B Mahol  wrote:
> >> 
> >> On 11/13/19, Michael Niedermayer  wrote:
> >>> On Tue, Nov 12, 2019 at 12:48:09PM +0100, Paul B Mahol wrote:
>  If this filter is same speed or better than boxblur, it should replace
>  boxblur filter, as boxblur filter is GPL.
> >>> 
> >>> relicensing boxblur should not be hard if someone needs the code to be
> >>> under lgpl
> >> 
> >> I do not think so, look at geq, lots of devs no longer contactable,
> >> 
> > Maybe we can keep both based on the license choice
> I think your suggestion is better :D

I think the best is to get boxblur relicensed to LGPL and then put any
improvments, if there are improvments into it.
Avoiding a 2nd filter which does the same thing and using the filter
name and syntax users already know

Thanks

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

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/5] vcodec/agm: Alloc based on coded dimensions

2019-11-14 Thread Michael Niedermayer
Fixes: out of array read
Fixes: 
18715/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5659333417500672

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/agm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/agm.c b/libavcodec/agm.c
index 241e9eeb1b..628f324913 100644
--- a/libavcodec/agm.c
+++ b/libavcodec/agm.c
@@ -827,7 +827,7 @@ static int decode_intra(AVCodecContext *avctx, 
GetBitContext *gb, AVFrame *frame
 static int decode_motion_vectors(AVCodecContext *avctx, GetBitContext *gb)
 {
 AGMContext *s = avctx->priv_data;
-int nb_mvs = ((avctx->height + 15) >> 4) * ((avctx->width + 15) >> 4);
+int nb_mvs = ((avctx->coded_height + 15) >> 4) * ((avctx->coded_width + 
15) >> 4);
 int ret, skip = 0, value, map;
 
 av_fast_padded_malloc(>mvectors, >mvectors_size,
-- 
2.23.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 4/5] avcodec/apedec: Fix 2 integer overflows

2019-11-14 Thread Michael Niedermayer
Fixes: signed integer overflow: 2119056926 - -134217728 cannot be represented 
in type 'int'
Fixes: 
18728/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5747539563511808

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/apedec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
index cfcf9a06c1..1df14fa946 100644
--- a/libavcodec/apedec.c
+++ b/libavcodec/apedec.c
@@ -1234,7 +1234,7 @@ static void predictor_decode_mono_3950(APEContext *ctx, 
int count)
 p->buf = p->historybuffer;
 }
 
-p->filterA[0] = currentA + ((int)(p->filterA[0] * 31U) >> 5);
+p->filterA[0] = currentA + (unsigned)((int)(p->filterA[0] * 31U) >> 5);
 *(decoded0++) = p->filterA[0];
 }
 
@@ -1302,7 +1302,7 @@ static void do_apply_filter(APEContext *ctx, int version, 
APEFilter *f,
 else
 *f->adaptcoeffs = 0;
 
-f->avg += (absres - f->avg) / 16;
+f->avg += (int)(absres - (unsigned)f->avg) / 16;
 
 f->adaptcoeffs[-1] >>= 1;
 f->adaptcoeffs[-2] >>= 1;
-- 
2.23.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 5/5] avcodec/truespeech: Fix an integer overflow in truespeech_synth()

2019-11-14 Thread Michael Niedermayer
Fixes: signed integer overflow: 2147483188 + 2048 cannot be represented in type 
'int'
Fixes: 
18741/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUESPEECH_fuzzer-5748950460268544

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/truespeech.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/truespeech.c b/libavcodec/truespeech.c
index d7c2d535e2..3cdae8c556 100644
--- a/libavcodec/truespeech.c
+++ b/libavcodec/truespeech.c
@@ -255,7 +255,7 @@ static void truespeech_synth(TSContext *dec, int16_t *out, 
int quart)
 int sum = 0;
 for(k = 0; k < 8; k++)
 sum += ptr0[k] * (unsigned)ptr1[k];
-sum = out[i] + ((sum + 0x800) >> 12);
+sum = out[i] + ((int)(sum + 0x800U) >> 12);
 out[i] = av_clip(sum, -0x7FFE, 0x7FFE);
 for(k = 7; k > 0; k--)
 ptr0[k] = ptr0[k - 1];
-- 
2.23.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/5] avcodec/wmalosslessdec: Set FF_CODEC_CAP_INIT_CLEANUP

2019-11-14 Thread Michael Niedermayer
Fixes: memleaks
Fixes: 
18429/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-6210814364614656
Fixes: 
18722/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-5680535690543104

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/wmalosslessdec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/wmalosslessdec.c b/libavcodec/wmalosslessdec.c
index d4f18b9841..7ed6ce3135 100644
--- a/libavcodec/wmalosslessdec.c
+++ b/libavcodec/wmalosslessdec.c
@@ -1327,6 +1327,7 @@ AVCodec ff_wmalossless_decoder = {
 .decode = decode_packet,
 .flush  = flush,
 .capabilities   = AV_CODEC_CAP_SUBFRAMES | AV_CODEC_CAP_DR1 | 
AV_CODEC_CAP_DELAY,
+.caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
 .sample_fmts= (const enum AVSampleFormat[]) { AV_SAMPLE_FMT_S16P,
   AV_SAMPLE_FMT_S32P,
   AV_SAMPLE_FMT_NONE },
-- 
2.23.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avdevice/decklink: add option to drop frames till timecode is seen

2019-11-14 Thread Ilinca Tudose
This also works when passing the -format_code parameter.

On Wed, Nov 13, 2019 at 7:04 PM Ilinca Tudose  wrote:

> My previous email was incorrect about "-wait_for_tc 1". The 2 commands
> used were:
>
> (1)
> ffmpeg -loglevel trace  -timecode_format rp188any  -wait_for_tc 1 -f
> decklink -probesize 15M -analyzeduration 5M -i "DeckLink Quad (1)" -t 30
> -preset veryfast output.mov
>
> (2)
> ffmpeg -loglevel trace  -timecode_format rp188any  -wait_for_tc 1 -f
> decklink -i "DeckLink Quad (1)" -t 30 -preset veryfast output.mov
>
> The second command is the one that produced 1 frame offset in 3 of the
> captures. The first command had 0 frames offset for all files tried.
>
> On Wed, Nov 13, 2019 at 6:30 PM Ilinca Tudose  wrote:
>
>> Hi,
>>
>> We tested this with several types of tapes. The results are as follows:
>>
>> Out of 58 captures on Betacam tapes 55 had 0 frame offset and 3 had an
>> offset of 1 frame. All 3 were captured using the flag "-wait_for_tc 1".
>> Out of the 58 captures roughly half were captured with and half without 
>> "-wait_for_tc
>> 1".
>>
>> Out of 26 HDCAM captures (50/50 with/without "-wait_for_tc 1") all 26
>> had 0 TC offset.
>>
>> Let me know if there's any questions re testing. The testing setup is the
>> same as previously mentioned.
>>
>> Thanks,
>> ilinca
>>
>> On Wed, Nov 13, 2019 at 5:40 PM Gyan  wrote:
>>
>>> As suggested in the review of an earlier patch*, this one drops frames
>>> till a TC is seen.
>>>
>>> Testing results to follow.
>>>
>>> Thanks,
>>> Gyan
>>>
>>> *https://patchwork.ffmpeg.org/patch/14081/
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>> To unsubscribe, visit link above, or email
>>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>>
>>
>>
>>
>
> --
>
> ---
> Ilinca Tudose | Technical Solutions Consultant, Digitization Operations |
> go/digitops 
> Google Germany GmbH
> Erika-Mann-Str. 33
> 80636 München
>
> Registergericht und -nummer: Hamburg, HRB 86891
>
> Sitz der Gesellschaft: Hamburg
>
> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Diese E-Mail ist
> vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese
> bitte nicht weiter, informieren Sie den Absender und löschen Sie die E-Mail
> und alle Anhänge. Vielen Dank. This e-mail is confidential. If you are not
> the right addressee please do not forward it, please inform the sender, and
> please erase this e-mail including any attachments. Thanks. Der Inhalt
> dieser E-Mail spiegelt den derzeitigen Stand der Verhandlungen wider und
> dient als Basis für weitere Gespräche. Er soll keine rechtlich verbindliche
> Verpflichtung begründen. Eine solche Verpflichtung wird allein durch einen
> zwischen allen beteiligten Parteien abgeschlossenen, schriftlichen Vertrag
> geschaffen. The above terms reflect a potential business arrangement, are
> provided solely as a basis for further discussion, and are not intended to
> be and do not constitute a legally binding obligation. No legally binding
> obligations will be created, implied, or inferred until an agreement in
> final form is executed in writing by all parties involved.
>


-- 

---
Ilinca Tudose | Technical Solutions Consultant, Digitization Operations |
go/digitops 
Google Germany GmbH
Erika-Mann-Str. 33
80636 München

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Diese E-Mail ist
vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese
bitte nicht weiter, informieren Sie den Absender und löschen Sie die E-Mail
und alle Anhänge. Vielen Dank. This e-mail is confidential. If you are not
the right addressee please do not forward it, please inform the sender, and
please erase this e-mail including any attachments. Thanks. Der Inhalt
dieser E-Mail spiegelt den derzeitigen Stand der Verhandlungen wider und
dient als Basis für weitere Gespräche. Er soll keine rechtlich verbindliche
Verpflichtung begründen. Eine solche Verpflichtung wird allein durch einen
zwischen allen beteiligten Parteien abgeschlossenen, schriftlichen Vertrag
geschaffen. The above terms reflect a potential business arrangement, are
provided solely as a basis for further discussion, and are not intended to
be and do not constitute a legally binding obligation. No legally binding
obligations will be created, implied, or inferred until an agreement in
final form is executed in writing by all parties involved.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Async the encoding and output procedure of encoder

2019-11-14 Thread Fu, Linjie
> -Original Message-
> From: ffmpeg-devel  On Behalf Of Fu,
> Linjie
> Sent: Monday, November 11, 2019 17:43
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Async the
> encoding and output procedure of encoder
> 
> > -Original Message-
> > From: Fu, Linjie 
> > Sent: Friday, November 8, 2019 00:32
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie 
> > Subject: [PATCH] lavc/vaapi_encode: Async the encoding and output
> > procedure of encoder
> >
> > Currently, vaapi encodes a pic if all its references are ready,
> > and then outputs it immediately by calling vaapi_encode_output.
> >
> > However, while working on output procedure, hardware is be able to
> > cope with encoding tasks in the meantime to have the better performance.
> >
> > So a more efficient way is to send all the pics with available refs to
> > hardware to allow encoding while output.
> >
> > It's what vaapi originally did before the regression, and the performance
> > could be improved for ~20%.
> >
> > CMD:
> > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128
> > -hwaccel_output_format vaapi -i
> bbb_sunflower_1080p_30fps_normal.mp4
> > -c:v h264_vaapi -f h264 -y /dev/null
> >
> > Source:
> > https://download.blender.org/demo/movies/BBB/
> >
> > Before:
> > ~164 fps
> > After:
> > ~198 fps
> >
> > Fix #7706.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/vaapi_encode.c | 27 +++
> >  1 file changed, 19 insertions(+), 8 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > index 3be9159d37..aceb268315 100644
> > --- a/libavcodec/vaapi_encode.c
> > +++ b/libavcodec/vaapi_encode.c
> > @@ -1109,17 +1109,28 @@ int
> > ff_vaapi_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
> >  return AVERROR(EAGAIN);
> >  }
> >
> > +pick_next:
> >  pic = NULL;
> >  err = vaapi_encode_pick_next(avctx, );
> > -if (err < 0)
> > -return err;
> > -av_assert0(pic);
> > +if (!err) {
> > +av_assert0(pic);
> >
> > -pic->encode_order = ctx->encode_order++;
> > +pic->encode_order = ctx->encode_order++;
> >
> > -err = vaapi_encode_issue(avctx, pic);
> > -if (err < 0) {
> > -av_log(avctx, AV_LOG_ERROR, "Encode failed: %d.\n", err);
> > +err = vaapi_encode_issue(avctx, pic);
> > +if (err < 0) {
> > +av_log(avctx, AV_LOG_ERROR, "Encode failed: %d.\n", err);
> > +return err;
> > +}
> > +goto pick_next;
> > +} else if (err == AVERROR(EAGAIN)) {
> > +for (pic = ctx->pic_start; pic; pic = pic->next)
> > +if (pic->encode_issued && !pic->encode_complete &&
> > +pic->encode_order == ctx->output_order)
> > +break;
> > +if (!pic)
> > +return err;
> > +} else {
> >  return err;
> >  }
> >
> > @@ -1143,7 +1154,7 @@ int
> > ff_vaapi_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
> >  av_log(avctx, AV_LOG_DEBUG, "Output packet: pts %"PRId64"
> > dts %"PRId64".\n",
> > pkt->pts, pkt->dts);
> >
> > -ctx->output_order = pic->encode_order;
> > +ctx->output_order++;
> >  vaapi_encode_clear_old(avctx);
> >
> >  return 0;
> 
> Ping.

Ping for this.
Any advice or comment would be appreciated.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/avcodec: Adapt the doc of av_bsf_send_packet

2019-11-14 Thread James Almer
On 11/14/2019 11:44 AM, Andreas Rheinhardt wrote:
> to match its actual implementation.
> 
> Explicitly allowing empty packets to signal flushing helps getting rid
> of special cases. It does not hinder the ability to send i.e.
> timing-only packets, because one can send packets with zero size and
> pkt->data set.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> I used "vanish" as an umbrella term for "being NULL or zero"
> (pkt->side_data_elems is an int). Maybe using C directly (i.e.
> !pkt->data) would be more clear? It would certainly be briefer.
> 
>  libavcodec/avcodec.h | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index bcb931f0dd..82f04f1130 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -5946,11 +5946,13 @@ int av_bsf_init(AVBSFContext *ctx);
>   *
>   * @param pkt the packet to filter. The bitstream filter will take ownership 
> of
>   * the packet and reset the contents of pkt. pkt is not touched if an error 
> occurs.
> - * This parameter may be NULL, which signals the end of the stream (i.e. no 
> more
> - * packets will be sent). That will cause the filter to output any packets it
> - * may have buffered internally.
> + * If pkt is empty (i.e. NULL or pkt->data is NULL and pkt->side_data_elems 
> zero),
> + * it signals the end of the stream (i.e. no more non-empty packets will be 
> sent;
> + * sending more empty packets does nothing) and will cause the filter to 
> output
> + * any packets it may have buffered internally.
>   *
>   * @return 0 on success, a negative AVERROR on error.
> + * This function never fails if pkt is empty.
>   */
>  int av_bsf_send_packet(AVBSFContext *ctx, AVPacket *pkt);

Applied, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/avcodec: Adapt the doc of av_bsf_send_packet

2019-11-14 Thread Andreas Rheinhardt
to match its actual implementation.

Explicitly allowing empty packets to signal flushing helps getting rid
of special cases. It does not hinder the ability to send i.e.
timing-only packets, because one can send packets with zero size and
pkt->data set.

Signed-off-by: Andreas Rheinhardt 
---
I used "vanish" as an umbrella term for "being NULL or zero"
(pkt->side_data_elems is an int). Maybe using C directly (i.e.
!pkt->data) would be more clear? It would certainly be briefer.

 libavcodec/avcodec.h | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index bcb931f0dd..82f04f1130 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -5946,11 +5946,13 @@ int av_bsf_init(AVBSFContext *ctx);
  *
  * @param pkt the packet to filter. The bitstream filter will take ownership of
  * the packet and reset the contents of pkt. pkt is not touched if an error 
occurs.
- * This parameter may be NULL, which signals the end of the stream (i.e. no 
more
- * packets will be sent). That will cause the filter to output any packets it
- * may have buffered internally.
+ * If pkt is empty (i.e. NULL or pkt->data is NULL and pkt->side_data_elems 
zero),
+ * it signals the end of the stream (i.e. no more non-empty packets will be 
sent;
+ * sending more empty packets does nothing) and will cause the filter to output
+ * any packets it may have buffered internally.
  *
  * @return 0 on success, a negative AVERROR on error.
+ * This function never fails if pkt is empty.
  */
 int av_bsf_send_packet(AVBSFContext *ctx, AVPacket *pkt);
 
-- 
2.20.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avformat/av1dec: Redo flushing of bsf

2019-11-14 Thread James Almer
On 11/14/2019 11:06 AM, Andreas Rheinhardt wrote:
> The current approach has two different calls to av_bsf_send_packet():
> A normal one, sending a packet; and an extraordinary one just for
> flushing. These can be unified into one by making use of the newly
> documented fact that av_bsf_send_packet() allows to signal flushing via
> empty packets (i.e. packets without data and side-data).
> 
> This also fixes CID 1455685 which resulted from the fact that the call
> for flushing was not checked given that it couldn't fail.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> Untested as I didn't have an annex b sample.
> 
>  libavformat/av1dec.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/libavformat/av1dec.c b/libavformat/av1dec.c
> index a0cad55668..5e7a057cb7 100644
> --- a/libavformat/av1dec.c
> +++ b/libavformat/av1dec.c
> @@ -193,7 +193,6 @@ retry:
>  if (avio_feof(s->pb)) {
>  if (c->temporal_unit_size || c->frame_unit_size)
>  return AVERROR(EIO);
> -av_bsf_send_packet(c->bsf, NULL);
>  goto end;
>  }
>  
> @@ -222,6 +221,7 @@ retry:
>  c->temporal_unit_size -= obu_unit_size + len;
>  c->frame_unit_size -= obu_unit_size + len;
>  
> +end:
>  ret = av_bsf_send_packet(c->bsf, pkt);
>  if (ret < 0) {
>  av_log(s, AV_LOG_ERROR, "Failed to send packet to "
> @@ -229,7 +229,6 @@ retry:
>  return ret;
>  }
>  
> -end:
>  ret = av_bsf_receive_packet(c->bsf, pkt);
>  if (ret < 0 && ret != AVERROR(EAGAIN) && ret != AVERROR_EOF)
>  av_log(s, AV_LOG_ERROR, "av1_frame_merge filter failed to "

Will test and apply. Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/avcodec: Adapt the doc of av_bsf_send_packet

2019-11-14 Thread James Almer
On 11/14/2019 11:06 AM, Andreas Rheinhardt wrote:
> to match its actual implementation.
> 
> Explicitly allowing empty packets to signal flushing helps getting rid
> of special cases. It does not hinder the ability to send i.e.
> timing-only packets, because one can send packets with zero size and
> pkt->data set.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/avcodec.h | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index bcb931f0dd..93ab04104a 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -5946,11 +5946,13 @@ int av_bsf_init(AVBSFContext *ctx);
>   *
>   * @param pkt the packet to filter. The bitstream filter will take ownership 
> of
>   * the packet and reset the contents of pkt. pkt is not touched if an error 
> occurs.
> - * This parameter may be NULL, which signals the end of the stream (i.e. no 
> more
> - * packets will be sent). That will cause the filter to output any packets it
> - * may have buffered internally.
> + * If pkt is empty (i.e. NULL or pkt->data and pkt->side_data_elems vanish),

I'm not sure about "vanish". English is not my first language and it was
not clear at first glance that you meant both being NULL.

It's the first time that word is used in the codebase as well, so i
think it's best if we're consistent with the doxy from similar functions.

> + * it signals the end of the stream (i.e. no more non-empty packets will be 
> sent;
> + * sending more empty packets does nothing and will cause the filter to 
> output
> + * any packets it may have buffered internally.
>   *
> - * @return 0 on success, a negative AVERROR on error.
> + * @return 0 on success, a negative AVERROR on error.  This function never 
> fails

Extra blank space.

> + * if pkt is empty.
>   */
>  int av_bsf_send_packet(AVBSFContext *ctx, AVPacket *pkt);
>  
> 

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/2] avcodec/avcodec: Adapt the doc of av_bsf_send_packet

2019-11-14 Thread Andreas Rheinhardt
to match its actual implementation.

Explicitly allowing empty packets to signal flushing helps getting rid
of special cases. It does not hinder the ability to send i.e.
timing-only packets, because one can send packets with zero size and
pkt->data set.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/avcodec.h | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index bcb931f0dd..93ab04104a 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -5946,11 +5946,13 @@ int av_bsf_init(AVBSFContext *ctx);
  *
  * @param pkt the packet to filter. The bitstream filter will take ownership of
  * the packet and reset the contents of pkt. pkt is not touched if an error 
occurs.
- * This parameter may be NULL, which signals the end of the stream (i.e. no 
more
- * packets will be sent). That will cause the filter to output any packets it
- * may have buffered internally.
+ * If pkt is empty (i.e. NULL or pkt->data and pkt->side_data_elems vanish),
+ * it signals the end of the stream (i.e. no more non-empty packets will be 
sent;
+ * sending more empty packets does nothing and will cause the filter to output
+ * any packets it may have buffered internally.
  *
- * @return 0 on success, a negative AVERROR on error.
+ * @return 0 on success, a negative AVERROR on error.  This function never 
fails
+ * if pkt is empty.
  */
 int av_bsf_send_packet(AVBSFContext *ctx, AVPacket *pkt);
 
-- 
2.20.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/2] avformat/av1dec: Redo flushing of bsf

2019-11-14 Thread Andreas Rheinhardt
The current approach has two different calls to av_bsf_send_packet():
A normal one, sending a packet; and an extraordinary one just for
flushing. These can be unified into one by making use of the newly
documented fact that av_bsf_send_packet() allows to signal flushing via
empty packets (i.e. packets without data and side-data).

This also fixes CID 1455685 which resulted from the fact that the call
for flushing was not checked given that it couldn't fail.

Signed-off-by: Andreas Rheinhardt 
---
Untested as I didn't have an annex b sample.

 libavformat/av1dec.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavformat/av1dec.c b/libavformat/av1dec.c
index a0cad55668..5e7a057cb7 100644
--- a/libavformat/av1dec.c
+++ b/libavformat/av1dec.c
@@ -193,7 +193,6 @@ retry:
 if (avio_feof(s->pb)) {
 if (c->temporal_unit_size || c->frame_unit_size)
 return AVERROR(EIO);
-av_bsf_send_packet(c->bsf, NULL);
 goto end;
 }
 
@@ -222,6 +221,7 @@ retry:
 c->temporal_unit_size -= obu_unit_size + len;
 c->frame_unit_size -= obu_unit_size + len;
 
+end:
 ret = av_bsf_send_packet(c->bsf, pkt);
 if (ret < 0) {
 av_log(s, AV_LOG_ERROR, "Failed to send packet to "
@@ -229,7 +229,6 @@ retry:
 return ret;
 }
 
-end:
 ret = av_bsf_receive_packet(c->bsf, pkt);
 if (ret < 0 && ret != AVERROR(EAGAIN) && ret != AVERROR_EOF)
 av_log(s, AV_LOG_ERROR, "av1_frame_merge filter failed to "
-- 
2.20.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2 2/4] avfilter/vf_lut3d: Fix for framecrc bitexact for 32bit and 64bit system

2019-11-14 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavfilter/vf_lut3d.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/libavfilter/vf_lut3d.c b/libavfilter/vf_lut3d.c
index 9e820a17c9..9ba86f7238 100644
--- a/libavfilter/vf_lut3d.c
+++ b/libavfilter/vf_lut3d.c
@@ -243,9 +243,9 @@ static int 
interp_##nbits##_##name##_p##depth(AVFilterContext *ctx, void *arg, i
   srcg[x] * scale_g,   
\
   srcb[x] * scale_b};  
\
 struct rgbvec vec = interp_##name(lut3d, _rgb); 
\
-dstr[x] = av_clip_uintp2(vec.r * (float)((1

[FFmpeg-devel] [PATCH v2 3/4] FATE: add a test for lut1d and lut3d

2019-11-14 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
have tested with x86_64(apple darwin, linux gcc), x86_32(linux), mips

 tests/fate/filter-video.mak |  6 ++
 tests/ref/fate/filter-pixfmts-lut1d | 24 
 tests/ref/fate/filter-pixfmts-lut3d | 24 
 3 files changed, 54 insertions(+)
 create mode 100644 tests/ref/fate/filter-pixfmts-lut1d
 create mode 100644 tests/ref/fate/filter-pixfmts-lut3d

diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index b5206909aa..8d617c62fc 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -684,6 +684,12 @@ fate-filter-pixfmts-kerndeint: CMD = pixfmts "" 
"tinterlace=interleave_top,"
 FATE_FILTER_PIXFMTS-$(CONFIG_LUT_FILTER) += fate-filter-pixfmts-lut
 fate-filter-pixfmts-lut: CMD = pixfmts 
"c0=2*val:c1=2*val:c2=val/2:c3=negval+40"
 
+FATE_FILTER_PIXFMTS-$(CONFIG_LUT_FILTER) += fate-filter-pixfmts-lut1d
+fate-filter-pixfmts-lut1d: CMD = pixfmts "interp=nearest" "" "" "le"
+
+FATE_FILTER_PIXFMTS-$(CONFIG_LUT_FILTER) += fate-filter-pixfmts-lut3d
+fate-filter-pixfmts-lut3d: CMD = pixfmts "interp=nearest" "" "" "le"
+
 FATE_FILTER_PIXFMTS-$(CONFIG_NULL_FILTER) += fate-filter-pixfmts-null
 fate-filter-pixfmts-null:  CMD = pixfmts
 
diff --git a/tests/ref/fate/filter-pixfmts-lut1d 
b/tests/ref/fate/filter-pixfmts-lut1d
new file mode 100644
index 00..62b024eab9
--- /dev/null
+++ b/tests/ref/fate/filter-pixfmts-lut1d
@@ -0,0 +1,24 @@
+0bgr074f16a502fe65d34a7933ff3575c7a8
+0rgbf5a434b811185534393f7144127a8625
+abgre1631a7ebcf6d1d80ef2a3de44605391
+argb6e898ace2a1a020df40050927eedea31
+bgr09133afba160bf37de9f8cb7cbe154539
+bgr24   2723c862eba4dc18776b908ee3e96015
+bgr48le ab0f343cd4f15e2a2a6cbe552777ede9
+bgra1771a74cceffb1dc8cb4a7b754c31cbe
+bgra64leca8f99b90f4727907824964b2f024115
+gbrap   04d467134a42becf7c2ddd8fbbb2c8e8
+gbrap10le   c36078e25fa8fdcf2d1965122e84a974
+gbrap12le   d41627c671d8cebf68a4ab1e340e3692
+gbrap16le   9acf810f050969b589c1c4040ad463bf
+gbrp48216afac8939342dd57e6a6d7bffa77
+gbrp10lea43244e4ac58b9b7321d1054f97362b5
+gbrp12le3acc433145a00b02517759a3d08ecbaa
+gbrp14le8d5c259928b5b13201deb0413661c58f
+gbrp16le4d0fe663751b111f1328244cbd194627
+gbrp9le b4d50fa86a796d57a93ea5ae14780f7a
+rgb0e780a70aabf6451ef9c27e448cb12e27
+rgb24   7c4fb568561631e596bec0ca7525d999
+rgb48le aba2a2d23af49c892d57b1bcd01317ea
+rgba51e48e3ffe1f208c613f3a3372516fc5
+rgba64le6468a415e6effee141a2022973275006
diff --git a/tests/ref/fate/filter-pixfmts-lut3d 
b/tests/ref/fate/filter-pixfmts-lut3d
new file mode 100644
index 00..62b024eab9
--- /dev/null
+++ b/tests/ref/fate/filter-pixfmts-lut3d
@@ -0,0 +1,24 @@
+0bgr074f16a502fe65d34a7933ff3575c7a8
+0rgbf5a434b811185534393f7144127a8625
+abgre1631a7ebcf6d1d80ef2a3de44605391
+argb6e898ace2a1a020df40050927eedea31
+bgr09133afba160bf37de9f8cb7cbe154539
+bgr24   2723c862eba4dc18776b908ee3e96015
+bgr48le ab0f343cd4f15e2a2a6cbe552777ede9
+bgra1771a74cceffb1dc8cb4a7b754c31cbe
+bgra64leca8f99b90f4727907824964b2f024115
+gbrap   04d467134a42becf7c2ddd8fbbb2c8e8
+gbrap10le   c36078e25fa8fdcf2d1965122e84a974
+gbrap12le   d41627c671d8cebf68a4ab1e340e3692
+gbrap16le   9acf810f050969b589c1c4040ad463bf
+gbrp48216afac8939342dd57e6a6d7bffa77
+gbrp10lea43244e4ac58b9b7321d1054f97362b5
+gbrp12le3acc433145a00b02517759a3d08ecbaa
+gbrp14le8d5c259928b5b13201deb0413661c58f
+gbrp16le4d0fe663751b111f1328244cbd194627
+gbrp9le b4d50fa86a796d57a93ea5ae14780f7a
+rgb0e780a70aabf6451ef9c27e448cb12e27
+rgb24   7c4fb568561631e596bec0ca7525d999
+rgb48le aba2a2d23af49c892d57b1bcd01317ea
+rgba51e48e3ffe1f208c613f3a3372516fc5
+rgba64le6468a415e6effee141a2022973275006
-- 
2.21.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2 1/4] tests/fate-run: add pixel format endian mode parameter for pixfmts function

2019-11-14 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
 tests/fate-run.sh | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index aec12c16a3..6ea0ab4f3c 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -385,6 +385,8 @@ pixfmts(){
 filter_args=$1
 prefilter_chain=$2
 nframes=${3:-1}
+# be,le
+endian_mode=$4
 
 showfiltfmts="$target_exec 
$target_path/libavfilter/tests/filtfmts${EXECSUF}"
 scale_exclude_fmts=${outfile}_scale_exclude_fmts
@@ -402,8 +404,13 @@ pixfmts(){
 
 outertest=$test
 for pix_fmt in $pix_fmts; do
-test=$pix_fmt
-video_filter "${prefilter_chain}format=$pix_fmt,$filter=$filter_args" 
-pix_fmt $pix_fmt -frames:v $nframes
+if [ "$endian_mode" = "le" ]; then
+output_pix_fmt=`echo $pix_fmt | sed "s/\(.*\)be/\1le/"`
+else
+output_pix_fmt=$pix_fmt
+fi
+test=$output_pix_fmt
+video_filter "${prefilter_chain}format=$pix_fmt,$filter=$filter_args" 
-pix_fmt $output_pix_fmt -frames:v $nframes
 done
 
 rm $in_fmts $scale_in_fmts $scale_out_fmts $scale_exclude_fmts
-- 
2.21.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/av1dec: check return value of the av_bsf_send_packet in annexb_read_packet

2019-11-14 Thread James Almer
On 11/14/2019 7:24 AM, Steven Liu wrote:
> CID: 1455685
> Signed-off-by: Steven Liu 
> ---
>  libavformat/av1dec.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/av1dec.c b/libavformat/av1dec.c
> index a0cad55668..7cbc7ef9bf 100644
> --- a/libavformat/av1dec.c
> +++ b/libavformat/av1dec.c
> @@ -193,7 +193,11 @@ retry:
>  if (avio_feof(s->pb)) {
>  if (c->temporal_unit_size || c->frame_unit_size)
>  return AVERROR(EIO);
> -av_bsf_send_packet(c->bsf, NULL);
> +ret = av_bsf_send_packet(c->bsf, NULL);
> +if (ret < 0) {
> +av_log(s, AV_LOG_ERROR, "annexb filter failed to send input 
> packet\n");
> +return ret;
> +}
>  goto end;
>  }

As Andreas mentioned, this is a flush call, and it can't fail. That's
why we're not checking the return value.

Can we hint Coverity about this in some form? Would setting ret followed
by the jump to the end label make it happy?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/av1dec: check return value of the av_bsf_send_packet in annexb_read_packet

2019-11-14 Thread Andreas Rheinhardt
Steven Liu:
> CID: 1455685
> Signed-off-by: Steven Liu 
> ---
>  libavformat/av1dec.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/av1dec.c b/libavformat/av1dec.c
> index a0cad55668..7cbc7ef9bf 100644
> --- a/libavformat/av1dec.c
> +++ b/libavformat/av1dec.c
> @@ -193,7 +193,11 @@ retry:
>  if (avio_feof(s->pb)) {
>  if (c->temporal_unit_size || c->frame_unit_size)
>  return AVERROR(EIO);
> -av_bsf_send_packet(c->bsf, NULL);
> +ret = av_bsf_send_packet(c->bsf, NULL);
> +if (ret < 0) {
> +av_log(s, AV_LOG_ERROR, "annexb filter failed to send input 
> packet\n");
> +return ret;
> +}
>  goto end;
>  }
>  
> 
Actually, there is a difference between this call and the other calls
to av_bsf_send_packet(): This one only flushes (sends a NULL packet)
and therefore can't fail.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/av1dec: check return value of the av_bsf_send_packet in annexb_read_packet

2019-11-14 Thread Steven Liu
CID: 1455685
Signed-off-by: Steven Liu 
---
 libavformat/av1dec.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavformat/av1dec.c b/libavformat/av1dec.c
index a0cad55668..7cbc7ef9bf 100644
--- a/libavformat/av1dec.c
+++ b/libavformat/av1dec.c
@@ -193,7 +193,11 @@ retry:
 if (avio_feof(s->pb)) {
 if (c->temporal_unit_size || c->frame_unit_size)
 return AVERROR(EIO);
-av_bsf_send_packet(c->bsf, NULL);
+ret = av_bsf_send_packet(c->bsf, NULL);
+if (ret < 0) {
+av_log(s, AV_LOG_ERROR, "annexb filter failed to send input 
packet\n");
+return ret;
+}
 goto end;
 }
 
-- 
2.15.1



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".