date:20161129

On Wed, Nov 30, 2016 at 02:27:12AM +0100, Andreas Cadhalpun wrote:
> Not doing so makes debugging unnecessarily hard.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  tests/ffserver-regression.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

i agree, i did the same mysef locally

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

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


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

[FFmpeg-devel] [PATCH] lavc/vaapi_h26[45]: add crop info support in vaapi_h26[4, 5]

2016-11-29 Thread Jun Zhao

From 20bedd18213420c77d5e8a26fbe741d8d204ac10 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 29 Nov 2016 14:14:25 +0800
Subject: [PATCH] lavc/vaapi_h26[45]: add crop info support in vaapi_h26[4,5]

add crop information support in vaapi_h26[4,5] hwaccel decode,
and align h264/hevc software decoder. After this fix, FATE test
h264-conformance-cvfc1_sony_c/hevc-conformance-CONFWIN_A_Sony_1
will pass in i965/SKL.

Signed-off-by: Wang, Yi A 
Signed-off-by: Jun Zhao 
---
 libavcodec/h264dec.c| 13 +
 libavcodec/hevc_refs.c  |  7 +++
 libavutil/hwcontext.h   |  6 ++
 libavutil/hwcontext_vaapi.c |  1 +
 4 files changed, 27 insertions(+)

diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index ed0b724..2e7692c 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -54,6 +54,7 @@
 #include "rectangle.h"
 #include "thread.h"
 #include "vdpau_compat.h"
+#include "libavutil/hwcontext.h"
 
 static int h264_decode_end(AVCodecContext *avctx);
 
@@ -1012,6 +1013,18 @@ static int output_frame(H264Context *h, AVFrame *dst, 
H264Picture *srcp)
   (srcp->crop_top  >> vshift) * dst->linesize[i];
 dst->data[i] += off;
 }
+
+/* HWAccel always used data[0-3] in avframe */
+for (i = 0; i < 3; i++) {
+if (dst->hw_frames_ctx) {
+int hshift = (i > 0) ? desc->log2_chroma_w : 0;
+int vshift = (i > 0) ? desc->log2_chroma_h : 0;
+AVHWFramesContext *ctx = 
(AVHWFramesContext*)dst->hw_frames_ctx->data;
+ctx->top_offset[i] = srcp->crop_top  >> vshift;
+ctx->left_offset[i] = (srcp->crop_left >> hshift) << 
h->pixel_shift;
+}
+}
+
 return 0;
 }
 
diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index 611ad45..a184de2 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -28,6 +28,7 @@
 #include "thread.h"
 #include "hevc.h"
 
+#include "libavutil/hwcontext.h"
 void ff_hevc_unref_frame(HEVCContext *s, HEVCFrame *frame, int flags)
 {
 /* frame->frame can be NULL if context init failed */
@@ -222,7 +223,13 @@ int ff_hevc_output_frame(HEVCContext *s, AVFrame *out, int 
flush)
 int off = ((frame->window.left_offset >> hshift) << 
pixel_shift) +
   (frame->window.top_offset   >> vshift) * 
dst->linesize[i];
 dst->data[i] += off;
+if (out->hw_frames_ctx) {
+AVHWFramesContext *ctx = 
(AVHWFramesContext*)out->hw_frames_ctx->data;
+ctx->top_offset[i] = frame->window.top_offset >> vshift;
+ctx->left_offset[i] = (frame->window.left_offset >> 
hshift) << pixel_shift;
+}
 }
+
 av_log(s->avctx, AV_LOG_DEBUG,
"Output frame with POC %d.\n", frame->poc);
 return 1;
diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
index 785da09..0d666c3 100644
--- a/libavutil/hwcontext.h
+++ b/libavutil/hwcontext.h
@@ -220,6 +220,12 @@ typedef struct AVHWFramesContext {
  * Must be set by the user before calling av_hwframe_ctx_init().
  */
 int width, height;
+
+/**
+ * The top and left offset of the frames
+ */
+int top_offset[AV_NUM_DATA_POINTERS];
+int left_offset[AV_NUM_DATA_POINTERS];
 } AVHWFramesContext;
 
 /**
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 6176bdc..fa026cc 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -781,6 +781,7 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
 for (i = 0; i < map->image.num_planes; i++) {
 dst->data[i] = (uint8_t*)address + map->image.offsets[i];
 dst->linesize[i] = map->image.pitches[i];
+dst->data[i] += hwfc->top_offset[i] * dst->linesize[i] + 
hwfc->left_offset[i];
 }
 if (
 #ifdef VA_FOURCC_YV16
-- 
2.9.3

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

[FFmpeg-devel] [PATCH 1/3] tests: print errors from ffserver

Not doing so makes debugging unnecessarily hard.

Signed-off-by: Andreas Cadhalpun 
---
 tests/ffserver-regression.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/ffserver-regression.sh b/tests/ffserver-regression.sh
index b776bad..47d6016 100755
--- a/tests/ffserver-regression.sh
+++ b/tests/ffserver-regression.sh
@@ -12,7 +12,7 @@ target_path=$5
 FILES=$(sed -n 's/^[^#]*.*/\1/p' $2 | grep -v html)
 
 rm -f tests/feed1.ffm
-$target_exec ${target_path}/ffserver${PROGSUF} -d -f "$2" 2> /dev/null &
+$target_exec ${target_path}/ffserver${PROGSUF} -d -f "$2" &
 FFSERVER_PID=$!
 echo "Waiting for feeds to startup..."
 sleep 2
-- 
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/3] ffserver: use codec time_base for stream

This fixes producing swf and rm files as done by ffservertest.

Signed-off-by: Andreas Cadhalpun 
---
 ffserver.c| 2 +-
 tests/ffserver.regression.ref | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/ffserver.c b/ffserver.c
index 20f5995..ffd75d4 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -3529,7 +3529,7 @@ static LayeredAVStream *add_av_stream1(FFServerStream 
*stream,
 //NOTE we previously allocated internal & internal->avctx, these seemed 
uneeded though
 fst->codecpar = avcodec_parameters_alloc();
 fst->index = stream->nb_streams;
-fst->time_base = (AVRational) {1, 9};
+fst->time_base = codec->time_base;
 fst->pts_wrap_bits = 33;
 fst->sample_aspect_ratio = codec->sample_aspect_ratio;
 stream->streams[stream->nb_streams++] = fst;
diff --git a/tests/ffserver.regression.ref b/tests/ffserver.regression.ref
index ec7b37c..f796b50 100644
--- a/tests/ffserver.regression.ref
+++ b/tests/ffserver.regression.ref
@@ -1,11 +1,11 @@
 233020d119085ba47535d5f2faf73cc0 *ff-test_h.avi
 431b75d1f12cb039acebad61a3d39225 *ff-test_l.avi
-d41d8cd98f00b204e9800998ecf8427e *ff-test.swf
+a767dbdf5d1bded3450279f812f97b37 *ff-test.swf
 dc16f607e13328a832e73801cd21ec98 *ff-test_h.asf
 69337d6c8cd7ac7e626338decdbf41d3 *ff-test_l.asf
-d41d8cd98f00b204e9800998ecf8427e *ff-test_h.rm
-d41d8cd98f00b204e9800998ecf8427e *ff-test_l.rm
+06f5a6a4c5d1c6735f4d0068e825c91f *ff-test_h.rm
+1f57580f02f0317407b3b82a3d5e093f *ff-test_l.rm
 4c887dfc1dd0f6ea1a3a2be6dd32e495 *ff-test.jpg
 1d04b73b04aad27793cc762d5afabac1 *ff-test_small.jpg
 bc36c40ee34ebee6ffe50f3094aab733 *ff-test.mjpg
-9b72c3d6d89a038fa141fe636baa2c0e *ff-stat
+db129c1b1b7fd55e101591392ba88854 *ff-stat
-- 
2.10.2

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

[FFmpeg-devel] [PATCH 2/3] tests: drop -d option from ffserver invocation

It randomly causes failures with an error like:
"Failed to set value '-f' for option 'd': Error number -920332800 occurred"

(The error number is different every time.)

Signed-off-by: Andreas Cadhalpun 
---
 tests/ffserver-regression.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/ffserver-regression.sh b/tests/ffserver-regression.sh
index 47d6016..5761602 100755
--- a/tests/ffserver-regression.sh
+++ b/tests/ffserver-regression.sh
@@ -12,7 +12,7 @@ target_path=$5
 FILES=$(sed -n 's/^[^#]*.*/\1/p' $2 | grep -v html)
 
 rm -f tests/feed1.ffm
-$target_exec ${target_path}/ffserver${PROGSUF} -d -f "$2" &
+$target_exec ${target_path}/ffserver${PROGSUF} -f "$2" &
 FFSERVER_PID=$!
 echo "Waiting for feeds to startup..."
 sleep 2
-- 
2.10.2

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

Re: [FFmpeg-devel] [PATCH] avidec: fix leaking extradata

On 30.11.2016 01:29, Michael Niedermayer wrote:
> On Wed, Nov 30, 2016 at 12:21:41AM +0100, Andreas Cadhalpun wrote:
>>  avidec.c |8 
>>  1 file changed, 8 insertions(+)
>> 88b8c27a72e7ec4519e92eee5a3a2764a657a823  
>> 0001-avidec-fix-leaking-extradata.patch
>> From e6a4fc92a99e2e3789730e8e122b39255d186c1f Mon Sep 17 00:00:00 2001
>> From: Andreas Cadhalpun 
>> Date: Tue, 29 Nov 2016 00:28:55 +0100
>> Subject: [PATCH] avidec: fix leaking extradata
> 
> LGTM

Pushed.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] avidec: fix leaking extradata

On Wed, Nov 30, 2016 at 12:21:41AM +0100, Andreas Cadhalpun wrote:
> On 29.11.2016 02:49, Michael Niedermayer wrote:
> > On Tue, Nov 29, 2016 at 12:33:17AM +0100, Andreas Cadhalpun wrote:
> >> Signed-off-by: Andreas Cadhalpun 
> >> ---
> >>  libavformat/avidec.c | 2 ++
> >>  1 file changed, 2 insertions(+)
> > 
> > If previous extradata is freed it should probably print a warning or
> > error out
> 
> That's a good idea, updated patch is attached.
> 
> Best regards,
> Andreas
> 

>  avidec.c |8 
>  1 file changed, 8 insertions(+)
> 88b8c27a72e7ec4519e92eee5a3a2764a657a823  
> 0001-avidec-fix-leaking-extradata.patch
> From e6a4fc92a99e2e3789730e8e122b39255d186c1f Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun 
> Date: Tue, 29 Nov 2016 00:28:55 +0100
> Subject: [PATCH] avidec: fix leaking extradata

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


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

Re: [FFmpeg-devel] matroskadec: prevent access of elements after freeing

On 28.11.2016 07:40, Schenk, Michael wrote:
> When using the decode interrupt feature of ffmpeg may causing crashes by
> accessing previous freed pointers in matroska_read_close.
> 
> The attached patch will reset nb_elem to zero after freeing the elements
> because ffmpeg normally tests for nb_elem.

Thanks. I've adapted this a bit, used it as the commit message and applied
the patch.

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

Re: [FFmpeg-devel] [PATCH] idroqdec: fix leaking pkt on failure

On 29.11.2016 02:57, Michael Niedermayer wrote:
> On Tue, Nov 29, 2016 at 12:46:11AM +0100, Andreas Cadhalpun wrote:
>> The code calls av_new_packet a few lines above and the allocated memory
>> has to be freed in case of an error.
> 
> should be ok

Pushed.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] avidec: fix leaking extradata

On 29.11.2016 02:49, Michael Niedermayer wrote:
> On Tue, Nov 29, 2016 at 12:33:17AM +0100, Andreas Cadhalpun wrote:
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavformat/avidec.c | 2 ++
>>  1 file changed, 2 insertions(+)
> 
> If previous extradata is freed it should probably print a warning or
> error out

That's a good idea, updated patch is attached.

Best regards,
Andreas

>From e6a4fc92a99e2e3789730e8e122b39255d186c1f Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun 
Date: Tue, 29 Nov 2016 00:28:55 +0100
Subject: [PATCH] avidec: fix leaking extradata

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

diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index e5a292e..d465965 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -770,6 +770,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
 st->codecpar->extradata_size = esize - 10 * 4;
 } else
 st->codecpar->extradata_size =  size - 10 * 4;
+if (st->codecpar->extradata) {
+av_log(s, AV_LOG_WARNING, "New extradata in strf chunk, freeing previous one.\n");
+av_freep(&st->codecpar->extradata);
+}
 if (ff_get_extradata(s, st->codecpar, pb, st->codecpar->extradata_size) < 0)
 return AVERROR(ENOMEM);
 }
@@ -925,6 +929,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
 st = s->streams[stream_index];
 
 if (size<(1<<30)) {
+if (st->codecpar->extradata) {
+av_log(s, AV_LOG_WARNING, "New extradata in strd chunk, freeing previous one.\n");
+av_freep(&st->codecpar->extradata);
+}
 if (ff_get_extradata(s, st->codecpar, pb, size) < 0)
 return AVERROR(ENOMEM);
 }
-- 
2.10.2

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

Re: [FFmpeg-devel] [PATCH]lavfi:Fix aix compilation

2016-11-29 Thread Paul B Mahol

On 11/29/16, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch fixes aix compilation, similar to 33f5d70d
>
> Please comment, Carl Eugen
>

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

[FFmpeg-devel] [PATCH] ffserver: Add client requested urls to the status page

Fixes Ticket3791

Signed-off-by: Michael Niedermayer 
---
 ffserver.c| 38 +++---
 tests/ffserver-regression.sh  |  2 +-
 tests/ffserver.regression.ref |  2 +-
 3 files changed, 37 insertions(+), 5 deletions(-)

diff --git a/ffserver.c b/ffserver.c
index 20f5995..8745181 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -164,6 +164,7 @@ typedef struct HTTPContext {
 char protocol[16];
 char method[16];
 char url[128];
+char clean_url[128*7];
 int buffer_size;
 uint8_t *buffer;
 int is_packetized; /* if true, the stream is packetized */
@@ -1920,6 +1921,34 @@ static inline void print_stream_params(AVIOContext *pb, 
FFServerStream *stream)
  avio_printf(pb, "\n");
 }
 
+static void clean_html(char *clean, int clean_len, char *dirty)
+{
+int i, o;
+
+for (o = i = 0; o+10 < clean_len && dirty[i];) {
+int len = strspn(dirty+i, 
"0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ$-_.+!*(),?/ 
:;%");
+if (len) {
+if (o + len >= clean_len)
+break;
+memcpy(clean + o, dirty + i, len);
+i += len;
+o += len;
+} else {
+int c = dirty[i++];
+switch (c) {
+case  '&': av_strlcat(clean+o, "&"  , clean_len - o); break;
+case  '<': av_strlcat(clean+o, "<"   , clean_len - o); break;
+case  '>': av_strlcat(clean+o, ">"   , clean_len - o); break;
+case '\'': av_strlcat(clean+o, "'" , clean_len - o); break;
+case '\"': av_strlcat(clean+o, """ , clean_len - o); break;
+default:   av_strlcat(clean+o, "☹", clean_len - o); break;
+}
+o += strlen(clean+o);
+}
+}
+clean[o] = 0;
+}
+
 static void compute_status(HTTPContext *c)
 {
 HTTPContext *c1;
@@ -2107,7 +2136,7 @@ static void compute_status(HTTPContext *c)
 current_bandwidth, config.max_bandwidth);
 
 avio_printf(pb, "\n");
-avio_printf(pb, "#FileIPProtoStateTarget "
+avio_printf(pb, 
"#FileIPURLProtoStateTarget "
 "bit/sActual bit/sBytes transferred\n");
 c1 = first_http_ctx;
 i = 0;
@@ -2127,10 +2156,13 @@ static void compute_status(HTTPContext *c)
 
 i++;
 p = inet_ntoa(c1->from_addr.sin_addr);
-avio_printf(pb, "%d%s%s%s%s%s"
+clean_html(c1->clean_url, sizeof(c1->clean_url), c1->url);
+avio_printf(pb, "%d%s%s%s%s%s%s"
 "",
 i, c1->stream ? c1->stream->filename : "",
-c1->state == HTTPSTATE_RECEIVE_DATA ? "(input)" : "", p,
+c1->state == HTTPSTATE_RECEIVE_DATA ? "(input)" : "",
+p,
+c1->clean_url,
 c1->protocol, http_state[c1->state]);
 fmt_bytecount(pb, bitrate);
 avio_printf(pb, "");
diff --git a/tests/ffserver-regression.sh b/tests/ffserver-regression.sh
index b776bad..17e9060 100755
--- a/tests/ffserver-regression.sh
+++ b/tests/ffserver-regression.sh
@@ -28,7 +28,7 @@ sleep 2
 fi
 do_md5sum ff-$file >>ffserver.regression
 done
-wget  $WGET_OPTIONS -O - teststat.html http://localhost:/teststat.html 
> ff-stat 2>/dev/null
+wget  $WGET_OPTIONS -O - 'http://localhost:/teststat.html?abc' > 
ff-stat 2>/dev/null
 do_md5sum ff-stat >>ffserver.regression
 )
 kill $FFSERVER_PID
diff --git a/tests/ffserver.regression.ref b/tests/ffserver.regression.ref
index ec7b37c..8629d52 100644
--- a/tests/ffserver.regression.ref
+++ b/tests/ffserver.regression.ref
@@ -8,4 +8,4 @@ d41d8cd98f00b204e9800998ecf8427e *ff-test_l.rm
 4c887dfc1dd0f6ea1a3a2be6dd32e495 *ff-test.jpg
 1d04b73b04aad27793cc762d5afabac1 *ff-test_small.jpg
 bc36c40ee34ebee6ffe50f3094aab733 *ff-test.mjpg
-9b72c3d6d89a038fa141fe636baa2c0e *ff-stat
+56c8b3ba2c4f3eebfa6d2a895e042ee3 *ff-stat
-- 
2.10.2

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/h264: sse2 and avx 4:2:2 idct add8 10-bit functions

On 2016-11-29 21:09, Carl Eugen Hoyos wrote:
> 2016-11-29 17:14 GMT+01:00 James Darnley :
>> On 2016-11-29 15:30, Carl Eugen Hoyos wrote:
>>> 2016-11-29 12:52 GMT+01:00 James Darnley :
 sse2:
 complex: 4.13x faster (1514 vs. 367 cycles)
 simple:  4.38x faster (1836 vs. 419 cycles)

 avx:
 complex: 1.07x faster (260 vs. 244 cycles)
 simple:  1.03x faster (284 vs. 274 cycles)
>>>
>>> What are you comparing?
> 
>> The AVX comparison is it versus SSE2.
> 
> This wasn't obvious to me.

Ah.  I will try to clarify the message.

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

[FFmpeg-devel] [PATCH]lavf/mov: Accept multiple fourcc for AVID 1:1

Hi!

Attached patch fixes ticket #5982.

Please comment, Carl Eugen
From add7f5d51491152af6d0431331543212c2c21ca4 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 29 Nov 2016 22:09:21 +0100
Subject: [PATCH] lavf/mov: Accept multiple fourcc for AVID 1:1.

Fixes ticket #5982.
---
 libavformat/mov.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9bbb155..1c2d88d 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2212,6 +2212,7 @@ static int mov_skip_multiple_stsd(MOVContext *c, 
AVIOContext *pb,
 
 if (codec_tag &&
  (codec_tag != format &&
+  (codec_tag != AV_RL32("AV1x") || format != AV_RL32("AVup")) &&
   // prores is allowed to have differing data format and codec tag
   codec_tag != AV_RL32("apcn") && codec_tag != AV_RL32("apch") &&
   // so is dv (sigh)
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH]lavfi:Fix aix compilation

Hi!

Attached patch fixes aix compilation, similar to 33f5d70d

Please comment, Carl Eugen
From a959ae4347edb37dc342ef03c178a621a1c3a74a Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 29 Nov 2016 21:49:22 +0100
Subject: [PATCH] lavfi: Fix aix compilation.

Rename hz in af_apulsator.c and avf_showspectrum.c as hertz.

The aix header sys/m_param.h defines hz as __hz.
---
 libavfilter/af_apulsator.c |6 +++---
 libavfilter/avf_showspectrum.c |   12 ++--
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/libavfilter/af_apulsator.c b/libavfilter/af_apulsator.c
index 802b8d0..67711a2 100644
--- a/libavfilter/af_apulsator.c
+++ b/libavfilter/af_apulsator.c
@@ -47,7 +47,7 @@ typedef struct AudioPulsatorContext {
 double offset_r;
 double pwidth;
 double bpm;
-double hz;
+double hertz;
 int ms;
 int timing;
 
@@ -76,7 +76,7 @@ static const AVOption apulsator_options[] = {
 {   "hz",   NULL, 0, AV_OPT_TYPE_CONST,  
{.i64=UNIT_HZ},   0,  0, FLAGS, "timing" },
 { "bpm",   "set BPM", OFFSET(bpm),   AV_OPT_TYPE_DOUBLE, 
{.dbl=120},30,  300, FLAGS },
 { "ms", "set ms", OFFSET(ms),AV_OPT_TYPE_INT,
{.i64=500},10, 2000, FLAGS },
-{ "hz",  "set frequency", OFFSET(hz),AV_OPT_TYPE_DOUBLE, 
{.dbl=2},0.01,  100, FLAGS },
+{ "hz",  "set frequency", OFFSET(hertz), AV_OPT_TYPE_DOUBLE, 
{.dbl=2},0.01,  100, FLAGS },
 { NULL }
 };
 
@@ -208,7 +208,7 @@ static int config_input(AVFilterLink *inlink)
 switch (s->timing) {
 case UNIT_BPM:  freq = s->bpm / 60; break;
 case UNIT_MS:   freq = 1 / (s->ms / 1000.); break;
-case UNIT_HZ:   freq = s->hz;   break;
+case UNIT_HZ:   freq = s->hertz;break;
 default: av_assert0(0);
 }
 
diff --git a/libavfilter/avf_showspectrum.c b/libavfilter/avf_showspectrum.c
index f63fbe8..8a08b20 100644
--- a/libavfilter/avf_showspectrum.c
+++ b/libavfilter/avf_showspectrum.c
@@ -1120,13 +1120,13 @@ static int showspectrumpic_request_frame(AVFilterLink 
*outlink)
 dst[x] = 200;
 }
 for (y = 0; y < h; y += 40) {
-float hz = y * (inlink->sample_rate / 2) / (float)(1 
<< (int)ceil(log2(h)));
+float hertz = y * (inlink->sample_rate / 2) / 
(float)(1 << (int)ceil(log2(h)));
 char *units;
 
-if (hz == 0)
+if (hertz == 0)
 units = av_asprintf("DC");
 else
-units = av_asprintf("%.2f", hz);
+units = av_asprintf("%.2f", hertz);
 if (!units)
 return AVERROR(ENOMEM);
 
@@ -1185,13 +1185,13 @@ static int showspectrumpic_request_frame(AVFilterLink 
*outlink)
 dst[x] = 200;
 }
 for (x = 0; x < w; x += 80) {
-float hz = x * (inlink->sample_rate / 2) / (float)(1 
<< (int)ceil(log2(w)));
+float hertz = x * (inlink->sample_rate / 2) / 
(float)(1 << (int)ceil(log2(w)));
 char *units;
 
-if (hz == 0)
+if (hertz == 0)
 units = av_asprintf("DC");
 else
-units = av_asprintf("%.2f", hz);
+units = av_asprintf("%.2f", hertz);
 if (!units)
 return AVERROR(ENOMEM);
 
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

2016-11-29 Thread Paul B Mahol

On 11/29/16, Carl Eugen Hoyos  wrote:
> 2016-11-29 21:11 GMT+01:00 James Almer :
>> On 11/29/2016 5:04 PM, Carl Eugen Hoyos wrote:
>>> 2016-11-29 20:38 GMT+01:00 James Almer :
>>>
 Seeing Nicolas is apparently very invested in ffserver, can we expect
 him to
 maintain it, improve and extend it if it were to remain in the tree?
>>>
>>> How is this related?
>>> For which part of FFmpeg can we "expect" anybody to maintain it?
>>
>> He's trying to override an announced project decision of removing a
>> feature.
>
> We - obviously - announced it to find somebody who would fix the issues
> raised. If they are fixed, the "decision" is of course void, and we don't
> have to vote about it.
> (We could vote to overturn our decision although there are still
> issues.)
>
>> If he has no interest in making sure said feature doesn't go back to the
>> state that prompted its removal, then he's simply trying to force the
>> project
>> to keep code someone else will have to deal with.
>>
>> It would make much more sense in that case if the actual person interested
>> and
>> willing to deal with the code to be behind these decision revoking
>> attempts.
>>
>>>
 Or is he just fighting this fight to not remove code for the sake of
 not removing code, and will forget about it and expect someone
 else to deal with it if it starts bitrotting again?
>>>
>>> This is a violation of our code-of-conduct or do I misunderstand you?
>>
>> How so? If he's not going to maintain the code he's campaigning to keep in
>> place, then he obviously expects someone else will, right? How is stating
>> that a violation of the CoC?
>
> I am not a native speaker but this is not how I read your accusation.
> "is he just fighting the fight to not remove code for the sake of not
> removing code" sounds to me as if you are not assuming good faith.

And your assumption that James doesn't act in good faith is also then violation
of CoC.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

On 11/29/2016 5:41 PM, Carl Eugen Hoyos wrote:
> 2016-11-29 21:11 GMT+01:00 James Almer :
>> On 11/29/2016 5:04 PM, Carl Eugen Hoyos wrote:
>>> 2016-11-29 20:38 GMT+01:00 James Almer :
>>>
 Seeing Nicolas is apparently very invested in ffserver, can we expect him 
 to
 maintain it, improve and extend it if it were to remain in the tree?
>>>
>>> How is this related?
>>> For which part of FFmpeg can we "expect" anybody to maintain it?
>>
>> He's trying to override an announced project decision of removing a feature.
> 
> We - obviously - announced it to find somebody who would fix the issues
> raised. If they are fixed, the "decision" is of course void, and we don't
> have to vote about it.

That's not what was announced, at all. Please, read the news entry in question
and inform yourself in the subject before trying to participate in a discussion.

> (We could vote to overturn our decision although there are still
> issues.)
> 
>> If he has no interest in making sure said feature doesn't go back to the
>> state that prompted its removal, then he's simply trying to force the project
>> to keep code someone else will have to deal with.
>>
>> It would make much more sense in that case if the actual person interested 
>> and
>> willing to deal with the code to be behind these decision revoking attempts.
>>
>>>
 Or is he just fighting this fight to not remove code for the sake of
 not removing code, and will forget about it and expect someone
 else to deal with it if it starts bitrotting again?
>>>
>>> This is a violation of our code-of-conduct or do I misunderstand you?
>>
>> How so? If he's not going to maintain the code he's campaigning to keep in
>> place, then he obviously expects someone else will, right? How is stating
>> that a violation of the CoC?
> 
> I am not a native speaker but this is not how I read your accusation.
> "is he just fighting the fight to not remove code for the sake of not
> removing code" sounds to me as if you are not assuming good faith.

I'm not assuming anything and I don't know the nature of his intentions, but i
do know everything points said intentions are to keep code he has no plan to 
deal
with afterwards. That's all i stated.

If you're interested in waving the CoC around, you could reply to the two emails
where Nicolas called me a dictator and an imbecile. It would be nice to know I'm
not being ganged up by two or three people on this whole deal.

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

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

2016-11-29 21:11 GMT+01:00 James Almer :
> On 11/29/2016 5:04 PM, Carl Eugen Hoyos wrote:
>> 2016-11-29 20:38 GMT+01:00 James Almer :
>>
>>> Seeing Nicolas is apparently very invested in ffserver, can we expect him to
>>> maintain it, improve and extend it if it were to remain in the tree?
>>
>> How is this related?
>> For which part of FFmpeg can we "expect" anybody to maintain it?
>
> He's trying to override an announced project decision of removing a feature.

We - obviously - announced it to find somebody who would fix the issues
raised. If they are fixed, the "decision" is of course void, and we don't
have to vote about it.
(We could vote to overturn our decision although there are still
issues.)

> If he has no interest in making sure said feature doesn't go back to the
> state that prompted its removal, then he's simply trying to force the project
> to keep code someone else will have to deal with.
>
> It would make much more sense in that case if the actual person interested and
> willing to deal with the code to be behind these decision revoking attempts.
>
>>
>>> Or is he just fighting this fight to not remove code for the sake of
>>> not removing code, and will forget about it and expect someone
>>> else to deal with it if it starts bitrotting again?
>>
>> This is a violation of our code-of-conduct or do I misunderstand you?
>
> How so? If he's not going to maintain the code he's campaigning to keep in
> place, then he obviously expects someone else will, right? How is stating
> that a violation of the CoC?

I am not a native speaker but this is not how I read your accusation.
"is he just fighting the fight to not remove code for the sake of not
removing code" sounds to me as if you are not assuming good faith.

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

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

On 11/29/2016 5:04 PM, Carl Eugen Hoyos wrote:
> 2016-11-29 20:38 GMT+01:00 James Almer :
> 
>> Seeing Nicolas is apparently very invested in ffserver, can we expect him to
>> maintain it, improve and extend it if it were to remain in the tree?
> 
> How is this related?
> For which part of FFmpeg can we "expect" anybody to maintain it?

He's trying to override an announced project decision of removing a feature.
If he has no interest in making sure said feature doesn't go back to the
state that prompted its removal, then he's simply trying to force the project
to keep code someone else will have to deal with.

It would make much more sense in that case if the actual person interested and
willing to deal with the code to be behind these decision revoking attempts.

> 
>> Or is he just fighting this fight to not remove code for the sake of
>> not removing code, and will forget about it and expect someone
>> else to deal with it if it starts bitrotting again?
> 
> This is a violation of our code-of-conduct or do I misunderstand you?

How so? If he's not going to maintain the code he's campaigning to keep in
place, then he obviously expects someone else will, right? How is stating that
a violation of the CoC?

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

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

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

2016-11-28 19:15 GMT+01:00 Nicolas George :
> Deadline: 2016-12-06 00:00 UTC.
>
> I propose, and put to the discussion, that the decision to drop ffserver
> is revoked, conditioned to the fixing of the technical issues that lead
> to it.

Could you point me to this decision?
What were the reasons at the time? Does any of the given reasons
still apply? If not, why is this vote necessary?

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/h264: sse2 and avx 4:2:2 idct add8 10-bit functions

2016-11-29 17:14 GMT+01:00 James Darnley :
> On 2016-11-29 15:30, Carl Eugen Hoyos wrote:
>> 2016-11-29 12:52 GMT+01:00 James Darnley :
>>> sse2:
>>> complex: 4.13x faster (1514 vs. 367 cycles)
>>> simple:  4.38x faster (1836 vs. 419 cycles)
>>>
>>> avx:
>>> complex: 1.07x faster (260 vs. 244 cycles)
>>> simple:  1.03x faster (284 vs. 274 cycles)
>>
>> What are you comparing?

> The AVX comparison is it versus SSE2.

This wasn't obvious to me.

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

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

2016-11-29 20:38 GMT+01:00 James Almer :

> Seeing Nicolas is apparently very invested in ffserver, can we expect him to
> maintain it, improve and extend it if it were to remain in the tree?

How is this related?
For which part of FFmpeg can we "expect" anybody to maintain it?

> Or is he just fighting this fight to not remove code for the sake of
> not removing code, and will forget about it and expect someone
> else to deal with it if it starts bitrotting again?

This is a violation of our code-of-conduct or do I misunderstand you?

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

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

2016-11-29 Thread Paul B Mahol

On 11/29/16, James Almer  wrote:
> On 11/28/2016 5:52 PM, Clement Boesch wrote:
>> On Mon, Nov 28, 2016 at 07:15:28PM +0100, Nicolas George wrote:
>>> Deadline: 2016-12-06 00:00 UTC.
>>>
>>> I propose, and put to the discussion, that the decision to drop ffserver
>>> is revoked, conditioned to the fixing of the technical issues that lead
>>> to it.
>>>
>>
>>> In other words, if the technical problems that require dropping ffserver
>>> are resolved at the time it is about to be dropped, then it must not be
>>> and the patch is not applied.
>>
>> Do we agree that the requirements are the following:
>>
>> - ZERO internal API usage
>> - at least partial FATE coverage
>>
>> ?
>>
>> What's the due date already? Next release?
>
> There are more important things to establish than just that.
>
> Seeing Nicolas is apparently very invested in ffserver, can we expect him to
> maintain it, improve and extend it if it were to remain in the tree? Or is
> he
> just fighting this fight to not remove code for the sake of not removing
> code,
> and will forget about it and expect someone else to deal with it if it
> starts
> bitrotting again?
>
> And furthermore, how can we even trust anything that's agreed out of this,
> if
> the very existence of this vote derives from people being incapable of
> honoring
> previous agreements? Will people once again come out of the woodwork at the
> very
> last second, start flipping tables and decreeing on a whim that everything
> should
> be declared invalid, much like Nicolas is doing right now?
>
> This entire situation is simply embarrassing, no matter how you look at it
> or how
> you try to rationalize it.

I'm against keeping ffserver as such in FFmpeg repo.
It can be readded later when it is mature and properly implemented.

I vote No for this attempt to revoke previous decisions.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

On 11/28/2016 5:52 PM, Clément Bœsch wrote:
> On Mon, Nov 28, 2016 at 07:15:28PM +0100, Nicolas George wrote:
>> Deadline: 2016-12-06 00:00 UTC.
>>
>> I propose, and put to the discussion, that the decision to drop ffserver
>> is revoked, conditioned to the fixing of the technical issues that lead
>> to it.
>>
> 
>> In other words, if the technical problems that require dropping ffserver
>> are resolved at the time it is about to be dropped, then it must not be
>> and the patch is not applied.
> 
> Do we agree that the requirements are the following:
> 
> - ZERO internal API usage
> - at least partial FATE coverage
> 
> ?
> 
> What's the due date already? Next release?

There are more important things to establish than just that.

Seeing Nicolas is apparently very invested in ffserver, can we expect him to
maintain it, improve and extend it if it were to remain in the tree? Or is he
just fighting this fight to not remove code for the sake of not removing code,
and will forget about it and expect someone else to deal with it if it starts
bitrotting again?

And furthermore, how can we even trust anything that's agreed out of this, if
the very existence of this vote derives from people being incapable of honoring
previous agreements? Will people once again come out of the woodwork at the very
last second, start flipping tables and decreeing on a whim that everything 
should
be declared invalid, much like Nicolas is doing right now?

This entire situation is simply embarrassing, no matter how you look at it or 
how
you try to rationalize it.

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

Re: [FFmpeg-devel] [PATCH] doc/filters: drawtext: add example of printing texts on same baseline

2016-11-29 Thread Lou Logan

On Tue, Nov 29, 2016, at 09:55 AM, Andrey Utkin wrote:
>
> The point is that with more naive approach to printing parts of text,
> using just same vertical offset (code given below), it will look fine in
> some cases (e.g. all capital letters), but case of printing part with
> capital letter(s) and part without capitals, the parts won't be aligned.
> 
> With the following script, you'll see the dot floating at the top of "A"
> letter:

I already realized that, but this example may be confusing to users. I
assume the close proximity of TEXT1 and TEXT2 were to demonstrate the
"normalized" placement of various glyph heights for multiple drawtexts,
but users may see this and wonder why you need to print "A.", with the
characters close together as in your example, using two drawtexts when
you could just use one (with text='A.'). Increasing X2 may make the
example less confusing in that regard.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hls: Added subtitle support

2016-11-29 Thread Franklin Phillips

On Tue, Nov 29, 2016 at 07:10:52PM +0100, wm4 wrote:
> On Tue, 29 Nov 2016 17:44:15 +
> Franklin Phillips  wrote:
> 
> > Hi,
> > 
> > If there are no more comments can we look at merging this please?
> 
> I think your previous post implied that subtitles are actually timed
> correctly, right?
The timing is correct as long as the X-TIMESTAMP-MAP header in the subtitle 
files is 0 because I haven't implemented that. If I encounter situations where 
that header contains a value other than 0 outside of the sample files from 
Apple I will consider implementing it.

> 
> If so, I don't mind it being applied as-is.
> ___
> 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] [DECISION] Revoke the decision of dropping ffserver

On Mon, 28 Nov 2016 19:15:28 +0100
Nicolas George  wrote:

> Deadline: 2016-12-06 00:00 UTC.
> 
> I propose, and put to the discussion, that the decision to drop ffserver
> is revoked, conditioned to the fixing of the technical issues that lead
> to it.
> 
> In other words, if the technical problems that require dropping ffserver
> are resolved at the time it is about to be dropped, then it must not be
> and the patch is not applied.
> 
> I support the decision. Pros:
> 
> ffserver has users, if there are no reason to drop it, doing so is a
> gratuitous annoyance to them.
> 
> Apparently James Almer opposes the decision. Cons, if I understand
> correctly:
> 
> A decision was made, a project should stick to it stubbornly.
> 
> Regards,
> 

If I'm still qualified to vote: I don't acknowledge this vote. This is
not a yes, no, or abstention from voting.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

On 11/29/2016 3:46 PM, Stefano Sabatini wrote:
> On date Monday 2016-11-28 19:15:28 +0100, Nicolas George encoded:
>> Deadline: 2016-12-06 00:00 UTC.
>>
>> I propose, and put to the discussion, that the decision to drop ffserver
>> is revoked, conditioned to the fixing of the technical issues that lead
>> to it.
>>
>> In other words, if the technical problems that require dropping ffserver
>> are resolved at the time it is about to be dropped, then it must not be
>> and the patch is not applied.
> 
> Someone please specify who is entitled to vote (such decisions are not
> so common, and the voting criteria were defined a long time ago IIRC).

Afaics, https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183803.html
is the most recent approved list. A third extension was suggested, but it
didn't go through.

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

Re: [FFmpeg-devel] [PATCH] doc/filters: drawtext: add example of printing texts on same baseline

2016-11-29 Thread Andrey Utkin

On Tue, Nov 29, 2016 at 09:31:08AM -0900, l...@lrcd.com wrote:
> On Mon, Nov 28, 2016, at 07:29 AM, Andrey Utkin wrote:
> > Dimensions of canvas drawtext produces vary depending on symbols in
> > text, so add example for printing multiple texts aligned horizontally.
> 
> I don't really understand the use case. Can you explain?

The point is that with more naive approach to printing parts of text,
using just same vertical offset (code given below), it will look fine in
some cases (e.g. all capital letters), but case of printing part with
capital letter(s) and part without capitals, the parts won't be aligned.

With the following script, you'll see the dot floating at the top of "A"
letter:

#!/bin/sh
FONTFILE=font.ttf
FONTSIZE=32
Y=10 # vertical offset of texts
X1=10 # horizontal offset of first text
X2=30 # horizontal offset of second text
TEXT1="A"
TEXT2="."
ffplay -f lavfi -i "color=color=white,
drawtext=fontfile=$FONTFILE:text=$TEXT1:fontsize=$FONTSIZE:x=$X1:y=$Y,
drawtext=fontfile=$FONTFILE:text=$TEXT2:fontsize=$FONTSIZE:x=$X2:y=$Y"
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

2016-11-29 Thread Ronald S. Bultje

Hi Stefano,

On Tue, Nov 29, 2016 at 1:46 PM, Stefano Sabatini 
wrote:

> On date Monday 2016-11-28 19:15:28 +0100, Nicolas George encoded:
> > Deadline: 2016-12-06 00:00 UTC.
> >
> > I propose, and put to the discussion, that the decision to drop ffserver
> > is revoked, conditioned to the fixing of the technical issues that lead
> > to it.
> >
> > In other words, if the technical problems that require dropping ffserver
> > are resolved at the time it is about to be dropped, then it must not be
> > and the patch is not applied.
>
> Someone please specify who is entitled to vote (such decisions are not
> so common, and the voting criteria were defined a long time ago IIRC).


https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183803.html

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

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

2016-11-29 Thread Stefano Sabatini

On date Monday 2016-11-28 19:15:28 +0100, Nicolas George encoded:
> Deadline: 2016-12-06 00:00 UTC.
> 
> I propose, and put to the discussion, that the decision to drop ffserver
> is revoked, conditioned to the fixing of the technical issues that lead
> to it.
> 
> In other words, if the technical problems that require dropping ffserver
> are resolved at the time it is about to be dropped, then it must not be
> and the patch is not applied.

Someone please specify who is entitled to vote (such decisions are not
so common, and the voting criteria were defined a long time ago IIRC).
-- 
FFmpeg = Fundamental & Fantastic MultiPurpose Entertaining Geek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/filters: drawtext: add example of printing texts on same baseline

2016-11-29 Thread Lou Logan

On Mon, Nov 28, 2016, at 07:29 AM, Andrey Utkin wrote:
> Dimensions of canvas drawtext produces vary depending on symbols in
> text, so add example for printing multiple texts aligned horizontally.

I don't really understand the use case. Can you explain?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

2016-11-29 Thread Ronald S. Bultje

Hi,

On Mon, Nov 28, 2016 at 1:15 PM, Nicolas George  wrote:

> Deadline: 2016-12-06 00:00 UTC.
>
> I propose, and put to the discussion, that the decision to drop ffserver
> is revoked, conditioned to the fixing of the technical issues that lead
> to it.
>
> In other words, if the technical problems that require dropping ffserver
> are resolved at the time it is about to be dropped, then it must not be
> and the patch is not applied.
>
> I support the decision.


I vote to continue to drop ffserver.

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

Re: [FFmpeg-devel] [PATCH 1/2] tests/ffserver-regression.sh: give wget a timeout and prevent retries

On Tue, Nov 29, 2016 at 08:51:59AM -0800, Reynaldo H. Verdejo Pinochet wrote:
> Both OK. Thanks.

will push in a moment

thx

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

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


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

Re: [FFmpeg-devel] [PATCH] Added Turing codec interface for ffmpeg

On Tue, 29 Nov 2016 17:18:49 +
Matteo Naccari  wrote:

> - This patch contains the changes to interface the Turing codec
>   (http://turingcodec.org/) to ffmpeg. The patch was modified to address
>   the comments in the review as follows:
>   - Added a pkg-config file to list all dependencies required by
>   libturing. This should address the issue pointed out by Hendrik
>   Leppkes on Fri 18/11/2016
>   - The buffer to store the turing-params options has now a size which
>   depends on how many of these parameters have been passed by the user.
>   The sizeof(char) and casting for the malloc calls have been removed as
>   per suggestion of wm4. Moreover, the maximum length for a whole option
>   (i.e. --param=value) is computed and the related buffer size allocated
>   accordingly.
> ---
>  LICENSE.md |   1 +
>  configure  |   5 +
>  libavcodec/Makefile|   1 +
>  libavcodec/allcodecs.c |   1 +
>  libavcodec/libturing.c | 270 
> +
>  5 files changed, 278 insertions(+)
>  create mode 100644 libavcodec/libturing.c
> 
> diff --git a/LICENSE.md b/LICENSE.md
> index 640633c..86e5371 100644
> --- a/LICENSE.md
> +++ b/LICENSE.md
> @@ -85,6 +85,7 @@ The following libraries are under GPL:
>  - frei0r
>  - libcdio
>  - librubberband
> +- libturing
>  - libvidstab
>  - libx264
>  - libx265
> diff --git a/configure b/configure
> index 6345fc2..022ffa9 100755
> --- a/configure
> +++ b/configure
> @@ -255,6 +255,7 @@ External library support:
>--enable-libssh  enable SFTP protocol via libssh [no]
>--enable-libtesseractenable Tesseract, needed for ocr filter [no]
>--enable-libtheora   enable Theora encoding via libtheora [no]
> +  --enable-libturing   enable H.265/HEVC encoding via libturing [no]
>--enable-libtwolame  enable MP2 encoding via libtwolame [no]
>--enable-libv4l2 enable libv4l2/v4l-utils [no]
>--enable-libvidstab  enable video stabilization using vid.stab [no]
> @@ -1534,6 +1535,7 @@ EXTERNAL_LIBRARY_LIST="
>  libssh
>  libtesseract
>  libtheora
> +libturing
>  libtwolame
>  libv4l2
>  libvidstab
> @@ -2831,6 +2833,7 @@ libspeex_decoder_deps="libspeex"
>  libspeex_encoder_deps="libspeex"
>  libspeex_encoder_select="audio_frame_queue"
>  libtheora_encoder_deps="libtheora"
> +libturing_encoder_deps="libturing"
>  libtwolame_encoder_deps="libtwolame"
>  libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
>  libvorbis_decoder_deps="libvorbis"
> @@ -5096,6 +5099,7 @@ die_license_disabled gpl frei0r
>  die_license_disabled gpl libcdio
>  die_license_disabled gpl librubberband
>  die_license_disabled gpl libsmbclient
> +die_license_disabled gpl libturing
>  die_license_disabled gpl libvidstab
>  die_license_disabled gpl libx264
>  die_license_disabled gpl libx265
> @@ -5754,6 +5758,7 @@ enabled libssh&& require_pkg_config libssh 
> libssh/sftp.h sftp_init
>  enabled libspeex  && require_pkg_config speex speex/speex.h 
> speex_decoder_init -lspeex
>  enabled libtesseract  && require_pkg_config tesseract tesseract/capi.h 
> TessBaseAPICreate
>  enabled libtheora && require libtheora theora/theoraenc.h 
> th_info_init -ltheoraenc -ltheoradec -logg
> +enabled libturing && require_pkg_config libturing turing.h 
> turing_version
>  enabled libtwolame&& require libtwolame twolame.h twolame_init 
> -ltwolame &&
>   { check_lib twolame.h 
> twolame_encode_buffer_float32_interleaved -ltwolame ||
> die "ERROR: libtwolame must be installed and 
> version must be >= 0.3.10"; }
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 82f7fa2..cadefdc 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -880,6 +880,7 @@ OBJS-$(CONFIG_LIBSPEEX_DECODER)   += libspeexdec.o
>  OBJS-$(CONFIG_LIBSPEEX_ENCODER)   += libspeexenc.o
>  OBJS-$(CONFIG_LIBTHEORA_ENCODER)  += libtheoraenc.o
>  OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
> +OBJS-$(CONFIG_LIBTURING_ENCODER)  += libturing.o
>  OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) += libvo-amrwbenc.o
>  OBJS-$(CONFIG_LIBVORBIS_DECODER)  += libvorbisdec.o
>  OBJS-$(CONFIG_LIBVORBIS_ENCODER)  += libvorbisenc.o \
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index ada9481..0e61a4a 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -610,6 +610,7 @@ void avcodec_register_all(void)
>  REGISTER_ENCDEC (LIBSPEEX,  libspeex);
>  REGISTER_ENCODER(LIBTHEORA, libtheora);
>  REGISTER_ENCODER(LIBTWOLAME,libtwolame);
> +REGISTER_ENCODER(LIBTURING, libturing);
>  REGISTER_ENCODER(LIBVO_AMRWBENC,libvo_amrwbenc);
>  REGISTER_ENCDEC (LIBVORBIS, libvorbis);
>  REGISTER_ENCDEC (LIBVPX_VP8,libvpx_vp8);
> diff --git a/libavcodec/libturing.c b/libavco

Re: [FFmpeg-devel] [PATCH] avformat/hls: Added subtitle support

On Tue, 29 Nov 2016 17:44:15 +
Franklin Phillips  wrote:

> Hi,
> 
> If there are no more comments can we look at merging this please?

I think your previous post implied that subtitles are actually timed
correctly, right?

If so, I don't mind it being applied as-is.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] Add a compat stdatomic.h implementation based on windows atomics

2016-11-29 Thread Wan-Teh Chang

I studied the history of vlc/include/vlc_atomic.h and compared it wth
libav/compat/atomics/win32/stdatomic.h.

1. vlc/include/vlc_atomic.h was initially written by Rémi
Denis-Courmont. This is the most substantial commit by Rémi
Denis-Courmont:

http://git.videolan.org/gitweb.cgi/vlc.git/?a=commit;h=ad3586579f956b6856d2f7c0c4cbd860fd8241af

2. The Windows port was written by Felix Abecassis. Note that he
didn't add his copyright notice to vlc/include/vlc_atomic.h. This is
the most substantial commit by Felix Abecassis:

http://git.videolan.org/gitweb.cgi/vlc.git/?a=commit;h=9c077c0d28df2ad7387b4db8702bd023b2556c86

3. libav/compat/atomics/win32/stdatomic.h contains code that is
apparently derived from the code in vlc/include/vlc_atomic.h written
by both Rémi Denis-Courmont and Felix Abecassis, but doesn't have a
copyright notice.

Similarly, libav/compat/atomics/suncc/stdatomic.h contains code that
is apparently derived from the code in vlc/include/vlc_atomic.h
written by Rémi Denis-Courmont, but doesn't have a copyright notice.

4. Given this information, should I add a copyright notice to
ffmpeg/compat/atomics/win32/stdatomic.h and
ffmpeg/compat/atomics/suncc/stdatomic.h?

5. A related question: libav/compat/atomics/pthread/stdatomic.c does
NOT contain any code that is apparently derived from the code in
vlc/include/vlc_atomic.h written by Rémi Denis-Courmont, but
libav/compat/atomics/pthread/stdatomic.c contains a copyright notice
of Rémi Denis-Courmont. Should I remove that copyright notice from
ffmpeg/compat/atomics/pthread/stdatomic.c?

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

Re: [FFmpeg-devel] [PATCH] Added Turing codec interface for ffmpeg

2016-11-29 Thread Josh de Kock

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 29/11/2016 17:18, Matteo Naccari wrote:
> [...]

Please send any later versions of this patch as a reply to the same
thread with a v3 (or later). For example (for this email): [PATCH v3]

Thanks,

- -- 
Josh

PGP fingerprint: A93A602D7A6D3C5388D792BCD052D40DDEF9703D
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJYPcAXAAoJENBS1A3e+XA9rUcP/3MPd02eNhdicHaXvi901eFs
LW5gUkzZfHIB9MqslgRyxtOEFwNzUxaavQCJUGTMSn/hkzXUNYH3Mlsg9w6yata/
Sh1nHrm9/iEOAKSu46m+0NhIIjlbX3kDQWUcAV3dixig2bMiYjyS0skypgIXVPCX
C+Kkbn4yv1YgJkogAXzftxsIsqegZuPIEJIxhahU1CCnUTaCPvw4mRaahtqZTx9U
O2ucQ6Z46oWIZArub8VGeC0rEYhesHwTQ24iyLGXHQWbQ92gxRaZ9z8Xw/Mxmzdn
D2scnqQR4BimjC9DQtSIKxIdnAknQtokNvLYJs59V4Y7DPBXgsA7mHoUBmW5ZDeh
kh5MkUuHQwOm9QbpHY7oXiMNTPwo3yJY8XNzTmykscCPVVL4GWdlbEFRjxWFpYFG
JTZ03TGcinOI+JpV4Air0tocijySnxDGSGvekMJC2KrNDIDuMRxc8tHFtp9tBRny
oHz2noIBenzO8UjxWAL7APLGBMiajB0I+9Kyunh7zaPyN3uq3tIQvtmAshKFZNhY
5g3jPJsfONBBl3Du4USroWHTxO2CkVEZPouZKyJHj25Y+iYk7EM6eq8YJrhtx5fN
+tTYbaTIt0LjrKi2Q/mehgU7vBMj8TxT/ke+zi2TG/4PuqhVzH5in+q+TWkUxm6L
hznUVrlS39z1vQ+4lwh1
=jLHk
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hls: Added subtitle support

2016-11-29 Thread Franklin Phillips

Hi,

If there are no more comments can we look at merging this please?

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

[FFmpeg-devel] [PATCH] Added Turing codec interface for ffmpeg

2016-11-29 Thread Matteo Naccari

- This patch contains the changes to interface the Turing codec
  (http://turingcodec.org/) to ffmpeg. The patch was modified to address
  the comments in the review as follows:
  - Added a pkg-config file to list all dependencies required by
  libturing. This should address the issue pointed out by Hendrik
  Leppkes on Fri 18/11/2016
  - The buffer to store the turing-params options has now a size which
  depends on how many of these parameters have been passed by the user.
  The sizeof(char) and casting for the malloc calls have been removed as
  per suggestion of wm4. Moreover, the maximum length for a whole option
  (i.e. --param=value) is computed and the related buffer size allocated
  accordingly.
---
 LICENSE.md |   1 +
 configure  |   5 +
 libavcodec/Makefile|   1 +
 libavcodec/allcodecs.c |   1 +
 libavcodec/libturing.c | 270 +
 5 files changed, 278 insertions(+)
 create mode 100644 libavcodec/libturing.c

diff --git a/LICENSE.md b/LICENSE.md
index 640633c..86e5371 100644
--- a/LICENSE.md
+++ b/LICENSE.md
@@ -85,6 +85,7 @@ The following libraries are under GPL:
 - frei0r
 - libcdio
 - librubberband
+- libturing
 - libvidstab
 - libx264
 - libx265
diff --git a/configure b/configure
index 6345fc2..022ffa9 100755
--- a/configure
+++ b/configure
@@ -255,6 +255,7 @@ External library support:
   --enable-libssh  enable SFTP protocol via libssh [no]
   --enable-libtesseractenable Tesseract, needed for ocr filter [no]
   --enable-libtheora   enable Theora encoding via libtheora [no]
+  --enable-libturing   enable H.265/HEVC encoding via libturing [no]
   --enable-libtwolame  enable MP2 encoding via libtwolame [no]
   --enable-libv4l2 enable libv4l2/v4l-utils [no]
   --enable-libvidstab  enable video stabilization using vid.stab [no]
@@ -1534,6 +1535,7 @@ EXTERNAL_LIBRARY_LIST="
 libssh
 libtesseract
 libtheora
+libturing
 libtwolame
 libv4l2
 libvidstab
@@ -2831,6 +2833,7 @@ libspeex_decoder_deps="libspeex"
 libspeex_encoder_deps="libspeex"
 libspeex_encoder_select="audio_frame_queue"
 libtheora_encoder_deps="libtheora"
+libturing_encoder_deps="libturing"
 libtwolame_encoder_deps="libtwolame"
 libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
 libvorbis_decoder_deps="libvorbis"
@@ -5096,6 +5099,7 @@ die_license_disabled gpl frei0r
 die_license_disabled gpl libcdio
 die_license_disabled gpl librubberband
 die_license_disabled gpl libsmbclient
+die_license_disabled gpl libturing
 die_license_disabled gpl libvidstab
 die_license_disabled gpl libx264
 die_license_disabled gpl libx265
@@ -5754,6 +5758,7 @@ enabled libssh&& require_pkg_config libssh 
libssh/sftp.h sftp_init
 enabled libspeex  && require_pkg_config speex speex/speex.h 
speex_decoder_init -lspeex
 enabled libtesseract  && require_pkg_config tesseract tesseract/capi.h 
TessBaseAPICreate
 enabled libtheora && require libtheora theora/theoraenc.h th_info_init 
-ltheoraenc -ltheoradec -logg
+enabled libturing && require_pkg_config libturing turing.h 
turing_version
 enabled libtwolame&& require libtwolame twolame.h twolame_init 
-ltwolame &&
  { check_lib twolame.h 
twolame_encode_buffer_float32_interleaved -ltwolame ||
die "ERROR: libtwolame must be installed and 
version must be >= 0.3.10"; }
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 82f7fa2..cadefdc 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -880,6 +880,7 @@ OBJS-$(CONFIG_LIBSPEEX_DECODER)   += libspeexdec.o
 OBJS-$(CONFIG_LIBSPEEX_ENCODER)   += libspeexenc.o
 OBJS-$(CONFIG_LIBTHEORA_ENCODER)  += libtheoraenc.o
 OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
+OBJS-$(CONFIG_LIBTURING_ENCODER)  += libturing.o
 OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) += libvo-amrwbenc.o
 OBJS-$(CONFIG_LIBVORBIS_DECODER)  += libvorbisdec.o
 OBJS-$(CONFIG_LIBVORBIS_ENCODER)  += libvorbisenc.o \
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index ada9481..0e61a4a 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -610,6 +610,7 @@ void avcodec_register_all(void)
 REGISTER_ENCDEC (LIBSPEEX,  libspeex);
 REGISTER_ENCODER(LIBTHEORA, libtheora);
 REGISTER_ENCODER(LIBTWOLAME,libtwolame);
+REGISTER_ENCODER(LIBTURING, libturing);
 REGISTER_ENCODER(LIBVO_AMRWBENC,libvo_amrwbenc);
 REGISTER_ENCDEC (LIBVORBIS, libvorbis);
 REGISTER_ENCDEC (LIBVPX_VP8,libvpx_vp8);
diff --git a/libavcodec/libturing.c b/libavcodec/libturing.c
new file mode 100644
index 000..a62fafb
--- /dev/null
+++ b/libavcodec/libturing.c
@@ -0,0 +1,270 @@
+/*
+ * libturing encoder
+ *
+ * Copyright (c) 2016 Turing Codec contributors
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redi

Re: [FFmpeg-devel] [PATCH 1/2] tests/ffserver-regression.sh: give wget a timeout and prevent retries

2016-11-29 Thread Reynaldo H. Verdejo Pinochet


Both OK. Thanks.

--
Reynaldo H. Verdejo Pinochet
Open Source Group - Samsung Research America

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

Re: [FFmpeg-devel] [PATCH 2/3] hevc: Support extradata changes

On Tue, Nov 29, 2016 at 10:53:15AM -0500, Vittorio Giovara wrote:
> On Tue, Nov 29, 2016 at 7:20 AM, Michael Niedermayer
>  wrote:
> > On Mon, Nov 28, 2016 at 10:03:37PM -0500, Vittorio Giovara wrote:
> >> On Mon, Nov 28, 2016 at 9:06 PM, Michael Niedermayer
> >>  wrote:
> >> > On Tue, Nov 08, 2016 at 05:03:27PM -0500, Vittorio Giovara wrote:
> >> >> Signed-off-by: Vittorio Giovara 
> >> >> ---
> >> >> Applied review.
> >> >> Please CC.
> >> >> Vittorio
> >> >>
> >> >>  libavcodec/hevc.c | 10 ++
> >> >>  libavformat/mov.c |  4 
> >> >
> >> > please split this in 2 patches, the libavcodec one probably should
> >> > also have its version bumped as apps might want to depend on
> >> > a libavcodec with that feature
> >>
> >> ok for the version bumb, why splitting it 2 patches though?
> >
> > making changes to 2 libs at the same time can mask bugs because
> > you cannot checkout and test the intermediate but in distributions
> > users can end up with one lib updated and the other not (within what
> > the dependancies and versions allow)
> > So i always suggest spliting non cosmetic changes into a patch per lib
> > unless i miss/forget
> 
> Well yes, but the changes in lavf only drop a log line, which is
> useless because of this patch, so imo it makes sense to keep them in
> the same diff. I'll split it if you insist though.

its ok to keep it on one patch if you prefer

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

You can kill me, but you cannot change the truth.


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] avcodec/h264: sse2 and avx 4:2:2 idct add8 10-bit functions

On 2016-11-29 15:30, Carl Eugen Hoyos wrote:
> 2016-11-29 12:52 GMT+01:00 James Darnley :
>> sse2:
>> complex: 4.13x faster (1514 vs. 367 cycles)
>> simple:  4.38x faster (1836 vs. 419 cycles)
>>
>> avx:
>> complex: 1.07x faster (260 vs. 244 cycles)
>> simple:  1.03x faster (284 vs. 274 cycles)
> 
> What are you comparing?

I stuck a timer around the call to the h264dsp function in
libavcodec/h264_mb_template.c.  Using STOP_TIMER(__func__) let me get a
different message for each function created.  The two functions my code
was called from were hl_decode_mb_simple_16 and hl_decode_mb_complex.

The video being decoded was one from fate concatenated together several
times.

The AVX comparison is it versus SSE2.

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

Re: [FFmpeg-devel] [PATCH] lavfi/avfiltergraph: always reduce all_layouts to a single layout

2016-11-29 Thread Marton Balint



On Sun, 27 Nov 2016, Nicolas George wrote:


Le tridi 3 frimaire, an CCXXV, Marton Balint a écrit :

I thought we are trying to move away from workarounds introduced only to be
able to be compatible with libav API. So this is clearly libav dirving
ffmpeg development, which is not fortunate IMHO.

I also think that the chance of an exploitable filter because of this is
small. An audio filter with no query_formats is quite rare in itself. Even
if such a filter got merged, making it work with unknown channel layouts is
a feature which we would want anyway, becase ffmpeg does support unknown
channel layouts.

Yes, it is not me who does the merges, but IMHO this does not add too much
burden for the people who does it. Hendrik, Clement, what do you think?

And even if such an issue got in the codebase, isn't this something that
coverity should be able to easily detect most of the times?


In principle, I think we would want to get rid of the work-ardounds and
have all filters support unknown layouts. But we also want our users to
have a working and reliable tool. Meeting both objectives requires
auditing and testing.

If we make unknown layouts the default and a filter that does not work
with them sneaks through, it will sometimes use 0 as the number of
channels. Depending on how much it does so, it can have several
unfortunate consequences, most probably either a generic error message
(probably "invalid argument" or "out of memory"), a corrupted output or
a crash (and unless proven otherwise, a crash must be assumed to be
exploitable).

Automated testing can not help us catching them. Neither FATE nor
coverity, the way they currently work.

On the other hand, detecting filters that do not work correctly is not
very hard in itself. The use of av_get_channel_layout_nb_channels() is a
very reliable condition. But it could be hidden in a call to an external
function. Making them work is usually rather easy too: replace
av_get_channel_layout_nb_channels() with the corresponding "channels"
field.

Here is, to the best of my knowledge, the current state of affairs. With
that information, we can decide to make unknown layouts the default. But
that is not my decision alone.

If it happens, I will try to help paying attention to new filters, but I
can not promise I will succeed catching them all.

Also, if we decide to proceed, I think we should not just make
all_counts the default: the all_counts / all_layouts logic is rather
complex, and with all_counts the default it becomes essentially dead
code. But the decision comes first.



There can be filters where .query_format is defined and they still can 
refer to all_formats and not all_counts, so i am not sure we can remove 
the all_formats/all_counts logic so easily.


Anyway, how can we move forward here? Apparently there is not too much 
interest in the topic... Since this can be easily changed later, I can 
also rework the patch to add the .query_formats callback to all filters 
currently not supporting unkown layouts until this is decided. What do you 
think? Obviously I prefer my original approach, but since it is not too 
much work, I can change the patch as well.


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

Re: [FFmpeg-devel] [PATCH] nvenc: always reduce DAR width and height

2016-11-29 Thread Timo Rothenpieler

(avctx->sample_aspect_ratio.num != 1 || avctx->sample_aspect_ratio.num
!= 1)) {

Damn, never noticed that typo.
Just fixing the typo should be fine as well, but I like the new logic
better so this LGTM and will push soon as well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vf_scale_npp: move aspect ratio correction after, av_frame_copy_props

2016-11-29 Thread Timo Rothenpieler

I'm not technically the maintainer of scale_npp, but this LGTM to me.
Will push with my next batch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] Add a compat stdatomic.h implementation based on windows atomics

On Tue, 29 Nov 2016 07:55:18 -0800
Wan-Teh Chang  wrote:

> On Tue, Nov 29, 2016 at 6:46 AM, Carl Eugen Hoyos  wrote:
> > 2016-11-29 0:29 GMT+01:00 Wan-Teh Chang :
> >  
> >> Adapted from the code by Rémi Denis-Courmont from VLC  
> >
> > Missing copyright statement, please do not commit as-is!  
> 
> Hi Carl,
> 
> I made only the following changes to the Libav commits:
> 
> 1. I changed Libav's LGPL license header to FFmpeg's LGPL license header.
> 
> 2. I changed the header inclusion guard macros (from
> LIBAV_COMPAT_ATOMICS_..._STDATOMIC_H to
> COMPAT_ATOMICS_..._STDATOMIC_H).
> 
> Rémi Denis-Courmont's copyright notice is not in all the headers I
> copied from Libav. I can do some source code archaeology in the VLC
> source code repository.

I don't think that's required anyway.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] hevc: Support extradata changes

2016-11-29 Thread Vittorio Giovara

On Tue, Nov 29, 2016 at 7:20 AM, Michael Niedermayer
 wrote:
> On Mon, Nov 28, 2016 at 10:03:37PM -0500, Vittorio Giovara wrote:
>> On Mon, Nov 28, 2016 at 9:06 PM, Michael Niedermayer
>>  wrote:
>> > On Tue, Nov 08, 2016 at 05:03:27PM -0500, Vittorio Giovara wrote:
>> >> Signed-off-by: Vittorio Giovara 
>> >> ---
>> >> Applied review.
>> >> Please CC.
>> >> Vittorio
>> >>
>> >>  libavcodec/hevc.c | 10 ++
>> >>  libavformat/mov.c |  4 
>> >
>> > please split this in 2 patches, the libavcodec one probably should
>> > also have its version bumped as apps might want to depend on
>> > a libavcodec with that feature
>>
>> ok for the version bumb, why splitting it 2 patches though?
>
> making changes to 2 libs at the same time can mask bugs because
> you cannot checkout and test the intermediate but in distributions
> users can end up with one lib updated and the other not (within what
> the dependancies and versions allow)
> So i always suggest spliting non cosmetic changes into a patch per lib
> unless i miss/forget

Well yes, but the changes in lavf only drop a log line, which is
useless because of this patch, so imo it makes sense to keep them in
the same diff. I'll split it if you insist though.
Thanks
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] Add a compat stdatomic.h implementation based on windows atomics

2016-11-29 Thread Wan-Teh Chang

On Tue, Nov 29, 2016 at 6:46 AM, Carl Eugen Hoyos  wrote:
> 2016-11-29 0:29 GMT+01:00 Wan-Teh Chang :
>
>> Adapted from the code by Rémi Denis-Courmont from VLC
>
> Missing copyright statement, please do not commit as-is!

Hi Carl,

I made only the following changes to the Libav commits:

1. I changed Libav's LGPL license header to FFmpeg's LGPL license header.

2. I changed the header inclusion guard macros (from
LIBAV_COMPAT_ATOMICS_..._STDATOMIC_H to
COMPAT_ATOMICS_..._STDATOMIC_H).

Rémi Denis-Courmont's copyright notice is not in all the headers I
copied from Libav. I can do some source code archaeology in the VLC
source code repository.

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

Re: [FFmpeg-devel] [PATCH 1/4] Add a compat stdatomic.h implementation based on windows atomics

2016-11-29 0:29 GMT+01:00 Wan-Teh Chang :

> Adapted from the code by Rémi Denis-Courmont from VLC

Missing copyright statement, please do not commit as-is!

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/h264: sse2 and avx 4:2:2 idct add8 10-bit functions

2016-11-29 12:52 GMT+01:00 James Darnley :
> sse2:
> complex: 4.13x faster (1514 vs. 367 cycles)
> simple:  4.38x faster (1836 vs. 419 cycles)
>
> avx:
> complex: 1.07x faster (260 vs. 244 cycles)
> simple:  1.03x faster (284 vs. 274 cycles)

What are you comparing?

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

Re: [FFmpeg-devel] [PATCH 2/3] hevc: Support extradata changes

On Mon, Nov 28, 2016 at 10:03:37PM -0500, Vittorio Giovara wrote:
> On Mon, Nov 28, 2016 at 9:06 PM, Michael Niedermayer
>  wrote:
> > On Tue, Nov 08, 2016 at 05:03:27PM -0500, Vittorio Giovara wrote:
> >> Signed-off-by: Vittorio Giovara 
> >> ---
> >> Applied review.
> >> Please CC.
> >> Vittorio
> >>
> >>  libavcodec/hevc.c | 10 ++
> >>  libavformat/mov.c |  4 
> >
> > please split this in 2 patches, the libavcodec one probably should
> > also have its version bumped as apps might want to depend on
> > a libavcodec with that feature
> 
> ok for the version bumb, why splitting it 2 patches though?

making changes to 2 libs at the same time can mask bugs because
you cannot checkout and test the intermediate but in distributions
users can end up with one lib updated and the other not (within what
the dependancies and versions allow)
So i always suggest spliting non cosmetic changes into a patch per lib
unless i miss/forget

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

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


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

Re: [FFmpeg-devel] [PATCH] Allow client to enable/disable openh264 load balancing.

2016-11-29 Thread Moritz Barsnick

On Mon, Nov 28, 2016 at 16:29:01 -0500, Gregory J. Wolfe wrote:
> +#if OPENH264_VER_AT_LEAST(1, 6)
> +{ "load_balancing", "enable/disable load balancing", 
> OFFSET(load_balancing), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, VE },
> +#endif

This could use a documentation update.

And since documentation isn't built conditionally, the option could be
made available unconditionally, and this:

> +#if OPENH264_VER_AT_LEAST(1, 6)
> +param.bUseLoadBalancing  = s->load_balancing;
> +#endif

be made to print a warning in an #else .. #endif case. (Perhaps make
the AV_OPT_TYPE_BOOL option default to -1 in order to detect whether it
was set.)

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

Re: [FFmpeg-devel] [PATCH 1/4] Add a compat stdatomic.h implementation based on windows atomics

On Mon, 28 Nov 2016 15:29:53 -0800
Wan-Teh Chang  wrote:

> From: Anton Khirnov 
> 
> Adapted from the code by Rémi Denis-Courmont from VLC
> 
> This merges libav commit c2755864afadfbaa349e8d583665c86fe99fa90b.
> 
> Signed-off-by: Wan-Teh Chang 
> ---

Patchset seems ok. No changes to the actual ffmpeg code yet. I assume
the patches are unchanged from Libav.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/3] avcodec/h264: mmxext 4:2:2 chroma intra deblock/loop filter

2.1 times faster (401 vs. 194 cycles)
---
 libavcodec/x86/h264_deblock.asm | 14 ++
 libavcodec/x86/h264dsp_init.c   |  2 ++
 2 files changed, 16 insertions(+)

diff --git a/libavcodec/x86/h264_deblock.asm b/libavcodec/x86/h264_deblock.asm
index 4aabbc0..fe0ab20 100644
--- a/libavcodec/x86/h264_deblock.asm
+++ b/libavcodec/x86/h264_deblock.asm
@@ -946,6 +946,20 @@ cglobal deblock_h_chroma_intra_8, 4,6
 TRANSPOSE8x4B_STORE PASS8ROWS(t5, r0, r1, t6)
 RET
 
+cglobal deblock_h_chroma422_intra_8, 4, 6
+CHROMA_H_START
+TRANSPOSE4x8_LOAD  bw, wd, dq, PASS8ROWS(t5, r0, r1, t6)
+call ff_chroma_intra_body_mmxext
+TRANSPOSE8x4B_STORE PASS8ROWS(t5, r0, r1, t6)
+
+lea r0, [r0+r1*8]
+lea t5, [t5+r1*8]
+
+TRANSPOSE4x8_LOAD  bw, wd, dq, PASS8ROWS(t5, r0, r1, t6)
+call ff_chroma_intra_body_mmxext
+TRANSPOSE8x4B_STORE PASS8ROWS(t5, r0, r1, t6)
+RET
+
 ALIGN 16
 ff_chroma_intra_body_mmxext:
 LOAD_MASK r2d, r3d
diff --git a/libavcodec/x86/h264dsp_init.c b/libavcodec/x86/h264dsp_init.c
index d2452c7..027c1ae 100644
--- a/libavcodec/x86/h264dsp_init.c
+++ b/libavcodec/x86/h264dsp_init.c
@@ -130,6 +130,7 @@ LF_FUNCS(uint8_t,   8)
 LF_FUNCS(uint16_t, 10)
 
 void ff_deblock_h_chroma422_8_mmxext(uint8_t *pix, int stride, int alpha, int 
beta, int8_t *tc0);
+LF_IFUNC(h, chroma422_intra, 8, mmxext)
 
 #if ARCH_X86_32 && HAVE_MMXEXT_EXTERNAL
 LF_FUNC(v8, luma, 8, mmxext)
@@ -249,6 +250,7 @@ av_cold void ff_h264dsp_init_x86(H264DSPContext *c, const 
int bit_depth,
 c->h264_h_loop_filter_chroma_intra = 
ff_deblock_h_chroma_intra_8_mmxext;
 } else {
 c->h264_h_loop_filter_chroma = ff_deblock_h_chroma422_8_mmxext;
+c->h264_h_loop_filter_chroma_intra = 
ff_deblock_h_chroma422_intra_8_mmxext;
 }
 #if ARCH_X86_32 && HAVE_MMXEXT_EXTERNAL
 c->h264_v_loop_filter_luma   = deblock_v_luma_8_mmxext;
-- 
2.10.2

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

[FFmpeg-devel] [PATCH 3/3] avcodec/h264: sse2 and avx 4:2:2 idct add8 10-bit functions

sse2:
complex: 4.13x faster (1514 vs. 367 cycles)
simple:  4.38x faster (1836 vs. 419 cycles)

avx:
complex: 1.07x faster (260 vs. 244 cycles)
simple:  1.03x faster (284 vs. 274 cycles)
---
 libavcodec/x86/h264_idct_10bit.asm | 53 ++
 libavcodec/x86/h264dsp_init.c  | 13 --
 2 files changed, 64 insertions(+), 2 deletions(-)

diff --git a/libavcodec/x86/h264_idct_10bit.asm 
b/libavcodec/x86/h264_idct_10bit.asm
index 4f7491d..9fd05ab 100644
--- a/libavcodec/x86/h264_idct_10bit.asm
+++ b/libavcodec/x86/h264_idct_10bit.asm
@@ -351,6 +351,59 @@ IDCT_ADD8
 %endif
 
 ;-
+; void ff_h264_idct_add8_422_10(pixel **dst, const int *block_offset,
+;   int16_t *block, int stride,
+;   const uint8_t nnzc[6*8])
+;-
+%assign last_block 44
+
+%macro IDCT_ADD8_422 0
+
+cglobal h264_idct_add8_422_10, 5, 8, 7
+movsxdifnidn r3, r3d
+%if ARCH_X86_64
+mov  r7, r0
+%endif
+
+add  r2, 1024
+mov  r0, [r0]
+ADD16_OP_INTRA 16, 4+ 6*8
+ADD16_OP_INTRA 18, 4+ 7*8
+ADD16_OP_INTRA 24, 4+ 8*8 ; i+4
+ADD16_OP_INTRA 26, 4+ 9*8 ; i+4
+add  r2, 1024-128*4
+
+%if ARCH_X86_64
+mov  r0, [r7+gprsize]
+%else
+mov  r0, r0m
+mov  r0, [r0+gprsize]
+%endif
+
+ADD16_OP_INTRA 32, 4+11*8
+ADD16_OP_INTRA 34, 4+12*8
+ADD16_OP_INTRA 40, 4+13*8 ; i+4
+ADD16_OP_INTRA 42, 4+14*8 ; i+4
+REP_RET
+AC 16
+AC 18
+AC 24 ; i+4
+AC 26 ; i+4
+AC 32
+AC 34
+AC 40 ; i+4
+AC 42 ; i+4
+
+%endmacro
+
+INIT_XMM sse2
+IDCT_ADD8_422
+%if HAVE_AVX_EXTERNAL
+INIT_XMM avx
+IDCT_ADD8_422
+%endif
+
+;-
 ; void ff_h264_idct8_add_10(pixel *dst, int16_t *block, int stride)
 ;-
 %macro IDCT8_1D 2
diff --git a/libavcodec/x86/h264dsp_init.c b/libavcodec/x86/h264dsp_init.c
index ed52c4d..c6c643a 100644
--- a/libavcodec/x86/h264dsp_init.c
+++ b/libavcodec/x86/h264dsp_init.c
@@ -80,6 +80,9 @@ IDCT_ADD_REP_FUNC2(, 8, 10, avx)
 
 IDCT_ADD_REP_FUNC2(, 8_422, 8, mmx)
 
+IDCT_ADD_REP_FUNC2(, 8_422, 10, sse2)
+IDCT_ADD_REP_FUNC2(, 8_422, 10, avx)
+
 void ff_h264_luma_dc_dequant_idct_mmx(int16_t *output, int16_t *input, int 
qmul);
 void ff_h264_luma_dc_dequant_idct_sse2(int16_t *output, int16_t *input, int 
qmul);
 
@@ -319,8 +322,11 @@ av_cold void ff_h264dsp_init_x86(H264DSPContext *c, const 
int bit_depth,
 c->h264_idct8_dc_add = ff_h264_idct8_dc_add_10_sse2;
 
 c->h264_idct_add16 = ff_h264_idct_add16_10_sse2;
-if (chroma_format_idc <= 1)
+if (chroma_format_idc <= 1) {
 c->h264_idct_add8 = ff_h264_idct_add8_10_sse2;
+} else {
+c->h264_idct_add8 = ff_h264_idct_add8_422_10_sse2;
+}
 c->h264_idct_add16intra = ff_h264_idct_add16intra_10_sse2;
 #if HAVE_ALIGNED_STACK
 c->h264_idct8_add  = ff_h264_idct8_add_10_sse2;
@@ -359,8 +365,11 @@ av_cold void ff_h264dsp_init_x86(H264DSPContext *c, const 
int bit_depth,
 c->h264_idct8_dc_add = ff_h264_idct8_dc_add_10_avx;
 
 c->h264_idct_add16 = ff_h264_idct_add16_10_avx;
-if (chroma_format_idc <= 1)
+if (chroma_format_idc <= 1) {
 c->h264_idct_add8 = ff_h264_idct_add8_10_avx;
+} else {
+c->h264_idct_add8 = ff_h264_idct_add8_422_10_avx;
+}
 c->h264_idct_add16intra = ff_h264_idct_add16intra_10_avx;
 #if HAVE_ALIGNED_STACK
 c->h264_idct8_add  = ff_h264_idct8_add_10_avx;
-- 
2.10.2

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

[FFmpeg-devel] [PATCH 2/3] avcodec/h264: mmx 4:2:2 idct add8 function

2.87 times faster (1830 vs. 638 cycles)
---
 libavcodec/x86/h264_idct.asm  | 32 
 libavcodec/x86/h264dsp_init.c |  7 ++-
 2 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/libavcodec/x86/h264_idct.asm b/libavcodec/x86/h264_idct.asm
index 27222cb..c36fea5 100644
--- a/libavcodec/x86/h264_idct.asm
+++ b/libavcodec/x86/h264_idct.asm
@@ -697,6 +697,38 @@ cglobal h264_idct_add8_8, 5, 8 + npicregs, 0, dst1, 
block_offset, block, stride,
 call h264_idct_add8_mmx_plane
 RET
 
+cglobal h264_idct_add8_422_8, 5, 8 + npicregs, 0, dst1, block_offset, block, 
stride, nnzc, cntr, coeff, dst2, picreg
+; dst1, block_offset, block, stride, nnzc, cntr, coeff, dst2, picreg
+movsxdifnidn r3, r3d
+%ifdef PIC
+lea picregq, [scan8_mem]
+%endif
+%if ARCH_X86_64
+mov   dst2q, r0
+%endif
+
+mov  r5, 16  ; i
+add  r2, 512 ; i * 16 * sizeof(dctcoef) ; #define dctcoef int16_t
+
+call h264_idct_add8_mmx_plane
+add r5, 4
+call h264_idct_add8_mmx_plane
+
+%if ARCH_X86_64
+add   dst2q, gprsize ; dest[1]
+%else
+addr0mp, gprsize
+%endif
+
+add r5, 4   ; set to 32
+add r2, 256 ; set to i * 16 * sizeof(dctcoef)
+
+call h264_idct_add8_mmx_plane
+add r5, 4
+call h264_idct_add8_mmx_plane
+
+RET
+
 h264_idct_add8_mmxext_plane:
 movsxdifnidn r3, r3d
 .nextblock:
diff --git a/libavcodec/x86/h264dsp_init.c b/libavcodec/x86/h264dsp_init.c
index 027c1ae..ed52c4d 100644
--- a/libavcodec/x86/h264dsp_init.c
+++ b/libavcodec/x86/h264dsp_init.c
@@ -78,6 +78,8 @@ IDCT_ADD_REP_FUNC2(, 8, 8, sse2)
 IDCT_ADD_REP_FUNC2(, 8, 10, sse2)
 IDCT_ADD_REP_FUNC2(, 8, 10, avx)
 
+IDCT_ADD_REP_FUNC2(, 8_422, 8, mmx)
+
 void ff_h264_luma_dc_dequant_idct_mmx(int16_t *output, int16_t *input, int 
qmul);
 void ff_h264_luma_dc_dequant_idct_sse2(int16_t *output, int16_t *input, int 
qmul);
 
@@ -228,8 +230,11 @@ av_cold void ff_h264dsp_init_x86(H264DSPContext *c, const 
int bit_depth,
 
 c->h264_idct_add16 = ff_h264_idct_add16_8_mmx;
 c->h264_idct8_add4 = ff_h264_idct8_add4_8_mmx;
-if (chroma_format_idc <= 1)
+if (chroma_format_idc <= 1) {
 c->h264_idct_add8 = ff_h264_idct_add8_8_mmx;
+} else {
+c->h264_idct_add8 = ff_h264_idct_add8_422_8_mmx;
+}
 c->h264_idct_add16intra = ff_h264_idct_add16intra_8_mmx;
 if (cpu_flags & AV_CPU_FLAG_CMOV)
 c->h264_luma_dc_dequant_idct = 
ff_h264_luma_dc_dequant_idct_mmx;
-- 
2.10.2

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

[FFmpeg-devel] [PATCH 0/3] Some new H.264 4:2:2 assembly