[FFmpeg-devel] [PATCH 2/3 v2] avformat/matroskadec: support parsing Chroma Location elements

[James Almer]

Signed-off-by: James Almer 
---
 libavformat/matroska.h| 14 ++
 libavformat/matroskadec.c |  7 +++
 2 files changed, 21 insertions(+)

diff --git a/libavformat/matroska.h b/libavformat/matroska.h
index 8ad89da..13155e5 100644
--- a/libavformat/matroska.h
+++ b/libavformat/matroska.h
@@ -317,6 +317,20 @@ typedef enum {
   MATROSKA_VIDEO_DISPLAYUNIT_UNKNOWN = 4,
 } MatroskaVideoDisplayUnit;
 
+typedef enum {
+  MATROSKA_COLOUR_CHROMASITINGHORZ_UNDETERMINED = 0,
+  MATROSKA_COLOUR_CHROMASITINGHORZ_LEFT = 1,
+  MATROSKA_COLOUR_CHROMASITINGHORZ_HALF = 2,
+  MATROSKA_COLOUR_CHROMASITINGHORZ_NB
+} MatroskaColourChromaSitingHorz;
+
+typedef enum {
+  MATROSKA_COLOUR_CHROMASITINGVERT_UNDETERMINED = 0,
+  MATROSKA_COLOUR_CHROMASITINGVERT_TOP  = 1,
+  MATROSKA_COLOUR_CHROMASITINGVERT_HALF = 2,
+  MATROSKA_COLOUR_CHROMASITINGVERT_NB
+} MatroskaColourChromaSitingVert;
+
 /*
  * Matroska Codec IDs, strings
  */
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index a5d3c0e..722d0b0 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1827,6 +1827,13 @@ static int mkv_parse_video_color(AVStream *st, const 
MatroskaTrack *track) {
 if (track->video.color.range != AVCOL_RANGE_UNSPECIFIED &&
 track->video.color.range <= AVCOL_RANGE_JPEG)
 st->codecpar->color_range = track->video.color.range;
+if (track->video.color.chroma_siting_horz && 
track->video.color.chroma_siting_vert &&
+track->video.color.chroma_siting_horz < 
MATROSKA_COLOUR_CHROMASITINGHORZ_NB &&
+track->video.color.chroma_siting_vert < 
MATROSKA_COLOUR_CHROMASITINGVERT_NB) {
+st->codecpar->chroma_location =
+avcodec_chroma_pos_to_enum((track->video.color.chroma_siting_horz 
- 1) << 7,
+   (track->video.color.chroma_siting_vert 
- 1) << 7);
+}
 
 if (has_mastering_primaries || has_mastering_luminance) {
 // Use similar rationals as other standards.
-- 
2.9.1

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

[FFmpeg-devel] [PATCH] doc/examples/demuxing_decoding: Drop AVFrame->pts use

[Michael Niedermayer]

This code is not correct for git master

Signed-off-by: Michael Niedermayer 
---
 doc/examples/demuxing_decoding.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/doc/examples/demuxing_decoding.c b/doc/examples/demuxing_decoding.c
index 49fb6af..b1a216a 100644
--- a/doc/examples/demuxing_decoding.c
+++ b/doc/examples/demuxing_decoding.c
@@ -93,10 +93,9 @@ static int decode_packet(int *got_frame, int cached)
 return -1;
 }
 
-printf("video_frame%s n:%d coded_n:%d pts:%s\n",
+printf("video_frame%s n:%d coded_n:%d\n",
cached ? "(cached)" : "",
-   video_frame_count++, frame->coded_picture_number,
-   av_ts2timestr(frame->pts, _dec_ctx->time_base));
+   video_frame_count++, frame->coded_picture_number);
 
 /* copy decoded frame to destination buffer:
  * this is required since rawvideo expects non aligned data */
-- 
2.10.1

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

Re: [FFmpeg-devel] [PATCH 2/3] avformat/matroskadec: support parsing Chroma Location elements

[James Almer]

On 10/17/2016 10:00 PM, Michael Niedermayer wrote:
> On Sat, Oct 15, 2016 at 12:40:55PM -0300, James Almer wrote:
>> Signed-off-by: James Almer 
>> ---
>>  libavformat/matroskadec.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
>> index acf1ccb..cfe4692 100644
>> --- a/libavformat/matroskadec.c
>> +++ b/libavformat/matroskadec.c
>> @@ -1826,6 +1826,10 @@ static int mkv_parse_video_color(AVStream *st, const 
>> MatroskaTrack *track) {
>>  if (track->video.color.range != AVCOL_RANGE_UNSPECIFIED &&
>>  track->video.color.range <= AVCOL_RANGE_JPEG)
>>  st->codecpar->color_range = track->video.color.range;
>> +if (track->video.color.chroma_siting_horz && 
>> track->video.color.chroma_siting_vert)
>> +st->codecpar->chroma_location =
>> +
>> avcodec_chroma_pos_to_enum((track->video.color.chroma_siting_horz - 1) << 7,
>> +   
>> (track->video.color.chroma_siting_vert - 1) << 7);
> 
> does this need some validity check ? (i didnt immedeatly see any check)
> << 7 could overflow without check

avcodec_chroma_pos_to_enum() will return AVCHROMA_LOC_UNSPECIFIED if
either xpos or ypos have bad values, so even if it overflows it wouldn't
be a problem.
The spec doesn't specify a range for the elements, but currently values
0 (Unspecified), 1 (Left/Top Collocated) and 2 (Half) are the only valid
ones. I guess 3 may be added in the future, at least for ChromaSitingVert
to represent bottom based on our AVChromaLocation enum values.

In any case, I'll add some range checks for both elements to be safe.

> 
> [...]
> 
> 
> 
> ___
> 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/http.c: Add listen_timeout option.

[Stephan Holljes]

On Tue, Oct 18, 2016 at 2:09 AM, Stephan Holljes
 wrote:
> ---
>  libavformat/http.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/libavformat/http.c b/libavformat/http.c
> index d48958d..3b0d6ab 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -115,6 +115,7 @@ typedef struct HTTPContext {
>  int reconnect_delay;
>  int reconnect_delay_max;
>  int listen;
> +int listen_timeout;
>  char *resource;
>  int reply_code;
>  int is_multi_client;
> @@ -158,6 +159,7 @@ static const AVOption options[] = {
>  { "reconnect_streamed", "auto reconnect streamed / non seekable 
> streams", OFFSET(reconnect_streamed), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, D 
> },
>  { "reconnect_delay_max", "max reconnect delay in seconds after which to 
> give up", OFFSET(reconnect_delay_max), AV_OPT_TYPE_INT, { .i64 = 120 }, 0, 
> UINT_MAX/1000/1000, D },
>  { "listen", "listen on HTTP", OFFSET(listen), AV_OPT_TYPE_INT, { .i64 = 
> 0 }, 0, 2, D | E },
> +{ "listen_timeout",  "Connection awaiting timeout (in milliseconds)",
>   OFFSET(listen_timeout), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 
> INT_MAX, .flags = D|E },
>  { "resource", "The resource requested by a client", OFFSET(resource), 
> AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, E },
>  { "reply_code", "The http status code to return to a client", 
> OFFSET(reply_code), AV_OPT_TYPE_INT, { .i64 = 200}, INT_MIN, 599, E},
>  { NULL }
> @@ -463,6 +465,9 @@ static int http_listen(URLContext *h, const char *uri, 
> int flags,
>  NULL);
>  if ((ret = av_dict_set_int(options, "listen", s->listen, 0)) < 0)
>  goto fail;
> +if ((ret = av_dict_set_int(options, "listen_timeout", s->listen_timeout, 
> 0)) < 0)
> +goto fail;
> +
>  if ((ret = ffurl_open_whitelist(>hd, lower_url, AVIO_FLAG_READ_WRITE,
>  >interrupt_callback, options,
>  h->protocol_whitelist, 
> h->protocol_blacklist, h
> --
> 2.5.5
>

Disregard this patch. I was producing buggy application code and
thought this was necessary. (Options are passed down to lower
protocols and threads make things weird...).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] fate: add loudnorm filter test

[Michael Niedermayer]

On Tue, Oct 18, 2016 at 02:20:03AM +0200, Marton Balint wrote:
> 
> On Tue, 18 Oct 2016, Michael Niedermayer wrote:
> 
> >On Sun, Oct 16, 2016 at 10:12:17PM +0200, Marton Balint wrote:
> >>
> >>On Sun, 16 Oct 2016, Marton Balint wrote:
> >>
> >>>Signed-off-by: Marton Balint 
> >>>---
> >>>tests/fate/filter-audio.mak | 7 +++
> >>>1 file changed, 7 insertions(+)
> >>>
> >>>diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
> >>>index 9c6f7cd..d376f25 100644
> >>>--- a/tests/fate/filter-audio.mak
> >>>+++ b/tests/fate/filter-audio.mak
> >>>@@ -279,6 +279,13 @@ fate-filter-hdcd-detect-errors: CMD = md5 -i $(SRC) 
> >>>-af hdcd -f s24le
> >>>fate-filter-hdcd-detect-errors: CMP = grep
> >>>fate-filter-hdcd-detect-errors: REF = detectable errors: [1-9]
> >>>
> >>>+FATE_AFILTER-$(call FILTERDEMDECENCMUX, LOUDNORM, AAC, AAC, PCM_S16LE, 
> >>>PCM_S16LE) += fate-filter-loudnorm-simple
> >>>+fate-filter-loudnorm-simple: SRC = $(SAMPLES)/aac/sintel.aac
> >>>+fate-filter-loudnorm-simple: CMD = ffmpeg -t 30 -i $(SRC) -af 
> >>>loudnorm=i=-23 -f s16le -ar 44100 -
> >>>+fate-filter-loudnorm-simple: REF = $(SAMPLES)/filter/loudnorm-simple.pcm
> >>>+fate-filter-loudnorm-simple: CMP = oneoff
> >>>+fate-filter-loudnorm-simple: CMP_UNIT = s16
> >>>+
> >>
> >>This patch needs two files in the fate samples:
> >>
> >>The audio part of the Sintel movie, as a source, because I wanted to
> >>test with a real world example, with proper length. And the
> >>reference file. Sources can be generated like this:
> >>
> >>wget http://media.xiph.org/sintel/sintel-master-st.flac
> >>ffmpeg -i sintel-master-st.flac -codec aac -b 96k fate-suite/aac/sintel.aac
> >>ffmpeg -t 30 -i fate-suite/aac/sintel.aac -af loudnorm=i=-23 -f s16le -ar 
> >>44100 fate-suite/filter/loudnorm-simple.pcm
> >>
> >>Due to the 96k AAC codec, sintel.aac is about 15M,
> >
> >are low bitrate speech codecs unsuitable instead of aac for this ?
> >that would cut the size down by alot
> 
> In theory, maybe, on the other hand, we are only using the first 30
> second of the sample, so if size is an issue, we can reduce it to
> around 500k and the fate test will still work.
> 
> Since the reference file alone is 6M, it does not seem to make too
> much difference if the sample is 500k, or less, so I'd prefer the
> normal codec. I am not sure I can give you a pure technical
> reasoning, the only thing I could think of is that as far as I know
> a speech codec is usually not good at very low or very high

> frequencies, but it is a good idea to test loudness measurement with
> all kind of frequencies, because of it's frequency dependant
> filters.

a synthetic sample that contains a sine sweep would excercise all
frequencies
tests/audiogen would need very little space to generate such sample
but i dont know if its worse for testing ?

also is using a PCM file optimal as reference ?
it may be hard to understand from the psnr difference what exactly
changed if some code change triggers a change in the output.
and also if the code is changed to require a new reference in the
future we would need to keep multiple reference files

either way, if you say that these files are the best solution then ill
upload them (assuming the new fate tests pass, didnt try yet)

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

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


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

Re: [FFmpeg-devel] [PATCH 1/2] compat/avisynth: minor update for alpha offsets

[Stephen Hutchinson]

On 9/27/2016 10:07 PM, Stephen Hutchinson wrote:

On 9/27/2016 4:11 PM, Michael Niedermayer wrote:

can you update the status for the patch(es) on
https://patchwork.ffmpeg.org/project/ffmpeg/list/?submitter=49
?

so developers know what needs a review, needs to be applied and what
is on hold/revovked, ...

thx



Done.  I think I did it right, hopefully.


Since there haven't been any responses, I've changed the status on
the Planar RGB fix patch on Patchwork to Accepted (which I assume is
what says it needs to be applied).  This should definitely go in before
3.2 is split off.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/tests/gitignore: add fifo_muxer entry

[Michael Niedermayer]

On Mon, Oct 17, 2016 at 01:38:24PM +0200, Jan Sebechlebsky wrote:
> On 10/15/2016 06:32 PM, Zhao Zhili wrote:
> 
> > From a3ee9afc37331315e4ec57f1ebf881779b62bf60 Mon Sep 17 00:00:00 2001
> >From: Zhao Zhili 
> >Date: Sun, 16 Oct 2016 00:09:25 +0800
> >Subject: [PATCH] avformat/tests/gitignore: add fifo_muxer entry
> >
> >---
> >  libavformat/tests/.gitignore | 1 +
> >  1 file changed, 1 insertion(+)
> >
> >diff --git a/libavformat/tests/.gitignore b/libavformat/tests/.gitignore
> >index c8adb86..7ceb7a3 100644
> >--- a/libavformat/tests/.gitignore
> >+++ b/libavformat/tests/.gitignore
> >@@ -1,3 +1,4 @@
> >+/fifo_muxer
> >  /movenc
> >  /noproxy
> >  /rtmpdh
> LGTM, thanks!

applied

thx

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

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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

Re: [FFmpeg-devel] [PATCH] lavc/videotoolboxenc: implement a53cc

[Aman Gupta]

On Mon, Oct 17, 2016 at 5:51 PM, Richard Kern  wrote:

>
> On Oct 17, 2016, at 8:47 PM, Aman Gupta  wrote:
>
>
>
> On Mon, Oct 17, 2016 at 6:35 AM, Richard Kern  wrote:
>
>>
>> On Sep 19, 2016, at 10:30 AM, Aman Gupta  wrote:
>>
>>
>>
>> On Monday, September 19, 2016, Richard Kern  wrote:
>>
>>>
>>> On Sep 10, 2016, at 10:33 PM, Aman Gupta  wrote:
>>>
>>>
>>>
>>> On Sunday, September 11, 2016, Richard Kern  wrote:
>>>

 > On Sep 8, 2016, at 4:19 AM, Aman Gupta  wrote:
 >
 > From: Aman Gupta 
 >
 > ---
 > libavcodec/videotoolboxenc.c | 76 ++
 --
 > 1 file changed, 67 insertions(+), 9 deletions(-)
 >
 > diff --git a/libavcodec/videotoolboxenc.c
 b/libavcodec/videotoolboxenc.c
 > index 4345ca3..859dde9 100644
 > --- a/libavcodec/videotoolboxenc.c
 > +++ b/libavcodec/videotoolboxenc.c
 > @@ -32,6 +32,7 @@
 > #include "libavutil/pixdesc.h"
 > #include "internal.h"
 > #include 
 > +#include "h264.h"
 >
 > #if !CONFIG_VT_BT2020
 > # define kCVImageBufferColorPrimaries_ITU_R_2020
  CFSTR("ITU_R_2020")
 > @@ -55,8 +56,14 @@ typedef enum VTH264Entropy{
 >
 > static const uint8_t start_code[] = { 0, 0, 0, 1 };
 >
 > +typedef struct ExtraSEI {
 > +  void *data;
 > +  size_t size;
 > +} ExtraSEI;
 > +
 > typedef struct BufNode {
 > CMSampleBufferRef cm_buffer;
 > +ExtraSEI *sei;
 > struct BufNode* next;
 > int error;
 > } BufNode;
 > @@ -94,6 +101,7 @@ typedef struct VTEncContext {
 > bool flushing;
 > bool has_b_frames;
 > bool warned_color_range;
 > +bool a53_cc;
 > } VTEncContext;
 >
 > static int vtenc_populate_extradata(AVCodecContext   *avctx,
 > @@ -136,7 +144,7 @@ static void set_async_error(VTEncContext *vtctx,
 int err)
 > pthread_mutex_unlock(>lock);
 > }
 >
 > -static int vtenc_q_pop(VTEncContext *vtctx, bool wait,
 CMSampleBufferRef *buf)
 > +static int vtenc_q_pop(VTEncContext *vtctx, bool wait,
 CMSampleBufferRef *buf, ExtraSEI **sei)
 > {
 > BufNode *info;
 >
 > @@ -173,6 +181,12 @@ static int vtenc_q_pop(VTEncContext *vtctx, bool
 wait, CMSampleBufferRef *buf)
 > pthread_mutex_unlock(>lock);
 >
 > *buf = info->cm_buffer;
 > +if (sei && *buf) {
 > +*sei = info->sei;
 > +} else if (info->sei) {
 > +if (info->sei->data) av_free(info->sei->data);
 > +av_free(info->sei);
 > +}
 > av_free(info);
 >
 > vtctx->frame_ct_out++;
 > @@ -180,7 +194,7 @@ static int vtenc_q_pop(VTEncContext *vtctx, bool
 wait, CMSampleBufferRef *buf)
 > return 0;
 > }
 >
 > -static void vtenc_q_push(VTEncContext *vtctx, CMSampleBufferRef
 buffer)
 > +static void vtenc_q_push(VTEncContext *vtctx, CMSampleBufferRef
 buffer, ExtraSEI *sei)
 > {
 > BufNode *info = av_malloc(sizeof(BufNode));
 > if (!info) {
 > @@ -190,6 +204,7 @@ static void vtenc_q_push(VTEncContext *vtctx,
 CMSampleBufferRef buffer)
 >
 > CFRetain(buffer);
 > info->cm_buffer = buffer;
 > +info->sei = sei;
 > info->next = NULL;
 >
 > pthread_mutex_lock(>lock);
 > @@ -420,6 +435,7 @@ static void vtenc_output_callback(
 > {
 > AVCodecContext *avctx = ctx;
 > VTEncContext   *vtctx = avctx->priv_data;
 > +ExtraSEI *sei = sourceFrameCtx;
 >
 > if (vtctx->async_error) {
 > if(sample_buffer) CFRelease(sample_buffer);
 > @@ -440,7 +456,7 @@ static void vtenc_output_callback(
 > }
 > }
 >
 > -vtenc_q_push(vtctx, sample_buffer);
 > +vtenc_q_push(vtctx, sample_buffer, sei);
 > }
 >
 > static int get_length_code_size(
 > @@ -1258,7 +1274,8 @@ static int copy_replace_length_codes(
 > static int vtenc_cm_to_avpacket(
 > AVCodecContext*avctx,
 > CMSampleBufferRef sample_buffer,
 > -AVPacket  *pkt)
 > +AVPacket  *pkt,
 > +ExtraSEI  *sei)
 > {
 > VTEncContext *vtctx = avctx->priv_data;
 >
 > @@ -1269,6 +1286,7 @@ static int vtenc_cm_to_avpacket(
 > size_t  header_size = 0;
 > size_t  in_buf_size;
 > size_t  out_buf_size;
 > +size_t  sei_nalu_size = 0;
 > int64_t dts_delta;
 > int64_t time_base_num;
 > int nalu_count;
 > @@ -1298,9 +1316,14 @@ static int vtenc_cm_to_avpacket(
 > if(status)
 > return status;
 >
 > +if (sei) {
 > +sei_nalu_size = sizeof(start_code) + 3 + sei->size + 1;
 > +}

Re: [FFmpeg-devel] [PATCH] lavc/videotoolboxenc: implement a53cc

[Aman Gupta]

On Mon, Oct 17, 2016 at 6:35 AM, Richard Kern  wrote:

>
> On Sep 19, 2016, at 10:30 AM, Aman Gupta  wrote:
>
>
>
> On Monday, September 19, 2016, Richard Kern  wrote:
>
>>
>> On Sep 10, 2016, at 10:33 PM, Aman Gupta  wrote:
>>
>>
>>
>> On Sunday, September 11, 2016, Richard Kern  wrote:
>>
>>>
>>> > On Sep 8, 2016, at 4:19 AM, Aman Gupta  wrote:
>>> >
>>> > From: Aman Gupta 
>>> >
>>> > ---
>>> > libavcodec/videotoolboxenc.c | 76 ++
>>> --
>>> > 1 file changed, 67 insertions(+), 9 deletions(-)
>>> >
>>> > diff --git a/libavcodec/videotoolboxenc.c
>>> b/libavcodec/videotoolboxenc.c
>>> > index 4345ca3..859dde9 100644
>>> > --- a/libavcodec/videotoolboxenc.c
>>> > +++ b/libavcodec/videotoolboxenc.c
>>> > @@ -32,6 +32,7 @@
>>> > #include "libavutil/pixdesc.h"
>>> > #include "internal.h"
>>> > #include 
>>> > +#include "h264.h"
>>> >
>>> > #if !CONFIG_VT_BT2020
>>> > # define kCVImageBufferColorPrimaries_ITU_R_2020   CFSTR("ITU_R_2020")
>>> > @@ -55,8 +56,14 @@ typedef enum VTH264Entropy{
>>> >
>>> > static const uint8_t start_code[] = { 0, 0, 0, 1 };
>>> >
>>> > +typedef struct ExtraSEI {
>>> > +  void *data;
>>> > +  size_t size;
>>> > +} ExtraSEI;
>>> > +
>>> > typedef struct BufNode {
>>> > CMSampleBufferRef cm_buffer;
>>> > +ExtraSEI *sei;
>>> > struct BufNode* next;
>>> > int error;
>>> > } BufNode;
>>> > @@ -94,6 +101,7 @@ typedef struct VTEncContext {
>>> > bool flushing;
>>> > bool has_b_frames;
>>> > bool warned_color_range;
>>> > +bool a53_cc;
>>> > } VTEncContext;
>>> >
>>> > static int vtenc_populate_extradata(AVCodecContext   *avctx,
>>> > @@ -136,7 +144,7 @@ static void set_async_error(VTEncContext *vtctx,
>>> int err)
>>> > pthread_mutex_unlock(>lock);
>>> > }
>>> >
>>> > -static int vtenc_q_pop(VTEncContext *vtctx, bool wait,
>>> CMSampleBufferRef *buf)
>>> > +static int vtenc_q_pop(VTEncContext *vtctx, bool wait,
>>> CMSampleBufferRef *buf, ExtraSEI **sei)
>>> > {
>>> > BufNode *info;
>>> >
>>> > @@ -173,6 +181,12 @@ static int vtenc_q_pop(VTEncContext *vtctx, bool
>>> wait, CMSampleBufferRef *buf)
>>> > pthread_mutex_unlock(>lock);
>>> >
>>> > *buf = info->cm_buffer;
>>> > +if (sei && *buf) {
>>> > +*sei = info->sei;
>>> > +} else if (info->sei) {
>>> > +if (info->sei->data) av_free(info->sei->data);
>>> > +av_free(info->sei);
>>> > +}
>>> > av_free(info);
>>> >
>>> > vtctx->frame_ct_out++;
>>> > @@ -180,7 +194,7 @@ static int vtenc_q_pop(VTEncContext *vtctx, bool
>>> wait, CMSampleBufferRef *buf)
>>> > return 0;
>>> > }
>>> >
>>> > -static void vtenc_q_push(VTEncContext *vtctx, CMSampleBufferRef
>>> buffer)
>>> > +static void vtenc_q_push(VTEncContext *vtctx, CMSampleBufferRef
>>> buffer, ExtraSEI *sei)
>>> > {
>>> > BufNode *info = av_malloc(sizeof(BufNode));
>>> > if (!info) {
>>> > @@ -190,6 +204,7 @@ static void vtenc_q_push(VTEncContext *vtctx,
>>> CMSampleBufferRef buffer)
>>> >
>>> > CFRetain(buffer);
>>> > info->cm_buffer = buffer;
>>> > +info->sei = sei;
>>> > info->next = NULL;
>>> >
>>> > pthread_mutex_lock(>lock);
>>> > @@ -420,6 +435,7 @@ static void vtenc_output_callback(
>>> > {
>>> > AVCodecContext *avctx = ctx;
>>> > VTEncContext   *vtctx = avctx->priv_data;
>>> > +ExtraSEI *sei = sourceFrameCtx;
>>> >
>>> > if (vtctx->async_error) {
>>> > if(sample_buffer) CFRelease(sample_buffer);
>>> > @@ -440,7 +456,7 @@ static void vtenc_output_callback(
>>> > }
>>> > }
>>> >
>>> > -vtenc_q_push(vtctx, sample_buffer);
>>> > +vtenc_q_push(vtctx, sample_buffer, sei);
>>> > }
>>> >
>>> > static int get_length_code_size(
>>> > @@ -1258,7 +1274,8 @@ static int copy_replace_length_codes(
>>> > static int vtenc_cm_to_avpacket(
>>> > AVCodecContext*avctx,
>>> > CMSampleBufferRef sample_buffer,
>>> > -AVPacket  *pkt)
>>> > +AVPacket  *pkt,
>>> > +ExtraSEI  *sei)
>>> > {
>>> > VTEncContext *vtctx = avctx->priv_data;
>>> >
>>> > @@ -1269,6 +1286,7 @@ static int vtenc_cm_to_avpacket(
>>> > size_t  header_size = 0;
>>> > size_t  in_buf_size;
>>> > size_t  out_buf_size;
>>> > +size_t  sei_nalu_size = 0;
>>> > int64_t dts_delta;
>>> > int64_t time_base_num;
>>> > int nalu_count;
>>> > @@ -1298,9 +1316,14 @@ static int vtenc_cm_to_avpacket(
>>> > if(status)
>>> > return status;
>>> >
>>> > +if (sei) {
>>> > +sei_nalu_size = sizeof(start_code) + 3 + sei->size + 1;
>>> > +}
>>> > +
>>> > in_buf_size = CMSampleBufferGetTotalSampleSize(sample_buffer);
>>> > out_buf_size = header_size +
>>> >in_buf_size +
>>> > +   sei_nalu_size +
>>> >nalu_count * ((int)sizeof(start_code) -
>>> (int)length_code_size);
>>> >
>>> > 

Re: [FFmpeg-devel] [PATCH 1/2] avformat/mov: zero initialize codec_name in mov_parse_stsd_video()

[Michael Niedermayer]

On Sun, Oct 16, 2016 at 09:34:50PM -0300, James Almer wrote:
> Fixes valgrind warning about "Conditional jump or move depends on 
> uninitialised value(s)"
> 
> Signed-off-by: James Almer 
> ---
>  libavformat/mov.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

This should be suppressable by adding it to
tests/fate-valgrind.supp

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA


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

Re: [FFmpeg-devel] [PATCH] lavc/videotoolboxenc: implement a53cc

[Richard Kern]

> On Oct 17, 2016, at 8:47 PM, Aman Gupta  wrote:
> 
> 
> 
> On Mon, Oct 17, 2016 at 6:35 AM, Richard Kern  > wrote:
> 
>> On Sep 19, 2016, at 10:30 AM, Aman Gupta > > wrote:
>> 
>> 
>> 
>> On Monday, September 19, 2016, Richard Kern > > wrote:
>> 
>>> On Sep 10, 2016, at 10:33 PM, Aman Gupta > wrote:
>>> 
>>> 
>>> 
>>> On Sunday, September 11, 2016, Richard Kern > wrote:
>>> 
>>> > On Sep 8, 2016, at 4:19 AM, Aman Gupta > wrote:
>>> >
>>> > From: Aman Gupta >
>>> >
>>> > ---
>>> > libavcodec/videotoolboxenc.c | 76 
>>> > ++--
>>> > 1 file changed, 67 insertions(+), 9 deletions(-)
>>> >
>>> > diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
>>> > index 4345ca3..859dde9 100644
>>> > --- a/libavcodec/videotoolboxenc.c
>>> > +++ b/libavcodec/videotoolboxenc.c
>>> > @@ -32,6 +32,7 @@
>>> > #include "libavutil/pixdesc.h"
>>> > #include "internal.h"
>>> > #include 
>>> > +#include "h264.h"
>>> >
>>> > #if !CONFIG_VT_BT2020
>>> > # define kCVImageBufferColorPrimaries_ITU_R_2020   CFSTR("ITU_R_2020")
>>> > @@ -55,8 +56,14 @@ typedef enum VTH264Entropy{
>>> >
>>> > static const uint8_t start_code[] = { 0, 0, 0, 1 };
>>> >
>>> > +typedef struct ExtraSEI {
>>> > +  void *data;
>>> > +  size_t size;
>>> > +} ExtraSEI;
>>> > +
>>> > typedef struct BufNode {
>>> > CMSampleBufferRef cm_buffer;
>>> > +ExtraSEI *sei;
>>> > struct BufNode* next;
>>> > int error;
>>> > } BufNode;
>>> > @@ -94,6 +101,7 @@ typedef struct VTEncContext {
>>> > bool flushing;
>>> > bool has_b_frames;
>>> > bool warned_color_range;
>>> > +bool a53_cc;
>>> > } VTEncContext;
>>> >
>>> > static int vtenc_populate_extradata(AVCodecContext   *avctx,
>>> > @@ -136,7 +144,7 @@ static void set_async_error(VTEncContext *vtctx, int 
>>> > err)
>>> > pthread_mutex_unlock(>lock);
>>> > }
>>> >
>>> > -static int vtenc_q_pop(VTEncContext *vtctx, bool wait, CMSampleBufferRef 
>>> > *buf)
>>> > +static int vtenc_q_pop(VTEncContext *vtctx, bool wait, CMSampleBufferRef 
>>> > *buf, ExtraSEI **sei)
>>> > {
>>> > BufNode *info;
>>> >
>>> > @@ -173,6 +181,12 @@ static int vtenc_q_pop(VTEncContext *vtctx, bool 
>>> > wait, CMSampleBufferRef *buf)
>>> > pthread_mutex_unlock(>lock);
>>> >
>>> > *buf = info->cm_buffer;
>>> > +if (sei && *buf) {
>>> > +*sei = info->sei;
>>> > +} else if (info->sei) {
>>> > +if (info->sei->data) av_free(info->sei->data);
>>> > +av_free(info->sei);
>>> > +}
>>> > av_free(info);
>>> >
>>> > vtctx->frame_ct_out++;
>>> > @@ -180,7 +194,7 @@ static int vtenc_q_pop(VTEncContext *vtctx, bool 
>>> > wait, CMSampleBufferRef *buf)
>>> > return 0;
>>> > }
>>> >
>>> > -static void vtenc_q_push(VTEncContext *vtctx, CMSampleBufferRef buffer)
>>> > +static void vtenc_q_push(VTEncContext *vtctx, CMSampleBufferRef buffer, 
>>> > ExtraSEI *sei)
>>> > {
>>> > BufNode *info = av_malloc(sizeof(BufNode));
>>> > if (!info) {
>>> > @@ -190,6 +204,7 @@ static void vtenc_q_push(VTEncContext *vtctx, 
>>> > CMSampleBufferRef buffer)
>>> >
>>> > CFRetain(buffer);
>>> > info->cm_buffer = buffer;
>>> > +info->sei = sei;
>>> > info->next = NULL;
>>> >
>>> > pthread_mutex_lock(>lock);
>>> > @@ -420,6 +435,7 @@ static void vtenc_output_callback(
>>> > {
>>> > AVCodecContext *avctx = ctx;
>>> > VTEncContext   *vtctx = avctx->priv_data;
>>> > +ExtraSEI *sei = sourceFrameCtx;
>>> >
>>> > if (vtctx->async_error) {
>>> > if(sample_buffer) CFRelease(sample_buffer);
>>> > @@ -440,7 +456,7 @@ static void vtenc_output_callback(
>>> > }
>>> > }
>>> >
>>> > -vtenc_q_push(vtctx, sample_buffer);
>>> > +vtenc_q_push(vtctx, sample_buffer, sei);
>>> > }
>>> >
>>> > static int get_length_code_size(
>>> > @@ -1258,7 +1274,8 @@ static int copy_replace_length_codes(
>>> > static int vtenc_cm_to_avpacket(
>>> > AVCodecContext*avctx,
>>> > CMSampleBufferRef sample_buffer,
>>> > -AVPacket  *pkt)
>>> > +AVPacket  *pkt,
>>> > +ExtraSEI  *sei)
>>> > {
>>> > VTEncContext *vtctx = avctx->priv_data;
>>> >
>>> > @@ -1269,6 +1286,7 @@ static int vtenc_cm_to_avpacket(
>>> > size_t  header_size = 0;
>>> > size_t  in_buf_size;
>>> > size_t  out_buf_size;
>>> > +size_t  sei_nalu_size = 0;
>>> > int64_t dts_delta;
>>> > int64_t time_base_num;
>>> > int nalu_count;
>>> > @@ -1298,9 +1316,14 @@ static int vtenc_cm_to_avpacket(
>>> > if(status)
>>> > return status;
>>> >
>>> > +if (sei) {
>>> > +sei_nalu_size = sizeof(start_code) + 3 + sei->size + 1;
>>> > +}
>>> > +
>>> > in_buf_size = CMSampleBufferGetTotalSampleSize(sample_buffer);
>>> > 

[FFmpeg-devel] [PATCH] lavf/http.c: Add listen_timeout option.

[Stephan Holljes]

---
 libavformat/http.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/http.c b/libavformat/http.c
index d48958d..3b0d6ab 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -115,6 +115,7 @@ typedef struct HTTPContext {
 int reconnect_delay;
 int reconnect_delay_max;
 int listen;
+int listen_timeout;
 char *resource;
 int reply_code;
 int is_multi_client;
@@ -158,6 +159,7 @@ static const AVOption options[] = {
 { "reconnect_streamed", "auto reconnect streamed / non seekable streams", 
OFFSET(reconnect_streamed), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, D },
 { "reconnect_delay_max", "max reconnect delay in seconds after which to 
give up", OFFSET(reconnect_delay_max), AV_OPT_TYPE_INT, { .i64 = 120 }, 0, 
UINT_MAX/1000/1000, D },
 { "listen", "listen on HTTP", OFFSET(listen), AV_OPT_TYPE_INT, { .i64 = 0 
}, 0, 2, D | E },
+{ "listen_timeout",  "Connection awaiting timeout (in milliseconds)",  
OFFSET(listen_timeout), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, 
.flags = D|E },
 { "resource", "The resource requested by a client", OFFSET(resource), 
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, E },
 { "reply_code", "The http status code to return to a client", 
OFFSET(reply_code), AV_OPT_TYPE_INT, { .i64 = 200}, INT_MIN, 599, E},
 { NULL }
@@ -463,6 +465,9 @@ static int http_listen(URLContext *h, const char *uri, int 
flags,
 NULL);
 if ((ret = av_dict_set_int(options, "listen", s->listen, 0)) < 0)
 goto fail;
+if ((ret = av_dict_set_int(options, "listen_timeout", s->listen_timeout, 
0)) < 0)
+goto fail;
+
 if ((ret = ffurl_open_whitelist(>hd, lower_url, AVIO_FLAG_READ_WRITE,
 >interrupt_callback, options,
 h->protocol_whitelist, 
h->protocol_blacklist, h
-- 
2.5.5

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

Re: [FFmpeg-devel] [PATCH 3/3] fate: add loudnorm filter test

[Marton Balint]

On Tue, 18 Oct 2016, Michael Niedermayer wrote:


On Sun, Oct 16, 2016 at 10:12:17PM +0200, Marton Balint wrote:


On Sun, 16 Oct 2016, Marton Balint wrote:


Signed-off-by: Marton Balint 
---
tests/fate/filter-audio.mak | 7 +++
1 file changed, 7 insertions(+)

diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index 9c6f7cd..d376f25 100644
--- a/tests/fate/filter-audio.mak
+++ b/tests/fate/filter-audio.mak
@@ -279,6 +279,13 @@ fate-filter-hdcd-detect-errors: CMD = md5 -i $(SRC) -af 
hdcd -f s24le
fate-filter-hdcd-detect-errors: CMP = grep
fate-filter-hdcd-detect-errors: REF = detectable errors: [1-9]

+FATE_AFILTER-$(call FILTERDEMDECENCMUX, LOUDNORM, AAC, AAC, PCM_S16LE, 
PCM_S16LE) += fate-filter-loudnorm-simple
+fate-filter-loudnorm-simple: SRC = $(SAMPLES)/aac/sintel.aac
+fate-filter-loudnorm-simple: CMD = ffmpeg -t 30 -i $(SRC) -af loudnorm=i=-23 
-f s16le -ar 44100 -
+fate-filter-loudnorm-simple: REF = $(SAMPLES)/filter/loudnorm-simple.pcm
+fate-filter-loudnorm-simple: CMP = oneoff
+fate-filter-loudnorm-simple: CMP_UNIT = s16
+


This patch needs two files in the fate samples:

The audio part of the Sintel movie, as a source, because I wanted to
test with a real world example, with proper length. And the
reference file. Sources can be generated like this:

wget http://media.xiph.org/sintel/sintel-master-st.flac
ffmpeg -i sintel-master-st.flac -codec aac -b 96k fate-suite/aac/sintel.aac
ffmpeg -t 30 -i fate-suite/aac/sintel.aac -af loudnorm=i=-23 -f s16le -ar 44100 
fate-suite/filter/loudnorm-simple.pcm

Due to the 96k AAC codec, sintel.aac is about 15M,


are low bitrate speech codecs unsuitable instead of aac for this ?
that would cut the size down by alot


In theory, maybe, on the other hand, we are only using the first 30 second 
of the sample, so if size is an issue, we can reduce it to around 500k and 
the fate test will still work.


Since the reference file alone is 6M, it does not seem to make too much 
difference if the sample is 500k, or less, so I'd prefer the 
normal codec. I am not sure I can give you a pure technical reasoning, the 
only thing I could think of is that as far as I know a speech codec is 
usually not good at very low or very high frequencies, but it is a 
good idea to test loudness measurement with all kind of frequencies, 
because of it's frequency dependant filters.


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

Re: [FFmpeg-devel] [PATCH]lavf/avidec: Be more verbose when ignoring very large tag size

[Michael Niedermayer]

On Tue, Oct 18, 2016 at 12:42:18AM +0200, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch prints the tag and the tag size when ignoring the size.
> 
> Please comment, Carl Eugen

>  avidec.c |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 5e698290127169160243ccf1f06fe9c443c41b6c  
> 0001-lavf-avidec-Be-more-verbose-when-ignoring-very-large.patch
> From e99dc274b7b4b4b5ef502ddb0a8245c1f47c2ece Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Tue, 18 Oct 2016 00:37:06 +0200
> Subject: [PATCH] lavf/avidec: Be more verbose when ignoring very large tag
>  size.
> 
> ---
>  libavformat/avidec.c |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/avidec.c b/libavformat/avidec.c
> index b291625..2fcb0ee 100644
> --- a/libavformat/avidec.c
> +++ b/libavformat/avidec.c
> @@ -986,7 +986,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  if (size > 100) {
>  av_log(s, AV_LOG_ERROR,
> "Something went wrong during header parsing, "
> -   "I will ignore it and try to continue anyway.\n");
> +   "tag %c%c%c%c has size %u, "
> +   "I will ignore it and try to continue anyway.\n",
> +   tag & 0xff, tag >> 8 & 0xff, tag >> 16 & 0xff, tag >> 
> 24 & 0xff,
> +   size);

the last & 0xff is redundant

LGTM otherwise

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Never trust a computer, one day, it may think you are the virus. -- Compn


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

Re: [FFmpeg-devel] [PATCH 3/3] fate: add loudnorm filter test

[Michael Niedermayer]

On Sun, Oct 16, 2016 at 10:12:17PM +0200, Marton Balint wrote:
> 
> On Sun, 16 Oct 2016, Marton Balint wrote:
> 
> >Signed-off-by: Marton Balint 
> >---
> >tests/fate/filter-audio.mak | 7 +++
> >1 file changed, 7 insertions(+)
> >
> >diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
> >index 9c6f7cd..d376f25 100644
> >--- a/tests/fate/filter-audio.mak
> >+++ b/tests/fate/filter-audio.mak
> >@@ -279,6 +279,13 @@ fate-filter-hdcd-detect-errors: CMD = md5 -i $(SRC) -af 
> >hdcd -f s24le
> >fate-filter-hdcd-detect-errors: CMP = grep
> >fate-filter-hdcd-detect-errors: REF = detectable errors: [1-9]
> >
> >+FATE_AFILTER-$(call FILTERDEMDECENCMUX, LOUDNORM, AAC, AAC, PCM_S16LE, 
> >PCM_S16LE) += fate-filter-loudnorm-simple
> >+fate-filter-loudnorm-simple: SRC = $(SAMPLES)/aac/sintel.aac
> >+fate-filter-loudnorm-simple: CMD = ffmpeg -t 30 -i $(SRC) -af 
> >loudnorm=i=-23 -f s16le -ar 44100 -
> >+fate-filter-loudnorm-simple: REF = $(SAMPLES)/filter/loudnorm-simple.pcm
> >+fate-filter-loudnorm-simple: CMP = oneoff
> >+fate-filter-loudnorm-simple: CMP_UNIT = s16
> >+
> 
> This patch needs two files in the fate samples:
> 
> The audio part of the Sintel movie, as a source, because I wanted to
> test with a real world example, with proper length. And the
> reference file. Sources can be generated like this:
> 
> wget http://media.xiph.org/sintel/sintel-master-st.flac
> ffmpeg -i sintel-master-st.flac -codec aac -b 96k fate-suite/aac/sintel.aac
> ffmpeg -t 30 -i fate-suite/aac/sintel.aac -af loudnorm=i=-23 -f s16le -ar 
> 44100 fate-suite/filter/loudnorm-simple.pcm
> 
> Due to the 96k AAC codec, sintel.aac is about 15M,

are low bitrate speech codecs unsuitable instead of aac for this ?
that would cut the size down by alot


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] fate: add swr-convertaudio test

[Michael Niedermayer]

On Mon, Oct 17, 2016 at 05:37:41AM +0700, Muhammad Faiz wrote:
> test for flt to s16
> should pass on correct rounding to nearest
> 
> Signed-off-by: Muhammad Faiz 
> ---
>  tests/fate/libswresample.mak | 8 
>  1 file changed, 8 insertions(+)

tested on linux32/64, arm and mips qemu

LGTM

thx

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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

Re: [FFmpeg-devel] [PATCH v3] aacenc: add SIMD optimizations for abs_pow34 and quantization

[James Almer]

On 10/17/2016 6:24 PM, Rostislav Pehlivanov wrote:
> diff --git a/libavcodec/aacenc_utils.h b/libavcodec/aacenc_utils.h
> index ff9188a..f5cf77d 100644
> --- a/libavcodec/aacenc_utils.h
> +++ b/libavcodec/aacenc_utils.h
> @@ -37,7 +37,7 @@
>  #define ROUND_TO_ZERO 0.1054f
>  #define C_QUANT 0.4054f
>  
> -static inline void abs_pow34_v(float *out, const float *in, const int size)
> +static inline void abs_pow34_v(float *out, const float *in, const int64_t 
> size)

Why int64_t? There's no need for values that big...

>  {
>  int i;
>  for (i = 0; i < size; i++) {

...And it's certainly not correct, seeing this for loop here.

> diff --git a/libavcodec/x86/aacencdsp.asm b/libavcodec/x86/aacencdsp.asm
> new file mode 100644
> index 000..ff4019f
> --- /dev/null
> +++ b/libavcodec/x86/aacencdsp.asm
> @@ -0,0 +1,87 @@
> +;**
> +;* SIMD optimized AAC encoder DSP functions
> +;*
> +;* Copyright (C) 2016 Rostislav Pehlivanov 
> +;*
> +;* 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 "libavutil/x86/x86util.asm"
> +
> +SECTION_RODATA
> +
> +float_abs_mask:  times 4 dd 0x7fff
> +
> +SECTION .text
> +
> +;***
> +;void ff_abs_pow34_sse(float *out, const float *in, const int64_t size);
> +;***
> +INIT_XMM sse
> +cglobal abs_pow34, 3, 3, 3, out, in, size
> +mova   m2, [float_abs_mask]
> +shlsizeq, 2
> +addinq, sizeq
> +addoutq, sizeq
> +negsizeq
> +.loop:
> +mova   m0, [inq+sizeq]
> +andps  m0, m2
> +sqrtps m1, m0
> +mulps  m0, m1
> +sqrtps m0, m0
> +mova   [outq+sizeq], m0
> +addsizeq, mmsize
> +jl .loop
> +RET
> +
> +;***
> +;void ff_aac_quantize_bands_sse2(int *out, const float *in, const float 
> *scaled,
> +;int size, int is_signed, int maxval, const 
> float Q34,
> +;const float rounding)
> +;***
> +INIT_XMM sse2
> +cglobal aac_quantize_bands, 6, 6, 6, out, in, scaled, size, is_signed, 
> maxval, Q34, rounding

5, 5, 6

No need to load maxval into a gpr on x86_32 and win64 when cvtsi2ss
can also load it directly from memory.

> +%if UNIX64 == 0
> +movss m0, Q34m
> +movss m1, roundingm
> +%endif
> +SPLATDm0
> +SPLATDm1

shufps m0, m0, 0
shufps m1, m1, 0

On sse2, SPLATD will expand to pshufd, so better stay in float domain.

If you add an AVX/FMA3 version of this function, you could instead use
vbroadcastss in them, and save yourself the movss.

> +cvtsi2ss  m3, maxvald
> +SPLATDm3

%if UNIX64
cvtsi2ss  m3, maxvald
%else
cvtsi2ss  m3, dword maxvalm
%endif
shufpsm3, m3, 0

After you made the function 5, 5, 6.

> +shl   is_signedd, 31
> +movd  m4, is_signedd
> +SPLATDm4

Use shufps here since the instruction using this register in the loop
should be a float one.

> +shl   sizeq,   2

Even if it doesn't come from stack on win64, better use "sized" anyway.

> +add   inq, sizeq
> +add   outq,sizeq
> +add   scaledq, sizeq
> +neg   sizeq
> +.loop:
> +mova  m2, [scaledq+sizeq]
> +mulps m2, m0

mulps m2, m0, [scaledq+sizeq]

> +addps m2, m1

You could combine the mulps and addps into a single fmaddps if you add
an FMA3 version. Something like

movaps  m2, [scaledq+sizeq]
fmaddps m2, m2, m0, m1

The movaps is needed because, unlike FMA4's fmaddps which is
non-destructive, FMA3 needs dst to be the same as one of the three src
registers.

> +minps m2, m3
> +mova  m5, [inq+sizeq]

movaps m5, [inq+sizeq]

> +pand  m5, m4

andps m5, m4

> +orps  m2, m5
> +cvttps2dq m2, m2
> +mova  [outq+sizeq], m2
> +add   sizeq, mmsize
> +jl   .loop
> +RET

Can't you make these function also 

Re: [FFmpeg-devel] [PATCH v3] aacenc: add SIMD optimizations for abs_pow34 and quantization

[Michael Niedermayer]

On Mon, Oct 17, 2016 at 10:24:48PM +0100, Rostislav Pehlivanov wrote:
> Should fix segfaults on x86-32
> 
> Performance improvements:
> 
> quant_bands:
> with: 681 decicycles in quant_bands, 8388453 runs,155 skips
> without: 1190 decicycles in quant_bands, 8388386 runs,222 skips
> Around 42% for the function
> 
> Twoloop coder:
> 
> abs_pow34:
> with/without: 7.82s/8.17s
> Around 4% for the entire encoder
> 
> Both:
> with/without: 7.15s/8.17s
> Around 12% for the entire encoder
> 
> Fast coder:
> 
> abs_pow34:
> with/without: 3.40s/3.77s
> Around 10% for the entire encoder
> 
> Both:
> with/without: 3.02s/3.77s
> Around 20% faster for the entire encoder
> 
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/aaccoder.c| 27 +++--
>  libavcodec/aaccoder_trellis.h|  2 +-
>  libavcodec/aaccoder_twoloop.h|  2 +-
>  libavcodec/aacenc.c  |  4 ++
>  libavcodec/aacenc.h  |  6 +++
>  libavcodec/aacenc_is.c   |  6 +--
>  libavcodec/aacenc_ltp.c  |  4 +-
>  libavcodec/aacenc_pred.c |  6 +--
>  libavcodec/aacenc_quantization.h |  4 +-
>  libavcodec/aacenc_utils.h|  4 +-
>  libavcodec/x86/Makefile  |  2 +
>  libavcodec/x86/aacencdsp.asm | 87 
> 
>  libavcodec/x86/aacencdsp_init.c  | 43 
>  13 files changed, 170 insertions(+), 27 deletions(-)
>  create mode 100644 libavcodec/x86/aacencdsp.asm
>  create mode 100644 libavcodec/x86/aacencdsp_init.c

fate passes on linux32/64 x86, mingw32/64 x86

build fails on arm:

libavcodec/libavcodec.a(aacenc.o): In function `aac_encode_init':
ffmpeg/arm/src/libavcodec/aacenc.c:1038: undefined reference to 
`ff_aac_dsp_init_x86'
collect2: ld returned 1 exit status
make: *** [ffserver_g] Error 1
make: *** Waiting for unfinished jobs
libavcodec/libavcodec.a(aacenc.o): In function `aac_encode_init':
ffmpeg/arm/src/libavcodec/aacenc.c:1038: undefined reference to 
`ff_aac_dsp_init_x86'
collect2: ld returned 1 exit status
make: *** [ffprobe_g] Error 1
libavcodec/libavcodec.a(aacenc.o): In function `aac_encode_init':
ffmpeg/arm/src/libavcodec/aacenc.c:1038: undefined reference to 
`ff_aac_dsp_init_x86'
collect2: ld returned 1 exit status
make: *** [ffmpeg_g] Error 1

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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

[FFmpeg-devel] [PATCH]lavf/avidec: Be more verbose when ignoring very large tag size

[Carl Eugen Hoyos]

Hi!

Attached patch prints the tag and the tag size when ignoring the size.

Please comment, Carl Eugen
From e99dc274b7b4b4b5ef502ddb0a8245c1f47c2ece Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 18 Oct 2016 00:37:06 +0200
Subject: [PATCH] lavf/avidec: Be more verbose when ignoring very large tag
 size.

---
 libavformat/avidec.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index b291625..2fcb0ee 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -986,7 +986,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
 if (size > 100) {
 av_log(s, AV_LOG_ERROR,
"Something went wrong during header parsing, "
-   "I will ignore it and try to continue anyway.\n");
+   "tag %c%c%c%c has size %u, "
+   "I will ignore it and try to continue anyway.\n",
+   tag & 0xff, tag >> 8 & 0xff, tag >> 16 & 0xff, tag >> 
24 & 0xff,
+   size);
 if (s->error_recognition & AV_EF_EXPLODE)
 goto fail;
 avi->movi_list = avio_tell(pb) - 4;
-- 
1.7.10.4

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

Re: [FFmpeg-devel] comma at the end of enumerator lists

[Carl Eugen Hoyos]

2016-10-18 0:17 GMT+02:00 Michael Behrisch :

> I am not claiming that -Wpedantic is the only way to achieve this.
> I only think it helps or at least I assume that was the intention
> when it was invented.

("If gcc does it this way, it must be a good idea.")

This is an extremely unconvincing argument and concerning your
next sentence, I would expect that the trailing commas do not
violate any standard (if they do, your original patch would most
likely be ok).

In any case, your second patch is acceptable, should not have
any adversary effects and we have significantly worse cosmetic
patches in our tree, so it is ok imo.

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

Re: [FFmpeg-devel] comma at the end of enumerator lists

[Michael Behrisch]

Hi Ronald,

Am 17.10.2016 um 23:45 schrieb Ronald S. Bultje:
> Hi Michael,
> 
> On Mon, Oct 17, 2016 at 5:23 PM, Michael Behrisch  wrote:
> 
>> Hi Ronald,
>>
>> Am 17.10.2016 um 21:37 schrieb Ronald S. Bultje:
>>> Hi Michael,
>>>
>>> On Mon, Oct 17, 2016 at 3:16 PM, Michael Behrisch 
>>> wrote:
>>>
 Am 17.10.2016 um 15:29 schrieb Michael Niedermayer:
> On Mon, Oct 17, 2016 at 01:34:55PM +0200, wm4 wrote:
>> On Mon, 17 Oct 2016 13:09:36 +0200 Michael Niedermayer
>>  wrote:
>>
> this is about a cosmetic change having no real technical effect

 So here are my cosmetics for libavutil. It simply helps with
 keeping track of real warnings in downstream projects.
>>>
>>>
>>> Why are you using -Wpedantic?
>>
>> My main reason is that we are compiling with different compilers for
>> different platforms and -Wpedantic at least promises to keep the code
>> closer to the standard and thus better transferable. I never tested
>> whether this is actually true, but I like the fact that the project
>> currently compiles with gcc, clang and msvc and welcome every tool and
>> option that helps me to keep it this way. See also here:
>> http://stackoverflow.com/questions/2855121/what-is-the-
>> purpose-of-using-pedantic-in-gcc-g-compiler
>>
>>>
>>> Most people use warnings as a way for the compiler to inform them of
>>> potential bugs in their code; has -Wpedantic ever helped you find
>>> bugs?
>>
>> I cannot think of any but to be honest I cannot even tell exactly which
>> warnings are enabled by which of the -Wall, -Wextra and -Wpedantic flags
>> and it is surprisingly hard to find out.
> 
> 
> FFmpeg compiles with msvc, clang and gcc (without -Wpedantic), so the logic
> seems a little strange.

I am not claiming that -Wpedantic is the only way to achieve this. I
only think it helps or at least I assume that was the intention when it
was invented. After all, that is one of the reasons why standards exist
(in my opinion), to keep code compiler agnostic such that (in theory) I
do not have to check by myself whether it compiles with all the
compilers out there, as long as it adheres to the standard. And
"-Wpedantic" is just a "standard" checker to me. Maybe it checks for an
outdated version of the standard or for some version which is of no
relevance to FFmpeg, then please tell me.

Best regards,
Michael




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

[FFmpeg-devel] [PATCH 0/2] Fix gapless encoding/remuxing for MP3

[Jon Toohill]

Round trip wav->mp3->wav now preserves the correct number of samples.
Remuxing mp3->mp3 with -c:a copy also preserves any existing gapless
metadata in the Info tag.

The code in libmp3lame.c to set AV_PKT_DATA_SKIP_SAMPLES was mostly
copied from libopusenc.c.

Jon Toohill (2):
  lavc/libmp3lame: send encoder delay/padding in packet side data
  lavf/mp3enc: write encoder delay/padding upon closing

 libavcodec/libmp3lame.c | 27 ++-
 libavformat/mp3enc.c| 34 --
 2 files changed, 54 insertions(+), 7 deletions(-)

-- 
2.8.0.rc3.226.g39d4020

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

[FFmpeg-devel] [PATCH 1/2] lavc/libmp3lame: send encoder delay/padding in packet side data

[Jon Toohill]

---
 libavcodec/libmp3lame.c | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/libavcodec/libmp3lame.c b/libavcodec/libmp3lame.c
index 5642264..e55aa85 100644
--- a/libavcodec/libmp3lame.c
+++ b/libavcodec/libmp3lame.c
@@ -50,6 +50,7 @@ typedef struct LAMEContext {
 int reservoir;
 int joint_stereo;
 int abr;
+int delay_sent;
 float *samples_flt[2];
 AudioFrameQueue afq;
 AVFloatDSPContext *fdsp;
@@ -185,7 +186,7 @@ static int mp3lame_encode_frame(AVCodecContext *avctx, 
AVPacket *avpkt,
 {
 LAMEContext *s = avctx->priv_data;
 MPADecodeHeader hdr;
-int len, ret, ch;
+int len, ret, ch, discard_padding;
 int lame_result;
 uint32_t h;
 
@@ -269,6 +270,30 @@ static int mp3lame_encode_frame(AVCodecContext *avctx, 
AVPacket *avpkt,
 ff_af_queue_remove(>afq, avctx->frame_size, >pts,
>duration);
 
+discard_padding = avctx->frame_size - avpkt->duration;
+// Check if subtraction resulted in an overflow
+if ((discard_padding < avctx->frame_size) != (avpkt->duration > 0)) {
+av_log(avctx, AV_LOG_ERROR, "discard padding overflow\n");
+av_packet_unref(avpkt);
+av_free(avpkt);
+return AVERROR(EINVAL);
+}
+if ((!s->delay_sent && avctx->initial_padding > 0) || discard_padding 
> 0) {
+uint8_t* side_data = av_packet_new_side_data(avpkt,
+ 
AV_PKT_DATA_SKIP_SAMPLES,
+ 10);
+if(!side_data) {
+av_packet_unref(avpkt);
+av_free(avpkt);
+return AVERROR(ENOMEM);
+}
+if (!s->delay_sent) {
+AV_WL32(side_data, avctx->initial_padding);
+s->delay_sent = 1;
+}
+AV_WL32(side_data + 4, discard_padding);
+}
+
 avpkt->size = len;
 *got_packet_ptr = 1;
 }
-- 
2.8.0.rc3.226.g39d4020

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

[FFmpeg-devel] [PATCH 2/2] lavf/mp3enc: write encoder delay/padding upon closing

[Jon Toohill]

---
 libavformat/mp3enc.c | 34 --
 1 file changed, 28 insertions(+), 6 deletions(-)

diff --git a/libavformat/mp3enc.c b/libavformat/mp3enc.c
index de63401..4c97fa1 100644
--- a/libavformat/mp3enc.c
+++ b/libavformat/mp3enc.c
@@ -111,6 +111,8 @@ typedef struct MP3Context {
 uint64_t bag[XING_NUM_BAGS];
 int initial_bitrate;
 int has_variable_bitrate;
+int delay;
+int padding;
 
 /* index of the audio stream */
 int audio_stream_idx;
@@ -247,12 +249,7 @@ static int mp3_write_xing(AVFormatContext *s)
 ffio_fill(dyn_ctx, 0, 8); // empty replaygain fields
 avio_w8(dyn_ctx, 0);  // unknown encoding flags
 avio_w8(dyn_ctx, 0);  // unknown abr/minimal bitrate
-
-// encoder delay
-if (par->initial_padding - 528 - 1 >= 1 << 12) {
-av_log(s, AV_LOG_WARNING, "Too many samples of initial padding.\n");
-}
-avio_wb24(dyn_ctx, FFMAX(par->initial_padding - 528 - 1, 0)<<12);
+avio_wb24(dyn_ctx, 0);// empty encoder delay/padding
 
 avio_w8(dyn_ctx,   0); // misc
 avio_w8(dyn_ctx,   0); // mp3gain
@@ -345,10 +342,24 @@ static int mp3_write_audio_packet(AVFormatContext *s, 
AVPacket *pkt)
 #endif
 
 if (mp3->xing_offset) {
+uint8_t *side_data = NULL;
+int side_data_size = 0;
+
 mp3_xing_add_frame(mp3, pkt);
 mp3->audio_size += pkt->size;
 mp3->audio_crc   = av_crc(av_crc_get_table(AV_CRC_16_ANSI_LE),
   mp3->audio_crc, pkt->data, pkt->size);
+
+side_data = av_packet_get_side_data(pkt,
+AV_PKT_DATA_SKIP_SAMPLES,
+_data_size);
+if (side_data && side_data_size >= 10) {
+mp3->padding = FFMAX(AV_RL32(side_data + 4) + 528 + 1, 0);
+if (!mp3->delay)
+mp3->delay =  FFMAX(AV_RL32(side_data) - 528 - 1, 0);
+} else {
+mp3->padding = 0;
+}
 }
 }
 
@@ -422,6 +433,17 @@ static void mp3_update_xing(AVFormatContext *s)
 }
 }
 
+/* write encoder delay/padding */
+if (mp3->delay >= 1 << 12) {
+mp3->delay = (1 << 12) - 1;
+av_log(s, AV_LOG_WARNING, "Too many samples of initial padding.\n");
+}
+if (mp3->padding >= 1 << 12) {
+mp3->padding = (1 << 12) - 1;
+av_log(s, AV_LOG_WARNING, "Too many samples of trailing padding.\n");
+}
+AV_WB24(mp3->xing_frame + mp3->xing_offset + 141, (mp3->delay << 12) + 
mp3->padding);
+
 AV_WB32(mp3->xing_frame + mp3->xing_offset + XING_SIZE - 8, 
mp3->audio_size);
 AV_WB16(mp3->xing_frame + mp3->xing_offset + XING_SIZE - 4, 
mp3->audio_crc);
 
-- 
2.8.0.rc3.226.g39d4020

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

Re: [FFmpeg-devel] [PATCHv2] vf_colorspace: Interpret unspecified color range as limited range

[Ronald S. Bultje]

Hi Vittorio,

On Mon, Oct 17, 2016 at 5:28 PM, Vittorio Giovara <
vittorio.giov...@gmail.com> wrote:

> On Mon, Sep 19, 2016 at 8:36 AM, Ronald S. Bultje 
> wrote:
> > Hi,
> >
> > On Fri, Sep 16, 2016 at 9:27 AM, Clément Bœsch  wrote:
> >>
> >> On Fri, Sep 16, 2016 at 03:20:49PM +0200, Vittorio Giovara wrote:
> >> > This is the assumption that is made in pixel format conversion do
> >> > throughout the code (in particular swscale), and BT-specifications
> >> > mandate.
> >> >
> >> > Add a warning to inform the user that an automatic selection is being
> >> > made.
> >> >
> >> > Signed-off-by: Vittorio Giovara 
> >> > ---
> >> >  libavfilter/vf_colorspace.c | 9 ++---
> >> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
> >> > index e69be50..41d1692 100644
> >> > --- a/libavfilter/vf_colorspace.c
> >> > +++ b/libavfilter/vf_colorspace.c
> >> > @@ -518,10 +518,13 @@ static int convert(AVFilterContext *ctx, void
> >> > *data, int job_nr, int n_jobs)
> >> >  return 0;
> >> >  }
> >> >
> >> > -static int get_range_off(int *off, int *y_rng, int *uv_rng,
> >> > +static int get_range_off(AVFilterContext *ctx, int *off,
> >> > + int *y_rng, int *uv_rng,
> >> >   enum AVColorRange rng, int depth)
> >> >  {
> >> >  switch (rng) {
> >> > +case AVCOL_RANGE_UNSPECIFIED:
> >> > +av_log(ctx, AV_LOG_WARNING, "Input range not set, assuming
> >> > tv/mpeg\n");
>
> Hey Ronald,
> this message ends up spamming quite a bit, since it prints a warning
> for every frame, which is a tad excessive.
>
> As mentioned in this thread, I doubt this line could be beneficial to
> the user, and needlessly filling the logs might be just worse since it
> makes it harder to notice warnings in the first place. I don't think
> it warrants a if_already_warned clause, would it be possible to just
> drop it?


If we just print it once and then disable further spamming the console from
then onwards, is that OK?

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

Re: [FFmpeg-devel] comma at the end of enumerator lists

[Ronald S. Bultje]

Hi Michael,

On Mon, Oct 17, 2016 at 5:23 PM, Michael Behrisch  wrote:

> Hi Ronald,
>
> Am 17.10.2016 um 21:37 schrieb Ronald S. Bultje:
> > Hi Michael,
> >
> > On Mon, Oct 17, 2016 at 3:16 PM, Michael Behrisch 
> > wrote:
> >
> >> Am 17.10.2016 um 15:29 schrieb Michael Niedermayer:
> >>> On Mon, Oct 17, 2016 at 01:34:55PM +0200, wm4 wrote:
>  On Mon, 17 Oct 2016 13:09:36 +0200 Michael Niedermayer
>   wrote:
> 
> >>> this is about a cosmetic change having no real technical effect
> >>
> >> So here are my cosmetics for libavutil. It simply helps with
> >> keeping track of real warnings in downstream projects.
> >
> >
> > Why are you using -Wpedantic?
>
> My main reason is that we are compiling with different compilers for
> different platforms and -Wpedantic at least promises to keep the code
> closer to the standard and thus better transferable. I never tested
> whether this is actually true, but I like the fact that the project
> currently compiles with gcc, clang and msvc and welcome every tool and
> option that helps me to keep it this way. See also here:
> http://stackoverflow.com/questions/2855121/what-is-the-
> purpose-of-using-pedantic-in-gcc-g-compiler
>
> >
> > Most people use warnings as a way for the compiler to inform them of
> > potential bugs in their code; has -Wpedantic ever helped you find
> > bugs?
>
> I cannot think of any but to be honest I cannot even tell exactly which
> warnings are enabled by which of the -Wall, -Wextra and -Wpedantic flags
> and it is surprisingly hard to find out.


FFmpeg compiles with msvc, clang and gcc (without -Wpedantic), so the logic
seems a little strange.

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mov: pass the demuxer's AVFormatContext to avpriv_request_sample()

[Michael Niedermayer]

On Sun, Oct 16, 2016 at 09:34:51PM -0300, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  libavformat/mov.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)

LGTM

thx

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

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


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

Re: [FFmpeg-devel] [PATCHv2] vf_colorspace: Interpret unspecified color range as limited range

[Vittorio Giovara]

On Mon, Sep 19, 2016 at 8:36 AM, Ronald S. Bultje  wrote:
> Hi,
>
> On Fri, Sep 16, 2016 at 9:27 AM, Clément Bœsch  wrote:
>>
>> On Fri, Sep 16, 2016 at 03:20:49PM +0200, Vittorio Giovara wrote:
>> > This is the assumption that is made in pixel format conversion do
>> > throughout the code (in particular swscale), and BT-specifications
>> > mandate.
>> >
>> > Add a warning to inform the user that an automatic selection is being
>> > made.
>> >
>> > Signed-off-by: Vittorio Giovara 
>> > ---
>> >  libavfilter/vf_colorspace.c | 9 ++---
>> >  1 file changed, 6 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
>> > index e69be50..41d1692 100644
>> > --- a/libavfilter/vf_colorspace.c
>> > +++ b/libavfilter/vf_colorspace.c
>> > @@ -518,10 +518,13 @@ static int convert(AVFilterContext *ctx, void
>> > *data, int job_nr, int n_jobs)
>> >  return 0;
>> >  }
>> >
>> > -static int get_range_off(int *off, int *y_rng, int *uv_rng,
>> > +static int get_range_off(AVFilterContext *ctx, int *off,
>> > + int *y_rng, int *uv_rng,
>> >   enum AVColorRange rng, int depth)
>> >  {
>> >  switch (rng) {
>> > +case AVCOL_RANGE_UNSPECIFIED:
>> > +av_log(ctx, AV_LOG_WARNING, "Input range not set, assuming
>> > tv/mpeg\n");

Hey Ronald,
this message ends up spamming quite a bit, since it prints a warning
for every frame, which is a tad excessive.

As mentioned in this thread, I doubt this line could be beneficial to
the user, and needlessly filling the logs might be just worse since it
makes it harder to notice warnings in the first place. I don't think
it warrants a if_already_warned clause, would it be possible to just
drop it?

Thanks (please CC)
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v3] aacenc: add SIMD optimizations for abs_pow34 and quantization

[Rostislav Pehlivanov]

Should fix segfaults on x86-32

Performance improvements:

quant_bands:
with: 681 decicycles in quant_bands, 8388453 runs,155 skips
without: 1190 decicycles in quant_bands, 8388386 runs,222 skips
Around 42% for the function

Twoloop coder:

abs_pow34:
with/without: 7.82s/8.17s
Around 4% for the entire encoder

Both:
with/without: 7.15s/8.17s
Around 12% for the entire encoder

Fast coder:

abs_pow34:
with/without: 3.40s/3.77s
Around 10% for the entire encoder

Both:
with/without: 3.02s/3.77s
Around 20% faster for the entire encoder

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/aaccoder.c| 27 +++--
 libavcodec/aaccoder_trellis.h|  2 +-
 libavcodec/aaccoder_twoloop.h|  2 +-
 libavcodec/aacenc.c  |  4 ++
 libavcodec/aacenc.h  |  6 +++
 libavcodec/aacenc_is.c   |  6 +--
 libavcodec/aacenc_ltp.c  |  4 +-
 libavcodec/aacenc_pred.c |  6 +--
 libavcodec/aacenc_quantization.h |  4 +-
 libavcodec/aacenc_utils.h|  4 +-
 libavcodec/x86/Makefile  |  2 +
 libavcodec/x86/aacencdsp.asm | 87 
 libavcodec/x86/aacencdsp_init.c  | 43 
 13 files changed, 170 insertions(+), 27 deletions(-)
 create mode 100644 libavcodec/x86/aacencdsp.asm
 create mode 100644 libavcodec/x86/aacencdsp_init.c

diff --git a/libavcodec/aaccoder.c b/libavcodec/aaccoder.c
index 35787e8..9f3b4ed 100644
--- a/libavcodec/aaccoder.c
+++ b/libavcodec/aaccoder.c
@@ -88,7 +88,7 @@ static void encode_window_bands_info(AACEncContext *s, 
SingleChannelElement *sce
 float next_minrd = INFINITY;
 int next_mincb = 0;
 
-abs_pow34_v(s->scoefs, sce->coeffs, 1024);
+s->abs_pow34(s->scoefs, sce->coeffs, 1024);
 start = win*128;
 for (cb = 0; cb < CB_TOT_ALL; cb++) {
 path[0][cb].cost = 0.0f;
@@ -299,7 +299,7 @@ static void search_for_quantizers_anmr(AVCodecContext 
*avctx, AACEncContext *s,
 }
 }
 idx = 1;
-abs_pow34_v(s->scoefs, sce->coeffs, 1024);
+s->abs_pow34(s->scoefs, sce->coeffs, 1024);
 for (w = 0; w < sce->ics.num_windows; w += sce->ics.group_len[w]) {
 start = w*128;
 for (g = 0; g < sce->ics.num_swb; g++) {
@@ -446,7 +446,7 @@ static void search_for_quantizers_fast(AVCodecContext 
*avctx, AACEncContext *s,
 
 if (!allz)
 return;
-abs_pow34_v(s->scoefs, sce->coeffs, 1024);
+s->abs_pow34(s->scoefs, sce->coeffs, 1024);
 ff_quantize_band_cost_cache_init(s);
 
 for (w = 0; w < sce->ics.num_windows; w += sce->ics.group_len[w]) {
@@ -652,8 +652,8 @@ static void search_for_pns(AACEncContext *s, AVCodecContext 
*avctx, SingleChanne
 s->fdsp->vector_fmul_scalar(PNS, PNS, scale, 
sce->ics.swb_sizes[g]);
 pns_senergy = s->fdsp->scalarproduct_float(PNS, PNS, 
sce->ics.swb_sizes[g]);
 pns_energy += pns_senergy;
-abs_pow34_v(NOR34, >coeffs[start_c], 
sce->ics.swb_sizes[g]);
-abs_pow34_v(PNS34, PNS, sce->ics.swb_sizes[g]);
+s->abs_pow34(NOR34, >coeffs[start_c], 
sce->ics.swb_sizes[g]);
+s->abs_pow34(PNS34, PNS, sce->ics.swb_sizes[g]);
 dist1 += quantize_band_cost(s, >coeffs[start_c],
 NOR34,
 sce->ics.swb_sizes[g],
@@ -757,8 +757,9 @@ static void search_for_ms(AACEncContext *s, ChannelElement 
*cpe)
 {
 int start = 0, i, w, w2, g, sid_sf_boost, prev_mid, prev_side;
 uint8_t nextband0[128], nextband1[128];
-float M[128], S[128];
-float *L34 = s->scoefs, *R34 = s->scoefs + 128, *M34 = s->scoefs + 128*2, 
*S34 = s->scoefs + 128*3;
+float *M   = s->scoefs + 128*0, *S   = s->scoefs + 128*1;
+float *L34 = s->scoefs + 128*2, *R34 = s->scoefs + 128*3;
+float *M34 = s->scoefs + 128*4, *S34 = s->scoefs + 128*5;
 const float lambda = s->lambda;
 const float mslambda = FFMIN(1.0f, lambda / 120.f);
 SingleChannelElement *sce0 = >ch[0];
@@ -789,8 +790,8 @@ static void search_for_ms(AACEncContext *s, ChannelElement 
*cpe)
 S[i] =  M[i]
   - sce1->coeffs[start+(w+w2)*128+i];
 }
-abs_pow34_v(M34, M, sce0->ics.swb_sizes[g]);
-abs_pow34_v(S34, S, sce0->ics.swb_sizes[g]);
+s->abs_pow34(M34, M, sce0->ics.swb_sizes[g]);
+s->abs_pow34(S34, S, sce0->ics.swb_sizes[g]);
 for (i = 0; i < sce0->ics.swb_sizes[g]; i++ ) {
 Mmax = FFMAX(Mmax, M34[i]);
 Smax = FFMAX(Smax, S34[i]);
@@ -833,10 +834,10 @@ static void search_for_ms(AACEncContext *s, 
ChannelElement *cpe)
   - sce1->coeffs[start+(w+w2)*128+i];
 }
 
-abs_pow34_v(L34, sce0->coeffs+start+(w+w2)*128, 

Re: [FFmpeg-devel] [PATCHv3] mov: Evaluate the movie display matrix

[Vittorio Giovara]

On Thu, Oct 13, 2016 at 6:50 PM, Vittorio Giovara
 wrote:
> This matrix needs to be applied after all others have (currently only
> display matrix from trak), but cannot be handled in movie box, since
> streams are not allocated yet. So store it in main context, and apply
> it when appropriate, that is after parsing the tkhd one.
>
> Signed-off-by: Vittorio Giovara 
> ---
> Reworked second matrix handling so that it is always applied, which makes
> the code easier to read and test. Updated according reviews, rolled back
> a couple of points for the reasons explained in the thread.
>
> Needs a new sample to be uploaded to fate,
> https://www.dropbox.com/s/qfio4bjhkpz3p4o/displaymatrix.mov?dl=0,
> the previous one can be deleted.
>
> Cheers,
> Vittorio
>
>  libavformat/isom.h|  2 ++
>  libavformat/mov.c | 53 
> +++
>  tests/fate/mov.mak|  6 -
>  tests/ref/fate/mov-display-matrix | 10 
>  4 files changed, 59 insertions(+), 12 deletions(-)
>  create mode 100644 tests/ref/fate/mov-display-matrix

Ping? Please cc me or i might miss replies.
Thanks
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] comma at the end of enumerator lists

[Michael Behrisch]

Hi Ronald,

Am 17.10.2016 um 21:37 schrieb Ronald S. Bultje:
> Hi Michael,
> 
> On Mon, Oct 17, 2016 at 3:16 PM, Michael Behrisch 
> wrote:
> 
>> Am 17.10.2016 um 15:29 schrieb Michael Niedermayer:
>>> On Mon, Oct 17, 2016 at 01:34:55PM +0200, wm4 wrote:
 On Mon, 17 Oct 2016 13:09:36 +0200 Michael Niedermayer
  wrote:
 
>>> this is about a cosmetic change having no real technical effect
>> 
>> So here are my cosmetics for libavutil. It simply helps with
>> keeping track of real warnings in downstream projects.
> 
> 
> Why are you using -Wpedantic?

My main reason is that we are compiling with different compilers for
different platforms and -Wpedantic at least promises to keep the code
closer to the standard and thus better transferable. I never tested
whether this is actually true, but I like the fact that the project
currently compiles with gcc, clang and msvc and welcome every tool and
option that helps me to keep it this way. See also here:
http://stackoverflow.com/questions/2855121/what-is-the-purpose-of-using-pedantic-in-gcc-g-compiler

> 
> Most people use warnings as a way for the compiler to inform them of 
> potential bugs in their code; has -Wpedantic ever helped you find
> bugs?

I cannot think of any but to be honest I cannot even tell exactly which
warnings are enabled by which of the -Wall, -Wextra and -Wpedantic flags
and it is surprisingly hard to find out.

Best regards,
Michael



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

Re: [FFmpeg-devel] [PATCH/RFC]lavf/avidec: Do not fail for very large idx1 tags

[Michael Niedermayer]

On Mon, Oct 17, 2016 at 06:29:42PM +0200, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch fixes the file mentioned in github pull request 197, 
> it can be played with MPlayer, vlc, xine and totem.
> 
> Please comment, Carl Eugen

>  avidec.c |2 ++
>  1 file changed, 2 insertions(+)
> 0b5d5e672b7ec13a8c8aa1597ceb21b16b5e61b8  
> 0001-lavf-avidec-Do-not-fail-for-very-large-idx1-tags.patch
> From 646a765749e08bb48f74488ad9f539cbc736673c Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Mon, 17 Oct 2016 18:25:48 +0200
> Subject: [PATCH] lavf/avidec: Do not fail for very large idx1 tags.
> 
> Fixes demuxing the sample file from github pull request 197,
> the size of its idx1 tag is 6171936 bytes, followed by a JUNK
> tag of 9505704 bytes.
> ---
>  libavformat/avidec.c |2 ++
>  1 file changed, 2 insertions(+)

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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

Re: [FFmpeg-devel] comma at the end of enumerator lists

[Ronald S. Bultje]

Hi Michael,

On Mon, Oct 17, 2016 at 3:16 PM, Michael Behrisch  wrote:

> Am 17.10.2016 um 15:29 schrieb Michael Niedermayer:
> > On Mon, Oct 17, 2016 at 01:34:55PM +0200, wm4 wrote:
> >> On Mon, 17 Oct 2016 13:09:36 +0200
> >> Michael Niedermayer  wrote:
> >>
> >>> On Mon, Oct 17, 2016 at 10:07:42AM +0200, Nicolas George wrote:
>  Le sextidi 26 vendémiaire, an CCXXV, Michael Niedermayer a écrit :
> > probably, yes
> 
>  I would have said exactly the opposite. It is nothing but a waste of
> time
>  and a pollution of the history.
> >>>
> >>> My idea here is to maximize the number of developers
> >>> And if in cases where one doesnt really care much either way and
> >>> someone else seems caring more one says, "ok" that may result in a
> happy
> >>> new contributor.
> >>> Saying "no" is more likely to turn someone away.
> >>> and again, it doesnt really matter if the , is there after a
> >>> final sentinel /count entry as no next field would ever be added
> >>
> >> Are you kidding me. Patches should be judged on their technical merrit,
> >> not whether you might piss someone off by rejecting it.
> >
> > this is about a cosmetic change having no real technical effect
>
> So here are my cosmetics for libavutil. It simply helps with keeping
> track of real warnings in downstream projects.


Why are you using -Wpedantic?

Most people use warnings as a way for the compiler to inform them of
potential bugs in their code; has -Wpedantic ever helped you find bugs?

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

Re: [FFmpeg-devel] comma at the end of enumerator lists

[Michael Behrisch]

Am 17.10.2016 um 15:29 schrieb Michael Niedermayer:
> On Mon, Oct 17, 2016 at 01:34:55PM +0200, wm4 wrote:
>> On Mon, 17 Oct 2016 13:09:36 +0200
>> Michael Niedermayer  wrote:
>>
>>> On Mon, Oct 17, 2016 at 10:07:42AM +0200, Nicolas George wrote:
 Le sextidi 26 vendémiaire, an CCXXV, Michael Niedermayer a écrit :  
> probably, yes  

 I would have said exactly the opposite. It is nothing but a waste of time
 and a pollution of the history.  
>>>
>>> My idea here is to maximize the number of developers
>>> And if in cases where one doesnt really care much either way and
>>> someone else seems caring more one says, "ok" that may result in a happy
>>> new contributor.
>>> Saying "no" is more likely to turn someone away.
>>> and again, it doesnt really matter if the , is there after a
>>> final sentinel /count entry as no next field would ever be added
>>
>> Are you kidding me. Patches should be judged on their technical merrit,
>> not whether you might piss someone off by rejecting it.
> 
> this is about a cosmetic change having no real technical effect

So here are my cosmetics for libavutil. It simply helps with keeping
track of real warnings in downstream projects.

Best regards,
Michael



diff -rup FFmpeg-master/libavutil/log.h FFmpeg/libavutil/log.h
--- FFmpeg-master/libavutil/log.h	2016-10-17 19:47:57.0 +0200
+++ FFmpeg/libavutil/log.h	2016-10-17 20:30:38.545498875 +0200
@@ -44,7 +44,7 @@ typedef enum {
 AV_CLASS_CATEGORY_DEVICE_AUDIO_INPUT,
 AV_CLASS_CATEGORY_DEVICE_OUTPUT,
 AV_CLASS_CATEGORY_DEVICE_INPUT,
-AV_CLASS_CATEGORY_NB, ///< not part of ABI/API
+AV_CLASS_CATEGORY_NB  ///< not part of ABI/API
 }AVClassCategory;
 
 #define AV_IS_INPUT_DEVICE(category) \
diff -rup FFmpeg-master/libavutil/pixfmt.h FFmpeg/libavutil/pixfmt.h
--- FFmpeg-master/libavutil/pixfmt.h	2016-10-17 19:47:57.0 +0200
+++ FFmpeg/libavutil/pixfmt.h	2016-10-17 20:30:38.565499123 +0200
@@ -306,7 +306,7 @@ enum AVPixelFormat {
 
 AV_PIX_FMT_MEDIACODEC, ///< hardware decoding through MediaCodec
 
-AV_PIX_FMT_NB,///< number of pixel formats, DO NOT USE THIS if you want to link with shared libav* because the number of formats might differ between versions
+AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS if you want to link with shared libav* because the number of formats might differ between versions
 };
 
 #if AV_HAVE_BIGENDIAN
@@ -401,7 +401,7 @@ enum AVColorPrimaries {
 AVCOL_PRI_SMPTEST428_1 = 10, ///< SMPTE ST 428-1 (CIE 1931 XYZ)
 AVCOL_PRI_SMPTE431= 11, ///< SMPTE ST 431-2 (2011)
 AVCOL_PRI_SMPTE432= 12, ///< SMPTE ST 432-1 D65 (2010)
-AVCOL_PRI_NB,   ///< Not part of ABI
+AVCOL_PRI_NB///< Not part of ABI
 };
 
 /**
@@ -427,7 +427,7 @@ enum AVColorTransferCharacteristic {
 AVCOL_TRC_SMPTEST2084  = 16, ///< SMPTE ST 2084 for 10-, 12-, 14- and 16-bit systems
 AVCOL_TRC_SMPTEST428_1 = 17, ///< SMPTE ST 428-1
 AVCOL_TRC_ARIB_STD_B67 = 18, ///< ARIB STD-B67, known as "Hybrid log-gamma"
-AVCOL_TRC_NB,///< Not part of ABI
+AVCOL_TRC_NB ///< Not part of ABI
 };
 
 /**
@@ -446,7 +446,7 @@ enum AVColorSpace {
 AVCOL_SPC_BT2020_NCL  = 9,  ///< ITU-R BT2020 non-constant luminance system
 AVCOL_SPC_BT2020_CL   = 10, ///< ITU-R BT2020 constant luminance system
 AVCOL_SPC_SMPTE2085   = 11, ///< SMPTE 2085, Y'D'zD'x
-AVCOL_SPC_NB,   ///< Not part of ABI
+AVCOL_SPC_NB///< Not part of ABI
 };
 #define AVCOL_SPC_YCGCO AVCOL_SPC_YCOCG
 
@@ -458,7 +458,7 @@ enum AVColorRange {
 AVCOL_RANGE_UNSPECIFIED = 0,
 AVCOL_RANGE_MPEG= 1, ///< the normal 219*2^(n-8) "MPEG" YUV ranges
 AVCOL_RANGE_JPEG= 2, ///< the normal 2^n-1   "JPEG" YUV ranges
-AVCOL_RANGE_NB,  ///< Not part of ABI
+AVCOL_RANGE_NB   ///< Not part of ABI
 };
 
 /**
@@ -484,7 +484,7 @@ enum AVChromaLocation {
 AVCHROMA_LOC_TOP = 4,
 AVCHROMA_LOC_BOTTOMLEFT  = 5,
 AVCHROMA_LOC_BOTTOM  = 6,
-AVCHROMA_LOC_NB,  ///< Not part of ABI
+AVCHROMA_LOC_NB   ///< Not part of ABI
 };
 
 #endif /* AVUTIL_PIXFMT_H */



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

[FFmpeg-devel] [PATCH] avformat: close parser if codec changed

[Andreas Cadhalpun]

The parser depends on the codec and thus must not be used with a different one.
If it is, the 'avctx->codec_id == s->parser->codec_ids[0] ...' assert in
av_parser_parse2 gets triggered.

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/utils.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 8a51aea..a581994 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -480,6 +480,12 @@ static int update_stream_avctx(AVFormatContext *s)
 if (!st->internal->need_context_update)
 continue;
 
+/* close parser, because it depends on the codec */
+if (st->parser) {
+av_parser_close(st->parser);
+st->parser = NULL;
+}
+
 /* update internal codec context, for the parser */
 ret = avcodec_parameters_to_context(st->internal->avctx, st->codecpar);
 if (ret < 0)
@@ -1515,6 +1521,12 @@ static int read_frame_internal(AVFormatContext *s, 
AVPacket *pkt)
 st->info->found_decoder = 0;
 }
 
+/* close parser, because it depends on the codec */
+if (st->parser) {
+av_parser_close(st->parser);
+st->parser = NULL;
+}
+
 ret = avcodec_parameters_to_context(st->internal->avctx, 
st->codecpar);
 if (ret < 0)
 return ret;
-- 
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] aiffdec: fix division by zero

[Andreas Cadhalpun]

On 17.10.2016 20:11, Michael Niedermayer wrote:
> On Mon, Oct 17, 2016 at 06:27:29PM +0200, Andreas Cadhalpun wrote:
>> On 17.10.2016 17:13, Michael Niedermayer wrote:
>>> On Mon, Oct 17, 2016 at 04:17:35PM +0200, Andreas Cadhalpun wrote:
 On 17.10.2016 05:43, Michael Niedermayer wrote:
> On Sun, Oct 16, 2016 at 10:38:42PM +0200, Andreas Cadhalpun wrote:
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavformat/aiffdec.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/aiffdec.c b/libavformat/aiffdec.c
>> index cd916f9..de82787 100644
>> --- a/libavformat/aiffdec.c
>> +++ b/libavformat/aiffdec.c
>> @@ -380,7 +380,7 @@ static int aiff_read_packet(AVFormatContext *s,
>>  size = st->codecpar->block_align;
>>  break;
>>  default:
>> -size = (MAX_SIZE / st->codecpar->block_align) * 
>> st->codecpar->block_align;
>> +size = st->codecpar->block_align ? (MAX_SIZE / 
>> st->codecpar->block_align) * st->codecpar->block_align : MAX_SIZE;
>
> how do you reach block_align == 0 ?
> aiff_read_header() checks for block_align == 0

 I'm not aware of a way to reproduce this with the ffmpeg binary, however
 an API user (e.g. my fuzz-testing-program) can change codecpar->codec_type
 and codecpar->codec_id to force decoding a stream with a particular codec.

 However, avcodec_parameters_from_context sets codecpar->block_align to 0
 for AVMEDIA_TYPE_VIDEO thus causing the subsequent crash.
>>>
>>> hmm, patch is probably ok then
>>
>> Pushed.
>>
>> What about the similar patches for astdec and westwood_aud?
> 
> probably ok too

Thanks, pushed both.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] avcodec/vda: define av_vda_default_init2 when CONFIG_H264_VDA_HWACCEL equ 0

[Xidorn Quan]

This isn't maintained by me. You should probaby ping Sebastien Zwickert <
dilar...@free.fr>.

But this change looks trivial, so I think it is fine.

- Xidorn

On Mon, Oct 17, 2016 at 7:01 PM, Steven Liu  wrote:

> ping Xidorn Quan
>
> 2016-10-15 6:01 GMT+08:00 wm4 :
>
>> On Thu, 13 Oct 2016 20:57:07 +0800
>> Steven Liu  wrote:
>>
>> > ping
>> >
>> > 2016-10-12 17:36 GMT+08:00 Steven Liu :
>> >
>> > > on OSX:
>> > > ../configure --disable-everything --enable-demuxer=hls make
>> > > error message: Undefined symbols for architecture x86_64:
>> > > "_av_vda_default_init2", referenced from:_videotoolbox_init in
>> > > ffmpeg_videotoolbox.o
>> > > so add av_vda_default_init2 when CONFIG_H264_VDA_HWACCEL=0
>> > >
>> > > Signed-off-by: Steven Liu 
>> > > ---
>> > >  libavcodec/vda.c |5 +
>> > >  1 files changed, 5 insertions(+), 0 deletions(-)
>> > >
>> > > diff --git a/libavcodec/vda.c b/libavcodec/vda.c
>> > > index 4670140..819ae03 100644
>> > > --- a/libavcodec/vda.c
>> > > +++ b/libavcodec/vda.c
>> > > @@ -73,6 +73,11 @@ int av_vda_default_init(AVCodecContext *avctx)
>> > >  return AVERROR(ENOSYS);
>> > >  }
>> > >
>> > > +int av_vda_default_init2(AVCodecContext *avctx, AVVDAContext
>> *vdactx)
>> > > +{
>> > > +return AVERROR(ENOSYS);
>> > > +}
>> > > +
>> > >  void av_vda_default_free(AVCodecContext *ctx)
>> > >  {
>> > >  }
>> > > --
>> > > 1.7.1
>> > >
>> > >
>> > >
>> > > ___
>> > > 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
>>
>> Patch ok, but I can't push for a while (and I'm not VDA maintainer).
>> ___
>> 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] avfilter/showcqt: add font option

[Muhammad Faiz]

On Mon, Oct 17, 2016 at 6:02 AM, Muhammad Faiz  wrote:
> this is fontconfig pattern
>
> Signed-off-by: Muhammad Faiz 
> ---
>  doc/filters.texi  | 10 ++
>  libavfilter/avf_showcqt.c | 85 
> +++
>  libavfilter/avf_showcqt.h |  1 +
>  3 files changed, 89 insertions(+), 7 deletions(-)
>

applied

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

Re: [FFmpeg-devel] [PATCH] avfilter/firequalizer: optimize gain/gain_entry command

[Muhammad Faiz]

On Mon, Oct 17, 2016 at 6:16 AM, Muhammad Faiz  wrote:
> do not rebuild when gain/gain_entry command are
> equal with old gain/gain_entry
>
> Signed-off-by: Muhammad Faiz 
> ---
>  libavfilter/af_firequalizer.c | 20 
>  1 file changed, 16 insertions(+), 4 deletions(-)
>

applied

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

Re: [FFmpeg-devel] FFmpeg 3.2

[Carl Eugen Hoyos]

2016-10-17 0:01 GMT+02:00 Helmut K. C. Tessarek :
> On 2016-09-27 09:30, Michael Niedermayer wrote:
>> Its long since FFmpeg 3.1, so its time to make 3.2
>> ill branch release/3.2 off master and make 3.2 in maybe about a week or
>> 2 unless something delays it
>
> What happened to 3.2?

I believe developers still work on musl patches.

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

[FFmpeg-devel] [PATCH/RFC]lavf/avidec: Do not fail for very large idx1 tags

[Carl Eugen Hoyos]

Hi!

Attached patch fixes the file mentioned in github pull request 197, 
it can be played with MPlayer, vlc, xine and totem.

Please comment, Carl Eugen
From 646a765749e08bb48f74488ad9f539cbc736673c Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Mon, 17 Oct 2016 18:25:48 +0200
Subject: [PATCH] lavf/avidec: Do not fail for very large idx1 tags.

Fixes demuxing the sample file from github pull request 197,
the size of its idx1 tag is 6171936 bytes, followed by a JUNK
tag of 9505704 bytes.
---
 libavformat/avidec.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index 2c81267..b291625 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -993,6 +993,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
 avi->movi_end  = avi->fsize;
 goto end_of_header;
 }
+/* Do not fail for very large idx1 tags */
+case MKTAG('i', 'd', 'x', '1'):
 /* skip tag */
 size += (size & 1);
 avio_skip(pb, size);
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] aiffdec: fix division by zero

[Andreas Cadhalpun]

On 17.10.2016 17:13, Michael Niedermayer wrote:
> On Mon, Oct 17, 2016 at 04:17:35PM +0200, Andreas Cadhalpun wrote:
>> On 17.10.2016 05:43, Michael Niedermayer wrote:
>>> On Sun, Oct 16, 2016 at 10:38:42PM +0200, Andreas Cadhalpun wrote:
 Signed-off-by: Andreas Cadhalpun 
 ---
  libavformat/aiffdec.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/libavformat/aiffdec.c b/libavformat/aiffdec.c
 index cd916f9..de82787 100644
 --- a/libavformat/aiffdec.c
 +++ b/libavformat/aiffdec.c
 @@ -380,7 +380,7 @@ static int aiff_read_packet(AVFormatContext *s,
  size = st->codecpar->block_align;
  break;
  default:
 -size = (MAX_SIZE / st->codecpar->block_align) * 
 st->codecpar->block_align;
 +size = st->codecpar->block_align ? (MAX_SIZE / 
 st->codecpar->block_align) * st->codecpar->block_align : MAX_SIZE;
>>>
>>> how do you reach block_align == 0 ?
>>> aiff_read_header() checks for block_align == 0
>>
>> I'm not aware of a way to reproduce this with the ffmpeg binary, however
>> an API user (e.g. my fuzz-testing-program) can change codecpar->codec_type
>> and codecpar->codec_id to force decoding a stream with a particular codec.
>>
>> However, avcodec_parameters_from_context sets codecpar->block_align to 0
>> for AVMEDIA_TYPE_VIDEO thus causing the subsequent crash.
> 
> hmm, patch is probably ok then

Pushed.

What about the similar patches for astdec and westwood_aud?

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] libavcodec: Added Selftest for libavcodec/avpacket.c

[Michael Niedermayer]

Hi

first, please dont forget to submit an application to outreachy theres
a deadline in a few hours


On Sun, Oct 16, 2016 at 04:28:23PM -0700, Thomas Turner wrote:
> Improved code coverage for libavcodec.
> Function(s) Tested: av_packet_clone().

It seems your mails get stuck in the moderation que
please make sure the address you use to send patches is subscribed
note, you can subscscribe multple addresses and set all but one to
nomail


[...]
> +static int IS_SPRINTF_ERR(int val, int tot_elem)
> +{
> +int ret = 0;
> +if(val > tot_elem){
> +perror("overflow");
> +ret = 1;
> +}
> +else if(val < 0){
> +perror("sprintf");
> +ret = 1;
> +}
> +if(ret > 0)
> +return ret;
> +
> +return ret;
> +}
> +
> +static void LOG_AVPACKET(AVPacket avpkt, const char* message)
> +{
> +int val, tot_elem;
> +
> +/* initialize array's */
> +char buf_info[256]  = {0};
> +char data_info[256] = {0};
> +char side_info[256] = {0};
> +
> +/* get buf information */
> +if(avpkt.buf){
> +val = sprintf(buf_info, "{buffer: %p,  data: %p, size: %d}",
> +avpkt.buf->buffer, avpkt.buf->data, avpkt.buf->size);
> +tot_elem = strlen(buf_info);
> +
> +/** if sprintf error found */
> +if(IS_SPRINTF_ERR(val, tot_elem))
> +exit(-1);

iam not sure what this is doing  but you should just use snprintf()
instead of sprintf()
sprintf() is not "safe" as it doesnt check its output buffer size
its more a matter or principle, not that any specific case would
actually write over the array end

[...]

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


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

Re: [FFmpeg-devel] [PATCH 2/3] lavfi/loudnorm: add an internal libebur128 library

[Moritz Barsnick]

On Mon, Oct 17, 2016 at 17:09:15 +0200, wm4 wrote:
> Does this copy parts of libebur128 to FFmpeg?
> Why?

There was a long discussion regarding this patch:

http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-April/192668.html

(in summary: "please don't require yet another small external library,
rather port it to ffmpeg and maintain it") leading to this one:

http://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195284.html

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

Re: [FFmpeg-devel] [PATCH] aiffdec: fix division by zero

[Michael Niedermayer]

On Mon, Oct 17, 2016 at 04:17:35PM +0200, Andreas Cadhalpun wrote:
> On 17.10.2016 05:43, Michael Niedermayer wrote:
> > On Sun, Oct 16, 2016 at 10:38:42PM +0200, Andreas Cadhalpun wrote:
> >> Signed-off-by: Andreas Cadhalpun 
> >> ---
> >>  libavformat/aiffdec.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavformat/aiffdec.c b/libavformat/aiffdec.c
> >> index cd916f9..de82787 100644
> >> --- a/libavformat/aiffdec.c
> >> +++ b/libavformat/aiffdec.c
> >> @@ -380,7 +380,7 @@ static int aiff_read_packet(AVFormatContext *s,
> >>  size = st->codecpar->block_align;
> >>  break;
> >>  default:
> >> -size = (MAX_SIZE / st->codecpar->block_align) * 
> >> st->codecpar->block_align;
> >> +size = st->codecpar->block_align ? (MAX_SIZE / 
> >> st->codecpar->block_align) * st->codecpar->block_align : MAX_SIZE;
> > 
> > how do you reach block_align == 0 ?
> > aiff_read_header() checks for block_align == 0
> 
> I'm not aware of a way to reproduce this with the ffmpeg binary, however
> an API user (e.g. my fuzz-testing-program) can change codecpar->codec_type
> and codecpar->codec_id to force decoding a stream with a particular codec.
> 
> However, avcodec_parameters_from_context sets codecpar->block_align to 0
> for AVMEDIA_TYPE_VIDEO thus causing the subsequent crash.

hmm, patch is probably ok then

thx

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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

Re: [FFmpeg-devel] [PATCH 2/3] lavfi/loudnorm: add an internal libebur128 library

[wm4]

On Sun, 16 Oct 2016 21:32:03 +0200
Marton Balint  wrote:

> Also contains the following changes to the library:
> - add ff_ prefix to functions
> - remove cplusplus defines.
> - add FF_ prefix to contants and some structs
> - remove true peak calculation feature, since it uses its own resampler, and
>   af_audnorm does not need it.
> - remove version info and some fprintf(stderr) functions
> - convert to use av_malloc
> - always use histogram mode for LRA calculation, otherwise LRA data is slowly
>   consuming memory making af_loudnorm unfit for 24/7 operation. It also uses a
>   BSD style linked list implementation which is probably not available on all
>   platforms. So let's just remove the classic mode which not uses histogram.
> - add ff_thread_once for calculating static histogram tables
> - convert some functions to void which cannot fail
> - remove intrinsics and some unused headers
> - add support for planar audio
> 
> Signed-off-by: Marton Balint 
> ---

Does this copy parts of libebur128 to FFmpeg?

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

Re: [FFmpeg-devel] [PATCH] add hds demuxer

[Steven Liu]

2016-10-15 21:52 GMT+08:00 Nicolas George :

> Le tridi 23 vendémiaire, an CCXXV, wm4 a écrit :
> >   XML is very complex
>
> This is the usual, and often only, argument raised in this kind of
> situation. And unfortunately, I already addressed it in this very thread.
>
> XML is very complex, yes: processing instructions, entity definitions, DTSs
> and schemas, namespaces, etc.
>
> Fortunately, we do not need that. Manifests only use the most basic XML
> features: elements, attributes, text. Parsing that is easy.
>
> Regards,
>
> --
>   Nicolas George
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
Hi guys,

  I'm trying to parse the XML now, maybe update patch later.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.2

[Michael Niedermayer]

On Mon, Oct 17, 2016 at 04:12:26PM +0200, Hendrik Leppkes wrote:
> On Mon, Oct 17, 2016 at 3:47 PM, Michael Niedermayer
>  wrote:
> > On Mon, Oct 17, 2016 at 12:01:56PM +0200, wm4 wrote:
> >> On Mon, 17 Oct 2016 04:24:40 +0200
> >> Michael Niedermayer  wrote:
> >>
> >> > On Sun, Oct 16, 2016 at 06:01:54PM -0400, Helmut K. C. Tessarek wrote:
> >> > > On 2016-09-27 09:30, Michael Niedermayer wrote:
> >> > > > Its long since FFmpeg 3.1, so its time to make 3.2
> >> > > > ill branch release/3.2 off master and make 3.2 in maybe about a week 
> >> > > > or
> >> > > > 2 unless something delays it
> >> > >
> >> > > What happened to 3.2?
> >> >
> >> > the AVFrame.pts field has been changed in master redefining ABI/API
> >> > without soname bump.
> >> >
> >> > this complicates the 3.2 release.
> >> > ATM we have 3.0 and 3.1 releases with the same sonames as git master
> >> > but they are not fully compatible due to the AVFrame.pts change
> >> > (on top of that i was a bit more busy with random stuff than i
> >> >  expected)
> >> >
> >> > the obvious solution is to bump major version of all libs. (this is
> >> > not wanted i belive though)
> >> >
> >> > the alternative is to remove the (useless) use of AVFrame.pts from
> >> > 3.0 and 3.1 and make new releases
> >> > then document in release notes that the 3.2 release cannot co-exist
> >> > with 3.0 or 3.1 prior to the last release and assume no other
> >> > application use AVFrame.pts
> >> >
> >> > Ill look at making the 3.0 and 3.1 release without AVFrame.pts use in
> >> > ffmpeg ASAP. These wont do any harm either way
> >> >
> >> > Maybe someone can write the release notes ?
> >> >
> >> > [...]
> >> >
> >>
> >> The change was backwards-compatible, as nobody should have used the pts
> >> field for decoding before.
> >
> > The field was a normal public and documented field
> > Documented in our public doxygen for 3.0 and 3.1
> > http://ffmpeg.org/doxygen/3.0/structAVFrame.html#a0452833e3ab6ddd7acbf82817a7818a4
> > http://ffmpeg.org/doxygen/3.1/structAVFrame.html#a0452833e3ab6ddd7acbf82817a7818a4
> >
> > The AVFrame.pts doxy links to examples, which use the field:
> > http://ffmpeg.org/doxygen/3.0/demuxing_decoding_8c-example.html#a41
> > http://ffmpeg.org/doxygen/3.1/demuxing_decoding_8c-example.html#a41
> >
> >
> 
> The documentation is hardly very enlightining on any level. Which
> time_base does it refer to, even? AVFrames can come from various
> sources, and there is various time_bases involved.

AVFrame was in libavcodec, there was just one timebase in libavcodec
when AVFrame was moved to libavutil the ambiguity of "what timebase"
was introduced


> Or why does it not
> document that its basically unused for decoding, and only used for
> encoding and filtering?
> Not to mention that the field was 99% of the time unset during
> decoding, and when it was set (by like 2 video decoders that didnt
> know any better), it was actually using the pkt timebase (ie. a clone
> of pkt_pts).

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

Re: [FFmpeg-devel] FFmpeg 3.2

[Michael Niedermayer]

On Mon, Oct 17, 2016 at 03:56:37PM +0200, wm4 wrote:
> On Mon, 17 Oct 2016 15:47:06 +0200
> Michael Niedermayer  wrote:
> 
> > On Mon, Oct 17, 2016 at 12:01:56PM +0200, wm4 wrote:
> > > On Mon, 17 Oct 2016 04:24:40 +0200
> > > Michael Niedermayer  wrote:
> > >   
> > > > On Sun, Oct 16, 2016 at 06:01:54PM -0400, Helmut K. C. Tessarek wrote:  
> > > > > On 2016-09-27 09:30, Michael Niedermayer wrote:
> > > > > > Its long since FFmpeg 3.1, so its time to make 3.2
> > > > > > ill branch release/3.2 off master and make 3.2 in maybe about a 
> > > > > > week or
> > > > > > 2 unless something delays it
> > > > > 
> > > > > What happened to 3.2?
> > > > 
> > > > the AVFrame.pts field has been changed in master redefining ABI/API
> > > > without soname bump.
> > > > 
> > > > this complicates the 3.2 release.
> > > > ATM we have 3.0 and 3.1 releases with the same sonames as git master
> > > > but they are not fully compatible due to the AVFrame.pts change
> > > > (on top of that i was a bit more busy with random stuff than i
> > > >  expected)
> > > > 
> > > > the obvious solution is to bump major version of all libs. (this is
> > > > not wanted i belive though)
> > > > 
> > > > the alternative is to remove the (useless) use of AVFrame.pts from
> > > > 3.0 and 3.1 and make new releases
> > > > then document in release notes that the 3.2 release cannot co-exist
> > > > with 3.0 or 3.1 prior to the last release and assume no other
> > > > application use AVFrame.pts
> > > > 
> > > > Ill look at making the 3.0 and 3.1 release without AVFrame.pts use in
> > > > ffmpeg ASAP. These wont do any harm either way
> > > > 
> > > > Maybe someone can write the release notes ?
> > > > 
> > > > [...]
> > > >   
> > > 
> > > The change was backwards-compatible, as nobody should have used the pts
> > > field for decoding before.  
> > 
> > The field was a normal public and documented field
> > Documented in our public doxygen for 3.0 and 3.1
> > http://ffmpeg.org/doxygen/3.0/structAVFrame.html#a0452833e3ab6ddd7acbf82817a7818a4
> > http://ffmpeg.org/doxygen/3.1/structAVFrame.html#a0452833e3ab6ddd7acbf82817a7818a4
> > 
> > The AVFrame.pts doxy links to examples, which use the field:
> > http://ffmpeg.org/doxygen/3.0/demuxing_decoding_8c-example.html#a41
> > http://ffmpeg.org/doxygen/3.1/demuxing_decoding_8c-example.html#a41
> > 
> > 
> > > The fact that ffmpeg.c couldn't use its own
> > > API correctly is not of matter.  
> > 
> > 
> > [...]
> 
> This doesn't change anything about what I said. The example merely
> dumps some garbage values.
> 

> How do you expect downstream code to break with the change, and which
> actual downstream projects do break?

I hope none break, what might happen though is
the way ffmpeg.c breaks if i put the AVFrame.pts code back and
run "make fate"

This is the one specific breakage i know of.


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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

Re: [FFmpeg-devel] [PATCH] aiffdec: fix division by zero

[Andreas Cadhalpun]

On 17.10.2016 05:43, Michael Niedermayer wrote:
> On Sun, Oct 16, 2016 at 10:38:42PM +0200, Andreas Cadhalpun wrote:
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavformat/aiffdec.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/aiffdec.c b/libavformat/aiffdec.c
>> index cd916f9..de82787 100644
>> --- a/libavformat/aiffdec.c
>> +++ b/libavformat/aiffdec.c
>> @@ -380,7 +380,7 @@ static int aiff_read_packet(AVFormatContext *s,
>>  size = st->codecpar->block_align;
>>  break;
>>  default:
>> -size = (MAX_SIZE / st->codecpar->block_align) * 
>> st->codecpar->block_align;
>> +size = st->codecpar->block_align ? (MAX_SIZE / 
>> st->codecpar->block_align) * st->codecpar->block_align : MAX_SIZE;
> 
> how do you reach block_align == 0 ?
> aiff_read_header() checks for block_align == 0

I'm not aware of a way to reproduce this with the ffmpeg binary, however
an API user (e.g. my fuzz-testing-program) can change codecpar->codec_type
and codecpar->codec_id to force decoding a stream with a particular codec.

However, avcodec_parameters_from_context sets codecpar->block_align to 0
for AVMEDIA_TYPE_VIDEO thus causing the subsequent crash.

It's similar for the other two division by zero patches.

So an alternative approach would be to set all parameter fields from the codec
in avcodec_parameters_from_context, but I prefer making the code more robust.

Best regards,
Andreas

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

Re: [FFmpeg-devel] FFmpeg 3.2

[Hendrik Leppkes]

On Mon, Oct 17, 2016 at 3:47 PM, Michael Niedermayer
 wrote:
> On Mon, Oct 17, 2016 at 12:01:56PM +0200, wm4 wrote:
>> On Mon, 17 Oct 2016 04:24:40 +0200
>> Michael Niedermayer  wrote:
>>
>> > On Sun, Oct 16, 2016 at 06:01:54PM -0400, Helmut K. C. Tessarek wrote:
>> > > On 2016-09-27 09:30, Michael Niedermayer wrote:
>> > > > Its long since FFmpeg 3.1, so its time to make 3.2
>> > > > ill branch release/3.2 off master and make 3.2 in maybe about a week or
>> > > > 2 unless something delays it
>> > >
>> > > What happened to 3.2?
>> >
>> > the AVFrame.pts field has been changed in master redefining ABI/API
>> > without soname bump.
>> >
>> > this complicates the 3.2 release.
>> > ATM we have 3.0 and 3.1 releases with the same sonames as git master
>> > but they are not fully compatible due to the AVFrame.pts change
>> > (on top of that i was a bit more busy with random stuff than i
>> >  expected)
>> >
>> > the obvious solution is to bump major version of all libs. (this is
>> > not wanted i belive though)
>> >
>> > the alternative is to remove the (useless) use of AVFrame.pts from
>> > 3.0 and 3.1 and make new releases
>> > then document in release notes that the 3.2 release cannot co-exist
>> > with 3.0 or 3.1 prior to the last release and assume no other
>> > application use AVFrame.pts
>> >
>> > Ill look at making the 3.0 and 3.1 release without AVFrame.pts use in
>> > ffmpeg ASAP. These wont do any harm either way
>> >
>> > Maybe someone can write the release notes ?
>> >
>> > [...]
>> >
>>
>> The change was backwards-compatible, as nobody should have used the pts
>> field for decoding before.
>
> The field was a normal public and documented field
> Documented in our public doxygen for 3.0 and 3.1
> http://ffmpeg.org/doxygen/3.0/structAVFrame.html#a0452833e3ab6ddd7acbf82817a7818a4
> http://ffmpeg.org/doxygen/3.1/structAVFrame.html#a0452833e3ab6ddd7acbf82817a7818a4
>
> The AVFrame.pts doxy links to examples, which use the field:
> http://ffmpeg.org/doxygen/3.0/demuxing_decoding_8c-example.html#a41
> http://ffmpeg.org/doxygen/3.1/demuxing_decoding_8c-example.html#a41
>
>

The documentation is hardly very enlightining on any level. Which
time_base does it refer to, even? AVFrames can come from various
sources, and there is various time_bases involved. Or why does it not
document that its basically unused for decoding, and only used for
encoding and filtering?
Not to mention that the field was 99% of the time unset during
decoding, and when it was set (by like 2 video decoders that didnt
know any better), it was actually using the pkt timebase (ie. a clone
of pkt_pts).

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

Re: [FFmpeg-devel] FFmpeg 3.2

[wm4]

On Mon, 17 Oct 2016 15:47:06 +0200
Michael Niedermayer  wrote:

> On Mon, Oct 17, 2016 at 12:01:56PM +0200, wm4 wrote:
> > On Mon, 17 Oct 2016 04:24:40 +0200
> > Michael Niedermayer  wrote:
> >   
> > > On Sun, Oct 16, 2016 at 06:01:54PM -0400, Helmut K. C. Tessarek wrote:  
> > > > On 2016-09-27 09:30, Michael Niedermayer wrote:
> > > > > Its long since FFmpeg 3.1, so its time to make 3.2
> > > > > ill branch release/3.2 off master and make 3.2 in maybe about a week 
> > > > > or
> > > > > 2 unless something delays it
> > > > 
> > > > What happened to 3.2?
> > > 
> > > the AVFrame.pts field has been changed in master redefining ABI/API
> > > without soname bump.
> > > 
> > > this complicates the 3.2 release.
> > > ATM we have 3.0 and 3.1 releases with the same sonames as git master
> > > but they are not fully compatible due to the AVFrame.pts change
> > > (on top of that i was a bit more busy with random stuff than i
> > >  expected)
> > > 
> > > the obvious solution is to bump major version of all libs. (this is
> > > not wanted i belive though)
> > > 
> > > the alternative is to remove the (useless) use of AVFrame.pts from
> > > 3.0 and 3.1 and make new releases
> > > then document in release notes that the 3.2 release cannot co-exist
> > > with 3.0 or 3.1 prior to the last release and assume no other
> > > application use AVFrame.pts
> > > 
> > > Ill look at making the 3.0 and 3.1 release without AVFrame.pts use in
> > > ffmpeg ASAP. These wont do any harm either way
> > > 
> > > Maybe someone can write the release notes ?
> > > 
> > > [...]
> > >   
> > 
> > The change was backwards-compatible, as nobody should have used the pts
> > field for decoding before.  
> 
> The field was a normal public and documented field
> Documented in our public doxygen for 3.0 and 3.1
> http://ffmpeg.org/doxygen/3.0/structAVFrame.html#a0452833e3ab6ddd7acbf82817a7818a4
> http://ffmpeg.org/doxygen/3.1/structAVFrame.html#a0452833e3ab6ddd7acbf82817a7818a4
> 
> The AVFrame.pts doxy links to examples, which use the field:
> http://ffmpeg.org/doxygen/3.0/demuxing_decoding_8c-example.html#a41
> http://ffmpeg.org/doxygen/3.1/demuxing_decoding_8c-example.html#a41
> 
> 
> > The fact that ffmpeg.c couldn't use its own
> > API correctly is not of matter.  
> 
> 
> [...]

This doesn't change anything about what I said. The example merely
dumps some garbage values.

How do you expect downstream code to break with the change, and which
actual downstream projects do break?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] matroskadec: fix NULL pointer dereference

[Andreas Cadhalpun]

On 17.10.2016 15:44, James Almer wrote:
> On 10/17/2016 4:47 AM, Benoit Fouet wrote:
>> On 17/10/2016 06:49, James Almer wrote:
>>> On 10/16/2016 9:30 PM, James Almer wrote:
 On 10/16/2016 5:11 PM, Andreas Cadhalpun wrote:
> The problem was introduced in commit 1273bc6.
>
> Signed-off-by: Andreas Cadhalpun 
> ---
>   libavformat/matroskadec.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 8847c62..a5d3c0e 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -1759,7 +1759,7 @@ static int mkv_field_order(MatroskaDemuxContext 
> *matroska, int64_t field_order)
> /* workaround a bug in our Matroska muxer, introduced in version 
> 57.36 alongside
>* this function, and fixed in 57.52 */
> -if (sscanf(matroska->muxingapp, "Lavf%d.%d.%d", , , 
> ) == 3)
> +if (matroska->muxingapp && sscanf(matroska->muxingapp, 
> "Lavf%d.%d.%d", , , ) == 3)
 LGTM.

 Matroska files are supposed to always have that element, but even ffmpeg 
 used
 to mux files without it at some point when bitexact flag was enabled, so i
 guess plenty of files out there are missing it.

>   bttb = (major == 57 && minor >= 36 && minor <= 51 && micro >= 
> 100);
> switch (field_order) {
>
>>> Just tried a file missing the muxingapp element, meaning matroska->muxingapp
>>> is NULL, and sscanf simply returns -1 and sets errno to EINVAL.
>>>
>>> Where does it crash for you and using what file?
>>
>> FWIW, I've just written a quick test on my machine, and an "sscanf(NULL, 
>> "%d", )" segfaults.

With glibc it crashes:
$ gdb --batch -ex r -ex bt -ex q --args ./ffmpeg_g -i 
./id_b42167853bffe74a3a93ea312837dd8a2a25a951.matroska -f null /dev/null
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
ffmpeg version N-82012-gd3874b7 Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 6.2.0 (Debian 6.2.0-6) 20161010
  configuration: --disable-optimizations
  libavutil  55. 32.100 / 55. 32.100
  libavcodec 57. 61.103 / 57. 61.103
  libavformat57. 52.100 / 57. 52.100
  libavdevice57.  0.102 / 57.  0.102
  libavfilter 6. 64.100 /  6. 64.100
  libswscale  4.  1.100 /  4.  1.100
  libswresample   2.  2.100 /  2.  2.100
[matroska,webm @ 0x2380fc0] Unknown EBML doctype 'ma@roUka'
Truncating packet of size 134217728 to 1551
Truncating packet of size 1431346 to 1507
Truncating packet of size 4467 to 1401
[matroska,webm @ 0x2380fc0] Duplicate element
[matroska,webm @ 0x2380fc0] Unknown/unsupported AVCodecID ��OPU=.
Ignoring attempt to set invalid timebase 0/1 for st:0

Program received signal SIGSEGV, Segmentation fault.
rawmemchr () at ../sysdeps/x86_64/rawmemchr.S:37
37  ../sysdeps/x86_64/rawmemchr.S: Datei oder Verzeichnis nicht gefunden.
#0  rawmemchr () at ../sysdeps/x86_64/rawmemchr.S:37
#1  0x74b383a2 in _IO_str_init_static_internal 
(sf=sf@entry=0x7fffd360, ptr=ptr@entry=0x0, size=size@entry=0, 
pstart=pstart@entry=0x0) at strops.c:41
#2  0x74b27567 in __GI___isoc99_vsscanf (string=0x0, format=0x15e597c 
"Lavf%d.%d.%d", args=args@entry=0x7fffd488) at isoc99_vsscanf.c:41
#3  0x74b27507 in __isoc99_sscanf (s=, format=) at isoc99_sscanf.c:31
#4  0x006ca2eb in mkv_field_order (matroska=0x2381ba0, field_order=2) 
at src/libavformat/matroskadec.c:1762
#5  0x006cc0c2 in matroska_parse_tracks (s=0x2380fc0) at 
src/libavformat/matroskadec.c:2293
#6  0x006ccc83 in matroska_read_header (s=0x2380fc0) at 
src/libavformat/matroskadec.c:2470
#7  0x007bbd13 in avformat_open_input (ps=0x7fffd948, 
filename=0x7fffe3a4 
"./id_b42167853bffe74a3a93ea312837dd8a2a25a951.matroska", fmt=0x0, 
options=0x2380d68) at src/libavformat/utils.c:587
#8  0x00411aeb in open_input_file (o=0x7fffda50, 
filename=0x7fffe3a4 
"./id_b42167853bffe74a3a93ea312837dd8a2a25a951.matroska") at 
src/ffmpeg_opt.c:997
#9  0x0041a9af in open_files (l=0x2380c98, inout=0x154c797 "input", 
open_file=0x411330 ) at src/ffmpeg_opt.c:3135
#10 0x0041ab10 in ffmpeg_parse_options (argc=6, argv=0x7fffe048) at 
src/ffmpeg_opt.c:3175
#11 0x0042e78a in main (argc=6, argv=0x7fffe048) at 
src/ffmpeg.c:4564

> Guess it's up to the implementation, then. I tried with mingw-w64 only.
> The documentation for sscanf says it sets errno to EINVAL if *format is NULL,
> but doesn't mention *str.
> 
> Patch still LGTM. It doesn't hurt either way.

Pushed.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] lavc/videotoolboxenc: implement a53cc

[Richard Kern]

> On Sep 19, 2016, at 10:30 AM, Aman Gupta  wrote:
> 
> 
> 
> On Monday, September 19, 2016, Richard Kern  > wrote:
> 
>> On Sep 10, 2016, at 10:33 PM, Aman Gupta > wrote:
>> 
>> 
>> 
>> On Sunday, September 11, 2016, Richard Kern > wrote:
>> 
>> > On Sep 8, 2016, at 4:19 AM, Aman Gupta > wrote:
>> >
>> > From: Aman Gupta >
>> >
>> > ---
>> > libavcodec/videotoolboxenc.c | 76 
>> > ++--
>> > 1 file changed, 67 insertions(+), 9 deletions(-)
>> >
>> > diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
>> > index 4345ca3..859dde9 100644
>> > --- a/libavcodec/videotoolboxenc.c
>> > +++ b/libavcodec/videotoolboxenc.c
>> > @@ -32,6 +32,7 @@
>> > #include "libavutil/pixdesc.h"
>> > #include "internal.h"
>> > #include 
>> > +#include "h264.h"
>> >
>> > #if !CONFIG_VT_BT2020
>> > # define kCVImageBufferColorPrimaries_ITU_R_2020   CFSTR("ITU_R_2020")
>> > @@ -55,8 +56,14 @@ typedef enum VTH264Entropy{
>> >
>> > static const uint8_t start_code[] = { 0, 0, 0, 1 };
>> >
>> > +typedef struct ExtraSEI {
>> > +  void *data;
>> > +  size_t size;
>> > +} ExtraSEI;
>> > +
>> > typedef struct BufNode {
>> > CMSampleBufferRef cm_buffer;
>> > +ExtraSEI *sei;
>> > struct BufNode* next;
>> > int error;
>> > } BufNode;
>> > @@ -94,6 +101,7 @@ typedef struct VTEncContext {
>> > bool flushing;
>> > bool has_b_frames;
>> > bool warned_color_range;
>> > +bool a53_cc;
>> > } VTEncContext;
>> >
>> > static int vtenc_populate_extradata(AVCodecContext   *avctx,
>> > @@ -136,7 +144,7 @@ static void set_async_error(VTEncContext *vtctx, int 
>> > err)
>> > pthread_mutex_unlock(>lock);
>> > }
>> >
>> > -static int vtenc_q_pop(VTEncContext *vtctx, bool wait, CMSampleBufferRef 
>> > *buf)
>> > +static int vtenc_q_pop(VTEncContext *vtctx, bool wait, CMSampleBufferRef 
>> > *buf, ExtraSEI **sei)
>> > {
>> > BufNode *info;
>> >
>> > @@ -173,6 +181,12 @@ static int vtenc_q_pop(VTEncContext *vtctx, bool 
>> > wait, CMSampleBufferRef *buf)
>> > pthread_mutex_unlock(>lock);
>> >
>> > *buf = info->cm_buffer;
>> > +if (sei && *buf) {
>> > +*sei = info->sei;
>> > +} else if (info->sei) {
>> > +if (info->sei->data) av_free(info->sei->data);
>> > +av_free(info->sei);
>> > +}
>> > av_free(info);
>> >
>> > vtctx->frame_ct_out++;
>> > @@ -180,7 +194,7 @@ static int vtenc_q_pop(VTEncContext *vtctx, bool wait, 
>> > CMSampleBufferRef *buf)
>> > return 0;
>> > }
>> >
>> > -static void vtenc_q_push(VTEncContext *vtctx, CMSampleBufferRef buffer)
>> > +static void vtenc_q_push(VTEncContext *vtctx, CMSampleBufferRef buffer, 
>> > ExtraSEI *sei)
>> > {
>> > BufNode *info = av_malloc(sizeof(BufNode));
>> > if (!info) {
>> > @@ -190,6 +204,7 @@ static void vtenc_q_push(VTEncContext *vtctx, 
>> > CMSampleBufferRef buffer)
>> >
>> > CFRetain(buffer);
>> > info->cm_buffer = buffer;
>> > +info->sei = sei;
>> > info->next = NULL;
>> >
>> > pthread_mutex_lock(>lock);
>> > @@ -420,6 +435,7 @@ static void vtenc_output_callback(
>> > {
>> > AVCodecContext *avctx = ctx;
>> > VTEncContext   *vtctx = avctx->priv_data;
>> > +ExtraSEI *sei = sourceFrameCtx;
>> >
>> > if (vtctx->async_error) {
>> > if(sample_buffer) CFRelease(sample_buffer);
>> > @@ -440,7 +456,7 @@ static void vtenc_output_callback(
>> > }
>> > }
>> >
>> > -vtenc_q_push(vtctx, sample_buffer);
>> > +vtenc_q_push(vtctx, sample_buffer, sei);
>> > }
>> >
>> > static int get_length_code_size(
>> > @@ -1258,7 +1274,8 @@ static int copy_replace_length_codes(
>> > static int vtenc_cm_to_avpacket(
>> > AVCodecContext*avctx,
>> > CMSampleBufferRef sample_buffer,
>> > -AVPacket  *pkt)
>> > +AVPacket  *pkt,
>> > +ExtraSEI  *sei)
>> > {
>> > VTEncContext *vtctx = avctx->priv_data;
>> >
>> > @@ -1269,6 +1286,7 @@ static int vtenc_cm_to_avpacket(
>> > size_t  header_size = 0;
>> > size_t  in_buf_size;
>> > size_t  out_buf_size;
>> > +size_t  sei_nalu_size = 0;
>> > int64_t dts_delta;
>> > int64_t time_base_num;
>> > int nalu_count;
>> > @@ -1298,9 +1316,14 @@ static int vtenc_cm_to_avpacket(
>> > if(status)
>> > return status;
>> >
>> > +if (sei) {
>> > +sei_nalu_size = sizeof(start_code) + 3 + sei->size + 1;
>> > +}
>> > +
>> > in_buf_size = CMSampleBufferGetTotalSampleSize(sample_buffer);
>> > out_buf_size = header_size +
>> >in_buf_size +
>> > +   sei_nalu_size +
>> >nalu_count * ((int)sizeof(start_code) - 
>> > (int)length_code_size);
>> >
>> > status = ff_alloc_packet2(avctx, pkt, out_buf_size, out_buf_size);
>> > @@ -1317,7 +1340,7 @@ static int vtenc_cm_to_avpacket(
>> > 

Re: [FFmpeg-devel] FFmpeg 3.2

[Michael Niedermayer]

On Mon, Oct 17, 2016 at 12:01:56PM +0200, wm4 wrote:
> On Mon, 17 Oct 2016 04:24:40 +0200
> Michael Niedermayer  wrote:
> 
> > On Sun, Oct 16, 2016 at 06:01:54PM -0400, Helmut K. C. Tessarek wrote:
> > > On 2016-09-27 09:30, Michael Niedermayer wrote:  
> > > > Its long since FFmpeg 3.1, so its time to make 3.2
> > > > ill branch release/3.2 off master and make 3.2 in maybe about a week or
> > > > 2 unless something delays it  
> > > 
> > > What happened to 3.2?  
> > 
> > the AVFrame.pts field has been changed in master redefining ABI/API
> > without soname bump.
> > 
> > this complicates the 3.2 release.
> > ATM we have 3.0 and 3.1 releases with the same sonames as git master
> > but they are not fully compatible due to the AVFrame.pts change
> > (on top of that i was a bit more busy with random stuff than i
> >  expected)
> > 
> > the obvious solution is to bump major version of all libs. (this is
> > not wanted i belive though)
> > 
> > the alternative is to remove the (useless) use of AVFrame.pts from
> > 3.0 and 3.1 and make new releases
> > then document in release notes that the 3.2 release cannot co-exist
> > with 3.0 or 3.1 prior to the last release and assume no other
> > application use AVFrame.pts
> > 
> > Ill look at making the 3.0 and 3.1 release without AVFrame.pts use in
> > ffmpeg ASAP. These wont do any harm either way
> > 
> > Maybe someone can write the release notes ?
> > 
> > [...]
> > 
> 
> The change was backwards-compatible, as nobody should have used the pts
> field for decoding before.

The field was a normal public and documented field
Documented in our public doxygen for 3.0 and 3.1
http://ffmpeg.org/doxygen/3.0/structAVFrame.html#a0452833e3ab6ddd7acbf82817a7818a4
http://ffmpeg.org/doxygen/3.1/structAVFrame.html#a0452833e3ab6ddd7acbf82817a7818a4

The AVFrame.pts doxy links to examples, which use the field:
http://ffmpeg.org/doxygen/3.0/demuxing_decoding_8c-example.html#a41
http://ffmpeg.org/doxygen/3.1/demuxing_decoding_8c-example.html#a41


> The fact that ffmpeg.c couldn't use its own
> API correctly is not of matter.


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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/mov: zero initialize codec_name in mov_parse_stsd_video()

[James Almer]

On 10/17/2016 10:05 AM, Benoit Fouet wrote:
> Hi,
> 
> 
> On 17/10/2016 02:34, James Almer wrote:
>> Fixes valgrind warning about "Conditional jump or move depends on 
>> uninitialised value(s)"
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavformat/mov.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index add1812..7462ecf 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -1802,7 +1802,7 @@ static int mov_codec_id(AVStream *st, uint32_t format)
>>  static void mov_parse_stsd_video(MOVContext *c, AVIOContext *pb,
>>   AVStream *st, MOVStreamContext *sc)
>>  {
>> -uint8_t codec_name[32];
>> +uint8_t codec_name[32] = { 0 };
>>  int64_t stsd_start;
>>  unsigned int len;
>>  
> 
> Do we really need to "fix" false positive from Valgrind?

I don't see why not. It's a one line change that zero initializes
stack and removes noise from the valgrind fate clients, making actual
memleaks and such in the future easy to notice after a quick glance.

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

Re: [FFmpeg-devel] comma at the end of enumerator lists

[wm4]

On Mon, 17 Oct 2016 13:09:36 +0200
Michael Niedermayer  wrote:

> On Mon, Oct 17, 2016 at 10:07:42AM +0200, Nicolas George wrote:
> > Le sextidi 26 vendémiaire, an CCXXV, Michael Niedermayer a écrit :  
> > > probably, yes  
> > 
> > I would have said exactly the opposite. It is nothing but a waste of time
> > and a pollution of the history.  
> 
> My idea here is to maximize the number of developers
> And if in cases where one doesnt really care much either way and
> someone else seems caring more one says, "ok" that may result in a happy
> new contributor.
> Saying "no" is more likely to turn someone away.
> and again, it doesnt really matter if the , is there after a
> final sentinel /count entry as no next field would ever be added

Are you kidding me. Patches should be judged on their technical merrit,
not whether you might piss someone off by rejecting it.

Rather, you'd keep someone on one's toes by giving him hope that his
patch might be accepted - and making him waste some more time on it.
Just with the result that other devs might reject the patch anyway,
which would make for a frustrating experience.

> And ATM the "," thing is not consistent either way
> git grep '_NB$' |wc
>  53 1142123
> git grep '_NB,$' |wc
>  30  761499
> 
> Making this more consistent shouldnt be a bad thing if the people who
> want it also do the work ... (and it doesnt end as some rule that
> causes future work to people not caring ...)
> 
> [...]

That's true, but your grep has a huge number of false positives.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/tests/gitignore: add fifo_muxer entry

[Jan Sebechlebsky]

On 10/15/2016 06:32 PM, Zhao Zhili wrote:


 From a3ee9afc37331315e4ec57f1ebf881779b62bf60 Mon Sep 17 00:00:00 2001
From: Zhao Zhili 
Date: Sun, 16 Oct 2016 00:09:25 +0800
Subject: [PATCH] avformat/tests/gitignore: add fifo_muxer entry

---
  libavformat/tests/.gitignore | 1 +
  1 file changed, 1 insertion(+)

diff --git a/libavformat/tests/.gitignore b/libavformat/tests/.gitignore
index c8adb86..7ceb7a3 100644
--- a/libavformat/tests/.gitignore
+++ b/libavformat/tests/.gitignore
@@ -1,3 +1,4 @@
+/fifo_muxer
  /movenc
  /noproxy
  /rtmpdh

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

[FFmpeg-devel] [PATCH v2] libavformat/tee: Add fifo support for tee

[sebechlebskyjan]

From: Jan Sebechlebsky 

Signed-off-by: Jan Sebechlebsky 
---
 Thanks for noticing, I've fixed the patch 
 (also some minor formatting issues I've noticed).

 doc/muxers.texi   | 20 +
 libavformat/tee.c | 87 ++-
 2 files changed, 106 insertions(+), 1 deletion(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index dbe53f5..7b4e165 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1473,6 +1473,7 @@ Specify whether to remove all fragments when finished. 
Default 0 (do not remove)
 
 @end table
 
+@anchor{fifo}
 @section fifo
 
 The fifo pseudo-muxer allows the separation of encoding and muxing by using
@@ -1580,6 +1581,18 @@ with the tee muxer; encoding can be a very expensive 
process. It is not
 useful when using the libavformat API directly because it is then possible
 to feed the same packets to several muxers directly.
 
+@table @option
+
+@item use_fifo @var{bool}
+If set to 1, slave outputs will be processed in separate thread using 
@ref{fifo}
+muxer. This allows to compensate for different speed/latency/reliability of
+outputs and setup transparent recovery. By default this feature is turned off.
+
+@item fifo_options
+Options to pass to fifo pseudo-muxer instances. See @ref{fifo}.
+
+@end table
+
 The slave outputs are specified in the file name given to the muxer,
 separated by '|'. If any of the slave name contains the '|' separator,
 leading or trailing spaces or any special character, it must be
@@ -1601,6 +1614,13 @@ output name suffix.
 Specify a list of bitstream filters to apply to the specified
 output.
 
+@item use_fifo @var{bool}
+This allows to override tee muxer use_fifo option for individual slave muxer.
+
+@item fifo_options
+This allows to override tee muxer fifo_options for individual slave muxer.
+See @ref{fifo}.
+
 It is possible to specify to which streams a given bitstream filter
 applies, by appending a stream specifier to the option separated by
 @code{/}. @var{spec} must be a stream specifier (see @ref{Format
diff --git a/libavformat/tee.c b/libavformat/tee.c
index d59ad4d..c668e95 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -40,6 +40,8 @@ typedef struct {
 AVBSFContext **bsfs; ///< bitstream filters per stream
 
 SlaveFailurePolicy on_fail;
+int use_fifo;
+AVDictionary *fifo_options;
 
 /** map from input to output streams indexes,
  * disabled output streams are set to -1 */
@@ -52,15 +54,28 @@ typedef struct TeeContext {
 unsigned nb_slaves;
 unsigned nb_alive;
 TeeSlave *slaves;
+int use_fifo;
+AVDictionary *fifo_options;
+char *fifo_options_str;
 } TeeContext;
 
 static const char *const slave_delim = "|";
 static const char *const slave_bsfs_spec_sep = "/";
 static const char *const slave_select_sep = ",";
 
+#define OFFSET(x) offsetof(TeeContext, x)
+static const AVOption options[] = {
+{"use_fifo", "Use fifo pseudo-muxer to separate actual muxers from 
encoder",
+ OFFSET(use_fifo), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, 
AV_OPT_FLAG_ENCODING_PARAM},
+{"fifo_options", "fifo pseudo-muxer options", OFFSET(fifo_options_str),
+ AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, AV_OPT_FLAG_ENCODING_PARAM},
+{NULL}
+};
+
 static const AVClass tee_muxer_class = {
 .class_name = "Tee muxer",
 .item_name  = av_default_item_name,
+.option = options,
 .version= LIBAVUTIL_VERSION_INT,
 };
 
@@ -81,6 +96,27 @@ static inline int parse_slave_failure_policy_option(const 
char *opt, TeeSlave *t
 return AVERROR(EINVAL);
 }
 
+static int parse_slave_fifo_options(const char *use_fifo,
+const char *fifo_options, TeeSlave 
*tee_slave)
+{
+int ret = 0;
+
+if (use_fifo) {
+if (av_match_name(use_fifo, "true,y,yes,enable,enabled,on,1")) {
+tee_slave->use_fifo = 1;
+} else if (av_match_name(use_fifo, 
"false,n,no,disable,disabled,off,0")) {
+tee_slave->use_fifo = 0;
+} else {
+return AVERROR(EINVAL);
+}
+}
+
+if (fifo_options)
+ret = av_dict_parse_string(_slave->fifo_options, fifo_options, 
"=", ":", 0);
+
+return ret;
+}
+
 static int close_slave(TeeSlave *tee_slave)
 {
 AVFormatContext *avf;
@@ -125,6 +161,7 @@ static int open_slave(AVFormatContext *avf, char *slave, 
TeeSlave *tee_slave)
 AVDictionaryEntry *entry;
 char *filename;
 char *format = NULL, *select = NULL, *on_fail = NULL;
+char *use_fifo = NULL, *fifo_options_str = NULL;
 AVFormatContext *avf2 = NULL;
 AVStream *st, *st2;
 int stream_count;
@@ -145,6 +182,8 @@ static int open_slave(AVFormatContext *avf, char *slave, 
TeeSlave *tee_slave)
 STEAL_OPTION("f", format);
 STEAL_OPTION("select", select);
 STEAL_OPTION("onfail", on_fail);
+STEAL_OPTION("use_fifo", use_fifo);
+STEAL_OPTION("fifo_options", 

Re: [FFmpeg-devel] comma at the end of enumerator lists

[Clément Bœsch]

On Mon, Oct 17, 2016 at 12:11:08AM +0200, Michael Behrisch wrote:
> Am 16.10.2016 um 23:24 schrieb Clément Bœsch:
> > On Sun, Oct 16, 2016 at 09:46:20PM +0200, Michael Behrisch wrote:
> >> Hi all,
> >> first of all thanks for providing this great library.
> >>
> >> Today my pull request https://github.com/FFmpeg/FFmpeg/pull/237 has been
> >> rejected which tried to remove the comma at the end of enumerator lists
> >> which triggers a warning when compiling with gcc and -Wpedantic. I still
> >> think it could be a good idea to remove this, especially in the cases
> >> where the enumerator list already ends in some _NB item, which seems to
> >> be the final one "forever", but I am here to learn :-).
> > 
> > The enum with a final _NB (or similar) entry are the only ones where
> > removing the comma is relevant.
> > 
> 
> So would a patch removing only those have a chance of being accepted?
> 

I don't really see a reason not to as long as the changes are squashed at
least per-lib, yes.

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] matroskadec: fix NULL pointer dereference

[Benoit Fouet]

Hi,

On 17/10/2016 06:49, James Almer wrote:

On 10/16/2016 9:30 PM, James Almer wrote:

On 10/16/2016 5:11 PM, Andreas Cadhalpun wrote:

The problem was introduced in commit 1273bc6.

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

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 8847c62..a5d3c0e 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1759,7 +1759,7 @@ static int mkv_field_order(MatroskaDemuxContext 
*matroska, int64_t field_order)
  
  /* workaround a bug in our Matroska muxer, introduced in version 57.36 alongside

   * this function, and fixed in 57.52 */
-if (sscanf(matroska->muxingapp, "Lavf%d.%d.%d", , , ) == 
3)
+if (matroska->muxingapp && sscanf(matroska->muxingapp, "Lavf%d.%d.%d", , 
, ) == 3)

LGTM.

Matroska files are supposed to always have that element, but even ffmpeg used
to mux files without it at some point when bitexact flag was enabled, so i
guess plenty of files out there are missing it.


  bttb = (major == 57 && minor >= 36 && minor <= 51 && micro >= 100);
  
  switch (field_order) {



Just tried a file missing the muxingapp element, meaning matroska->muxingapp
is NULL, and sscanf simply returns -1 and sets errno to EINVAL.

Where does it crash for you and using what file?


FWIW, I've just written a quick test on my machine, and an "sscanf(NULL, 
"%d", )" segfaults.


--
Ben

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

Re: [FFmpeg-devel] comma at the end of enumerator lists

[Michael Niedermayer]

On Mon, Oct 17, 2016 at 10:07:42AM +0200, Nicolas George wrote:
> Le sextidi 26 vendémiaire, an CCXXV, Michael Niedermayer a écrit :
> > probably, yes
> 
> I would have said exactly the opposite. It is nothing but a waste of time
> and a pollution of the history.

My idea here is to maximize the number of developers
And if in cases where one doesnt really care much either way and
someone else seems caring more one says, "ok" that may result in a happy
new contributor.
Saying "no" is more likely to turn someone away.
and again, it doesnt really matter if the , is there after a
final sentinel /count entry as no next field would ever be added

And ATM the "," thing is not consistent either way
git grep '_NB$' |wc
 53 1142123
git grep '_NB,$' |wc
 30  761499

Making this more consistent shouldnt be a bad thing if the people who
want it also do the work ... (and it doesnt end as some rule that
causes future work to people not caring ...)

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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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

Re: [FFmpeg-devel] [PATCH] matroskadec: fix NULL pointer dereference

[Hendrik Leppkes]

On Mon, Oct 17, 2016 at 12:13 PM, wm4  wrote:
> On Sun, 16 Oct 2016 22:11:03 +0200
> Andreas Cadhalpun  wrote:
>
>> The problem was introduced in commit 1273bc6.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavformat/matroskadec.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
>> index 8847c62..a5d3c0e 100644
>> --- a/libavformat/matroskadec.c
>> +++ b/libavformat/matroskadec.c
>> @@ -1759,7 +1759,7 @@ static int mkv_field_order(MatroskaDemuxContext 
>> *matroska, int64_t field_order)
>>
>>  /* workaround a bug in our Matroska muxer, introduced in version 57.36 
>> alongside
>>   * this function, and fixed in 57.52 */
>> -if (sscanf(matroska->muxingapp, "Lavf%d.%d.%d", , , ) 
>> == 3)
>> +if (matroska->muxingapp && sscanf(matroska->muxingapp, "Lavf%d.%d.%d", 
>> , , ) == 3)
>>  bttb = (major == 57 && minor >= 36 && minor <= 51 && micro >= 100);
>>
>>  switch (field_order) {
>
> Why do we even have this dumb check?
>
> The files that have already produced will be misinterpreted by
> compliant demuxers, and adding ugly workarounds is unfair to those
> compliant demuxers.

This way you can at least fix it by remuxing with a newer ffmpeg,
instead of it being broken forever.

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

Re: [FFmpeg-devel] [PATCH] mov: move stsd finalization to an appropriate place

[Hendrik Leppkes]

On Sat, Oct 15, 2016 at 11:19 AM, Hendrik Leppkes  wrote:
> On Fri, Oct 14, 2016 at 3:21 PM, Carl Eugen Hoyos  wrote:
>> 2016-10-14 13:56 GMT+02:00 Hendrik Leppkes :
>>> mov_finalize_stsd_codec parses stream information from the ALAC extradata,
>>> so run it after the extradata processing is completed in mov_read_stsd.
>>
>> Please mention ticket #5826 if your patch fixes the issue.
>>
>
> It probably should, it sounds like a similar issue.
>
> If there are no further comments, I'll apply tomorrow. It just moves
> this call down slightly, no real risk of breakage.
>

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

Re: [FFmpeg-devel] [PATCH] matroskadec: fix NULL pointer dereference

[wm4]

On Sun, 16 Oct 2016 22:11:03 +0200
Andreas Cadhalpun  wrote:

> The problem was introduced in commit 1273bc6.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/matroskadec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 8847c62..a5d3c0e 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -1759,7 +1759,7 @@ static int mkv_field_order(MatroskaDemuxContext 
> *matroska, int64_t field_order)
>  
>  /* workaround a bug in our Matroska muxer, introduced in version 57.36 
> alongside
>   * this function, and fixed in 57.52 */
> -if (sscanf(matroska->muxingapp, "Lavf%d.%d.%d", , , ) 
> == 3)
> +if (matroska->muxingapp && sscanf(matroska->muxingapp, "Lavf%d.%d.%d", 
> , , ) == 3)
>  bttb = (major == 57 && minor >= 36 && minor <= 51 && micro >= 100);
>  
>  switch (field_order) {

Why do we even have this dumb check?

The files that have already produced will be misinterpreted by
compliant demuxers, and adding ugly workarounds is unfair to those
compliant demuxers.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/rtsp: support rtsps

[wm4]

On Sun, 16 Oct 2016 21:20:04 +
Jay  wrote:

> This is the approach present in avformat/rtsp.c, but I can modify. What is
> preferred?
> 
> For clarity, this patch does not copy url params from the `rtsps://` input.
> It passes tls params provided as cmd line options to the `tls://` protocol
> handler.
> 
> Personally, I would like tls negotiation to be recognized in the tcp
> handler and the connection upgraded to tls. This would allow for `rtsp://`
> schemes to work with tls - nice if you do not initially know the connection
> is secure ( parity with gstreamer ). Unfortunately I am new to ffmpeg and
> there is a lot of code to digest. It also does not address encrypted udp.
> 
> Let me know how best to proceed. Thank you.
> Jay

ffurl_open_whitelist() has an options parameter. This is a AVDictionary
that contains one option/value pair per entry. It _should_ be possible
to pass down the options you want to set with this, instead of
appending them to the URL. Although I haven't tried this myself, and
can't be sure there isn't something else that breaks this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.2

[wm4]

On Mon, 17 Oct 2016 04:24:40 +0200
Michael Niedermayer  wrote:

> On Sun, Oct 16, 2016 at 06:01:54PM -0400, Helmut K. C. Tessarek wrote:
> > On 2016-09-27 09:30, Michael Niedermayer wrote:  
> > > Its long since FFmpeg 3.1, so its time to make 3.2
> > > ill branch release/3.2 off master and make 3.2 in maybe about a week or
> > > 2 unless something delays it  
> > 
> > What happened to 3.2?  
> 
> the AVFrame.pts field has been changed in master redefining ABI/API
> without soname bump.
> 
> this complicates the 3.2 release.
> ATM we have 3.0 and 3.1 releases with the same sonames as git master
> but they are not fully compatible due to the AVFrame.pts change
> (on top of that i was a bit more busy with random stuff than i
>  expected)
> 
> the obvious solution is to bump major version of all libs. (this is
> not wanted i belive though)
> 
> the alternative is to remove the (useless) use of AVFrame.pts from
> 3.0 and 3.1 and make new releases
> then document in release notes that the 3.2 release cannot co-exist
> with 3.0 or 3.1 prior to the last release and assume no other
> application use AVFrame.pts
> 
> Ill look at making the 3.0 and 3.1 release without AVFrame.pts use in
> ffmpeg ASAP. These wont do any harm either way
> 
> Maybe someone can write the release notes ?
> 
> [...]
> 

The change was backwards-compatible, as nobody should have used the pts
field for decoding before. The fact that ffmpeg.c couldn't use its own
API correctly is not of matter.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/vda: define av_vda_default_init2 when CONFIG_H264_VDA_HWACCEL equ 0

[Steven Liu]

ping Xidorn Quan

2016-10-15 6:01 GMT+08:00 wm4 :

> On Thu, 13 Oct 2016 20:57:07 +0800
> Steven Liu  wrote:
>
> > ping
> >
> > 2016-10-12 17:36 GMT+08:00 Steven Liu :
> >
> > > on OSX:
> > > ../configure --disable-everything --enable-demuxer=hls make
> > > error message: Undefined symbols for architecture x86_64:
> > > "_av_vda_default_init2", referenced from:_videotoolbox_init in
> > > ffmpeg_videotoolbox.o
> > > so add av_vda_default_init2 when CONFIG_H264_VDA_HWACCEL=0
> > >
> > > Signed-off-by: Steven Liu 
> > > ---
> > >  libavcodec/vda.c |5 +
> > >  1 files changed, 5 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/libavcodec/vda.c b/libavcodec/vda.c
> > > index 4670140..819ae03 100644
> > > --- a/libavcodec/vda.c
> > > +++ b/libavcodec/vda.c
> > > @@ -73,6 +73,11 @@ int av_vda_default_init(AVCodecContext *avctx)
> > >  return AVERROR(ENOSYS);
> > >  }
> > >
> > > +int av_vda_default_init2(AVCodecContext *avctx, AVVDAContext *vdactx)
> > > +{
> > > +return AVERROR(ENOSYS);
> > > +}
> > > +
> > >  void av_vda_default_free(AVCodecContext *ctx)
> > >  {
> > >  }
> > > --
> > > 1.7.1
> > >
> > >
> > >
> > > ___
> > > 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
>
> Patch ok, but I can't push for a while (and I'm not VDA maintainer).
> ___
> 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] avcodec/mediacodec: Factor duplicate include

[Matthieu Bouron]

On Sun, Oct 16, 2016 at 04:52:10PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/mediacodec.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/mediacodec.c b/libavcodec/mediacodec.c
> index a658f0e..37008e0 100644
> --- a/libavcodec/mediacodec.c
> +++ b/libavcodec/mediacodec.c
> @@ -24,6 +24,8 @@
>  
>  #include "libavutil/error.h"
>  
> +#include "mediacodec.h"
> +
>  #if CONFIG_H264_MEDIACODEC_HWACCEL
>  
>  #include 
> @@ -33,7 +35,6 @@
>  #include "libavutil/mem.h"
>  
>  #include "ffjni.h"
> -#include "mediacodec.h"
>  #include "mediacodecdec.h"
>  
>  AVMediaCodecContext *av_mediacodec_alloc_context(void)
> @@ -101,8 +102,6 @@ int av_mediacodec_release_buffer(AVMediaCodecBuffer 
> *buffer, int render)
>  
>  #include 
>  
> -#include "mediacodec.h"
> -
>  AVMediaCodecContext *av_mediacodec_alloc_context(void)
>  {
>  return NULL;
> -- 
> 2.10.1

LGTM.

Thanks,
Matthieu

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