[FFmpeg-devel] [PATCH] lavfi: add helper macro for OpenCL error handling.

2018-06-12 Thread Ruiling Song 
Signed-off-by: Ruiling Song 
---
I am not sure whether do you think this would be useful?
the main purpose is to make OpenCL error check code simpler.
If we think this is good, I can go to replace current
OpenCL filters to use this macro.

for example:
if (cle != CL_SUCCESS) {
av_log(avctx, AV_LOG_ERROR, "Failed to enqueue kernel: %d.\n",
   cle);
err = AVERROR(EIO);
goto fail;
}
can be replaced with:
OCL_FAIL_ON_ERR(avctx, cle, AVERROR(EIO), "Failed to enqueue kernel: %d.\n", 
cle);

Thanks!
Ruiling
 libavfilter/opencl.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/libavfilter/opencl.h b/libavfilter/opencl.h
index c0a4519..c33df1c 100644
--- a/libavfilter/opencl.h
+++ b/libavfilter/opencl.h
@@ -97,5 +97,16 @@ int ff_opencl_filter_work_size_from_image(AVFilterContext 
*avctx,
   size_t *work_size,
   AVFrame *frame, int plane,
   int block_alignment);
+/**
+ * A helper macro to handle OpenCL error. It will assign errcode to
+ * variable err, log error msg, and jump to fail label on error.
+ */
+#define OCL_FAIL_ON_ERR(logctx, cle, errcode, ...) do {\
+if (cle != CL_SUCCESS) {\
+av_log(logctx, AV_LOG_ERROR, __VA_ARGS__);\
+err = errcode;\
+goto fail;\
+}\
+} while(0)
 
 #endif /* AVFILTER_OPENCL_H */
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH v2 11/36] vaapi_encode: Choose profiles dynamically

2018-06-12 Thread Xiang, Haihao 
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> Previously there was one fixed choice for each codec (e.g. H.265 -> Main
> profile), and using anything else then required an explicit option from
> the user.  This changes to selecting the profile based on the input format
> and the set of profiles actually supported by the driver (e.g. P010 input
> will choose Main 10 profile for H.265 if the driver supports it).
> 
> The entrypoint and render target format are also chosen dynamically in the
> same way, removing those explicit selections from the per-codec code.
> ---
>  doc/encoders.texi   |   3 +
>  libavcodec/vaapi_encode.c   | 271 ---
> -
>  libavcodec/vaapi_encode.h   |  43 +--
>  libavcodec/vaapi_encode_h264.c  |  45 ++-
>  libavcodec/vaapi_encode_h265.c  |  35 ++
>  libavcodec/vaapi_encode_mjpeg.c |  13 +-
>  libavcodec/vaapi_encode_mpeg2.c |  36 ++
>  libavcodec/vaapi_encode_vp8.c   |  11 +-
>  libavcodec/vaapi_encode_vp9.c   |  34 ++---
>  9 files changed, 310 insertions(+), 181 deletions(-)
> 
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 7b095754d1..16be6359b3 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -2565,6 +2565,9 @@ The following standard libavcodec options are used:
>  @option{bf} / @option{max_b_frames}
>  @item
>  @option{profile}
> +
> +If not set, this will be determined automatically from the format of the
> input
> +frames and the profiles supported by the driver.
>  @item
>  @option{level}
>  @item
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 27ce792fbe..6104470b31 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -983,70 +983,247 @@ static av_cold void
> vaapi_encode_add_global_param(AVCodecContext *avctx,
>  ++ctx->nb_global_params;
>  }
>  
> -static av_cold int vaapi_encode_config_attributes(AVCodecContext *avctx)
> +typedef struct VAAPIEncodeRTFormat {
> +const char *name;
> +unsigned int value;
> +int depth;
> +int components;

How about adding a prefix of 'nb_' to this field? I think nb_components is more
readable. 

> +int log2_chroma_w;
> +int log2_chroma_h;
> +} VAAPIEncodeRTFormat;
> +
> +static const VAAPIEncodeRTFormat vaapi_encode_rt_formats[] = {
> +{ "YUV400",VA_RT_FORMAT_YUV400,8, 1,  },
> +{ "YUV420",VA_RT_FORMAT_YUV420,8, 3, 1, 1 },
> +{ "YUV422",VA_RT_FORMAT_YUV422,8, 3, 1, 0 },
> +{ "YUV444",VA_RT_FORMAT_YUV444,8, 3, 0, 0 },
> +{ "YUV411",VA_RT_FORMAT_YUV411,8, 3, 2, 0 },
> +#if VA_CHECK_VERSION(0, 38, 1)
> +{ "YUV420_10", VA_RT_FORMAT_YUV420_10BPP, 10, 3, 1, 1 },
> +#endif
> +};
> +
> +static const VAEntrypoint vaapi_encode_entrypoints_normal[] = {
> +VAEntrypointEncSlice,
> +VAEntrypointEncPicture,
> +#if VA_CHECK_VERSION(0, 39, 2)
> +VAEntrypointEncSliceLP,
> +#endif
> +0
> +};
> +#if VA_CHECK_VERSION(0, 39, 2)
> +static const VAEntrypoint vaapi_encode_entrypoints_low_power[] = {
> +VAEntrypointEncSliceLP,
> +0
> +};
> +#endif
> +
> +static av_cold int vaapi_encode_profile_entrypoint(AVCodecContext *avctx)
>  {
> -VAAPIEncodeContext *ctx = avctx->priv_data;
> +VAAPIEncodeContext  *ctx = avctx->priv_data;
> +VAProfile*va_profiles= NULL;
> +VAEntrypoint *va_entrypoints = NULL;
>  VAStatus vas;
> -int i, n, err;
> -VAProfile*profiles= NULL;
> -VAEntrypoint *entrypoints = NULL;
> -VAConfigAttrib attr[] = {
> -{ VAConfigAttribRTFormat },
> -{ VAConfigAttribRateControl  },
> -{ VAConfigAttribEncMaxRefFrames  },
> -{ VAConfigAttribEncPackedHeaders },
> -};
> +const VAEntrypoint *usable_entrypoints;
> +const VAAPIEncodeProfile *profile;
> +const AVPixFmtDescriptor *desc;
> +VAConfigAttrib rt_format_attr;
> +const VAAPIEncodeRTFormat *rt_format;
> +int i, j, n, depth, err;
> +
> +
> +if (ctx->low_power) {
> +#if VA_CHECK_VERSION(0, 39, 2)
> +usable_entrypoints = vaapi_encode_entrypoints_low_power;
> +#else
> +av_log(avctx, AV_LOG_ERROR, "Low-power encoding is not "
> +   "supported with this VAAPI version.\n");

Is it possible to report the minimal VAAPI version in the log in case user
doesn't know the requirement on vaapi version 0.39.2?

> +return AVERROR(EINVAL);
> +#endif
> +} else {
> +usable_entrypoints = vaapi_encode_entrypoints_normal;
> +}
> +
> +desc = av_pix_fmt_desc_get(ctx->input_frames->sw_format);
> +if (!desc) {
> +av_log(avctx, AV_LOG_ERROR, "Invalid input pixfmt (%d).\n",
> +   ctx->input_frames->sw_format);
> +return AVERROR(EINVAL);
> +}
> +depth = desc->comp[0].depth;
> +for (i = 1; i < desc->nb_components; i++) {
> +if (desc->comp[i].depth != depth) {
> +av_log(avctx, AV_LOG_ERROR, "Inv

Re: [FFmpeg-devel] [PATCH v2 14/36] vaapi_encode: Clean up the encode quality configuration

2018-06-12 Thread Xiang, Haihao 
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> ---
>  libavcodec/vaapi_encode.c  | 84 +--
> ---
>  libavcodec/vaapi_encode_h264.c |  7 ++--
>  2 files changed, 54 insertions(+), 37 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 6104470b31..4da8a7083c 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1391,6 +1391,51 @@ static av_cold int
> vaapi_encode_init_rate_control(AVCodecContext *avctx)
>  return 0;
>  }
>  
> +static av_cold int vaapi_encode_init_quality(AVCodecContext *avctx)
> +{
> +#if VA_CHECK_VERSION(0, 36, 0)
> +VAAPIEncodeContext *ctx = avctx->priv_data;
> +VAStatus vas;
> +VAConfigAttrib attr = { VAConfigAttribEncQualityRange };
> +int quality = avctx->compression_level;
> +
> +vas = vaGetConfigAttributes(ctx->hwctx->display,
> +ctx->va_profile,
> +ctx->va_entrypoint,
> +&attr, 1);
> +if (vas != VA_STATUS_SUCCESS) {
> +av_log(avctx, AV_LOG_ERROR, "Failed to query quality "
> +   "config attribute: %d (%s).\n", vas, vaErrorStr(vas));
> +return AVERROR_EXTERNAL;
> +}
> +
> +if (attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> +if (quality != 0) {
> +av_log(avctx, AV_LOG_WARNING, "Quality attribute is not "
> +   "supported: will use default quality level.\n");
> +}
> +} else {
> +if (quality > attr.value) {
> +av_log(avctx, AV_LOG_WARNING, "Invalid quality level: "
> +   "valid range is 0-%d, using %d.\n",
> +   attr.value, attr.value);
> +quality = attr.value;
> +}
> +
> +ctx->quality_params.misc.type = VAEncMiscParameterTypeQualityLevel;
> +ctx->quality_params.quality.quality_level = quality;
> +
> +vaapi_encode_add_global_param(avctx, &ctx->quality_params.misc,
> +  sizeof(ctx->quality_params));
> +}
> +#else
> +av_log(avctx, AV_LOG_WARNING, "The encode quality option is "
> +   "not supported with this VAAPI version.\n");

Log the minimal VAAPI version for quality attribute?

> +#endif
> +
> +return 0;
> +}
> +
>  static void vaapi_encode_free_output_buffer(void *opaque,
>  uint8_t *data)
>  {
> @@ -1572,6 +1617,12 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx)
>  if (err < 0)
>  goto fail;
>  
> +if (avctx->compression_level >= 0) {
> +err = vaapi_encode_init_quality(avctx);
> +if (err < 0)
> +goto fail;
> +}
> +
>  vas = vaCreateConfig(ctx->hwctx->display,
>   ctx->va_profile, ctx->va_entrypoint,
>   ctx->config_attributes, ctx->nb_config_attributes,
> @@ -1621,39 +1672,6 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx)
>  goto fail;
>  }
>  
> -if (avctx->compression_level >= 0) {
> -#if VA_CHECK_VERSION(0, 36, 0)
> -VAConfigAttrib attr = { VAConfigAttribEncQualityRange };
> -
> -vas = vaGetConfigAttributes(ctx->hwctx->display,
> -ctx->va_profile,
> -ctx->va_entrypoint,
> -&attr, 1);
> -if (vas != VA_STATUS_SUCCESS) {
> -av_log(avctx, AV_LOG_WARNING, "Failed to query quality "
> -   "attribute: will use default compression level.\n");
> -} else {
> -if (avctx->compression_level > attr.value) {
> -av_log(avctx, AV_LOG_WARNING, "Invalid compression "
> -   "level: valid range is 0-%d, using %d.\n",
> -   attr.value, attr.value);
> -avctx->compression_level = attr.value;
> -}
> -
> -ctx->quality_params.misc.type =
> -VAEncMiscParameterTypeQualityLevel;
> -ctx->quality_params.quality.quality_level =
> -avctx->compression_level;
> -
> -vaapi_encode_add_global_param(avctx, &ctx->quality_params.misc,
> -  sizeof(ctx->quality_params));
> -}
> -#else
> -av_log(avctx, AV_LOG_WARNING, "The encode compression level "
> -   "option is not supported with this VAAPI version.\n");
> -#endif
> -}
> -
>  ctx->input_order  = 0;
>  ctx->output_delay = avctx->max_b_frames;
>  ctx->decode_delay = 1;
> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> index c72fb9f00a..df6f39a946 100644
> --- a/libavcodec/vaapi_encode_h264.c
> +++ b/libavcodec/vaapi_encode_h264.c
> @@ -831,9 +831,6 @@ static av_cold int
> vaapi_encode_h264_configure(AVCodecContext *avctx)
>  av_assert0(0 && "Invalid RC mode.");
>  }
>  
> -

Re: [FFmpeg-devel] [PATCH v3 1/2] lavfi: add opencl tonemap filter.

2018-06-12 Thread Song, Ruiling 


> -Original Message-
> From: Song, Ruiling
> Sent: Wednesday, June 6, 2018 3:24 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Song, Ruiling 
> Subject: [PATCH v3 1/2] lavfi: add opencl tonemap filter.
> 
> This filter does HDR(HDR10/HLG) to SDR conversion with tone-mapping.
> 
> An example command to use this filter with vaapi codecs:
> FFMPEG -init_hw_device vaapi=va:/dev/dri/renderD128 -init_hw_device \
> opencl=ocl@va -hwaccel vaapi -hwaccel_device va -hwaccel_output_format \
> vaapi -i INPUT -filter_hw_device ocl -filter_complex \
> '[0:v]hwmap,tonemap_opencl=t=bt2020:tonemap=linear:format=p010[x1]; \
> [x1]hwmap=derive_device=vaapi:reverse=1' -c:v hevc_vaapi -profile 2 OUTPUT
> 
> Signed-off-by: Ruiling Song 
> ---
> this version mainly address Mark's comments on v2.
> 
> Thanks!
> Ruiling
Ping? Any other comments on this version?

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

[FFmpeg-devel] [PATCH]configure: The eac3_core bsf needs the ac3 parser

2018-06-12 Thread Carl Eugen Hoyos 
Hi!

Attached patch fixes a linking error reported on libav-user, other
solutions are slightly more intrusive.

Please comment, Carl Eugen
From d65eb39bb0fb52ca2ba88445535a23aa5fca6b27 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 12 Jun 2018 10:02:44 +0200
Subject: [PATCH] configure: The eac3_core bitstream filter needs the ac3
 parser.

---
 configure |1 +
 1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index 473be31..994d800 100755
--- a/configure
+++ b/configure
@@ -2992,6 +2992,7 @@ vc1_parser_select="vc1dsp"
 
 # bitstream_filters
 aac_adtstoasc_bsf_select="adts_header"
+eac3_core_bsf_select="ac3_parser"
 filter_units_bsf_select="cbs"
 h264_metadata_bsf_deps="const_nan"
 h264_metadata_bsf_select="cbs_h264"
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] avformat: remove unused MP4A_LATM flag

2018-06-12 Thread Hendrik Leppkes 
On Tue, Jun 12, 2018 at 7:00 AM Gyan Doshi  wrote:
>
>
> Will push tomorrow.

This flag is part of the public API, and eventhough it is entirely
unused, you cannot remove public API without a proper deprecation
period.

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

Re: [FFmpeg-devel] [PATCH] avformat: remove unused MP4A_LATM flag

2018-06-12 Thread Gyan Doshi 



On 12-06-2018 01:39 PM, Hendrik Leppkes wrote:


This flag is part of the public API, and eventhough it is entirely
unused, you cannot remove public API without a proper deprecation
period.


Ok, so looking at older flags, I need to

add a define to version.h, something like

#ifndef FF_API_LAVF_MP4A_LATM
#define FF_API_LAVF_MP4A_LATM(LIBAVFORMAT_VERSION_MAJOR < 59)
#endif

and place the flag under guard in avformat.h

And place same guard in the options table.

Is that correct?

I assume the other changes can be committed as-is.

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

Re: [FFmpeg-devel] [PATCH 09/12] avformat/mxfdec: add support for clip wrapped essences

2018-06-12 Thread Marton Balint 



On Tue, 12 Jun 2018, Michael Niedermayer wrote:


On Sun, Jun 10, 2018 at 12:36:47PM +0200, Marton Balint wrote:

Also use common code with opAtom.

Fixes ticket #2776.
Partially fixes ticket #5671.
Fixes ticket #5866.

Signed-off-by: Marton Balint 
---
 libavformat/mxfdec.c | 281 ---
 1 file changed, 130 insertions(+), 151 deletions(-)


causes a segfault:

==23735== Invalid read of size 8
==23735==at 0x75A627: mxf_set_pts (mxfdec.c:3277)
==23735==by 0x75ACAD: mxf_read_packet_old (mxfdec.c:3396)
==23735==by 0x7E099D: ff_read_packet (utils.c:856)
==23735==by 0x7E39FF: read_frame_internal (utils.c:1581)
==23735==by 0x7EB82B: avformat_find_stream_info (utils.c:3773)
==23735==by 0x415534: open_input_file (ffmpeg_opt.c:1091)
==23735==by 0x41EB11: open_files (ffmpeg_opt.c:3206)
==23735==by 0x41ECA3: ffmpeg_parse_options (ffmpeg_opt.c:3246)
==23735==by 0x43D1A3: main (ffmpeg.c:4832)
==23735==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==23735==
==23735==
==23735== Process terminating with default action of signal 11 (SIGSEGV)
==23735==  Access not within mapped region at address 0x0
==23735==at 0x75A627: mxf_set_pts (mxfdec.c:3277)
==23735==by 0x75ACAD: mxf_read_packet_old (mxfdec.c:3396)
==23735==by 0x7E099D: ff_read_packet (utils.c:856)
==23735==by 0x7E39FF: read_frame_internal (utils.c:1581)
==23735==by 0x7EB82B: avformat_find_stream_info (utils.c:3773)
==23735==by 0x415534: open_input_file (ffmpeg_opt.c:1091)
==23735==by 0x41EB11: open_files (ffmpeg_opt.c:3206)
==23735==by 0x41ECA3: ffmpeg_parse_options (ffmpeg_opt.c:3246)
==23735==by 0x43D1A3: main (ffmpeg.c:4832)
==23735==  If you believe this happened as a result of a stack
==23735==  overflow in your program's main thread (unlikely but
==23735==  possible), you can try to increase the size of the
==23735==  main thread stack using the --main-stacksize= flag.
==23735==  The main thread stack size used in this run was 8388608.


I don't see this. What is your command line?

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

Re: [FFmpeg-devel] [PATCH 09/12] avformat/mxfdec: add support for clip wrapped essences

2018-06-12 Thread Paul B Mahol 
On 6/12/18, Michael Niedermayer  wrote:
> On Sun, Jun 10, 2018 at 12:36:47PM +0200, Marton Balint wrote:
>> Also use common code with opAtom.
>>
>> Fixes ticket #2776.
>> Partially fixes ticket #5671.
>> Fixes ticket #5866.
>>
>> Signed-off-by: Marton Balint 
>> ---
>>  libavformat/mxfdec.c | 281
>> ---
>>  1 file changed, 130 insertions(+), 151 deletions(-)
>
> causes a segfault:

Looks like some old habits never disappear.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4 v3] avcodec/vc1: rewrite vc1_decode_i_blocks to align with VC-1 spec

2018-06-12 Thread Jerome Borsboom 
Change vc1_decode_i_blocks to use vc1_put_blocks_clamped and
ff_vc1_i_loop_filter.

Signed-off-by: Jerome Borsboom 
---
The v3 patch should resolve the crashing that was seen on corrupted source 
files.

 libavcodec/vc1_block.c | 79 +++---
 1 file changed, 30 insertions(+), 49 deletions(-)

diff --git a/libavcodec/vc1_block.c b/libavcodec/vc1_block.c
index 1dc8c6422d..c620566f78 100644
--- a/libavcodec/vc1_block.c
+++ b/libavcodec/vc1_block.c
@@ -2537,30 +2537,28 @@ static void vc1_decode_i_blocks(VC1Context *v)
 s->mb_x = s->mb_y = 0;
 s->mb_intra = 1;
 s->first_slice_line = 1;
-for (s->mb_y = 0; s->mb_y < s->end_mb_y; s->mb_y++) {
+for (s->mb_y = s->start_mb_y; s->mb_y < s->end_mb_y; s->mb_y++) {
 s->mb_x = 0;
 init_block_index(v);
 for (; s->mb_x < v->end_mb_x; s->mb_x++) {
-uint8_t *dst[6];
+int16_t (*block)[64] = v->block[v->cur_blk_idx];
 ff_update_block_index(s);
-dst[0] = s->dest[0];
-dst[1] = dst[0] + 8;
-dst[2] = s->dest[0] + s->linesize * 8;
-dst[3] = dst[2] + 8;
-dst[4] = s->dest[1];
-dst[5] = s->dest[2];
-s->bdsp.clear_blocks(s->block[0]);
+s->bdsp.clear_blocks(block[0]);
 mb_pos = s->mb_x + s->mb_y * s->mb_width;
 s->current_picture.mb_type[mb_pos] = 
MB_TYPE_INTRA;
 s->current_picture.qscale_table[mb_pos]= v->pq;
-s->current_picture.motion_val[1][s->block_index[0]][0] = 0;
-s->current_picture.motion_val[1][s->block_index[0]][1] = 0;
+for (int i = 0; i < 4; i++) {
+s->current_picture.motion_val[1][s->block_index[i]][0] = 0;
+s->current_picture.motion_val[1][s->block_index[i]][1] = 0;
+}
 
 // do actual MB decoding and displaying
 cbp = get_vlc2(&v->s.gb, ff_msmp4_mb_i_vlc.table, 
MB_INTRA_VLC_BITS, 2);
 v->s.ac_pred = get_bits1(&v->s.gb);
 
 for (k = 0; k < 6; k++) {
+v->mb_type[0][s->block_index[k]] = 1;
+
 val = ((cbp >> (5 - k)) & 1);
 
 if (k < 4) {
@@ -2570,52 +2568,30 @@ static void vc1_decode_i_blocks(VC1Context *v)
 }
 cbp |= val << (5 - k);
 
-vc1_decode_i_block(v, s->block[k], k, val, (k < 4) ? 
v->codingset : v->codingset2);
+vc1_decode_i_block(v, block[k], k, val, (k < 4) ? v->codingset 
: v->codingset2);
 
 if (CONFIG_GRAY && k > 3 && (s->avctx->flags & 
AV_CODEC_FLAG_GRAY))
 continue;
-v->vc1dsp.vc1_inv_trans_8x8(s->block[k]);
-if (v->pq >= 9 && v->overlap) {
-if (v->rangeredfrm)
+v->vc1dsp.vc1_inv_trans_8x8(block[k]);
+}
+
+if (v->overlap && v->pq >= 9) {
+ff_vc1_i_overlap_filter(v);
+if (v->rangeredfrm)
+for (k = 0; k < 6; k++)
 for (j = 0; j < 64; j++)
-s->block[k][j] <<= 1;
-s->idsp.put_signed_pixels_clamped(s->block[k], dst[k],
-  k & 4 ? s->uvlinesize
-: s->linesize);
-} else {
-if (v->rangeredfrm)
+block[k][j] <<= 1;
+vc1_put_blocks_clamped(v, 1);
+} else {
+if (v->rangeredfrm)
+for (k = 0; k < 6; k++)
 for (j = 0; j < 64; j++)
-s->block[k][j] = (s->block[k][j] - 64) << 1;
-s->idsp.put_pixels_clamped(s->block[k], dst[k],
-   k & 4 ? s->uvlinesize
- : s->linesize);
-}
+block[k][j] = (block[k][j] - 64) << 1;
+vc1_put_blocks_clamped(v, 0);
 }
 
-if (v->pq >= 9 && v->overlap) {
-if (s->mb_x) {
-v->vc1dsp.vc1_h_overlap(s->dest[0], s->linesize);
-v->vc1dsp.vc1_h_overlap(s->dest[0] + 8 * s->linesize, 
s->linesize);
-if (!CONFIG_GRAY || !(s->avctx->flags & 
AV_CODEC_FLAG_GRAY)) {
-v->vc1dsp.vc1_h_overlap(s->dest[1], s->uvlinesize);
-v->vc1dsp.vc1_h_overlap(s->dest[2], s->uvlinesize);
-}
-}
-v->vc1dsp.vc1_h_overlap(s->dest[0] + 8, s->linesize);
-v->vc1dsp.vc1_h_overlap(s->dest[0] + 8 * s->linesize + 8, 
s->linesize);
-if (!s->first_slice_line) {
-v->vc1dsp.vc1_v_overlap(s->dest[0], s->linesize);
-

[FFmpeg-devel] Fw: [PATCH] Refactor two near-identical clauses.

2018-06-12 Thread Shlomi Fish 
This message did not arrive to the list after three submissions.

Begin forwarded message:

Date: Tue, 12 Jun 2018 12:42:52 +0300
From: Shlomi Fish 
To: ffmpeg-devel@ffmpeg.org
Cc: Shlomi Fish 
Subject: [PATCH] Refactor two near-identical clauses.


Placed under the Expat licence . All tests pass.
---
 libavfilter/vf_weave.c | 33 ++---
 1 file changed, 14 insertions(+), 19 deletions(-)

diff --git a/libavfilter/vf_weave.c b/libavfilter/vf_weave.c
index 037f5d1cf2..be371201e1 100644
--- a/libavfilter/vf_weave.c
+++ b/libavfilter/vf_weave.c
@@ -23,6 +23,7 @@
 #include "libavutil/pixdesc.h"
 #include "avfilter.h"
 #include "internal.h"
+#include 
 
 typedef struct WeaveContext {
 const AVClass *class;
@@ -84,6 +85,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 AVFilterLink *outlink = ctx->outputs[0];
 AVFrame *out;
 int i;
+bool weave;
+int field1, field2;
 
 if (!s->prev) {
 s->prev = in;
@@ -98,26 +101,18 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 }
 av_frame_copy_props(out, in);
 
+weave = (s->double_weave && !(inlink->frame_count_out & 1));
+field1 = s->first_field * weave;
+field2 = s->first_field * !weave;
 for (i = 0; i < s->nb_planes; i++) {
-if (s->double_weave && !(inlink->frame_count_out & 1)) {
-av_image_copy_plane(out->data[i] + out->linesize[i] *
s->first_field,
-out->linesize[i] * 2,
-in->data[i], in->linesize[i],
-s->linesize[i], s->planeheight[i]);
-av_image_copy_plane(out->data[i] + out->linesize[i]
* !s->first_field,
-out->linesize[i] * 2,
-s->prev->data[i], s->prev->linesize[i],
-s->linesize[i], s->planeheight[i]);
-} else {
-av_image_copy_plane(out->data[i] + out->linesize[i]
* !s->first_field,
-out->linesize[i] * 2,
-in->data[i], in->linesize[i],
-s->linesize[i], s->planeheight[i]);
-av_image_copy_plane(out->data[i] + out->linesize[i] *
s->first_field,
-out->linesize[i] * 2,
-s->prev->data[i], s->prev->linesize[i],
-s->linesize[i], s->planeheight[i]);
-}
+av_image_copy_plane(out->data[i] + out->linesize[i] * field1,
+out->linesize[i] * 2,
+in->data[i], in->linesize[i],
+s->linesize[i], s->planeheight[i]);
+av_image_copy_plane(out->data[i] + out->linesize[i] * field2,
+out->linesize[i] * 2,
+s->prev->data[i], s->prev->linesize[i],
+s->linesize[i], s->planeheight[i]);
 }
 
 out->pts = s->double_weave ? s->prev->pts : in->pts / 2;
-- 
2.17.0


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

Re: [FFmpeg-devel] [PATCH] Refactor two near-identical clauses.

2018-06-12 Thread Shlomi Fish 
On Tue, 12 Jun 2018 12:53:20 +0300
Shlomi Fish  wrote:

> This message did not arrive to the list after three submissions.
> 

Just for the record, the patch can also be found here:

http://www.shlomifish.org/Files/files/code/0001-Refactor-two-near-identical-clauses.patch

> Begin forwarded message:
> 
> Date: Tue, 12 Jun 2018 12:42:52 +0300
> From: Shlomi Fish 
> To: ffmpeg-devel@ffmpeg.org
> Cc: Shlomi Fish 
> Subject: [PATCH] Refactor two near-identical clauses.
> 
> 
> Placed under the Expat licence . All tests pass.
> ---
>  libavfilter/vf_weave.c | 33 ++---
>  1 file changed, 14 insertions(+), 19 deletions(-)
> 
> diff --git a/libavfilter/vf_weave.c b/libavfilter/vf_weave.c
> index 037f5d1cf2..be371201e1 100644
> --- a/libavfilter/vf_weave.c
> +++ b/libavfilter/vf_weave.c
> @@ -23,6 +23,7 @@
>  #include "libavutil/pixdesc.h"
>  #include "avfilter.h"
>  #include "internal.h"
> +#include 
>  
>  typedef struct WeaveContext {
>  const AVClass *class;
> @@ -84,6 +85,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
>  AVFilterLink *outlink = ctx->outputs[0];
>  AVFrame *out;
>  int i;
> +bool weave;
> +int field1, field2;
>  
>  if (!s->prev) {
>  s->prev = in;
> @@ -98,26 +101,18 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *in) }
>  av_frame_copy_props(out, in);
>  
> +weave = (s->double_weave && !(inlink->frame_count_out & 1));
> +field1 = s->first_field * weave;
> +field2 = s->first_field * !weave;
>  for (i = 0; i < s->nb_planes; i++) {
> -if (s->double_weave && !(inlink->frame_count_out & 1)) {
> -av_image_copy_plane(out->data[i] + out->linesize[i] *
> s->first_field,
> -out->linesize[i] * 2,
> -in->data[i], in->linesize[i],
> -s->linesize[i], s->planeheight[i]);
> -av_image_copy_plane(out->data[i] + out->linesize[i]
> * !s->first_field,
> -out->linesize[i] * 2,
> -s->prev->data[i], s->prev->linesize[i],
> -s->linesize[i], s->planeheight[i]);
> -} else {
> -av_image_copy_plane(out->data[i] + out->linesize[i]
> * !s->first_field,
> -out->linesize[i] * 2,
> -in->data[i], in->linesize[i],
> -s->linesize[i], s->planeheight[i]);
> -av_image_copy_plane(out->data[i] + out->linesize[i] *
> s->first_field,
> -out->linesize[i] * 2,
> -s->prev->data[i], s->prev->linesize[i],
> -s->linesize[i], s->planeheight[i]);
> -}
> +av_image_copy_plane(out->data[i] + out->linesize[i] * field1,
> +out->linesize[i] * 2,
> +in->data[i], in->linesize[i],
> +s->linesize[i], s->planeheight[i]);
> +av_image_copy_plane(out->data[i] + out->linesize[i] * field2,
> +out->linesize[i] * 2,
> +s->prev->data[i], s->prev->linesize[i],
> +s->linesize[i], s->planeheight[i]);
>  }
>  
>  out->pts = s->double_weave ? s->prev->pts : in->pts / 2;



-- 
-
Shlomi Fish   http://www.shlomifish.org/
Freecell Solver - http://fc-solve.shlomifish.org/

A kid always wishes they were older until they are 18. Afterwards, they always
wish they were younger.

Please reply to list if it's a mailing list post - http://shlom.in/reply .
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat: remove unused MP4A_LATM flag

2018-06-12 Thread James Almer 
On 6/12/2018 5:33 AM, Gyan Doshi wrote:
> 
> 
> On 12-06-2018 01:39 PM, Hendrik Leppkes wrote:
> 
>> This flag is part of the public API, and eventhough it is entirely
>> unused, you cannot remove public API without a proper deprecation
>> period.
> 
> Ok, so looking at older flags, I need to
> 
> add a define to version.h, something like
> 
> #ifndef FF_API_LAVF_MP4A_LATM
> #define FF_API_LAVF_MP4A_LATM    (LIBAVFORMAT_VERSION_MAJOR < 59)
> #endif
> 
> and place the flag under guard in avformat.h
> 
> And place same guard in the options table.

Change the description of the option in this table into something like
"Deprecated, does nothing" while at it as well.

> 
> Is that correct?
> 
> I assume the other changes can be committed as-is.

Yes, that should do it.

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

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

Re: [FFmpeg-devel] [PATCH] smc: check for frame dimensions

2018-06-12 Thread Michael Niedermayer 
On Mon, Jun 11, 2018 at 08:01:56AM +, Xiao Yang wrote:
> sms: check for frame dimensions

>  smc.c |7 +++
>  1 file changed, 7 insertions(+)
> e029edfa5d1c3294879861bc785691759c8ab75c  
> 0001-smc-check-for-frame-dimensions.patch
> From 2ea1d0329ca80b5dea781dea7144cb58d16dc501 Mon Sep 17 00:00:00 2001
> From: Young 
> Date: Sun, 10 Jun 2018 11:55:56 +0800
> Subject: [PATCH] smc: check for frame dimensions
> 
> ---
>  libavcodec/smc.c |7 +++
>  1 file changed, 7 insertions(+)

this is unneeded and incorrect, smc can have odd dimensions


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.


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

Re: [FFmpeg-devel] [PATCH 09/12] avformat/mxfdec: add support for clip wrapped essences

2018-06-12 Thread Michael Niedermayer 
On Tue, Jun 12, 2018 at 10:47:24AM +0200, Marton Balint wrote:
> 
> 
> On Tue, 12 Jun 2018, Michael Niedermayer wrote:
> 
> >On Sun, Jun 10, 2018 at 12:36:47PM +0200, Marton Balint wrote:
> >>Also use common code with opAtom.
> >>
> >>Fixes ticket #2776.
> >>Partially fixes ticket #5671.
> >>Fixes ticket #5866.
> >>
> >>Signed-off-by: Marton Balint 
> >>---
> >> libavformat/mxfdec.c | 281 
> >> ---
> >> 1 file changed, 130 insertions(+), 151 deletions(-)
> >
> >causes a segfault:
> >
> >==23735== Invalid read of size 8
> >==23735==at 0x75A627: mxf_set_pts (mxfdec.c:3277)
> >==23735==by 0x75ACAD: mxf_read_packet_old (mxfdec.c:3396)
> >==23735==by 0x7E099D: ff_read_packet (utils.c:856)
> >==23735==by 0x7E39FF: read_frame_internal (utils.c:1581)
> >==23735==by 0x7EB82B: avformat_find_stream_info (utils.c:3773)
> >==23735==by 0x415534: open_input_file (ffmpeg_opt.c:1091)
> >==23735==by 0x41EB11: open_files (ffmpeg_opt.c:3206)
> >==23735==by 0x41ECA3: ffmpeg_parse_options (ffmpeg_opt.c:3246)
> >==23735==by 0x43D1A3: main (ffmpeg.c:4832)
> >==23735==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
> >==23735==
> >==23735==
> >==23735== Process terminating with default action of signal 11 (SIGSEGV)
> >==23735==  Access not within mapped region at address 0x0
> >==23735==at 0x75A627: mxf_set_pts (mxfdec.c:3277)
> >==23735==by 0x75ACAD: mxf_read_packet_old (mxfdec.c:3396)
> >==23735==by 0x7E099D: ff_read_packet (utils.c:856)
> >==23735==by 0x7E39FF: read_frame_internal (utils.c:1581)
> >==23735==by 0x7EB82B: avformat_find_stream_info (utils.c:3773)
> >==23735==by 0x415534: open_input_file (ffmpeg_opt.c:1091)
> >==23735==by 0x41EB11: open_files (ffmpeg_opt.c:3206)
> >==23735==by 0x41ECA3: ffmpeg_parse_options (ffmpeg_opt.c:3246)
> >==23735==by 0x43D1A3: main (ffmpeg.c:4832)
> >==23735==  If you believe this happened as a result of a stack
> >==23735==  overflow in your program's main thread (unlikely but
> >==23735==  possible), you can try to increase the size of the
> >==23735==  main thread stack using the --main-stacksize= flag.
> >==23735==  The main thread stack size used in this run was 8388608.
> 
> I don't see this. What is your command line?

testcase sent privatly

thx

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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


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

[FFmpeg-devel] [PATCH] msrle_decode_init: check frame dimensions

2018-06-12 Thread Xiao Yang 
---
 libavcodec/msrle.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavcodec/msrle.c b/libavcodec/msrle.c
index adb55b1..cd952a8 100644
--- a/libavcodec/msrle.c
+++ b/libavcodec/msrle.c
@@ -71,6 +71,13 @@ static av_cold int msrle_decode_init(AVCodecContext *avctx)
 return AVERROR_INVALIDDATA;
 }
 
+if (!avctx->width || !avctx->height ||
+(avctx->width & 1) || (avctx->height & 1)) {
+av_log(avctx, AV_LOG_ERROR, "Invalid video dimensions: %dx%d\n",
+   avctx->width, avctx->height);
+return AVERROR(EINVAL);
+}
+
 s->frame = av_frame_alloc();
 if (!s->frame)
 return AVERROR(ENOMEM);
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH] qtrle_decode_init: check frame dimensions

2018-06-12 Thread Xiao Yang 
---
 libavcodec/qtrle.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavcodec/qtrle.c b/libavcodec/qtrle.c
index 670690d..1cceeff 100644
--- a/libavcodec/qtrle.c
+++ b/libavcodec/qtrle.c
@@ -415,6 +415,13 @@ static av_cold int qtrle_decode_init(AVCodecContext *avctx)
 return AVERROR_INVALIDDATA;
 }
 
+if (!avctx->width || !avctx->height ||
+(avctx->width & 1) || (avctx->height & 1)) {
+av_log(avctx, AV_LOG_ERROR, "Invalid video dimensions: %dx%d\n",
+   avctx->width, avctx->height);
+return AVERROR(EINVAL);
+}
+
 s->frame = av_frame_alloc();
 if (!s->frame)
 return AVERROR(ENOMEM);
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH] cinvideo_decode_init: check frame dimensions

2018-06-12 Thread Xiao Yang 
---
 libavcodec/dsicinvideo.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavcodec/dsicinvideo.c b/libavcodec/dsicinvideo.c
index aa08041..d0f79d9 100644
--- a/libavcodec/dsicinvideo.c
+++ b/libavcodec/dsicinvideo.c
@@ -73,6 +73,13 @@ static av_cold int cinvideo_decode_init(AVCodecContext 
*avctx)
 cin->avctx = avctx;
 avctx->pix_fmt = AV_PIX_FMT_PAL8;
 
+if (!avctx->width || !avctx->height ||
+(avctx->width & 1) || (avctx->height & 1)) {
+av_log(avctx, AV_LOG_ERROR, "Invalid video dimensions: %dx%d\n",
+   avctx->width, avctx->height);
+return AVERROR(EINVAL);
+}
+
 cin->frame = av_frame_alloc();
 if (!cin->frame)
 return AVERROR(ENOMEM);
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH] msvideo1_decode_init: check frame dimensions

2018-06-12 Thread Xiao Yang 
---
 libavcodec/msvideo1.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavcodec/msvideo1.c b/libavcodec/msvideo1.c
index 29700f5..04c5ebb 100644
--- a/libavcodec/msvideo1.c
+++ b/libavcodec/msvideo1.c
@@ -73,6 +73,13 @@ static av_cold int msvideo1_decode_init(AVCodecContext 
*avctx)
 avctx->pix_fmt = AV_PIX_FMT_RGB555;
 }
 
+if (!avctx->width || !avctx->height ||
+(avctx->width & 1) || (avctx->height & 1)) {
+av_log(avctx, AV_LOG_ERROR, "Invalid video dimensions: %dx%d\n",
+   avctx->width, avctx->height);
+return AVERROR(EINVAL);
+}
+
 s->frame = av_frame_alloc();
 if (!s->frame)
 return AVERROR(ENOMEM);
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH] cinepak_decode_init: check frame dimensions

2018-06-12 Thread Xiao Yang 
---
 libavcodec/cinepak.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavcodec/cinepak.c b/libavcodec/cinepak.c
index 9b00774..3713ec0 100644
--- a/libavcodec/cinepak.c
+++ b/libavcodec/cinepak.c
@@ -430,6 +430,13 @@ static av_cold int cinepak_decode_init(AVCodecContext 
*avctx)
 avctx->pix_fmt = AV_PIX_FMT_PAL8;
 }
 
+if (!avctx->width || !avctx->height ||
+(avctx->width & 1) || (avctx->height & 1)) {
+av_log(avctx, AV_LOG_ERROR, "Invalid video dimensions: %dx%d\n",
+   avctx->width, avctx->height);
+return AVERROR(EINVAL);
+}
+
 s->frame = av_frame_alloc();
 if (!s->frame)
 return AVERROR(ENOMEM);
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH] Limited timecode support for lavd/decklink

2018-06-12 Thread Dave Rice 

> On Jun 7, 2018, at 5:01 PM, Marton Balint  wrote:
> 
> On Thu, 7 Jun 2018, Dave Rice wrote:
> 
> [...]
> 
>> 
>> Before I only tested with vitc but now have a serial cable connected as well 
>> and found a source tape that has distinct values for LTC and VITC timecodes. 
>> The LTC values are from 1:00:00 to 2:00:00 and the VITC values are from 
>> 07:00:00 - 08:00:00.
>> 
>> With the deckcontrol utility at https://github.com/bavc/deckcontrol 
>> , I can use the command gettimecode to 
>> grab the LTC value:
>> 
>> deckcontrol gettimecode
>> Issued command 'gettimecode'
>> TC=07:37:56:21
>> Command sucessfully issued
>> Error sending command (No error)
>> 
>> With these patches, I can only grab the vitc values:
>> 
>> for i in rp188vitc rp188vitc2 rp188ltc rp188any vitc vitc2 serial ; do echo 
>> -n "${i}: " ; ./ffprobe -v quiet -timecode_format "$i" -f decklink 
>> -draw_bars 0 -audio_input embedded -video_input sdi -format_code ntsc 
>> -channels 8 -raw_format yuv422p10 -i "UltraStudio Express" -select_streams v 
>> -show_entries stream_tags=timecode -of default=nw=1:nk=1 ; echo ; done
>> rp188vitc: rp188vitc2: rp188ltc: rp188any: vitc: 01:41:44;06
>> vitc2: 01:41:44;21
>> serial:
>> 
>> Also it may be interesting in cases like this to support accepting multiple 
>> timecode inputs at once, such as "-timecode_format vitc+rp188ltc” though it 
>> would need to be contextualized more in metadata.
>> 
>> With a serial cable connected, I can access LTC via the deckcontrol utility 
>> but not with this patch.
> 
> Well, the way I understand it, deckcontrol is using a totally different 
> timecode source: the RS422 deck control interface. In contrast, the
> timecode capture in the patch is using the SDI (video) source.
> 
> If the deck does not put the LTC timecode into SDI line 10, then the driver 
> won't be able to capture it if you specify 'rp188ltc'. I am not sure however 
> why 'serial' does not work, but from a quick look at the SDK maybe that only 
> works if you use the deck control capture functions…

I see at 
https://forum.blackmagicdesign.com/viewtopic.php?f=12&t=71730&p=400097&hilit=bmdTimecodeSerial#p400097
 

 that capturing bmdTimecodeSerial is an issue there too, so this is likely an 
issue with the sdk rather than with your patch. Otherwise I’ve been testing 
this more and find it really useful. Hope to see this merged.
Dave
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/movenc: fix recognization of cover image streams

2018-06-12 Thread Michael Niedermayer 
On Mon, Jun 04, 2018 at 05:36:19PM +0300, Timo Teräs wrote:
> For chapter images, the mov demux produces streams with disposition set
> to attached_pic+timed_thumbnails. This patch fixes to properly recognize
> streams that should be encoded as cover image (ones with only and only
> attached_pic disposition set).
> 
> Signed-off-by: Timo Teräs 
> ---
> > ffmpeg should act close to what a inteligent user expects.
> > For example a simple ffmpeg -i inputfile outputfile
> > should produce a outputfile that results in similar presentation as the 
> > input
> > when played.
> >...
> > It may be good to minimize the amount of exceptions for how streams are
> > handled.
> 
> Agree. My question was more about the details how the disposition flags
> should be handled, because there seems to be no accurate documentation.
> Apparently the logic is to handle based on what demuxers produce.
> 
> This patch addresses how the cover image is detected, and should restore
> earlier behaviour on copying files where demuxer supports more features
> than current muxer.
> 
> This applies on top of the "[v2] avformat/movenc: properly handle cover
> image codecs" patch. I can rebase the order if wanted, but it'll require
> little work.
> 
> Hopefully just the above mentioned patch, and this one could be applied
> in the order.

will apply the 2 patches

adding a fate test may make sense, the patches didnt change any so
its not tested

thx

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

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


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

[FFmpeg-devel] [PATCH] Improve dnn_backend_native convolution speed

2018-06-12 Thread Pedro Arthur 
The attached patch adds some specialized convolution functions based on the
filter size.

Benchmark (1190x670px image):
FilterNewOld  Diff (%)
9x9x1x64 |  3.093662   5.135679   39.76%
1x1x64x32|  0.912451   5.670451   83.90%
5x5x32x1 |  0.502857   0.787371   36.13%
Total|  4.5102311.595461.10%
From 3868e5f033c62b84d29a3592bb7997fa348c2e9c Mon Sep 17 00:00:00 2001
From: Pedro Arthur 
Date: Tue, 12 Jun 2018 17:47:05 -0300
Subject: [PATCH] Improve dnn_backend_native convolution speed

Changed memory layout from i x j x k (width, height, ch) to k x i x j
Added convolve function for 1x1xn filter case
Added convolve using 32x32 blocks of input
---
 libavfilter/dnn_backend_native.c | 212 ++-
 1 file changed, 181 insertions(+), 31 deletions(-)

diff --git a/libavfilter/dnn_backend_native.c b/libavfilter/dnn_backend_native.c
index 6e80dd3663..9f6b690a82 100644
--- a/libavfilter/dnn_backend_native.c
+++ b/libavfilter/dnn_backend_native.c
@@ -51,6 +51,187 @@ typedef struct ConvolutionalNetwork{
 int32_t layers_num;
 } ConvolutionalNetwork;
 
+#define VINDEX3(view, i, j, k) (view)->data[((view)->c * ((view)->w * (i) + (j)) + (k))]
+#define VINDEX2(view, i, j) (view)->data[((view)->w * (i) + (j))]
+#define VINDEX3A(view, i, j, k) (view)->data[((view)->w * ((view)->h * (k) + (i)) + (j))]
+#define CLAMP_TO_EDGE(x, w) ((x) < 0 ? 0 : ((x) >= (w) ? (w - 1) : (x)))
+
+typedef struct Tensor_view
+{
+float *data;
+int w, h, c;
+} Tensor_view;
+
+static void copy(Tensor_view *in, Tensor_view *buff, int size, int row, int col, int channel, int half)
+{
+int h = in->h;
+int w = in->w;
+
+for (int i = 0; i < size; ++i) {
+int line = CLAMP_TO_EDGE(row + i - half, h);
+for (int j = 0; j < size; ++j) {
+int column = CLAMP_TO_EDGE(col + j - half, w);
+VINDEX2(buff, i, j) = VINDEX3A(in, line, column, channel);
+}
+}
+}
+
+static void copy_relu(Tensor_view *in, Tensor_view *out, int row, int col, int ilen, int jlen, float bias)
+{
+for (int i = 0; i <= ilen; ++i) {
+for (int j = 0; j <= jlen; ++j) {
+VINDEX3A(out, row + i, col + j, 0) = FFMAX(VINDEX2(in, i, j) + bias, 0);
+}
+}
+}
+
+static void do_block(Tensor_view *in, Tensor_view *out, Tensor_view *kern, float bias, const int row, const int col, int w, int h, int fw)
+{
+float tmp[32 * 32];
+float tmp2[32 * 32];
+
+int half = fw / 2;
+int ilen = FFMIN(32 - fw, h - row - 1);
+int jlen = FFMIN(32 - fw, w - col - 1);
+
+Tensor_view buf = {tmp, 32, 32, 1};
+Tensor_view obuf = { tmp2, 32, 32, 1 };
+memset(tmp2, 0, sizeof(float) * 32 * 32);
+
+
+for (int k = 0; k < kern->c; ++k) {
+copy(in, &buf, 32, row, col, k, half);
+for (int ii = 0; ii <= ilen; ++ii) {
+for (int jj = 0; jj <= jlen; ++jj) {
+
+float acc = 0;
+for (int i = 0; i < fw; ++i) {
+for (int j = 0; j < fw; ++j) {
+acc += VINDEX2(&buf, ii + i, jj + j) * VINDEX3(kern, i, j, k);
+}
+}
+VINDEX2(&obuf, ii, jj) += acc;
+}
+}
+}
+copy_relu(&obuf, out, row, col, ilen, jlen, bias);
+}
+
+
+static void convolve_block_32(Tensor_view *in, Tensor_view *kernel, Tensor_view *out, float bias, int w, int h, int c, int fw)
+{
+int stride = 32 - fw + 1;
+for (int i = 0; i < h; i += stride) {
+for (int j = 0; j < w; j += stride) {
+do_block(in, out, kernel, bias, i, j, w, h, fw);
+}
+}
+}
+
+static void convolve_1x1(Tensor_view *in, Tensor_view *kernel, Tensor_view *out, float bias, int w, int h, int c, int fw)
+{
+if (c > 1) {
+for (int i = 0; i < h; ++i) {
+for (int j = 0; j < w; ++j) {
+VINDEX3A(out, i, j, 0) = VINDEX3A(in, i, j, 0) * kernel->data[0];
+}
+}
+}
+
+for (int k = 1; k < c-1; ++k) {
+for (int i = 0; i < h; ++i) {
+for (int j = 0; j < w; ++j) {
+VINDEX3A(out, i, j, 0) += VINDEX3A(in, i, j, k) * kernel->data[k];
+}
+}
+}
+
+for (int i = 0; i < h; ++i) {
+for (int j = 0; j < w; ++j) {
+VINDEX3A(out, i, j, 0) += VINDEX3A(in, i, j, c-1) * kernel->data[c-1];
+VINDEX3A(out, i, j, 0) = FFMAX(VINDEX3A(out, i, j, 0) + bias, 0);
+}
+}
+}
+
+static void convolve_generic(Tensor_view *in, Tensor_view *kernel, Tensor_view *out, float bias, int w, int h, int c, int fw)
+{
+int half = fw / 2;
+
+if (c > 1) {
+for (int i = 0; i < h; ++i) {
+for (int j = 0; j < w; ++j) {
+float acc = 0;
+for (int ii = 0; ii < fw; ++ii) {
+for (int jj = 0; jj < fw; ++jj) {
+int row = CLAMP_TO_EDGE(i + ii - half, h);
+int col =

Re: [FFmpeg-devel] qt-faststart bug near 4GB

2018-06-12 Thread Michael Niedermayer 
On Mon, Jun 11, 2018 at 12:05:20PM +, Eran Kornblau wrote:
> > On Sun, Jun 10, 2018 at 01:20:10PM +, Eran Kornblau wrote:
> > > > 
> > > > -Original Message-
> > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On 
> > > > Behalf Of Michael Niedermayer
> > > > Sent: Saturday, June 9, 2018 9:17 PM
> > > > To: FFmpeg development discussions and patches 
> > > > 
> > > > Subject: Re: [FFmpeg-devel] qt-faststart bug near 4GB
> > > > 
> > > > > +
> > > > > +if (atom.size < atom.header_size) {
> > > > 
> > > > > +printf("atom size %"PRIu64" too small\n", atom.size);
> > > > 
> > > > errors should go to stderr if av_log() is not used i see this is not 
> > > > introduced by the patch but was that way before so its more a comment 
> > > > about the code in git than the patch ...
> > > > but ideally this should be fixed in a seperate patch either before 
> > > > or after this one
> > > 
> > > I agree, had the same thought when I wrote the patch, but left it as it 
> > > was - only the usage error is printed to stderr.
> > > Will submit a patch for this after we finalize the discussion on this one.
> > > 
> > > > 
> > > > some self test for the newly added feature would also be a good idea
> > > 
> > > Since a real MP4 with this problem is going to be large (4GB), I'm 
> > > thinking about taking a small MP4, and patch some stco offset to 
> > > UINT_MAX. Naturally, it will break the file, but faststart won't care - 
> > > it should still upgrade the stco to co64, and we can just compare the 
> > > cksum/md5sum of the result to some fixed value.
> > > What do you think?
> > 
> > hmm, thats probably the most practical, yes
> > 
> > you could also simply compress the file a 4gb file thats 99.99% 0 bytes is 
> > not large but the problem would be that to test this it would need to be 
> > decompressed and the space requirements seems too problematic for fate 
> > clients
> > 
> Ok, took the 'fake offset' approach - created the attached mp4 with -
> ffmpeg -f lavfi -i anullsrc=sample_rate=48000 -t 1 faststart-4gb-overflow.mov
> python
> d = file('faststart-4gb-overflow.mov','rb').read()
> p = d.find('stco')
> d = d[:(p+12)] + '\xff' * 4 + d[(p+16):]
> file('faststart-4gb-overflow.mov','wb').write(d)
> 
> I added a fate test for this under 'mov' (that seemed the closest match...).
> For the faststart output, I'm using a temp file, I tried to avoid it with -
> qt-faststart input.mov >(md5sum -)
> But for some reason, this didn't work from 'make fate' (it did work in bash).
> Another option to avoid the temp file, is that I'll add support for passing 
> '-'
> as the qt-faststart output file name, and have it write to stdout. 
> Since all writes there are sequential (no seeks) it should be easy.
> Let me know what you prefer... anyway, current patch + sample file are 
> attached.
> 
> > 
> > > 
> > > Btw, the tests we ran on this change internally are - 1. compared the 
> > > result of the new version to the previous one on more than 1k files 
> > > (incl small files and large >4gb files) and verified the result was 
> > > exactly the same (the edge case this solves is extremely rare, and 
> > > "normal" files are not expected to change) 2. checked the specific file 
> > > that had this issue, and verified it was fixed.
> > > 
> > > > 
> > 
> > > > also, was the new code tested with a fuzzer ?
> > > 
> > > No, can you provide some guidance on this - is there some fuzzing 
> > > framework that you're using?
> > 
> > hmm, you can probably add qt-faststart to:
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Foss-fuzz%2Ftree%2Fmaster%2Fprojects%2Fffmpeg&data=02%7C01%7Ceran.kornblau%40kaltura.com%7C439d2ebbc07940dc5cda08d5cf345a9b%7C0c503748de3f4e2597e26819d53a42b6%7C0%7C0%7C636642746144001154&sdata=8N9HpfHJ6atTGmtwHmr0Vuccw39W7RzMM%2BLw%2F4Ptj0g%3D&reserved=0
> > 
> > this is probably a bit effort though.
> > 
> > using some arbitrary choosen fuzzer, AFL, zzuf or anything else is probably 
> > simpler. adding it to oss-fuzz has the advantage that google will in the 
> > future automatically do the fuzzing for qt-faststart in ffmpeg.
> > to add it to oss-fuzz you probably would have to submit changes both to the 
> > oss-fuzz ffmpeg repo as well as to ffmpeg ...
> > 
> Is this mandatory? :) it may be because I'm not familiar with these 
> frameworks, but indeed sounds like 
> a significant effort to do it...
> 
> > thx
> > 
> > [...]
> > -- 
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> > 
> > It is what and why we do it that matters, not just one of them.
> > 
> 
> Thanks!
> 
> Eran

>  Makefile |4 +++-
>  fate/mov.mak |9 -
>  2 files changed, 11 insertions(+), 2 deletions(-)
> a5668223451eb818958fa6943af0a50bf5c11a70  
> 0001-qt-faststart-add-fate-test-for-stco-overflow.patch
> From 2ae7cf2839f9bc36cc762da581d16e3eb3adaaec Mon Sep 17 00:00:00 2001
> From: erankor 
> Date: Mon, 11 Ju

[FFmpeg-devel] [PATCH] avformat/mov: Add check for per-sample IV size.

2018-06-12 Thread Jacob Trimble 
Found by Chrome's ClusterFuzz: http://crbug.com/849062.

Signed-off-by: Jacob Trimble 
---
 libavformat/mov.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2fca025889..5d9ffa69a3 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6273,8 +6273,13 @@ static int mov_read_tenc(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 return AVERROR(ENOMEM);
 }
 sc->cenc.per_sample_iv_size = avio_r8(pb);
+if (sc->cenc.per_sample_iv_size != 0 && sc->cenc.per_sample_iv_size != 8 &&
+sc->cenc.per_sample_iv_size != 16) {
+av_log(c->fc, AV_LOG_ERROR, "invalid per-sample IV size value\n");
+return AVERROR_INVALIDDATA;
+}
 if (avio_read(pb, sc->cenc.default_encrypted_sample->key_id, 16) != 16) {
-av_log(c->fc, AV_LOG_ERROR, "failed to read the default key ID");
+av_log(c->fc, AV_LOG_ERROR, "failed to read the default key ID\n");
 return AVERROR_INVALIDDATA;
 }
 
@@ -6286,7 +6291,7 @@ static int mov_read_tenc(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 }
 
 if (avio_read(pb, sc->cenc.default_encrypted_sample->iv, iv_size) != 
iv_size) {
-av_log(c->fc, AV_LOG_ERROR, "failed to read the default IV");
+av_log(c->fc, AV_LOG_ERROR, "failed to read the default IV\n");
 return AVERROR_INVALIDDATA;
 }
 }
-- 
2.18.0.rc1.242.g61856ae69a-goog

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

[FFmpeg-devel] [PATCH v2] avcodec/mediacodecdec: work around for decoding h264 with coded fields

2018-06-12 Thread Aman Gupta 
From: Aman Gupta 

This is a hacky work-around for #7092, where the lavc h264
parser splits coded fields into separate video packets, only one
of which has a PTS set.

The MediaCodec#queueInputBuffer API expects a PTS along with
incoming video packets, and breaks badly when the PTS is missing
or incorrect (previously it would be passed in as AV_NOPTS_VALUE,
but the same breakage happens if you pass in 0 instead).

Since it seems there's no easy fix for #7092, this patch stores
the previous PTS in the decoder context and re-uses it for the
second packet. This emulates the behavior of other Android video
players that don't split the coded fields, and pass them as a single
buffer with the same timestamp.

Signed-off-by: Aman Gupta 
---
 libavcodec/mediacodecdec_common.c | 9 +
 libavcodec/mediacodecdec_common.h | 2 ++
 2 files changed, 11 insertions(+)

diff --git a/libavcodec/mediacodecdec_common.c 
b/libavcodec/mediacodecdec_common.c
index 40a2ee6778..80cbb7afbd 100644
--- a/libavcodec/mediacodecdec_common.c
+++ b/libavcodec/mediacodecdec_common.c
@@ -448,6 +448,7 @@ static int mediacodec_dec_flush_codec(AVCodecContext 
*avctx, MediaCodecDecContex
 s->eos = 0;
 atomic_fetch_add(&s->serial, 1);
 atomic_init(&s->hw_buffer_count, 0);
+s->last_pts = AV_NOPTS_VALUE;
 s->current_input_buffer = -1;
 
 status = ff_AMediaCodec_flush(codec);
@@ -476,6 +477,7 @@ int ff_mediacodec_dec_init(AVCodecContext *avctx, 
MediaCodecDecContext *s,
 atomic_init(&s->refcount, 1);
 atomic_init(&s->hw_buffer_count, 0);
 atomic_init(&s->serial, 1);
+s->last_pts = AV_NOPTS_VALUE;
 s->current_input_buffer = -1;
 
 pix_fmt = ff_get_format(avctx, pix_fmts);
@@ -609,6 +611,13 @@ int ff_mediacodec_dec_send(AVCodecContext *avctx, 
MediaCodecDecContext *s,
 }
 
 pts = pkt->pts;
+if (pts == AV_NOPTS_VALUE && s->last_pts != AV_NOPTS_VALUE) {
+pts = s->last_pts;
+} else if (pts == AV_NOPTS_VALUE) {
+av_log(avctx, AV_LOG_WARNING, "Packet is missing PTS!\n");
+pts = 0;
+}
+s->last_pts = pkt->pts;
 if (pts != AV_NOPTS_VALUE && avctx->pkt_timebase.num && 
avctx->pkt_timebase.den) {
 pts = av_rescale_q(pts, avctx->pkt_timebase, AV_TIME_BASE_Q);
 }
diff --git a/libavcodec/mediacodecdec_common.h 
b/libavcodec/mediacodecdec_common.h
index d280236b8e..9f22006e12 100644
--- a/libavcodec/mediacodecdec_common.h
+++ b/libavcodec/mediacodecdec_common.h
@@ -69,6 +69,8 @@ typedef struct MediaCodecDecContext {
 bool delay_flush;
 atomic_int serial;
 
+int64_t last_pts;
+
 } MediaCodecDecContext;
 
 int ff_mediacodec_dec_init(AVCodecContext *avctx,
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH] seqvideo_decode_init:check frame dimensions

2018-06-12 Thread Michael Niedermayer 
On Mon, Jun 11, 2018 at 07:07:36AM +, Xiao Yang wrote:
> ---
>  libavcodec/tiertexseqv.c |7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/libavcodec/tiertexseqv.c b/libavcodec/tiertexseqv.c
> index af39f74..2d0fa98 100644
> --- a/libavcodec/tiertexseqv.c
> +++ b/libavcodec/tiertexseqv.c
> @@ -222,6 +222,13 @@ static av_cold int seqvideo_decode_init(AVCodecContext 
> *avctx)
>  if (ret < 0)
>  return ret;
>  
> +if (!avctx->width || !avctx->height ||
> +(avctx->width & 1) || (avctx->height & 1)) {
> +av_log(avctx, AV_LOG_ERROR, "Invalid video dimensions: %dx%d\n",
> +   avctx->width, avctx->height);
> +return AVERROR(EINVAL);
> +}

this makes no sense, 4 lines above the width and height is hardcoded to
256 x 128, this is neither 0 nor odd


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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

Re: [FFmpeg-devel] [PATCH 09/12] avformat/mxfdec: add support for clip wrapped essences

2018-06-12 Thread Marton Balint 



On Tue, 12 Jun 2018, Michael Niedermayer wrote:


On Tue, Jun 12, 2018 at 10:47:24AM +0200, Marton Balint wrote:



On Tue, 12 Jun 2018, Michael Niedermayer wrote:


On Sun, Jun 10, 2018 at 12:36:47PM +0200, Marton Balint wrote:

Also use common code with opAtom.

Fixes ticket #2776.
Partially fixes ticket #5671.
Fixes ticket #5866.

Signed-off-by: Marton Balint 
---
libavformat/mxfdec.c | 281 ---
1 file changed, 130 insertions(+), 151 deletions(-)


causes a segfault:

==23735== Invalid read of size 8
==23735==at 0x75A627: mxf_set_pts (mxfdec.c:3277)
==23735==by 0x75ACAD: mxf_read_packet_old (mxfdec.c:3396)
==23735==by 0x7E099D: ff_read_packet (utils.c:856)
==23735==by 0x7E39FF: read_frame_internal (utils.c:1581)
==23735==by 0x7EB82B: avformat_find_stream_info (utils.c:3773)
==23735==by 0x415534: open_input_file (ffmpeg_opt.c:1091)
==23735==by 0x41EB11: open_files (ffmpeg_opt.c:3206)
==23735==by 0x41ECA3: ffmpeg_parse_options (ffmpeg_opt.c:3246)
==23735==by 0x43D1A3: main (ffmpeg.c:4832)
==23735==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==23735==
==23735==
==23735== Process terminating with default action of signal 11 (SIGSEGV)
==23735==  Access not within mapped region at address 0x0
==23735==at 0x75A627: mxf_set_pts (mxfdec.c:3277)
==23735==by 0x75ACAD: mxf_read_packet_old (mxfdec.c:3396)
==23735==by 0x7E099D: ff_read_packet (utils.c:856)
==23735==by 0x7E39FF: read_frame_internal (utils.c:1581)
==23735==by 0x7EB82B: avformat_find_stream_info (utils.c:3773)
==23735==by 0x415534: open_input_file (ffmpeg_opt.c:1091)
==23735==by 0x41EB11: open_files (ffmpeg_opt.c:3206)
==23735==by 0x41ECA3: ffmpeg_parse_options (ffmpeg_opt.c:3246)
==23735==by 0x43D1A3: main (ffmpeg.c:4832)
==23735==  If you believe this happened as a result of a stack
==23735==  overflow in your program's main thread (unlikely but
==23735==  possible), you can try to increase the size of the
==23735==  main thread stack using the --main-stacksize= flag.
==23735==  The main thread stack size used in this run was 8388608.


I don't see this. What is your command line?


testcase sent privatly


index_table->nb_ptses was negative, but that did not cause problems before 
the patch, because the comparison to nb_ptses was signed, after the patch 
it became unsigned.


It is better to explicitly disallow a negative nb_ptses, please apply the 
attached patch before this one, you should be good.


Thanks,
MartonFrom c3f9e8442fe66f474466d769f44f782532eacb82 Mon Sep 17 00:00:00 2001
From: Marton Balint 
Date: Tue, 12 Jun 2018 23:42:16 +0200
Subject: [PATCH] avformat/mxfdec: avoid index_table->nb_ptses overflow in
 mxf_compute_ptses_fake_index

Signed-off-by: Marton Balint 
---
 libavformat/mxfdec.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 32ca9e0f99..b2930087ab 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1528,6 +1528,12 @@ static int mxf_compute_ptses_fake_index(MXFContext *mxf, MXFIndexTable *index_ta
 return 0;   /* no TemporalOffsets */
 }
 
+if (s->index_duration > INT_MAX - index_table->nb_ptses) {
+index_table->nb_ptses = 0;
+av_log(mxf->fc, AV_LOG_ERROR, "ignoring IndexSID %d, duration is too large\n", s->index_sid);
+return 0;
+}
+
 index_table->nb_ptses += s->index_duration;
 }
 
-- 
2.16.4

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

Re: [FFmpeg-devel] [PATCH] avformat/mpegts: parse large PMTs with multiple tables

2018-06-12 Thread Michael Niedermayer 
On Mon, Jun 11, 2018 at 12:43:31AM -0700, Aman Gupta wrote:
> From: Aman Gupta 
> 
> In 9152c1e4955, the mpegts parser was taught how to parse
> PMT sections which contained multiple tables. That commit
> fixed parsing of PMT packets from some cable providers,
> which included a special SCTE table (0xc0) before the
> standard program map table (0x2).
> 
> Sometimes, however, the combined 0xc0 and 0x2 tables are
> larger than a single TS packet (188 bytes). The mpegts parser
> already attempts to parse sections which span multiple packets,
> but still assumed that the split section only contained one
> table.
> 
> This patch fixes parsing of such a sample[1].
> 
> Before:
> 
> Input #0, mpegts, from 'combined-pmt-tids-split.ts':
>   Duration: 00:00:01.26, start: 39188.931756, bitrate: 597 kb/s
>   Program 1
>   No Program
> Stream #0:0[0xeff]: Audio: ac3, 48000 Hz, mono, fltp, 64 kb/s
> Stream #0:1[0xefd]: Audio: mp3, 0 channels, fltp
> Stream #0:2[0xefe]: Unknown: none
> 
> After:
> 
> Input #0, mpegts, from 'combined-pmt-tids-split.ts':
>   Duration: 00:00:01.27, start: 39188.931756, bitrate: 589 kb/s
>   Program 1
> Stream #0:0[0xefd]: Video: h264 ([27][0][0][0] / 0x001B), none, 59.94 
> fps, 59.94 tbr, 90k tbn, 180k tbc
> Stream #0:1[0xefe](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 
> Hz, stereo, fltp, 384 kb/s
> Stream #0:2[0xeff](spa): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 
> Hz, mono, fltp, 64 kb/s
> Stream #0:3[0xf00]: Data: scte_35
> Stream #0:4[0xf01]: Unknown: none (ETV1 / 0x31565445)
> Stream #0:5[0xf02]: Unknown: none (ETV1 / 0x31565445)
> Stream #0:6[0xf03]: Unknown: none ([192][0][0][0] / 0x00C0)
> 
> With the patch, the PMT is parsed correctly so the streams are
> created in the correct order, are associated with "Program 1",
> and their codecs are set correctly.
> 
> [1] https://s3.amazonaws.com/tmm1/combined-pmt-tids-split.ts
> 
> Signed-off-by: Aman Gupta 
> ---
>  libavformat/mpegts.c | 1 +
>  1 file changed, 1 insertion(+)

with this change section_h_size becomes almost a local variable
is that intended ?

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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

Re: [FFmpeg-devel] [PATCH] Limited timecode support for lavd/decklink

2018-06-12 Thread Marton Balint 



On Tue, 12 Jun 2018, Dave Rice wrote:




On Jun 7, 2018, at 5:01 PM, Marton Balint  wrote:

On Thu, 7 Jun 2018, Dave Rice wrote:

[...]



Before I only tested with vitc but now have a serial cable connected as well 
and found a source tape that has distinct values for LTC and VITC timecodes. 
The LTC values are from 1:00:00 to 2:00:00 and the VITC values are from 
07:00:00 - 08:00:00.

With the deckcontrol utility at https://github.com/bavc/deckcontrol 
, I can use the command gettimecode to 
grab the LTC value:

deckcontrol gettimecode
Issued command 'gettimecode'
TC=07:37:56:21
Command sucessfully issued
Error sending command (No error)

With these patches, I can only grab the vitc values:

for i in rp188vitc rp188vitc2 rp188ltc rp188any vitc vitc2 serial ; do echo -n "${i}: " ; ./ffprobe 
-v quiet -timecode_format "$i" -f decklink -draw_bars 0 -audio_input embedded -video_input sdi 
-format_code ntsc -channels 8 -raw_format yuv422p10 -i "UltraStudio Express" -select_streams v 
-show_entries stream_tags=timecode -of default=nw=1:nk=1 ; echo ; done
rp188vitc: rp188vitc2: rp188ltc: rp188any: vitc: 01:41:44;06
vitc2: 01:41:44;21
serial:

Also it may be interesting in cases like this to support accepting multiple timecode 
inputs at once, such as "-timecode_format vitc+rp188ltc” though it would need 
to be contextualized more in metadata.

With a serial cable connected, I can access LTC via the deckcontrol utility but 
not with this patch.


Well, the way I understand it, deckcontrol is using a totally different 
timecode source: the RS422 deck control interface. In contrast, the
timecode capture in the patch is using the SDI (video) source.

If the deck does not put the LTC timecode into SDI line 10, then the driver 
won't be able to capture it if you specify 'rp188ltc'. I am not sure however 
why 'serial' does not work, but from a quick look at the SDK maybe that only 
works if you use the deck control capture functions…




I see at 
https://forum.blackmagicdesign.com/viewtopic.php?f=12&t=71730&p=400097&hilit=bmdTimecodeSerial#p400097 
 
that capturing bmdTimecodeSerial is an issue there too, so this is 
likely an issue with the sdk rather than with your patch. Otherwise I’ve 
been testing this more and find it really useful. Hope to see this 
merged.


Pushed, thanks for testing.

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

Re: [FFmpeg-devel] [PATCH 1/2] avdevice/decklink_dec: use a custom memory allocator

2018-06-12 Thread Marton Balint 



On Tue, 5 Jun 2018, Dave Rice wrote:




On Jun 5, 2018, at 1:17 PM, Marton Balint  wrote:

On Tue, 5 Jun 2018, Dave Rice wrote:


On Jun 4, 2018, at 4:21 PM, Marton Balint  wrote:

The default memory allocator is limited in the max number of frames available,
and therefore caused frame drops if the frames were not freed fast enough.


I’ve been testing this patchset today. Yesterday I was occasionally getting 
“Decklink input buffer overrun!” errors with this command:

/usr/local/opt/ffmpegdecklink/bin/ffmpeg-dl -v info -nostdin -nostats -t 1980 -f decklink -draw_bars 0 -audio_input embedded 
-video_input sdi -format_code ntsc -channels 8 -raw_format yuv422p10 -i "UltraStudio Express" -metadata:s:v:0 
encoder="FFV1 version 3" -color_primaries smpte170m -color_trc bt709 -colorspace smpte170m -color_range mpeg -metadata 
creation_time=now -f_strict unofficial -c:v ffv1 -level 3 -g 1 -slices 16 -slicecrc 1 -c:a pcm_s24le -filter_complex 
"[0:v:0]setfield=bff,setsar=40/27,setdar=4/3; [0:a:0]pan=stereo| c0=c0 | c1=c1[stereo1];[0:a:0]pan=stereo| c0=c2 | 
c1=c3[stereo2]" -map "[stereo1]" -map "[stereo2]" -f matroska output.mkv -an -f framemd5 output.framemd5

With the patchset applied, I haven’t had that buffer overrun error re-occur.


That is very strange, it should work the opposite way. Without the patch, the 
decklink driver is dropping frames (silently), so you should never get a 
Decklink input buffer overrun error message, but silent frame drops instead if 
you don't release (transcode) the frames fast enough.

With the patch, you won't get silent frame drops, but you might fill the 
internal queue and therefore get Decklink input buffer overruns. On the other 
hand, if you get Decklink input buffer overruns, that typically means that your 
computer is too slow to handle transcoding in real time…


Trying to detect unreported dropped frames is why I added the framemd5 output 
as a second output. After the command runs, I would use this command

grep -v "^#” output.framemd5 | awk -F',' '$2!=p+1{printf p+1"-"$2-1" "}{p=$2}'

to report the ranges of pts that weren’t incrementing the pts by 1 within the 
pts. I had presumed that getting a gap in the pts within the framemd5 was 
corresponding with the buffer overrun error in the terminal output. I’ve tested 
a few hours of recorded with your patch applied and haven’t gotten any pts 
discontinuity in the framemd5s yet.


Pushed the series.

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

Re: [FFmpeg-devel] qt-faststart bug near 4GB

2018-06-12 Thread Michael Niedermayer 
On Mon, Jun 11, 2018 at 12:05:20PM +, Eran Kornblau wrote:
> > On Sun, Jun 10, 2018 at 01:20:10PM +, Eran Kornblau wrote:
> > > > 
> > > > -Original Message-
> > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On 
> > > > Behalf Of Michael Niedermayer
> > > > Sent: Saturday, June 9, 2018 9:17 PM
> > > > To: FFmpeg development discussions and patches 
> > > > 
> > > > Subject: Re: [FFmpeg-devel] qt-faststart bug near 4GB
> > > > 
> > > > > +
> > > > > +if (atom.size < atom.header_size) {
> > > > 
> > > > > +printf("atom size %"PRIu64" too small\n", atom.size);
> > > > 
> > > > errors should go to stderr if av_log() is not used i see this is not 
> > > > introduced by the patch but was that way before so its more a comment 
> > > > about the code in git than the patch ...
> > > > but ideally this should be fixed in a seperate patch either before 
> > > > or after this one
> > > 
> > > I agree, had the same thought when I wrote the patch, but left it as it 
> > > was - only the usage error is printed to stderr.
> > > Will submit a patch for this after we finalize the discussion on this one.
> > > 
> > > > 
> > > > some self test for the newly added feature would also be a good idea
> > > 
> > > Since a real MP4 with this problem is going to be large (4GB), I'm 
> > > thinking about taking a small MP4, and patch some stco offset to 
> > > UINT_MAX. Naturally, it will break the file, but faststart won't care - 
> > > it should still upgrade the stco to co64, and we can just compare the 
> > > cksum/md5sum of the result to some fixed value.
> > > What do you think?
> > 
> > hmm, thats probably the most practical, yes
> > 
> > you could also simply compress the file a 4gb file thats 99.99% 0 bytes is 
> > not large but the problem would be that to test this it would need to be 
> > decompressed and the space requirements seems too problematic for fate 
> > clients
> > 
> Ok, took the 'fake offset' approach - created the attached mp4 with -
> ffmpeg -f lavfi -i anullsrc=sample_rate=48000 -t 1 faststart-4gb-overflow.mov
> python
> d = file('faststart-4gb-overflow.mov','rb').read()
> p = d.find('stco')
> d = d[:(p+12)] + '\xff' * 4 + d[(p+16):]
> file('faststart-4gb-overflow.mov','wb').write(d)
> 
> I added a fate test for this under 'mov' (that seemed the closest match...).
> For the faststart output, I'm using a temp file, I tried to avoid it with -
> qt-faststart input.mov >(md5sum -)
> But for some reason, this didn't work from 'make fate' (it did work in bash).
> Another option to avoid the temp file, is that I'll add support for passing 
> '-'
> as the qt-faststart output file name, and have it write to stdout. 
> Since all writes there are sequential (no seeks) it should be easy.
> Let me know what you prefer... anyway, current patch + sample file are 
> attached.
> 
> > 
> > > 
> > > Btw, the tests we ran on this change internally are - 1. compared the 
> > > result of the new version to the previous one on more than 1k files 
> > > (incl small files and large >4gb files) and verified the result was 
> > > exactly the same (the edge case this solves is extremely rare, and 
> > > "normal" files are not expected to change) 2. checked the specific file 
> > > that had this issue, and verified it was fixed.
> > > 
> > > > 
> > 
> > > > also, was the new code tested with a fuzzer ?
> > > 
> > > No, can you provide some guidance on this - is there some fuzzing 
> > > framework that you're using?
> > 
> > hmm, you can probably add qt-faststart to:
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Foss-fuzz%2Ftree%2Fmaster%2Fprojects%2Fffmpeg&data=02%7C01%7Ceran.kornblau%40kaltura.com%7C439d2ebbc07940dc5cda08d5cf345a9b%7C0c503748de3f4e2597e26819d53a42b6%7C0%7C0%7C636642746144001154&sdata=8N9HpfHJ6atTGmtwHmr0Vuccw39W7RzMM%2BLw%2F4Ptj0g%3D&reserved=0
> > 
> > this is probably a bit effort though.
> > 
> > using some arbitrary choosen fuzzer, AFL, zzuf or anything else is probably 
> > simpler. adding it to oss-fuzz has the advantage that google will in the 
> > future automatically do the fuzzing for qt-faststart in ffmpeg.
> > to add it to oss-fuzz you probably would have to submit changes both to the 
> > oss-fuzz ffmpeg repo as well as to ffmpeg ...
> > 
> Is this mandatory? :) it may be because I'm not familiar with these 
> frameworks, but indeed sounds like 
> a significant effort to do it...

this is not mandatory but trying with some basic fuzzer seems like a good idea
look at the examples in the manpage of zzuf for example, its very easy to use

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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

Re: [FFmpeg-devel] [PATCH] cinepak_decode_init: check frame dimensions

2018-06-12 Thread Michael Niedermayer 
Hi

first please make sure you are subscribed to ffmpeg-devel if you want to
submit patches. submited patches are discussed on the ffmpeg-devel
mailing list almost always. People rarely think of CC-ing the author

then 2nd you should make sure you confirm both the bug you
are trying to fix as well as the fix with ffmpeg git master

is ffmpeg git master really affected by any of the bugs you are trying to fix?

also it is neccessary for you to understand the format you
are changing
and run tests to confirm that you are not breaking something.

The changes you are posting which i looked at so far are basically wrong.

we have cinepak files with odd resolutions even in the fate tests for example

[...]
-- 
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
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavfilter/opencl.h: Add macro for setting opencl kernel

2018-06-12 Thread Song, Ruiling 


> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Danil Iashchenko
> Sent: Tuesday, June 12, 2018 5:39 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Danil Iashchenko 
> Subject: [FFmpeg-devel] [PATCH] libavfilter/opencl.h: Add macro for setting
> opencl kernel
> 
> ---
>  libavfilter/opencl.h| 15 ++
>  libavfilter/vf_convolution_opencl.c | 43 
>  libavfilter/vf_overlay_opencl.c | 44 +++-
>  libavfilter/vf_unsharp_opencl.c | 57 
> ++---
>  4 files changed, 46 insertions(+), 113 deletions(-)
> 
> diff --git a/libavfilter/opencl.h b/libavfilter/opencl.h
> index c0a4519..7441b11 100644
> --- a/libavfilter/opencl.h
> +++ b/libavfilter/opencl.h
> @@ -46,6 +46,21 @@ typedef struct OpenCLFilterContext {
>  intoutput_height;
>  } OpenCLFilterContext;
> 
> +
> +/**
> + * set argument to specific Kernel.
> + * This macro relies on usage of local label "fail" and variables:
> + * avctx, cle and err.
> + */
> +#define CL_SET_KERNEL_ARG(kernel, arg_num, type, arg)  \
> +cle = clSetKernelArg(kernel, arg_num, sizeof(type), arg);  \
> +if (cle != CL_SUCCESS) {   \
> +av_log(avctx, AV_LOG_ERROR, "Failed to set kernel "\
> +   "argument %d: error %d.\n", arg_num, cle);  \
> +err = AVERROR(EIO);\
> +goto fail; \
> +}

> -if (cle != CL_SUCCESS)
> -goto fail_kernel_arg;
> +CL_SET_KERNEL_ARG(ctx->kernel, kernel_arg, cl_int, &alpha_adj_x);
> +kernel_arg++;
> +CL_SET_KERNEL_ARG(ctx->kernel, kernel_arg, cl_int, &alpha_adj_y);
> +kernel_arg++;
>  }
Hi Danil,

I think about this for some while. Instead of totally wrap the clSetKernelArg() 
together with the error handling.
I would rather provide a simple macro for OpenCL error handling, which may not 
reduce code complexity as much as this patch.
But people can still use clSetKernelArg(kernel, argIdx++,...) without 
explicitly separate the self-increment to a new line.
And also an dedicated OpenCL macro for error handling could benefit other 
OpenCL functions like clFinish() or clEnqueueNDRange() etc.
So I post a patch as: "[PATCH] lavfi: add helper macro for OpenCL error 
handling." Welcome your comment!

Ruiling
 

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

Re: [FFmpeg-devel] [PATCH] avformat/mpegts: parse large PMTs with multiple tables

2018-06-12 Thread Aman Gupta 
On Tue, Jun 12, 2018 at 3:17 PM Michael Niedermayer 
wrote:

> On Mon, Jun 11, 2018 at 12:43:31AM -0700, Aman Gupta wrote:
> > From: Aman Gupta 
> >
> > In 9152c1e4955, the mpegts parser was taught how to parse
> > PMT sections which contained multiple tables. That commit
> > fixed parsing of PMT packets from some cable providers,
> > which included a special SCTE table (0xc0) before the
> > standard program map table (0x2).
> >
> > Sometimes, however, the combined 0xc0 and 0x2 tables are
> > larger than a single TS packet (188 bytes). The mpegts parser
> > already attempts to parse sections which span multiple packets,
> > but still assumed that the split section only contained one
> > table.
> >
> > This patch fixes parsing of such a sample[1].
> >
> > Before:
> >
> > Input #0, mpegts, from 'combined-pmt-tids-split.ts':
> >   Duration: 00:00:01.26, start: 39188.931756, bitrate: 597 kb/s
> >   Program 1
> >   No Program
> > Stream #0:0[0xeff]: Audio: ac3, 48000 Hz, mono, fltp, 64 kb/s
> > Stream #0:1[0xefd]: Audio: mp3, 0 channels, fltp
> > Stream #0:2[0xefe]: Unknown: none
> >
> > After:
> >
> > Input #0, mpegts, from 'combined-pmt-tids-split.ts':
> >   Duration: 00:00:01.27, start: 39188.931756, bitrate: 589 kb/s
> >   Program 1
> > Stream #0:0[0xefd]: Video: h264 ([27][0][0][0] / 0x001B), none,
> 59.94 fps, 59.94 tbr, 90k tbn, 180k tbc
> > Stream #0:1[0xefe](eng): Audio: ac3 ([129][0][0][0] / 0x0081),
> 48000 Hz, stereo, fltp, 384 kb/s
> > Stream #0:2[0xeff](spa): Audio: ac3 ([129][0][0][0] / 0x0081),
> 48000 Hz, mono, fltp, 64 kb/s
> > Stream #0:3[0xf00]: Data: scte_35
> > Stream #0:4[0xf01]: Unknown: none (ETV1 / 0x31565445)
> > Stream #0:5[0xf02]: Unknown: none (ETV1 / 0x31565445)
> > Stream #0:6[0xf03]: Unknown: none ([192][0][0][0] / 0x00C0)
> >
> > With the patch, the PMT is parsed correctly so the streams are
> > created in the correct order, are associated with "Program 1",
> > and their codecs are set correctly.
> >
> > [1] https://s3.amazonaws.com/tmm1/combined-pmt-tids-split.ts
> >
> > Signed-off-by: Aman Gupta 
> > ---
> >  libavformat/mpegts.c | 1 +
> >  1 file changed, 1 insertion(+)
>
> with this change section_h_size becomes almost a local variable
> is that intended ?


Yes that is the intended behavior. Previously the size was cached as an
optimization, but that assumed that there was only one size value per
section (whereas these sections have multiple tables and thus multiple
sizes).

I will follow up with a refactor to turn it into a local variable and
remove the field from the struct.

Aman


>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The worst form of inequality is to try to make unequal things equal.
> -- Aristotle
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat: remove unused MP4A_LATM flag

2018-06-12 Thread Gyan Doshi 



On 12-06-2018 11:00 PM, James Almer wrote:


Is that correct?

I assume the other changes can be committed as-is.


Yes, that should do it.


Revised and pushed.

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