Re: [FFmpeg-devel] [PATCH 3/3] mpegvideo_parser: fix indentation of an if statement

[Paul B Mahol]

On 3/6/18, Jan Ekstroem  wrote:
> On Sun, Feb 11, 2018 at 4:37 PM, Jan Ekstroem  wrote:
>> From: Masaki Tanaka 
>>
>> ---
>>  libavcodec/mpegvideo_parser.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/mpegvideo_parser.c b/libavcodec/mpegvideo_parser.c
>> index 4f554b684e..ecf7c28e72 100644
>> --- a/libavcodec/mpegvideo_parser.c
>> +++ b/libavcodec/mpegvideo_parser.c
>> @@ -63,7 +63,7 @@ static void
>> mpegvideo_extract_headers(AVCodecParserContext *s,
>>  s->output_picture_number = (buf[0] << 2) | (buf[1] >> 6);
>>  s->pict_type = (buf[1] >> 3) & 7;
>>  if (bytes_left >= 4)
>> -vbv_delay = ((buf[1] & 0x07) << 13) | (buf[2] << 5) |
>> (buf[3]  >> 3);
>> +vbv_delay = ((buf[1] & 0x07) << 13) | (buf[2] << 5) |
>> (buf[3] >> 3);
>>  }
>>  break;
>>  case SEQ_START_CODE:
>> --
>> 2.14.3
>>
>
> Ping.

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

Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: disable h264 look_ahead by default

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Tuesday, March 6, 2018 8:32 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: disable h264 look_ahead
> by default
> 
> On 01/03/18 05:20, Zhong Li wrote:
> > Look_ahead can provide quality improvements, but would better disable it
> by default due to some reasons:
> > 1. It is only available for some codecs (e.g. HEVC is not supported) on 
> > Intel
> >Haswell and plus platforms. Thus means it will be failed on some
> platforms.
> > 2. It significantly increases encoding latency and memory consumption.
> > 3. It may overwrite some other options such as CBR and CAVLC.
> >
> > Signed-off-by: Zhong Li 
> > ---
> >  libavcodec/qsvenc_h264.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c index
> > 09e4c0e..e01a2a3 100644
> > --- a/libavcodec/qsvenc_h264.c
> > +++ b/libavcodec/qsvenc_h264.c
> > @@ -109,7 +109,7 @@ static const AVOption options[] = {
> >  { "max_dec_frame_buffering", "Maximum number of frames
> buffered in the DPB", OFFSET(qsv.max_dec_frame_buffering),
> AV_OPT_TYPE_INT, { .i64 = 0 },   0, UINT16_MAX, VE },
> >
> >  #if QSV_HAVE_LA
> > -{ "look_ahead",   "Use VBR algorithm with look ahead",
> OFFSET(qsv.look_ahead),   AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, VE },
> > +{ "look_ahead",   "Use VBR algorithm with look ahead",
> OFFSET(qsv.look_ahead),   AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE },
> >  { "look_ahead_depth", "Depth of look ahead in number frames",
> > OFFSET(qsv.look_ahead_depth), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 100,
> > VE },  #endif  #if QSV_HAVE_LA_DS
> >
> 
> I agree with everything you've said, so applied.

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

Re: [FFmpeg-devel] [PATCH v2 1/1] libavformat/hlsenc: Option to set timeout for socket I/O operation

[Steven Liu]

> On 5 Mar 2018, at 17:41, rpata...@akamai.com wrote:
> 
> From: Ravindra 
> 
> ---
> doc/muxers.texi  | 3 +++
> libavformat/hlsenc.c | 5 -
> 2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index c156ec0..3a63da7 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -964,6 +964,9 @@ publishing it repeatedly every after 30 segments i.e. 
> every after 60s.
> @item http_persistent
> Use persistent HTTP connections. Applicable only for HTTP output.
> 
> +@item timeout
> +Set timeout for socket I/O operations. Applicable only for HTTP output.
> +
> @end table
> 
> @anchor{ico}
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 08fe0aa..5d462da 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -224,6 +224,7 @@ typedef struct HLSContext {
> int http_persistent;
> AVIOContext *m3u8_out;
> AVIOContext *sub_m3u8_out;
> +int64_t timeout;
> } HLSContext;
> 
> static int mkdir_p(const char *path) {
> @@ -305,7 +306,8 @@ static void set_http_options(AVFormatContext *s, 
> AVDictionary **options, HLSCont
> av_dict_set(options, "user_agent", c->user_agent, 0);
> if (c->http_persistent)
> av_dict_set_int(options, "multiple_requests", 1, 0);
> -
> +if (c->timeout >= 0)
> +av_dict_set_int(options, "timeout", c->timeout, 0);
> }
> 
> static void write_codec_attr(AVStream *st, VariantStream *vs) {
> @@ -2792,6 +2794,7 @@ static const AVOption options[] = {
> {"master_pl_name", "Create HLS master playlist with this name", 
> OFFSET(master_pl_name), AV_OPT_TYPE_STRING, {.str = NULL},  0, 0,E},
> {"master_pl_publish_rate", "Publish master play list every after this 
> many segment intervals", OFFSET(master_publish_rate), AV_OPT_TYPE_INT, {.i64 
> = 0}, 0, UINT_MAX, E},
> {"http_persistent", "Use persistent HTTP connections", 
> OFFSET(http_persistent), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
> +{"timeout", "set timeout for socket I/O operations", OFFSET(timeout), 
> AV_OPT_TYPE_DURATION, { .i64 = -1 }, -1, INT_MAX, .flags = E },
> { NULL },
> };
> 
> -- 
> 1.9.1
> 

Will apply!

Thanks
Steven





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

[FFmpeg-devel] GSoC

[Dylan Fernando]

Hi,

I am Dylan Fernando. I am a Computer Science student from Australia. I am
new to FFmpeg and I wish to apply for GSoC this year.
I would like to do the Video filtering with OpenCL project and I have a few
questions. Would trying to implement an opencl version of vf_fade be a good
idea for the qualification task, or would I be better off using a different
filter?

Also, I’m having a bit of trouble with running unsharp_opencl. I tried
running:
ffmpeg -hide_banner -nostats -v verbose -init_hw_device opencl=ocl:0.1
-filter_hw_device ocl -i space.mpg -filter_complex unsharp_opencl output.mp4

but I got the error:
[AVHWDeviceContext @ 0x7fdac050c700] 0.1: Apple / Intel(R) Iris(TM)
Graphics 6100
[mpeg @ 0x7fdac3132600] max_analyze_duration 500 reached at 5005000
microseconds st:0
Input #0, mpeg, from 'space.mpg':
  Duration: 00:00:21.99, start: 0.387500, bitrate: 6108 kb/s
Stream #0:0[0x1e0]: Video: mpeg2video (Main), 1 reference frame,
yuv420p(tv, bt470bg, bottom first, left), 720x480 [SAR 8:9 DAR 4:3], 6000
kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Stream mapping:
  Stream #0:0 (mpeg2video) -> unsharp_opencl
  unsharp_opencl -> Stream #0:0 (mpeg4)
Press [q] to stop, [?] for help
[graph 0 input from stream 0:0 @ 0x7fdac0418800] w:720 h:480 pixfmt:yuv420p
tb:1/9 fr:3/1001 sar:8/9 sws_param:flags=2
[auto_scaler_0 @ 0x7fdac05232c0] w:iw h:ih flags:'bilinear' interl:0
[Parsed_unsharp_opencl_0 @ 0x7fdac0715a80] auto-inserting filter
'auto_scaler_0' between the filter 'graph 0 input from stream 0:0' and the
filter 'Parsed_unsharp_opencl_0'
Impossible to convert between the formats supported by the filter 'graph 0
input from stream 0:0' and the filter 'auto_scaler_0'
Error reinitializing filters!
Failed to inject frame into filter network: Function not implemented
Error while processing the decoded data for stream #0:0
Conversion failed!

How do I correctly run unsharp_opencl? Should I be running it on a
different video file?

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

Re: [FFmpeg-devel] [PATCH] checkasm/hevc_sao : add hevc_sao for checkasm

[Yingming Fan]

Hi there.

We are working on add some neon optimization for hevc decoder. But before 
submit neon codes, i'd like to submit some checkasm codes. First one will be 
checkasm codes of SAO.

I tested this path under MacOS 10.13.3 and Debian, all FATE case passed.

So will anyone review this patch?

Yingming Fan

> On 3 Mar 2018, at 8:38 PM, Martin Vignali  wrote:
> 
> Works for me on MacOs 10.12 (x86_64 and x86_32).
> 
> Martin
> ___
> 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] checkasm/hevc_sao : add hevc_sao for checkasm

[James Almer]

On 3/3/2018 12:15 AM, Yingming Fan wrote:
> ---
>  tests/checkasm/Makefile   |   2 +-
>  tests/checkasm/checkasm.c |   1 +
>  tests/checkasm/checkasm.h |   1 +
>  tests/checkasm/hevc_sao.c | 158 
> ++
>  tests/fate/checkasm.mak   |   1 +
>  5 files changed, 162 insertions(+), 1 deletion(-)
>  create mode 100644 tests/checkasm/hevc_sao.c
> 
> diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
> index 77bdcf6e65..0520e264e2 100644
> --- a/tests/checkasm/Makefile
> +++ b/tests/checkasm/Makefile
> @@ -23,7 +23,7 @@ AVCODECOBJS-$(CONFIG_EXR_DECODER)   += exrdsp.o
>  AVCODECOBJS-$(CONFIG_HUFFYUV_DECODER)   += huffyuvdsp.o
>  AVCODECOBJS-$(CONFIG_JPEG2000_DECODER)  += jpeg2000dsp.o
>  AVCODECOBJS-$(CONFIG_PIXBLOCKDSP)   += pixblockdsp.o
> -AVCODECOBJS-$(CONFIG_HEVC_DECODER)  += hevc_add_res.o hevc_idct.o
> +AVCODECOBJS-$(CONFIG_HEVC_DECODER)  += hevc_add_res.o hevc_idct.o 
> hevc_sao.o
>  AVCODECOBJS-$(CONFIG_UTVIDEO_DECODER)   += utvideodsp.o
>  AVCODECOBJS-$(CONFIG_V210_ENCODER)  += v210enc.o
>  AVCODECOBJS-$(CONFIG_VP9_DECODER)   += vp9dsp.o
> diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
> index a4b8aff984..fe81d139c6 100644
> --- a/tests/checkasm/checkasm.c
> +++ b/tests/checkasm/checkasm.c
> @@ -116,6 +116,7 @@ static const struct {
>  #if CONFIG_HEVC_DECODER
>  { "hevc_add_res", checkasm_check_hevc_add_res },
>  { "hevc_idct", checkasm_check_hevc_idct },
> +{ "hevc_sao", checkasm_check_hevc_sao },
>  #endif
>  #if CONFIG_HUFFYUV_DECODER
>  { "huffyuvdsp", checkasm_check_huffyuvdsp },
> diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
> index 3de38e6717..8b9d96bc15 100644
> --- a/tests/checkasm/checkasm.h
> +++ b/tests/checkasm/checkasm.h
> @@ -57,6 +57,7 @@ void checkasm_check_h264pred(void);
>  void checkasm_check_h264qpel(void);
>  void checkasm_check_hevc_add_res(void);
>  void checkasm_check_hevc_idct(void);
> +void checkasm_check_hevc_sao(void);
>  void checkasm_check_huffyuvdsp(void);
>  void checkasm_check_jpeg2000dsp(void);
>  void checkasm_check_llviddsp(void);
> diff --git a/tests/checkasm/hevc_sao.c b/tests/checkasm/hevc_sao.c
> new file mode 100644
> index 00..e2a0a54e9b
> --- /dev/null
> +++ b/tests/checkasm/hevc_sao.c
> @@ -0,0 +1,158 @@
> +/*
> + * Copyright (c) 2018 Yingming Fan 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 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 General Public License for more details.
> + *
> + * You should have received a copy of the GNU 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 "libavutil/intreadwrite.h"
> +
> +#include "libavcodec/avcodec.h"
> +
> +#include "libavcodec/hevcdsp.h"
> +
> +#include "checkasm.h"
> +
> +static const uint32_t pixel_mask[3] = { 0x, 0x01ff01ff, 0x03ff03ff };
> +static const uint32_t sao_size[5] = {8, 16, 32, 48, 64};
> +
> +#define SIZEOF_PIXEL ((bit_depth + 7) / 8)
> +#define PIXEL_STRIDE (2*MAX_PB_SIZE + AV_INPUT_BUFFER_PADDING_SIZE) //same 
> with sao_edge src_stride
> +#define BUF_SIZE (PIXEL_STRIDE * (64+2) * 2) //+2 for top and bottom row, *2 
> for high bit depth
> +#define OFFSET_THRESH (1 << (bit_depth - 5))
> +#define OFFSET_LENGTH 5
> +
> +#define randomize_buffers(buf0, buf1, size) \
> +do {\
> +uint32_t mask = pixel_mask[bit_depth - 8];  \
> +int i;  \
> +if (bit_depth == 8) {   \
> +for (i = 0; i < size; i += 4) { \
> +uint32_t r = rnd() & mask;  \
> +AV_WN32A(buf0 + i, r);  \
> +AV_WN32A(buf1 + i, r);  \
> +}   \
> +} else {\
> +for (i = 0; i < size; i += 2) { \
> +uint32_t r = rnd() & mask;  \
> +AV_WN32A((uint16_t *)buf0 + i, r);  \
> +AV_WN32A((uint16_t *)buf1 + i, r);  \
> +}   \
> +}   \
> +} while (0)
> +
> +#define randomize_buf

Re: [FFmpeg-devel] GSoC

[Mark Thompson]

On 06/03/18 12:37, Dylan Fernando wrote:
> Hi,
> 
> I am Dylan Fernando. I am a Computer Science student from Australia. I am
> new to FFmpeg and I wish to apply for GSoC this year.
> I would like to do the Video filtering with OpenCL project and I have a few
> questions. Would trying to implement an opencl version of vf_fade be a good
> idea for the qualification task, or would I be better off using a different
> filter?
> 
> Also, I’m having a bit of trouble with running unsharp_opencl. I tried
> running:
> ffmpeg -hide_banner -nostats -v verbose -init_hw_device opencl=ocl:0.1
> -filter_hw_device ocl -i space.mpg -filter_complex unsharp_opencl output.mp4
> 
> but I got the error:
> [AVHWDeviceContext @ 0x7fdac050c700] 0.1: Apple / Intel(R) Iris(TM)
> Graphics 6100
> [mpeg @ 0x7fdac3132600] max_analyze_duration 500 reached at 5005000
> microseconds st:0
> Input #0, mpeg, from 'space.mpg':
>   Duration: 00:00:21.99, start: 0.387500, bitrate: 6108 kb/s
> Stream #0:0[0x1e0]: Video: mpeg2video (Main), 1 reference frame,
> yuv420p(tv, bt470bg, bottom first, left), 720x480 [SAR 8:9 DAR 4:3], 6000
> kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
> Stream mapping:
>   Stream #0:0 (mpeg2video) -> unsharp_opencl
>   unsharp_opencl -> Stream #0:0 (mpeg4)
> Press [q] to stop, [?] for help
> [graph 0 input from stream 0:0 @ 0x7fdac0418800] w:720 h:480 pixfmt:yuv420p
> tb:1/9 fr:3/1001 sar:8/9 sws_param:flags=2
> [auto_scaler_0 @ 0x7fdac05232c0] w:iw h:ih flags:'bilinear' interl:0
> [Parsed_unsharp_opencl_0 @ 0x7fdac0715a80] auto-inserting filter
> 'auto_scaler_0' between the filter 'graph 0 input from stream 0:0' and the
> filter 'Parsed_unsharp_opencl_0'
> Impossible to convert between the formats supported by the filter 'graph 0
> input from stream 0:0' and the filter 'auto_scaler_0'
> Error reinitializing filters!
> Failed to inject frame into filter network: Function not implemented
> Error while processing the decoded data for stream #0:0
> Conversion failed!
> 
> How do I correctly run unsharp_opencl? Should I be running it on a
> different video file?

It's intended to be used in filter graphs where much of the activity is already 
happening on the GPU, so the input and output are in the AV_PIX_FMT_OPENCL 
format which contains GPU-side OpenCL images.

If you want to use it standalone then you need hwupload and hwdownload filters 
to move the frames between the CPU and GPU.  For your example, it should work 
with:

ffmpeg -init_hw_device opencl=ocl:0.1 -filter_hw_device ocl -i space.mpg 
-filter_complex hwupload,unsharp_opencl,hwdownload output.mp4

(There are constraints on what formats can be used and therefore suitable files 
(or required format conversions), but I believe a normal yuv420p video like 
this should work in all cases.)

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

Re: [FFmpeg-devel] [PATCH] lavf/oggparseflac: Free flac extradata before reallocating.

[James Almer]

On 3/5/2018 10:04 PM, Matthew Wolenetz wrote:
> Perhaps true, but there are a ton of paths to ff_alloc_extradata that are
> not included in Chromium. Such a wider, general, fix seems more appropriate
> to land upstream first with more testing.

The function allocates a buffer and overwrites the pointer without
bothering to make sure it was NULL beforehand, so it's a latent source
of leaks if given improper usage.

I've sent a patchset to make it do a proper cleaning before allocating
new extradata, to see what other developers think.

> For now, this is a particular known case that's occurring in Chromium that
> needs fixing.
> 
> On Mon, Mar 5, 2018 at 2:10 PM, James Almer  wrote:
> 
>> On 3/5/2018 6:54 PM, Matthew Wolenetz wrote:
>>>
>>> 0001-lavf-oggparseflac-Free-flac-extradata-before-realloc.patch
>>>
>>>
>>> From 5d28b92d9d164b104e9a47b8183cd7ddedfde366 Mon Sep 17 00:00:00 2001
>>> From: Matt Wolenetz 
>>> Date: Mon, 5 Mar 2018 12:36:28 -0800
>>> Subject: [PATCH] lavf/oggparseflac: Free flac extradata before
>> reallocating.
>>>
>>> Otherwise ff_alloc_extradata() just leaks any existing allocated
>>> memory.
>>
>> Maybe ff_alloc_extradata() is the one that should free any existing
>> extradata instead of littering the tree with av_freep() calls before
>> every ff_alloc_extradata() call. Otherwise you'll keep patching up
>> demuxers as your fuzzer generates files for them.
>>
>>>
>>> BUG=789835
>>>
>>> Change-Id: I8e1c21a16749d28c7f050f5f5d8bffda3b419638
>>> Reviewed-on: https://chromium-review.googlesource.com/949415
>>> Reviewed-by: Xiaohan Wang 
>>> ---
>>>  libavformat/oggparseflac.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/libavformat/oggparseflac.c b/libavformat/oggparseflac.c
>>> index b5f1416a3c..6cb3468022 100644
>>> --- a/libavformat/oggparseflac.c
>>> +++ b/libavformat/oggparseflac.c
>>> @@ -61,6 +61,7 @@ flac_header (AVFormatContext * s, int idx)
>>>  st->codecpar->codec_id = AV_CODEC_ID_FLAC;
>>>  st->need_parsing = AVSTREAM_PARSE_HEADERS;
>>>
>>> +av_freep(&st->codecpar->extradata);
>>>  if (ff_alloc_extradata(st->codecpar, FLAC_STREAMINFO_SIZE) < 0)
>>>  return AVERROR(ENOMEM);
>>>  memcpy(st->codecpar->extradata, streaminfo_start,
>> st->codecpar->extradata_size);
>>> -- 2.16.2.395.g2e18187dfd-goog
>>>
>>>
>>>
>>> ___
>>> 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
>>
> ___
> 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] avformat/utils: free existing extradata before trying to allocate a new one

[Paul B Mahol]

On 3/6/18, James Almer  wrote:
> This prevents leaks in the rare cases the function is called when extradata
> already exists.
>
> Signed-off-by: James Almer 
> ---
>  libavformat/utils.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 72531d4185..31340a484b 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -3245,6 +3245,7 @@ int ff_alloc_extradata(AVCodecParameters *par, int
> size)
>  {
>  int ret;
>
> +av_freep(&par->extradata);
>  if (size < 0 || size >= INT32_MAX - AV_INPUT_BUFFER_PADDING_SIZE) {
>  par->extradata = NULL;
>  par->extradata_size = 0;
> --
> 2.16.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/utils: simplify ff_alloc_extradata()

[Paul B Mahol]

On 3/6/18, James Almer  wrote:
> Cosmetic refactor
>
> Signed-off-by: James Almer 
> ---
>  libavformat/utils.c | 26 +++---
>  1 file changed, 11 insertions(+), 15 deletions(-)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 31340a484b..3ca1ca2441 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -3243,24 +3243,20 @@ static int tb_unreliable(AVCodecContext *c)
>
>  int ff_alloc_extradata(AVCodecParameters *par, int size)
>  {
> -int ret;
> -
>  av_freep(&par->extradata);
> -if (size < 0 || size >= INT32_MAX - AV_INPUT_BUFFER_PADDING_SIZE) {
> -par->extradata = NULL;
> -par->extradata_size = 0;
> +par->extradata_size = 0;
> +
> +if (size < 0 || size >= INT32_MAX - AV_INPUT_BUFFER_PADDING_SIZE)
>  return AVERROR(EINVAL);
> -}
> +
>  par->extradata = av_malloc(size + AV_INPUT_BUFFER_PADDING_SIZE);
> -if (par->extradata) {
> -memset(par->extradata + size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
> -par->extradata_size = size;
> -ret = 0;
> -} else {
> -par->extradata_size = 0;
> -ret = AVERROR(ENOMEM);
> -}
> -return ret;
> +if (!par->extradata)
> +return AVERROR(ENOMEM);
> +
> +memset(par->extradata + size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
> +par->extradata_size = size;
> +
> +return 0;
>  }
>
>  int ff_get_extradata(AVFormatContext *s, AVCodecParameters *par,
> AVIOContext *pb, int size)
> --
> 2.16.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Don't pass VAConfigAttribEncPackedHeaders with value set to 0

[Mark Thompson]

On 06/03/18 06:04, Eoff, Ullysses A wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
>> Mark Thompson
>> Sent: Tuesday, February 13, 2018 11:54 AM
>> To: FFmpeg development discussions and patches 
>> Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Don't pass 
>> VAConfigAttribEncPackedHeaders with value set to 0
>>
>> On 13/02/18 18:52, Mark Thompson wrote:
>>> On 13/02/18 08:24, Haihao Xiang wrote:
 Recent Intel i965 driver commit strictly disallows application to set
 unsupported attribute values, VA_ENC_PACKED_HEADER_NONE (0) is not used
 in Intel i965 driver, so application shouldn't pass this value to the
 driver. On the other hand, VA_ENC_PACKED_HEADER_NONE (0) means the
 driver doesn't support any packed header mode, so application also
 shouldn't pass packed header to driver if a driver returns
 VA_ENC_PACKED_HEADER_NONE (0), the driver should work without
 VAConfigAttribEncPackedHeaders set for this case.

 In addition, VA_ATTRIB_NOT_SUPPORTED and VA_ENC_PACKED_HEADER_NONE make
 thing messy, we will deprecate VA_ENC_PACKED_HEADER_NONE in the
 future. See https://github.com/intel/libva/issues/178 for more information.

 This fixes broken vp9 encoder on Kably Lake with Intel I965 driver.

 Signed-off-by: Haihao Xiang 
 ---
  libavcodec/vaapi_encode.c | 4 
  1 file changed, 4 insertions(+)

 diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
 index e371f5761ee..1d30aabed40 100644
 --- a/libavcodec/vaapi_encode.c
 +++ b/libavcodec/vaapi_encode.c
 @@ -,6 +,10 @@ static av_cold int 
 vaapi_encode_config_attributes(AVCodecContext *avctx)
 ctx->va_packed_headers, attr[i].value);
  ctx->va_packed_headers &= attr[i].value;
  }
 +
 +if (!ctx->va_packed_headers)
 +continue;
 +
  ctx->config_attributes[ctx->nb_config_attributes++] =
  (VAConfigAttrib) {
  .type  = VAConfigAttribEncPackedHeaders,

>>>
>>> This seems wrong to me: the driver has indicated that packed headers are 
>>> supported, so the user is providing this attribute to
>> indicate to the driver that they will not use any of them.  Compare the VP8 
>> case, where the driver does not support them and says so -
>> there we correctly don't provide the attribute (though maybe the commentary 
>> could be clearer on that).
>>
>> Right, I hadn't realised you had already made a change so that encoding is 
>> currently broken.  I've made
>>  to revert the 
>> API/ABI-breaking part of the change.
>>
>> Thanks,
>>
>> - Mark
> 
> I prefer this patch over the one for intel-vaapi-driver.

Well, the driver patch should be applied anyway to fix the API/ABI break 
(existing libavcodec builds should continue to work on the new library/driver), 
but it can be reverted on the next major version bump.  Maybe a warning 
(i965_log_info()) could be added to the patch to indicate to the client that 
the usage is deprecated in libva 2 and will be removed in libva 3?

> The va.h documentation for VA_ENC_PACKED_HEADER_NONE
> says "Driver does not support any packed headers mode".
> Hence, it's only valid for reporting to client that packed headers
> are "unsupported".  Unfortunately, VA_ENC_PACKED_HEADER_NONE 
> is redundant/ambiguous since there is also
> VA_ATTRIB_NOT_SUPPORTED to relay the same information.
> This is why we want to deprecate VA_ENC_PACKED_HEADER_NONE
> in VAAPI.
> 
> I don't think it's correct for clients to send
> VA_ENC_PACKED_HEADER_NONE attribute value to the driver
> when the driver reports packed headers are "supported".  It
> goes against VA_ENC_PACKED_HEADER_NONE's documented
> purpose.  AFAIK, libavcodec is the only library that does this.  It
> is better to just omit the attribute altogether if client does not
> want to use any of the "supported" packed headers.  And this
> patch solves that.

I still disagree with this logic.  The driver supplied a bitmask of allowed 
packed headers, and the client picks which of those it will send and supplies 
that back to the driver with vaCreateConfig().  If the driver believes that set 
is not sufficient then it can reject that choice, but if it is sufficient then 
the empty set should be just as much a valid setting as any other usable subset 
of the given headers.

Any talk of VA_ENC_PACKED_HEADER_NONE is orthogonal - that symbol isn't used in 
libavcodec at all, and the fact that it happens to have the same value (zero) 
as an empty bitmask is unfortunate but not relevant because one is only used in 
the driver -> client case (vaGetConfigAttributes()) while the other is only 
used in the client -> driver case (vaCreateConfig()).

> In the future, it's probably worth amending VAAPI to

Re: [FFmpeg-devel] ALS encoder

[Paul B Mahol]

On 3/5/18, Oleg Khokhlov  wrote:
> Hi all.
>
> I am student and my name is Oleg. I work on qualification task for GSoC
> 2018.
> I should implement float-point support to als encoder.

Isn't that a little too much for qualification task?

>
> A have some questions:
> 1)In documentation was written
>
> "The floating-point sequence is modeled by the sum of an integer sequence
> multiplied by a constant (ACF: Approximate Common Factor) and a
> residual sequence."
>
> and in another part was written:
>
> "If the input signal is 32-bit floating-point, input values are
> decomposed  into three
> parts: An estimated common multiplier A, a truncated integer
> multiplicand sequence Y,
> and a difference signal Z.".
>
> Can somebody explain what is ACF (I don`t find definition of this term
> in google)
> and how I can compute it?
>
> 2)What is the best method for testing encoder?
>
>
> Link to documentation.
> (https://drive.google.com/open?id=1iMqwUrhzdhWhm-IdNXx2P3djvS0wCtDt)
>
> Oleg.
> ___
> 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

[FFmpeg-devel] [PATCH 1/2] avfilter/vf_*_vaapi: Add missing AV_OPT_FLAG_FILTERING_PARAM

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavfilter/vf_misc_vaapi.c| 2 +-
 libavfilter/vf_procamp_vaapi.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/vf_misc_vaapi.c b/libavfilter/vf_misc_vaapi.c
index 8b179fe215..30b808a993 100644
--- a/libavfilter/vf_misc_vaapi.c
+++ b/libavfilter/vf_misc_vaapi.c
@@ -226,7 +226,7 @@ static av_cold int sharpness_vaapi_init(AVFilterContext 
*avctx)
 }
 
 #define DOFFSET(x) offsetof(DenoiseVAAPIContext, x)
-#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM)
+#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_FILTERING_PARAM)
 static const AVOption denoise_vaapi_options[] = {
 { "denoise", "denoise level",
   DOFFSET(denoise), AV_OPT_TYPE_INT, { .i64 = DENOISE_DEFAULT }, 
DENOISE_MIN, DENOISE_MAX, .flags = FLAGS },
diff --git a/libavfilter/vf_procamp_vaapi.c b/libavfilter/vf_procamp_vaapi.c
index 45a3120b23..10eccbe97d 100644
--- a/libavfilter/vf_procamp_vaapi.c
+++ b/libavfilter/vf_procamp_vaapi.c
@@ -214,7 +214,7 @@ static av_cold int procamp_vaapi_init(AVFilterContext 
*avctx)
 }
 
 #define OFFSET(x) offsetof(ProcampVAAPIContext, x)
-#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM)
+#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_FILTERING_PARAM)
 static const AVOption procamp_vaapi_options[] = {
 { "b", "Output video brightness",
   OFFSET(bright),  AV_OPT_TYPE_FLOAT, { .dbl = BRIGHTNESS_DEFAULT }, 
BRIGHTNESS_MIN, BRIGHTNESS_MAX, .flags = FLAGS },
-- 
2.16.2

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

[FFmpeg-devel] [PATCH 2/2] avformat/mov: Fix integer overflow in mov_get_stsc_samples()

[Michael Niedermayer]

Fixes: runtime error: signed integer overflow: 5 * -2147483647 cannot be 
represented in type 'int'
Fixes: Chromium bug 817338
Reviewed-by: Matt Wolenetz 
Reported-by: Matt Wolenetz 
Signed-off-by: Michael Niedermayer 
---
 libavformat/mov.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 95b9cd3f8b..7002a82787 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2645,7 +2645,7 @@ static inline int mov_stsc_index_valid(unsigned int 
index, unsigned int count)
 }
 
 /* Compute the samples value for the stsc entry at the given index. */
-static inline int mov_get_stsc_samples(MOVStreamContext *sc, unsigned int 
index)
+static inline int64_t mov_get_stsc_samples(MOVStreamContext *sc, unsigned int 
index)
 {
 int chunk_count;
 
@@ -2654,7 +2654,7 @@ static inline int mov_get_stsc_samples(MOVStreamContext 
*sc, unsigned int index)
 else
 chunk_count = sc->chunk_count - (sc->stsc_data[index].first - 1);
 
-return sc->stsc_data[index].count * chunk_count;
+return sc->stsc_data[index].count * (int64_t)chunk_count;
 }
 
 static int mov_read_stps(MOVContext *c, AVIOContext *pb, MOVAtom atom)
@@ -7189,12 +7189,13 @@ static int mov_seek_stream(AVFormatContext *s, AVStream 
*st, int64_t timestamp,
 /* adjust stsd index */
 time_sample = 0;
 for (i = 0; i < sc->stsc_count; i++) {
-int next = time_sample + mov_get_stsc_samples(sc, i);
+int64_t next = time_sample + mov_get_stsc_samples(sc, i);
 if (next > sc->current_sample) {
 sc->stsc_index = i;
 sc->stsc_sample = sc->current_sample - time_sample;
 break;
 }
+av_assert0(next == (int)next);
 time_sample = next;
 }
 
-- 
2.16.2

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

[FFmpeg-devel] avformat/movenc: add param for filtering nal types

[Eran Kornblau]

Hi all,

The attached patch adds a parameter that enables the user to choose which 
AVC/HEVC NAL units to include in the output.
The parameter is supplied as a bitmask in order to keep things simple.

A short background on why we need it - in our transcoding process, we partition 
the video in chunks, the chunks are
transcoded in parallel and packaged in MPEG-TS container. The transcoded TS 
chunks are then concatenated and
packaged in MP4. These MP4 files are later repackaged on-the-fly to various 
protocols (HLS/DASH etc.) using our
JIT packager.
For performance reasons (can get into more detail if anyone's interested...), 
when packaging the MP4 to DASH/CENC,
we configure the packager to assume that each AVC frame contains exactly one 
NAL unit.
The problem is that the transition through MPEG-TS adds additional NAL units 
(NAL AUD before each frame + SPS/PPS
before each key frame), and this assumption fails.
Using the attached patch we can pass '-nal_types_mask 0x3e' which will make 
ffmpeg output only VCL NALs in the stream.

Thanks!

Eran


0001-avformat-movenc-add-param-for-filtering-nal-types.patch
Description: 0001-avformat-movenc-add-param-for-filtering-nal-types.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avformat/movenc: add param for filtering nal types

[Hendrik Leppkes]

On Tue, Mar 6, 2018 at 3:51 PM, Eran Kornblau  wrote:
> Hi all,
>
> The attached patch adds a parameter that enables the user to choose which 
> AVC/HEVC NAL units to include in the output.
> The parameter is supplied as a bitmask in order to keep things simple.
>
> A short background on why we need it - in our transcoding process, we 
> partition the video in chunks, the chunks are
> transcoded in parallel and packaged in MPEG-TS container. The transcoded TS 
> chunks are then concatenated and
> packaged in MP4. These MP4 files are later repackaged on-the-fly to various 
> protocols (HLS/DASH etc.) using our
> JIT packager.
> For performance reasons (can get into more detail if anyone's interested...), 
> when packaging the MP4 to DASH/CENC,
> we configure the packager to assume that each AVC frame contains exactly one 
> NAL unit.
> The problem is that the transition through MPEG-TS adds additional NAL units 
> (NAL AUD before each frame + SPS/PPS
> before each key frame), and this assumption fails.
> Using the attached patch we can pass '-nal_types_mask 0x3e' which will make 
> ffmpeg output only VCL NALs in the stream.
>

Having such logic in one single muxer is not something we really like
around here. Next time someone needs something similar for another
codec, you're stuck re-implementing it.

To achieve the same effect, Mark Thompson quickly wipped up a
Bitstream Filter using his CBS framework which achieves the same
result. He'll be sending that patch to the mailing list in a while.

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

Re: [FFmpeg-devel] [PATCH] lavf/oggparseflac: Free flac extradata before reallocating.

[Matthew Wolenetz]

SGTM. Thanks James.

On Tue, Mar 6, 2018 at 6:23 AM, James Almer  wrote:

> On 3/5/2018 10:04 PM, Matthew Wolenetz wrote:
> > Perhaps true, but there are a ton of paths to ff_alloc_extradata that are
> > not included in Chromium. Such a wider, general, fix seems more
> appropriate
> > to land upstream first with more testing.
>
> The function allocates a buffer and overwrites the pointer without
> bothering to make sure it was NULL beforehand, so it's a latent source
> of leaks if given improper usage.
>
> I've sent a patchset to make it do a proper cleaning before allocating
> new extradata, to see what other developers think.
>
> > For now, this is a particular known case that's occurring in Chromium
> that
> > needs fixing.
> >
> > On Mon, Mar 5, 2018 at 2:10 PM, James Almer  wrote:
> >
> >> On 3/5/2018 6:54 PM, Matthew Wolenetz wrote:
> >>>
> >>> 0001-lavf-oggparseflac-Free-flac-extradata-before-realloc.patch
> >>>
> >>>
> >>> From 5d28b92d9d164b104e9a47b8183cd7ddedfde366 Mon Sep 17 00:00:00 2001
> >>> From: Matt Wolenetz 
> >>> Date: Mon, 5 Mar 2018 12:36:28 -0800
> >>> Subject: [PATCH] lavf/oggparseflac: Free flac extradata before
> >> reallocating.
> >>>
> >>> Otherwise ff_alloc_extradata() just leaks any existing allocated
> >>> memory.
> >>
> >> Maybe ff_alloc_extradata() is the one that should free any existing
> >> extradata instead of littering the tree with av_freep() calls before
> >> every ff_alloc_extradata() call. Otherwise you'll keep patching up
> >> demuxers as your fuzzer generates files for them.
> >>
> >>>
> >>> BUG=789835
> >>>
> >>> Change-Id: I8e1c21a16749d28c7f050f5f5d8bffda3b419638
> >>> Reviewed-on: https://chromium-review.googlesource.com/949415
> >>> Reviewed-by: Xiaohan Wang 
> >>> ---
> >>>  libavformat/oggparseflac.c | 1 +
> >>>  1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/libavformat/oggparseflac.c b/libavformat/oggparseflac.c
> >>> index b5f1416a3c..6cb3468022 100644
> >>> --- a/libavformat/oggparseflac.c
> >>> +++ b/libavformat/oggparseflac.c
> >>> @@ -61,6 +61,7 @@ flac_header (AVFormatContext * s, int idx)
> >>>  st->codecpar->codec_id = AV_CODEC_ID_FLAC;
> >>>  st->need_parsing = AVSTREAM_PARSE_HEADERS;
> >>>
> >>> +av_freep(&st->codecpar->extradata);
> >>>  if (ff_alloc_extradata(st->codecpar, FLAC_STREAMINFO_SIZE) <
> 0)
> >>>  return AVERROR(ENOMEM);
> >>>  memcpy(st->codecpar->extradata, streaminfo_start,
> >> st->codecpar->extradata_size);
> >>> -- 2.16.2.395.g2e18187dfd-goog
> >>>
> >>>
> >>>
> >>> ___
> >>> 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
> >>
> > ___
> > 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
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] ALS encoder

[Umair Khan]

On Tue, Mar 6, 2018 at 8:14 PM, Paul B Mahol  wrote:
> On 3/5/18, Oleg Khokhlov  wrote:
>> Hi all.
>>
>> I am student and my name is Oleg. I work on qualification task for GSoC
>> 2018.
>> I should implement float-point support to als encoder.
>
> Isn't that a little too much for qualification task?

We can take into account the difficulty along with the completion
percentage of the task while making the final decision.

>>
>> A have some questions:
>> 1)In documentation was written
>>
>> "The floating-point sequence is modeled by the sum of an integer sequence
>> multiplied by a constant (ACF: Approximate Common Factor) and a
>> residual sequence."
>>
>> and in another part was written:
>>
>> "If the input signal is 32-bit floating-point, input values are
>> decomposed  into three
>> parts: An estimated common multiplier A, a truncated integer
>> multiplicand sequence Y,
>> and a difference signal Z.".
>>
>> Can somebody explain what is ACF (I don`t find definition of this term
>> in google)
>> and how I can compute it?
>>
>> 2)What is the best method for testing encoder?
>>
>>
>> Link to documentation.
>> (https://drive.google.com/open?id=1iMqwUrhzdhWhm-IdNXx2P3djvS0wCtDt)
>>
>> Oleg.
>> ___
>> 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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/mediacodec_wrapper: blacklist more software decoders

[Stefan _]

Hi,

for hwdec on Android the wrapper attempts to blacklist known software decoders 
also provided through the mediacodec API. The list isn't complete however and 
ffmpeg might e.g. prefer slower "external" HEVC software decoding over its own 
software decoder.

This patch completes the list of known software decoders, which are:

OMX.ffmpeg.*

 see 
https://github.com/AOSB/android_device_lge_hammerhead/blob/master/media_codecs.xml#L89

OMX.SEC.*

 see 
https://chromium.googlesource.com/chromium/src/+/refs/heads/lkgr/media/base/android/media_codec_util.cc#288

OMX.qcom.video.decoder.hevcswvdec

 see 
https://github.com/moonlight-stream/moonlight-android/blob/master/app/src/main/java/com/limelight/binding/video/MediaCodecHelper.java#L83
From fbc876a8763db254d4e26d00c8b4fcf9ea7e7183 Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Tue, 6 Mar 2018 18:47:35 +0100
Subject: [PATCH] avcodec/mediacodec_wrapper: blacklist more software decoders

Additionally blacklist ffmpeg, Samsung and Qualcomm
software implementations offered through MediaCodec.
---
 libavcodec/mediacodec_wrapper.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
index dbc37bf463..b12528500d 100644
--- a/libavcodec/mediacodec_wrapper.c
+++ b/libavcodec/mediacodec_wrapper.c
@@ -465,7 +465,12 @@ char *ff_AMediaCodecList_getCodecNameByType(const char *mime, int profile, int e
 goto done;
 }
 
-if (strstr(name, "OMX.google")) {
+/* Skip software decoders */
+if (
+strstr(name, "OMX.google") ||
+strstr(name, "OMX.ffmpeg") ||
+strstr(name, "OMX.SEC") ||
+!strcmp(name, "OMX.qcom.video.decoder.hevcswvdec")) {
 av_freep(&name);
 goto done_with_type;
 }
-- 
2.16.2

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

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

[Thomas Mundt]

Hi,

2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos :

> 2018-03-05 12:37 GMT+01:00, Paul B Mahol :
> > On 3/5/18, Vasile Toncu  wrote:
> >> Hello,
> >>
> >> Thanks for the review. I've made changes according to your guidance.
> >>
> >> It would be great to know if the community will go on with our intention
> >> of adding reinterlace as a alternative for tinterlace.
> >>
> >> That being said, here is the new patch.
> >
> > As already said, this is not acceptable.
> >
> > There is no point in having 2 filters with near same funcionality.
>
> If you consider the new filter ok, the existing filter will be removed
> in the same push. I believe sending only the new filter makes
> reviewing easier.
>

For me reviewing would be easier when Vasile sends a patchset that includes
the replacement of tinterlace filter.
That way existing fate tests could be used which are fortunately pretty
extensive in this case.
Also it would be helpful when you and/or other experienced ffmpeg
developers would clarify first which parts of tinterlace have to be
rewritten for proper relicensing.
Being left in the dark makes working on patches frustrating.

Another question is how to deal with vf_interlace? IMHO for the user there
should be no difference in output, speed and license.
Two options:
1. Relicensing and slice threading will also be ported to vf_interlace
2. The commands from vf_interlace will be included in the new tinterlace
filter. vf_interlace will be deleted together with old tinterlace filter

I would prefer the second option, but maybe there are even better options
that don´t come to my mind.

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

[FFmpeg-devel] [PATCH] lavc: Add filter_units bitstream filter

[Mark Thompson]

This can remove units with types in or not in a given set from a stream.
For example, it can be used to remove all non-VCL NAL units from an H.264 or
H.265 stream.
---
On 06/03/18 17:27, Hendrik Leppkes wrote:
> On Tue, Mar 6, 2018 at 3:51 PM, Eran Kornblau  
> wrote:
>> Hi all,
>>
>> The attached patch adds a parameter that enables the user to choose which 
>> AVC/HEVC NAL units to include in the output.
>> The parameter is supplied as a bitmask in order to keep things simple.
>>
>> A short background on why we need it - in our transcoding process, we 
>> partition the video in chunks, the chunks are
>> transcoded in parallel and packaged in MPEG-TS container. The transcoded TS 
>> chunks are then concatenated and
>> packaged in MP4. These MP4 files are later repackaged on-the-fly to various 
>> protocols (HLS/DASH etc.) using our
>> JIT packager.
>> For performance reasons (can get into more detail if anyone's 
>> interested...), when packaging the MP4 to DASH/CENC,
>> we configure the packager to assume that each AVC frame contains exactly one 
>> NAL unit.
>> The problem is that the transition through MPEG-TS adds additional NAL units 
>> (NAL AUD before each frame + SPS/PPS
>> before each key frame), and this assumption fails.
>> Using the attached patch we can pass '-nal_types_mask 0x3e' which will make 
>> ffmpeg output only VCL NALs in the stream.
>>
> 
> Having such logic in one single muxer is not something we really like
> around here. Next time someone needs something similar for another
> codec, you're stuck re-implementing it.
> 
> To achieve the same effect, Mark Thompson quickly wipped up a
> Bitstream Filter using his CBS framework which achieves the same
> result. He'll be sending that patch to the mailing list in a while.
The suggested use-case would be '-bsf:v filter_units=pass_types=1-5' for H.264 
or '-bsf:v filter_units=pass_types=0-31' for H.265.

(Also note that filters already exist for some individual parts of this: 
h264_metadata can remove AUDs, extract_extradata can remove parameter sets.)

- Mark


 libavcodec/Makefile|   1 +
 libavcodec/bitstream_filters.c |   1 +
 libavcodec/filter_units_bsf.c  | 250 +
 3 files changed, 252 insertions(+)
 create mode 100644 libavcodec/filter_units_bsf.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index b496f0d..b99bdce 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1037,6 +1037,7 @@ OBJS-$(CONFIG_DUMP_EXTRADATA_BSF) += 
dump_extradata_bsf.o
 OBJS-$(CONFIG_DCA_CORE_BSF)   += dca_core_bsf.o
 OBJS-$(CONFIG_EXTRACT_EXTRADATA_BSF)  += extract_extradata_bsf.o\
  h2645_parse.o
+OBJS-$(CONFIG_FILTER_UNITS_BSF)   += filter_units_bsf.o
 OBJS-$(CONFIG_H264_METADATA_BSF)  += h264_metadata_bsf.o
 OBJS-$(CONFIG_H264_MP4TOANNEXB_BSF)   += h264_mp4toannexb_bsf.o
 OBJS-$(CONFIG_H264_REDUNDANT_PPS_BSF) += h264_redundant_pps_bsf.o
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index 338ef82..e1dc198 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -29,6 +29,7 @@ extern const AVBitStreamFilter ff_chomp_bsf;
 extern const AVBitStreamFilter ff_dump_extradata_bsf;
 extern const AVBitStreamFilter ff_dca_core_bsf;
 extern const AVBitStreamFilter ff_extract_extradata_bsf;
+extern const AVBitStreamFilter ff_filter_units_bsf;
 extern const AVBitStreamFilter ff_h264_metadata_bsf;
 extern const AVBitStreamFilter ff_h264_mp4toannexb_bsf;
 extern const AVBitStreamFilter ff_h264_redundant_pps_bsf;
diff --git a/libavcodec/filter_units_bsf.c b/libavcodec/filter_units_bsf.c
new file mode 100644
index 000..3126f17
--- /dev/null
+++ b/libavcodec/filter_units_bsf.c
@@ -0,0 +1,250 @@
+/*
+ * 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 "libavutil/common.h"
+#include "libavutil/opt.h"
+
+#include "bsf.h"
+#include "cbs.h"
+
+
+typedef struct FilterUnitsContext {
+const AVClass *class;
+
+CodedBitstreamContext *cbc;
+
+const char *pass_types;
+const char *remove_types;
+
+int remove;
+CodedBitstreamUnitType *type_list;
+int nb_types;
+} FilterUnitsContext;
+
+
+static int filt

[FFmpeg-devel] [PATCH] avcodec/aacdec: log configuration change details

[Aman Gupta]

From: Aman Gupta 

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

diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index 44352764a7..d394700cdc 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -318,8 +318,8 @@ static int latm_decode_audio_specific_config(struct 
LATMContext *latmctx,
 ac->oc[1].m4ac.sample_rate != m4ac.sample_rate ||
 ac->oc[1].m4ac.chan_config != m4ac.chan_config) {
 
-if(latmctx->initialized) {
-av_log(avctx, AV_LOG_INFO, "audio config changed\n");
+if (latmctx->initialized) {
+av_log(avctx, AV_LOG_INFO, "audio config changed (sample_rate=%d, 
chan_config=%d)\n", m4ac.sample_rate, m4ac.chan_config);
 } else {
 av_log(avctx, AV_LOG_DEBUG, "initializing latmctx\n");
 }
-- 
2.14.2

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

[FFmpeg-devel] [PATCH] avcodec/noise_bsf: Add keyframes option.

[Josh Allmann]

---
 doc/bitstream_filters.texi |  5 +
 libavcodec/noise_bsf.c | 12 
 libavcodec/version.h   |  2 +-
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index cfd81fa12d..a9f17f32ec 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -399,6 +399,11 @@ every byte is modified.
 A numeral string, whose value is related to how often packets will be dropped.
 Therefore, values below or equal to 0 are forbidden, and the lower the more
 frequent packets will be dropped, with 1 meaning every packet is dropped.
+@item keyframes
+A numeral string, whose value indicates the number of keyframe packets that
+will be dropped from the beginning of the stream. This option will not add
+noise to the source data. If used with stream copy, then -copyinkf should
+be added to the output options as well.
 @end table
 
 The following example applies the modification to every byte but does not drop
diff --git a/libavcodec/noise_bsf.c b/libavcodec/noise_bsf.c
index 84b94032ad..363ea4fc71 100644
--- a/libavcodec/noise_bsf.c
+++ b/libavcodec/noise_bsf.c
@@ -32,6 +32,7 @@ typedef struct NoiseContext {
 const AVClass *class;
 int amount;
 int dropamount;
+int keyframes;
 unsigned int state;
 } NoiseContext;
 
@@ -49,6 +50,13 @@ static int noise(AVBSFContext *ctx, AVPacket *out)
 if (ret < 0)
 return ret;
 
+if (s->keyframes > 0 && in->flags & AV_PKT_FLAG_KEY) {
+  s->keyframes--;
+  if (!s->keyframes) s->keyframes = -1;
+  av_packet_free(&in);
+  return AVERROR(EAGAIN);
+}
+
 if (s->dropamount > 0 && s->state % s->dropamount == 0) {
 s->state++;
 av_packet_free(&in);
@@ -65,6 +73,9 @@ static int noise(AVBSFContext *ctx, AVPacket *out)
 
 memcpy(out->data, in->data, in->size);
 
+if (s->keyframes)
+  return ret;
+
 for (i = 0; i < out->size; i++) {
 s->state += out->data[i] + 1;
 if (s->state % amount == 0)
@@ -81,6 +92,7 @@ fail:
 static const AVOption options[] = {
 { "amount", NULL, OFFSET(amount), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 
INT_MAX },
 { "dropamount", NULL, OFFSET(dropamount), AV_OPT_TYPE_INT, { .i64 = 0 }, 
0, INT_MAX },
+{ "keyframes", NULL, OFFSET(keyframes), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 
INT_MAX },
 { NULL },
 };
 
diff --git a/libavcodec/version.h b/libavcodec/version.h
index ca18ce6e8b..1e84410d68 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
 
 #define LIBAVCODEC_VERSION_MAJOR  58
 #define LIBAVCODEC_VERSION_MINOR  13
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 2/2] avcodec/mediacodecdec: add more trace logging of input/output buffers

[Aman Gupta]

From: Aman Gupta 

---
 libavcodec/mediacodec.c   | 1 +
 libavcodec/mediacodecdec_common.c | 4 
 libavcodec/mediacodecdec_common.h | 1 +
 3 files changed, 6 insertions(+)

diff --git a/libavcodec/mediacodec.c b/libavcodec/mediacodec.c
index bf1b7477f1..5cb96d2b65 100644
--- a/libavcodec/mediacodec.c
+++ b/libavcodec/mediacodec.c
@@ -92,6 +92,7 @@ int av_mediacodec_release_buffer(AVMediaCodecBuffer *buffer, 
int render)
 int released = atomic_fetch_add(&buffer->released, 1);
 
 if (!released && (ctx->delay_flush || buffer->serial == 
atomic_load(&ctx->serial))) {
+av_log(ctx->avctx, AV_LOG_TRACE, "Releasing output buffer %zd 
ts=%"PRId64" render=%d\n", buffer->index, buffer->pts, render);
 return ff_AMediaCodec_releaseOutputBuffer(ctx->codec, buffer->index, 
render);
 }
 
diff --git a/libavcodec/mediacodecdec_common.c 
b/libavcodec/mediacodecdec_common.c
index b4f1f6685b..121356c13e 100644
--- a/libavcodec/mediacodecdec_common.c
+++ b/libavcodec/mediacodecdec_common.c
@@ -452,6 +452,7 @@ int ff_mediacodec_dec_init(AVCodecContext *avctx, 
MediaCodecDecContext *s,
 AV_PIX_FMT_NONE,
 };
 
+s->avctx = avctx;
 atomic_init(&s->refcount, 1);
 atomic_init(&s->serial, 1);
 
@@ -619,6 +620,9 @@ int ff_mediacodec_dec_send(AVCodecContext *avctx, 
MediaCodecDecContext *s,
 av_log(avctx, AV_LOG_ERROR, "Failed to queue input buffer 
(status = %d)\n", status);
 return AVERROR_EXTERNAL;
 }
+
+av_log(avctx, AV_LOG_TRACE, "Queued input buffer %zd"
+" size=%zd ts=%" PRIi64 "\n", index, size, pts);
 }
 }
 
diff --git a/libavcodec/mediacodecdec_common.h 
b/libavcodec/mediacodecdec_common.h
index afb98ffed9..3fd2412a65 100644
--- a/libavcodec/mediacodecdec_common.h
+++ b/libavcodec/mediacodecdec_common.h
@@ -36,6 +36,7 @@
 
 typedef struct MediaCodecDecContext {
 
+AVCodecContext *avctx;
 atomic_int refcount;
 
 char *codec_name;
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 1/2] avcodec/mediacodecdec: add delay_flush option

[Aman Gupta]

From: Aman Gupta 

The default behavior of the mediacodec decoder before this commit
was to delay flushes until all pending hardware frames were
returned to the decoder. This was useful for certain types of
applications, but was unexpected behavior for others.

The new default behavior with this commit is now to execute
flushes immediately to invalidate all pending frames. The old
behavior can be enabled by setting delay_flush=1.

With the new behavior, video players implementing seek can simply
call flush on the decoder without having to worry about whether
they have one or more mediacodec frames still buffered in their
rendering pipeline. Previously, all these frames had to be
explictly freed (or rendered) before the seek/flush would execute.

The new behavior matches the behavior of all other lavc decoders,
reducing the amount of special casing required when using the
mediacodec decoder.
---
 libavcodec/mediacodec.c   |  2 +-
 libavcodec/mediacodecdec.c| 23 +++
 libavcodec/mediacodecdec_common.c | 11 ---
 libavcodec/mediacodecdec_common.h |  4 
 4 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/libavcodec/mediacodec.c b/libavcodec/mediacodec.c
index d492eefe0b..bf1b7477f1 100644
--- a/libavcodec/mediacodec.c
+++ b/libavcodec/mediacodec.c
@@ -91,7 +91,7 @@ int av_mediacodec_release_buffer(AVMediaCodecBuffer *buffer, 
int render)
 MediaCodecDecContext *ctx = buffer->ctx;
 int released = atomic_fetch_add(&buffer->released, 1);
 
-if (!released) {
+if (!released && (ctx->delay_flush || buffer->serial == 
atomic_load(&ctx->serial))) {
 return ff_AMediaCodec_releaseOutputBuffer(ctx->codec, buffer->index, 
render);
 }
 
diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 0fe14846c3..3582a1377d 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -41,10 +41,14 @@
 
 typedef struct MediaCodecH264DecContext {
 
+AVClass *avclass;
+
 MediaCodecDecContext *ctx;
 
 AVPacket buffered_pkt;
 
+int delay_flush;
+
 } MediaCodecH264DecContext;
 
 static av_cold int mediacodec_decode_close(AVCodecContext *avctx)
@@ -366,6 +370,8 @@ static av_cold int mediacodec_decode_init(AVCodecContext 
*avctx)
 goto done;
 }
 
+s->ctx->delay_flush = s->delay_flush;
+
 if ((ret = ff_mediacodec_dec_init(avctx, s->ctx, codec_mime, format)) < 0) 
{
 s->ctx = NULL;
 goto done;
@@ -485,7 +491,24 @@ static const AVCodecHWConfigInternal 
*mediacodec_hw_configs[] = {
 NULL
 };
 
+#define OFFSET(x) offsetof(MediaCodecH264DecContext, x)
+#define VD AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
+static const AVOption ff_mediacodec_vdec_options[] = {
+{ "delay_flush", "Delay flush until hw output buffers are returned to the 
decoder",
+ OFFSET(delay_flush), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, 
VD },
+{ NULL }
+};
+
+#define DECLARE_MEDIACODEC_VCLASS(short_name)   \
+static const AVClass ff_##short_name##_mediacodec_dec_class = { \
+.class_name = #short_name "_mediacodec",\
+.item_name  = av_default_item_name, \
+.option = ff_mediacodec_vdec_options,   \
+.version= LIBAVUTIL_VERSION_INT,\
+};
+
 #define DECLARE_MEDIACODEC_VDEC(short_name, full_name, codec_id, bsf)  
\
+DECLARE_MEDIACODEC_VCLASS(short_name)  
\
 AVCodec ff_##short_name##_mediacodec_decoder = {   
\
 .name   = #short_name "_mediacodec",   
\
 .long_name  = NULL_IF_CONFIG_SMALL(full_name " Android MediaCodec 
decoder"),   \
diff --git a/libavcodec/mediacodecdec_common.c 
b/libavcodec/mediacodecdec_common.c
index 929db78361..b4f1f6685b 100644
--- a/libavcodec/mediacodecdec_common.c
+++ b/libavcodec/mediacodecdec_common.c
@@ -178,11 +178,12 @@ static void mediacodec_buffer_release(void *opaque, 
uint8_t *data)
 MediaCodecDecContext *ctx = buffer->ctx;
 int released = atomic_load(&buffer->released);
 
-if (!released) {
+if (!released && (ctx->delay_flush || buffer->serial == 
atomic_load(&ctx->serial))) {
 ff_AMediaCodec_releaseOutputBuffer(ctx->codec, buffer->index, 0);
 }
 
-ff_mediacodec_dec_unref(ctx);
+if (ctx->delay_flush)
+ff_mediacodec_dec_unref(ctx);
 av_freep(&buffer);
 }
 
@@ -236,7 +237,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 
 buffer->ctx = s;
-ff_mediacodec_dec_ref(s);
+buffer->serial = atomic_load(&s->serial);
+if (s->delay_flush)
+ff_mediacodec_dec_ref(s);
 
 buffer->index = index;
 buffer->pts = info->presentationTimeUs;
@@ -425,6 +428,7 @@ static int mediacodec_dec_flush_codec(AVCodecContext 
*avctx, MediaCodecDecContex
 s->draining = 0;
 s->flu

Re: [FFmpeg-devel] [PATCH] avcodec/mediacodec_wrapper: blacklist more software decoders

[Aman Gupta]

On Tue, Mar 6, 2018 at 10:00 AM, Stefan _  wrote:

> Hi,
>
> for hwdec on Android the wrapper attempts to blacklist known software
> decoders also provided through the mediacodec API. The list isn't complete
> however and ffmpeg might e.g. prefer slower "external" HEVC software
> decoding over its own software decoder.
>
> This patch completes the list of known software decoders, which are:
>
> OMX.ffmpeg.*
>
> see https://github.com/AOSB/android_device_lge_hammerhead/
> blob/master/media_codecs.xml#L89
>
> OMX.SEC.*
>
> see https://chromium.googlesource.com/chromium/src/+/refs/heads/
> lkgr/media/base/android/media_codec_util.cc#288
>
> OMX.qcom.video.decoder.hevcswvdec
>
> see https://github.com/moonlight-stream/moonlight-android/blob/
> master/app/src/main/java/com/limelight/binding/video/
> MediaCodecHelper.java#L83


Patch LGTM

Aman


>
>
> ___
> 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

[FFmpeg-devel] [PATCH 1/2] avcodec/mediacodec: reduce loglevel for per-frame logging

[Aman Gupta]

From: Aman Gupta 

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

diff --git a/libavcodec/mediacodecdec_common.c 
b/libavcodec/mediacodecdec_common.c
index 929db78361..0bd660f7c9 100644
--- a/libavcodec/mediacodecdec_common.c
+++ b/libavcodec/mediacodecdec_common.c
@@ -297,7 +297,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 frame->pkt_dts = AV_NOPTS_VALUE;
 
-av_log(avctx, AV_LOG_DEBUG,
+av_log(avctx, AV_LOG_TRACE,
 "Frame: width=%d stride=%d height=%d slice-height=%d "
 "crop-top=%d crop-bottom=%d crop-left=%d crop-right=%d 
encoder=%s\n"
 "destination linesizes=%d,%d,%d\n" ,
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 2/2] MAINTAINERS: add myself to mediacodec

[Aman Gupta]

From: Aman Gupta 

---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index cc4c23df6f..3c54ad6781 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -268,7 +268,7 @@ Hardware acceleration:
   crystalhd.c   Philip Langdale
   dxva2*Hendrik Leppkes, Laurent Aimar, Steve 
Lhomme
   d3d11va*  Steve Lhomme
-  mediacodec*   Matthieu Bouron
+  mediacodec*   Matthieu Bouron, Aman Gupta
   vaapi*Gwenole Beauchesne
   vaapi_encode* Mark Thompson
   vdpau*Philip Langdale, Carl Eugen Hoyos
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mediacodec: reduce loglevel for per-frame logging

[Matthieu Bouron]

On Tue, Mar 06, 2018 at 01:33:19PM -0800, Aman Gupta wrote:
> From: Aman Gupta 
> 
> ---
>  libavcodec/mediacodecdec_common.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/mediacodecdec_common.c 
> b/libavcodec/mediacodecdec_common.c
> index 929db78361..0bd660f7c9 100644
> --- a/libavcodec/mediacodecdec_common.c
> +++ b/libavcodec/mediacodecdec_common.c
> @@ -297,7 +297,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  #endif
>  frame->pkt_dts = AV_NOPTS_VALUE;
>  
> -av_log(avctx, AV_LOG_DEBUG,
> +av_log(avctx, AV_LOG_TRACE,
>  "Frame: width=%d stride=%d height=%d slice-height=%d "
>  "crop-top=%d crop-bottom=%d crop-left=%d crop-right=%d 
> encoder=%s\n"
>  "destination linesizes=%d,%d,%d\n" ,
> -- 
> 2.14.2
> 

LGTM.

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

Re: [FFmpeg-devel] [PATCH 2/2] MAINTAINERS: add myself to mediacodec

[Matthieu Bouron]

On Tue, Mar 06, 2018 at 01:33:20PM -0800, Aman Gupta wrote:
> From: Aman Gupta 
> 
> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cc4c23df6f..3c54ad6781 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -268,7 +268,7 @@ Hardware acceleration:
>crystalhd.c   Philip Langdale
>dxva2*Hendrik Leppkes, Laurent Aimar, 
> Steve Lhomme
>d3d11va*  Steve Lhomme
> -  mediacodec*   Matthieu Bouron
> +  mediacodec*   Matthieu Bouron, Aman Gupta
>vaapi*Gwenole Beauchesne
>vaapi_encode* Mark Thompson
>vdpau*Philip Langdale, Carl Eugen Hoyos
> -- 
> 2.14.2
> 

LGTM.

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

Re: [FFmpeg-devel] [PATCH] avcodec/mediacodec_wrapper: blacklist more software decoders

[Matthieu Bouron]

On Tue, Mar 06, 2018 at 06:00:27PM +, Stefan _ wrote:
> Hi,
> 
> for hwdec on Android the wrapper attempts to blacklist known software 
> decoders also provided through the mediacodec API. The list isn't complete 
> however and ffmpeg might e.g. prefer slower "external" HEVC software decoding 
> over its own software decoder.
> 
> This patch completes the list of known software decoders, which are:
> 
> OMX.ffmpeg.*
> 
>  see 
> https://github.com/AOSB/android_device_lge_hammerhead/blob/master/media_codecs.xml#L89
> 
> OMX.SEC.*
> 
>  see 
> https://chromium.googlesource.com/chromium/src/+/refs/heads/lkgr/media/base/android/media_codec_util.cc#288
> 
> OMX.qcom.video.decoder.hevcswvdec
> 
>  see 
> https://github.com/moonlight-stream/moonlight-android/blob/master/app/src/main/java/com/limelight/binding/video/MediaCodecHelper.java#L83

> From fbc876a8763db254d4e26d00c8b4fcf9ea7e7183 Mon Sep 17 00:00:00 2001
> From: sfan5 
> Date: Tue, 6 Mar 2018 18:47:35 +0100
> Subject: [PATCH] avcodec/mediacodec_wrapper: blacklist more software decoders
> 
> Additionally blacklist ffmpeg, Samsung and Qualcomm
> software implementations offered through MediaCodec.
> ---
>  libavcodec/mediacodec_wrapper.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
> index dbc37bf463..b12528500d 100644
> --- a/libavcodec/mediacodec_wrapper.c
> +++ b/libavcodec/mediacodec_wrapper.c
> @@ -465,7 +465,12 @@ char *ff_AMediaCodecList_getCodecNameByType(const char 
> *mime, int profile, int e
>  goto done;
>  }
>  
> -if (strstr(name, "OMX.google")) {
> +/* Skip software decoders */
> +if (
> +strstr(name, "OMX.google") ||
> +strstr(name, "OMX.ffmpeg") ||
> +strstr(name, "OMX.SEC") ||
> +!strcmp(name, "OMX.qcom.video.decoder.hevcswvdec")) {
>  av_freep(&name);
>  goto done_with_type;
>  }
> -- 
> 2.16.2
> 

LGTM.

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

[FFmpeg-devel] [PATCH 1/2] libavformat/oggparsevorbis: Fix memleak on multiple headers

[Michael Niedermayer]

Fixes: Chromium bug 800123
Reported-by: Matt Wolenetz 
Reviewed-by: Matt Wolenetz 
Signed-off-by: Michael Niedermayer 
---
 libavformat/oggparsevorbis.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/oggparsevorbis.c b/libavformat/oggparsevorbis.c
index 29b1ab514e..bcfd246b8d 100644
--- a/libavformat/oggparsevorbis.c
+++ b/libavformat/oggparsevorbis.c
@@ -230,6 +230,10 @@ static int fixup_vorbis_headers(AVFormatContext *as,
 
 len = priv->len[0] + priv->len[1] + priv->len[2];
 buf_len = len + len / 255 + 64;
+
+if (*buf)
+return AVERROR_INVALIDDATA;
+
 ptr = *buf = av_realloc(NULL, buf_len);
 if (!ptr)
 return AVERROR(ENOMEM);
-- 
2.16.2

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

[FFmpeg-devel] [PATCH 2/2] avformat/oggdec: Fix metadata memleak on multiple headers

[Michael Niedermayer]

Fixes: Chromium bug 800123
Reported-by: Matt Wolenetz 
Reviewed-by: Matt Wolenetz 
Signed-off-by: Michael Niedermayer 
---
 libavformat/oggdec.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c
index 38f60653f9..27d16a3e4e 100644
--- a/libavformat/oggdec.c
+++ b/libavformat/oggdec.c
@@ -128,7 +128,10 @@ static int ogg_restore(AVFormatContext *s)
 ogg->state = ost->next;
 
 for (i = 0; i < ogg->nstreams; i++) {
-av_freep(&ogg->streams[i].buf);
+struct ogg_stream *stream = &ogg->streams[i];
+av_freep(&stream->buf);
+av_freep(&stream->new_metadata);
+
 if (i >= ost->nstreams || !ost->streams[i].private) {
 free_stream(s, i);
 }
-- 
2.16.2

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/utils: free existing extradata before trying to allocate a new one

[James Almer]

On 3/6/2018 11:29 AM, Paul B Mahol wrote:
> On 3/6/18, James Almer  wrote:
>> This prevents leaks in the rare cases the function is called when extradata
>> already exists.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavformat/utils.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>> index 72531d4185..31340a484b 100644
>> --- a/libavformat/utils.c
>> +++ b/libavformat/utils.c
>> @@ -3245,6 +3245,7 @@ int ff_alloc_extradata(AVCodecParameters *par, int
>> size)
>>  {
>>  int ret;
>>
>> +av_freep(&par->extradata);
>>  if (size < 0 || size >= INT32_MAX - AV_INPUT_BUFFER_PADDING_SIZE) {
>>  par->extradata = NULL;
>>  par->extradata_size = 0;
>> --
>> 2.16.2
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> 
> lgtm

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

[FFmpeg-devel] [PATCH] avcodec/mediacodec_wrapper: fix false positives in swdec blacklist

[Stefan _]

Hi,

attached patch fixes an issue with the previous mediacodec patch.

From b6a8721679483900b4f824504fdb1f7944ec268f Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Tue, 6 Mar 2018 23:14:09 +0100
Subject: [PATCH] avcodec/mediacodec_wrapper: fix false positives in swdec
 blacklist

'OMX.SEC.avc.dec' is a valid hardware decoder, while the decoders
we seek to blacklist all match 'OMX.SEC.*.sw.dec'.
---
 libavcodec/mediacodec_wrapper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
index 8381128..11d7f66 100644
--- a/libavcodec/mediacodec_wrapper.c
+++ b/libavcodec/mediacodec_wrapper.c
@@ -473,7 +473,7 @@ char *ff_AMediaCodecList_getCodecNameByType(const char *mime, int profile, int e
 if (
 strstr(name, "OMX.google") ||
 strstr(name, "OMX.ffmpeg") ||
-strstr(name, "OMX.SEC") ||
+(strstr(name, "OMX.SEC") && strstr(name, ".sw.")) ||
 !strcmp(name, "OMX.qcom.video.decoder.hevcswvdec")) {
 av_freep(&name);
 goto done_with_type;
-- 
2.16.2

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

Re: [FFmpeg-devel] Fix stts_data memory allocation

[王消寒]

kingly ping!

On Tue, Feb 13, 2018 at 4:08 PM, Xiaohan Wang (王消寒) 
wrote:

> "unsigned" is perfectly fine. Just trying to be consistent with the line
> above.
>
> On Tue, Feb 13, 2018 at 4:06 PM, Carl Eugen Hoyos 
> wrote:
>
>> 2018-02-13 23:48 GMT+01:00 Xiaohan Wang (王消寒) :
>>
>> Thank you for the fix!
>> (What's wrong with "unsigned"?)
>>
>> Carl Eugen
>> ___
>> 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

[FFmpeg-devel] [PATCH] avcodec/mpeg12dec: ignore scte20 captions when a53 data is also present

[Aman Gupta]

From: Aman Gupta 

Some streams include both a53 and scte20 data. Before this commit,
the scte20 data would be used instead of the a53 data.

See https://s3.amazonaws.com/tmm1/ccaptions/scte20plusa53.ts,
which produced garbage captions since 3f1a540204a8c187f77b3805d.
---
 libavcodec/mpeg12dec.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 9e076e89da..45d0a9d737 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -59,6 +59,7 @@ typedef struct Mpeg1Context {
 int has_stereo3d;
 uint8_t *a53_caption;
 int a53_caption_size;
+int ignore_scte20;
 uint8_t afd;
 int has_afd;
 int slice_count;
@@ -2241,6 +2242,7 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
 /* extract A53 Part 4 CC data */
 int cc_count = p[5] & 0x1f;
 if (cc_count > 0 && buf_size >= 7 + cc_count * 3) {
+s1->ignore_scte20 = 1;
 av_freep(&s1->a53_caption);
 s1->a53_caption_size = cc_count * 3;
 s1->a53_caption  = av_malloc(s1->a53_caption_size);
@@ -2253,7 +2255,8 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
 }
 return 1;
 } else if (buf_size >= 2 &&
-   p[0] == 0x03 && (p[1]&0x7f) == 0x01) {
+   p[0] == 0x03 && (p[1]&0x7f) == 0x01 &&
+   !s1->ignore_scte20) {
 /* extract SCTE-20 CC data */
 GetBitContext gb;
 int cc_count = 0;
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 2/5] CodeAi generated fix for CWE 457 Uninitialized Variable

[C0deAi]

Prevent uninitialized value 'pb[1]' being passed as an
argument on line 143.

Signed-off-by: C0deAi 
---
 libavformat/img2enc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/img2enc.c b/libavformat/img2enc.c
index a09cc8e..6cfbaa2 100644
--- a/libavformat/img2enc.c
+++ b/libavformat/img2enc.c
@@ -81,7 +81,7 @@ static int write_header(AVFormatContext *s)
 static int write_packet(AVFormatContext *s, AVPacket *pkt)
 {
 VideoMuxData *img = s->priv_data;
-AVIOContext *pb[4];
+AVIOContext *pb[4] = {0};
 char filename[1024];
 AVCodecParameters *par = s->streams[pkt->stream_index]->codecpar;
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(par->format);
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 1/5] CodeAi generated fix for CWE 476 Null Pointer Dereference

[C0deAi]

Tighten condition to prevent possible Null Dereference from
access to field 'pts' loaded from variable 'in'.

Signed-off-by: C0deAi 
---
 libavfilter/af_afade.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/af_afade.c b/libavfilter/af_afade.c
index 285b5b6..7f5106e 100644
--- a/libavfilter/af_afade.c
+++ b/libavfilter/af_afade.c
@@ -460,7 +460,7 @@ static int activate(AVFilterContext *ctx)
 return ff_filter_frame(outlink, in);
 }
 
-if (ff_framequeue_queued_samples(&ctx->inputs[0]->fifo) > s->nb_samples) {
+if (in && (ff_framequeue_queued_samples(&ctx->inputs[0]->fifo) > 
s->nb_samples)) {
 nb_samples = ff_framequeue_queued_samples(&ctx->inputs[0]->fifo) - 
s->nb_samples;
 if (nb_samples > 0) {
 ret = ff_inlink_consume_samples(ctx->inputs[0], nb_samples, 
nb_samples, &in);
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 0/5] CodeAi fixes: 1 Null Deref, 2 Dead Code, 2 Uninitialized Variables

[C0deAi]

CodeAI (www.mycode.ai) found 233 defects and fixed 205 in FFmpeg. It wants to 
merge commits fixing 5 of these issues- 1 Null Pointer Dereference, 2 Dead 
Code, and 2 Uninitialized Variables. A screenshot of the results as well as the 
Dockerfile used to build and run your project in CodeAI can be found here-
https://drive.google.com/open?id=13plMG_j6PyyVojsBiQQpYC1bkd4Tq6jn

C0deAi (5):
  CodeAi generated fix for CWE 476 Null Pointer Dereference
  CodeAi generated fix for CWE 457 Uninitialized Variable
  CodeAi generated fix for CWE 457 Uninitialized Variable
  CodeAi generated fix for CWE 561 Dead Code
  CodeAi generated fix for CWE 561 Dead Code

 libavcodec/h264_metadata_bsf.c | 1 -
 libavcodec/indeo3.c| 1 -
 libavfilter/af_afade.c | 2 +-
 libavformat/img2enc.c  | 2 +-
 libavutil/hash.c   | 2 +-
 5 files changed, 3 insertions(+), 5 deletions(-)

-- 
2.7.4

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

[FFmpeg-devel] [PATCH 3/5] CodeAi generated fix for CWE 457 Uninitialized Variable

[C0deAi]

Prevent passing of uninitialized value 'buf[i]' as function
call argument on line 222.

Signed-off-by: C0deAi 
---
 libavutil/hash.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/hash.c b/libavutil/hash.c
index 75edb6d..593176c 100644
--- a/libavutil/hash.c
+++ b/libavutil/hash.c
@@ -214,7 +214,7 @@ void av_hash_final_bin(struct AVHashContext *ctx, uint8_t 
*dst, int size)
 
 void av_hash_final_hex(struct AVHashContext *ctx, uint8_t *dst, int size)
 {
-uint8_t buf[AV_HASH_MAX_SIZE];
+uint8_t buf[AV_HASH_MAX_SIZE] = {0};
 unsigned rsize = av_hash_get_size(ctx), i;
 
 av_hash_final(ctx, buf);
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 5/5] CodeAi generated fix for CWE 561 Dead Code

[C0deAi]

Signed-off-by: C0deAi 
---
 libavcodec/indeo3.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavcodec/indeo3.c b/libavcodec/indeo3.c
index 71d478c..ebd8ab9 100644
--- a/libavcodec/indeo3.c
+++ b/libavcodec/indeo3.c
@@ -657,7 +657,6 @@ static int decode_cell(Indeo3DecodeContext *ctx, 
AVCodecContext *avctx,
 ref_block[x] = requant_tab[vq_index & 7][ref_block[x] & 127];
 }
 
-error = IV3_NOERR;
 
 switch (mode) {
 case 0: /*-- MODES 0 & 1 (4x4 block processing) 
*/
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 4/5] CodeAi generated fix for CWE 561 Dead Code

[C0deAi]

Signed-off-by: C0deAi 
---
 libavcodec/h264_metadata_bsf.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index 89bdedf..09b3f1a 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -344,7 +344,6 @@ static int h264_metadata_filter(AVBSFContext *bsf, AVPacket 
*out)
 invalid_user_data:
 av_log(bsf, AV_LOG_ERROR, "Invalid user data: "
"must be \"UUID+string\".\n");
-err = AVERROR(EINVAL);
 }
 }
 
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH] avcodec/mediacodec_wrapper: fix false positives in swdec blacklist

[Jan Ekström]

On Wed, Mar 7, 2018 at 12:19 AM, Stefan _  wrote:
> Hi,
>
> attached patch fixes an issue with the previous mediacodec patch.
>

LGTM.

`strstr(name, "OMX.SEC") && strstr(name, ".sw.")`

..will most likely have less false positives as OMX.SEC seems to be
utilized for HW decoders on some Exynos SoCs.

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

Re: [FFmpeg-devel] [PATCH 3/5] CodeAi generated fix for CWE 457 Uninitialized Variable

[Nicolas George]

C0deAi (2018-03-06):
> Prevent passing of uninitialized value 'buf[i]' as function
> call argument on line 222.
> 
> Signed-off-by: C0deAi 
> ---
>  libavutil/hash.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Nack. buf[i] cannot be unitialized at this point.

Also, the first line of commit message should be "lavu/hash: fix...".

The same comment about commit messages applies to the other patches. I
suspect some of them fix nothing too, but I do not have time to check
right now.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH]lavfi/drawutils: Do not claim to support P016

[Carl Eugen Hoyos]

Hi!

Attached patch fixes fate on big-endian, I failed to fix drawutils for P016.

Please comment (or fix the underlying issue), Carl Eugen
From 5254acb48a67adc10e2651c6be449e11ecd8cb74 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 7 Mar 2018 00:36:21 +0100
Subject: [PATCH] lavfi/drawutils: Do not claim to support P016.

Fixes fate on big-endian.
---
 libavfilter/drawutils.c   |2 +-
 tests/ref/fate/filter-pixfmts-pad |1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
index 77ab86b..17e26c7 100644
--- a/libavfilter/drawutils.c
+++ b/libavfilter/drawutils.c
@@ -186,7 +186,7 @@ int ff_draw_init(FFDrawContext *draw, enum AVPixelFormat format, unsigned flags)
 return AVERROR(EINVAL);
 if (desc->flags & ~(AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_RGB | AV_PIX_FMT_FLAG_PSEUDOPAL | AV_PIX_FMT_FLAG_ALPHA))
 return AVERROR(ENOSYS);
-if (format == AV_PIX_FMT_P010LE || format == AV_PIX_FMT_P010BE)
+if (format == AV_PIX_FMT_P010LE || format == AV_PIX_FMT_P010BE || format == AV_PIX_FMT_P016LE || format == AV_PIX_FMT_P016BE)
 return AVERROR(ENOSYS);
 for (i = 0; i < desc->nb_components; i++) {
 c = &desc->comp[i];
diff --git a/tests/ref/fate/filter-pixfmts-pad b/tests/ref/fate/filter-pixfmts-pad
index 097bd58..e777211 100644
--- a/tests/ref/fate/filter-pixfmts-pad
+++ b/tests/ref/fate/filter-pixfmts-pad
@@ -22,7 +22,6 @@ gray16le468bda6155bdc7a7a20c34d6e599fd16
 gray9le f8f3dfe31ca5fcba828285bceefdab9a
 nv12381574979cb04be10c9168540310afad
 nv210fdeb2cdd56cf5a7147dc273456fa217
-p016le  536a3b4c3b47d005f9ab033370cc1c3b
 rgb078d500c8361ab6423a4826a00268c908
 rgb24   17f9e2e0c609009acaf2175c42d4a2a5
 rgbab157c90191463d34fb3ce77b36c96386
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

[Carl Eugen Hoyos]

2018-03-05 13:53 GMT+01:00, Paul B Mahol :
> On 3/5/18, Carl Eugen Hoyos  wrote:
>> 2018-03-05 12:37 GMT+01:00, Paul B Mahol :
>>> On 3/5/18, Vasile Toncu  wrote:
 Hello,

 Thanks for the review. I've made changes according to your guidance.

 It would be great to know if the community will go on with our intention
 of adding reinterlace as a alternative for tinterlace.

 That being said, here is the new patch.
>>>
>>> As already said, this is not acceptable.
>>>
>>> There is no point in having 2 filters with near same funcionality.
>>
>> If you consider the new filter ok, the existing filter will be removed
>> in the same push. I believe sending only the new filter makes
>> reviewing easier.
>
> I'm ok with that, but next commits that do that and also do rename are
> not available.

It should have been a former (not a next) commit that I considered
trivial but I see now that because of fate it makes sense to add and
remove in one patch.

> I'm also not sure can reinterlace filter be considered really safe from
> standpoint that it does not use any old GPL code.

Not sure I understand:
Do you mean that the new filter was not independently written?

> Also bunch of stuff it does is trivial, both new and old GPL
> code so I consider nobody should care about its license.

That does not sound like a safe approach.

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

Re: [FFmpeg-devel] [PATCH 4/5] CodeAi generated fix for CWE 561 Dead Code

[Mark Thompson]

On 06/03/18 22:42, C0deAi wrote:
> Signed-off-by: C0deAi 
> ---
>  libavcodec/h264_metadata_bsf.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
> index 89bdedf..09b3f1a 100644
> --- a/libavcodec/h264_metadata_bsf.c
> +++ b/libavcodec/h264_metadata_bsf.c
> @@ -344,7 +344,6 @@ static int h264_metadata_filter(AVBSFContext *bsf, 
> AVPacket *out)
>  invalid_user_data:
>  av_log(bsf, AV_LOG_ERROR, "Invalid user data: "
> "must be \"UUID+string\".\n");
> -err = AVERROR(EINVAL);
>  }
>  }
>  
> 

This is an error, but the analysis is misleading and therefore the suggested 
change is not correct.  I've applied a proper fix in 
.

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

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

[Carl Eugen Hoyos]

2018-03-06 19:38 GMT+01:00, Thomas Mundt :
>
> 2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos :
>
>> 2018-03-05 12:37 GMT+01:00, Paul B Mahol :
>> > On 3/5/18, Vasile Toncu  wrote:
>> >> Hello,
>> >>
>> >> Thanks for the review. I've made changes according to your guidance.
>> >>
>> >> It would be great to know if the community will go on with our
>> >> intention
>> >> of adding reinterlace as a alternative for tinterlace.
>> >>
>> >> That being said, here is the new patch.
>> >
>> > As already said, this is not acceptable.
>> >
>> > There is no point in having 2 filters with near same funcionality.
>>
>> If you consider the new filter ok, the existing filter will be removed
>> in the same push. I believe sending only the new filter makes
>> reviewing easier.
>
> For me reviewing would be easier when Vasile sends a patchset
> that includes the replacement of tinterlace filter.

The first patch would be quite trivial, this patch is the one you have to
review...

> That way existing fate tests could be used which are fortunately pretty
> extensive in this case.

I thought that one patch should remove the existing filter and
another one adding the new one but I agree that fate suggests
to do this in one patch.

> Also it would be helpful when you and/or other experienced ffmpeg
> developers would clarify first which parts of tinterlace have to be
> rewritten for proper relicensing.

The suggestion is to replace the whole filter instead of rewriting
parts which definitely is the safer solution.

> Being left in the dark makes working on patches frustrating.

I don't understand this comment, sorry.

> Another question is how to deal with vf_interlace? IMHO for the user there
> should be no difference in output, speed and license.

The whole point of this patch is to make a difference license-wise:
Having the same filter also for default compilation is an improvement
imo.

> Two options:
> 1. Relicensing and slice threading will also be ported to vf_interlace

> 2. The commands from vf_interlace will be included in the new tinterlace
> filter. vf_interlace will be deleted together with old tinterlace filter

I believe 2 was suggested. Is the patch not sufficient?

> I would prefer the second option, but maybe there are even better options
> that don´t come to my mind.

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

Re: [FFmpeg-devel] [PATCH v2] libavformat/tls: pass numeric hostnames to tls_connect_cbs()

[Jan Ekström]

On Sat, Mar 3, 2018 at 10:30 PM, Jan Ekström  wrote:
> On Wed, Feb 21, 2018 at 7:57 PM, Stefan _  wrote:
>> Hadn't seen that one, it does indeed describe this exact problem.
>> I've included it in the commit message, new patch attached.
>>
>
> Generally LGTM after checking the patch on patchwork
> https://patchwork.ffmpeg.org/patch/7693/
>
> Jan

Pushed.

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

Re: [FFmpeg-devel] [PATCH 1/2] avfilter/vf_*_vaapi: Add missing AV_OPT_FLAG_FILTERING_PARAM

[Jun Zhao]

On 2018/3/6 22:43, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavfilter/vf_misc_vaapi.c| 2 +-
>  libavfilter/vf_procamp_vaapi.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/vf_misc_vaapi.c b/libavfilter/vf_misc_vaapi.c
> index 8b179fe215..30b808a993 100644
> --- a/libavfilter/vf_misc_vaapi.c
> +++ b/libavfilter/vf_misc_vaapi.c
> @@ -226,7 +226,7 @@ static av_cold int sharpness_vaapi_init(AVFilterContext 
> *avctx)
>  }
>  
>  #define DOFFSET(x) offsetof(DenoiseVAAPIContext, x)
> -#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM)
> +#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_FILTERING_PARAM)
>  static const AVOption denoise_vaapi_options[] = {
>  { "denoise", "denoise level",
>DOFFSET(denoise), AV_OPT_TYPE_INT, { .i64 = DENOISE_DEFAULT }, 
> DENOISE_MIN, DENOISE_MAX, .flags = FLAGS },
> diff --git a/libavfilter/vf_procamp_vaapi.c b/libavfilter/vf_procamp_vaapi.c
> index 45a3120b23..10eccbe97d 100644
> --- a/libavfilter/vf_procamp_vaapi.c
> +++ b/libavfilter/vf_procamp_vaapi.c
> @@ -214,7 +214,7 @@ static av_cold int procamp_vaapi_init(AVFilterContext 
> *avctx)
>  }
>  
>  #define OFFSET(x) offsetof(ProcampVAAPIContext, x)
> -#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM)
> +#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_FILTERING_PARAM)
>  static const AVOption procamp_vaapi_options[] = {
>  { "b", "Output video brightness",
>OFFSET(bright),  AV_OPT_TYPE_FLOAT, { .dbl = BRIGHTNESS_DEFAULT }, 
> BRIGHTNESS_MIN, BRIGHTNESS_MAX, .flags = FLAGS },
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] mpegvideo_parser: fix indentation of an if statement

[Jan Ekström]

On Tue, Mar 6, 2018 at 10:39 AM, Paul B Mahol  wrote:
> LGTM

Cheers, pushed.

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

Re: [FFmpeg-devel] [PATCH 2/3] mpegvideo_parser: parse the output picture number

[Michael Niedermayer]

On Sun, Feb 11, 2018 at 08:31:40PM +0200, Jan Ekström wrote:
> On Sun, Feb 11, 2018 at 7:52 PM, Michael Niedermayer
>  wrote:
> >
> > should be ok unless its intended to also restore the MSB
> >
> 
> The value seemed to be 10bit and if the pointer is at the position
> right after the picture_start_code, then `buf[0] << 2` would move the
> 8 bits left of data two bits leftwards, and `buf[1] >> 6` would then
> move the topmost bits of the following byte to be the bottom-most
> bits.
> 
> Unless you mean that there's a forgotten `(uint16_t)` there as the end
> value has 10 bits of effective data, making the correct way of doing
> it something a la `(((uint16_t)buf[0]) << 2) | (((uint16_t)buf[1]) >>
> 6)`?

it was more a question about our API 

if output_picture_number is intended to be what it is called in english then
this patch is wrong as the number will frequently go back to 0 and
as more than 1024 pictures are output.
so taken as its english meaning, there would be code needed to 
increase(/decrease)
the MSB occasionally
OTOH if the field is intended to store a unspecified number of LSB only
i wonder what it could be used for

> 
> > Theres no code using output_picture_number currently
> >
> 
> Seems like some API users utilize this value.

What do they do with it ?

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH 1/2] avfilter/vf_*_vaapi: Add missing AV_OPT_FLAG_FILTERING_PARAM

[Michael Niedermayer]

On Wed, Mar 07, 2018 at 08:08:52AM +0800, Jun Zhao wrote:
> 
> 
> On 2018/3/6 22:43, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavfilter/vf_misc_vaapi.c| 2 +-
> >  libavfilter/vf_procamp_vaapi.c | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavfilter/vf_misc_vaapi.c b/libavfilter/vf_misc_vaapi.c
> > index 8b179fe215..30b808a993 100644
> > --- a/libavfilter/vf_misc_vaapi.c
> > +++ b/libavfilter/vf_misc_vaapi.c
> > @@ -226,7 +226,7 @@ static av_cold int sharpness_vaapi_init(AVFilterContext 
> > *avctx)
> >  }
> >  
> >  #define DOFFSET(x) offsetof(DenoiseVAAPIContext, x)
> > -#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM)
> > +#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_FILTERING_PARAM)
> >  static const AVOption denoise_vaapi_options[] = {
> >  { "denoise", "denoise level",
> >DOFFSET(denoise), AV_OPT_TYPE_INT, { .i64 = DENOISE_DEFAULT }, 
> > DENOISE_MIN, DENOISE_MAX, .flags = FLAGS },
> > diff --git a/libavfilter/vf_procamp_vaapi.c b/libavfilter/vf_procamp_vaapi.c
> > index 45a3120b23..10eccbe97d 100644
> > --- a/libavfilter/vf_procamp_vaapi.c
> > +++ b/libavfilter/vf_procamp_vaapi.c
> > @@ -214,7 +214,7 @@ static av_cold int procamp_vaapi_init(AVFilterContext 
> > *avctx)
> >  }
> >  
> >  #define OFFSET(x) offsetof(ProcampVAAPIContext, x)
> > -#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM)
> > +#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_FILTERING_PARAM)
> >  static const AVOption procamp_vaapi_options[] = {
> >  { "b", "Output video brightness",
> >OFFSET(bright),  AV_OPT_TYPE_FLOAT, { .dbl = BRIGHTNESS_DEFAULT }, 
> > BRIGHTNESS_MIN, BRIGHTNESS_MAX, .flags = FLAGS },
> LGTM

will apply

thx

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

[Thomas Mundt]

2018-03-07 0:49 GMT+01:00 Carl Eugen Hoyos :

> 2018-03-06 19:38 GMT+01:00, Thomas Mundt :
> >
> > 2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos :
> >
> >> 2018-03-05 12:37 GMT+01:00, Paul B Mahol :
> >> > On 3/5/18, Vasile Toncu  wrote:
> >> >> Hello,
> >> >>
> >> >> Thanks for the review. I've made changes according to your guidance.
> >> >>
> >> >> It would be great to know if the community will go on with our
> >> >> intention
> >> >> of adding reinterlace as a alternative for tinterlace.
> >> >>
> >> >> That being said, here is the new patch.
> >> >
> >> > As already said, this is not acceptable.
> >> >
> >> > There is no point in having 2 filters with near same funcionality.
> >>
> >> If you consider the new filter ok, the existing filter will be removed
> >> in the same push. I believe sending only the new filter makes
> >> reviewing easier.
> >
> > For me reviewing would be easier when Vasile sends a patchset
> > that includes the replacement of tinterlace filter.
>
> The first patch would be quite trivial, this patch is the one you have to
> review...
>
> > That way existing fate tests could be used which are fortunately pretty
> > extensive in this case.
>
> I thought that one patch should remove the existing filter and
> another one adding the new one but I agree that fate suggests
> to do this in one patch.
>

I would have no problem using fate with two patches - one that removes
vf_tinterlace and another that adds a new vf_tinterlace when they are both
available for the review.
But it seems that Vasile, and to be honest me too, understood your
suggestion that first he shall send a new filter with a different name.
That one shall be reviewed and later on vf_ tinterlace be replaced.

> Also it would be helpful when you and/or other experienced ffmpeg
> > developers would clarify first which parts of tinterlace have to be
> > rewritten for proper relicensing.
>
> The suggestion is to replace the whole filter instead of rewriting
> parts which definitely is the safer solution.
>

Do you mean the whole filter shall be rewritten?
I´m sorry, but I have no clue at what difference from the original, code,
that does the same thing, can be considered as rewritten.


>
> > Being left in the dark makes working on patches frustrating.
>
> I don't understand this comment, sorry.
>

I hope my answer above explains my problem.


>
> > Another question is how to deal with vf_interlace? IMHO for the user
> there
> > should be no difference in output, speed and license.
>
> The whole point of this patch is to make a difference license-wise:
> Having the same filter also for default compilation is an improvement
> imo.
>
> > Two options:
> > 1. Relicensing and slice threading will also be ported to vf_interlace
>
> > 2. The commands from vf_interlace will be included in the new tinterlace
> > filter. vf_interlace will be deleted together with old tinterlace filter
>
> I believe 2 was suggested. Is the patch not sufficient?
>

I didn´t notice that anything was suggested in relation to vf_interlace.
It is not included in the patch and maybe should be separate one.


> > I would prefer the second option, but maybe there are even better options
> > that don´t come to my mind.
>
>
Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] CodeAi generated fix for CWE 476 Null Pointer Dereference

[Michael Niedermayer]

On Tue, Mar 06, 2018 at 05:42:19PM -0500, C0deAi wrote:
> Tighten condition to prevent possible Null Dereference from
> access to field 'pts' loaded from variable 'in'.
> 
> Signed-off-by: C0deAi 
> ---
>  libavfilter/af_afade.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

breaks fate-filter-acrossfade

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/utils: free existing extradata before trying to allocate a new one

[Michael Niedermayer]

On Tue, Mar 06, 2018 at 01:42:36AM -0300, James Almer wrote:
> This prevents leaks in the rare cases the function is called when extradata
> already exists.
> 
> Signed-off-by: James Almer 
> ---
>  libavformat/utils.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 72531d4185..31340a484b 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -3245,6 +3245,7 @@ int ff_alloc_extradata(AVCodecParameters *par, int size)
>  {
>  int ret;
>  
> +av_freep(&par->extradata);
>  if (size < 0 || size >= INT32_MAX - AV_INPUT_BUFFER_PADDING_SIZE) {
>  par->extradata = NULL;
>  par->extradata_size = 0;

This causes memory corruption
...
[mpegts @ 0x7f8c74000a80] PES packet size mismatch
*** Error in `./ffplay': double free or corruption (fasttop): 
0x7f8c7402d9c0 ***
Aborted (core dumped)

I think this should not have been applied so quickly, i tested it as soon as i
had time and saw it but it was applied already

If it helps i can debug the cases i see to find out which calls cause them but
someone will still have to review all call sites probably for this change to
be safe


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

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


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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/utils: free existing extradata before trying to allocate a new one

[James Almer]

On 3/6/2018 10:47 PM, Michael Niedermayer wrote:
> On Tue, Mar 06, 2018 at 01:42:36AM -0300, James Almer wrote:
>> This prevents leaks in the rare cases the function is called when extradata
>> already exists.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavformat/utils.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>> index 72531d4185..31340a484b 100644
>> --- a/libavformat/utils.c
>> +++ b/libavformat/utils.c
>> @@ -3245,6 +3245,7 @@ int ff_alloc_extradata(AVCodecParameters *par, int 
>> size)
>>  {
>>  int ret;
>>  
>> +av_freep(&par->extradata);
>>  if (size < 0 || size >= INT32_MAX - AV_INPUT_BUFFER_PADDING_SIZE) {
>>  par->extradata = NULL;
>>  par->extradata_size = 0;
> 
> This causes memory corruption
> ...
> [mpegts @ 0x7f8c74000a80] PES packet size mismatch
> *** Error in `./ffplay': double free or corruption (fasttop): 
> 0x7f8c7402d9c0 ***
> Aborted (core dumped)

Is something freeing extradata and leaving a dangling pointer before
eventually calling ff_alloc_extradata()?
At least the two calls in mpegts.c don't seem to do that.

> 
> I think this should not have been applied so quickly, i tested it as soon as i
> had time and saw it but it was applied already

Fate passed when i tested it, and i got a positive review from the
author of the function in question, that's why i pushed it. Sorry.

> 
> If it helps i can debug the cases i see to find out which calls cause them but
> someone will still have to review all call sites probably for this change to
> be safe

Yes, help would be welcome. Crashes like this probably hint at frees
leaving dangling pointers across the codebase.

> 
> 
> [...]
> 
> 
> 
> ___
> 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] avformat/utils: free existing extradata before trying to allocate a new one

[James Almer]

On 3/6/2018 11:03 PM, James Almer wrote:
> On 3/6/2018 10:47 PM, Michael Niedermayer wrote:
>> On Tue, Mar 06, 2018 at 01:42:36AM -0300, James Almer wrote:
>>> This prevents leaks in the rare cases the function is called when extradata
>>> already exists.
>>>
>>> Signed-off-by: James Almer 
>>> ---
>>>  libavformat/utils.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>>> index 72531d4185..31340a484b 100644
>>> --- a/libavformat/utils.c
>>> +++ b/libavformat/utils.c
>>> @@ -3245,6 +3245,7 @@ int ff_alloc_extradata(AVCodecParameters *par, int 
>>> size)
>>>  {
>>>  int ret;
>>>  
>>> +av_freep(&par->extradata);
>>>  if (size < 0 || size >= INT32_MAX - AV_INPUT_BUFFER_PADDING_SIZE) {
>>>  par->extradata = NULL;
>>>  par->extradata_size = 0;
>>
>> This causes memory corruption
>> ...
>> [mpegts @ 0x7f8c74000a80] PES packet size mismatch
>> *** Error in `./ffplay': double free or corruption (fasttop): 
>> 0x7f8c7402d9c0 ***
>> Aborted (core dumped)
> 
> Is something freeing extradata and leaving a dangling pointer before
> eventually calling ff_alloc_extradata()?
> At least the two calls in mpegts.c don't seem to do that.
> 
>>
>> I think this should not have been applied so quickly, i tested it as soon as 
>> i
>> had time and saw it but it was applied already
> 
> Fate passed when i tested it, and i got a positive review from the
> author of the function in question, that's why i pushed it. Sorry.
> 
>>
>> If it helps i can debug the cases i see to find out which calls cause them 
>> but
>> someone will still have to review all call sites probably for this change to
>> be safe
> 
> Yes, help would be welcome. Crashes like this probably hint at frees
> leaving dangling pointers across the codebase.

Does the attached patch fix this crash?
From 1f128144cdd2f212b2ec74b29e2db771ad0977a6 Mon Sep 17 00:00:00 2001
From: James Almer 
Date: Tue, 6 Mar 2018 23:26:22 -0300
Subject: [PATCH] avformat/isom: don't free extradata before calling
 ff_get_extradata()

Using av_free() leaves a dangling pointer.

Signed-off-by: James Almer 
---
 libavformat/isom.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavformat/isom.c b/libavformat/isom.c
index 59502a8b3f..2792371c25 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -526,7 +526,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
 av_log(fc, AV_LOG_TRACE, "Specific MPEG-4 header len=%d\n", len);
 if (!len || (uint64_t)len > (1<<30))
 return AVERROR_INVALIDDATA;
-av_free(st->codecpar->extradata);
 if ((ret = ff_get_extradata(fc, st->codecpar, pb, len)) < 0)
 return ret;
 if (st->codecpar->codec_id == AV_CODEC_ID_AAC) {
-- 
2.16.2

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/utils: free existing extradata before trying to allocate a new one

[Michael Niedermayer]

On Tue, Mar 06, 2018 at 11:03:55PM -0300, James Almer wrote:
> On 3/6/2018 10:47 PM, Michael Niedermayer wrote:
> > On Tue, Mar 06, 2018 at 01:42:36AM -0300, James Almer wrote:
> >> This prevents leaks in the rare cases the function is called when extradata
> >> already exists.
> >>
> >> Signed-off-by: James Almer 
> >> ---
> >>  libavformat/utils.c | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/libavformat/utils.c b/libavformat/utils.c
> >> index 72531d4185..31340a484b 100644
> >> --- a/libavformat/utils.c
> >> +++ b/libavformat/utils.c
> >> @@ -3245,6 +3245,7 @@ int ff_alloc_extradata(AVCodecParameters *par, int 
> >> size)
> >>  {
> >>  int ret;
> >>  
> >> +av_freep(&par->extradata);
> >>  if (size < 0 || size >= INT32_MAX - AV_INPUT_BUFFER_PADDING_SIZE) {
> >>  par->extradata = NULL;
> >>  par->extradata_size = 0;
> > 
> > This causes memory corruption
> > ...
> > [mpegts @ 0x7f8c74000a80] PES packet size mismatch
> > *** Error in `./ffplay': double free or corruption (fasttop): 
> > 0x7f8c7402d9c0 ***
> > Aborted (core dumped)
> 
> Is something freeing extradata and leaving a dangling pointer before
> eventually calling ff_alloc_extradata()?
> At least the two calls in mpegts.c don't seem to do that.
> 
> > 
> > I think this should not have been applied so quickly, i tested it as soon 
> > as i
> > had time and saw it but it was applied already
> 
> Fate passed when i tested it, and i got a positive review from the
> author of the function in question, that's why i pushed it. Sorry.
> 
> > 
> > If it helps i can debug the cases i see to find out which calls cause them 
> > but
> > someone will still have to review all call sites probably for this change to
> > be safe
> 
> Yes, help would be welcome. Crashes like this probably hint at frees
> leaving dangling pointers across the codebase.

heres some valgrind output

==8248== Thread 15:peated 5 times
==8248== Invalid free() / delete / delete[] / realloc()
==8248==at 0x4C2B5D9: free (vg_replace_malloc.c:446)
==8248==by 0x75B0FE: ff_get_extradata (in ffmpeg/ffplay_g)
==8248==by 0x68F1E1: ff_mp4_read_dec_config_descr (in ffmpeg/ffplay_g)
==8248==by 0x6D7A2C: m4sl_cb (in ffmpeg/ffplay_g)
==8248==by 0x6D6539: handle_packet (in ffmpeg/ffplay_g)
==8248==by 0x6D69B3: handle_packets (in ffmpeg/ffplay_g)
==8248==by 0x6D6A53: mpegts_read_packet (in ffmpeg/ffplay_g)
==8248==by 0x754AA1: ff_read_packet (in ffmpeg/ffplay_g)
==8248==by 0x75E32F: avformat_find_stream_info (in ffmpeg/ffplay_g)
==8248==by 0x4B86D8: read_thread (in ffmpeg/ffplay_g)
==8248==by 0x74742EC: SDL_RunThread (SDL_thread.c:282)
==8248==by 0x74D21A8: RunThread (SDL_systhread.c:75)
==8248==  Address 0x3085a000 is 0 bytes inside a block of size 88 free'd
==8248==at 0x4C2B5D9: free (vg_replace_malloc.c:446)
==8248==by 0x68F1CD: ff_mp4_read_dec_config_descr (in ffmpeg/ffplay_g)
==8248==by 0x6D7A2C: m4sl_cb (in ffmpeg/ffplay_g)
==8248==by 0x6D6539: handle_packet (in ffmpeg/ffplay_g)
==8248==by 0x6D69B3: handle_packets (in ffmpeg/ffplay_g)
==8248==by 0x6D6A53: mpegts_read_packet (in ffmpeg/ffplay_g)
==8248==by 0x754AA1: ff_read_packet (in ffmpeg/ffplay_g)
==8248==by 0x75E32F: avformat_find_stream_info (in ffmpeg/ffplay_g)
==8248==by 0x4B86D8: read_thread (in ffmpeg/ffplay_g)
==8248==by 0x74742EC: SDL_RunThread (SDL_thread.c:282)
==8248==by 0x74D21A8: RunThread (SDL_systhread.c:75)
==8248==by 0xB8A2183: start_thread (pthread_create.c:312)
==8248== 
Last message repeated 5 times

i can provide a better debug output tomorrow, need to go afk now


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

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/utils: free existing extradata before trying to allocate a new one

[James Almer]

On 3/6/2018 11:29 PM, Michael Niedermayer wrote:
> On Tue, Mar 06, 2018 at 11:03:55PM -0300, James Almer wrote:
>> On 3/6/2018 10:47 PM, Michael Niedermayer wrote:
>>> On Tue, Mar 06, 2018 at 01:42:36AM -0300, James Almer wrote:
 This prevents leaks in the rare cases the function is called when extradata
 already exists.

 Signed-off-by: James Almer 
 ---
  libavformat/utils.c | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/libavformat/utils.c b/libavformat/utils.c
 index 72531d4185..31340a484b 100644
 --- a/libavformat/utils.c
 +++ b/libavformat/utils.c
 @@ -3245,6 +3245,7 @@ int ff_alloc_extradata(AVCodecParameters *par, int 
 size)
  {
  int ret;
  
 +av_freep(&par->extradata);
  if (size < 0 || size >= INT32_MAX - AV_INPUT_BUFFER_PADDING_SIZE) {
  par->extradata = NULL;
  par->extradata_size = 0;
>>>
>>> This causes memory corruption
>>> ...
>>> [mpegts @ 0x7f8c74000a80] PES packet size mismatch
>>> *** Error in `./ffplay': double free or corruption (fasttop): 
>>> 0x7f8c7402d9c0 ***
>>> Aborted (core dumped)
>>
>> Is something freeing extradata and leaving a dangling pointer before
>> eventually calling ff_alloc_extradata()?
>> At least the two calls in mpegts.c don't seem to do that.
>>
>>>
>>> I think this should not have been applied so quickly, i tested it as soon 
>>> as i
>>> had time and saw it but it was applied already
>>
>> Fate passed when i tested it, and i got a positive review from the
>> author of the function in question, that's why i pushed it. Sorry.
>>
>>>
>>> If it helps i can debug the cases i see to find out which calls cause them 
>>> but
>>> someone will still have to review all call sites probably for this change to
>>> be safe
>>
>> Yes, help would be welcome. Crashes like this probably hint at frees
>> leaving dangling pointers across the codebase.
> 
> heres some valgrind output
> 
> ==8248== Thread 15:peated 5 times
> ==8248== Invalid free() / delete / delete[] / realloc()
> ==8248==at 0x4C2B5D9: free (vg_replace_malloc.c:446)
> ==8248==by 0x75B0FE: ff_get_extradata (in ffmpeg/ffplay_g)
> ==8248==by 0x68F1E1: ff_mp4_read_dec_config_descr (in ffmpeg/ffplay_g)

Figures. The patch i sent a few minutes ago should fix it then.

> ==8248==by 0x6D7A2C: m4sl_cb (in ffmpeg/ffplay_g)
> ==8248==by 0x6D6539: handle_packet (in ffmpeg/ffplay_g)
> ==8248==by 0x6D69B3: handle_packets (in ffmpeg/ffplay_g)
> ==8248==by 0x6D6A53: mpegts_read_packet (in ffmpeg/ffplay_g)
> ==8248==by 0x754AA1: ff_read_packet (in ffmpeg/ffplay_g)
> ==8248==by 0x75E32F: avformat_find_stream_info (in ffmpeg/ffplay_g)
> ==8248==by 0x4B86D8: read_thread (in ffmpeg/ffplay_g)
> ==8248==by 0x74742EC: SDL_RunThread (SDL_thread.c:282)
> ==8248==by 0x74D21A8: RunThread (SDL_systhread.c:75)
> ==8248==  Address 0x3085a000 is 0 bytes inside a block of size 88 free'd
> ==8248==at 0x4C2B5D9: free (vg_replace_malloc.c:446)
> ==8248==by 0x68F1CD: ff_mp4_read_dec_config_descr (in ffmpeg/ffplay_g)
> ==8248==by 0x6D7A2C: m4sl_cb (in ffmpeg/ffplay_g)
> ==8248==by 0x6D6539: handle_packet (in ffmpeg/ffplay_g)
> ==8248==by 0x6D69B3: handle_packets (in ffmpeg/ffplay_g)
> ==8248==by 0x6D6A53: mpegts_read_packet (in ffmpeg/ffplay_g)
> ==8248==by 0x754AA1: ff_read_packet (in ffmpeg/ffplay_g)
> ==8248==by 0x75E32F: avformat_find_stream_info (in ffmpeg/ffplay_g)
> ==8248==by 0x4B86D8: read_thread (in ffmpeg/ffplay_g)
> ==8248==by 0x74742EC: SDL_RunThread (SDL_thread.c:282)
> ==8248==by 0x74D21A8: RunThread (SDL_systhread.c:75)
> ==8248==by 0xB8A2183: start_thread (pthread_create.c:312)
> ==8248== 
> Last message repeated 5 times
> 
> i can provide a better debug output tomorrow, need to go afk now
> 
> 
> [...]
> 
> 
> 
> ___
> 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] checkasm/hevc_sao : add hevc_sao for checkasm

[Yingming Fan]

Hi James, I agree with what you said, we should test 8 10 and 12 bit.

But i noticed that hevc_idct and hevc_add_res also not test 12 bit. I think
we should also add 12 bit for these checkasm codes.

2018-03-06 21:55 GMT+08:00 James Almer :

> On 3/3/2018 12:15 AM, Yingming Fan wrote:
> > ---
> >  tests/checkasm/Makefile   |   2 +-
> >  tests/checkasm/checkasm.c |   1 +
> >  tests/checkasm/checkasm.h |   1 +
> >  tests/checkasm/hevc_sao.c | 158 ++
> 
> >  tests/fate/checkasm.mak   |   1 +
> >  5 files changed, 162 insertions(+), 1 deletion(-)
> >  create mode 100644 tests/checkasm/hevc_sao.c
> >
> > diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
> > index 77bdcf6e65..0520e264e2 100644
> > --- a/tests/checkasm/Makefile
> > +++ b/tests/checkasm/Makefile
> > @@ -23,7 +23,7 @@ AVCODECOBJS-$(CONFIG_EXR_DECODER)   += exrdsp.o
> >  AVCODECOBJS-$(CONFIG_HUFFYUV_DECODER)   += huffyuvdsp.o
> >  AVCODECOBJS-$(CONFIG_JPEG2000_DECODER)  += jpeg2000dsp.o
> >  AVCODECOBJS-$(CONFIG_PIXBLOCKDSP)   += pixblockdsp.o
> > -AVCODECOBJS-$(CONFIG_HEVC_DECODER)  += hevc_add_res.o hevc_idct.o
> > +AVCODECOBJS-$(CONFIG_HEVC_DECODER)  += hevc_add_res.o hevc_idct.o
> hevc_sao.o
> >  AVCODECOBJS-$(CONFIG_UTVIDEO_DECODER)   += utvideodsp.o
> >  AVCODECOBJS-$(CONFIG_V210_ENCODER)  += v210enc.o
> >  AVCODECOBJS-$(CONFIG_VP9_DECODER)   += vp9dsp.o
> > diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
> > index a4b8aff984..fe81d139c6 100644
> > --- a/tests/checkasm/checkasm.c
> > +++ b/tests/checkasm/checkasm.c
> > @@ -116,6 +116,7 @@ static const struct {
> >  #if CONFIG_HEVC_DECODER
> >  { "hevc_add_res", checkasm_check_hevc_add_res },
> >  { "hevc_idct", checkasm_check_hevc_idct },
> > +{ "hevc_sao", checkasm_check_hevc_sao },
> >  #endif
> >  #if CONFIG_HUFFYUV_DECODER
> >  { "huffyuvdsp", checkasm_check_huffyuvdsp },
> > diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
> > index 3de38e6717..8b9d96bc15 100644
> > --- a/tests/checkasm/checkasm.h
> > +++ b/tests/checkasm/checkasm.h
> > @@ -57,6 +57,7 @@ void checkasm_check_h264pred(void);
> >  void checkasm_check_h264qpel(void);
> >  void checkasm_check_hevc_add_res(void);
> >  void checkasm_check_hevc_idct(void);
> > +void checkasm_check_hevc_sao(void);
> >  void checkasm_check_huffyuvdsp(void);
> >  void checkasm_check_jpeg2000dsp(void);
> >  void checkasm_check_llviddsp(void);
> > diff --git a/tests/checkasm/hevc_sao.c b/tests/checkasm/hevc_sao.c
> > new file mode 100644
> > index 00..e2a0a54e9b
> > --- /dev/null
> > +++ b/tests/checkasm/hevc_sao.c
> > @@ -0,0 +1,158 @@
> > +/*
> > + * Copyright (c) 2018 Yingming Fan 
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 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 General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU 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 "libavutil/intreadwrite.h"
> > +
> > +#include "libavcodec/avcodec.h"
> > +
> > +#include "libavcodec/hevcdsp.h"
> > +
> > +#include "checkasm.h"
> > +
> > +static const uint32_t pixel_mask[3] = { 0x, 0x01ff01ff,
> 0x03ff03ff };
> > +static const uint32_t sao_size[5] = {8, 16, 32, 48, 64};
> > +
> > +#define SIZEOF_PIXEL ((bit_depth + 7) / 8)
> > +#define PIXEL_STRIDE (2*MAX_PB_SIZE + AV_INPUT_BUFFER_PADDING_SIZE)
> //same with sao_edge src_stride
> > +#define BUF_SIZE (PIXEL_STRIDE * (64+2) * 2) //+2 for top and bottom
> row, *2 for high bit depth
> > +#define OFFSET_THRESH (1 << (bit_depth - 5))
> > +#define OFFSET_LENGTH 5
> > +
> > +#define randomize_buffers(buf0, buf1, size) \
> > +do {\
> > +uint32_t mask = pixel_mask[bit_depth - 8];  \
> > +int i;  \
> > +if (bit_depth == 8) {   \
> > +for (i = 0; i < size; i += 4) { \
> > +uint32_t r = rnd() & mask;  \
> > +AV_WN32A(buf0 + i, r);  \
> > +AV_WN32A(buf1 + i, r);  \
> > +}   \
> > +} else {   

Re: [FFmpeg-devel] [PATCH 1/2] avformat/utils: free existing extradata before trying to allocate a new one

[Michael Niedermayer]

On Tue, Mar 06, 2018 at 11:27:54PM -0300, James Almer wrote:
> On 3/6/2018 11:03 PM, James Almer wrote:
> > On 3/6/2018 10:47 PM, Michael Niedermayer wrote:
> >> On Tue, Mar 06, 2018 at 01:42:36AM -0300, James Almer wrote:
> >>> This prevents leaks in the rare cases the function is called when 
> >>> extradata
> >>> already exists.
> >>>
> >>> Signed-off-by: James Almer 
> >>> ---
> >>>  libavformat/utils.c | 1 +
> >>>  1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/libavformat/utils.c b/libavformat/utils.c
> >>> index 72531d4185..31340a484b 100644
> >>> --- a/libavformat/utils.c
> >>> +++ b/libavformat/utils.c
> >>> @@ -3245,6 +3245,7 @@ int ff_alloc_extradata(AVCodecParameters *par, int 
> >>> size)
> >>>  {
> >>>  int ret;
> >>>  
> >>> +av_freep(&par->extradata);
> >>>  if (size < 0 || size >= INT32_MAX - AV_INPUT_BUFFER_PADDING_SIZE) {
> >>>  par->extradata = NULL;
> >>>  par->extradata_size = 0;
> >>
> >> This causes memory corruption
> >> ...
> >> [mpegts @ 0x7f8c74000a80] PES packet size mismatch
> >> *** Error in `./ffplay': double free or corruption (fasttop): 
> >> 0x7f8c7402d9c0 ***
> >> Aborted (core dumped)
> > 
> > Is something freeing extradata and leaving a dangling pointer before
> > eventually calling ff_alloc_extradata()?
> > At least the two calls in mpegts.c don't seem to do that.
> > 
> >>
> >> I think this should not have been applied so quickly, i tested it as soon 
> >> as i
> >> had time and saw it but it was applied already
> > 
> > Fate passed when i tested it, and i got a positive review from the
> > author of the function in question, that's why i pushed it. Sorry.
> > 
> >>
> >> If it helps i can debug the cases i see to find out which calls cause them 
> >> but
> >> someone will still have to review all call sites probably for this change 
> >> to
> >> be safe
> > 
> > Yes, help would be welcome. Crashes like this probably hint at frees
> > leaving dangling pointers across the codebase.
> 
> Does the attached patch fix this crash?

yes, thanks!


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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/utils: free existing extradata before trying to allocate a new one

[James Almer]

On 3/6/2018 11:40 PM, Michael Niedermayer wrote:
> On Tue, Mar 06, 2018 at 11:27:54PM -0300, James Almer wrote:
>> On 3/6/2018 11:03 PM, James Almer wrote:
>>> On 3/6/2018 10:47 PM, Michael Niedermayer wrote:
 On Tue, Mar 06, 2018 at 01:42:36AM -0300, James Almer wrote:
> This prevents leaks in the rare cases the function is called when 
> extradata
> already exists.
>
> Signed-off-by: James Almer 
> ---
>  libavformat/utils.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 72531d4185..31340a484b 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -3245,6 +3245,7 @@ int ff_alloc_extradata(AVCodecParameters *par, int 
> size)
>  {
>  int ret;
>  
> +av_freep(&par->extradata);
>  if (size < 0 || size >= INT32_MAX - AV_INPUT_BUFFER_PADDING_SIZE) {
>  par->extradata = NULL;
>  par->extradata_size = 0;

 This causes memory corruption
 ...
 [mpegts @ 0x7f8c74000a80] PES packet size mismatch
 *** Error in `./ffplay': double free or corruption (fasttop): 
 0x7f8c7402d9c0 ***
 Aborted (core dumped)
>>>
>>> Is something freeing extradata and leaving a dangling pointer before
>>> eventually calling ff_alloc_extradata()?
>>> At least the two calls in mpegts.c don't seem to do that.
>>>

 I think this should not have been applied so quickly, i tested it as soon 
 as i
 had time and saw it but it was applied already
>>>
>>> Fate passed when i tested it, and i got a positive review from the
>>> author of the function in question, that's why i pushed it. Sorry.
>>>

 If it helps i can debug the cases i see to find out which calls cause them 
 but
 someone will still have to review all call sites probably for this change 
 to
 be safe
>>>
>>> Yes, help would be welcome. Crashes like this probably hint at frees
>>> leaving dangling pointers across the codebase.
>>
>> Does the attached patch fix this crash?
> 
> yes, thanks!

Pushed. Sorry again for the regression.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] GSoC

[Dylan Fernando]

Thanks, it works now

Would trying to implement an OpenCL version of vf_fade be a good idea for a
qualification task, or would it be a better idea to try a different filter?

Regards,
Dylan

On Wed, Mar 7, 2018 at 1:20 AM, Mark Thompson  wrote:

> On 06/03/18 12:37, Dylan Fernando wrote:
> > Hi,
> >
> > I am Dylan Fernando. I am a Computer Science student from Australia. I am
> > new to FFmpeg and I wish to apply for GSoC this year.
> > I would like to do the Video filtering with OpenCL project and I have a
> few
> > questions. Would trying to implement an opencl version of vf_fade be a
> good
> > idea for the qualification task, or would I be better off using a
> different
> > filter?
> >
> > Also, I’m having a bit of trouble with running unsharp_opencl. I tried
> > running:
> > ffmpeg -hide_banner -nostats -v verbose -init_hw_device opencl=ocl:0.1
> > -filter_hw_device ocl -i space.mpg -filter_complex unsharp_opencl
> output.mp4
> >
> > but I got the error:
> > [AVHWDeviceContext @ 0x7fdac050c700] 0.1: Apple / Intel(R) Iris(TM)
> > Graphics 6100
> > [mpeg @ 0x7fdac3132600] max_analyze_duration 500 reached at 5005000
> > microseconds st:0
> > Input #0, mpeg, from 'space.mpg':
> >   Duration: 00:00:21.99, start: 0.387500, bitrate: 6108 kb/s
> > Stream #0:0[0x1e0]: Video: mpeg2video (Main), 1 reference frame,
> > yuv420p(tv, bt470bg, bottom first, left), 720x480 [SAR 8:9 DAR 4:3], 6000
> > kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
> > Stream mapping:
> >   Stream #0:0 (mpeg2video) -> unsharp_opencl
> >   unsharp_opencl -> Stream #0:0 (mpeg4)
> > Press [q] to stop, [?] for help
> > [graph 0 input from stream 0:0 @ 0x7fdac0418800] w:720 h:480
> pixfmt:yuv420p
> > tb:1/9 fr:3/1001 sar:8/9 sws_param:flags=2
> > [auto_scaler_0 @ 0x7fdac05232c0] w:iw h:ih flags:'bilinear' interl:0
> > [Parsed_unsharp_opencl_0 @ 0x7fdac0715a80] auto-inserting filter
> > 'auto_scaler_0' between the filter 'graph 0 input from stream 0:0' and
> the
> > filter 'Parsed_unsharp_opencl_0'
> > Impossible to convert between the formats supported by the filter 'graph
> 0
> > input from stream 0:0' and the filter 'auto_scaler_0'
> > Error reinitializing filters!
> > Failed to inject frame into filter network: Function not implemented
> > Error while processing the decoded data for stream #0:0
> > Conversion failed!
> >
> > How do I correctly run unsharp_opencl? Should I be running it on a
> > different video file?
>
> It's intended to be used in filter graphs where much of the activity is
> already happening on the GPU, so the input and output are in the
> AV_PIX_FMT_OPENCL format which contains GPU-side OpenCL images.
>
> If you want to use it standalone then you need hwupload and hwdownload
> filters to move the frames between the CPU and GPU.  For your example, it
> should work with:
>
> ffmpeg -init_hw_device opencl=ocl:0.1 -filter_hw_device ocl -i space.mpg
> -filter_complex hwupload,unsharp_opencl,hwdownload output.mp4
>
> (There are constraints on what formats can be used and therefore suitable
> files (or required format conversions), but I believe a normal yuv420p
> video like this should work in all cases.)
>
> - Mark
> ___
> 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

[FFmpeg-devel] [PATCH v2] checkasm/hevc_sao : add hevc_sao for checkasm

[Yingming Fan]

From: Yingming Fan 

---
 Previous patch test 8 9 and 10 bit depth, because i consult codes from 
hevc_idct and hevc_add_res.
 While this patch test 8 10 and 12 bit depth like what VP9 does. I will submit 
another patch fix these issue in hevc_idct and hevc_add_res.
 This patch also refined randomize_buffers codes compared to previous patch.
 
 tests/checkasm/Makefile   |   2 +-
 tests/checkasm/checkasm.c |   1 +
 tests/checkasm/checkasm.h |   1 +
 tests/checkasm/hevc_sao.c | 150 ++
 tests/fate/checkasm.mak   |   1 +
 5 files changed, 154 insertions(+), 1 deletion(-)
 create mode 100644 tests/checkasm/hevc_sao.c

diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index 77bdcf6e65..0520e264e2 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -23,7 +23,7 @@ AVCODECOBJS-$(CONFIG_EXR_DECODER)   += exrdsp.o
 AVCODECOBJS-$(CONFIG_HUFFYUV_DECODER)   += huffyuvdsp.o
 AVCODECOBJS-$(CONFIG_JPEG2000_DECODER)  += jpeg2000dsp.o
 AVCODECOBJS-$(CONFIG_PIXBLOCKDSP)   += pixblockdsp.o
-AVCODECOBJS-$(CONFIG_HEVC_DECODER)  += hevc_add_res.o hevc_idct.o
+AVCODECOBJS-$(CONFIG_HEVC_DECODER)  += hevc_add_res.o hevc_idct.o 
hevc_sao.o
 AVCODECOBJS-$(CONFIG_UTVIDEO_DECODER)   += utvideodsp.o
 AVCODECOBJS-$(CONFIG_V210_ENCODER)  += v210enc.o
 AVCODECOBJS-$(CONFIG_VP9_DECODER)   += vp9dsp.o
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index a4b8aff984..fe81d139c6 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -116,6 +116,7 @@ static const struct {
 #if CONFIG_HEVC_DECODER
 { "hevc_add_res", checkasm_check_hevc_add_res },
 { "hevc_idct", checkasm_check_hevc_idct },
+{ "hevc_sao", checkasm_check_hevc_sao },
 #endif
 #if CONFIG_HUFFYUV_DECODER
 { "huffyuvdsp", checkasm_check_huffyuvdsp },
diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index 3de38e6717..8b9d96bc15 100644
--- a/tests/checkasm/checkasm.h
+++ b/tests/checkasm/checkasm.h
@@ -57,6 +57,7 @@ void checkasm_check_h264pred(void);
 void checkasm_check_h264qpel(void);
 void checkasm_check_hevc_add_res(void);
 void checkasm_check_hevc_idct(void);
+void checkasm_check_hevc_sao(void);
 void checkasm_check_huffyuvdsp(void);
 void checkasm_check_jpeg2000dsp(void);
 void checkasm_check_llviddsp(void);
diff --git a/tests/checkasm/hevc_sao.c b/tests/checkasm/hevc_sao.c
new file mode 100644
index 00..8d0cf80774
--- /dev/null
+++ b/tests/checkasm/hevc_sao.c
@@ -0,0 +1,150 @@
+/*
+ * Copyright (c) 2018 Yingming Fan 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU 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 "libavutil/intreadwrite.h"
+
+#include "libavcodec/avcodec.h"
+
+#include "libavcodec/hevcdsp.h"
+
+#include "checkasm.h"
+
+static const uint32_t pixel_mask[3] = { 0x, 0x03ff03ff, 0x0fff0fff };
+static const uint32_t sao_size[5] = {8, 16, 32, 48, 64};
+
+#define SIZEOF_PIXEL ((bit_depth + 7) / 8)
+#define PIXEL_STRIDE (2*MAX_PB_SIZE + AV_INPUT_BUFFER_PADDING_SIZE) //same 
with sao_edge src_stride
+#define BUF_SIZE (PIXEL_STRIDE * (64+2) * 2) //+2 for top and bottom row, *2 
for high bit depth
+#define OFFSET_THRESH (1 << (bit_depth - 5))
+#define OFFSET_LENGTH 5
+
+#define randomize_buffers(buf0, buf1, size) \
+do {\
+uint32_t mask = pixel_mask[(bit_depth - 8) >> 1];   \
+int k;  \
+for (k = 0; k < size; k += 4) { \
+uint32_t r = rnd() & mask;  \
+AV_WN32A(buf0 + k, r);  \
+AV_WN32A(buf1 + k, r);  \
+}   \
+} while (0)
+
+#define randomize_buffers2(buf, size)   \
+do {\
+uint32_t max_offset = OFFSET_THRESH;\
+int k;  \
+if (bit_depth == 8) {   \
+for (k = 0; k < size; k++) {\
+uint8_t r = rnd() % max_offset; \
+   

[FFmpeg-devel] h.264 and h.265 bitstream consultant needed

[Alex Day]

Hello,

Our company has need of some consulting services to support some development 
potentially including direct bitstream modifications to h.264 and h.265 bit 
streams.

Would anyone be able to provide these sort of consultancy services? If so, what 
are your normal arrangements for this kind of work? If not, could you refer 
someone who might do this kind of work?

Best Regards,
Alex Day

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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Don't pass VAConfigAttribEncPackedHeaders with value set to 0

[Xiang, Haihao]

On Tue, 2018-03-06 at 14:42 +, Mark Thompson wrote:
> On 06/03/18 06:04, Eoff, Ullysses A wrote:
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > > Mark Thompson
> > > Sent: Tuesday, February 13, 2018 11:54 AM
> > > To: FFmpeg development discussions and patches 
> > > Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Don't pass
> > > VAConfigAttribEncPackedHeaders with value set to 0
> > > 
> > > On 13/02/18 18:52, Mark Thompson wrote:
> > > > On 13/02/18 08:24, Haihao Xiang wrote:
> > > > > Recent Intel i965 driver commit strictly disallows application to set
> > > > > unsupported attribute values, VA_ENC_PACKED_HEADER_NONE (0) is not
> > > > > used
> > > > > in Intel i965 driver, so application shouldn't pass this value to the
> > > > > driver. On the other hand, VA_ENC_PACKED_HEADER_NONE (0) means the
> > > > > driver doesn't support any packed header mode, so application also
> > > > > shouldn't pass packed header to driver if a driver returns
> > > > > VA_ENC_PACKED_HEADER_NONE (0), the driver should work without
> > > > > VAConfigAttribEncPackedHeaders set for this case.
> > > > > 
> > > > > In addition, VA_ATTRIB_NOT_SUPPORTED and VA_ENC_PACKED_HEADER_NONE
> > > > > make
> > > > > thing messy, we will deprecate VA_ENC_PACKED_HEADER_NONE in the
> > > > > future. See https://github.com/intel/libva/issues/178 for more
> > > > > information.
> > > > > 
> > > > > This fixes broken vp9 encoder on Kably Lake with Intel I965 driver.
> > > > > 
> > > > > Signed-off-by: Haihao Xiang 
> > > > > ---
> > > > >  libavcodec/vaapi_encode.c | 4 
> > > > >  1 file changed, 4 insertions(+)
> > > > > 
> > > > > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > > > > index e371f5761ee..1d30aabed40 100644
> > > > > --- a/libavcodec/vaapi_encode.c
> > > > > +++ b/libavcodec/vaapi_encode.c
> > > > > @@ -,6 +,10 @@ static av_cold int
> > > > > vaapi_encode_config_attributes(AVCodecContext *avctx)
> > > > > ctx->va_packed_headers, attr[i].value);
> > > > >  ctx->va_packed_headers &= attr[i].value;
> > > > >  }
> > > > > +
> > > > > +if (!ctx->va_packed_headers)
> > > > > +continue;
> > > > > +
> > > > >  ctx->config_attributes[ctx->nb_config_attributes++] =
> > > > >  (VAConfigAttrib) {
> > > > >  .type  = VAConfigAttribEncPackedHeaders,
> > > > > 
> > > > 
> > > > This seems wrong to me: the driver has indicated that packed headers are
> > > > supported, so the user is providing this attribute to
> > > 
> > > indicate to the driver that they will not use any of them.  Compare the
> > > VP8 case, where the driver does not support them and says so -
> > > there we correctly don't provide the attribute (though maybe the
> > > commentary could be clearer on that).
> > > 
> > > Right, I hadn't realised you had already made a change so that encoding is
> > > currently broken.  I've made
> > >  to revert the
> > > API/ABI-breaking part of the change.
> > > 
> > > Thanks,
> > > 
> > > - Mark
> > 
> > I prefer this patch over the one for intel-vaapi-driver.
> 
> Well, the driver patch should be applied anyway to fix the API/ABI break
> (existing libavcodec builds should continue to work on the new
> library/driver), but it can be reverted on the next major version bump.  Maybe
> a warning (i965_log_info()) could be added to the patch to indicate to the
> client that the usage is deprecated in libva 2 and will be removed in libva 3?
> 

Ok, I will merge your driver patch for this special case (allow 0 for
VAConfigAttribEncPackedHeaders when calling vaCreateConfig()) to resolve this
issue. Could you update your patch to add some warning message?

> > The va.h documentation for VA_ENC_PACKED_HEADER_NONE
> > says "Driver does not support any packed headers mode".
> > Hence, it's only valid for reporting to client that packed headers
> > are "unsupported".  Unfortunately, VA_ENC_PACKED_HEADER_NONE 
> > is redundant/ambiguous since there is also
> > VA_ATTRIB_NOT_SUPPORTED to relay the same information.
> > This is why we want to deprecate VA_ENC_PACKED_HEADER_NONE
> > in VAAPI.
> > 
> > I don't think it's correct for clients to send
> > VA_ENC_PACKED_HEADER_NONE attribute value to the driver
> > when the driver reports packed headers are "supported".  It
> > goes against VA_ENC_PACKED_HEADER_NONE's documented
> > purpose.  AFAIK, libavcodec is the only library that does this.  It
> > is better to just omit the attribute altogether if client does not
> > want to use any of the "supported" packed headers.  And this
> > patch solves that.
> 
> I still disagree with this logic.  The driver supplied a bitmask of allowed
> packed headers, and the client picks which of those it will send and supplies
> that back to the driver with vaCreateConfig().  If the drive

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Don't return error if the underlying driver doesn't support B frame

[Xiang, Haihao]

Hi Mark,

Do you have any comment to this patch? FFmpeg-vaapi fails to use low power mode
for H.264 encoding.

Thanks
Haihao

> On Wed, 2018-02-07 at 10:31 +0800, Jun Zhao wrote:
> > 
> > On 2018/2/6 16:17, Haihao Xiang wrote:
> > > It is possible B frame is not supported for VAEntrypointEncSliceLP and
> > > the underlying driver has advertised it, so it is better to disable B
> > > frame instead of returning error for this case
> > > 
> > > Signed-off-by: Haihao Xiang 
> > > ---
> > >  libavcodec/vaapi_encode.c | 7 +++
> > >  1 file changed, 3 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > > index 550ea47991d..e371f5761ee 100644
> > > --- a/libavcodec/vaapi_encode.c
> > > +++ b/libavcodec/vaapi_encode.c
> > > @@ -1094,10 +1094,9 @@ static av_cold int
> > > vaapi_encode_config_attributes(AVCodecContext *avctx)
> > >  goto fail;
> > >  }
> > >  if (avctx->max_b_frames > 0 && ref_l1 < 1) {
> > > -av_log(avctx, AV_LOG_ERROR, "B frames are not "
> > > -   "supported (%#x).\n", attr[i].value);
> > > -err = AVERROR(EINVAL);
> > > -goto fail;
> > > +av_log(avctx, AV_LOG_WARNING, "B frames are not "
> > > +   "supported (%#x) by the underlying driver.\n",
> > > attr[i].value);
> > > +avctx->max_b_frames = 0;
> > 
> > I think check b frames when enable low_power in vaapi_encode_xxx_init()
> > more better.
> 
> VAConfigAttribEncMaxRefFrames is applicable for other CODECs and non-low power
> mode. so I think it is better to handle this case in vaapi_encoder.c
> 
> Thanks
> Haihao
> 
> 
> > >  }
> > >  }
> > >  break;
> > 
> > 
> 
> ___
> 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