Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: Check that data is set

2018-01-20 Thread Steven Liu
2018-01-20 23:56 GMT+08:00 Steven Liu :
>
>
>> 在 2018年1月20日,上午10:35,Jeyapal, Karthick  写道:
>>
>>
>>
>>> On 1/20/18 6:29 AM, Brendan McGrath wrote:
>>> If codecpar->extradata is not set (for example, when the stream goes
>>> through the 'tee' muxer), then a segfault occurs.
>>>
>>> This patch ensures the data variable is not null before attempting
>>> to access it
>>>
>>> Signed-off-by: Brendan McGrath 
>>> ---
>>> Before the var_stream_map option was available - I was using the tee
>>> muxer to create each resolution as an individual stream.
>>>
>>> When running this configuration after the most recent hlsenc change
>>> I hit a segfault
>>>
>>> The most simple command which recreates the segfault is:
>>> ffmpeg -i in.ts -map 0:a -map 0:v -c:a aac -c:v h264 \
>>>  -f tee [select=\'a,v\':f=hls]tv_hls_hd.m3u8
>>>
>>> libavformat/hlsenc.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>>> index 8ad906a..42e437f 100644
>>> --- a/libavformat/hlsenc.c
>>> +++ b/libavformat/hlsenc.c
>>> @@ -308,7 +308,7 @@ static void write_codec_attr(AVStream *st, 
>>> VariantStream *vs) {
>>>
>>> if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
>>> uint8_t *data = st->codecpar->extradata;
>>> -if ((data[0] | data[1] | data[2]) == 0 && data[3] == 1 && (data[4] 
>>> & 0x1F) == 7) {
>>> +if (data && (data[0] | data[1] | data[2]) == 0 && data[3] == 1 && 
>>> (data[4] & 0x1F) == 7) {
>>> snprintf(attr, sizeof(attr),
>>>  "avc1.%02x%02x%02x", data[5], data[6], data[7]);
>>> } else {
>>
>> LGTM. Thanks for the fix
>
> will apply
>
>

Pushed

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


Re: [FFmpeg-devel] [PATCH 3/3] libavformat/dashdec: Fix for ticket 6856 (filename limited to 1024)

2018-01-20 Thread Steven Liu
2018-01-17 11:02 GMT+08:00 Colin NG :
> ---
>  libavformat/dashdec.c | 88 
> +--
>  1 file changed, 58 insertions(+), 30 deletions(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 1d520d4..9d5986d 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -147,6 +147,7 @@ typedef struct DASHContext {
>  char *headers;   ///< holds HTTP headers set as an 
> AVOption to the HTTP protocol context
>  char *allowed_extensions;
>  AVDictionary *avio_opts;
> +int max_url_size;
>  } DASHContext;
>
>  static int ishttp(char *url) {
> @@ -154,6 +155,10 @@ static int ishttp(char *url) {
>  return av_strstart(proto_name, "http", NULL);
>  }
>
> +static int aligned(int val) {
> +return ((val + 0x3F) >> 6) << 6;
> +}
> +
>  static uint64_t get_current_time_in_sec(void)
>  {
>  return  av_gettime() / 100;
> @@ -452,6 +457,7 @@ static int open_url(AVFormatContext *s, AVIOContext **pb, 
> const char *url,
>
>  static char *get_content_url(xmlNodePtr *baseurl_nodes,
>   int n_baseurl_nodes,
> + int max_url_size,
>   char *rep_id_val,
>   char *rep_bandwidth_val,
>   char *val)
> @@ -459,43 +465,47 @@ static char *get_content_url(xmlNodePtr *baseurl_nodes,
>  int i;
>  char *text;
>  char *url = NULL;
> -char tmp_str[MAX_URL_SIZE];
> -char tmp_str_2[MAX_URL_SIZE];
> -
> -memset(tmp_str, 0, sizeof(tmp_str));
> +char *tmp_str = av_mallocz(max_url_size);
> +char *tmp_str_2 = av_mallocz(max_url_size);
>
> +if (!tmp_str || !tmp_str_2) {
> +return NULL;
> +}
>  for (i = 0; i < n_baseurl_nodes; ++i) {
>  if (baseurl_nodes[i] &&
>  baseurl_nodes[i]->children &&
>  baseurl_nodes[i]->children->type == XML_TEXT_NODE) {
>  text = xmlNodeGetContent(baseurl_nodes[i]->children);
>  if (text) {
> -memset(tmp_str, 0, sizeof(tmp_str));
> -memset(tmp_str_2, 0, sizeof(tmp_str_2));
> -ff_make_absolute_url(tmp_str_2, MAX_URL_SIZE, tmp_str, text);
> -av_strlcpy(tmp_str, tmp_str_2, sizeof(tmp_str));
> +memset(tmp_str, 0, max_url_size);
> +memset(tmp_str_2, 0, max_url_size);
> +ff_make_absolute_url(tmp_str_2, max_url_size, tmp_str, text);
> +av_strlcpy(tmp_str, tmp_str_2, max_url_size);
>  xmlFree(text);
>  }
>  }
>  }
>
>  if (val)
> -av_strlcat(tmp_str, (const char*)val, sizeof(tmp_str));
> +av_strlcat(tmp_str, (const char*)val, max_url_size);
>
>  if (rep_id_val) {
>  url = av_strireplace(tmp_str, "$RepresentationID$", (const 
> char*)rep_id_val);
>  if (!url) {
> -return NULL;
> +goto end;
>  }
> -av_strlcpy(tmp_str, url, sizeof(tmp_str));
> +av_strlcpy(tmp_str, url, max_url_size);
>  av_free(url);
>  }
>  if (rep_bandwidth_val && tmp_str[0] != '\0') {
>  url = av_strireplace(tmp_str, "$Bandwidth$", (const 
> char*)rep_bandwidth_val);
>  if (!url) {
> -return NULL;
> +goto end;
>  }
>  }
> +end:
> +av_free(tmp_str);
> +av_free(tmp_str_2);
>  return url;
>  }
>
> @@ -580,9 +590,11 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
> *s, struct representati
>   char *rep_id_val,
>   char *rep_bandwidth_val)
>  {
> +DASHContext *c = s->priv_data;
>  char *initialization_val = NULL;
>  char *media_val = NULL;
>  char *range_val = NULL;
> +int max_url_size = c ? c->max_url_size: MAX_URL_SIZE;
>
>  if (!av_strcasecmp(fragmenturl_node->name, (const char 
> *)"Initialization")) {
>  initialization_val = xmlGetProp(fragmenturl_node, "sourceURL");
> @@ -595,6 +607,7 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
> *s, struct representati
>  return AVERROR(ENOMEM);
>  }
>  rep->init_section->url = get_content_url(baseurl_nodes, 4,
> + max_url_size,
>   rep_id_val,
>   rep_bandwidth_val,
>   initialization_val);
> @@ -619,6 +632,7 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
> *s, struct representati
>  return AVERROR(ENOMEM);
>  }
>  seg->url = get_content_url(baseurl_nodes, 4,
> +   max_url_size,
> rep_id_val,
>

Re: [FFmpeg-devel] [PATCHv2] dashdec: Only free url string if being reused

2018-01-20 Thread Liu Steven

> 在 2018年1月20日,上午9:14,Brendan McGrath  写道:
> 
> If no representation bandwidth value is set, the url value returned
> by get_content_url is corrupt (as it has been freed).
> 
> This change ensures the url string is not freed unless it is about
> to be reused
> 
> Signed-off-by: Brendan McGrath 
> ---
> Changes since v1:
> - removed the unneeded 'if' statement (as pointed out by Michael Niedermayer
> - added comment to make it clear why the av_free was required
> 
> libavformat/dashdec.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 2492f1d..6380318 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -482,9 +482,10 @@ static char *get_content_url(xmlNodePtr *baseurl_nodes,
> return NULL;
> }
> av_strlcpy(tmp_str, url, sizeof(tmp_str));
> -av_free(url);
> }
> if (rep_bandwidth_val && tmp_str[0] != '\0') {
> +// free any previously assigned url before reassigning
> +av_free(url);
> url = av_strireplace(tmp_str, "$Bandwidth$", (const 
> char*)rep_bandwidth_val);
> if (!url) {
> return NULL;
> -- 
> 2.7.4
> 

pushed

Thanks
Steven

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


Re: [FFmpeg-devel] [PATCH] dashdec: Make use of frame rate specified in Representation

2018-01-20 Thread Liu Steven

> 在 2018年1月20日,下午11:56,Steven Liu  写道:
> 
> 
> 
>> 在 2018年1月15日,下午11:58,Stefan _  写道:
>> 
>> Hi,
>> 
>> attached patch fixes an annoyance when playing DASH videos from e.g. 
>> YouTube:
>> 
>> "mov,mp4,m4a,3gp,3g2,mj2: Stream #0: not enough frames to estimate rate; 
>> consider increasing probesize"
>> 
>> <0001-dashdec-Make-use-of-frame-rate-specified-in-Represen.patch>
>> ___
> 
> will apply
pushed

Thanks

Steven


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


Re: [FFmpeg-devel] [PATCH] docs/codecs: remove dead codec debug options

2018-01-20 Thread Gyan Doshi

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


[FFmpeg-devel] [PATCH] MAINTAINERS: Adding myself as dashenc maintainer

2018-01-20 Thread Karthick J
From: Karthick Jeyapal 

If somebody else wants to maintain dashenc either now or in future,
I am absolutely fine with giving up this responsibility anytime.
But till then we need a maintainer for dashenc, and I am volunteering for that 
task.
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index e583926..1785851 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -394,6 +394,7 @@ Muxers/Demuxers:
   cdxl.cPaul B Mahol
   crc.c Michael Niedermayer
   dashdec.c Steven Liu
+  dashenc.c Karthick Jeyapal
   daud.cReimar Doeffinger
   dss.c Oleksij Rempel
   dtsdec.c  foo86
-- 
1.9.1

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


Re: [FFmpeg-devel] [PATCH 1/5] avcodec/hevc_ps: add a function to uninitialize parameter set buffers

2018-01-20 Thread James Almer
On 1/20/2018 11:36 PM, Michael Niedermayer wrote:
> On Sat, Jan 20, 2018 at 06:20:53PM -0300, James Almer wrote:
>> On 1/20/2018 6:12 PM, James Almer wrote:
>>> Signed-off-by: James Almer 
>>> ---
>>>  libavcodec/hevc_ps.c | 16 
>>>  libavcodec/hevc_ps.h |  2 ++
>>>  2 files changed, 18 insertions(+)
>>>
>>> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
>>> index a4f7ed60f7..b18457296b 100644
>>> --- a/libavcodec/hevc_ps.c
>>> +++ b/libavcodec/hevc_ps.c
>>> @@ -1704,6 +1704,22 @@ err:
>>>  return ret;
>>>  }
>>>  
>>> +void ff_hevc_uninit_parameter_sets(HEVCParamSets *ps)
>>
>> Might change this to ff_hevc_ps_uninit(), to use the naming scheme of
>> the similar h264 function.
> 
> LGTM either way

Changed and pushed, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/3] avutil: add staticpool

2018-01-20 Thread Muhammad Faiz
On Sat, Jan 20, 2018 at 5:22 PM, wm4  wrote:
> On Sat, 20 Jan 2018 11:29:13 +0700
> Muhammad Faiz  wrote:
>
>> Help avoiding malloc-free cycles when allocating-freeing common
>> structures.
>>
>> Signed-off-by: Muhammad Faiz 
>> ---
>>  libavutil/staticpool.h | 117 
>> +
>>  1 file changed, 117 insertions(+)
>>  create mode 100644 libavutil/staticpool.h
>>
>> diff --git a/libavutil/staticpool.h b/libavutil/staticpool.h
>> new file mode 100644
>> index 00..9c9b2784bc
>> --- /dev/null
>> +++ b/libavutil/staticpool.h
>> @@ -0,0 +1,117 @@
>> +/*
>> + * 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
>> + */
>> +
>> +#ifndef AVUTIL_STATICPOOL_H
>> +#define AVUTIL_STATICPOOL_H
>> +
>> +#include 
>> +#include "avassert.h"
>> +#include "mem.h"
>> +
>> +/**
>> + * FF_STATICPOOL allocate memory without av_malloc if possible
>> + * @param size must be 2^n between 64 and 4096
>> + */
>> +#define FF_STATICPOOL_DECLARE(type, size)   
>> \
>> +typedef struct type##_StaticPoolWrapper {   
>> \
>> +typebuf;
>> \
>> +unsignedindex;  
>> \
>> +atomic_uint next;   
>> \
>> +} type##_StaticPoolWrapper; 
>> \
>> +
>> \
>> +static atomic_uint  type##_staticpool_next; 
>> \
>> +static atomic_uint  type##_staticpool_last; 
>> \
>> +static type##_StaticPoolWrapper type##_staticpool_table[size];  
>> \
>> +
>> \
>> +static type *type##_staticpool_malloc(void) 
>> \
>> +{   
>> \
>> +unsigned val, index, serial, new_val;   
>> \
>> +
>> \
>> +av_assert0((size) >= 64 && (size) <= 4096 && !((size) & ((size) - 1))); 
>> \
>> +
>> \
>> +/* use serial, avoid spinlock */
>> \
>> +/* acquire, so we don't get stalled table[index].next */
>> \
>> +val = atomic_load_explicit(##_staticpool_next, 
>> memory_order_acquire);  \
>> +do {
>> \
>> +index  = val & ((size) - 1);
>> \
>> +serial = val & ~((size) - 1);   
>> \
>> +new_val = 
>> atomic_load_explicit(##_staticpool_table[index].next, 
>> memory_order_relaxed) | (serial + (size)); \
>> +} while 
>> (!atomic_compare_exchange_strong_explicit(##_staticpool_next, , 
>> new_val, \
>> +  memory_order_acquire, 
>> memory_order_acquire)); \
>> +
>> \
>> +index = val & ((size) - 1); 
>> \
>> +if (index)  
>> \
>> +return ##_staticpool_table[index].buf; 
>> \
>> +
>> \
>> +index = atomic_fetch_add_explicit(##_staticpool_last, 1, 
>> memory_order_relaxed) + 1; \
>> +if (index < (size)) {   
>> \
>> +type##_staticpool_table[index].index = index;   
>> \
>> +return ##_staticpool_table[index].buf; 
>> \
>> +}  

Re: [FFmpeg-devel] [PATCH 1/3] avutil: add staticpool

2018-01-20 Thread Muhammad Faiz
On Sat, Jan 20, 2018 at 5:18 PM, wm4  wrote:
> On Sat, 20 Jan 2018 12:52:46 +0700
> Muhammad Faiz  wrote:
>
>> On Sat, Jan 20, 2018 at 11:49 AM, James Almer  wrote:
>> > On 1/20/2018 1:29 AM, Muhammad Faiz wrote:
>> >> Help avoiding malloc-free cycles when allocating-freeing common
>> >> structures.
>> >>
>> >> Signed-off-by: Muhammad Faiz 
>> >> ---
>> >>  libavutil/staticpool.h | 117 
>> >> +
>> >>  1 file changed, 117 insertions(+)
>> >>  create mode 100644 libavutil/staticpool.h
>> >>
>> >> diff --git a/libavutil/staticpool.h b/libavutil/staticpool.h
>> >> new file mode 100644
>> >> index 00..9c9b2784bc
>> >> --- /dev/null
>> >> +++ b/libavutil/staticpool.h
>> >> @@ -0,0 +1,117 @@
>> >> +/*
>> >> + * 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
>> >> + */
>> >> +
>> >> +#ifndef AVUTIL_STATICPOOL_H
>> >> +#define AVUTIL_STATICPOOL_H
>> >> +
>> >> +#include 
>> >> +#include "avassert.h"
>> >> +#include "mem.h"
>> >> +
>> >> +/**
>> >> + * FF_STATICPOOL allocate memory without av_malloc if possible
>> >> + * @param size must be 2^n between 64 and 4096
>> >> + */
>> >> +#define FF_STATICPOOL_DECLARE(type, size)
>> >>\
>> >> +typedef struct type##_StaticPoolWrapper {
>> >>\
>> >> +typebuf; 
>> >>\
>> >> +unsignedindex;   
>> >>\
>> >> +atomic_uint next;
>> >>\
>> >> +} type##_StaticPoolWrapper;  
>> >>\
>> >> + 
>> >>\
>> >> +static atomic_uint  type##_staticpool_next;  
>> >>\
>> >> +static atomic_uint  type##_staticpool_last;  
>> >>\
>> >> +static type##_StaticPoolWrapper type##_staticpool_table[size];   
>> >>\
>> >> + 
>> >>\
>> >> +static type *type##_staticpool_malloc(void)  
>> >>\
>> >> +{
>> >>\
>> >> +unsigned val, index, serial, new_val;
>> >>\
>> >> + 
>> >>\
>> >> +av_assert0((size) >= 64 && (size) <= 4096 && !((size) & ((size) - 
>> >> 1))); \
>> >> + 
>> >>\
>> >> +/* use serial, avoid spinlock */ 
>> >>\
>> >> +/* acquire, so we don't get stalled table[index].next */ 
>> >>\
>> >> +val = atomic_load_explicit(##_staticpool_next, 
>> >> memory_order_acquire);  \
>> >> +do { 
>> >>\
>> >> +index  = val & ((size) - 1); 
>> >>\
>> >> +serial = val & ~((size) - 1);
>> >>\
>> >> +new_val = 
>> >> atomic_load_explicit(##_staticpool_table[index].next, 
>> >> memory_order_relaxed) | (serial + (size)); \
>> >> +} while 
>> >> (!atomic_compare_exchange_strong_explicit(##_staticpool_next, , 
>> >> new_val, \
>> >
>> > The wrappers for atomic_compare_exchange_* in the compat folder are not
>> > really working and fixing them is supposedly not trivial, so this will
>> > only work with GCC and Clang but not with for example MSVC or SunCC.
>>
>> What's the problem? I only see that stdatomic compat make typedef
>> every atomic type to intptr_t, so atomic_*64_t won't work if
>> sizeof(intptr_t) == 32.
>> Here I use atomic_uint, so I guess it will work.
>>
>> Note that if atomic_compare_exchange_* is broken then atomic_fetch_*

Re: [FFmpeg-devel] [PATCH]lavf/rawdec: Probe last byte for mjpeg

2018-01-20 Thread Carl Eugen Hoyos
2018-01-21 3:39 GMT+01:00 Michael Niedermayer :
> On Sat, Jan 20, 2018 at 04:11:00PM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch fixes ticket #6957 for me, I believe
>> there was an off-by-one issue in the original function.
>>
>> Please comment, Carl Eugen
>
>>  rawdec.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 0d791c60f3d38346afea65714fee08c7fb2c16b0  
>> 0001-lavf-rawdec-Also-probe-the-last-byte-of-mjpeg-stream.patch
>> From 0711e0474f9a83ec47a31b8cf261cf2e6a10a35e Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Sat, 20 Jan 2018 16:07:25 +0100
>> Subject: [PATCH] lavf/rawdec: Also probe the last byte of mjpeg streams.
>
> LGTM

Patch applied.

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


Re: [FFmpeg-devel] [PATCH] avcodec/h264_ps: use the AVBufferPool API to allocate parameter set buffers

2018-01-20 Thread James Almer
On 1/20/2018 11:33 PM, Michael Niedermayer wrote:
> On Sat, Jan 20, 2018 at 06:49:29PM -0300, James Almer wrote:
>> Signed-off-by: James Almer 
>> ---
>> Similar rationale as hevc. With up to 32 sps and 256 pps, this may
>> come in handy when parsing raw streams.
>>
>>  libavcodec/h264_parser.c   |  3 ++-
>>  libavcodec/h264_ps.c   | 22 --
>>  libavcodec/h264_ps.h   |  5 +
>>  libavcodec/h264dec.c   |  3 +++
>>  libavcodec/mediacodecdec.c |  4 
>>  5 files changed, 34 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
>> index 65d9d44b50..fa6777fc05 100644
>> --- a/libavcodec/h264_parser.c
>> +++ b/libavcodec/h264_parser.c
>> @@ -697,7 +697,8 @@ static av_cold int init(AVCodecParserContext *s)
>>  p->reference_dts = AV_NOPTS_VALUE;
>>  p->last_frame_num = INT_MAX;
>>  ff_h264dsp_init(>h264dsp, 8, 1);
>> -return 0;
>> +
>> +return ff_h264_ps_init(>ps);
>>  }
>>  
>>  AVCodecParser ff_h264_parser = {
>> diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
>> index 8d1ef831fa..50dbabdb8b 100644
>> --- a/libavcodec/h264_ps.c
>> +++ b/libavcodec/h264_ps.c
>> @@ -314,6 +314,21 @@ static int decode_scaling_matrices(GetBitContext *gb, 
>> const SPS *sps,
>>  return ret;
>>  }
>>  
>> +int ff_h264_ps_init(H264ParamSets *ps)
>> +{
>> +ps->sps_pool = av_buffer_pool_init(sizeof(*ps->sps), av_buffer_allocz);
>> +ps->pps_pool = av_buffer_pool_init(sizeof(*ps->pps), av_buffer_allocz);
>> +
>> +if (!ps->sps_pool || !ps->pps_pool) {
>> +av_buffer_pool_uninit(>sps_pool);
>> +av_buffer_pool_uninit(>pps_pool);
>> +
>> +return AVERROR(ENOMEM);
>> +}
>> +
>> +return 0;
>> +}
>> +
>>  void ff_h264_ps_uninit(H264ParamSets *ps)
>>  {
>>  int i;
>> @@ -327,6 +342,9 @@ void ff_h264_ps_uninit(H264ParamSets *ps)
>>  av_buffer_unref(>sps_ref);
>>  av_buffer_unref(>pps_ref);
>>  
>> +av_buffer_pool_uninit(>sps_pool);
>> +av_buffer_pool_uninit(>pps_pool);
>> +
>>  ps->pps = NULL;
>>  ps->sps = NULL;
>>  }
>> @@ -341,7 +359,7 @@ int ff_h264_decode_seq_parameter_set(GetBitContext *gb, 
>> AVCodecContext *avctx,
>>  SPS *sps;
>>  int ret;
>>  
>> -sps_buf = av_buffer_allocz(sizeof(*sps));
>> +sps_buf = av_buffer_pool_get(ps->sps_pool);
>>  if (!sps_buf)
>>  return AVERROR(ENOMEM);
>>  sps = (SPS*)sps_buf->data;
>> @@ -738,7 +756,7 @@ int ff_h264_decode_picture_parameter_set(GetBitContext 
>> *gb, AVCodecContext *avct
>>  return AVERROR_INVALIDDATA;
>>  }
>>  
>> -pps_buf = av_buffer_allocz(sizeof(*pps));
>> +pps_buf = av_buffer_pool_get(ps->pps_pool);
> 
> this seems to remove the memset(0) unless iam missing something

Isn't it enough using av_buffer_allocz() as the alloc function when
initializing the pool?
If the buffers are not cleared when returned to the pool to be reused
then I could change the alloc function to av_buffer_alloc() and call
memset(0) here.

> is this intended?

Not really. My intention is to still get a zeroed buffer as it always did.

> has someone checked this to be safe ?
> 
> 
> [...]
>> --- a/libavcodec/h264dec.c
>> +++ b/libavcodec/h264dec.c
>> @@ -326,6 +326,9 @@ static int h264_init_context(AVCodecContext *avctx, 
>> H264Context *h)
>>  
>>  ff_h264_sei_uninit(>sei);
>>  
>> +if (ff_h264_ps_init(>ps) < 0)
>> +return AVERROR(ENOMEM);
> 
> This probably should forward the returned error code

Changed locally.

> 
> also a memcmp on the data might be worth looking into to avoid re-parsing of
> unchanged PS
> (theres already a memcmp in libavcodec/h264_ps.c)
> 
> [...]
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

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


Re: [FFmpeg-devel] [PATCH]lavf/rawdec: Probe last byte for mjpeg

2018-01-20 Thread Michael Niedermayer
On Sat, Jan 20, 2018 at 04:11:00PM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch fixes ticket #6957 for me, I believe
> there was an off-by-one issue in the original function.
> 
> Please comment, Carl Eugen

>  rawdec.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 0d791c60f3d38346afea65714fee08c7fb2c16b0  
> 0001-lavf-rawdec-Also-probe-the-last-byte-of-mjpeg-stream.patch
> From 0711e0474f9a83ec47a31b8cf261cf2e6a10a35e Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sat, 20 Jan 2018 16:07:25 +0100
> Subject: [PATCH] lavf/rawdec: Also probe the last byte of mjpeg streams.

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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/5] avcodec/hevc_ps: add a function to uninitialize parameter set buffers

2018-01-20 Thread Michael Niedermayer
On Sat, Jan 20, 2018 at 06:20:53PM -0300, James Almer wrote:
> On 1/20/2018 6:12 PM, James Almer wrote:
> > Signed-off-by: James Almer 
> > ---
> >  libavcodec/hevc_ps.c | 16 
> >  libavcodec/hevc_ps.h |  2 ++
> >  2 files changed, 18 insertions(+)
> > 
> > diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> > index a4f7ed60f7..b18457296b 100644
> > --- a/libavcodec/hevc_ps.c
> > +++ b/libavcodec/hevc_ps.c
> > @@ -1704,6 +1704,22 @@ err:
> >  return ret;
> >  }
> >  
> > +void ff_hevc_uninit_parameter_sets(HEVCParamSets *ps)
> 
> Might change this to ff_hevc_ps_uninit(), to use the naming scheme of
> the similar h264 function.

LGTM either way

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

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


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


Re: [FFmpeg-devel] [PATCH 2/5] avcodec/hevcdec: use ff_hevc_uninit_parameter_sets()

2018-01-20 Thread Michael Niedermayer
On Sat, Jan 20, 2018 at 06:12:50PM -0300, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  libavcodec/hevcdec.c | 10 +-
>  1 file changed, 1 insertion(+), 9 deletions(-)

LGTM

thx

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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


Re: [FFmpeg-devel] [PATCH 3/5] avcodec/hevc_parser: use ff_hevc_uninit_parameter_sets()

2018-01-20 Thread Michael Niedermayer
On Sat, Jan 20, 2018 at 06:12:51PM -0300, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  libavcodec/hevc_parser.c | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)

LGTM

thx

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

Democracy is the form of government in which you can choose your dictator


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


Re: [FFmpeg-devel] [PATCH] avcodec/h264_ps: use the AVBufferPool API to allocate parameter set buffers

2018-01-20 Thread Michael Niedermayer
On Sat, Jan 20, 2018 at 06:49:29PM -0300, James Almer wrote:
> Signed-off-by: James Almer 
> ---
> Similar rationale as hevc. With up to 32 sps and 256 pps, this may
> come in handy when parsing raw streams.
> 
>  libavcodec/h264_parser.c   |  3 ++-
>  libavcodec/h264_ps.c   | 22 --
>  libavcodec/h264_ps.h   |  5 +
>  libavcodec/h264dec.c   |  3 +++
>  libavcodec/mediacodecdec.c |  4 
>  5 files changed, 34 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
> index 65d9d44b50..fa6777fc05 100644
> --- a/libavcodec/h264_parser.c
> +++ b/libavcodec/h264_parser.c
> @@ -697,7 +697,8 @@ static av_cold int init(AVCodecParserContext *s)
>  p->reference_dts = AV_NOPTS_VALUE;
>  p->last_frame_num = INT_MAX;
>  ff_h264dsp_init(>h264dsp, 8, 1);
> -return 0;
> +
> +return ff_h264_ps_init(>ps);
>  }
>  
>  AVCodecParser ff_h264_parser = {
> diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
> index 8d1ef831fa..50dbabdb8b 100644
> --- a/libavcodec/h264_ps.c
> +++ b/libavcodec/h264_ps.c
> @@ -314,6 +314,21 @@ static int decode_scaling_matrices(GetBitContext *gb, 
> const SPS *sps,
>  return ret;
>  }
>  
> +int ff_h264_ps_init(H264ParamSets *ps)
> +{
> +ps->sps_pool = av_buffer_pool_init(sizeof(*ps->sps), av_buffer_allocz);
> +ps->pps_pool = av_buffer_pool_init(sizeof(*ps->pps), av_buffer_allocz);
> +
> +if (!ps->sps_pool || !ps->pps_pool) {
> +av_buffer_pool_uninit(>sps_pool);
> +av_buffer_pool_uninit(>pps_pool);
> +
> +return AVERROR(ENOMEM);
> +}
> +
> +return 0;
> +}
> +
>  void ff_h264_ps_uninit(H264ParamSets *ps)
>  {
>  int i;
> @@ -327,6 +342,9 @@ void ff_h264_ps_uninit(H264ParamSets *ps)
>  av_buffer_unref(>sps_ref);
>  av_buffer_unref(>pps_ref);
>  
> +av_buffer_pool_uninit(>sps_pool);
> +av_buffer_pool_uninit(>pps_pool);
> +
>  ps->pps = NULL;
>  ps->sps = NULL;
>  }
> @@ -341,7 +359,7 @@ int ff_h264_decode_seq_parameter_set(GetBitContext *gb, 
> AVCodecContext *avctx,
>  SPS *sps;
>  int ret;
>  
> -sps_buf = av_buffer_allocz(sizeof(*sps));
> +sps_buf = av_buffer_pool_get(ps->sps_pool);
>  if (!sps_buf)
>  return AVERROR(ENOMEM);
>  sps = (SPS*)sps_buf->data;
> @@ -738,7 +756,7 @@ int ff_h264_decode_picture_parameter_set(GetBitContext 
> *gb, AVCodecContext *avct
>  return AVERROR_INVALIDDATA;
>  }
>  
> -pps_buf = av_buffer_allocz(sizeof(*pps));
> +pps_buf = av_buffer_pool_get(ps->pps_pool);

this seems to remove the memset(0) unless iam missing something
is this intended?
has someone checked this to be safe ?


[...]
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -326,6 +326,9 @@ static int h264_init_context(AVCodecContext *avctx, 
> H264Context *h)
>  
>  ff_h264_sei_uninit(>sei);
>  
> +if (ff_h264_ps_init(>ps) < 0)
> +return AVERROR(ENOMEM);

This probably should forward the returned error code

also a memcmp on the data might be worth looking into to avoid re-parsing of
unchanged PS
(theres already a memcmp in libavcodec/h264_ps.c)

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

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


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


Re: [FFmpeg-devel] [PATCH] ffmpeg: Ignore SIGPIPE

2018-01-20 Thread Mark Thompson
On 18/01/18 23:42, Mark Thompson wrote:
> On systems which deliver SIGPIPE (Unices), a broken pipe will currently
> result in the immediate termination of the ffmpeg process (the default
> disposition as required by POSIX).  This is undesirable, because while
> the broken pipe is likely fatal to useful cleanup of whatever component
> is writing to it, there might be other components which can do useful
> cleanup - for example, a muxer on another stream may still need to write
> indexes to complete a file.  Therefore, set the signal disposition for
> SIGPIPE to ignore the signal - the call which caused the signal will
> fail with EPIPE and the error will be propagated upwards like any other
> I/O failure on a single stream.
> ---
>  fftools/ffmpeg.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 528849a2c6..918eb353aa 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -406,6 +406,9 @@ void term_init(void)
>  #ifdef SIGXCPU
>  signal(SIGXCPU, sigterm_handler);
>  #endif
> +#ifdef SIGPIPE
> +signal(SIGPIPE, SIG_IGN); /* Broken pipe (POSIX). */
> +#endif
>  #if HAVE_SETCONSOLECTRLHANDLER
>  SetConsoleCtrlHandler((PHANDLER_ROUTINE) CtrlHandler, TRUE);
>  #endif
> 

I'll apply this tomorrow if there are no further comments.

Thanks,

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


[FFmpeg-devel] [PATCH] v4l2_m2m: Fix integer overflow in timestamp handling

2018-01-20 Thread Mark Thompson
---
struct timeval elements are not big enough in a 32-bit ABI.


 libavcodec/v4l2_buffers.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index 8e4d4d1..aef911f 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -69,7 +69,8 @@ static inline uint64_t v4l2_get_pts(V4L2Buffer *avbuf)
 int64_t v4l2_pts;
 
 /* convert pts back to encoder timebase */
-v4l2_pts = avbuf->buf.timestamp.tv_sec * USEC_PER_SEC + 
avbuf->buf.timestamp.tv_usec;
+v4l2_pts = (int64_t)avbuf->buf.timestamp.tv_sec * USEC_PER_SEC +
+avbuf->buf.timestamp.tv_usec;
 
 return av_rescale_q(v4l2_pts, v4l2_timebase, s->avctx->time_base);
 }
-- 
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v1 1/3] avcodec: v4l2_m2m: fix races around freeing data on close

2018-01-20 Thread Mark Thompson
On 09/01/18 22:56, Jorge Ramirez-Ortiz wrote:
> From: Mark Thompson 
> 
> Refcount all of the context information. This also fixes a potential
> segmentation fault when accessing freed memory  (buffer returned after
> the codec has been closed).
> 
> Tested-by: Jorge Ramirez-Ortiz 
> ---
>  libavcodec/v4l2_buffers.c | 32 ++--
>  libavcodec/v4l2_buffers.h |  6 +++
>  libavcodec/v4l2_m2m.c | 93 
> +--
>  libavcodec/v4l2_m2m.h | 35 ++
>  libavcodec/v4l2_m2m_dec.c | 22 +++
>  libavcodec/v4l2_m2m_enc.c | 22 +++
>  6 files changed, 140 insertions(+), 70 deletions(-)

I've done some more testing of this set on s5p-mfc.  I still don't like the 
residual use of atomics in what I wrote, but it is overall a bit better than 
before so I've applied the whole set.

Other stuff:
* There's a timestamp overflow case, patch follows.
* Reinitialisation still fails in some cases - decoding 
fate/h264/reinit-large_420_8-to-small_420_8.h264 currently hangs.  That needs 
more investigation, which I haven't done.
* valgrind still shows leaks when h264_mp4toannexb feeds the decoder, but the 
bsf doesn't show it in isolation.  Buffer references leaking in the decoder 
somehow?

Thanks,

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


Re: [FFmpeg-devel] [PATCH] avfilter/drawtext - implement fix_bounds

2018-01-20 Thread Kyle Swanson
Hi,

On Fri, Jan 19, 2018 at 5:03 PM, Michael Niedermayer
 wrote:
> On Fri, Jan 19, 2018 at 03:46:57PM -0800, Kyle Swanson wrote:
>> Hi,
>>
>> >
>> > Ping. Unless text needs to be rescaled as well, this patch is ready for 
>> > review.
>> >
>> >
>> > Regards,
>> > Gyan
>> > ___
>> > ffmpeg-devel mailing list
>> > ffmpeg-devel@ffmpeg.org
>> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>>
>> LGTM as-is. I'll push this sometime in the next 24 hours unless
>> someone else has anything to add.
>
> nothing to add, just wanted to test & push myself but as i saw your mail
> and my todo is long i gladly leave that to you :)
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I know you won't believe me, but the highest form of Human Excellence is
> to question oneself and others. -- Socrates
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Pushed. Thanks.

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


[FFmpeg-devel] [PATCH]lavc/aarch64/h264_init_aarch64: Fix weight function prototypes

2018-01-20 Thread Carl Eugen Hoyos
Hi!

Attached patch fixes a warning when compiling for aarch64, fate passes.

Please comment, Carl Eugen
From a7f0de38974a6a3a651b6f3e0d46180c67a154c1 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 21 Jan 2018 00:17:19 +0100
Subject: [PATCH] lavc/aarch64/h264dsp_init_aarch64: Fix weight function
 prototypes.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Fixes the following warnings:
libavcodec/aarch64/h264dsp_init_aarch64.c: In function ‘ff_h264dsp_init_aarch64’:
libavcodec/aarch64/h264dsp_init_aarch64.c:84:38: warning: assignment from incompatible pointer type [enabled by default]
 c->weight_h264_pixels_tab[0] = ff_weight_h264_pixels_16_neon;
  ^
libavcodec/aarch64/h264dsp_init_aarch64.c:85:38: warning: assignment from incompatible pointer type [enabled by default]
 c->weight_h264_pixels_tab[1] = ff_weight_h264_pixels_8_neon;
  ^
libavcodec/aarch64/h264dsp_init_aarch64.c:86:38: warning: assignment from incompatible pointer type [enabled by default]
 c->weight_h264_pixels_tab[2] = ff_weight_h264_pixels_4_neon;
  ^
libavcodec/aarch64/h264dsp_init_aarch64.c:88:40: warning: assignment from incompatible pointer type [enabled by default]
 c->biweight_h264_pixels_tab[0] = ff_biweight_h264_pixels_16_neon;
^
libavcodec/aarch64/h264dsp_init_aarch64.c:89:40: warning: assignment from incompatible pointer type [enabled by default]
 c->biweight_h264_pixels_tab[1] = ff_biweight_h264_pixels_8_neon;
^
libavcodec/aarch64/h264dsp_init_aarch64.c:90:40: warning: assignment from incompatible pointer type [enabled by default]
 c->biweight_h264_pixels_tab[2] = ff_biweight_h264_pixels_4_neon;
^
---
 libavcodec/aarch64/h264dsp_init_aarch64.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavcodec/aarch64/h264dsp_init_aarch64.c b/libavcodec/aarch64/h264dsp_init_aarch64.c
index e0f378f..eb2014e 100644
--- a/libavcodec/aarch64/h264dsp_init_aarch64.c
+++ b/libavcodec/aarch64/h264dsp_init_aarch64.c
@@ -34,20 +34,20 @@ void ff_h264_v_loop_filter_chroma_neon(uint8_t *pix, int stride, int alpha,
 void ff_h264_h_loop_filter_chroma_neon(uint8_t *pix, int stride, int alpha,
int beta, int8_t *tc0);
 
-void ff_weight_h264_pixels_16_neon(uint8_t *dst, int stride, int height,
+void ff_weight_h264_pixels_16_neon(uint8_t *dst, ptrdiff_t stride, int height,
int log2_den, int weight, int offset);
-void ff_weight_h264_pixels_8_neon(uint8_t *dst, int stride, int height,
+void ff_weight_h264_pixels_8_neon(uint8_t *dst, ptrdiff_t stride, int height,
   int log2_den, int weight, int offset);
-void ff_weight_h264_pixels_4_neon(uint8_t *dst, int stride, int height,
+void ff_weight_h264_pixels_4_neon(uint8_t *dst, ptrdiff_t stride, int height,
   int log2_den, int weight, int offset);
 
-void ff_biweight_h264_pixels_16_neon(uint8_t *dst, uint8_t *src, int stride,
+void ff_biweight_h264_pixels_16_neon(uint8_t *dst, uint8_t *src, ptrdiff_t stride,
  int height, int log2_den, int weightd,
  int weights, int offset);
-void ff_biweight_h264_pixels_8_neon(uint8_t *dst, uint8_t *src, int stride,
+void ff_biweight_h264_pixels_8_neon(uint8_t *dst, uint8_t *src, ptrdiff_t stride,
 int height, int log2_den, int weightd,
 int weights, int offset);
-void ff_biweight_h264_pixels_4_neon(uint8_t *dst, uint8_t *src, int stride,
+void ff_biweight_h264_pixels_4_neon(uint8_t *dst, uint8_t *src, ptrdiff_t stride,
 int height, int log2_den, int weightd,
 int weights, int offset);
 
-- 
1.7.10.4

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


Re: [FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec

2018-01-20 Thread Rostislav Pehlivanov
On 20 January 2018 at 17:26, Aurelien Jacobs  wrote:

> On Sun, Jan 14, 2018 at 10:54:34PM +0100, Carl Eugen Hoyos wrote:
> > 2018-01-14 14:06 GMT+01:00 Aurelien Jacobs :
> >
> > > Well, here is an updated patch which uses codec tags for the decoder
> and
> > > profile for the encoder.
> >
> > Sorry but I object to this patch:
> > We should not invent codec_tags.
>
> OK, I understand, and I agree.
>
> But now we are in an interlocking situation.
> We have 2 solutions to handle aptX vs. aptX HD but those 2 solutions have
> been rejected by 2 different person.
>
> Do anybody have a 3rd solution, that everyone would accept ?
>
> And if not, how do we resolve this ?
> Is there any policy nowadays to handle this kind of interlocking ?
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Fine, I see no choice but to use multiple codec IDs for aptxhd since the
format really provides you with nothing bitstream wise to determine what it
is. Even game codecs have a bit or two for version.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] cuvid : add support to force intra frames as in input source

2018-01-20 Thread Timo Rothenpieler

Shouldn't we generally recommend people use the new NVDEC
implementation instead? It already has all these features and more. :)


There are still features missing from nvdec which will take a while to 
implement, if it's possible at all. Like deinterlacing/cropping.


Also, cuviddec is still notably faster than nvdec in sw frame output mode.



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] cuvid : add support to force intra frames as in input source

2018-01-20 Thread Hendrik Leppkes
On Fri, Jan 19, 2018 at 11:33 PM, Timo Rothenpieler
 wrote:
> Am 19.01.2018 um 19:47 schrieb Michael Niedermayer:
>>
>> On Fri, Jan 19, 2018 at 11:09:51AM +0100, Timo Rothenpieler wrote:
>>>
>>> Am 18.01.2018 um 07:52 schrieb Yogender Gupta:

 Improved the patch by dynamic allocation.

 Thanks,
 Yogender

>>>
 @@ -1072,6 +1083,8 @@ static void cuvid_flush(AVCodecContext *avctx)
   if (ret < 0)
   goto error;

>>
 +av_free(ctx->key_frame);
>>
>>
>> this should probably be av_freep()
>> unless the place where it resides is before some code
>> unconditionally overwriting it afterwards
>
>
> Yeah, it should. Changed and applied.
>
>

Shouldn't we generally recommend people use the new NVDEC
implementation instead? It already has all these features and more. :)

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


Re: [FFmpeg-devel] [PATCH 4/5] avcodec/mediacodecdec: use ff_hevc_uninit_parameter_sets()

2018-01-20 Thread James Almer
On 1/20/2018 8:00 PM, wm4 wrote:
> On Sat, 20 Jan 2018 18:12:52 -0300
> James Almer  wrote:
> 
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/mediacodecdec.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
>> index 6c5d3ddd79..b360e7a7f1 100644
>> --- a/libavcodec/mediacodecdec.c
>> +++ b/libavcodec/mediacodecdec.c
>> @@ -258,6 +258,8 @@ static int hevc_set_extradata(AVCodecContext *avctx, 
>> FFAMediaFormat *format)
>>  }
>>  
>>  done:
>> +ff_hevc_uninit_parameter_sets();
>> +
>>  av_freep(_data);
>>  av_freep(_data);
>>  av_freep(_data);
> 
> Did this leak before? Or is it only needed to make it work with
> patch 5/5?

It most likely leaked before. Notice how hevc parser and decoder both
free the buffers, and even mediacodecdec here does it with h264.

I can't test this module in any case, so someone else will have to
confirm this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 4/5] avcodec/mediacodecdec: use ff_hevc_uninit_parameter_sets()

2018-01-20 Thread wm4
On Sat, 20 Jan 2018 18:12:52 -0300
James Almer  wrote:

> Signed-off-by: James Almer 
> ---
>  libavcodec/mediacodecdec.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> index 6c5d3ddd79..b360e7a7f1 100644
> --- a/libavcodec/mediacodecdec.c
> +++ b/libavcodec/mediacodecdec.c
> @@ -258,6 +258,8 @@ static int hevc_set_extradata(AVCodecContext *avctx, 
> FFAMediaFormat *format)
>  }
>  
>  done:
> +ff_hevc_uninit_parameter_sets();
> +
>  av_freep(_data);
>  av_freep(_data);
>  av_freep(_data);

Did this leak before? Or is it only needed to make it work with
patch 5/5?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 3/3] lavu/timer.h: add Linux Perf API support

2018-01-20 Thread Carl Eugen Hoyos
2017-09-02 20:17 GMT+02:00 Clément Bœsch :
> From: Clément Bœsch 
>
> Refer to "checkasm: use perf API on Linux ARM*" commit for the
> rationale.
>
> The implementation is somehow duplicated with checkasm, but so is the
> current usage of AV_READ_TIME(). Until these implementations and
> heuristics are made consistent, I don't see a way of sharing that code.
>
> Note: when using libavutil/timer.h, it is now important to include
> before any other include due to the _GNU_SOURCE requirement.
> ---
>  libavutil/timer.h | 46 +++---
>  1 file changed, 43 insertions(+), 3 deletions(-)
>
> diff --git a/libavutil/timer.h b/libavutil/timer.h
> index da0761b607..f7ab455df2 100644
> --- a/libavutil/timer.h
> +++ b/libavutil/timer.h
> @@ -26,12 +26,22 @@
>  #ifndef AVUTIL_TIMER_H
>  #define AVUTIL_TIMER_H
>
> +#include "config.h"
> +
> +#if CONFIG_LINUX_PERF
> +# ifndef _GNU_SOURCE
> +#  define _GNU_SOURCE
> +# endif
> +# include  // read(3)
> +# include 
> +# include 
> +# include 

Not sure how relevant this is but this
patch broke compilation for Android 19
and earlier, still supported by ndk 16b.

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


[FFmpeg-devel] [PATCH] avcodec/h264_ps: use the AVBufferPool API to allocate parameter set buffers

2018-01-20 Thread James Almer
Signed-off-by: James Almer 
---
Similar rationale as hevc. With up to 32 sps and 256 pps, this may
come in handy when parsing raw streams.

 libavcodec/h264_parser.c   |  3 ++-
 libavcodec/h264_ps.c   | 22 --
 libavcodec/h264_ps.h   |  5 +
 libavcodec/h264dec.c   |  3 +++
 libavcodec/mediacodecdec.c |  4 
 5 files changed, 34 insertions(+), 3 deletions(-)

diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index 65d9d44b50..fa6777fc05 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -697,7 +697,8 @@ static av_cold int init(AVCodecParserContext *s)
 p->reference_dts = AV_NOPTS_VALUE;
 p->last_frame_num = INT_MAX;
 ff_h264dsp_init(>h264dsp, 8, 1);
-return 0;
+
+return ff_h264_ps_init(>ps);
 }
 
 AVCodecParser ff_h264_parser = {
diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 8d1ef831fa..50dbabdb8b 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -314,6 +314,21 @@ static int decode_scaling_matrices(GetBitContext *gb, 
const SPS *sps,
 return ret;
 }
 
+int ff_h264_ps_init(H264ParamSets *ps)
+{
+ps->sps_pool = av_buffer_pool_init(sizeof(*ps->sps), av_buffer_allocz);
+ps->pps_pool = av_buffer_pool_init(sizeof(*ps->pps), av_buffer_allocz);
+
+if (!ps->sps_pool || !ps->pps_pool) {
+av_buffer_pool_uninit(>sps_pool);
+av_buffer_pool_uninit(>pps_pool);
+
+return AVERROR(ENOMEM);
+}
+
+return 0;
+}
+
 void ff_h264_ps_uninit(H264ParamSets *ps)
 {
 int i;
@@ -327,6 +342,9 @@ void ff_h264_ps_uninit(H264ParamSets *ps)
 av_buffer_unref(>sps_ref);
 av_buffer_unref(>pps_ref);
 
+av_buffer_pool_uninit(>sps_pool);
+av_buffer_pool_uninit(>pps_pool);
+
 ps->pps = NULL;
 ps->sps = NULL;
 }
@@ -341,7 +359,7 @@ int ff_h264_decode_seq_parameter_set(GetBitContext *gb, 
AVCodecContext *avctx,
 SPS *sps;
 int ret;
 
-sps_buf = av_buffer_allocz(sizeof(*sps));
+sps_buf = av_buffer_pool_get(ps->sps_pool);
 if (!sps_buf)
 return AVERROR(ENOMEM);
 sps = (SPS*)sps_buf->data;
@@ -738,7 +756,7 @@ int ff_h264_decode_picture_parameter_set(GetBitContext *gb, 
AVCodecContext *avct
 return AVERROR_INVALIDDATA;
 }
 
-pps_buf = av_buffer_allocz(sizeof(*pps));
+pps_buf = av_buffer_pool_get(ps->pps_pool);
 if (!pps_buf)
 return AVERROR(ENOMEM);
 pps = (PPS*)pps_buf->data;
diff --git a/libavcodec/h264_ps.h b/libavcodec/h264_ps.h
index 51b6694b5f..65730153e7 100644
--- a/libavcodec/h264_ps.h
+++ b/libavcodec/h264_ps.h
@@ -135,6 +135,9 @@ typedef struct PPS {
 } PPS;
 
 typedef struct H264ParamSets {
+AVBufferPool *sps_pool;
+AVBufferPool *pps_pool;
+
 AVBufferRef *sps_list[MAX_SPS_COUNT];
 AVBufferRef *pps_list[MAX_PPS_COUNT];
 
@@ -162,4 +165,6 @@ int ff_h264_decode_picture_parameter_set(GetBitContext *gb, 
AVCodecContext *avct
  */
 void ff_h264_ps_uninit(H264ParamSets *ps);
 
+int ff_h264_ps_init(H264ParamSets *ps);
+
 #endif /* AVCODEC_H264_PS_H */
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 8c9c6d9f3b..ef79387326 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -326,6 +326,9 @@ static int h264_init_context(AVCodecContext *avctx, 
H264Context *h)
 
 ff_h264_sei_uninit(>sei);
 
+if (ff_h264_ps_init(>ps) < 0)
+return AVERROR(ENOMEM);
+
 avctx->chroma_sample_location = AVCHROMA_LOC_LEFT;
 
 h->nb_slice_ctx = (avctx->active_thread_type & FF_THREAD_SLICE) ? 
avctx->thread_count : 1;
diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 6c5d3ddd79..f623147741 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -131,6 +131,10 @@ static int h264_set_extradata(AVCodecContext *avctx, 
FFAMediaFormat *format)
 
 memset(, 0, sizeof(ps));
 
+ret = ff_h264_ps_init();
+if (ret < 0)
+goto done;
+
 ret = ff_h264_decode_extradata(avctx->extradata, avctx->extradata_size,
, _avc, _length_size, 0, avctx);
 if (ret < 0) {
-- 
2.15.0

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


Re: [FFmpeg-devel] [PATCH 1/5] avcodec/hevc_ps: add a function to uninitialize parameter set buffers

2018-01-20 Thread James Almer
On 1/20/2018 6:12 PM, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  libavcodec/hevc_ps.c | 16 
>  libavcodec/hevc_ps.h |  2 ++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> index a4f7ed60f7..b18457296b 100644
> --- a/libavcodec/hevc_ps.c
> +++ b/libavcodec/hevc_ps.c
> @@ -1704,6 +1704,22 @@ err:
>  return ret;
>  }
>  
> +void ff_hevc_uninit_parameter_sets(HEVCParamSets *ps)

Might change this to ff_hevc_ps_uninit(), to use the naming scheme of
the similar h264 function.

> +{
> +int i;
> +
> +for (i = 0; i < FF_ARRAY_ELEMS(ps->vps_list); i++)
> +av_buffer_unref(>vps_list[i]);
> +for (i = 0; i < FF_ARRAY_ELEMS(ps->sps_list); i++)
> +av_buffer_unref(>sps_list[i]);
> +for (i = 0; i < FF_ARRAY_ELEMS(ps->pps_list); i++)
> +av_buffer_unref(>pps_list[i]);
> +
> +ps->sps = NULL;
> +ps->pps = NULL;
> +ps->vps = NULL;
> +}
> +
>  int ff_hevc_compute_poc(const HEVCSPS *sps, int pocTid0, int poc_lsb, int 
> nal_unit_type)
>  {
>  int max_poc_lsb  = 1 << sps->log2_max_poc_lsb;
> diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
> index 477ee4299a..871a58acc6 100644
> --- a/libavcodec/hevc_ps.h
> +++ b/libavcodec/hevc_ps.h
> @@ -421,6 +421,8 @@ int ff_hevc_decode_nal_sps(GetBitContext *gb, 
> AVCodecContext *avctx,
>  int ff_hevc_decode_nal_pps(GetBitContext *gb, AVCodecContext *avctx,
> HEVCParamSets *ps);
>  
> +void ff_hevc_uninit_parameter_sets(HEVCParamSets *ps);
> +
>  int ff_hevc_decode_short_term_rps(GetBitContext *gb, AVCodecContext *avctx,
>ShortTermRPS *rps, const HEVCSPS *sps, int 
> is_slice_header);
>  
> 

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


[FFmpeg-devel] [PATCH 5/5] avcodec/hevc_ps: use the AVBufferPool API to allocate parameter set buffers

2018-01-20 Thread James Almer
Signed-off-by: James Almer 
---
I don't know if this brings many benefits. With up to 16 sps/vps
and 64 pps, plus the fact all three ff_hevc_decode_nal_* functions
allocate a buffer even if the result will not be added to the
HEVCParamSets list, it may considerably reduce the amount of buffer
allocations on raw streams where parameter sets are repeated on every
keyframe, but i can't say if it will have a noticeable effect in
performance.

 libavcodec/hevc_parser.c   |  8 +++
 libavcodec/hevc_ps.c   | 57 ++
 libavcodec/hevc_ps.h   |  6 +
 libavcodec/hevcdec.c   |  3 +++
 libavcodec/mediacodecdec.c |  4 
 5 files changed, 64 insertions(+), 14 deletions(-)

diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index 09a203097b..8e4423263d 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -353,6 +353,13 @@ static int hevc_split(AVCodecContext *avctx, const uint8_t 
*buf, int buf_size)
 return 0;
 }
 
+static av_cold int hevc_parser_init(AVCodecParserContext *s)
+{
+HEVCParserContext *ctx = s->priv_data;
+
+return ff_hevc_init_parameter_sets(>ps);
+}
+
 static void hevc_parser_close(AVCodecParserContext *s)
 {
 HEVCParserContext *ctx = s->priv_data;
@@ -368,6 +375,7 @@ AVCodecParser ff_hevc_parser = {
 .codec_ids  = { AV_CODEC_ID_HEVC },
 .priv_data_size = sizeof(HEVCParserContext),
 .parser_parse   = hevc_parse,
+.parser_init= hevc_parser_init,
 .parser_close   = hevc_parser_close,
 .split  = hevc_split,
 };
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index b18457296b..7d5195d667 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -420,7 +420,7 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb, 
AVCodecContext *avctx,
 int vps_id = 0;
 ptrdiff_t nal_size;
 HEVCVPS *vps;
-AVBufferRef *vps_buf = av_buffer_allocz(sizeof(*vps));
+AVBufferRef *vps_buf = av_buffer_pool_get(ps->vps_pool);
 
 if (!vps_buf)
 return AVERROR(ENOMEM);
@@ -1218,11 +1218,11 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb, 
unsigned int *sps_id,
 int ff_hevc_decode_nal_sps(GetBitContext *gb, AVCodecContext *avctx,
HEVCParamSets *ps, int apply_defdispwin)
 {
-HEVCSPS *sps;
-AVBufferRef *sps_buf = av_buffer_allocz(sizeof(*sps));
 unsigned int sps_id;
 int ret;
 ptrdiff_t nal_size;
+HEVCSPS *sps;
+AVBufferRef *sps_buf = av_buffer_pool_get(ps->sps_pool);
 
 if (!sps_buf)
 return AVERROR(ENOMEM);
@@ -1291,6 +1291,21 @@ static void hevc_pps_free(void *opaque, uint8_t *data)
 av_freep();
 }
 
+static AVBufferRef *hevc_pps_alloc(void *opaque, int size)
+{
+AVBufferRef *buf;
+uint8_t *data = av_mallocz(size);
+
+if (!data)
+return NULL;
+
+buf = av_buffer_create(data, size, hevc_pps_free, NULL, 0);
+if (!buf)
+av_free(data);
+
+return buf;
+}
+
 static int pps_range_extensions(GetBitContext *gb, AVCodecContext *avctx,
 HEVCPPS *pps, HEVCSPS *sps) {
 int i;
@@ -1467,19 +1482,12 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb, 
AVCodecContext *avctx,
 unsigned int pps_id = 0;
 ptrdiff_t nal_size;
 unsigned log2_parallel_merge_level_minus2;
+HEVCPPS *pps;
+AVBufferRef *pps_buf = av_buffer_pool_get(ps->pps_pool);
 
-AVBufferRef *pps_buf;
-HEVCPPS *pps = av_mallocz(sizeof(*pps));
-
-if (!pps)
-return AVERROR(ENOMEM);
-
-pps_buf = av_buffer_create((uint8_t *)pps, sizeof(*pps),
-   hevc_pps_free, NULL, 0);
-if (!pps_buf) {
-av_freep();
+if (!pps_buf)
 return AVERROR(ENOMEM);
-}
+pps = (HEVCPPS*)pps_buf->data;
 
 av_log(avctx, AV_LOG_DEBUG, "Decoding PPS\n");
 
@@ -1704,6 +1712,23 @@ err:
 return ret;
 }
 
+int ff_hevc_init_parameter_sets(HEVCParamSets *ps)
+{
+ps->vps_pool = av_buffer_pool_init (sizeof(*ps->vps), av_buffer_allocz);
+ps->sps_pool = av_buffer_pool_init (sizeof(*ps->sps), av_buffer_allocz);
+ps->pps_pool = av_buffer_pool_init2(sizeof(*ps->pps), NULL, 
hevc_pps_alloc, NULL);
+
+if (!ps->vps_pool || !ps->sps_pool || !ps->pps_pool) {
+av_buffer_pool_uninit(>vps_pool);
+av_buffer_pool_uninit(>sps_pool);
+av_buffer_pool_uninit(>pps_pool);
+
+return AVERROR(ENOMEM);
+}
+
+return 0;
+}
+
 void ff_hevc_uninit_parameter_sets(HEVCParamSets *ps)
 {
 int i;
@@ -1715,6 +1740,10 @@ void ff_hevc_uninit_parameter_sets(HEVCParamSets *ps)
 for (i = 0; i < FF_ARRAY_ELEMS(ps->pps_list); i++)
 av_buffer_unref(>pps_list[i]);
 
+av_buffer_pool_uninit(>vps_pool);
+av_buffer_pool_uninit(>sps_pool);
+av_buffer_pool_uninit(>pps_pool);
+
 ps->sps = NULL;
 ps->pps = NULL;
 ps->vps = NULL;
diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
index 871a58acc6..c05265a9be 100644
--- 

[FFmpeg-devel] [PATCH 4/5] avcodec/mediacodecdec: use ff_hevc_uninit_parameter_sets()

2018-01-20 Thread James Almer
Signed-off-by: James Almer 
---
 libavcodec/mediacodecdec.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 6c5d3ddd79..b360e7a7f1 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -258,6 +258,8 @@ static int hevc_set_extradata(AVCodecContext *avctx, 
FFAMediaFormat *format)
 }
 
 done:
+ff_hevc_uninit_parameter_sets();
+
 av_freep(_data);
 av_freep(_data);
 av_freep(_data);
-- 
2.15.0

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


[FFmpeg-devel] [PATCH 3/5] avcodec/hevc_parser: use ff_hevc_uninit_parameter_sets()

2018-01-20 Thread James Almer
Signed-off-by: James Almer 
---
 libavcodec/hevc_parser.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index 76176185fa..09a203097b 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -356,17 +356,8 @@ static int hevc_split(AVCodecContext *avctx, const uint8_t 
*buf, int buf_size)
 static void hevc_parser_close(AVCodecParserContext *s)
 {
 HEVCParserContext *ctx = s->priv_data;
-int i;
-
-for (i = 0; i < FF_ARRAY_ELEMS(ctx->ps.vps_list); i++)
-av_buffer_unref(>ps.vps_list[i]);
-for (i = 0; i < FF_ARRAY_ELEMS(ctx->ps.sps_list); i++)
-av_buffer_unref(>ps.sps_list[i]);
-for (i = 0; i < FF_ARRAY_ELEMS(ctx->ps.pps_list); i++)
-av_buffer_unref(>ps.pps_list[i]);
-
-ctx->ps.sps = NULL;
 
+ff_hevc_uninit_parameter_sets(>ps);
 ff_h2645_packet_uninit(>pkt);
 ff_hevc_reset_sei(>sei);
 
-- 
2.15.0

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


[FFmpeg-devel] [PATCH 2/5] avcodec/hevcdec: use ff_hevc_uninit_parameter_sets()

2018-01-20 Thread James Almer
Signed-off-by: James Almer 
---
 libavcodec/hevcdec.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 4bfae8c12b..98a96defb7 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -3277,15 +3277,7 @@ static av_cold int hevc_decode_free(AVCodecContext 
*avctx)
 av_frame_free(>DPB[i].frame);
 }
 
-for (i = 0; i < FF_ARRAY_ELEMS(s->ps.vps_list); i++)
-av_buffer_unref(>ps.vps_list[i]);
-for (i = 0; i < FF_ARRAY_ELEMS(s->ps.sps_list); i++)
-av_buffer_unref(>ps.sps_list[i]);
-for (i = 0; i < FF_ARRAY_ELEMS(s->ps.pps_list); i++)
-av_buffer_unref(>ps.pps_list[i]);
-s->ps.sps = NULL;
-s->ps.pps = NULL;
-s->ps.vps = NULL;
+ff_hevc_uninit_parameter_sets(>ps);
 
 av_freep(>sh.entry_point_offset);
 av_freep(>sh.offset);
-- 
2.15.0

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


[FFmpeg-devel] [PATCH 1/5] avcodec/hevc_ps: add a function to uninitialize parameter set buffers

2018-01-20 Thread James Almer
Signed-off-by: James Almer 
---
 libavcodec/hevc_ps.c | 16 
 libavcodec/hevc_ps.h |  2 ++
 2 files changed, 18 insertions(+)

diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index a4f7ed60f7..b18457296b 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -1704,6 +1704,22 @@ err:
 return ret;
 }
 
+void ff_hevc_uninit_parameter_sets(HEVCParamSets *ps)
+{
+int i;
+
+for (i = 0; i < FF_ARRAY_ELEMS(ps->vps_list); i++)
+av_buffer_unref(>vps_list[i]);
+for (i = 0; i < FF_ARRAY_ELEMS(ps->sps_list); i++)
+av_buffer_unref(>sps_list[i]);
+for (i = 0; i < FF_ARRAY_ELEMS(ps->pps_list); i++)
+av_buffer_unref(>pps_list[i]);
+
+ps->sps = NULL;
+ps->pps = NULL;
+ps->vps = NULL;
+}
+
 int ff_hevc_compute_poc(const HEVCSPS *sps, int pocTid0, int poc_lsb, int 
nal_unit_type)
 {
 int max_poc_lsb  = 1 << sps->log2_max_poc_lsb;
diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
index 477ee4299a..871a58acc6 100644
--- a/libavcodec/hevc_ps.h
+++ b/libavcodec/hevc_ps.h
@@ -421,6 +421,8 @@ int ff_hevc_decode_nal_sps(GetBitContext *gb, 
AVCodecContext *avctx,
 int ff_hevc_decode_nal_pps(GetBitContext *gb, AVCodecContext *avctx,
HEVCParamSets *ps);
 
+void ff_hevc_uninit_parameter_sets(HEVCParamSets *ps);
+
 int ff_hevc_decode_short_term_rps(GetBitContext *gb, AVCodecContext *avctx,
   ShortTermRPS *rps, const HEVCSPS *sps, int 
is_slice_header);
 
-- 
2.15.0

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


Re: [FFmpeg-devel] [PATCH] Fix memory leak in lrcdec.c

2018-01-20 Thread Michael Niedermayer
On Fri, Jan 19, 2018 at 01:17:07PM -0800, Nikolas Bowe wrote:
> ---
>  libavformat/lrcdec.c | 1 +
>  1 file changed, 1 insertion(+)

will apply

thx

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

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


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


Re: [FFmpeg-devel] [PATCH 1/2] avdevice/decklink: addition of copyts option

2018-01-20 Thread Carl Eugen Hoyos
2018-01-20 20:47 GMT+01:00 Marton Balint :
>
> On Sat, 20 Jan 2018, Carl Eugen Hoyos wrote:
>
>> 2018-01-20 19:50 GMT+01:00 Marton Balint :
>>>
>>> On Sat, 20 Jan 2018, Carl Eugen Hoyos wrote:
>>>
 2018-01-08 6:26 GMT+01:00  :

> +@item decklink_copyts
> +If set to @option{true}, timestamps are forwarded as they are without
> removing
> +the initial offset.
> +Defaults to @option{false}.

 Why is the offset ever removed?
 I believe this is not done for any other demuxer or is it?
>>>
>>> The code keeps track separate audio and video initial offset
>>
>> But they can't be independent or can they?
>> And if they can, how is A/V sync assured?
>
> Well, I am not entirely sure. Decklink has always had problems with
> timestamps and A-V desync was not uncommon when using the default clock
> sources. Probably a bug in the SDK.
>
> The whole offset removal is is originated from this commit:
>
> https://github.com/lu-zero/bmdtools/commit/b51ce3841ea763f27431ed9c77b99ae5404180c6

Thanks for the info, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/2] avdevice/decklink: addition of copyts option

2018-01-20 Thread Marton Balint



On Sat, 20 Jan 2018, Carl Eugen Hoyos wrote:


2018-01-20 19:50 GMT+01:00 Marton Balint :


On Sat, 20 Jan 2018, Carl Eugen Hoyos wrote:


2018-01-08 6:26 GMT+01:00  :


+@item decklink_copyts
+If set to @option{true}, timestamps are forwarded as they are without
removing
+the initial offset.
+Defaults to @option{false}.



Why is the offset ever removed?
I believe this is not done for any other demuxer or is it?


The code keeps track separate audio and video initial offset


But they can't be independent or can they?
And if they can, how is A/V sync assured?


Well, I am not entirely sure. Decklink has always had problems with 
timestamps and A-V desync was not uncommon when using the default clock 
sources. Probably a bug in the SDK.


The whole offset removal is is originated from this commit:

https://github.com/lu-zero/bmdtools/commit/b51ce3841ea763f27431ed9c77b99ae5404180c6

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


Re: [FFmpeg-devel] [PATCH] add dumpwave filter

2018-01-20 Thread Dmytro Humeniuk

> On 18 Jan 2018, at 17:32, Dmytro Humeniuk  wrote:
> 
>> 
>> On 18 Jan 2018, at 08:56, Tobias Rapp  wrote:
>> 
>> On 15.01.2018 13:48, Dmytro Humeniuk wrote:
 On 15 Jan 2018, at 09:14, Tobias Rapp  wrote:
 
 On 13.01.2018 23:52, Дмитрий Гуменюк wrote:
> Hi,
>> On 13 Jan 2018, at 01:37, Дмитрий Гуменюк  
>> wrote:
>> 
>> Hi
>> 
>>> On 12 Jan 2018, at 13:32, Дмитрий Гуменюк  
>>> wrote:
>>> 
 On 12 Jan 2018, at 13:17, Tobias Rapp  wrote:
 
 On 12.01.2018 12:16, Дмитрий Гуменюк wrote:
> Hi
>> On 11 Jan 2018, at 09:20, Tobias Rapp  wrote:
>> 
>> On 10.01.2018 18:18, Kyle Swanson wrote:
>>> Hi,
>>> For this to be a part of libavfilter the output needs to be more 
>>> generic
>>> than the just the Soundcloud format. If we want this to be 
>>> generally useful
>>> it should probably just output an array of floats between 0.0 and 
>>> 1.0. The
>>> consumer of this data (JS library, or whatever) can use this in 
>>> whatever
>>> way it wants.
>> 
>> I agree. If the BWF Peak Envelope output which was suggested in the 
>> other thread does not match your demands and filter implementation 
>> is actually necessary I would prefer if the filter would attach the 
>> RMS value(s) as frame metadata instead of directly dumping to file. 
>> Frame metadata can then be re-
> RMS values may be counted for several frames or only for a half of a 
> frame
>> used by other filters or dumped into file by using the existing 
>> "ametadata" filter.
>> 
>> This would be similar to:
>> 
>> ffmpeg -i input-file -f null -filter:a 
>> "asetnsamples=22050,astats=metadata=on,ametadata=print:file=stats-file.dat"
>>  /dev/null
> I like this idea, but won’t asetnsamples affect performance by 
> creating fifo queue? And it may require some effort to parse long 
> output
 
 I added asetnsamples to define the audio frame size (interval of 
 values from astats). You can reduce the number of lines printed by 
 ametadata by using the "key=lavfi.astats.foo" option.
>>> I used asetnsamples as well, and I measured performance while 
>>> transcoding - it appears to be slight slower
>> I think output is now more generic and I got rid of long switch/case, 
>> thanks for support
> Here is most recent patch, seems like all comments are addressed, did I 
> miss something?
 
 I still would prefer to have the value attached as frame metadata, then 
 dumped into file via the existing "ametadata" filter. Even better would be 
 to integrate the statistic value (if missing) into the "astats" filter.
 
 If your concern is the output format of "ametadata" then some output 
 format extension (CSV/JSON) needs to be discussed for ametadata/metadata.
 
 If your concern is performance then please add some numbers. In my tests 
 using an approx. 5 minutes input WAV file (48kHz, stereo) the run with 
 "asetnsamples" was considerably faster than the run without (1.7s vs. 
 13.9s)
>>> Hi
>>> As I mentioned previously adding metadata to each frame is not possible
>>> as value may be counted for several frames or only for a half of a frame
>>> I used 2 hours long 48kHz mp3 
>>> https://s3-eu-west-1.amazonaws.com/balamii/SynthSystemSystersJAN2018.mp3
>>> For this purposes I set up CentOS AWS EC2 nano instance
>>> Then I transcoded it while filtering like following (just to recreate real 
>>> situation):
>>> 1. -filter:a 
>>> "asetnsamples=192197,astats=metadata=on,ametadata=print:file=stats-file.dat"
>>>  out.mp3
>>> 2. -filter:a "dumpwave=n=192197:f=-" out.mp3
>>> Results:
>>> 1. 244810550046 nanoseconds
>>> 2. 87494286740 nanoseconds
>>> One of the possible use cases - to set up 2 chains of 
>>> asetnsamples->metadata - for example:
>>> "asetnsamples=192197,astats=metadata=on,ametadata=print:file=stats-file.dat,asetnsamples=22050,astats=metadata=on,ametadata=print:file=stats-file1.dat”
>>>  for sure it will affect performance
>>> Comparing with "dumpwave=n=192197:f=out1,dumpwave=n= 22050:f=out2"
>> 
>> Sorry, I misunderstood your concerns regarding asetnsamples filter 
>> performance. The numbers I provided have been for
>> 
>> "asetnsamples=22050,astats=metadata=on,ametadata=print:file=stats-file.dat"
>> 
>> versus
>> 
>> "astats=metadata=on,ametadata=print:file=stats-file.dat"
>> 
>> When comparing astats+ametadata versus dumpwave it is obvious that a 
>> specialized filter which only calculates one statistic value is faster than 
>> a filter that calculates multiple 

Re: [FFmpeg-devel] [PATCH 0/5] x86inc: Sync changes from x264

2018-01-20 Thread Henrik Gramner
Pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/2] avdevice/decklink: addition of copyts option

2018-01-20 Thread Carl Eugen Hoyos
2018-01-20 19:50 GMT+01:00 Marton Balint :
>
> On Sat, 20 Jan 2018, Carl Eugen Hoyos wrote:
>
>> 2018-01-08 6:26 GMT+01:00  :
>>
>>> +@item decklink_copyts
>>> +If set to @option{true}, timestamps are forwarded as they are without
>>> removing
>>> +the initial offset.
>>> +Defaults to @option{false}.
>>
>>
>> Why is the offset ever removed?
>> I believe this is not done for any other demuxer or is it?
>
> The code keeps track separate audio and video initial offset

But they can't be independent or can they?
And if they can, how is A/V sync assured?

I am just surprised because I don't remember another
device input that removes the time offset on initialization
and demuxers like mpegts don't do it either.

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


Re: [FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec

2018-01-20 Thread Rostislav Pehlivanov
On 20 January 2018 at 17:25, Aurelien Jacobs  wrote:

> On Sun, Jan 14, 2018 at 05:19:12PM +, Rostislav Pehlivanov wrote:
> > On 14 January 2018 at 13:06, Aurelien Jacobs  wrote:
> >
> > > On Tue, Jan 09, 2018 at 02:21:02PM +, Rostislav Pehlivanov wrote:
> > > > On 9 January 2018 at 14:07, Rostislav Pehlivanov <
> atomnu...@gmail.com>
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > > On 9 January 2018 at 09:00, Hendrik Leppkes 
> > > wrote:
> > > > >
> > > > >> On Tue, Jan 9, 2018 at 9:33 AM, Hendrik Leppkes <
> h.lepp...@gmail.com>
> > > > >> wrote:
> > > > >> > On Tue, Jan 9, 2018 at 5:07 AM, Rostislav Pehlivanov
> > > > >> >  wrote:
> > > > >> >>
> > > > >> >>> Anyway, all this discussion is moot as Hendrik pointed out
> that
> > > > >> profile
> > > > >> >>> can't be set outside of lavc to determine a decoder behavior.
> > > > >> >>>
> > > > >> >>
> > > > >> >> What, based on a comment in lavc? Comments there describe the
> api
> > > but
> > > > >> they
> > > > >> >> rarely define it. We're free to adjust them if need be and in
> this
> > > > >> case,
> > > > >> >> since the codec profile may not be set, the API user is forced
> to
> > > deal
> > > > >> with
> > > > >> >> the lack of such set. Hence, we can clarify that it may be set
> by
> > > lavf
> > > > >> as
> > > > >> >> well as lavc as well as not being set at all. And the decoder
> may
> > > use
> > > > >> it.
> > > > >> >> I maintain that adding a new codec ID for this is unacceptable.
> > > > >> >>
> > > > >> >
> > > > >> > We already have established methods to select codec
> sub-variants, we
> > > > >> > don't need to invent a new one just because you feel like it.
> > > > >> >
> > > > >>
> > > > >> On that note, we also have cases where the same codec has
> different
> > > > >> codec ids based on popular known names.
> > > > >> For example wmv3/vc1 - wmv3 is simple/main profile, vc1 is
> advanced
> > > > >> profile, different codec ids, same implementation.
> > > > >>
> > > > >> Re-defining public API is what is unacceptable, it requires every
> > > > >> caller of lavc to suddenly start handling one more field for no
> real
> > > > >> reason.
> > > > >>
> > > > >
> > > > > Then its a good thing I suggested something that doesn't involve
> having
> > > > > every caller of lavc to handle another field.
> > > > >
> > > > >
> > > > >
> > > > >> Either use a separate codec ID if there is sufficient reason for
> that
> > > > >> (mostly driven by external factors, if its handled as different
> codecs
> > > > >> everywhere else, not only in marketing but actual (reference)
> > > > >> implementations), or use a codec_tag if one is available (the
> codec id
> > > > >> field from a2dp for example)
> > > > >
> > > > > I'd be fine with using codec tags, but not with codec IDs.
> > > >
> > > > Though for encoding using profiles would be best.
> > >
> > > Well, here is an updated patch which uses codec tags for the decoder
> and
> > > profile for the encoder.
> > >
> > > I still maintain that this solution is worse than using separate
> > > codec IDs.
> > > It is worse for developper / maintainer as it adds a bit of compexity
> to
> > > the code.
> > >
> > > It is worse for user as it requires adding a mandatory parameter for
> > > encoding to aptX HD:
> > >   ffmpeg -i sample.wav -profile:a 1 sample.aptxhd
> > >
> >
> > As opposed to having a mandatory parameter for encoder like -c:a
> > aptx_hd?
>
> No. As opposed to:
> ffmpeg -i sample.wav sample.aptxhd
>
> > Perhaps we should encode everything to aptx hd by default to not have to
> > mess about by confusing users with these codecs or profiles things.
>
> ?
> It is sensible to use the aptxhd encoder by default when muxing to raw
> aptxhd. And it is sensible to use the aptx encoder by default when
> muxing to raw aptx.
> Or do you disagree about this ?
>

I think its sensible to specify a codec, always, and never rely on the
defaults. Especially for raw formats like this.



>
> > > Without this -profile parameter, the encoding will just fail but user
> > > will have to guess how to fix it.
> > >
> >
> > Here's how you could fix it: don't have separate muxers for aptx and
> > aptxhd. Make the aptx muxer handle both .aptx and .aptxhd extensions and
> > the codec tags.
>
> Muxer handling the codec tags ? What do you mean ?
> A muxer can't pass a codec tag to an encoder (encoder's init is called
> before the muxer's init).
>

Not handling, accepting. You currently have 2 muxers doing the same thing
but accepting different codec tags and extensions. You can make it 1 muxer
accepting multiple codec tags and extensions.



>
> > > And the reported stream is much less explicit:
> > >   Stream #0:0: Audio: aptx ([36][0][215][0] / 0xD70024), 48000 Hz, 2
> > > channels, s32p
> > > vs.
> > >   Stream #0:0: Audio: aptx_hd, 48000 Hz, 2 channels, s32p
> > >
> >
> > Profiles are still explicit
> > "Stream #0:0: Audio: aac (LC), 

Re: [FFmpeg-devel] [PATCH 1/2] avdevice/decklink: addition of copyts option

2018-01-20 Thread Marton Balint


On Sat, 20 Jan 2018, Carl Eugen Hoyos wrote:


2018-01-08 6:26 GMT+01:00  :


+@item decklink_copyts
+If set to @option{true}, timestamps are forwarded as they are without removing
+the initial offset.
+Defaults to @option{false}.


Why is the offset ever removed?
I believe this is not done for any other demuxer or is it?


The code keeps track separate audio and video initial offset, so even if 
you are using different clock sources for audio and video, you will get 
comparable output. Probably that is the reason.


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


Re: [FFmpeg-devel] [PATCH 1/2] avdevice/decklink: addition of copyts option

2018-01-20 Thread Carl Eugen Hoyos
2018-01-08 6:26 GMT+01:00  :

> +@item decklink_copyts
> +If set to @option{true}, timestamps are forwarded as they are without 
> removing
> +the initial offset.
> +Defaults to @option{false}.

Why is the offset ever removed?
I believe this is not done for any other demuxer or is it?

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


Re: [FFmpeg-devel] [PATCH 09/11] decklink: Suppress warning about misuse of struct instead of class

2018-01-20 Thread Marton Balint



On Mon, 8 Jan 2018, Devin Heitmueller wrote:


When building with Clang, the following warning is shown:

warning: struct 'IDeckLinkVideoFrame' was previously declared as a
class [-Wmismatched-tags]

The function incorrectly casts IDeckLinkVideoFrame as a struct
instead of a class pointer.

Signed-off-by: Devin Heitmueller 
---
libavdevice/decklink_enc.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


Thannks, applied.

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


Re: [FFmpeg-devel] [PATCH] avcodec/hevc_parser: use ff_hevc_decode_extradata() to parse extradata

2018-01-20 Thread James Almer
On 1/20/2018 1:12 AM, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  libavcodec/hevc_parser.c | 21 +
>  1 file changed, 9 insertions(+), 12 deletions(-)
> 
> diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
> index ff7e8a49d6..a3a9098c7c 100644
> --- a/libavcodec/hevc_parser.c
> +++ b/libavcodec/hevc_parser.c
> @@ -24,6 +24,7 @@
>  
>  #include "golomb.h"
>  #include "hevc.h"
> +#include "hevc_parse.h"
>  #include "hevc_ps.h"
>  #include "hevc_sei.h"
>  #include "h2645_parse.h"
> @@ -43,6 +44,8 @@ typedef struct HEVCParserContext {
>  HEVCSEI sei;
>  SliceHeader sh;
>  
> +int is_avc;
> +int nal_length_size;
>  int parsed_extradata;
>  
>  int poc;
> @@ -181,7 +184,6 @@ static int parse_nal_units(AVCodecParserContext *s, const 
> uint8_t *buf,
>  HEVCParserContext *ctx = s->priv_data;
>  HEVCParamSets *ps = >ps;
>  HEVCSEI *sei = >sei;
> -int is_global = buf == avctx->extradata;
>  int ret, i;
>  
>  /* set some sane default values */
> @@ -191,8 +193,8 @@ static int parse_nal_units(AVCodecParserContext *s, const 
> uint8_t *buf,
>  
>  ff_hevc_reset_sei(sei);
>  
> -ret = ff_h2645_packet_split(>pkt, buf, buf_size, avctx, 0, 0,
> -AV_CODEC_ID_HEVC, 1);
> +ret = ff_h2645_packet_split(>pkt, buf, buf_size, avctx, ctx->is_avc,
> +ctx->nal_length_size, AV_CODEC_ID_HEVC, 1);
>  if (ret < 0)
>  return ret;
>  
> @@ -230,12 +232,6 @@ static int parse_nal_units(AVCodecParserContext *s, 
> const uint8_t *buf,
>  case HEVC_NAL_RADL_R:
>  case HEVC_NAL_RASL_N:
>  case HEVC_NAL_RASL_R:
> -
> -if (is_global) {
> -av_log(avctx, AV_LOG_ERROR, "Invalid NAL unit: %d\n", 
> nal->type);
> -return AVERROR_INVALIDDATA;
> -}
> -
>  ret = hevc_parse_slice_header(s, nal, avctx);
>  if (ret)
>  return ret;
> @@ -243,8 +239,7 @@ static int parse_nal_units(AVCodecParserContext *s, const 
> uint8_t *buf,
>  }
>  }
>  /* didn't find a picture! */
> -if (!is_global)
> -av_log(avctx, AV_LOG_ERROR, "missing picture in access unit\n");
> +av_log(avctx, AV_LOG_ERROR, "missing picture in access unit\n");
>  return -1;
>  }
>  
> @@ -301,7 +296,9 @@ static int hevc_parse(AVCodecParserContext *s, 
> AVCodecContext *avctx,
>  ParseContext *pc = >pc;
>  
>  if (avctx->extradata && !ctx->parsed_extradata) {
> -parse_nal_units(s, avctx->extradata, avctx->extradata_size, avctx);
> +ff_hevc_decode_extradata(buf, buf_size, >ps, >sei, 
> >is_avc,

Changed buf and buf_size locally to avctx->extradata and
avctx->extradata_size.

> + >nal_length_size, 
> avctx->err_recognition,
> + 1, avctx);
>  ctx->parsed_extradata = 1;
>  }
>  
> 

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


Re: [FFmpeg-devel] [PATCH 11/11] decklink: Fix compilation of module on OSX

2018-01-20 Thread Marton Balint



On Mon, 8 Jan 2018, Devin Heitmueller wrote:


Clang applies the missing-prototypes warning on C++ files, whereas
gcc only applies it to C.  As a result, the decklink_common.cpp file
fails to build because of missing prototypes in DecklinkDispatch.cpp
(which is #included by decklink_common.cpp).

We don't want to change the actual Blackmagic SDK sources, so
suppress the warning just for that one #include.

Signed-off-by: Devin Heitmueller 
---
libavdevice/decklink_common.cpp | 11 +++
1 file changed, 11 insertions(+)


Thanks, applied.

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


Re: [FFmpeg-devel] [PATCH v3 1/3] avdevice/decklink: addition of copyts option

2018-01-20 Thread Marton Balint



On Mon, 15 Jan 2018, vdi...@akamai.com wrote:


From: Vishwanath Dixit 

---
doc/indevs.texi |  5 +
libavdevice/decklink_common_c.h |  1 +
libavdevice/decklink_dec.cpp| 18 +++---
libavdevice/decklink_dec_c.c|  1 +
4 files changed, 18 insertions(+), 7 deletions(-)


Applied the whole series with a micro version bump.

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


[FFmpeg-devel] [PATCH] avdevice/decklink_dec: Extract 1080i and NTSC VANC

2018-01-20 Thread Ray Tiley
This changes the vertical blanking lines extracted for NTSC and 1080i
resolutions that in personal testing were required to extract closed
caption data from the decklink video frames.

Additionally NTSC resolutions have the vanc data interleved between the uyvy
and not just the luma as in high definition resolutions.

In my testing this allows a decklink card encoding valid NTSC and 1080i
closed captions to pass the caption data to the x264 encoder.

Signed-off-by: Ray Tiley 
---
 libavdevice/decklink_dec.cpp | 37 -
 1 file changed, 32 insertions(+), 5 deletions(-)

diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 94dae26..bceced5 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -67,8 +67,7 @@ typedef struct VANCLineNumber {
  * another source during switching*/
 static VANCLineNumber vanc_line_numbers[] = {
 /* SD Modes */
-
-{bmdModeNTSC, 11, 19, 274, 282},
+{bmdModeNTSC, 4, 21, 24, 284},
 {bmdModeNTSC2398, 11, 19, 274, 282},
 {bmdModePAL, 7, 22, 320, 335},
 {bmdModeNTSCp, 11, -1, -1, 39},
@@ -82,7 +81,7 @@ static VANCLineNumber vanc_line_numbers[] = {
 {bmdModeHD1080p2997, 8, -1, -1, 42},
 {bmdModeHD1080p30, 8, -1, -1, 42},
 {bmdModeHD1080i50, 8, 20, 570, 585},
-{bmdModeHD1080i5994, 8, 20, 570, 585},
+{bmdModeHD1080i5994, 6, 30, 568, 595},
 {bmdModeHD1080i6000, 8, 20, 570, 585},
 {bmdModeHD1080p50, 8, -1, -1, 42},
 {bmdModeHD1080p5994, 8, -1, -1, 42},
@@ -92,7 +91,7 @@ static VANCLineNumber vanc_line_numbers[] = {
 
 {bmdModeHD720p50, 8, -1, -1, 26},
 {bmdModeHD720p5994, 8, -1, -1, 26},
-{bmdModeHD720p60, 8, -1, -1, 26},
+{bmdModeHD720p60, 7, -1, -1, 26},
 
 /* For all other modes, for which we don't support VANC */
 {bmdModeUnknown, 0, -1, -1, -1}
@@ -149,6 +148,30 @@ static void extract_luma_from_v210(uint16_t *dst, const 
uint8_t *src, int width)
 }
 }
 
+static void unpack_v210(uint16_t *dst, const uint8_t *src, int width)
+{
+int i;
+for (i = 0; i < width / 6; i++) {
+*dst++ =  src[0]   + ((src[1] & 3)  << 8);
+*dst++ = (src[1] >> 2) + ((src[2] & 15) << 6);
+*dst++ = (src[2] >> 4) + ((src[3] & 63) << 4);
+
+*dst++ =  src[4]   + ((src[5] & 3)  << 8);
+*dst++ = (src[5] >> 2) + ((src[6] & 15) << 6);
+*dst++ = (src[6] >> 4) + ((src[7] & 63) << 4);
+
+*dst++ =  src[8]   + ((src[9] & 3)  << 8);
+*dst++ = (src[9] >> 2) + ((src[10] & 15) << 6);
+*dst++ = (src[10] >> 4) + ((src[11] & 63) << 4);
+
+*dst++ =  src[12]   + ((src[13] & 3)  << 8);
+*dst++ = (src[13] >> 2) + ((src[14] & 15) << 6);
+*dst++ = (src[14] >> 4) + ((src[15] & 63) << 4);
+
+src += 16;
+}
+}
+
 static uint8_t calc_parity_and_line_offset(int line)
 {
 uint8_t ret = (line < 313) << 5;
@@ -741,7 +764,11 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
 uint8_t *buf;
 if (vanc->GetBufferForVerticalBlankingLine(i, 
(void**)) == S_OK) {
 uint16_t luma_vanc[MAX_WIDTH_VANC];
-extract_luma_from_v210(luma_vanc, buf, 
videoFrame->GetWidth());
+if (ctx->bmd_mode == bmdModeNTSC) {
+  unpack_v210(luma_vanc, buf, 
videoFrame->GetWidth());
+} else {
+  extract_luma_from_v210(luma_vanc, buf, 
videoFrame->GetWidth());
+}
 txt_buf = get_metadata(avctx, luma_vanc, 
videoFrame->GetWidth(),
txt_buf, sizeof(txt_buf0) - 
(txt_buf - txt_buf0), );
 }
-- 
2.7.4

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


Re: [FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec

2018-01-20 Thread Aurelien Jacobs
On Sun, Jan 14, 2018 at 10:54:34PM +0100, Carl Eugen Hoyos wrote:
> 2018-01-14 14:06 GMT+01:00 Aurelien Jacobs :
> 
> > Well, here is an updated patch which uses codec tags for the decoder and
> > profile for the encoder.
> 
> Sorry but I object to this patch:
> We should not invent codec_tags.

OK, I understand, and I agree.

But now we are in an interlocking situation.
We have 2 solutions to handle aptX vs. aptX HD but those 2 solutions have
been rejected by 2 different person.

Do anybody have a 3rd solution, that everyone would accept ?

And if not, how do we resolve this ?
Is there any policy nowadays to handle this kind of interlocking ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec

2018-01-20 Thread Aurelien Jacobs
On Sun, Jan 14, 2018 at 05:19:12PM +, Rostislav Pehlivanov wrote:
> On 14 January 2018 at 13:06, Aurelien Jacobs  wrote:
> 
> > On Tue, Jan 09, 2018 at 02:21:02PM +, Rostislav Pehlivanov wrote:
> > > On 9 January 2018 at 14:07, Rostislav Pehlivanov 
> > > wrote:
> > >
> > > >
> > > >
> > > > On 9 January 2018 at 09:00, Hendrik Leppkes 
> > wrote:
> > > >
> > > >> On Tue, Jan 9, 2018 at 9:33 AM, Hendrik Leppkes 
> > > >> wrote:
> > > >> > On Tue, Jan 9, 2018 at 5:07 AM, Rostislav Pehlivanov
> > > >> >  wrote:
> > > >> >>
> > > >> >>> Anyway, all this discussion is moot as Hendrik pointed out that
> > > >> profile
> > > >> >>> can't be set outside of lavc to determine a decoder behavior.
> > > >> >>>
> > > >> >>
> > > >> >> What, based on a comment in lavc? Comments there describe the api
> > but
> > > >> they
> > > >> >> rarely define it. We're free to adjust them if need be and in this
> > > >> case,
> > > >> >> since the codec profile may not be set, the API user is forced to
> > deal
> > > >> with
> > > >> >> the lack of such set. Hence, we can clarify that it may be set by
> > lavf
> > > >> as
> > > >> >> well as lavc as well as not being set at all. And the decoder may
> > use
> > > >> it.
> > > >> >> I maintain that adding a new codec ID for this is unacceptable.
> > > >> >>
> > > >> >
> > > >> > We already have established methods to select codec sub-variants, we
> > > >> > don't need to invent a new one just because you feel like it.
> > > >> >
> > > >>
> > > >> On that note, we also have cases where the same codec has different
> > > >> codec ids based on popular known names.
> > > >> For example wmv3/vc1 - wmv3 is simple/main profile, vc1 is advanced
> > > >> profile, different codec ids, same implementation.
> > > >>
> > > >> Re-defining public API is what is unacceptable, it requires every
> > > >> caller of lavc to suddenly start handling one more field for no real
> > > >> reason.
> > > >>
> > > >
> > > > Then its a good thing I suggested something that doesn't involve having
> > > > every caller of lavc to handle another field.
> > > >
> > > >
> > > >
> > > >> Either use a separate codec ID if there is sufficient reason for that
> > > >> (mostly driven by external factors, if its handled as different codecs
> > > >> everywhere else, not only in marketing but actual (reference)
> > > >> implementations), or use a codec_tag if one is available (the codec id
> > > >> field from a2dp for example)
> > > >
> > > > I'd be fine with using codec tags, but not with codec IDs.
> > >
> > > Though for encoding using profiles would be best.
> >
> > Well, here is an updated patch which uses codec tags for the decoder and
> > profile for the encoder.
> >
> > I still maintain that this solution is worse than using separate
> > codec IDs.
> > It is worse for developper / maintainer as it adds a bit of compexity to
> > the code.
> >
> > It is worse for user as it requires adding a mandatory parameter for
> > encoding to aptX HD:
> >   ffmpeg -i sample.wav -profile:a 1 sample.aptxhd
> >
> 
> As opposed to having a mandatory parameter for encoder like -c:a
> aptx_hd?

No. As opposed to:
ffmpeg -i sample.wav sample.aptxhd

> Perhaps we should encode everything to aptx hd by default to not have to
> mess about by confusing users with these codecs or profiles things.

?
It is sensible to use the aptxhd encoder by default when muxing to raw
aptxhd. And it is sensible to use the aptx encoder by default when
muxing to raw aptx.
Or do you disagree about this ?

> > Without this -profile parameter, the encoding will just fail but user
> > will have to guess how to fix it.
> >
> 
> Here's how you could fix it: don't have separate muxers for aptx and
> aptxhd. Make the aptx muxer handle both .aptx and .aptxhd extensions and
> the codec tags.

Muxer handling the codec tags ? What do you mean ?
A muxer can't pass a codec tag to an encoder (encoder's init is called
before the muxer's init).

> > And the reported stream is much less explicit:
> >   Stream #0:0: Audio: aptx ([36][0][215][0] / 0xD70024), 48000 Hz, 2
> > channels, s32p
> > vs.
> >   Stream #0:0: Audio: aptx_hd, 48000 Hz, 2 channels, s32p
> >
> 
> Profiles are still explicit
> "Stream #0:0: Audio: aac (LC), 44100 Hz, stereo, fltp (16 bit), 128 kb/s"
> vs
> "Stream #0:0: Audio: aac (Main), 44100 Hz, stereo, fltp (16 bit), 128 kb/s"

Well, this doesn't work here for aptX. I havn't checked why. Maybe codec
tags is printed rather than profile, when present.

> > So for the good of users and maintainers, I suggest to follow the
> > wmv3/vc1 example, that is to acknowledge that aptX and aptX HD are
> > commonly used as 2 separate codecs (search for
> > libaptX-1.0.0-rel-Android21-ARMv7A.so and
> > libaptXHD-1.0.0-rel-Android21-ARMv7A.so for example) and use the
> > original patch with 2 codec IDs.
> >
> 
> Ah, android, a shining beacon of well-written, small, 

Re: [FFmpeg-devel] [PATCH] avfilter/formats: remove support for deprecated channel count specification

2018-01-20 Thread Marton Balint



On Sat, 6 Jan 2018, Marton Balint wrote:


Signed-off-by: Marton Balint 
---
libavfilter/formats.c | 12 ++--
tests/ref/fate/filter-formats |  2 +-
2 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/libavfilter/formats.c b/libavfilter/formats.c
index 20a2c89719..31ee445c49 100644
--- a/libavfilter/formats.c
+++ b/libavfilter/formats.c
@@ -662,20 +662,12 @@ int ff_parse_sample_rate(int *ret, const char *arg, void 
*log_ctx)
int ff_parse_channel_layout(int64_t *ret, int *nret, const char *arg,
void *log_ctx)
{
-char *tail;
int64_t chlayout;
int nb_channels;

if (av_get_extended_channel_layout(arg, , _channels) < 0) {
-/* [TEMPORARY 2016-12 -> 2017-12]*/
-nb_channels = strtol(arg, , 10);
-if (!errno && *tail == 'c' && *(tail + 1) == '\0' && nb_channels > 0 && 
nb_channels < 64) {
-chlayout = 0;
-av_log(log_ctx, AV_LOG_WARNING, "Deprecated channel count specification 
'%s'. This will stop working in releases made in 2018 and after.\n", arg);
-} else {
-av_log(log_ctx, AV_LOG_ERROR, "Invalid channel layout '%s'\n", 
arg);
-return AVERROR(EINVAL);
-}
+av_log(log_ctx, AV_LOG_ERROR, "Invalid channel layout '%s'\n", arg);
+return AVERROR(EINVAL);
}
if (!chlayout && !nret) {
av_log(log_ctx, AV_LOG_ERROR, "Unknown channel layout '%s' is not 
supported.\n", arg);
diff --git a/tests/ref/fate/filter-formats b/tests/ref/fate/filter-formats
index ea85eed23d..17ff5b222f 100644
--- a/tests/ref/fate/filter-formats
+++ b/tests/ref/fate/filter-formats
@@ -75,7 +75,7 @@ quad(side)
0 = ff_parse_channel_layout(0004,  1, 1c);
0 = ff_parse_channel_layout(0003,  2, 2c);
-1 = ff_parse_channel_layout(, -1, -1c);
-0 = ff_parse_channel_layout(, 60, 60c);
+-1 = ff_parse_channel_layout(, -1, 60c);
-1 = ff_parse_channel_layout(, -1, 65c);
0 = ff_parse_channel_layout(,  2, 2C);
0 = ff_parse_channel_layout(, 60, 60C);


Pushed.

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


Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: Check that data is set

2018-01-20 Thread Steven Liu


> 在 2018年1月20日,上午10:35,Jeyapal, Karthick  写道:
> 
> 
> 
>> On 1/20/18 6:29 AM, Brendan McGrath wrote:
>> If codecpar->extradata is not set (for example, when the stream goes
>> through the 'tee' muxer), then a segfault occurs.
>> 
>> This patch ensures the data variable is not null before attempting
>> to access it
>> 
>> Signed-off-by: Brendan McGrath 
>> ---
>> Before the var_stream_map option was available - I was using the tee
>> muxer to create each resolution as an individual stream.
>> 
>> When running this configuration after the most recent hlsenc change
>> I hit a segfault
>> 
>> The most simple command which recreates the segfault is:
>> ffmpeg -i in.ts -map 0:a -map 0:v -c:a aac -c:v h264 \
>>  -f tee [select=\'a,v\':f=hls]tv_hls_hd.m3u8
>> 
>> libavformat/hlsenc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index 8ad906a..42e437f 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -308,7 +308,7 @@ static void write_codec_attr(AVStream *st, VariantStream 
>> *vs) {
>> 
>> if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
>> uint8_t *data = st->codecpar->extradata;
>> -if ((data[0] | data[1] | data[2]) == 0 && data[3] == 1 && (data[4] 
>> & 0x1F) == 7) {
>> +if (data && (data[0] | data[1] | data[2]) == 0 && data[3] == 1 && 
>> (data[4] & 0x1F) == 7) {
>> snprintf(attr, sizeof(attr),
>>  "avc1.%02x%02x%02x", data[5], data[6], data[7]);
>> } else {
> 
> LGTM. Thanks for the fix

will apply


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


Re: [FFmpeg-devel] [PATCH] dashdec: Make use of frame rate specified in Representation

2018-01-20 Thread Steven Liu


> 在 2018年1月15日,下午11:58,Stefan _  写道:
> 
> Hi,
> 
> attached patch fixes an annoyance when playing DASH videos from e.g. 
> YouTube:
> 
> "mov,mp4,m4a,3gp,3g2,mj2: Stream #0: not enough frames to estimate rate; 
> consider increasing probesize"
> 
> <0001-dashdec-Make-use-of-frame-rate-specified-in-Represen.patch>
> ___

will apply
> 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]lavf/rawdec: Probe last byte for mjpeg

2018-01-20 Thread Carl Eugen Hoyos
Hi!

Attached patch fixes ticket #6957 for me, I believe
there was an off-by-one issue in the original function.

Please comment, Carl Eugen
From 0711e0474f9a83ec47a31b8cf261cf2e6a10a35e Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 20 Jan 2018 16:07:25 +0100
Subject: [PATCH] lavf/rawdec: Also probe the last byte of mjpeg streams.

Fixes ticket #6957.
---
 libavformat/rawdec.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/rawdec.c b/libavformat/rawdec.c
index e926549..b38a4b5 100644
--- a/libavformat/rawdec.c
+++ b/libavformat/rawdec.c
@@ -130,7 +130,7 @@ static int mjpeg_probe(AVProbeData *p)
 int nb_invalid = 0;
 int nb_frames = 0;
 
-for (i=0; ibuf_size-2; i++) {
+for (i = 0; i < p->buf_size - 1; i++) {
 int c;
 if (p->buf[i] != 0xFF)
 continue;
-- 
1.7.10.4

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


Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mlp_parser: don't try to combine frames when full frames are provided

2018-01-20 Thread James Almer
On 1/20/2018 7:15 AM, wm4 wrote:
> On Fri, 19 Jan 2018 20:30:59 -0300
> James Almer  wrote:
> 
>> On 1/19/2018 5:06 PM, wm4 wrote:
>>> On Fri, 19 Jan 2018 16:51:45 -0300
>>> James Almer  wrote:
>>>   
 Attempting full frame reconstruction is unnecessary for containers
 like Matroska, so just skip it altogether.

 Signed-off-by: James Almer 
 ---
  libavcodec/mlp_parser.c | 4 
  1 file changed, 4 insertions(+)

 diff --git a/libavcodec/mlp_parser.c b/libavcodec/mlp_parser.c
 index 3c0330f777..4827354f18 100644
 --- a/libavcodec/mlp_parser.c
 +++ b/libavcodec/mlp_parser.c
 @@ -256,6 +256,9 @@ static int mlp_parse(AVCodecParserContext *s,
  if (buf_size == 0)
  return 0;
  
 +if (s->flags & PARSER_FLAG_COMPLETE_FRAMES) {
 +next = buf_size;
 +} else {
  if (!mp->in_sync) {
  // Not in sync - find a major sync header
  
 @@ -315,6 +318,7 @@ static int mlp_parse(AVCodecParserContext *s,
  }
  
  mp->bytes_left = 0;
 +}
  
  sync_present = (AV_RB32(buf + 4) & 0xfffe) == 0xf8726fba;

>>>
>>> Not so sure about this. I think some mkv TrueHD files contain packets
>>> that are not properly starting on frame boundaries. But I don't really
>>> remember.  
>>
>> As in badly muxed files? Couldn't the same thing happen with any other
>> codec? We're not bothering to consider such cases in other parses as far
>> as i could see.
> 
> From my hazy memory, this also happened with mp3, although the Matroska
> demuxer explicitly forces full parsing for that codec.

I guess i could force full parsing for truehd on matroska as well, but
it kinda defeats the point of this patch. There are not a lot of
containers that support it after all (mpegts is another, but that one
forces full parsing for everything).

Would that be ok?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH]lavf/swfdec: Reduce score when auto-detecting swf files

2018-01-20 Thread Carl Eugen Hoyos
2018-01-20 3:14 GMT+01:00 Michael Niedermayer :
> On Sat, Jan 20, 2018 at 02:36:08AM +0100, Carl Eugen Hoyos wrote:
>> 2018-01-19 23:42 GMT+01:00 Michael Niedermayer :
>> > On Fri, Jan 19, 2018 at 07:25:43PM +0100, Carl Eugen Hoyos wrote:
>> >> 2018-01-19 18:51 GMT+01:00 Michael Niedermayer :
>> >> > On Thu, Jan 18, 2018 at 09:28:40PM +0100, Carl Eugen Hoyos wrote:
>> >> >> Hi!
>> >> >>
>> >> >> The probe score for swf files (with uncompressed headers) is currently
>> >> >> very high after testing a little more than 24bit, attached patch
>> >> >> reduces the score.
>> >> >
>> >> > hmm
>> >> > the first 24 bits are tested and all but 2 values are rejected
>> >> >
>> >> > thats 23 bits that must match
>> >>
>> >> Ok.
>> >>
>> >> > then 4 values are tested which can be from 1 to 31 bits each
>> >> > the tests are each either == 0 or != 0 so they are a bit weak
>> >> > but its at least adding 4 bits that must match and also len
>> >>
>> >> I was sure this is not equivalent to four bits on a specific
>> >> position (but for the patch I assumed a "best case scenario"
>> >> where this actually were the case).
>> >>
>> >> > itself has to be smallish so we could argue that this gets us to
>> >> > about 28 bits
>> >>
>> >> > and then buf[3] is checked to be < 20
>> >> > at this point we need about 32bits to be matching, still not huge but
>> >> > id think this is stronger than what file extensions prove which are
>> >> > MAX/2
>> >>
>> >> We return MAX/2 for many "initial 32 bits" tests and I believe
>> >> we made good experience (and for MAX/2 the extension is
>> >> ignored or do I misremember?)
>> >>
>> >
>> >> > The test is weakened by using 0 / not 0 / ascii as values though
>> >> >
>> >> > Have you seen an actual probe failure ?
>> >>
>> >> No, I was looking at another issue.
>> >
>> > we have many files with wrong extensions, its not uncommon
>>
>> Yes, I misremembered how extensions are rated, I actually
>> wanted to set the return value to "AVPROBE_SCORE_EXTENSION + 1".
>> Would that be ok?
>
> yes

Pushed with this new value.

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


Re: [FFmpeg-devel] [PATCH 1/3] avutil: add staticpool

2018-01-20 Thread Muhammad Faiz
On Sat, Jan 20, 2018 at 6:32 PM, Rostislav Pehlivanov
 wrote:
> On 20 January 2018 at 11:13, Rostislav Pehlivanov 
> wrote:
>
>>
>>
>> On 20 January 2018 at 10:22, wm4  wrote:
>>
>>> On Sat, 20 Jan 2018 11:29:13 +0700
>>> Muhammad Faiz  wrote:
>>>
>>> > Help avoiding malloc-free cycles when allocating-freeing common
>>> > structures.
>>> >
>>> > Signed-off-by: Muhammad Faiz 
>>> > ---
>>> >  libavutil/staticpool.h | 117 ++
>>> +++
>>> >  1 file changed, 117 insertions(+)
>>> >  create mode 100644 libavutil/staticpool.h
>>> >
>>> > diff --git a/libavutil/staticpool.h b/libavutil/staticpool.h
>>> > new file mode 100644
>>> > index 00..9c9b2784bc
>>> > --- /dev/null
>>> > +++ b/libavutil/staticpool.h
>>> > @@ -0,0 +1,117 @@
>>> > +/*
>>> > + * 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
>>> > + */
>>> > +
>>> > +#ifndef AVUTIL_STATICPOOL_H
>>> > +#define AVUTIL_STATICPOOL_H
>>> > +
>>> > +#include 
>>> > +#include "avassert.h"
>>> > +#include "mem.h"
>>> > +
>>> > +/**
>>> > + * FF_STATICPOOL allocate memory without av_malloc if possible
>>> > + * @param size must be 2^n between 64 and 4096
>>> > + */
>>> > +#define FF_STATICPOOL_DECLARE(type, size)
>>>  \
>>> > +typedef struct type##_StaticPoolWrapper {
>>>  \
>>> > +typebuf;
>>>   \
>>> > +unsignedindex;
>>>   \
>>> > +atomic_uint next;
>>>  \
>>> > +} type##_StaticPoolWrapper;
>>>  \
>>> > +
>>>   \
>>> > +static atomic_uint  type##_staticpool_next;
>>>  \
>>> > +static atomic_uint  type##_staticpool_last;
>>>  \
>>> > +static type##_StaticPoolWrapper type##_staticpool_table[size];
>>>   \
>>> > +
>>>   \
>>> > +static type *type##_staticpool_malloc(void)
>>>\
>>> > +{
>>>  \
>>> > +unsigned val, index, serial, new_val;
>>>  \
>>> > +
>>>   \
>>> > +av_assert0((size) >= 64 && (size) <= 4096 && !((size) & ((size) -
>>> 1))); \
>>> > +
>>>   \
>>> > +/* use serial, avoid spinlock */
>>>   \
>>> > +/* acquire, so we don't get stalled table[index].next */
>>>   \
>>> > +val = atomic_load_explicit(##_staticpool_next,
>>> memory_order_acquire);  \
>>> > +do {
>>>   \
>>> > +index  = val & ((size) - 1);
>>>   \
>>> > +serial = val & ~((size) - 1);
>>>  \
>>> > +new_val = 
>>> > atomic_load_explicit(##_staticpool_table[index].next,
>>> memory_order_relaxed) | (serial + (size)); \
>>> > +} while (!atomic_compare_exchange_stro
>>> ng_explicit(##_staticpool_next, , new_val, \
>>> > +
>>> memory_order_acquire, memory_order_acquire)); \
>>> > +
>>>   \
>>> > +index = val & ((size) - 1);
>>>  \
>>> > +if (index)
>>>   \
>>> > +return ##_staticpool_table[index].buf;
>>>\
>>> > +
>>>   \
>>> > +index = atomic_fetch_add_explicit(##_staticpool_last, 1,
>>> memory_order_relaxed) + 1; \
>>> > +if (index < (size)) {
>>>  \
>>> > +type##_staticpool_table[index].index = index;
>>>\
>>> > +return ##_staticpool_table[index].buf;
>>>\
>>> > +}
>>>  \
>>> > +
>>>   \
>>> > +atomic_fetch_add_explicit(##_staticpool_last, -1,
>>> memory_order_relaxed); \
>>> > +return av_malloc(sizeof(type));
>>>  \
>>> > +}
>>>  \
>>> > +
>>>   \
>>> > +static inline type *type##_staticpool_mallocz(void)
>>>\
>>> > +{
>>>  \
>>> > +type *ptr = type##_staticpool_malloc();
>>>  \
>>> > +if (ptr)
>>>   \
>>> > +memset(ptr, 0, sizeof(*ptr));
>>>  \
>>> > +return ptr;
>>>  \
>>> > +}
>>>  \
>>> > +
>>>   \
>>> > +static void type##_staticpool_free(type *ptr)
>>>  \
>>> > +{
>>>  \
>>> > +type##_StaticPoolWrapper *entry = (type##_StaticPoolWrapper *)
>>> ptr; \
>>> > +unsigned val, serial, index, new_val;

[FFmpeg-devel] [PATCH V4 1/7] lavfi: VAAPI VPP common infrastructure.

2018-01-20 Thread Jun Zhao
V4: - Fix the wrong ctx lead to scale_vaapi filter crash issue.
- Follow Mark's suggestion use VAAPIVPPContext as the first field in 
FooVAAPICOntext.
- Add "ff_" prefix to common VPP function.
- Add range map to procamp_vaapi filter.
- Split misc_vaapi as denoise_vaapi/sharpness_vaapi.
V3: - Fix the error handle in vaapi_vpp.
    - Fix the build issue and remove the duplicated header file
- Add a entry to Changelog for procamp_vaapi filter.
 
V2: - Fix the resource leak in procamp/misc VPP filter.
    - Re-work the common VAAPIVPPContext and specific VPP context part
  like VAAPIVPPContext+ScaleVAAPIContext, borrowing the idea from
  vaapi_encode.
    - misc vpp part need to refactoring, and I don't have good idea
  about the file name for vf_misc_vaapi.c, sadly.

From 77cc143b2885c8decb2c2fa26091a9308713e1ce Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Mon, 8 Jan 2018 15:56:43 +0800
Subject: [PATCH V4 1/7] lavfi: VAAPI VPP common infrastructure.

Re-work the VA-API common infrastructure.

Signed-off-by: Jun Zhao 
---
 libavfilter/vaapi_vpp.c | 379 
 libavfilter/vaapi_vpp.h |  82 +++
 2 files changed, 461 insertions(+)
 create mode 100644 libavfilter/vaapi_vpp.c
 create mode 100644 libavfilter/vaapi_vpp.h

diff --git a/libavfilter/vaapi_vpp.c b/libavfilter/vaapi_vpp.c
new file mode 100644
index 00..9d917722a0
--- /dev/null
+++ b/libavfilter/vaapi_vpp.c
@@ -0,0 +1,379 @@
+/*
+ * 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/avassert.h"
+#include "libavutil/pixdesc.h"
+#include "formats.h"
+
+#include "vaapi_vpp.h"
+
+int ff_vaapi_vpp_query_formats(AVFilterContext *avctx)
+{
+enum AVPixelFormat pix_fmts[] = {
+AV_PIX_FMT_VAAPI, AV_PIX_FMT_NONE,
+};
+int err;
+
+if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
+  >inputs[0]->out_formats)) < 0)
+return err;
+if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
+  >outputs[0]->in_formats)) < 0)
+return err;
+
+return 0;
+}
+
+void ff_vaapi_vpp_pipeline_uninit(AVFilterContext *avctx)
+{
+VAAPIVPPContext *ctx   = avctx->priv;
+int i;
+for (i = 0; i < ctx->nb_filter_buffers; i++) {
+if (ctx->filter_buffers[i] != VA_INVALID_ID) {
+vaDestroyBuffer(ctx->hwctx->display, ctx->filter_buffers[i]);
+ctx->filter_buffers[i] = VA_INVALID_ID;
+}
+}
+ctx->nb_filter_buffers = 0;
+
+if (ctx->va_context != VA_INVALID_ID) {
+vaDestroyContext(ctx->hwctx->display, ctx->va_context);
+ctx->va_context = VA_INVALID_ID;
+}
+
+if (ctx->va_config != VA_INVALID_ID) {
+vaDestroyConfig(ctx->hwctx->display, ctx->va_config);
+ctx->va_config = VA_INVALID_ID;
+}
+
+av_buffer_unref(>output_frames_ref);
+av_buffer_unref(>device_ref);
+ctx->hwctx = NULL;
+}
+
+int ff_vaapi_vpp_config_input(AVFilterLink *inlink)
+{
+AVFilterContext *avctx = inlink->dst;
+VAAPIVPPContext *ctx   = avctx->priv;
+
+if (ctx->pipeline_uninit)
+ctx->pipeline_uninit(avctx);
+
+if (!inlink->hw_frames_ctx) {
+av_log(avctx, AV_LOG_ERROR, "A hardware frames reference is "
+   "required to associate the processing device.\n");
+return AVERROR(EINVAL);
+}
+
+ctx->input_frames_ref = av_buffer_ref(inlink->hw_frames_ctx);
+if (!ctx->input_frames_ref) {
+av_log(avctx, AV_LOG_ERROR, "A input frames reference create "
+   "failed.\n");
+return AVERROR(ENOMEM);
+}
+ctx->input_frames = (AVHWFramesContext*)ctx->input_frames_ref->data;
+
+return 0;
+}
+
+int ff_vaapi_vpp_config_output(AVFilterLink *outlink)
+{
+AVFilterContext *avctx = outlink->src;
+VAAPIVPPContext *ctx   = avctx->priv;
+AVVAAPIHWConfig *hwconfig = NULL;
+AVHWFramesConstraints *constraints = NULL;
+AVVAAPIFramesContext *va_frames;
+VAStatus vas;
+int err, i;
+
+if (ctx->pipeline_uninit)
+ctx->pipeline_uninit(avctx);
+
+if (!ctx->output_width)
+ctx->output_width  = avctx->inputs[0]->w;
+if 

[FFmpeg-devel] [PATCH V4 4/7] lavfi: add ProcAmp(color balance) vaapi video filter.

2018-01-20 Thread Jun Zhao

From 5f561eca2fca4e173badfadc2e9a06f1d85d9b7d Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Mon, 8 Jan 2018 16:12:41 +0800
Subject: [PATCH V4 4/7] lavfi: add ProcAmp(color balance) vaapi video filter.

add ProcAmp(color balance) vaapi video filter, use the option
like -vf "procamp_vaapi=b=10:h=120:c=2.8:s=3.7" to set
brightness/hue/contrast/saturation.

Signed-off-by: Yun Zhou 
Signed-off-by: Jun Zhao 
---
 configure  |   1 +
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/vf_procamp_vaapi.c | 281 +
 4 files changed, 284 insertions(+)
 create mode 100644 libavfilter/vf_procamp_vaapi.c

diff --git a/configure b/configure
index 5d533621ae..12fb34a202 100755
--- a/configure
+++ b/configure
@@ -3245,6 +3245,7 @@ perspective_filter_deps="gpl"
 phase_filter_deps="gpl"
 pp7_filter_deps="gpl"
 pp_filter_deps="gpl postproc"
+procamp_vaapi_filter_deps="vaapi VAProcPipelineParameterBuffer"
 program_opencl_filter_deps="opencl"
 pullup_filter_deps="gpl"
 removelogo_filter_deps="avcodec avformat swscale"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index bbc97a0831..43d0dd36e6 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -275,6 +275,7 @@ OBJS-$(CONFIG_PP_FILTER) += vf_pp.o
 OBJS-$(CONFIG_PP7_FILTER)+= vf_pp7.o
 OBJS-$(CONFIG_PREMULTIPLY_FILTER)+= vf_premultiply.o framesync.o
 OBJS-$(CONFIG_PREWITT_FILTER)+= vf_convolution.o
+OBJS-$(CONFIG_PROCAMP_VAAPI_FILTER)  += vf_procamp_vaapi.o vaapi_vpp.o
 OBJS-$(CONFIG_PROGRAM_OPENCL_FILTER) += vf_program_opencl.o opencl.o 
framesync.o
 OBJS-$(CONFIG_PSEUDOCOLOR_FILTER)+= vf_pseudocolor.o
 OBJS-$(CONFIG_PSNR_FILTER)   += vf_psnr.o framesync.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 42516bbdf9..63550628e5 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -284,6 +284,7 @@ static void register_all(void)
 REGISTER_FILTER(PP7,pp7,vf);
 REGISTER_FILTER(PREMULTIPLY,premultiply,vf);
 REGISTER_FILTER(PREWITT,prewitt,vf);
+REGISTER_FILTER(PROCAMP_VAAPI,  procamp_vaapi,  vf);
 REGISTER_FILTER(PROGRAM_OPENCL, program_opencl, vf);
 REGISTER_FILTER(PSEUDOCOLOR,pseudocolor,vf);
 REGISTER_FILTER(PSNR,   psnr,   vf);
diff --git a/libavfilter/vf_procamp_vaapi.c b/libavfilter/vf_procamp_vaapi.c
new file mode 100644
index 00..10f9a6ba0c
--- /dev/null
+++ b/libavfilter/vf_procamp_vaapi.c
@@ -0,0 +1,281 @@
+/*
+ * 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/avassert.h"
+#include "libavutil/mem.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "vaapi_vpp.h"
+
+// ProcAmp Min/Max/Default Values
+#define BRIGHTNESS_MIN -100.0F
+#define BRIGHTNESS_MAX  100.0F
+#define BRIGHTNESS_DEFAULT0.0F
+
+#define CONTRAST_MIN  0.0F
+#define CONTRAST_MAX 10.0F
+#define CONTRAST_DEFAULT  1.0F
+
+#define HUE_MIN-180.0F
+#define HUE_MAX 180.0F
+#define HUE_DEFAULT   0.0F
+
+#define SATURATION_MIN0.0F
+#define SATURATION_MAX   10.0F
+#define SATURATION_DEFAULT1.0F
+
+#define EPSILON   0.1F
+
+typedef struct ProcampVAAPIContext {
+VAAPIVPPContext vpp_ctx; // must be the first fileld
+
+float bright;
+float hue;
+float saturation;
+float contrast;
+} ProcampVAAPIContext;
+
+static float map(float x, float in_min, float in_max, float out_min, float 
out_max)
+{
+double slope, output;
+
+slope = 1.0 * (out_max - out_min) / (in_max - in_min);
+output = out_min + slope * (x - in_min);
+
+return (float)output;
+}
+
+static int fequal(float a, float b)
+{
+return fabs(a-b) < EPSILON;
+}
+
+static int procamp_vaapi_build_filter_params(AVFilterContext *avctx)
+{
+VAAPIVPPContext *vpp_ctx = avctx->priv;
+ProcampVAAPIContext *ctx = avctx->priv;
+VAStatus vas;
+

[FFmpeg-devel] [PATCH V4 7/7] Changelog: add Misc VPP(denoise/sharpness) filter entry.

2018-01-20 Thread Jun Zhao

From 78a03fa2ddb5a254f75e526248037a667442fafc Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Sat, 20 Jan 2018 12:43:04 +0800
Subject: [PATCH V4 7/7] Changelog: add Misc VPP(denoise/sharpness) filter
 entry.

Signed-off-by: Jun Zhao 
---
 Changelog | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Changelog b/Changelog
index b5ea252de4..5c6be090d1 100644
--- a/Changelog
+++ b/Changelog
@@ -39,6 +39,7 @@ version :
 - Removed the ffmenc and ffmdec muxer and demuxer
 - VideoToolbox HEVC encoder and hwaccel
 - VAAPI-accelerated ProcAmp(color balance) video filter
+- VAAPI-accelerated Misc(denoise/sharpness) video filter
 
 version 3.4:
 - deflicker video filter
-- 
2.14.1

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


[FFmpeg-devel] [PATCH V4 5/7] lavfi: add misc(denoise/sharpness) VPP video filter.

2018-01-20 Thread Jun Zhao

From f8b21eda57c036c91d114d3a1f89a75ebdb7a104 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Mon, 8 Jan 2018 16:19:17 +0800
Subject: [PATCH V4 5/7] lavfi: add misc(denoise/sharpness) VPP video filter.

add misc(denoise/sharpness) VPP video filter.

 Signed-off-by: Yun Zhou 
 Signed-off-by: Jun Zhao 
---
 configure   |   2 +
 libavfilter/Makefile|   3 +
 libavfilter/allfilters.c|   2 +
 libavfilter/vf_misc_vaapi.c | 293 
 4 files changed, 300 insertions(+)
 create mode 100644 libavfilter/vf_misc_vaapi.c

diff --git a/configure b/configure
index 12fb34a202..24c4f672a3 100755
--- a/configure
+++ b/configure
@@ -3204,6 +3204,7 @@ deconvolve_filter_select="fft"
 deinterlace_qsv_filter_deps="libmfx"
 deinterlace_vaapi_filter_deps="vaapi"
 delogo_filter_deps="gpl"
+denoise_vaapi_filter_deps="vaapi VAProcPipelineParameterBuffer"
 deshake_filter_select="pixelutils"
 drawtext_filter_deps="libfreetype"
 drawtext_filter_suggest="libfontconfig libfribidi"
@@ -3257,6 +3258,7 @@ scale2ref_filter_deps="swscale"
 scale_filter_deps="swscale"
 scale_qsv_filter_deps="libmfx"
 select_filter_select="pixelutils"
+sharpness_vaapi_filter_deps="vaapi VAProcPipelineParameterBuffer"
 showcqt_filter_deps="avcodec avformat swscale"
 showcqt_filter_suggest="libfontconfig libfreetype"
 showcqt_filter_select="fft"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 43d0dd36e6..e7d3518c90 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -174,6 +174,7 @@ OBJS-$(CONFIG_DEINTERLACE_QSV_FILTER)+= 
vf_deinterlace_qsv.o
 OBJS-$(CONFIG_DEINTERLACE_VAAPI_FILTER)  += vf_deinterlace_vaapi.o 
vaapi_vpp.o
 OBJS-$(CONFIG_DEJUDDER_FILTER)   += vf_dejudder.o
 OBJS-$(CONFIG_DELOGO_FILTER) += vf_delogo.o
+OBJS-$(CONFIG_DENOISE_VAAPI_FILTER)  += vf_misc_vaapi.o vaapi_vpp.o
 OBJS-$(CONFIG_DESHAKE_FILTER)+= vf_deshake.o
 OBJS-$(CONFIG_DESPILL_FILTER)+= vf_despill.o
 OBJS-$(CONFIG_DETELECINE_FILTER) += vf_detelecine.o
@@ -246,6 +247,7 @@ OBJS-$(CONFIG_MESTIMATE_FILTER)  += 
vf_mestimate.o motion_estimation
 OBJS-$(CONFIG_METADATA_FILTER)   += f_metadata.o
 OBJS-$(CONFIG_MIDEQUALIZER_FILTER)   += vf_midequalizer.o framesync.o
 OBJS-$(CONFIG_MINTERPOLATE_FILTER)   += vf_minterpolate.o 
motion_estimation.o
+OBJS-$(CONFIG_MISC_VAAPI_FILTER) += vf_misc_vaapi.o vaapi_vpp.o
 OBJS-$(CONFIG_MIX_FILTER)+= vf_mix.o
 OBJS-$(CONFIG_MPDECIMATE_FILTER) += vf_mpdecimate.o
 OBJS-$(CONFIG_NEGATE_FILTER) += vf_lut.o
@@ -309,6 +311,7 @@ OBJS-$(CONFIG_SETPTS_FILTER) += setpts.o
 OBJS-$(CONFIG_SETRANGE_FILTER)   += vf_setparams.o
 OBJS-$(CONFIG_SETSAR_FILTER) += vf_aspect.o
 OBJS-$(CONFIG_SETTB_FILTER)  += settb.o
+OBJS-$(CONFIG_SHARPNESS_VAAPI_FILTER)+= vf_misc_vaapi.o vaapi_vpp.o
 OBJS-$(CONFIG_SHOWINFO_FILTER)   += vf_showinfo.o
 OBJS-$(CONFIG_SHOWPALETTE_FILTER)+= vf_showpalette.o
 OBJS-$(CONFIG_SHUFFLEFRAMES_FILTER)  += vf_shuffleframes.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 63550628e5..9adb1090b7 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -184,6 +184,7 @@ static void register_all(void)
 REGISTER_FILTER(DEINTERLACE_VAAPI, deinterlace_vaapi, vf);
 REGISTER_FILTER(DEJUDDER,   dejudder,   vf);
 REGISTER_FILTER(DELOGO, delogo, vf);
+REGISTER_FILTER(DENOISE_VAAPI,  denoise_vaapi,  vf);
 REGISTER_FILTER(DESHAKE,deshake,vf);
 REGISTER_FILTER(DESPILL,despill,vf);
 REGISTER_FILTER(DETELECINE, detelecine, vf);
@@ -318,6 +319,7 @@ static void register_all(void)
 REGISTER_FILTER(SETRANGE,   setrange,   vf);
 REGISTER_FILTER(SETSAR, setsar, vf);
 REGISTER_FILTER(SETTB,  settb,  vf);
+REGISTER_FILTER(SHARPNESS_VAAPI, sharpness_vaapi, vf);
 REGISTER_FILTER(SHOWINFO,   showinfo,   vf);
 REGISTER_FILTER(SHOWPALETTE,showpalette,vf);
 REGISTER_FILTER(SHUFFLEFRAMES,  shuffleframes,  vf);
diff --git a/libavfilter/vf_misc_vaapi.c b/libavfilter/vf_misc_vaapi.c
new file mode 100644
index 00..316f15e38b
--- /dev/null
+++ b/libavfilter/vf_misc_vaapi.c
@@ -0,0 +1,293 @@
+/*
+ * 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 

[FFmpeg-devel] [PATCH V4 6/7] Changelog: add ProcAmp(color balance) filter.

2018-01-20 Thread Jun Zhao

From 1e665ac730cf552fe0d7010e306de541cbe0ed89 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Thu, 18 Jan 2018 12:51:20 +0800
Subject: [PATCH V4 6/7] Changelog: add ProcAmp(color balance) filter.

Signed-off-by: Jun Zhao 
---
 Changelog | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Changelog b/Changelog
index 61075b3392..b5ea252de4 100644
--- a/Changelog
+++ b/Changelog
@@ -38,7 +38,7 @@ version :
 - Removed the ffserver program
 - Removed the ffmenc and ffmdec muxer and demuxer
 - VideoToolbox HEVC encoder and hwaccel
-
+- VAAPI-accelerated ProcAmp(color balance) video filter
 
 version 3.4:
 - deflicker video filter
-- 
2.14.1

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


[FFmpeg-devel] [PATCH V4 3/7] lavfi: use common VPP infrastructure for vf_deinterlace_vaapi.

2018-01-20 Thread Jun Zhao

From 376c1590a501ca88450ff3d737676643beee6c53 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Mon, 8 Jan 2018 16:07:38 +0800
Subject: [PATCH V4 3/7] lavfi: use common VPP infrastructure for
 vf_deinterlace_vaapi.

Use the common VPP infrastructure re-work vf_deinterlace_vaapi.

Signed-off-by: Jun Zhao 
---
 libavfilter/Makefile   |   2 +-
 libavfilter/vf_deinterlace_vaapi.c | 351 +
 2 files changed, 46 insertions(+), 307 deletions(-)

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 3d8dd2c890..bbc97a0831 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -171,7 +171,7 @@ OBJS-$(CONFIG_DECONVOLVE_FILTER) += 
vf_convolve.o framesync.o
 OBJS-$(CONFIG_DEFLATE_FILTER)+= vf_neighbor.o
 OBJS-$(CONFIG_DEFLICKER_FILTER)  += vf_deflicker.o
 OBJS-$(CONFIG_DEINTERLACE_QSV_FILTER)+= vf_deinterlace_qsv.o
-OBJS-$(CONFIG_DEINTERLACE_VAAPI_FILTER)  += vf_deinterlace_vaapi.o
+OBJS-$(CONFIG_DEINTERLACE_VAAPI_FILTER)  += vf_deinterlace_vaapi.o 
vaapi_vpp.o
 OBJS-$(CONFIG_DEJUDDER_FILTER)   += vf_dejudder.o
 OBJS-$(CONFIG_DELOGO_FILTER) += vf_delogo.o
 OBJS-$(CONFIG_DESHAKE_FILTER)+= vf_deshake.o
diff --git a/libavfilter/vf_deinterlace_vaapi.c 
b/libavfilter/vf_deinterlace_vaapi.c
index a38da5d57b..9700f85817 100644
--- a/libavfilter/vf_deinterlace_vaapi.c
+++ b/libavfilter/vf_deinterlace_vaapi.c
@@ -18,13 +18,8 @@
 
 #include 
 
-#include 
-#include 
-
 #include "libavutil/avassert.h"
 #include "libavutil/common.h"
-#include "libavutil/hwcontext.h"
-#include "libavutil/hwcontext_vaapi.h"
 #include "libavutil/mem.h"
 #include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
@@ -33,31 +28,17 @@
 #include "formats.h"
 #include "internal.h"
 #include "video.h"
+#include "vaapi_vpp.h"
 
 #define MAX_REFERENCES 8
 
 typedef struct DeintVAAPIContext {
-const AVClass *class;
-
-AVVAAPIDeviceContext *hwctx;
-AVBufferRef   *device_ref;
+VAAPIVPPContext vpp_ctx; // must be the first fileld
 
 intmode;
 intfield_rate;
 intauto_enable;
 
-intvalid_ids;
-VAConfigID va_config;
-VAContextIDva_context;
-
-AVBufferRef   *input_frames_ref;
-AVHWFramesContext *input_frames;
-
-AVBufferRef   *output_frames_ref;
-AVHWFramesContext *output_frames;
-intoutput_height;
-intoutput_width;
-
 VAProcFilterCapDeinterlacing
deint_caps[VAProcDeinterlacingCount];
 int nb_deint_caps;
@@ -67,8 +48,6 @@ typedef struct DeintVAAPIContext {
 intqueue_count;
 AVFrame   *frame_queue[MAX_REFERENCES];
 intextra_delay_for_timestamps;
-
-VABufferID filter_buffer;
 } DeintVAAPIContext;
 
 static const char *deint_vaapi_mode_name(int mode)
@@ -85,82 +64,29 @@ static const char *deint_vaapi_mode_name(int mode)
 }
 }
 
-static int deint_vaapi_query_formats(AVFilterContext *avctx)
+static void deint_vaapi_pipeline_uninit(AVFilterContext *avctx)
 {
-enum AVPixelFormat pix_fmts[] = {
-AV_PIX_FMT_VAAPI, AV_PIX_FMT_NONE,
-};
-int err;
-
-if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
-  >inputs[0]->out_formats)) < 0)
-return err;
-if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
-  >outputs[0]->in_formats)) < 0)
-return err;
-
-return 0;
-}
-
-static int deint_vaapi_pipeline_uninit(AVFilterContext *avctx)
-{
-DeintVAAPIContext *ctx = avctx->priv;
+DeintVAAPIContext *ctx   = avctx->priv;
 int i;
 
 for (i = 0; i < ctx->queue_count; i++)
 av_frame_free(>frame_queue[i]);
 ctx->queue_count = 0;
 
-if (ctx->filter_buffer != VA_INVALID_ID) {
-vaDestroyBuffer(ctx->hwctx->display, ctx->filter_buffer);
-ctx->filter_buffer = VA_INVALID_ID;
-}
-
-if (ctx->va_context != VA_INVALID_ID) {
-vaDestroyContext(ctx->hwctx->display, ctx->va_context);
-ctx->va_context = VA_INVALID_ID;
-}
-
-if (ctx->va_config != VA_INVALID_ID) {
-vaDestroyConfig(ctx->hwctx->display, ctx->va_config);
-ctx->va_config = VA_INVALID_ID;
-}
-
-av_buffer_unref(>device_ref);
-ctx->hwctx = NULL;
-
-return 0;
-}
-
-static int deint_vaapi_config_input(AVFilterLink *inlink)
-{
-AVFilterContext   *avctx = inlink->dst;
-DeintVAAPIContext *ctx = avctx->priv;
-
-deint_vaapi_pipeline_uninit(avctx);
-
-if (!inlink->hw_frames_ctx) {
-av_log(avctx, AV_LOG_ERROR, "A hardware frames reference is "
-   "required to associate the processing device.\n");
-return AVERROR(EINVAL);
-}
-
-ctx->input_frames_ref = av_buffer_ref(inlink->hw_frames_ctx);
-   

[FFmpeg-devel] [PATCH V4 2/7] lavfi: use common VPP infrastructure for vf_scale_vaapi.

2018-01-20 Thread Jun Zhao

From 58ab684afc6646e2eb092481a69cd633064f4a96 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Mon, 8 Jan 2018 16:02:35 +0800
Subject: [PATCH V4 2/7] lavfi: use common VPP infrastructure for
 vf_scale_vaapi.

Use the common VPP infrastructure re-work vf_scale_vaapi.

Signed-off-by: Jun Zhao 
---
 libavfilter/Makefile |   2 +-
 libavfilter/vf_scale_vaapi.c | 356 +--
 2 files changed, 42 insertions(+), 316 deletions(-)

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index ef4729dd3f..3d8dd2c890 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -296,7 +296,7 @@ OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o 
scale.o
 OBJS-$(CONFIG_SCALE_CUDA_FILTER) += vf_scale_cuda.o 
vf_scale_cuda.ptx.o
 OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
 OBJS-$(CONFIG_SCALE_QSV_FILTER)  += vf_scale_qsv.o
-OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o
+OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o 
vaapi_vpp.o
 OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale.o
 OBJS-$(CONFIG_SELECT_FILTER) += f_select.o
 OBJS-$(CONFIG_SELECTIVECOLOR_FILTER) += vf_selectivecolor.o
diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
index 4bead5aaf4..d349ff0f90 100644
--- a/libavfilter/vf_scale_vaapi.c
+++ b/libavfilter/vf_scale_vaapi.c
@@ -18,12 +18,7 @@
 
 #include 
 
-#include 
-#include 
-
 #include "libavutil/avassert.h"
-#include "libavutil/hwcontext.h"
-#include "libavutil/hwcontext_vaapi.h"
 #include "libavutil/mem.h"
 #include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
@@ -33,276 +28,74 @@
 #include "internal.h"
 #include "scale.h"
 #include "video.h"
+#include "vaapi_vpp.h"
 
 typedef struct ScaleVAAPIContext {
-const AVClass *class;
-
-AVVAAPIDeviceContext *hwctx;
-AVBufferRef *device_ref;
-
-int valid_ids;
-VAConfigID  va_config;
-VAContextID va_context;
-
-AVBufferRef   *input_frames_ref;
-AVHWFramesContext *input_frames;
-
-AVBufferRef   *output_frames_ref;
-AVHWFramesContext *output_frames;
+VAAPIVPPContext vpp_ctx; // must be the first fileld
 
 char *output_format_string;
-enum AVPixelFormat output_format;
 
 char *w_expr;  // width expression string
 char *h_expr;  // height expression string
-
-int output_width;  // computed width
-int output_height; // computed height
 } ScaleVAAPIContext;
 
-
-static int scale_vaapi_query_formats(AVFilterContext *avctx)
-{
-enum AVPixelFormat pix_fmts[] = {
-AV_PIX_FMT_VAAPI, AV_PIX_FMT_NONE,
-};
-int err;
-
-if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
-  >inputs[0]->out_formats)) < 0)
-return err;
-if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
-  >outputs[0]->in_formats)) < 0)
-return err;
-
-return 0;
-}
-
-static int scale_vaapi_pipeline_uninit(ScaleVAAPIContext *ctx)
-{
-if (ctx->va_context != VA_INVALID_ID) {
-vaDestroyContext(ctx->hwctx->display, ctx->va_context);
-ctx->va_context = VA_INVALID_ID;
-}
-
-if (ctx->va_config != VA_INVALID_ID) {
-vaDestroyConfig(ctx->hwctx->display, ctx->va_config);
-ctx->va_config = VA_INVALID_ID;
-}
-
-av_buffer_unref(>output_frames_ref);
-av_buffer_unref(>device_ref);
-ctx->hwctx = 0;
-
-return 0;
-}
-
-static int scale_vaapi_config_input(AVFilterLink *inlink)
-{
-AVFilterContext *avctx = inlink->dst;
-ScaleVAAPIContext *ctx = avctx->priv;
-
-scale_vaapi_pipeline_uninit(ctx);
-
-if (!inlink->hw_frames_ctx) {
-av_log(avctx, AV_LOG_ERROR, "A hardware frames reference is "
-   "required to associate the processing device.\n");
-return AVERROR(EINVAL);
-}
-
-ctx->input_frames_ref = av_buffer_ref(inlink->hw_frames_ctx);
-ctx->input_frames = (AVHWFramesContext*)ctx->input_frames_ref->data;
-
-return 0;
-}
-
 static int scale_vaapi_config_output(AVFilterLink *outlink)
 {
-AVFilterLink *inlink = outlink->src->inputs[0];
-AVFilterContext *avctx = outlink->src;
-ScaleVAAPIContext *ctx = avctx->priv;
-AVVAAPIHWConfig *hwconfig = NULL;
-AVHWFramesConstraints *constraints = NULL;
-AVVAAPIFramesContext *va_frames;
-VAStatus vas;
-int err, i;
-
-scale_vaapi_pipeline_uninit(ctx);
-
-ctx->device_ref = av_buffer_ref(ctx->input_frames->device_ref);
-ctx->hwctx = ((AVHWDeviceContext*)ctx->device_ref->data)->hwctx;
-
-av_assert0(ctx->va_config == VA_INVALID_ID);
-vas = vaCreateConfig(ctx->hwctx->display, VAProfileNone,
- VAEntrypointVideoProc, 0, 0, >va_config);
-if (vas != VA_STATUS_SUCCESS) {
-av_log(ctx, AV_LOG_ERROR, "Failed to create processing pipeline "
- 

Re: [FFmpeg-devel] [PATCH] dashdec: Make use of frame rate specified in Representation

2018-01-20 Thread Stefan _
bump

On 15.01.2018 at 16:58 Stefan _ wrote:
> Hi,
>
> attached patch fixes an annoyance when playing DASH videos from e.g.
> YouTube:
>
> "mov,mp4,m4a,3gp,3g2,mj2: Stream #0: not enough frames to estimate rate;
> consider increasing probesize"


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


Re: [FFmpeg-devel] [PATCH 1/3] avutil: add staticpool

2018-01-20 Thread Rostislav Pehlivanov
On 20 January 2018 at 11:13, Rostislav Pehlivanov 
wrote:

>
>
> On 20 January 2018 at 10:22, wm4  wrote:
>
>> On Sat, 20 Jan 2018 11:29:13 +0700
>> Muhammad Faiz  wrote:
>>
>> > Help avoiding malloc-free cycles when allocating-freeing common
>> > structures.
>> >
>> > Signed-off-by: Muhammad Faiz 
>> > ---
>> >  libavutil/staticpool.h | 117 ++
>> +++
>> >  1 file changed, 117 insertions(+)
>> >  create mode 100644 libavutil/staticpool.h
>> >
>> > diff --git a/libavutil/staticpool.h b/libavutil/staticpool.h
>> > new file mode 100644
>> > index 00..9c9b2784bc
>> > --- /dev/null
>> > +++ b/libavutil/staticpool.h
>> > @@ -0,0 +1,117 @@
>> > +/*
>> > + * 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
>> > + */
>> > +
>> > +#ifndef AVUTIL_STATICPOOL_H
>> > +#define AVUTIL_STATICPOOL_H
>> > +
>> > +#include 
>> > +#include "avassert.h"
>> > +#include "mem.h"
>> > +
>> > +/**
>> > + * FF_STATICPOOL allocate memory without av_malloc if possible
>> > + * @param size must be 2^n between 64 and 4096
>> > + */
>> > +#define FF_STATICPOOL_DECLARE(type, size)
>>  \
>> > +typedef struct type##_StaticPoolWrapper {
>>  \
>> > +typebuf;
>>   \
>> > +unsignedindex;
>>   \
>> > +atomic_uint next;
>>  \
>> > +} type##_StaticPoolWrapper;
>>  \
>> > +
>>   \
>> > +static atomic_uint  type##_staticpool_next;
>>  \
>> > +static atomic_uint  type##_staticpool_last;
>>  \
>> > +static type##_StaticPoolWrapper type##_staticpool_table[size];
>>   \
>> > +
>>   \
>> > +static type *type##_staticpool_malloc(void)
>>\
>> > +{
>>  \
>> > +unsigned val, index, serial, new_val;
>>  \
>> > +
>>   \
>> > +av_assert0((size) >= 64 && (size) <= 4096 && !((size) & ((size) -
>> 1))); \
>> > +
>>   \
>> > +/* use serial, avoid spinlock */
>>   \
>> > +/* acquire, so we don't get stalled table[index].next */
>>   \
>> > +val = atomic_load_explicit(##_staticpool_next,
>> memory_order_acquire);  \
>> > +do {
>>   \
>> > +index  = val & ((size) - 1);
>>   \
>> > +serial = val & ~((size) - 1);
>>  \
>> > +new_val = 
>> > atomic_load_explicit(##_staticpool_table[index].next,
>> memory_order_relaxed) | (serial + (size)); \
>> > +} while (!atomic_compare_exchange_stro
>> ng_explicit(##_staticpool_next, , new_val, \
>> > +
>> memory_order_acquire, memory_order_acquire)); \
>> > +
>>   \
>> > +index = val & ((size) - 1);
>>  \
>> > +if (index)
>>   \
>> > +return ##_staticpool_table[index].buf;
>>\
>> > +
>>   \
>> > +index = atomic_fetch_add_explicit(##_staticpool_last, 1,
>> memory_order_relaxed) + 1; \
>> > +if (index < (size)) {
>>  \
>> > +type##_staticpool_table[index].index = index;
>>\
>> > +return ##_staticpool_table[index].buf;
>>\
>> > +}
>>  \
>> > +
>>   \
>> > +atomic_fetch_add_explicit(##_staticpool_last, -1,
>> memory_order_relaxed); \
>> > +return av_malloc(sizeof(type));
>>  \
>> > +}
>>  \
>> > +
>>   \
>> > +static inline type *type##_staticpool_mallocz(void)
>>\
>> > +{
>>  \
>> > +type *ptr = type##_staticpool_malloc();
>>  \
>> > +if (ptr)
>>   \
>> > +memset(ptr, 0, sizeof(*ptr));
>>  \
>> > +return ptr;
>>  \
>> > +}
>>  \
>> > +
>>   \
>> > +static void type##_staticpool_free(type *ptr)
>>  \
>> > +{
>>  \
>> > +type##_StaticPoolWrapper *entry = (type##_StaticPoolWrapper *)
>> ptr; \
>> > +unsigned val, serial, index, new_val;
>>  \
>> > +
>>   \
>> > +if ((uintptr_t)ptr <= (uintptr_t)(type##_staticpool_table) ||
>>\
>> > +(uintptr_t)ptr >= (uintptr_t)(type##_staticpool_table +
>> size)) {\
>> > +av_free(ptr);
>> 

Re: [FFmpeg-devel] [PATCH 1/3] avutil: add staticpool

2018-01-20 Thread Rostislav Pehlivanov
On 20 January 2018 at 10:22, wm4  wrote:

> On Sat, 20 Jan 2018 11:29:13 +0700
> Muhammad Faiz  wrote:
>
> > Help avoiding malloc-free cycles when allocating-freeing common
> > structures.
> >
> > Signed-off-by: Muhammad Faiz 
> > ---
> >  libavutil/staticpool.h | 117 ++
> +++
> >  1 file changed, 117 insertions(+)
> >  create mode 100644 libavutil/staticpool.h
> >
> > diff --git a/libavutil/staticpool.h b/libavutil/staticpool.h
> > new file mode 100644
> > index 00..9c9b2784bc
> > --- /dev/null
> > +++ b/libavutil/staticpool.h
> > @@ -0,0 +1,117 @@
> > +/*
> > + * 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
> > + */
> > +
> > +#ifndef AVUTIL_STATICPOOL_H
> > +#define AVUTIL_STATICPOOL_H
> > +
> > +#include 
> > +#include "avassert.h"
> > +#include "mem.h"
> > +
> > +/**
> > + * FF_STATICPOOL allocate memory without av_malloc if possible
> > + * @param size must be 2^n between 64 and 4096
> > + */
> > +#define FF_STATICPOOL_DECLARE(type, size)
>  \
> > +typedef struct type##_StaticPoolWrapper {
>  \
> > +typebuf;
> \
> > +unsignedindex;
> \
> > +atomic_uint next;
>  \
> > +} type##_StaticPoolWrapper;
>  \
> > +
> \
> > +static atomic_uint  type##_staticpool_next;
>  \
> > +static atomic_uint  type##_staticpool_last;
>  \
> > +static type##_StaticPoolWrapper type##_staticpool_table[size];
> \
> > +
> \
> > +static type *type##_staticpool_malloc(void)
>  \
> > +{
>  \
> > +unsigned val, index, serial, new_val;
>  \
> > +
> \
> > +av_assert0((size) >= 64 && (size) <= 4096 && !((size) & ((size) -
> 1))); \
> > +
> \
> > +/* use serial, avoid spinlock */
> \
> > +/* acquire, so we don't get stalled table[index].next */
> \
> > +val = atomic_load_explicit(##_staticpool_next,
> memory_order_acquire);  \
> > +do {
> \
> > +index  = val & ((size) - 1);
> \
> > +serial = val & ~((size) - 1);
>  \
> > +new_val = 
> > atomic_load_explicit(##_staticpool_table[index].next,
> memory_order_relaxed) | (serial + (size)); \
> > +} while 
> > (!atomic_compare_exchange_strong_explicit(##_staticpool_next,
> , new_val, \
> > +
> memory_order_acquire, memory_order_acquire)); \
> > +
> \
> > +index = val & ((size) - 1);
>  \
> > +if (index)
> \
> > +return ##_staticpool_table[index].buf;
>  \
> > +
> \
> > +index = atomic_fetch_add_explicit(##_staticpool_last, 1,
> memory_order_relaxed) + 1; \
> > +if (index < (size)) {
>  \
> > +type##_staticpool_table[index].index = index;
>  \
> > +return ##_staticpool_table[index].buf;
>  \
> > +}
>  \
> > +
> \
> > +atomic_fetch_add_explicit(##_staticpool_last, -1,
> memory_order_relaxed); \
> > +return av_malloc(sizeof(type));
>  \
> > +}
>  \
> > +
> \
> > +static inline type *type##_staticpool_mallocz(void)
>  \
> > +{
>  \
> > +type *ptr = type##_staticpool_malloc();
>  \
> > +if (ptr)
> \
> > +memset(ptr, 0, sizeof(*ptr));
>  \
> > +return ptr;
>  \
> > +}
>  \
> > +
> \
> > +static void type##_staticpool_free(type *ptr)
>  \
> > +{
>  \
> > +type##_StaticPoolWrapper *entry = (type##_StaticPoolWrapper *)
> ptr; \
> > +unsigned val, serial, index, new_val;
>  \
> > +
> \
> > +if ((uintptr_t)ptr <= (uintptr_t)(type##_staticpool_table) ||
>  \
> > +(uintptr_t)ptr >= (uintptr_t)(type##_staticpool_table + size))
> {\
> > +av_free(ptr);
>  \
> > +return;
>  \
> > +}
>  \
> > +
> \
> > +if (CONFIG_MEMORY_POISONING)
> \
> > +memset(>buf, FF_MEMORY_POISON, sizeof(entry->buf));
> \
> > +
> \
> > +val = atomic_load_explicit(##_staticpool_next,
> 

Re: [FFmpeg-devel] [PATCH 1/3] avutil: add staticpool

2018-01-20 Thread Hendrik Leppkes
On Sat, Jan 20, 2018 at 11:22 AM, wm4  wrote:
> On Sat, 20 Jan 2018 11:29:13 +0700
> Muhammad Faiz  wrote:
>
>> Help avoiding malloc-free cycles when allocating-freeing common
>> structures.
>>
>> Signed-off-by: Muhammad Faiz 
>> ---
>>  libavutil/staticpool.h | 117 
>> +
>>  1 file changed, 117 insertions(+)
>>  create mode 100644 libavutil/staticpool.h
>>
>> diff --git a/libavutil/staticpool.h b/libavutil/staticpool.h
>> new file mode 100644
>> index 00..9c9b2784bc
>> --- /dev/null
>> +++ b/libavutil/staticpool.h
>> @@ -0,0 +1,117 @@
>> +/*
>> + * 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
>> + */
>> +
>> +#ifndef AVUTIL_STATICPOOL_H
>> +#define AVUTIL_STATICPOOL_H
>> +
>> +#include 
>> +#include "avassert.h"
>> +#include "mem.h"
>> +
>> +/**
>> + * FF_STATICPOOL allocate memory without av_malloc if possible
>> + * @param size must be 2^n between 64 and 4096
>> + */
>> +#define FF_STATICPOOL_DECLARE(type, size)   
>> \
>> +typedef struct type##_StaticPoolWrapper {   
>> \
>> +typebuf;
>> \
>> +unsignedindex;  
>> \
>> +atomic_uint next;   
>> \
>> +} type##_StaticPoolWrapper; 
>> \
>> +
>> \
>> +static atomic_uint  type##_staticpool_next; 
>> \
>> +static atomic_uint  type##_staticpool_last; 
>> \
>> +static type##_StaticPoolWrapper type##_staticpool_table[size];  
>> \
>> +
>> \
>> +static type *type##_staticpool_malloc(void) 
>> \
>> +{   
>> \
>> +unsigned val, index, serial, new_val;   
>> \
>> +
>> \
>> +av_assert0((size) >= 64 && (size) <= 4096 && !((size) & ((size) - 1))); 
>> \
>> +
>> \
>> +/* use serial, avoid spinlock */
>> \
>> +/* acquire, so we don't get stalled table[index].next */
>> \
>> +val = atomic_load_explicit(##_staticpool_next, 
>> memory_order_acquire);  \
>> +do {
>> \
>> +index  = val & ((size) - 1);
>> \
>> +serial = val & ~((size) - 1);   
>> \
>> +new_val = 
>> atomic_load_explicit(##_staticpool_table[index].next, 
>> memory_order_relaxed) | (serial + (size)); \
>> +} while 
>> (!atomic_compare_exchange_strong_explicit(##_staticpool_next, , 
>> new_val, \
>> +  memory_order_acquire, 
>> memory_order_acquire)); \
>> +
>> \
>> +index = val & ((size) - 1); 
>> \
>> +if (index)  
>> \
>> +return ##_staticpool_table[index].buf; 
>> \
>> +
>> \
>> +index = atomic_fetch_add_explicit(##_staticpool_last, 1, 
>> memory_order_relaxed) + 1; \
>> +if (index < (size)) {   
>> \
>> +type##_staticpool_table[index].index = index;   
>> \
>> +return ##_staticpool_table[index].buf; 
>> \
>> +} 

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mlp_parser: don't try to combine frames when full frames are provided

2018-01-20 Thread wm4
On Fri, 19 Jan 2018 20:30:59 -0300
James Almer  wrote:

> On 1/19/2018 5:06 PM, wm4 wrote:
> > On Fri, 19 Jan 2018 16:51:45 -0300
> > James Almer  wrote:
> >   
> >> Attempting full frame reconstruction is unnecessary for containers
> >> like Matroska, so just skip it altogether.
> >>
> >> Signed-off-by: James Almer 
> >> ---
> >>  libavcodec/mlp_parser.c | 4 
> >>  1 file changed, 4 insertions(+)
> >>
> >> diff --git a/libavcodec/mlp_parser.c b/libavcodec/mlp_parser.c
> >> index 3c0330f777..4827354f18 100644
> >> --- a/libavcodec/mlp_parser.c
> >> +++ b/libavcodec/mlp_parser.c
> >> @@ -256,6 +256,9 @@ static int mlp_parse(AVCodecParserContext *s,
> >>  if (buf_size == 0)
> >>  return 0;
> >>  
> >> +if (s->flags & PARSER_FLAG_COMPLETE_FRAMES) {
> >> +next = buf_size;
> >> +} else {
> >>  if (!mp->in_sync) {
> >>  // Not in sync - find a major sync header
> >>  
> >> @@ -315,6 +318,7 @@ static int mlp_parse(AVCodecParserContext *s,
> >>  }
> >>  
> >>  mp->bytes_left = 0;
> >> +}
> >>  
> >>  sync_present = (AV_RB32(buf + 4) & 0xfffe) == 0xf8726fba;
> >>
> > 
> > Not so sure about this. I think some mkv TrueHD files contain packets
> > that are not properly starting on frame boundaries. But I don't really
> > remember.  
> 
> As in badly muxed files? Couldn't the same thing happen with any other
> codec? We're not bothering to consider such cases in other parses as far
> as i could see.

From my hazy memory, this also happened with mp3, although the Matroska
demuxer explicitly forces full parsing for that codec.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/3] avutil: add staticpool

2018-01-20 Thread wm4
On Sat, 20 Jan 2018 11:29:13 +0700
Muhammad Faiz  wrote:

> Help avoiding malloc-free cycles when allocating-freeing common
> structures.
> 
> Signed-off-by: Muhammad Faiz 
> ---
>  libavutil/staticpool.h | 117 
> +
>  1 file changed, 117 insertions(+)
>  create mode 100644 libavutil/staticpool.h
> 
> diff --git a/libavutil/staticpool.h b/libavutil/staticpool.h
> new file mode 100644
> index 00..9c9b2784bc
> --- /dev/null
> +++ b/libavutil/staticpool.h
> @@ -0,0 +1,117 @@
> +/*
> + * 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
> + */
> +
> +#ifndef AVUTIL_STATICPOOL_H
> +#define AVUTIL_STATICPOOL_H
> +
> +#include 
> +#include "avassert.h"
> +#include "mem.h"
> +
> +/**
> + * FF_STATICPOOL allocate memory without av_malloc if possible
> + * @param size must be 2^n between 64 and 4096
> + */
> +#define FF_STATICPOOL_DECLARE(type, size)
>\
> +typedef struct type##_StaticPoolWrapper {
>\
> +typebuf; 
>\
> +unsignedindex;   
>\
> +atomic_uint next;
>\
> +} type##_StaticPoolWrapper;  
>\
> + 
>\
> +static atomic_uint  type##_staticpool_next;  
>\
> +static atomic_uint  type##_staticpool_last;  
>\
> +static type##_StaticPoolWrapper type##_staticpool_table[size];   
>\
> + 
>\
> +static type *type##_staticpool_malloc(void)  
>\
> +{
>\
> +unsigned val, index, serial, new_val;
>\
> + 
>\
> +av_assert0((size) >= 64 && (size) <= 4096 && !((size) & ((size) - 1)));  
>\
> + 
>\
> +/* use serial, avoid spinlock */ 
>\
> +/* acquire, so we don't get stalled table[index].next */ 
>\
> +val = atomic_load_explicit(##_staticpool_next, 
> memory_order_acquire);  \
> +do { 
>\
> +index  = val & ((size) - 1); 
>\
> +serial = val & ~((size) - 1);
>\
> +new_val = atomic_load_explicit(##_staticpool_table[index].next, 
> memory_order_relaxed) | (serial + (size)); \
> +} while 
> (!atomic_compare_exchange_strong_explicit(##_staticpool_next, , 
> new_val, \
> +  memory_order_acquire, 
> memory_order_acquire)); \
> + 
>\
> +index = val & ((size) - 1);  
>\
> +if (index)   
>\
> +return ##_staticpool_table[index].buf;  
>\
> + 
>\
> +index = atomic_fetch_add_explicit(##_staticpool_last, 1, 
> memory_order_relaxed) + 1; \
> +if (index < (size)) {
>\
> +type##_staticpool_table[index].index = index;
>\
> +return ##_staticpool_table[index].buf;  
>\
> +}
>\
> + 
>\
> +

Re: [FFmpeg-devel] [PATCH 1/3] avutil: add staticpool

2018-01-20 Thread wm4
On Sat, 20 Jan 2018 12:52:46 +0700
Muhammad Faiz  wrote:

> On Sat, Jan 20, 2018 at 11:49 AM, James Almer  wrote:
> > On 1/20/2018 1:29 AM, Muhammad Faiz wrote:  
> >> Help avoiding malloc-free cycles when allocating-freeing common
> >> structures.
> >>
> >> Signed-off-by: Muhammad Faiz 
> >> ---
> >>  libavutil/staticpool.h | 117 
> >> +
> >>  1 file changed, 117 insertions(+)
> >>  create mode 100644 libavutil/staticpool.h
> >>
> >> diff --git a/libavutil/staticpool.h b/libavutil/staticpool.h
> >> new file mode 100644
> >> index 00..9c9b2784bc
> >> --- /dev/null
> >> +++ b/libavutil/staticpool.h
> >> @@ -0,0 +1,117 @@
> >> +/*
> >> + * 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
> >> + */
> >> +
> >> +#ifndef AVUTIL_STATICPOOL_H
> >> +#define AVUTIL_STATICPOOL_H
> >> +
> >> +#include 
> >> +#include "avassert.h"
> >> +#include "mem.h"
> >> +
> >> +/**
> >> + * FF_STATICPOOL allocate memory without av_malloc if possible
> >> + * @param size must be 2^n between 64 and 4096
> >> + */
> >> +#define FF_STATICPOOL_DECLARE(type, size) 
> >>   \
> >> +typedef struct type##_StaticPoolWrapper { 
> >>   \
> >> +typebuf;  
> >>   \
> >> +unsignedindex;
> >>   \
> >> +atomic_uint next; 
> >>   \
> >> +} type##_StaticPoolWrapper;   
> >>   \
> >> +  
> >>   \
> >> +static atomic_uint  type##_staticpool_next;   
> >>   \
> >> +static atomic_uint  type##_staticpool_last;   
> >>   \
> >> +static type##_StaticPoolWrapper type##_staticpool_table[size];
> >>   \
> >> +  
> >>   \
> >> +static type *type##_staticpool_malloc(void)   
> >>   \
> >> +{ 
> >>   \
> >> +unsigned val, index, serial, new_val; 
> >>   \
> >> +  
> >>   \
> >> +av_assert0((size) >= 64 && (size) <= 4096 && !((size) & ((size) - 
> >> 1))); \
> >> +  
> >>   \
> >> +/* use serial, avoid spinlock */  
> >>   \
> >> +/* acquire, so we don't get stalled table[index].next */  
> >>   \
> >> +val = atomic_load_explicit(##_staticpool_next, 
> >> memory_order_acquire);  \
> >> +do {  
> >>   \
> >> +index  = val & ((size) - 1);  
> >>   \
> >> +serial = val & ~((size) - 1); 
> >>   \
> >> +new_val = 
> >> atomic_load_explicit(##_staticpool_table[index].next, 
> >> memory_order_relaxed) | (serial + (size)); \
> >> +} while 
> >> (!atomic_compare_exchange_strong_explicit(##_staticpool_next, , 
> >> new_val, \  
> >
> > The wrappers for atomic_compare_exchange_* in the compat folder are not
> > really working and fixing them is supposedly not trivial, so this will
> > only work with GCC and Clang but not with for example MSVC or SunCC.  
> 
> What's the problem? I only see that stdatomic compat make typedef
> every atomic type to intptr_t, so atomic_*64_t won't work if
> sizeof(intptr_t) == 32.
> Here I use atomic_uint, so I guess it will work.
> 
> Note that if atomic_compare_exchange_* is broken then atomic_fetch_*
> will also be broken because atomic_fetch_* call
> atomic_compare_exchange_* on suncc compat.
> 
> >
> > Can you implement this using mutexes instead, or otherwise avoid using

[FFmpeg-devel] [PATCH] avfilter/vf_framerate: fix cpy_line_width calculation on >8 bits format

2018-01-20 Thread Muhammad Faiz
Fix tsan warnings on fate-filter-framerate-12bit-down and
fate-filter-framerate-12bit-up.

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

diff --git a/libavfilter/vf_framerate.c b/libavfilter/vf_framerate.c
index a5ae6ddb71..578acaae52 100644
--- a/libavfilter/vf_framerate.c
+++ b/libavfilter/vf_framerate.c
@@ -240,7 +240,7 @@ static int filter_slice16(AVFilterContext *ctx, void *arg, 
int job, int nb_jobs)
 int plane, line, pixel;
 
 for (plane = 0; plane < 4 && td->copy_src1->data[plane] && 
td->copy_src2->data[plane]; plane++) {
-int cpy_line_width = s->line_size[plane];
+int cpy_line_width = s->line_size[plane] / 2;
 const uint16_t *cpy_src1_data = (const uint16_t 
*)td->copy_src1->data[plane];
 int cpy_src1_line_size = td->copy_src1->linesize[plane] / 2;
 const uint16_t *cpy_src2_data = (const uint16_t 
*)td->copy_src2->data[plane];
-- 
2.13.2

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