Re: [FFmpeg-devel] [PATCH v3] doc/filters: Add double-pass example for loudnorm
On 21-08-2018 03:18 AM, Marvin Scholz wrote: +@example +ffmpeg -i input -af loudnorm=I=-23:TP=-1:measured_I=-9.0:measured_TP=1.5:measured_LRA=9.4:measured_thresh=-19.5:print_format=summary output Since your input LRA is 9.4, and output LRA is 7 (default), the filter will upsample to 192 kHz. You should resample afterwards. If we publish this, it will generate support queries as to why our example produces "silent" files. Thanks, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] examples/vaapi_dec_scaling: init export
On Mon, Jun 11, 2018 at 7:22 PM Jun Zhao wrote:
>
> add a vaapi decoding/scaling sample.
>
> Signed-off-by: Jun Zhao
> ---
> configure| 2 +
> doc/examples/Makefile| 1 +
> doc/examples/vaapi_dec_scaling.c | 375
+++
> 3 files changed, 378 insertions(+)
> create mode 100644 doc/examples/vaapi_dec_scaling.c
>
> diff --git a/configure b/configure
> index 473be31..d28dc37 100755
> --- a/configure
> +++ b/configure
> @@ -1610,6 +1610,7 @@ EXAMPLE_LIST="
> scaling_video_example
> transcode_aac_example
> transcoding_example
> +vaapi_dec_scaling_example
> vaapi_encode_example
> vaapi_transcode_example
> "
> @@ -3445,6 +3446,7 @@ resampling_audio_example_deps="avutil swresample"
> scaling_video_example_deps="avutil swscale"
> transcode_aac_example_deps="avcodec avformat swresample"
> transcoding_example_deps="avfilter avcodec avformat avutil"
> +vaapi_dec_scaling_example_deps="avfilter avcodec avformat avutil"
> vaapi_encode_example_deps="avcodec avutil h264_vaapi_encoder"
> vaapi_transcode_example_deps="avcodec avformat avutil h264_vaapi_encoder"
>
> diff --git a/doc/examples/Makefile b/doc/examples/Makefile
> index 928ff30..3ea6899 100644
> --- a/doc/examples/Makefile
> +++ b/doc/examples/Makefile
> @@ -19,6 +19,7 @@ EXAMPLES-$(CONFIG_RESAMPLING_AUDIO_EXAMPLE) +=
resampling_audio
> EXAMPLES-$(CONFIG_SCALING_VIDEO_EXAMPLE) += scaling_video
> EXAMPLES-$(CONFIG_TRANSCODE_AAC_EXAMPLE) += transcode_aac
> EXAMPLES-$(CONFIG_TRANSCODING_EXAMPLE) += transcoding
> +EXAMPLES-$(CONFIG_VAAPI_DEC_SCALING_EXAMPLE) += vaapi_dec_scaling
> EXAMPLES-$(CONFIG_VAAPI_ENCODE_EXAMPLE) += vaapi_encode
> EXAMPLES-$(CONFIG_VAAPI_TRANSCODE_EXAMPLE) += vaapi_transcode
>
> diff --git a/doc/examples/vaapi_dec_scaling.c
b/doc/examples/vaapi_dec_scaling.c
> new file mode 100644
> index 000..6ec65da
> --- /dev/null
> +++ b/doc/examples/vaapi_dec_scaling.c
> @@ -0,0 +1,375 @@
> +/*
> + * Copyright (c) 2018 Jun Zhao
> + *
> + * VA-API Acceleration API (video decoding/scaling) sample
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA
> + */
> +
> +/**
> + * @file
> + * VA-API-Accelerated decoding/scaling example.
> + *
> + * @example vaapi_dec_scaling.c
> + * This example shows how to do VA-API-accelerated decoding/scaling with
output
> + * frames from the HW video surfaces.
> + */
> +
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static AVBufferRef *hw_device_ctx = NULL;
> +static enum AVPixelFormat hw_pix_fmt;
> +static FILE *output_file = NULL;
> +AVFilterContext *buffersink_ctx;
> +AVFilterContext *buffersrc_ctx;
> +AVFilterGraph *filter_graph;
> +const char *filter_descr =
> +"format=vaapi,scale_vaapi=w=iw/2:h=ih/2,hwdownload,format=nv12";
> +int init_filter = 0;
> +
> +static int init_hw_decode(AVCodecContext *ctx, const enum AVHWDeviceType
type)
> +{
> +int err = 0;
> +
> +if ((err = av_hwdevice_ctx_create(_device_ctx, type,
> + NULL, NULL, 0)) < 0) {
> +fprintf(stderr, "Failed to create specified HW device.\n");
> +return err;
> +}
> +ctx->hw_device_ctx = av_buffer_ref(hw_device_ctx);
> +
> +return err;
> +}
> +
> +static int init_filters(AVFormatContext *fmt_ctx, AVCodecContext
*dec_ctx,
> +int video_stream_index, const char
*filters_descr)
> +{
> +char args[512];
> +int ret = 0;
> +const AVFilter *buffersrc = avfilter_get_by_name("buffer");
> +const AVFilter *buffersink = avfilter_get_by_name("buffersink");
> +AVFilterInOut *outputs = avfilter_inout_alloc();
> +AVFilterInOut *inputs = avfilter_inout_alloc();
> +AVRational time_base =
fmt_ctx->streams[video_stream_index]->time_base;
> +AVBufferSrcParameters *par = av_buffersrc_parameters_alloc();
> +
> +filter_graph = avfilter_graph_alloc();
> +if (!outputs || !inputs || !filter_graph || !par) {
> +ret = AVERROR(ENOMEM);
> +goto end;
> +}
> +
> +/* buffer video source: the decoded frames from the decoder will be
inserted here. */
> +
Re: [FFmpeg-devel] [PATCH 2/3] lavc/vaapi_encode_h264: respect "slices" option in h264 vaapi encoder
On Tue, Aug 21, 2018 at 8:05 AM Mark Thompson wrote:
>
> On 30/07/18 12:42, Jun Zhao wrote:
> > Enable multi-slice support in AVC/H.264 vaapi encoder.
> >
> > Signed-off-by: Wang, Yi A
> > Signed-off-by: Jun Zhao
> > ---
> > libavcodec/vaapi_encode_h264.c | 31 +--
> > 1 files changed, 25 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> > index 905c507..70c89e8 100644
> > --- a/libavcodec/vaapi_encode_h264.c
> > +++ b/libavcodec/vaapi_encode_h264.c
> > @@ -581,6 +581,7 @@ static int
> > vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
> > H264RawSPS *sps = >sps;
> > VAEncPictureParameterBufferH264 *vpic = pic->codec_picture_params;
> > int i;
> > +int slices;
> >
> > memset(>current_access_unit, 0,
> > sizeof(priv->current_access_unit));
> > @@ -690,7 +691,17 @@ static int
> > vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
> > vpic->pic_fields.bits.idr_pic_flag = (pic->type ==
> > PICTURE_TYPE_IDR);
> > vpic->pic_fields.bits.reference_pic_flag = (pic->type !=
> > PICTURE_TYPE_B);
> >
> > -pic->nb_slices = 1;
> > +slices = 1;
> > +if (ctx->max_slices) {
> > +if (avctx->slices <= FFMIN(ctx->max_slices, priv->mb_height)) {
> > +slices = FFMAX(avctx->slices, slices);
> > +} else {
> > +av_log(avctx, AV_LOG_ERROR, "The max slices number per frame "
> > + "cannot be more than %d.\n", FFMIN(ctx->max_slices,
> > priv->mb_height));
> > +return AVERROR_INVALIDDATA;
>
> AVERROR(EINVAL) for invalid user parameters.
Will follow the comment.
>
> > +}
> > +}
> > +pic->nb_slices = slices;
> >
> > return 0;
> > }
> > @@ -716,8 +727,7 @@ static int
> > vaapi_encode_h264_init_slice_params(AVCodecContext *avctx,
> > sh->nal_unit_header.nal_ref_idc = pic->type != PICTURE_TYPE_B;
> > }
> >
> > -// Only one slice per frame.
> > -sh->first_mb_in_slice = 0;
> > +sh->first_mb_in_slice = !!slice->index;
> > sh->slice_type= priv->slice_type;
> >
> > sh->pic_parameter_set_id = pps->pic_parameter_set_id;
> > @@ -738,14 +748,19 @@ static int
> > vaapi_encode_h264_init_slice_params(AVCodecContext *avctx,
> > sh->slice_qp_delta = priv->fixed_qp_idr -
> > (pps->pic_init_qp_minus26 + 26);
> >
> >
> > -vslice->macroblock_address = sh->first_mb_in_slice;
> > -vslice->num_macroblocks= priv->mb_width * priv->mb_height;
> > +vslice->macroblock_address = slice->index * priv->mb_width *
> > (priv->mb_height / pic->nb_slices);
> > +if (slice->index == pic->nb_slices - 1) {
> > +vslice->num_macroblocks = priv->mb_width * priv->mb_height
> > + - slice->index * priv->mb_width *
> > (priv->mb_height / pic->nb_slices);
> > +priv->idr_pic_count++;
> > +} else
> > +vslice->num_macroblocks = priv->mb_width * (priv->mb_height /
> > pic->nb_slices);
>
> This dumps all of the rounding error in the last slice. E.g. 1080p with 8
> slices gives you 68 macroblocks high, so you get seven slices with 68/8 = 8
> macroblock height and the last one has 12 macroblock height.
>
> It should be balanced so that all slices are roughly the same size (8-slice
> 1080p -> four slices of 9 + four slices of 8). It might make sense to put
> the residual rounding error away from the middle of the frame too (so 9, 9,
> 8, 8, 8, 8, 9, 9), though that's probably second-order.
I agree with the comment, as my point, how about change the slice number as :
68 / 8 = 8 .. 4, and we give (9, 9, 9, 9, 8, 8, 8, 8) in this case?
>
> >
> > vslice->macroblock_info = VA_INVALID_ID;
> >
> > vslice->slice_type = sh->slice_type % 5;
> > vslice->pic_parameter_set_id = sh->pic_parameter_set_id;
> > -vslice->idr_pic_id = sh->idr_pic_id;
> > +vslice->idr_pic_id = priv->idr_pic_count;
> >
> > vslice->pic_order_cnt_lsb = sh->pic_order_cnt_lsb;
> >
> > @@ -855,6 +870,10 @@ static av_cold int
> > vaapi_encode_h264_configure(AVCodecContext *avctx)
> > }
> > }<
>
> > +if (!ctx->max_slices && avctx->slices > 0)
> > +av_log(avctx, AV_LOG_WARNING, "The encode slice option is not "
> > + "supported with the driver.\n");
>
> Maybe this should fail in the same way as the above case where you ask for
> too many slices? If the user requests them it is probably for conformance
> reasons, so continuing and generating a stream without slices seems unlikely
> to be useful. (The Mesa driver on AMD hits this case.)
Will double-check this part, Thanks.
>
> > +
> > return 0;
> > }
> >
> >
>
> Unfortunately, this doesn't seem to work at all for me - the driver is happy
> with the input, but I always get corrupt output. I tried on both Haswell and
> Coffee
Re: [FFmpeg-devel] [PATCH 2/3] lavc/vaapi_encode_h264: respect "slices" option in h264 vaapi encoder
On 30/07/18 12:42, Jun Zhao wrote:
> Enable multi-slice support in AVC/H.264 vaapi encoder.
>
> Signed-off-by: Wang, Yi A
> Signed-off-by: Jun Zhao
> ---
> libavcodec/vaapi_encode_h264.c | 31 +--
> 1 files changed, 25 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> index 905c507..70c89e8 100644
> --- a/libavcodec/vaapi_encode_h264.c
> +++ b/libavcodec/vaapi_encode_h264.c
> @@ -581,6 +581,7 @@ static int
> vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
> H264RawSPS *sps = >sps;
> VAEncPictureParameterBufferH264 *vpic = pic->codec_picture_params;
> int i;
> +int slices;
>
> memset(>current_access_unit, 0,
> sizeof(priv->current_access_unit));
> @@ -690,7 +691,17 @@ static int
> vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
> vpic->pic_fields.bits.idr_pic_flag = (pic->type ==
> PICTURE_TYPE_IDR);
> vpic->pic_fields.bits.reference_pic_flag = (pic->type != PICTURE_TYPE_B);
>
> -pic->nb_slices = 1;
> +slices = 1;
> +if (ctx->max_slices) {
> +if (avctx->slices <= FFMIN(ctx->max_slices, priv->mb_height)) {
> +slices = FFMAX(avctx->slices, slices);
> +} else {
> +av_log(avctx, AV_LOG_ERROR, "The max slices number per frame "
> + "cannot be more than %d.\n", FFMIN(ctx->max_slices,
> priv->mb_height));
> +return AVERROR_INVALIDDATA;
AVERROR(EINVAL) for invalid user parameters.
> +}
> +}
> +pic->nb_slices = slices;
>
> return 0;
> }
> @@ -716,8 +727,7 @@ static int
> vaapi_encode_h264_init_slice_params(AVCodecContext *avctx,
> sh->nal_unit_header.nal_ref_idc = pic->type != PICTURE_TYPE_B;
> }
>
> -// Only one slice per frame.
> -sh->first_mb_in_slice = 0;
> +sh->first_mb_in_slice = !!slice->index;
> sh->slice_type= priv->slice_type;
>
> sh->pic_parameter_set_id = pps->pic_parameter_set_id;
> @@ -738,14 +748,19 @@ static int
> vaapi_encode_h264_init_slice_params(AVCodecContext *avctx,
> sh->slice_qp_delta = priv->fixed_qp_idr - (pps->pic_init_qp_minus26
> + 26);
>
>
> -vslice->macroblock_address = sh->first_mb_in_slice;
> -vslice->num_macroblocks= priv->mb_width * priv->mb_height;
> +vslice->macroblock_address = slice->index * priv->mb_width *
> (priv->mb_height / pic->nb_slices);
> +if (slice->index == pic->nb_slices - 1) {
> +vslice->num_macroblocks = priv->mb_width * priv->mb_height
> + - slice->index * priv->mb_width *
> (priv->mb_height / pic->nb_slices);
> +priv->idr_pic_count++;
> +} else
> +vslice->num_macroblocks = priv->mb_width * (priv->mb_height /
> pic->nb_slices);
This dumps all of the rounding error in the last slice. E.g. 1080p with 8
slices gives you 68 macroblocks high, so you get seven slices with 68/8 = 8
macroblock height and the last one has 12 macroblock height.
It should be balanced so that all slices are roughly the same size (8-slice
1080p -> four slices of 9 + four slices of 8). It might make sense to put the
residual rounding error away from the middle of the frame too (so 9, 9, 8, 8,
8, 8, 9, 9), though that's probably second-order.
>
> vslice->macroblock_info = VA_INVALID_ID;
>
> vslice->slice_type = sh->slice_type % 5;
> vslice->pic_parameter_set_id = sh->pic_parameter_set_id;
> -vslice->idr_pic_id = sh->idr_pic_id;
> +vslice->idr_pic_id = priv->idr_pic_count;
>
> vslice->pic_order_cnt_lsb = sh->pic_order_cnt_lsb;
>
> @@ -855,6 +870,10 @@ static av_cold int
> vaapi_encode_h264_configure(AVCodecContext *avctx)
> }
> }
>
> +if (!ctx->max_slices && avctx->slices > 0)
> +av_log(avctx, AV_LOG_WARNING, "The encode slice option is not "
> + "supported with the driver.\n");
Maybe this should fail in the same way as the above case where you ask for too
many slices? If the user requests them it is probably for conformance reasons,
so continuing and generating a stream without slices seems unlikely to be
useful. (The Mesa driver on AMD hits this case.)
> +
> return 0;
> }
>
>
Unfortunately, this doesn't seem to work at all for me - the driver is happy
with the input, but I always get corrupt output. I tried on both Haswell and
Coffee Lake with the current i965 driver.
E.g. (with "Intel i965 driver for Intel(R) Coffee Lake - 2.1.1.pre1
(2.1.0-44-g40b15a5)"):
$ ./ffmpeg_g -v 55 -y -threads 1 -hwaccel vaapi -hwaccel_device
/dev/dri/renderD128 -hwaccel_output_format vaapi -i
~/video/test/bbb_1080_264.mp4 -an -c:v h264_vaapi -slices 2 -frames:v 1 test.264
...
[h264_vaapi @ 0x5607d595e280] Encode frame: 1920x1080 (0).
[h264_vaapi @ 0x5607d595e280] Pictures: IDR (0/0)
[h264_vaapi @ 0x5607d595e280]
[FFmpeg-devel] [PATCH v3] doc/filters: Add double-pass example for loudnorm
---
Changes to v2:
- Removed -map option to prevent filter to affect all audio channels
in the first pass example
doc/filters.texi | 23 +++
1 file changed, 23 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index 32c95b591c..f082d55d32 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -3659,6 +3659,29 @@ Set print format for stats. Options are summary, json,
or none.
Default value is none.
@end table
+@subsection Examples
+
+For double pass processing you need to first run the filter with
+@code{print_format} set to either @code{json} or @code{summary}, then read
+the values in the output and pass it to the next run of the filter:
+
+@example
+$ ffmpeg -i input -af loudnorm=I=-23:TP=-1:print_format=summary -f null -
+
+[...]
+Input Integrated: -9.0 LUFS
+Input True Peak: +1.5 dBTP
+Input LRA: 9.4 LU
+Input Threshold: -19.5 LUFS
+@end example
+
+Then pass the input measurements to the next run that produces the result:
+
+@example
+ffmpeg -i input -af
loudnorm=I=-23:TP=-1:measured_I=-9.0:measured_TP=1.5:measured_LRA=9.4:measured_thresh=-19.5:print_format=summary
output
+@end example
+
+
@section lowpass
Apply a low-pass filter with 3dB point frequency.
--
2.17.0 (Apple Git-106)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avcodec/hq_hqa: Check remaining input bits in hqa_decode_mb()
Fixes: Timeout Fixes: 9634/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HQ_HQA_fuzzer-6267852259590144 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/hq_hqa.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/hq_hqa.c b/libavcodec/hq_hqa.c index f88ad7d5f5..ec9da3e04f 100644 --- a/libavcodec/hq_hqa.c +++ b/libavcodec/hq_hqa.c @@ -181,6 +181,9 @@ static int hqa_decode_mb(HQContext *c, AVFrame *pic, int qgroup, int flag = 0; int i, ret, cbp; +if (get_bits_left(gb) < 1) +return AVERROR_INVALIDDATA; + cbp = get_vlc2(gb, c->hqa_cbp_vlc.table, 5, 1); for (i = 0; i < 12; i++) -- 2.18.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avcodec/vb: Check for end of bytestream before reading blocktype
Fixes: Timeout
Fixes:
9601/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VB_fuzzer-4550228702134272
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/vb.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/vb.c b/libavcodec/vb.c
index 021657f7d8..c6dd6fb456 100644
--- a/libavcodec/vb.c
+++ b/libavcodec/vb.c
@@ -107,6 +107,10 @@ static int vb_decode_framedata(VBDecContext *c, int offset)
blk2 = 0;
for (blk = 0; blk < blocks; blk++) {
if (!(blk & 3)) {
+if (bytestream2_get_bytes_left() < 1) {
+av_log(c->avctx, AV_LOG_ERROR, "Insufficient data\n");
+return AVERROR_INVALIDDATA;
+}
blocktypes = bytestream2_get_byte();
}
switch (blocktypes & 0xC0) {
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avcodec/snowdec: Fix integer overflow with motion vector residual
Fixes: signed integer overflow: -19818 + -2147483648 cannot be represented in
type 'int'
Fixes:
9545/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-4928769537081344
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/snowdec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/snowdec.c b/libavcodec/snowdec.c
index 0146a2a4c9..59bd24e881 100644
--- a/libavcodec/snowdec.c
+++ b/libavcodec/snowdec.c
@@ -208,8 +208,8 @@ static int decode_q_branch(SnowContext *s, int level, int
x, int y){
return AVERROR_INVALIDDATA;
}
pred_mv(s, , , ref, left, top, tr);
-mx+= get_symbol(>c, >block_state[128 + 32*(mx_context +
16*!!ref)], 1);
-my+= get_symbol(>c, >block_state[128 + 32*(my_context +
16*!!ref)], 1);
+mx+= (unsigned)get_symbol(>c, >block_state[128 +
32*(mx_context + 16*!!ref)], 1);
+my+= (unsigned)get_symbol(>c, >block_state[128 +
32*(my_context + 16*!!ref)], 1);
}
set_blocks(s, level, x, y, l, cb, cr, mx, my, ref, type);
}else{
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec: add Brooktree ProSumer Video decoder
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 7 +
libavcodec/prosumer.c | 413
libavformat/riff.c | 1 +
6 files changed, 424 insertions(+)
create mode 100644 libavcodec/prosumer.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index f0c8226283..9a309c348e 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -515,6 +515,7 @@ OBJS-$(CONFIG_PRORES_DECODER) += proresdec2.o
proresdsp.o proresdata.o
OBJS-$(CONFIG_PRORES_ENCODER) += proresenc_anatoliy.o
OBJS-$(CONFIG_PRORES_AW_ENCODER) += proresenc_anatoliy.o
OBJS-$(CONFIG_PRORES_KS_ENCODER) += proresenc_kostya.o proresdata.o
+OBJS-$(CONFIG_PROSUMER_DECODER)+= prosumer.o
OBJS-$(CONFIG_PSD_DECODER) += psd.o
OBJS-$(CONFIG_PTX_DECODER) += ptx.o
OBJS-$(CONFIG_QCELP_DECODER) += qcelpdec.o \
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index fd35fc1d0b..b1d1ef26c0 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -235,6 +235,7 @@ extern AVCodec ff_prores_encoder;
extern AVCodec ff_prores_decoder;
extern AVCodec ff_prores_aw_encoder;
extern AVCodec ff_prores_ks_encoder;
+extern AVCodec ff_prosumer_decoder;
extern AVCodec ff_psd_decoder;
extern AVCodec ff_ptx_decoder;
extern AVCodec ff_qdraw_decoder;
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 31e50d5a94..2a4be2ca4f 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -448,6 +448,7 @@ enum AVCodecID {
AV_CODEC_ID_GDV,
AV_CODEC_ID_FITS,
AV_CODEC_ID_IMM4,
+AV_CODEC_ID_PROSUMER,
/* various PCM "codecs" */
AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the
start of audio codecs
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 1779149091..b2c9a10f0b 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1661,6 +1661,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
.long_name = NULL_IF_CONFIG_SMALL("Infinity IMM4"),
.props = AV_CODEC_PROP_LOSSY,
},
+{
+.id= AV_CODEC_ID_PROSUMER,
+.type = AVMEDIA_TYPE_VIDEO,
+.name = "prosumer",
+.long_name = NULL_IF_CONFIG_SMALL("Brooktree ProSumer Video"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
+},
/* various PCM "codecs" */
{
diff --git a/libavcodec/prosumer.c b/libavcodec/prosumer.c
new file mode 100644
index 00..7e4514b5aa
--- /dev/null
+++ b/libavcodec/prosumer.c
@@ -0,0 +1,413 @@
+/*
+ * Brooktree ProSumer Video decoder
+ * Copyright (c) 2018 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+#include
+
+#include "libavutil/imgutils.h"
+#include "libavutil/internal.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/mem.h"
+
+#include "avcodec.h"
+#include "bytestream.h"
+#include "internal.h"
+
+typedef struct ProSumerContext {
+GetByteContext gb;
+PutByteContext pb;
+
+unsigned stride;
+unsigned size;
+unsigned lut[0x1];
+uint8_t *table_b;
+uint8_t *decbuffer;
+} ProSumerContext;
+
+#define PAIR(high, low) (((uint64_t)(high)<> 20;
+b = lut[2 * idx];
+
+while (1) {
+if b >> 8) & 0xFFu) != 0x80u) || (b & 0xFFu)) {
+if (((b >> 8) & 0xFFu) != 0x80u) {
+bytestream2_put_le16(pb, b);
+} else if (b & 0xFFu) {
+idx = 0;
+for (i = 0; i < (b & 0xFFu); i++)
+bytestream2_put_le32(pb, 0);
+}
+c = b >> 16;
+if ((c >> 8) & 0xFFu) {
+c = ((c >> 8) & 0xFFu) | (c & 0xFF00);
+c = c & 0xF00F;
+fill = lut[2 * idx + 1];
+if (((c >> 8) & 0xFFu) == 16 ) {
+bytestream2_put_le16(pb, fill);
+c &= 0x00FFu;
+} else {
+bytestream2_put_le32(pb, fill);
+c &= 0x00FFu;
+}
+}
+while (c) {
+
[FFmpeg-devel] [PATCH 1/2] avcodec: add IMM4 decoder
This work is sponsored by VideoLAN.
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 7 +
libavcodec/imm4.c | 501
libavformat/riff.c | 1 +
6 files changed, 512 insertions(+)
create mode 100644 libavcodec/imm4.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 6e40702947..f0c8226283 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -385,6 +385,7 @@ OBJS-$(CONFIG_IDCIN_DECODER) += idcinvideo.o
OBJS-$(CONFIG_IDF_DECODER) += bintext.o cga_data.o
OBJS-$(CONFIG_IFF_ILBM_DECODER)+= iff.o
OBJS-$(CONFIG_IMC_DECODER) += imc.o
+OBJS-$(CONFIG_IMM4_DECODER)+= imm4.o
OBJS-$(CONFIG_INDEO2_DECODER) += indeo2.o
OBJS-$(CONFIG_INDEO3_DECODER) += indeo3.o
OBJS-$(CONFIG_INDEO4_DECODER) += indeo4.o ivi.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index ab3ec04251..fd35fc1d0b 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -153,6 +153,7 @@ extern AVCodec ff_huffyuv_encoder;
extern AVCodec ff_huffyuv_decoder;
extern AVCodec ff_idcin_decoder;
extern AVCodec ff_iff_ilbm_decoder;
+extern AVCodec ff_imm4_decoder;
extern AVCodec ff_indeo2_decoder;
extern AVCodec ff_indeo3_decoder;
extern AVCodec ff_indeo4_decoder;
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 56be65bd56..31e50d5a94 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -447,6 +447,7 @@ enum AVCodecID {
AV_CODEC_ID_SVG,
AV_CODEC_ID_GDV,
AV_CODEC_ID_FITS,
+AV_CODEC_ID_IMM4,
/* various PCM "codecs" */
AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the
start of audio codecs
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 1cbb241389..1779149091 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1654,6 +1654,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
.long_name = NULL_IF_CONFIG_SMALL("FITS (Flexible Image Transport
System)"),
.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
},
+{
+.id= AV_CODEC_ID_IMM4,
+.type = AVMEDIA_TYPE_VIDEO,
+.name = "imm4",
+.long_name = NULL_IF_CONFIG_SMALL("Infinity IMM4"),
+.props = AV_CODEC_PROP_LOSSY,
+},
/* various PCM "codecs" */
{
diff --git a/libavcodec/imm4.c b/libavcodec/imm4.c
new file mode 100644
index 00..4769f352e9
--- /dev/null
+++ b/libavcodec/imm4.c
@@ -0,0 +1,501 @@
+/*
+ * Infinity IMM4 decoder
+ *
+ * Copyright (c) 2018 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+#include
+
+#include "libavutil/thread.h"
+
+#include "avcodec.h"
+#include "bswapdsp.h"
+#include "copy_block.h"
+#include "get_bits.h"
+#include "idctdsp.h"
+#include "internal.h"
+
+typedef struct IMM4Context {
+BswapDSPContext bdsp;
+GetBitContext gb;
+
+AVFrame *prev_frame;
+uint8_t *bitstream;
+int bitstream_size;
+
+int changed_size;
+int factor;
+unsigned sindex;
+
+DECLARE_ALIGNED(32, int16_t, block)[6][64];
+IDCTDSPContext idsp;
+} IMM4Context;
+
+static const uint8_t intra_cb[] = {
+12, 9, 6
+};
+
+static const uint8_t inter_cb[] = {
+30, 20, 15
+};
+
+static const uint8_t cbplo_symbols[] = {
+3, 4, 19, 20, 35, 36, 51, 52
+};
+
+static const uint8_t cbplo_bits[] = {
+1, 4, 3, 6, 3, 6, 3, 6
+};
+
+static const uint8_t cbplo_codes[] = {
+1, 1, 1, 1, 2, 2, 3, 3
+};
+
+static const uint8_t cbphi_bits[] = {
+4, 5, 5, 4, 5, 4, 6, 4, 5, 6, 4, 4, 4, 4, 4, 2
+};
+
+static const uint8_t cbphi_codes[] = {
+3, 5, 4, 9, 3, 7, 2, 11, 2, 3, 5, 10, 4, 8, 6, 3
+};
+
+static const uint8_t blktype_symbols[] = {
+0, 1, 2, 3, 4, 16, 17, 18, 19, 20, 32, 33, 34, 35, 48, 50, 51, 52
+};
+
+static const uint8_t blktype_bits[] = {
+1, 3, 3, 5, 6, 4, 7, 7, 8, 9, 4, 7, 7, 8, 6, 8, 7, 9
+};
+
+static const uint8_t blktype_codes[] = {
+1, 3, 2, 3, 4, 3, 7, 5, 4, 4, 2, 6, 4, 3, 5, 5, 3, 2
+};
+
+static const uint16_t block_symbols[] = {
+0x0, 0x1, 0x2, 0x3, 0x4,
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
Hello, I am having trouble reproducing this error. These tests are fine for 32-bit > VMs on > my computers. So the only thing I can do is to disable these tests for > these formats. > Otherwise, I need to test other changes somehow. Here is the patch, that > skips > pixfmts tests for these formats. > > What is the conversion function which create "problem" in tests ? Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/vf_libvmaf: update to use libvmaf v1.3.9
2018-08-20 19:09 GMT+02:00, Paul B Mahol : > On 8/20/18, Carl Eugen Hoyos wrote: >> 2018-08-20 7:15 GMT+02:00, Gyan Doshi : >>> On 20-08-2018 03:17 AM, Carl Eugen Hoyos wrote: > We have -filter_complex_threads for that, so no. For which use-case is this an advantage? >>> >>> For when the intended recipient is a complex filtergraph. >> >> For which use-case is it an advantage that there is not one >> option to tell the filter-chain the number of threads to use, >> no matter if it is a simple or a complex filter-chain, but to >> have one option to use for the simple and a different option >> for the complex case? > > Again, there is already option, please consult documentation. How is this related to the question? > This filter does not use lavfi threads so it should not use lavfi > threads option. Not sure if I misunderstand but my question above is not related to any filter. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
2018-08-18 23:20 GMT+03:00 Michael Niedermayer :
> On Sat, Aug 18, 2018 at 02:10:21PM +0300, Sergey Lavrushkin wrote:
> > 2018-08-17 23:28 GMT+03:00 Michael Niedermayer :
> >
> > > On Fri, Aug 17, 2018 at 12:46:52AM -0300, James Almer wrote:
> > > > On 8/14/2018 1:23 PM, Michael Niedermayer wrote:
> > > > > On Mon, Aug 13, 2018 at 04:58:42PM +0300, Sergey Lavrushkin wrote:
> > > > >>>
> > > > >>> Just use av_clipf instead of FFMIN/FFMAX.
> > > > >>
> > > > >>
> > > > >> Changed FFMIN/FFMAX to av_clip_uint16 and av_clip_uint8.
> > > > >
> > > > > will apply
> > > > >
> > > > > thanks
> > > >
> > > > This broke fate on some 32bit hosts. Guess float pixfmts shouldn't be
> > > > tested for bitexact output. The gbrpf32 ones aren't, for example.
> > > > http://fate.ffmpeg.org/report.cgi?time=20180816131312=
> > > x86_32-debian-kfreebsd-gcc-4.4-cpuflags-mmx
> > >
> > > h
> > > i remember i had tested this locally on 32bit
> > > can something be slightly adjusted (like an offset or factor) to avoid
> any
> > > values becoming close to 0.5 and rounding differently on platforms ?
> >
> > If not the tests should skip float pixel formats or try the nearest
> > > neighbor scaler
> > >
> >
> > Can it really be the problem with scaler? Do all these failed test use
> > scaling?
> > Is not it the problem, that different platforms can give slightly
> different
> > results for
> > floating-point operations? Does input for the float format is somehow
> > generated
> > for these tests, so the input conversion is tested? Maybe it uses output
> > conversion first?
> > If it is the problem of different floating-point operations results on
> > different platforms,
>
> > maybe it is possible to use precomputed LUT for output conversion, so it
>
> I dont think we should change the "algorithm" to achive "bitexactness"
> we could of course but it feels like the wrong reason to make such a
> change. How its done should be choosen based on what is fast (and to a
> lesser extend clean, simple and maintainable)
>
>
>
> > will give
> > the same results? Or is it possible to modify tests for the float format,
> > so it will
> > check if pixels of the result are just close to some reference.
>
> Its possible to compare to a reference, we do this in some other tests,
> but thats surely more work than just disabling teh specific tests or trying
> to nudge them a little to see if that makes nothing fall too close to n +
> 0.5
>
> >
> >
> > > Sergey, can you look into this (its your patch) ? (just asking to make
> sure
> > > not eevryone thinks someone else will work on this)
> > >
> >
> > Yes, I can, just need to know, what is possible to do to fix this issue,
> > besides skipping the tests.
>
> most things are possible
>
Hi,
I am having trouble reproducing this error. These tests are fine for 32-bit
VMs on
my computers. So the only thing I can do is to disable these tests for
these formats.
Otherwise, I need to test other changes somehow. Here is the patch, that
skips
pixfmts tests for these formats.
From a92e6965f9c328fcaa18460ac9da975748272e0a Mon Sep 17 00:00:00 2001
From: Sergey Lavrushkin
Date: Mon, 20 Aug 2018 23:14:07 +0300
Subject: [PATCH] tests: Disables pixfmts tests for float gray formats.
---
tests/fate-run.sh| 4 ++--
tests/ref/fate/filter-pixfmts-copy | 2 --
tests/ref/fate/filter-pixfmts-crop | 2 --
tests/ref/fate/filter-pixfmts-field | 2 --
tests/ref/fate/filter-pixfmts-fieldorder | 2 --
tests/ref/fate/filter-pixfmts-hflip | 2 --
tests/ref/fate/filter-pixfmts-il | 2 --
tests/ref/fate/filter-pixfmts-null | 2 --
tests/ref/fate/filter-pixfmts-scale | 2 --
tests/ref/fate/filter-pixfmts-transpose | 2 --
tests/ref/fate/filter-pixfmts-vflip | 2 --
11 files changed, 2 insertions(+), 22 deletions(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index aece90a01d..e8d71707b0 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -288,8 +288,8 @@ pixfmts(){
in_fmts=${outfile}_in_fmts
# exclude pixel formats which are not supported as input
-$showfiltfmts scale | awk -F '[ \r]' '/^INPUT/{ fmt=substr($3, 5); print fmt }' | sort >$scale_in_fmts
-$showfiltfmts scale | awk -F '[ \r]' '/^OUTPUT/{ fmt=substr($3, 5); print fmt }' | sort >$scale_out_fmts
+$showfiltfmts scale | awk -F '[ \r]' '/^INPUT/{ fmt=substr($3, 5); if (fmt !~ /grayf32.e/){ print fmt } }' | sort >$scale_in_fmts
+$showfiltfmts scale | awk -F '[ \r]' '/^OUTPUT/{ fmt=substr($3, 5); if (fmt !~ /grayf32.e/){ print fmt } }' | sort >$scale_out_fmts
comm -12 $scale_in_fmts $scale_out_fmts >$scale_exclude_fmts
$showfiltfmts $filter | awk -F '[ \r]' '/^INPUT/{ fmt=substr($3, 5); print fmt }' | sort >$in_fmts
diff --git a/tests/ref/fate/filter-pixfmts-copy b/tests/ref/fate/filter-pixfmts-copy
index 5385036a82..013b33f1c0 100644
--- a/tests/ref/fate/filter-pixfmts-copy
+++ b/tests/ref/fate/filter-pixfmts-copy
@@ -47,8 +47,6 @@ gray16be
Re: [FFmpeg-devel] [PATCH] libavcodec/cuviddec A53CC closed captions support added to cuviddec & nvenc
On 8/17/2018 2:38 PM, Carl Eugen Hoyos wrote: 2018-05-03 19:42 GMT+02:00, Timo Rothenpieler : Slightly refactored nvenc part can be found here: https://github.com/BtbN/FFmpeg/commit/e5d85ac3 Will push tomorrow if no issue with it comes up. Why is there no option to disable Closed Captions encoding? Especially as all other h264 encoders support such an option. Yeah, I guess adding one won't hurt. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aadec: alternate mp3 seek handling
Ping. Any thoughts on this?
Cheers, Karsten
> Am 31.07.2018 um 21:16 schrieb Karsten Otto :
>
> After seeking, determine the offset of the next frame in the decrypted
> buffer by scanning the first few bytes for a valid mp3 header.
> This significantly improves the listening experience for audio content
> with untypical encoding.
> ---
> This is a refinement of an earlier patch iteration, according to lessons
> learned and discussions on the mailing list: Scan a limited range to find
> the first shifted frame only, check for a very specific bit pattern, and
> add extra checks and guards for better code maintainability.
>
> Unfortunately, this variant violates the architectural layering between
> demuxer and codec. But I did some more testing with untypical encodings,
> where the current estimation mechanism fails, and the resulting audio on
> seek was just too horribly annoying.
>
> I believe the better listening experience outweighs the architectural
> uglyness, so this should be in the official code base. But if you think
> otherwise, just let me know, and I will keep this a private patch.
>
> libavformat/aadec.c | 45 -
> 1 file changed, 28 insertions(+), 17 deletions(-)
>
> diff --git a/libavformat/aadec.c b/libavformat/aadec.c
> index d83f283ffe..9b1495c218 100644
> --- a/libavformat/aadec.c
> +++ b/libavformat/aadec.c
> @@ -37,7 +37,7 @@
> #define TEA_BLOCK_SIZE 8
> #define CHAPTER_HEADER_SIZE 8
> #define TIMEPREC 1000
> -#define MP3_FRAME_SIZE 104
> +#define MP3_FRAME_SIZE 105
>
> typedef struct AADemuxContext {
> AVClass *class;
> @@ -51,7 +51,7 @@ typedef struct AADemuxContext {
> int64_t current_chapter_size;
> int64_t content_start;
> int64_t content_end;
> -int seek_offset;
> +int did_seek;
> } AADemuxContext;
>
> static int get_second_size(char *codec_name)
> @@ -179,7 +179,7 @@ static int aa_read_header(AVFormatContext *s)
> st->codecpar->sample_rate = 22050;
> st->need_parsing = AVSTREAM_PARSE_FULL_RAW;
> avpriv_set_pts_info(st, 64, 8, 32000 * TIMEPREC);
> -// encoded audio frame is MP3_FRAME_SIZE bytes (+1 with padding,
> unlikely)
> +// encoded audio frame is MP3_FRAME_SIZE bytes (-1 without padding)
> } else if (!strcmp(codec_name, "acelp85")) {
> st->codecpar->codec_id = AV_CODEC_ID_SIPR;
> st->codecpar->block_align = 19;
> @@ -231,7 +231,7 @@ static int aa_read_header(AVFormatContext *s)
> ff_update_cur_dts(s, st, 0);
> avio_seek(pb, start, SEEK_SET);
> c->current_chapter_size = 0;
> -c->seek_offset = 0;
> +c->did_seek = 0;
>
> return 0;
> }
> @@ -244,7 +244,7 @@ static int aa_read_packet(AVFormatContext *s, AVPacket
> *pkt)
> int trailing_bytes;
> int blocks;
> uint8_t buf[MAX_CODEC_SECOND_SIZE * 2];
> -int written = 0;
> +int written = 0, offset = 0;
> int ret;
> AADemuxContext *c = s->priv_data;
> uint64_t pos = avio_tell(s->pb);
> @@ -297,16 +297,33 @@ static int aa_read_packet(AVFormatContext *s, AVPacket
> *pkt)
> if (c->current_chapter_size <= 0)
> c->current_chapter_size = 0;
>
> -if (c->seek_offset > written)
> -c->seek_offset = 0; // ignore wrong estimate
> +if (c->did_seek) {
> +c->did_seek = 0;
> +
> +if (s->streams[0]->codecpar->codec_id == AV_CODEC_ID_MP3 && written
> >= MP3_FRAME_SIZE + 3) {
> +for (offset = 0; offset < MP3_FRAME_SIZE; ++offset) {
> +// find mp3 header: sync, v2, layer3, no crc, 32kbps, 22kHz,
> mono
> +if ((buf[offset + 0] ) == 0xff &&
> +(buf[offset + 1] ) == 0xf3 &&
> +(buf[offset + 2] & 0xfc) == 0x40 &&
> +(buf[offset + 3] & 0xf0) == 0xc0)
> +break;
> +}
> +if (offset == MP3_FRAME_SIZE) offset = 0; // not found, just use
> as is
> +}
> +
> +ff_update_cur_dts(s, s->streams[0],
> +(pos + offset - c->content_start - CHAPTER_HEADER_SIZE *
> (c->chapter_idx - 1))
> +* TIMEPREC);
> +}
>
> -ret = av_new_packet(pkt, written - c->seek_offset);
> +if (offset > written) offset = 0;
> +ret = av_new_packet(pkt, written - offset);
> if (ret < 0)
> return ret;
> -memcpy(pkt->data, buf + c->seek_offset, written - c->seek_offset);
> +memcpy(pkt->data, buf + offset, written - offset);
> pkt->pos = pos;
>
> -c->seek_offset = 0;
> return 0;
> }
>
> @@ -349,13 +366,7 @@ static int aa_read_seek(AVFormatContext *s,
> c->current_codec_second_size = c->codec_second_size;
> c->current_chapter_size = chapter_size - chapter_pos;
> c->chapter_idx = 1 + chapter_idx;
> -
> -// for unaligned frames, estimate offset of first frame in block (assume
> no padding)
> -if (s->streams[0]->codecpar->codec_id == AV_CODEC_ID_MP3) {
> -c->seek_offset = (MP3_FRAME_SIZE -
Re: [FFmpeg-devel] [PATCH] Avoid undefined behavior when start_time_text is -1<<63
Ok, let's use cast, new patch attached. On Mon, Jul 30, 2018 at 4:53 PM Michael Niedermayer wrote: > On Mon, Jul 30, 2018 at 01:49:24PM -0700, Fredrik Hubinette wrote: > > Is casting a negative integer to unsigned defined behavior? > > yes > > 6.3.1.3 Signed and unsigned integers > > 2 Otherwise, if the new type is unsigned, the value is converted by > repeatedly adding or > subtracting one more than the maximum value that can be represented in > the new type > until the value is in the range of the new type.49) > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > I do not agree with what you have to say, but I'll defend to the death your > right to say it. -- Voltaire > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > From e8f3a5a4ff9b89b33f4067c7aa735fff9895333e Mon Sep 17 00:00:00 2001 From: Fredrik Hubinette Date: Mon, 20 Aug 2018 12:59:32 -0700 Subject: [PATCH] avoid undefined integer overflow behavior --- libavformat/utils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/utils.c b/libavformat/utils.c index fcd4328587..b0b5e164a6 100644 --- a/libavformat/utils.c +++ b/libavformat/utils.c @@ -2666,7 +2666,7 @@ static void update_stream_timings(AVFormatContext *ic) duration = FFMAX(duration, duration1); } } -if (start_time == INT64_MAX || (start_time > start_time_text && start_time - start_time_text < AV_TIME_BASE)) +if (start_time == INT64_MAX || (start_time > start_time_text && start_time - (uint64_t)start_time_text < AV_TIME_BASE)) start_time = start_time_text; else if (start_time > start_time_text) av_log(ic, AV_LOG_VERBOSE, "Ignoring outlier non primary stream starttime %f\n", start_time_text / (float)AV_TIME_BASE); -- 2.18.0.865.gffc8e1a3cd6-goog ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] libavfilter: Removes stored DNN models. Adds support for native backend model file format in tf backend.
On 20-08-2018 11:52 PM, Sergey Lavrushkin wrote: But there are some issues. First, to use this filter for formats with chroma channels I do: ffmpeg -i in.bmp -filter_complex 'extractplanes=y+u+v[y][u][v]' -map '[y]' y.bmp -map '[u]' u.bmp -map '[v]' v.bmp ffmpeg -i y.bmp -vf sr=dnn_backend=tensorflow:model=espcn.model y2.bmp ffmpeg -i u.bmp -vf scale=iw*2:-1 u2.bmp ffmpeg -i v.bmp -vf scale=iw*2:-1 v2.bmp ffmpeg -i y2.bmp -i u2.bmp -i v2.bmp -filter_complex 'mergeplanes=0x001020:yuv444p' out.bmp Can these commands be merged into one command? Something like, ffmpeg -i in.bmp -filter_complex 'format=yuvj444p,extractplanes=y+u+v[y][u][v]; [y]sr=dnn_backend=tensorflow:model=espcn.model[y-sr]; [u]scale=iw*2:-1[u2x];[v]scale=iw*2:-1[v2x]; [y-sr][u2x][v2x]mergeplanes=0x001020:yuvj444p' out.bmp Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/opus_parser: Handle complete frames flag.
I am not entirely sure what this flag is supposed to be, since there
is no documentation where it is defined. But this was suggested by
James Almer as a fix for my encrypted Opus problems and several other
codec parsers do the same thing.
From 87dfe4d3d21a824c0fbe71dad2ebc8672b3fd2b4 Mon Sep 17 00:00:00 2001
From: Jacob Trimble
Date: Mon, 20 Aug 2018 11:25:27 -0700
Subject: [PATCH] avcodec/opus_parser: Handle complete frames flag.
Signed-off-by: Jacob Trimble
---
libavcodec/opus_parser.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/libavcodec/opus_parser.c b/libavcodec/opus_parser.c
index 28b0933900..a145fe7793 100644
--- a/libavcodec/opus_parser.c
+++ b/libavcodec/opus_parser.c
@@ -170,19 +170,24 @@ static int opus_parse(AVCodecParserContext *ctx, AVCodecContext *avctx,
ParseContext *pc= >pc;
int next, header_len;
-next = opus_find_frame_end(ctx, avctx, buf, buf_size, _len);
-
-if (s->ts_framing && next != AVERROR_INVALIDDATA &&
-ff_combine_frame(pc, next, , _size) < 0) {
-*poutbuf = NULL;
-*poutbuf_size = 0;
-return buf_size;
-}
+if (ctx->flags & PARSER_FLAG_COMPLETE_FRAMES) {
+next = buf_size;
+header_len = 0;
+} else {
+next = opus_find_frame_end(ctx, avctx, buf, buf_size, _len);
+
+if (s->ts_framing && next != AVERROR_INVALIDDATA &&
+ff_combine_frame(pc, next, , _size) < 0) {
+*poutbuf = NULL;
+*poutbuf_size = 0;
+return buf_size;
+}
-if (next == AVERROR_INVALIDDATA){
-*poutbuf = NULL;
-*poutbuf_size = 0;
-return buf_size;
+if (next == AVERROR_INVALIDDATA){
+*poutbuf = NULL;
+*poutbuf_size = 0;
+return buf_size;
+}
}
*poutbuf = buf + header_len;
--
2.18.0.865.gffc8e1a3cd6-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avformat.h: Add av_stream_remove_side_data.
On Mon, Jul 9, 2018 at 9:57 AM Jacob Trimble wrote: > > On Tue, Jul 3, 2018 at 5:59 PM Michael Niedermayer > wrote: > > > > On Tue, Jul 03, 2018 at 12:14:19PM -0700, Jacob Trimble wrote: > > > On Mon, Jul 2, 2018 at 6:07 PM Michael Niedermayer > > > wrote: > > > > > > > > On Mon, Jun 25, 2018 at 04:03:32PM -0700, Jacob Trimble wrote: > > > > > Signed-off-by: Jacob Trimble > > > > > --- > > > > > libavformat/avformat.h | 8 > > > > > libavformat/utils.c| 11 +++ > > > > > 2 files changed, 19 insertions(+) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/libavformat/avformat.h b/libavformat/avformat.h > > > > > index fdaffa5bf4..434c88837e 100644 > > > > > --- a/libavformat/avformat.h > > > > > +++ b/libavformat/avformat.h > > > > > @@ -2167,6 +2167,14 @@ AVStream *avformat_new_stream(AVFormatContext > > > > > *s, const AVCodec *c); > > > > > int av_stream_add_side_data(AVStream *st, enum AVPacketSideDataType > > > > > type, > > > > > uint8_t *data, size_t size); > > > > > > > > > > +/** > > > > > + * Removes any existing side data of the given type. > > > > > + * > > > > > + * @param st stream > > > > > + * @param type side information type > > > > > + */ > > > > > +void av_stream_remove_side_data(AVStream *st, enum > > > > > AVPacketSideDataType type); > > > > > > > > What would use this and why ? > > > > The commit message does not explain this > > > > > > > > If side data is changing it probably should be put in AVPackets or > > > > AVFrames > > > > not the stream. > > > > > > > > > > I am using this to removing the side data that contains the > > > AVEncryptionInitInfo objects once I handle them. Since an MP4 file > > > can contain multiple pssh atoms, there can be multiple > > > AVEncryptionInitInfo structs. To make it easier for me, I want to > > > remove the side data that contain them once I have handled them. This > > > means that if the AVStream contains the side data, it is because of > > > new init info I haven't seen. Since the pssh atoms are more "global" > > > it makes more sense to put them in the AVStream. > > > > I dont fully understand but > > If you intend to remove things while reading the "header" of a mp4 file > > these things probably should not be in side data to begin with but be > > internal to the demuxer. > > > > otherwise, after the header or outside the demuxer removal seems a "no go" > > but i may misunderstand what you intend to do. Please explain if iam > > totally off here with how i interpret this > > > > One simple API good vs. bad test btw should be to consider that theres > > a demuxer connected to a muxer. > > If this does not work to produce a equivalent file the API is not good > > for example if you change side data in the AVStream in the middle between > > outputing packets i would not expect the muxer to see this and thus not > > be able to reproduce this in the stored file. > > > > Also if you mess with the demxuers side data from outside, not only > > will this result in undefined behavior it also might be that you still > > need it when for example seeking back to the start > > > > again maybe i totally misunderstand what you intend here > > > > I would expect the muxer to do what I am doing, it would remove the > side data when it handles the data so it doesn't have to keep a copy > of all the init data it has seen. > > For example, consider converting fragmented MP4 into a different > fragmented MP4. The pssh atoms can appear inside the fragments, so > the muxer should see the new pssh atoms and add them to the > current/next fragment while muxing. The best way I see is to check if > the side data exists, handle it, and remove the side data. The > alternative would be to convert the side data to the > AVEncryptionInitInfo struct at every step, then compare each element > against a copy the muxer has. This is extremely slow and requires > storing the init data several different ways. > > Another alternative would be to put the side data on the frames, but > this doesn't seem right either. The init info is "header" data, so it > seems weird to put it on a random frame, and putting the data on every > frame would be more duplication and require the muxer/app to compare > them for every frame to detect new init info. > Does that make sense? Is this something that could be merged? > > > > [...] > > -- > > 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/matroskadec: Parse encryption init info from streams.
On Thu, Aug 9, 2018 at 9:14 AM Jacob Trimble wrote:
>
> On Wed, Aug 1, 2018 at 1:46 PM Jacob Trimble wrote:
> >
> > On Mon, Jul 23, 2018 at 2:01 PM Jacob Trimble wrote:
> > >
> > > On Thu, Jul 12, 2018 at 5:05 PM Jacob Trimble wrote:
> > > >
> > > > Signed-off-by: Jacob Trimble
> > > > ---
> > > > libavformat/matroskadec.c | 43 +--
> > > > 1 file changed, 32 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> > > > index 1ded431b80..bfef329e59 100644
> > > > --- a/libavformat/matroskadec.c
> > > > +++ b/libavformat/matroskadec.c
> > > > @@ -2080,7 +2080,8 @@ static int matroska_parse_tracks(AVFormatContext
> > > > *s)
> > > > int extradata_offset = 0;
> > > > uint32_t fourcc = 0;
> > > > AVIOContext b;
> > > > -char* key_id_base64 = NULL;
> > > > +char* key_id = NULL;
> > > > +int key_id_size = 0;
> > > > int bit_depth = -1;
> > > >
> > > > /* Apply some sanity checks. */
> > > > @@ -2133,14 +2134,8 @@ static int matroska_parse_tracks(AVFormatContext
> > > > *s)
> > > > if (encodings[0].encryption.key_id.size > 0) {
> > > > /* Save the encryption key id to be stored later
> > > > as a
> > > > metadata tag. */
> > > > -const int b64_size =
> > > > AV_BASE64_SIZE(encodings[0].encryption.key_id.size);
> > > > -key_id_base64 = av_malloc(b64_size);
> > > > -if (key_id_base64 == NULL)
> > > > -return AVERROR(ENOMEM);
> > > > -
> > > > -av_base64_encode(key_id_base64, b64_size,
> > > > -
> > > > encodings[0].encryption.key_id.data,
> > > > -
> > > > encodings[0].encryption.key_id.size);
> > > > +key_id = encodings[0].encryption.key_id.data;
> > > > +key_id_size = encodings[0].encryption.key_id.size;
> > > > } else {
> > > > encodings[0].scope = 0;
> > > > av_log(matroska->ctx, AV_LOG_ERROR,
> > > > @@ -2198,14 +2193,40 @@ static int
> > > > matroska_parse_tracks(AVFormatContext *s)
> > > >
> > > > st = track->stream = avformat_new_stream(s, NULL);
> > > > if (!st) {
> > > > -av_free(key_id_base64);
> > > > return AVERROR(ENOMEM);
> > > > }
> > > >
> > > > -if (key_id_base64) {
> > > > +if (key_id) {
> > > > +AVEncryptionInitInfo *init_info;
> > > > +uint8_t *side_data;
> > > > +size_t side_data_size;
> > > > +const int b64_size = AV_BASE64_SIZE(key_id_size);
> > > > +char *key_id_base64 = av_malloc(b64_size);
> > > > +if (!key_id_base64)
> > > > +return AVERROR(ENOMEM);
> > > > +av_base64_encode(key_id_base64, b64_size, key_id,
> > > > key_id_size);
> > > > +
> > > > /* export encryption key id as base64 metadata tag */
> > > > av_dict_set(>metadata, "enc_key_id", key_id_base64, 0);
> > > > av_freep(_id_base64);
> > > > +
> > > > +
> > > > +/* Convert the key ID to a generic encryption init info */
> > > > +init_info = av_encryption_init_info_alloc(/*
> > > > system_id_size */ 0, /* num_key_ids */ 1,
> > > > + /* key_id_size
> > > > */ key_id_size, /* data_size */ 0);
> > > > +if (!init_info)
> > > > +return AVERROR(ENOMEM);
> > > > +memcpy(init_info->key_ids[0], key_id, key_id_size);
> > > > +side_data =
> > > > av_encryption_init_info_add_side_data(init_info, _data_size);
> > > > +av_encryption_init_info_free(init_info);
> > > > +if (!side_data)
> > > > +return AVERROR(ENOMEM);
> > > > +ret = av_stream_add_side_data(st,
> > > > AV_PKT_DATA_ENCRYPTION_INIT_INFO,
> > > > + side_data, side_data_size);
> > > > +if (ret < 0) {
> > > > +av_free(side_data);
> > > > +return ret;
> > > > +}
> > > > }
> > > >
> > > > if (!strcmp(track->codec_id, "V_MS/VFW/FOURCC") &&
> > > > --
> > > > 2.18.0.203.gfac676dfb9-goog
> > > >
> > >
> > > Ping.
> >
> > Ping.
>
> Ping (only 43 lines changed, in "review" for 28 days...)
Ping.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/matroska: Parse generic encryption info from packets.
On Mon, Aug 13, 2018 at 9:01 PM James Almer wrote:
>
> On 8/14/2018 12:50 AM, James Almer wrote:
> > On 7/12/2018 8:45 PM, Jacob Trimble wrote:
> >> I am currently seeing a problem with this when using Opus audio. In
> >> read_frame_internal, it will try to parse the resulting packet. For
> >> video, which uses subsample encryption, it is able to parse the
> >> headers; but for Opus, which uses full-sample encryption, it fails to
> >> parse the headers. This causes the read_frame_internal to drop the
> >> packet.
> >>
> >> I have traced a workaround to opus_parse in opus_parser.c: instead of
> >> setting poutbuf to NULL, set it to the buffer and just pass the packet
> >> to the app to handle it. The frame will be decrypted before passing
> >> to the decoder. I can't just disable parsing in the demuxer because I
> >> want to parse the packets for clear content and when using subsample
> >> encryption.
> >>
> >> Does anyone have any other ideas to work around this? Is there a way
> >> to allow parsing but ignore errors?
> > Try the attached diff to see if it fixes the issue (It makes the parser
> > not bother trying to assemble packets from what could be incomplete data
> > if the source is a demuxer that guarantees the propagation of complete
> > packets).
> >
Yep that fixed it, thanks. I sent out a patch to implement that
(since other parsers do it, it seems like the correct thing to do).
In that case, this patch works well and is ready to review/merge.
> >
> > opus.diff
> >
> >
> > diff --git a/libavcodec/opus_parser.c b/libavcodec/opus_parser.c
> > index 28b0933900..e8d157356c 100644
> > --- a/libavcodec/opus_parser.c
> > +++ b/libavcodec/opus_parser.c
> > @@ -170,6 +170,9 @@ static int opus_parse(AVCodecParserContext *ctx,
> > AVCodecContext *avctx,
> > ParseContext *pc= >pc;
> > int next, header_len;
>
> Err, with the change below this should be initialized to 0 now. Sorry.
>
> >
> > +if (s->flags & PARSER_FLAG_COMPLETE_FRAMES) {
> > +next = buf_size;
> > +} else {
> > next = opus_find_frame_end(ctx, avctx, buf, buf_size, _len);
> >
> > if (s->ts_framing && next != AVERROR_INVALIDDATA &&
> > @@ -184,6 +187,7 @@ static int opus_parse(AVCodecParserContext *ctx,
> > AVCodecContext *avctx,
> > *poutbuf_size = 0;
> > return buf_size;
> > }
> > +}
> >
> > *poutbuf = buf + header_len;
> > *poutbuf_size = buf_size - header_len;
> >
>
> ___
> 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/mov: Allow saio/saiz in clear content.
On Wed, Aug 15, 2018 at 2:38 PM Michael Niedermayer
wrote:
>
> [...]
>
> > mov.c |6 ++
> > 1 file changed, 6 insertions(+)
> > 0e583b4ad11852ce38a2b945644e178b7f13a42f
> > 0001-avformat-mov-Allow-saio-saiz-in-clear-content-v2.patch
> > From 256880aca517f64257eb28342a656867d90307a7 Mon Sep 17 00:00:00 2001
> > From: Jacob Trimble
> > Date: Tue, 14 Aug 2018 10:18:55 -0700
> > Subject: [PATCH] avformat/mov: Allow saio/saiz in clear content.
>
> This code is used in saio/saiz/senc. The message only mentions the first
> 2.
>
senc shouldn't appear in clear content, so it shouldn't change
anything. Changed the commit message to include that.
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Whats the most studid thing your enemy could do ? Blow himself up
> Whats the most studid thing you could do ? Give up your rights and
> freedom because your enemy blew himself up.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
From 18e6aba25364b988ac52413949f62eef03d6c648 Mon Sep 17 00:00:00 2001
From: Jacob Trimble
Date: Tue, 14 Aug 2018 10:18:55 -0700
Subject: [PATCH] avformat/mov: Allow saio/saiz in clear content.
If there is a saio/saiz in clear content, we shouldn't create the
encryption index if we don't already have one. Otherwise it will
confuse the cenc_filter.
The changed method is also used for senc atoms, but they should not
appear in clear content.
Found by Chromium's ClusterFuzz: https://crbug.com/873432
Signed-off-by: Jacob Trimble
---
libavformat/mov.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index c863047d79..ee9acdb73c 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5847,6 +5847,9 @@ static int get_current_encryption_info(MOVContext *c, MOVEncryptionIndex **encry
*sc = st->priv_data;
if (!frag_stream_info->encryption_index) {
+// If this stream isn't encrypted, don't create the index.
+if (!(*sc)->cenc.default_encrypted_sample)
+return 0;
frag_stream_info->encryption_index = av_mallocz(sizeof(*frag_stream_info->encryption_index));
if (!frag_stream_info->encryption_index)
return AVERROR(ENOMEM);
@@ -5862,6 +5865,9 @@ static int get_current_encryption_info(MOVContext *c, MOVEncryptionIndex **encry
*sc = st->priv_data;
if (!(*sc)->cenc.encryption_index) {
+// If this stream isn't encrypted, don't create the index.
+if (!(*sc)->cenc.default_encrypted_sample)
+return 0;
(*sc)->cenc.encryption_index = av_mallocz(sizeof(*frag_stream_info->encryption_index));
if (!(*sc)->cenc.encryption_index)
return AVERROR(ENOMEM);
--
2.18.0.865.gffc8e1a3cd6-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/libaomenc: Add -tile-columns/-tile-rows
These options are required for multithreaded encoding, because they set
to zero by default in av1_cx_iface.c.
Signed-off-by: Kagami Hiiragi
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index 9431179886..55cb7ff72e 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -68,6 +68,8 @@ typedef struct AOMEncoderContext {
int static_thresh;
int drop_threshold;
int noise_sensitivity;
+int tile_columns;
+int tile_rows;
} AOMContext;
static const char *const ctlidstr[] = {
@@ -75,6 +77,8 @@ static const char *const ctlidstr[] = {
[AOME_SET_CQ_LEVEL] = "AOME_SET_CQ_LEVEL",
[AOME_SET_ENABLEAUTOALTREF] = "AOME_SET_ENABLEAUTOALTREF",
[AOME_SET_STATIC_THRESHOLD] = "AOME_SET_STATIC_THRESHOLD",
+[AV1E_SET_TILE_COLUMNS] = "AV1E_SET_TILE_COLUMNS",
+[AV1E_SET_TILE_ROWS]= "AV1E_SET_TILE_ROWS",
[AV1E_SET_COLOR_RANGE] = "AV1E_SET_COLOR_RANGE",
[AV1E_SET_COLOR_PRIMARIES] = "AV1E_SET_COLOR_PRIMARIES",
[AV1E_SET_MATRIX_COEFFICIENTS] = "AV1E_SET_MATRIX_COEFFICIENTS",
@@ -449,6 +453,11 @@ static av_cold int aom_init(AVCodecContext *avctx,
if (ctx->crf >= 0)
codecctl_int(avctx, AOME_SET_CQ_LEVEL, ctx->crf);
+if (ctx->tile_columns >= 0)
+codecctl_int(avctx, AV1E_SET_TILE_COLUMNS, ctx->tile_columns);
+if (ctx->tile_rows >= 0)
+codecctl_int(avctx, AV1E_SET_TILE_ROWS, ctx->tile_rows);
+
codecctl_int(avctx, AV1E_SET_COLOR_PRIMARIES, avctx->color_primaries);
codecctl_int(avctx, AV1E_SET_MATRIX_COEFFICIENTS, avctx->colorspace);
codecctl_int(avctx, AV1E_SET_TRANSFER_CHARACTERISTICS, avctx->color_trc);
@@ -746,6 +755,8 @@ static const AVOption options[] = {
{ "static-thresh","A change threshold on blocks below which they will
be skipped by the encoder", OFFSET(static_thresh), AV_OPT_TYPE_INT, { .i64 = 0
}, 0, INT_MAX, VE },
{ "drop-threshold", "Frame drop threshold", offsetof(AOMContext,
drop_threshold), AV_OPT_TYPE_INT, {.i64 = 0 }, INT_MIN, INT_MAX, VE },
{ "noise-sensitivity", "Noise sensitivity", OFFSET(noise_sensitivity),
AV_OPT_TYPE_INT, {.i64 = 0 }, 0, 4, VE},
+{ "tile-columns", "Number of tile columns to use, log2",
OFFSET(tile_columns), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},
+{ "tile-rows", "Number of tile rows to use, log2", OFFSET(tile_rows),
AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},
{ NULL }
};
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Avoid undefined behavior by limiting PTS to 62 bits in ogg decoder
I'm uncertain what the right thing to do here is. Oggdec generates PTS values which are a bit crazy, and the generic code that deals which those values encounters undefined behavior. It seems like there should be some input validation happening somewhere, but it's not clear to me if that belongs in oggdec or somewhere else. On Mon, Jul 30, 2018 at 4:23 PM Michael Niedermayer wrote: > On Mon, Jul 30, 2018 at 01:31:59PM -0700, Fredrik Hubinette wrote: > > Not sure how to update the commit message. > > git commit --amend > > > > The undefined behavior occurs in av_add_stable, which is called from > > compute_packet_fields. > > In that code PTS can be equal to -(1<<63), which then causes a int64_t to > > overflow. > > This does not sound specific to oggdec. Thus a change in oggdec would > likely > not fix it outside ogg. > Or am i missing something ? > > > thx > > > > > On Wed, Jul 18, 2018 at 4:04 AM Michael Niedermayer > > > wrote: > > > > > On Mon, Jul 16, 2018 at 04:32:14PM -0700, Fredrik Hubinette wrote: > > > > With some (garbled) OGG data, PTS can overflow causing undefined > > > behavior. > > > > This patch avoids that by zeroing out PTS values greater than 2^62. > > > > > > > oggdec.h |3 ++- > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > ff003b78842c7724ccc1a42f9584b1f8aa0b0b3d > > > 0001-Avoid-undefined-behavior-by-limiting-PTS-to-62-bits-.patch > > > > From 26a8582bc04f5bddc037ffcce99025e2f977abe0 Mon Sep 17 00:00:00 > 2001 > > > > From: Fredrik Hubinette > > > > Date: Mon, 16 Jul 2018 14:54:43 -0700 > > > > Subject: [PATCH] Avoid undefined behavior by limiting PTS to 62 bits > in > > > ogg > > > > decoder > > > > > > > > --- > > > > libavformat/oggdec.h | 3 ++- > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > I think someone reading this commit message would like to know more > > > about where that undefined behaviour occurs and how this is guranteeing > > > to fix it > > > > > > > > > [...] > > > > > > -- > > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > > > "Nothing to hide" only works if the folks in power share the values of > > > you and everyone you know entirely and always will -- Tom Scott > > > > > > ___ > > > 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 > > -- > 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 > ___ > 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] lavf/matroska: Allow AV1 in WebM
On Mon, Aug 20, 2018 at 7:09 PM James Almer wrote:
>
> On 8/20/2018 1:44 PM, Kagami Hiiragi wrote:
> > Nothing prevents it to work except this check. AV1 is already supported
> > by Matroska muxer and aomenc produces WebM/AV1 files as well.
> >
> > Signed-off-by: Kagami Hiiragi
> >
> > diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> > index 09a62e1922..76cb124221 100644
> > --- a/libavformat/matroskaenc.c
> > +++ b/libavformat/matroskaenc.c
> > @@ -1296,11 +1296,12 @@ static int mkv_write_track(AVFormatContext *s,
> > MatroskaMuxContext *mkv,
> >
> > if (mkv->mode == MODE_WEBM && !(par->codec_id == AV_CODEC_ID_VP8 ||
> > par->codec_id == AV_CODEC_ID_VP9 ||
> > +par->codec_id == AV_CODEC_ID_AV1 ||
> > par->codec_id == AV_CODEC_ID_OPUS ||
> > par->codec_id == AV_CODEC_ID_VORBIS ||
> > par->codec_id == AV_CODEC_ID_WEBVTT)) {
> > av_log(s, AV_LOG_ERROR,
> > - "Only VP8 or VP9 video and Vorbis or Opus audio and WebVTT
> > subtitles are supported for WebM.\n");
> > + "Only VP8 or VP9 or AV1 video and Vorbis or Opus audio and
> > WebVTT subtitles are supported for WebM.\n");
> > return AVERROR(EINVAL);
> > }
>
> I'm not against this, but i was thinking on at least waiting for libaom
> and libwebm to produce complaint files first. Right now, they are not
> writing anything in CodecPrivate.
>
> See https://bugs.chromium.org/p/aomedia/issues/detail?id=2027
Should definitely wait for the spec to be finalized before allowing
this, and only generate fully compliant files then.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/vf_libvmaf: update to use libvmaf v1.3.9
On 8/20/18, Carl Eugen Hoyos wrote: > 2018-08-20 7:15 GMT+02:00, Gyan Doshi : >> On 20-08-2018 03:17 AM, Carl Eugen Hoyos wrote: >> >>> I believe that if a general option exists (as in this case), it is a bad >>> idea to have a specifically targeted option that has to be used instead. >> >> The user may not want the thread pool to be available for any other >> threaded filters in the graph. > > I wonder if this is really useful (and especially if the cost of having > an additional option for the user to know is really worth this tiny > advantage). > > The more I think about it, the more it is obvious to me that 1) the > filter should use the default thread number for all filters and that 2) > an option may be specified to overwrite this number (if this is really > needed). Both cases are already present. Please learn to read and understand documentation. > >> Encoding/decoding threads can have stream specifiers suffixed to >> limit scope. The filter_[complex_]threads options don't. > > Ok. > We have -filter_complex_threads for that, so no. >>> >>> For which use-case is this an advantage? >> >> For when the intended recipient is a complex filtergraph. > > For which use-case is it an advantage that there is not one > option to tell the filter-chain the number of threads to use, > no matter if it is a simple or a complex filter-chain, but to > have one option to use for the simple and a different option > for the complex case? Again, there is already option, please consult documentation. This filter does not use lavfi threads so it should not use lavfi threads option. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/matroska: Allow AV1 in WebM
On 8/20/2018 1:44 PM, Kagami Hiiragi wrote:
> Nothing prevents it to work except this check. AV1 is already supported
> by Matroska muxer and aomenc produces WebM/AV1 files as well.
>
> Signed-off-by: Kagami Hiiragi
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index 09a62e1922..76cb124221 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -1296,11 +1296,12 @@ static int mkv_write_track(AVFormatContext *s,
> MatroskaMuxContext *mkv,
>
> if (mkv->mode == MODE_WEBM && !(par->codec_id == AV_CODEC_ID_VP8 ||
> par->codec_id == AV_CODEC_ID_VP9 ||
> +par->codec_id == AV_CODEC_ID_AV1 ||
> par->codec_id == AV_CODEC_ID_OPUS ||
> par->codec_id == AV_CODEC_ID_VORBIS ||
> par->codec_id == AV_CODEC_ID_WEBVTT)) {
> av_log(s, AV_LOG_ERROR,
> - "Only VP8 or VP9 video and Vorbis or Opus audio and WebVTT
> subtitles are supported for WebM.\n");
> + "Only VP8 or VP9 or AV1 video and Vorbis or Opus audio and
> WebVTT subtitles are supported for WebM.\n");
> return AVERROR(EINVAL);
> }
I'm not against this, but i was thinking on at least waiting for libaom
and libwebm to produce complaint files first. Right now, they are not
writing anything in CodecPrivate.
See https://bugs.chromium.org/p/aomedia/issues/detail?id=2027
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/matroska: Allow AV1 in WebM
Nothing prevents it to work except this check. AV1 is already supported
by Matroska muxer and aomenc produces WebM/AV1 files as well.
Signed-off-by: Kagami Hiiragi
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 09a62e1922..76cb124221 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -1296,11 +1296,12 @@ static int mkv_write_track(AVFormatContext *s,
MatroskaMuxContext *mkv,
if (mkv->mode == MODE_WEBM && !(par->codec_id == AV_CODEC_ID_VP8 ||
par->codec_id == AV_CODEC_ID_VP9 ||
+par->codec_id == AV_CODEC_ID_AV1 ||
par->codec_id == AV_CODEC_ID_OPUS ||
par->codec_id == AV_CODEC_ID_VORBIS ||
par->codec_id == AV_CODEC_ID_WEBVTT)) {
av_log(s, AV_LOG_ERROR,
- "Only VP8 or VP9 video and Vorbis or Opus audio and WebVTT
subtitles are supported for WebM.\n");
+ "Only VP8 or VP9 or AV1 video and Vorbis or Opus audio and
WebVTT subtitles are supported for WebM.\n");
return AVERROR(EINVAL);
}
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/vf_libvmaf: update to use libvmaf v1.3.9
2018-08-20 7:15 GMT+02:00, Gyan Doshi : > On 20-08-2018 03:17 AM, Carl Eugen Hoyos wrote: > >> I believe that if a general option exists (as in this case), it is a bad >> idea to have a specifically targeted option that has to be used instead. > > The user may not want the thread pool to be available for any other > threaded filters in the graph. I wonder if this is really useful (and especially if the cost of having an additional option for the user to know is really worth this tiny advantage). The more I think about it, the more it is obvious to me that 1) the filter should use the default thread number for all filters and that 2) an option may be specified to overwrite this number (if this is really needed). > Encoding/decoding threads can have stream specifiers suffixed to > limit scope. The filter_[complex_]threads options don't. Ok. >>> We have -filter_complex_threads for that, so no. >> >> For which use-case is this an advantage? > > For when the intended recipient is a complex filtergraph. For which use-case is it an advantage that there is not one option to tell the filter-chain the number of threads to use, no matter if it is a simple or a complex filter-chain, but to have one option to use for the simple and a different option for the complex case? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] doc/filters: Add double-pass example for loudnorm
2018-08-20 7:30 GMT+02:00, Gyan Doshi : > On 20-08-2018 03:27 AM, Marvin Scholz wrote: > >> +@example >> +$ ffmpeg -i input -map 0:a -af loudnorm=I=-23:TP=-1:print_format=summary >> -f null - >> + >> +[...] >> +Input Integrated: -9.0 LUFS >> +Input True Peak: +1.5 dBTP >> +Input LRA: 9.4 LU >> +Input Threshold: -19.5 LUFS >> +@end example >> + >> +Then pass the input measurements to the next run that produces the >> result: >> + >> +@example >> +ffmpeg -i input -af >> loudnorm=I=-23:TP=-1:measured_I=-9.0:measured_TP=1.5: >> measured_LRA=9.4:measured_thresh=-19.5:print_format=summary >> output > > a) Your first pass command will run the filter for all audio streams in > the input, but your 2nd pass command won't. Suggest you remove the mapping. Or use -map 0:a:0 Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] swscale/input : avoid float calc for GrayFloat to Gray16 conv
Hello, Patch in attach modify GrayFloat to Gray16 conversion using the same method currently use inside exr decoder (no float calc) duplicate the float_to_uint func inside swscale_internal Martin 0004-swscale-input-avoid-float-calc-for-grayFloat-to-uint.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: do not add --fsanitize= if coverage is tested
On 8/19/2018 5:40 PM, Michael Niedermayer wrote:
> Found-by: Max Moroz
> Signed-off-by: Michael Niedermayer
> ---
> configure | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 9b5421d5a8..b9c9d0b307 100755
> --- a/configure
> +++ b/configure
> @@ -3964,7 +3964,7 @@ set >> $logfile
>
> test -n "$valgrind" && toolchain="valgrind-memcheck"
>
> -enabled ossfuzz && ! echo $CFLAGS | grep -q -- "-fsanitize=" &&{
> +enabled ossfuzz && ! echo $CFLAGS | grep -q -- "-fsanitize=" && ! echo
> $CFLAGS | grep -q -- "-fcoverage-mapping" &&{
What part of configure adds -fcoverage-mapping? Or is this looking for a
user set cflag?
The subject should be more specific. This is specific for ossfuzz, not
other toolchains that add -fsanitize like asan/usan.
> add_cflags -fsanitize=address,undefined
> -fsanitize-coverage=trace-pc-guard,trace-cmp -fno-omit-frame-pointer
> add_ldflags -fsanitize=address,undefined
> -fsanitize-coverage=trace-pc-guard,trace-cmp
> }
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/psd : add support for gray float (WIP)
Hello, Better patch in attach (reuse the same "copy part" than uint 8bpc and 16 bpc pix fmt) Works only after applying swscale patch in discussion : swscale : hScale16To19 : limit shift for float(32bits) input Can be test with : ./ffmpeg -i lena-gray_float.psd -pix_fmt gray8 res8.png ./ffmpeg -i lena-gray_float.psd res16.png Martin 0001-avcodec-psd-add-support-for-gray-float.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] swscale : hScale16To19 : limit shift for float(32bits) input
Updated patch in attach also fix the conversion when using float gray as input, and 8bpc uint as output Martin 0002-swscale-treat-float-input-data-as-uint-16bpc.patch Description: Binary data 0003-swscale-swscale-small-cosmetic.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] doc/filters: Add double-pass example for loudnorm
On 20 Aug 2018, at 7:30, Gyan Doshi wrote: On 20-08-2018 03:27 AM, Marvin Scholz wrote: +@example +$ ffmpeg -i input -map 0:a -af loudnorm=I=-23:TP=-1:print_format=summary -f null - + +[...] +Input Integrated: -9.0 LUFS +Input True Peak: +1.5 dBTP +Input LRA: 9.4 LU +Input Threshold: -19.5 LUFS +@end example + +Then pass the input measurements to the next run that produces the result: + +@example +ffmpeg -i input -af loudnorm=I=-23:TP=-1:measured_I=-9.0:measured_TP=1.5:measured_LRA=9.4:measured_thresh=-19.5:print_format=summary output a) Your first pass command will run the filter for all audio streams in the input, but your 2nd pass command won't. Suggest you remove the mapping. Oh indeed, thanks. b) Except for a particular set of conditions*, loudnorm will resample the audio to 192 kHz. ffmpeg may then resample the result to the highest supported rate by the encoder. For native AAC, this will be 96 kHz; for PCM, it will remain to 192kHz. Some (many ?) players, especially web ones, don't support these sampling rates. It's advised to insert aresample afterwards e.g. aresample=48000 Sure but this is already mentioned in the documentation so I thought it would make the example needlessly complex as I wanted to focus it on the two-pass aspect. But I can add that. *if all of these conditions are met: linear is true and enabled; target LRA is equal or greater than input LRA; target TP is equal or greater than input LRA after adjusting for integrated loudness change. 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 1/2] lavf/hlsenc: fix mixed declarations and code warning.
> 在 2018年8月20日，下午7:13，Jun Zhao 写道：
>
> fix the build warning for "ISO C90 forbids mixed declarations and code"
>
> Signed-off-by: Jun Zhao
> ---
> libavformat/hlsenc.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 43e6fc8..c261016 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2152,6 +2152,7 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> uint8_t *buffer = NULL;
> VariantStream *vs = NULL;
> AVDictionary *options = NULL;
> +char *old_filename = NULL;
>
> for (i = 0; i < hls->nb_varstreams; i++) {
> vs = >var_streams[i];
> @@ -2218,7 +2219,6 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
>
> }
>
> -char *old_filename = NULL;
> if (vs->packets_written && can_split && av_compare_ts(pkt->pts -
> vs->start_pts, st->time_base,
> end_pts,
> AV_TIME_BASE_Q) >= 0) {
> int64_t new_start_pos;
> --
> 1.7.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
LGTM
Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] lavf/hlsenc: fix mixed declarations and code warning.
fix the build warning for "ISO C90 forbids mixed declarations and code"
Signed-off-by: Jun Zhao
---
libavformat/hlsenc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 43e6fc8..c261016 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2152,6 +2152,7 @@ static int hls_write_packet(AVFormatContext *s, AVPacket
*pkt)
uint8_t *buffer = NULL;
VariantStream *vs = NULL;
AVDictionary *options = NULL;
+char *old_filename = NULL;
for (i = 0; i < hls->nb_varstreams; i++) {
vs = >var_streams[i];
@@ -2218,7 +2219,6 @@ static int hls_write_packet(AVFormatContext *s, AVPacket
*pkt)
}
-char *old_filename = NULL;
if (vs->packets_written && can_split && av_compare_ts(pkt->pts -
vs->start_pts, st->time_base,
end_pts,
AV_TIME_BASE_Q) >= 0) {
int64_t new_start_pos;
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] lavc/libkvazaar: fix incompatible pointer type.
fix the waring: libavcodec/libkvazaar.c:210:27: warning: passing argument 3 of
‘av_image_copy’ from incompatible pointer type [-Wincompatible-pointer-types]
frame->data, frame->linesize,
^
In file included from libavcodec/libkvazaar.c:31:0:
./libavutil/imgutils.h:119:6: note: expected ‘const uint8_t ** {aka const
unsigned char **}’ but argument is of type ‘uint8_t * const* {aka unsigned char
* const*}’
void av_image_copy(uint8_t *dst_data[4], int dst_linesizes[4],
Signed-off-by: Jun Zhao
---
libavcodec/libkvazaar.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
index 41a1bbb..5bc5b4e 100644
--- a/libavcodec/libkvazaar.c
+++ b/libavcodec/libkvazaar.c
@@ -207,7 +207,7 @@ static int libkvazaar_encode(AVCodecContext *avctx,
0
};
av_image_copy(input_pic->data, dst_linesizes,
- frame->data, frame->linesize,
+ (const uint8_t **)frame->data, frame->linesize,
frame->format, frame->width, frame->height);
}
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] swscale : hScale16To19 : limit shift for float(32bits) input
Hello, New patch in attach Add an if case for float input, in order to define the shift value. I try to add some details in the commit msg. Pass fate test for me (Mac os 10.12, x86_64). Martin 0002-swscale-treat-float-input-data-as-uint-16bpc.patch Description: Binary data 0003-swscale-swscale-small-cosmetic.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
