[FFmpeg-devel] [PATCH] avcodec/wavpack: Fix runtime error: left shift of negative value -2

2017-03-03 Thread Michael Niedermayer 
Fixes: 723/clusterfuzz-testcase-6471394663596032

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/wavpack.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
index ebcdd96508..fbbd57d40b 100644
--- a/libavcodec/wavpack.c
+++ b/libavcodec/wavpack.c
@@ -739,13 +739,13 @@ static int wavpack_decode_block(AVCodecContext *avctx, 
int block_no,
 }
 for (i = 0; i < weights; i++) {
 t = (int8_t)bytestream2_get_byte(&gb);
-s->decorr[s->terms - i - 1].weightA = t << 3;
+s->decorr[s->terms - i - 1].weightA = t * (1 << 3);
 if (s->decorr[s->terms - i - 1].weightA > 0)
 s->decorr[s->terms - i - 1].weightA +=
 (s->decorr[s->terms - i - 1].weightA + 64) >> 7;
 if (s->stereo_in) {
 t = (int8_t)bytestream2_get_byte(&gb);
-s->decorr[s->terms - i - 1].weightB = t << 3;
+s->decorr[s->terms - i - 1].weightB = t * (1 << 3);
 if (s->decorr[s->terms - i - 1].weightB > 0)
 s->decorr[s->terms - i - 1].weightB +=
 (s->decorr[s->terms - i - 1].weightB + 64) >> 7;
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] avcodec/proresdec2: Do not discard frames with bad slices

2017-03-03 Thread Marton Balint 


On Sat, 4 Mar 2017, Michael Niedermayer wrote:


The code previously completely discarded frames that had any error in a slice


Could you set either AVFrame->flags to AV_FRAME_FLAG_CORRUPT or 
AVFrame->decode_error_flags to FF_DECODE_ERROR_INVALID_BITSTREAM in case 
of error on any of the slices?


Thanks,
Marton



Signed-off-by: Michael Niedermayer 
---
libavcodec/proresdec2.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index a3a1ebdecb..75fba9d35d 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@ -618,10 +618,11 @@ static int decode_picture(AVCodecContext *avctx)
avctx->execute2(avctx, decode_slice_thread, NULL, NULL, ctx->slice_count);

for (i = 0; i < ctx->slice_count; i++)
-if (ctx->slices[i].ret < 0)
-return ctx->slices[i].ret;
+if (ctx->slices[i].ret >= 0)
+return 0;

-return 0;
+av_assert0(ctx->slice_count>0);
+return ctx->slices[0].ret;
}

static int decode_frame(AVCodecContext *avctx, void *data, int *got_frame,
--
2.11.0

___
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 2/2] avcodec/mpeg4videodec: Improve the overflow checks in mpeg4_decode_sprite_trajectory()

2017-03-03 Thread Michael Niedermayer 
On Thu, Mar 02, 2017 at 03:02:07AM +0100, Michael Niedermayer wrote:
> Also clear the state on errors
> 
> Fixes integer overflows in 701/clusterfuzz-testcase-6594719951880192
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/mpeg4videodec.c | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)

applied

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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] avcodec/vp56: Require a correctly decoded frame before using vp56_conceal_mb()

2017-03-03 Thread Michael Niedermayer 
On Thu, Mar 02, 2017 at 03:02:06AM +0100, Michael Niedermayer wrote:
> Fixes timeout with 700/clusterfuzz-testcase-5660909504561152
> Fixes timeout with 702/clusterfuzz-testcase-4553541576294400
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/vp56.c | 14 +-
>  libavcodec/vp56.h |  3 +++
>  2 files changed, 16 insertions(+), 1 deletion(-)

applied


[...]
-- 
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] avformat/hlsenc: move the segment files handle close before temp flags process

2017-03-03 Thread Steven Liu 
2017-03-03 7:18 GMT+08:00 Steven Liu :

>
>
> 2017-03-01 10:23 GMT+08:00 Steven Liu :
>
>> fix ticket: #6204
>>
>> Signed-off-by: Steven Liu 
>> ---
>>  libavformat/hlsenc.c | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index 9cf6211..b8122f1 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -1329,13 +1329,14 @@ static int hls_write_packet(AVFormatContext *s,
>> AVPacket *pkt)
>>  new_start_pos = avio_tell(hls->avf->pb);
>>  hls->size = new_start_pos - hls->start_pos;
>>
>> +ff_format_io_close(s, &oc->pb);
>> +if (hls->vtt_avf) {
>> +ff_format_io_close(s, &hls->vtt_avf->pb);
>> +}
>>  if ((hls->flags & HLS_TEMP_FILE) && oc->filename[0]) {
>>  if (!(hls->flags & HLS_SINGLE_FILE) || (hls->max_seg_size <=
>> 0))
>>  if (hls->avf->oformat->priv_class && hls->avf->priv_data)
>>  av_opt_set(hls->avf->priv_data, "mpegts_flags",
>> "resend_headers", 0);
>> -ff_format_io_close(s, &oc->pb);
>> -if (hls->vtt_avf)
>> -ff_format_io_close(s, &hls->vtt_avf->pb);
>>  hls_rename_temp_file(s, oc);
>>  }
>>
>> --
>> 2.10.1 (Apple Git-78)
>>
>>
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> will push after 24 hours
>

pushed


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

Re: [FFmpeg-devel] [PATCH] lavc/libvpxenc: add -row-mt option

2017-03-03 Thread James Zern 
On Fri, Mar 3, 2017 at 2:20 AM, Kagami Hiiragi  wrote:
> [...]
>
> Updated. I don't think -slices would fit logically because -row-mt is boolean 
> and -slices is integer.
>
> ---
>  libavcodec/libvpxenc.c | 11 +++
>  1 file changed, 11 insertions(+)
>

Looks all right, I'll submit it soon if there are no other comments.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/proresdec2: Do not discard frames with bad slices

2017-03-03 Thread Michael Niedermayer 
The code previously completely discarded frames that had any error in a slice

Signed-off-by: Michael Niedermayer 
---
 libavcodec/proresdec2.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index a3a1ebdecb..75fba9d35d 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@ -618,10 +618,11 @@ static int decode_picture(AVCodecContext *avctx)
 avctx->execute2(avctx, decode_slice_thread, NULL, NULL, ctx->slice_count);
 
 for (i = 0; i < ctx->slice_count; i++)
-if (ctx->slices[i].ret < 0)
-return ctx->slices[i].ret;
+if (ctx->slices[i].ret >= 0)
+return 0;
 
-return 0;
+av_assert0(ctx->slice_count>0);
+return ctx->slices[0].ret;
 }
 
 static int decode_frame(AVCodecContext *avctx, void *data, int *got_frame,
-- 
2.11.0

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

Re: [FFmpeg-devel] Vincent Lang

2017-03-03 Thread Lou Logan 
On Thu, Mar 2, 2017, at 11:39 PM, Carl Eugen Hoyos wrote:
> Hi Admins!
> 
> Please revoke Vincent's commit rights for intentionally braking
> development rules.
> 
> Carl Eugen

I consider your message to be doxing, and I believe such behavior is in
violation of our Code of Conduct.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/3] avcodec/wavpack: Check bitrate_acc for overflow

2017-03-03 Thread Michael Niedermayer 
Fixes: undefined behavior in 717/clusterfuzz-testcase-5434924129583104

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/wavpack.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
index ebcdd96508..bf538a9b87 100644
--- a/libavcodec/wavpack.c
+++ b/libavcodec/wavpack.c
@@ -99,11 +99,13 @@ static av_always_inline int get_tail(GetBitContext *gb, int 
k)
 return res;
 }
 
-static void update_error_limit(WavpackFrameContext *ctx)
+static int update_error_limit(WavpackFrameContext *ctx)
 {
 int i, br[2], sl[2];
 
 for (i = 0; i <= ctx->stereo_in; i++) {
+if (ctx->ch[i].bitrate_acc > UINT_MAX - ctx->ch[i].bitrate_delta)
+return AVERROR_INVALIDDATA;
 ctx->ch[i].bitrate_acc += ctx->ch[i].bitrate_delta;
 br[i]   = ctx->ch[i].bitrate_acc >> 16;
 sl[i]   = LEVEL_DECAY(ctx->ch[i].slow_level);
@@ -131,6 +133,8 @@ static void update_error_limit(WavpackFrameContext *ctx)
 ctx->ch[i].error_limit = wp_exp2(br[i]);
 }
 }
+
+return 0;
 }
 
 static int wv_get_value(WavpackFrameContext *ctx, GetBitContext *gb,
@@ -200,8 +204,10 @@ static int wv_get_value(WavpackFrameContext *ctx, 
GetBitContext *gb,
 ctx->zero = !ctx->one;
 }
 
-if (ctx->hybrid && !channel)
-update_error_limit(ctx);
+if (ctx->hybrid && !channel) {
+if (update_error_limit(ctx) < 0)
+goto error;
+}
 
 if (!t) {
 base = 0;
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 1/3] avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: 134527392 * 16 cannot be represented in type 'int'

2017-03-03 Thread Michael Niedermayer 
This checks the sprite delta intermediates for overflow
Fixes: 716/clusterfuzz-testcase-4890287480504320

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/mpeg4videodec.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index 568263ecdf..128469d755 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -389,7 +389,10 @@ static int mpeg4_decode_sprite_trajectory(Mpeg4DecContext 
*ctx, GetBitContext *g
 for (i = 0; i < 2; i++) {
 if (llabs(s->sprite_offset[0][i] + s->sprite_delta[i][0] * 
(w+16LL)) >= INT_MAX ||
 llabs(s->sprite_offset[0][i] + s->sprite_delta[i][1] * 
(h+16LL)) >= INT_MAX ||
-llabs(s->sprite_offset[0][i] + s->sprite_delta[i][0] * 
(w+16LL) + s->sprite_delta[i][1] * (h+16LL)) >= INT_MAX) {
+llabs(s->sprite_offset[0][i] + s->sprite_delta[i][0] * 
(w+16LL) + s->sprite_delta[i][1] * (h+16LL)) >= INT_MAX ||
+llabs(s->sprite_delta[i][0] * (w+16LL)) >= INT_MAX ||
+llabs(s->sprite_delta[i][1] * (w+16LL)) >= INT_MAX
+) {
 avpriv_request_sample(s->avctx, "Overflow on sprite points");
 goto overflow;
 }
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 3/3] avcodec/dcadsp: Fix 2 runtime error: signed integer overflow: -1958094138 - 1078906344 cannot be represented in type 'int'

2017-03-03 Thread Michael Niedermayer 
Fixes: 722/clusterfuzz-testcase-5711268868521984

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/dcadsp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/dcadsp.c b/libavcodec/dcadsp.c
index 1503d00886..4f1e933cfb 100644
--- a/libavcodec/dcadsp.c
+++ b/libavcodec/dcadsp.c
@@ -347,7 +347,7 @@ static void dmix_scale_inv_c(int32_t *dst, int scale_inv, 
ptrdiff_t len)
 dst[i] = mul16(dst[i], scale_inv);
 }
 
-static void filter0(int32_t *dst, const int32_t *src, int32_t coeff, ptrdiff_t 
len)
+static void filter0(SUINT32 *dst, const int32_t *src, int32_t coeff, ptrdiff_t 
len)
 {
 int i;
 
@@ -355,7 +355,7 @@ static void filter0(int32_t *dst, const int32_t *src, 
int32_t coeff, ptrdiff_t l
 dst[i] -= mul22(src[i], coeff);
 }
 
-static void filter1(int32_t *dst, const int32_t *src, int32_t coeff, ptrdiff_t 
len)
+static void filter1(SUINT32 *dst, const int32_t *src, int32_t coeff, ptrdiff_t 
len)
 {
 int i;
 
-- 
2.11.0

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

Re: [FFmpeg-devel] Google Summer of Code

2017-03-03 Thread Reynaldo H. Verdejo Pinochet 

Hi Vidur. Please double check you got Paul's email as it
might contain additional information. However, the
generalities of the program are documented in the following
webpage. Please do take a look at it if you haven't already:

https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2017

Bests,

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

Re: [FFmpeg-devel] Google Summer of Code

2017-03-03 Thread Paul B Mahol 
On 3/3/17, Vidur Satija  wrote:
> Respected Sir/Madam,
> I'm an amateur developer and new to the Open Source Community but I would
> like to contribute to FFmpeg, can you please guide me along?
> I have intermediate C programming skills, I'm reading and implementing more
> and would like to help.
>

I replied to you already, did you got email at all?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] HEVC Video Transcode Transfer VUI, SEI Information

2017-03-03 Thread Jan Ekstrom 
On Fri, Mar 3, 2017 at 4:38 AM, Ben Chang  wrote:
>
> In short, is there any way to transfer meta data between a decode and encode 
> context in transcode scenario? If not, would it be supported in foreseeable 
> future?
>

Hi,

AVFrames do contain fields for:
* color_primaries
* color_trc
* colorspace
... and then there is the "new" side data type for the mastering
display data (AVMasteringDisplayMetadata).

So in theory if the decoder exports that information (AVC supports at
least the first three, and HEVC the latter side data as well) and you
utilize those values of the AVFrame in the encoder module, that should
be possible to obtain. Also I think AVFilter also takes in AVFrames,
which makes utilization of such information and updating it throughout
the chain possible when using the libav* framework.

Also, the recently merged better initialization of inputs in ffmpeg.c
might possibly help with some formats if ffmpeg.c is utilized and the
components involved support using the information within the AVFrames.

Best regards,
Jan Ekström
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Google Summer of Code

2017-03-03 Thread Vidur Satija 
Respected Sir/Madam,
I'm an amateur developer and new to the Open Source Community but I would
like to contribute to FFmpeg, can you please guide me along?
I have intermediate C programming skills, I'm reading and implementing more
and would like to help.

Thanking you,
Vidur Satija
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] -

2017-03-03 Thread Raja Mathanky Shankar 
Unsubscibe

-- 
regards,
Raja mathanky. S
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avutil/md5: stop discarding the const qualifier for the src pointer

2017-03-03 Thread James Almer 
On 3/3/2017 12:36 PM, Michael Niedermayer wrote:
> On Fri, Mar 03, 2017 at 01:54:20AM -0300, James Almer wrote:
>> The code modifying the buffer on big endian systems was removed.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavutil/md5.c | 13 +++--
>>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> LGTM
> 
> thx

Pushed.

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

Re: [FFmpeg-devel] [PATCH 1/2] avutil/md5: fix misaligned reads

2017-03-03 Thread James Almer 
On 3/3/2017 12:34 PM, Michael Niedermayer wrote:
> On Fri, Mar 03, 2017 at 01:54:19AM -0300, James Almer wrote:
>> This makes ubsan happy and also considerably increases performance on
>> big endian systems.
> 
> please include the difference in speed in the commit message if you
> tested (it sounds like you did)

I didn't, Nicolas George did some time ago back the first time i sent
this patch.
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-February/190027.html

> 
> should be fine otherwise
> 
> thx

Pushed.

> 
> [...]
> 
> 
> 
> ___
> 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 7/7] avcodec/vp3: Do not return random positive values but the buf size

2017-03-03 Thread Michael Niedermayer 
On Thu, Dec 15, 2016 at 09:21:13PM +0100, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/vp3.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

applied

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

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


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

Re: [FFmpeg-devel] [PATCH] omx: Add support for specifying H.264 profile [v5']

2017-03-03 Thread Michael Niedermayer 
On Fri, Mar 03, 2017 at 03:17:37PM +0900, Takayuki 'January June' Suwa wrote:
> From: Takayuki 'January June' Suwa 
> 
> This adds "-profile[:v] profile_name"-style option.
> ---
>  libavcodec/omx.c | 18 ++
>  1 file changed, 18 insertions(+)

applied

thx

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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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/2] avutil/md5: stop discarding the const qualifier for the src pointer

2017-03-03 Thread Michael Niedermayer 
On Fri, Mar 03, 2017 at 01:54:20AM -0300, James Almer wrote:
> The code modifying the buffer on big endian systems was removed.
> 
> Signed-off-by: James Almer 
> ---
>  libavutil/md5.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)

LGTM

thx

[...]
-- 
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 1/2] avutil/md5: fix misaligned reads

2017-03-03 Thread Michael Niedermayer 
On Fri, Mar 03, 2017 at 01:54:19AM -0300, James Almer wrote:
> This makes ubsan happy and also considerably increases performance on
> big endian systems.

please include the difference in speed in the commit message if you
tested (it sounds like you did)

should be fine otherwise

thx

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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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

Re: [FFmpeg-devel] [PATCH v2 2/3] avcodec: estimate output bitrate for ffv1/huffyuv codecs

2017-03-03 Thread Michael Niedermayer 
On Mon, Feb 06, 2017 at 01:33:19PM +0100, Tobias Rapp wrote:
> Allows to get a more realistic total bitrate (and estimated file size)
> in avi_write_header. Previously a static default value of 200k was
> assumed.
> 
> Signed-off-by: Tobias Rapp 
> ---
>  libavcodec/ffv1enc.c   |  4 
>  libavcodec/huffyuvenc.c|  4 
>  libavcodec/internal.h  |  6 ++
>  libavcodec/utils.c | 21 +
>  tests/ref/vsynth/vsynth1-ffv1  |  2 +-
>  tests/ref/vsynth/vsynth1-ffv1-v0   |  2 +-
>  tests/ref/vsynth/vsynth1-ffv1-v3-bgr0  |  2 +-
>  tests/ref/vsynth/vsynth1-ffv1-v3-rgb48 |  2 +-
>  tests/ref/vsynth/vsynth1-ffv1-v3-yuv420p   |  2 +-
>  tests/ref/vsynth/vsynth1-ffv1-v3-yuv422p10 |  2 +-
>  tests/ref/vsynth/vsynth1-ffv1-v3-yuv444p16 |  2 +-
>  tests/ref/vsynth/vsynth1-ffvhuff   |  2 +-
>  tests/ref/vsynth/vsynth1-ffvhuff420p12 |  2 +-
>  tests/ref/vsynth/vsynth1-ffvhuff422p10left |  2 +-
>  tests/ref/vsynth/vsynth1-ffvhuff444|  2 +-
>  tests/ref/vsynth/vsynth1-ffvhuff444p16 |  2 +-
>  tests/ref/vsynth/vsynth1-huffyuv   |  2 +-
>  tests/ref/vsynth/vsynth1-huffyuvbgr24  |  2 +-
>  tests/ref/vsynth/vsynth1-huffyuvbgra   |  2 +-
>  tests/ref/vsynth/vsynth2-ffv1  |  2 +-
>  tests/ref/vsynth/vsynth2-ffv1-v0   |  2 +-
>  tests/ref/vsynth/vsynth2-ffv1-v3-bgr0  |  2 +-
>  tests/ref/vsynth/vsynth2-ffv1-v3-rgb48 |  2 +-
>  tests/ref/vsynth/vsynth2-ffv1-v3-yuv420p   |  2 +-
>  tests/ref/vsynth/vsynth2-ffv1-v3-yuv422p10 |  2 +-
>  tests/ref/vsynth/vsynth2-ffv1-v3-yuv444p16 |  2 +-
>  tests/ref/vsynth/vsynth2-ffvhuff   |  2 +-
>  tests/ref/vsynth/vsynth2-ffvhuff420p12 |  2 +-
>  tests/ref/vsynth/vsynth2-ffvhuff422p10left |  2 +-
>  tests/ref/vsynth/vsynth2-ffvhuff444|  2 +-
>  tests/ref/vsynth/vsynth2-ffvhuff444p16 |  2 +-
>  tests/ref/vsynth/vsynth2-huffyuv   |  2 +-
>  tests/ref/vsynth/vsynth2-huffyuvbgr24  |  2 +-
>  tests/ref/vsynth/vsynth2-huffyuvbgra   |  2 +-
>  tests/ref/vsynth/vsynth3-ffv1  |  2 +-
>  tests/ref/vsynth/vsynth3-ffv1-v0   |  2 +-
>  tests/ref/vsynth/vsynth3-ffv1-v3-bgr0  |  2 +-
>  tests/ref/vsynth/vsynth3-ffv1-v3-rgb48 |  2 +-
>  tests/ref/vsynth/vsynth3-ffv1-v3-yuv420p   |  2 +-
>  tests/ref/vsynth/vsynth3-ffv1-v3-yuv422p10 |  2 +-
>  tests/ref/vsynth/vsynth3-ffv1-v3-yuv444p16 |  2 +-
>  tests/ref/vsynth/vsynth3-ffvhuff   |  2 +-
>  tests/ref/vsynth/vsynth3-ffvhuff420p12 |  2 +-
>  tests/ref/vsynth/vsynth3-ffvhuff422p10left |  2 +-
>  tests/ref/vsynth/vsynth3-ffvhuff444|  2 +-
>  tests/ref/vsynth/vsynth3-ffvhuff444p16 |  2 +-
>  tests/ref/vsynth/vsynth3-huffyuv   |  2 +-
>  tests/ref/vsynth/vsynth3-huffyuvbgr24  |  2 +-
>  tests/ref/vsynth/vsynth3-huffyuvbgra   |  2 +-
>  tests/ref/vsynth/vsynth_lena-ffv1  |  2 +-
>  tests/ref/vsynth/vsynth_lena-ffv1-v0   |  2 +-
>  tests/ref/vsynth/vsynth_lena-ffv1-v3-bgr0  |  2 +-
>  tests/ref/vsynth/vsynth_lena-ffv1-v3-rgb48 |  2 +-
>  tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv420p   |  2 +-
>  tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv422p10 |  2 +-
>  tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv444p16 |  2 +-
>  tests/ref/vsynth/vsynth_lena-ffvhuff   |  2 +-
>  tests/ref/vsynth/vsynth_lena-ffvhuff420p12 |  2 +-
>  tests/ref/vsynth/vsynth_lena-ffvhuff422p10left |  2 +-
>  tests/ref/vsynth/vsynth_lena-ffvhuff444|  2 +-
>  tests/ref/vsynth/vsynth_lena-ffvhuff444p16 |  2 +-
>  tests/ref/vsynth/vsynth_lena-huffyuv   |  2 +-
>  tests/ref/vsynth/vsynth_lena-huffyuvbgr24  |  2 +-
>  tests/ref/vsynth/vsynth_lena-huffyuvbgra   |  2 +-
>  64 files changed, 95 insertions(+), 60 deletions(-)
> 
> diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
> index 35f54c6..7138cc0 100644
> --- a/libavcodec/ffv1enc.c
> +++ b/libavcodec/ffv1enc.c
> @@ -894,6 +894,10 @@ slices_ok:
>  }
>  }
>  
> +// estimate bitrate assuming 40% compression
> +avctx->bit_rate = ff_guess_coded_bitrate(avctx) * 2 / 5;
> +avctx->bit_rate_tolerance = avctx->bit_rate;
> +
>  return 0;
>  }
>  
> diff --git a/libavcodec/huffyuvenc.c b/libavcodec/huffyuvenc.c
> index 89639b7..8911408 100644
> --- a/libavcodec/huffyuvenc.c
> +++ b/libavcodec/huffyuvenc.c
> @@ -446,6 +446,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  
>  s->picture_number=0;
>  
> +// estimate bitrate assuming 60% compression
> +avctx->bit_rate = ff_guess_coded_bitrate(avctx) * 3 / 5;
> +avctx->bit_rate_tolerance = avctx->bit_rate;

these violate the API

See avcodec.h:
/**
 * number of bits the bitstream is allowed to diverge from the refer

Re: [FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

2017-03-03 Thread Michael Niedermayer 
On Fri, Mar 03, 2017 at 02:30:49PM +0100, wm4 wrote:
> On Fri, 3 Mar 2017 14:21:37 +0100
> Michael Niedermayer  wrote:
> 
> > On Fri, Mar 03, 2017 at 09:53:17AM +0100, wm4 wrote:
> > > On Thu, 2 Mar 2017 20:31:53 +0100
> > > Michael Niedermayer  wrote:  
> > [...]
> > 
> > > 
> > > You seem to do everything to slow them down. Or that's what it looked
> > > like to me.  
> > 
> > I just test the code and report bugs.
> > 
> > also this is not new, i tested the code similarly when i did the merges
> > long ago ...
> > 
> > also theres something else i keep wondering about and thats
> > for example in this case here many people wanted
> > this patchset and it was a gigantic amount of work you did to get it
> > working and i belive others also helped and its not completely finished
> > yet, users will find bugs noone of us thoight of to test for.
> > Isnt it easier considering we have so many developers interrested in
> > this kind of refactoring that we do this ourselfs on ffmpeg
> > at some point in the future ?
> 
> People were just going to throw hacks on it (see how the qsv and cuvid
> code turned out, or what people do to get a full-hwaccel pipeline going
> with ffmpeg.c).

> Libav did the work, isn't it logical to take it?

absolutely yes, if it is less work for us. my question really was IF
it is actually less work


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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- 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 v3 0/7] Merge lazy filter initialization in ffmpeg CLI

2017-03-03 Thread Hendrik Leppkes 
On Fri, Mar 3, 2017 at 2:21 PM, Michael Niedermayer
 wrote:
>
> the patches break this:
> ./ffmpeg -itsoffset 2 -re -i ~/videos/matrixbench_mpeg2.mpg -vcodec h263 -s 
> cif -an  -t 3 -f rtp rtp://127.0.0.1:19955 >h263.sdp  ./ffmpeg -protocol_whitelist file,rtp,udp -i h263.sdp -y  -t 0.9 out-h263.avi
>
> It appears that h263.sdp is written later than previously
> and the sdp is needed at the receiving side so this might
> impact some real users
>
> the example above works with a sleep 2 instead of sleep 1
>

This sounds to me like this always was a race condition and could
always fail. There have never been any guarantees on timing, and it
depends on how long probing of the file takes, setup of the filters,
etc.
One of the key changes in this set is that output files are indeed
generated later, once all final format information is fully available,
instead of just guessing and creating the output before the input is
initialized fully, which was just a weird dataflow to begin with.

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

Re: [FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

2017-03-03 Thread wm4 
On Fri, 3 Mar 2017 14:21:37 +0100
Michael Niedermayer  wrote:

> On Fri, Mar 03, 2017 at 09:53:17AM +0100, wm4 wrote:
> > On Thu, 2 Mar 2017 20:31:53 +0100
> > Michael Niedermayer  wrote:  
> [...]
> 
> > 
> > You seem to do everything to slow them down. Or that's what it looked
> > like to me.  
> 
> I just test the code and report bugs.
> 
> also this is not new, i tested the code similarly when i did the merges
> long ago ...
> 
> also theres something else i keep wondering about and thats
> for example in this case here many people wanted
> this patchset and it was a gigantic amount of work you did to get it
> working and i belive others also helped and its not completely finished
> yet, users will find bugs noone of us thoight of to test for.
> Isnt it easier considering we have so many developers interrested in
> this kind of refactoring that we do this ourselfs on ffmpeg
> at some point in the future ?

People were just going to throw hacks on it (see how the qsv and cuvid
code turned out, or what people do to get a full-hwaccel pipeline going
with ffmpeg.c). Libav did the work, isn't it logical to take it?

> And yes thats a question iam not implying that i prefer such step or
> prefer the opposite. I cannot even have such preferrance as i did not
> look at some of the patches here, i just tested them and you know
> how many issues the code had
> 
> 
> > 
> > Anyway, I've pushed the patches now, with some local modifications.
> > I've had this sitting on my mind for 3 weeks or so, and now someone
> > wants to get my push rights revoked, so I'll leave it to others to fix
> > the final regressions. Sorry to sound like a dick again, but I'm done
> > here.  
> 
> the patches break this:
> ./ffmpeg -itsoffset 2 -re -i ~/videos/matrixbench_mpeg2.mpg -vcodec h263 -s 
> cif -an  -t 3 -f rtp rtp://127.0.0.1:19955 >h263.sdp  ./ffmpeg -protocol_whitelist file,rtp,udp -i h263.sdp -y  -t 0.9 out-h263.avi
> 
> It appears that h263.sdp is written later than previously
> and the sdp is needed at the receiving side so this might
> impact some real users
> 
> the example above works with a sleep 2 instead of sleep 1
> 
> [...]

Then use a sleep 2 instead of sleep 1. There, fixed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

2017-03-03 Thread James Almer 
On 3/3/2017 10:21 AM, Michael Niedermayer wrote:
> On Fri, Mar 03, 2017 at 09:53:17AM +0100, wm4 wrote:
>> On Thu, 2 Mar 2017 20:31:53 +0100
>> Michael Niedermayer  wrote:
> [...]
> 
>>
>> You seem to do everything to slow them down. Or that's what it looked
>> like to me.
> 
> I just test the code and report bugs.
> 
> also this is not new, i tested the code similarly when i did the merges
> long ago ...
> 
> also theres something else i keep wondering about and thats
> for example in this case here many people wanted
> this patchset and it was a gigantic amount of work you did to get it
> working and i belive others also helped and its not completely finished
> yet, users will find bugs noone of us thoight of to test for.
> Isnt it easier considering we have so many developers interrested in
> this kind of refactoring that we do this ourselfs on ffmpeg
> at some point in the future ?
> And yes thats a question iam not implying that i prefer such step or
> prefer the opposite. I cannot even have such preferrance as i did not
> look at some of the patches here, i just tested them and you know
> how many issues the code had
> 
> 
>>
>> Anyway, I've pushed the patches now, with some local modifications.
>> I've had this sitting on my mind for 3 weeks or so, and now someone
>> wants to get my push rights revoked, so I'll leave it to others to fix
>> the final regressions. Sorry to sound like a dick again, but I'm done
>> here.
> 
> the patches break this:
> ./ffmpeg -itsoffset 2 -re -i ~/videos/matrixbench_mpeg2.mpg -vcodec h263 -s 
> cif -an  -t 3 -f rtp rtp://127.0.0.1:19955 >h263.sdp  ./ffmpeg -protocol_whitelist file,rtp,udp -i h263.sdp -y  -t 0.9 out-h263.avi

To address one of wm4's complains: 
http://samples.ffmpeg.org/benchmark/testsuite1/matrixbench_mpeg2.mpg

> 
> It appears that h263.sdp is written later than previously
> and the sdp is needed at the receiving side so this might
> impact some real users
> 
> the example above works with a sleep 2 instead of sleep 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

Re: [FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

2017-03-03 Thread Michael Niedermayer 
On Fri, Mar 03, 2017 at 09:53:17AM +0100, wm4 wrote:
> On Thu, 2 Mar 2017 20:31:53 +0100
> Michael Niedermayer  wrote:
[...]

> 
> You seem to do everything to slow them down. Or that's what it looked
> like to me.

I just test the code and report bugs.

also this is not new, i tested the code similarly when i did the merges
long ago ...

also theres something else i keep wondering about and thats
for example in this case here many people wanted
this patchset and it was a gigantic amount of work you did to get it
working and i belive others also helped and its not completely finished
yet, users will find bugs noone of us thoight of to test for.
Isnt it easier considering we have so many developers interrested in
this kind of refactoring that we do this ourselfs on ffmpeg
at some point in the future ?
And yes thats a question iam not implying that i prefer such step or
prefer the opposite. I cannot even have such preferrance as i did not
look at some of the patches here, i just tested them and you know
how many issues the code had


> 
> Anyway, I've pushed the patches now, with some local modifications.
> I've had this sitting on my mind for 3 weeks or so, and now someone
> wants to get my push rights revoked, so I'll leave it to others to fix
> the final regressions. Sorry to sound like a dick again, but I'm done
> here.

the patches break this:
./ffmpeg -itsoffset 2 -re -i ~/videos/matrixbench_mpeg2.mpg -vcodec h263 -s cif 
-an  -t 3 -f rtp rtp://127.0.0.1:19955 >h263.sdp 

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

Re: [FFmpeg-devel] Vincent Lang

2017-03-03 Thread Ronald S. Bultje 
Hi Carl,

On Fri, Mar 3, 2017 at 3:39 AM, Carl Eugen Hoyos  wrote:

> Please revoke Vincent's commit rights for intentionally braking
> development rules.


If you're serious, you'll need to elaborate for the committee to vote on
this...

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

Re: [FFmpeg-devel] [PATCH] lavc/videotoolbox: set kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey

2017-03-03 Thread wm4 
On Fri, 3 Mar 2017 18:16:18 +0800
Wang Bin  wrote:

> From 011d03c4d2b6b138de539dcf5019169781ee7fb2 Mon Sep 17 00:00:00 2001
> From: wang-bin 
> Date: Fri, 3 Mar 2017 18:10:54 +0800
> Subject: [PATCH] avcodec/videotoolbox: set
>  kCVPixelBufferOpenGLESCompatibilityKey for iOS
> 
> kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey is not available in
> iOS
> ---
>  libavcodec/videotoolbox.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index 824f2d8e68..9199b02055 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -31,6 +31,7 @@
>  #include "bytestream.h"
>  #include "h264dec.h"
>  #include "mpegvideo.h"
> +#include 
> 
>  #ifndef kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder
>  #  define
> kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder
> CFSTR("RequireHardwareAcceleratedVideoDecoder")
> @@ -477,7 +478,11 @@ static CFDictionaryRef
> videotoolbox_buffer_attributes_create(int width,
>  CFDictionarySetValue(buffer_attributes,
> kCVPixelBufferIOSurfacePropertiesKey, io_surface_properties);
>  CFDictionarySetValue(buffer_attributes, kCVPixelBufferWidthKey, w);
>  CFDictionarySetValue(buffer_attributes, kCVPixelBufferHeightKey, h);
> +#if TARGET_OS_IPHONE
> +CFDictionarySetValue(buffer_attributes,
> kCVPixelBufferOpenGLESCompatibilityKey, kCFBooleanTrue);
> +#else
>  CFDictionarySetValue(buffer_attributes,
> kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey, kCFBooleanTrue);
> +#endif
> 
>  CFRelease(io_surface_properties);
>  CFRelease(cv_pix_fmt);

We use this TARGET_ stuff in some other source files too, so LGTM.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/videotoolbox: set kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey

2017-03-03 Thread Wang Bin 
From 011d03c4d2b6b138de539dcf5019169781ee7fb2 Mon Sep 17 00:00:00 2001
From: wang-bin 
Date: Fri, 3 Mar 2017 18:10:54 +0800
Subject: [PATCH] avcodec/videotoolbox: set
 kCVPixelBufferOpenGLESCompatibilityKey for iOS

kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey is not available in
iOS
---
 libavcodec/videotoolbox.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 824f2d8e68..9199b02055 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -31,6 +31,7 @@
 #include "bytestream.h"
 #include "h264dec.h"
 #include "mpegvideo.h"
+#include 

 #ifndef kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder
 #  define
kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder
CFSTR("RequireHardwareAcceleratedVideoDecoder")
@@ -477,7 +478,11 @@ static CFDictionaryRef
videotoolbox_buffer_attributes_create(int width,
 CFDictionarySetValue(buffer_attributes,
kCVPixelBufferIOSurfacePropertiesKey, io_surface_properties);
 CFDictionarySetValue(buffer_attributes, kCVPixelBufferWidthKey, w);
 CFDictionarySetValue(buffer_attributes, kCVPixelBufferHeightKey, h);
+#if TARGET_OS_IPHONE
+CFDictionarySetValue(buffer_attributes,
kCVPixelBufferOpenGLESCompatibilityKey, kCFBooleanTrue);
+#else
 CFDictionarySetValue(buffer_attributes,
kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey, kCFBooleanTrue);
+#endif

 CFRelease(io_surface_properties);
 CFRelease(cv_pix_fmt);
-- 
2.11.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/libvpxenc: add -row-mt option

2017-03-03 Thread Kagami Hiiragi 
On 03/03/17 10:18, James Zern wrote:
> On Thu, Mar 2, 2017 at 11:00 AM, Kagami Hiiragi  wrote:
>> From ae3856c302284d60761c3ad122ff49b7b9b68114 Mon Sep 17 00:00:00 2001
>> From: Kagami Hiiragi 
>> Date: Thu, 2 Mar 2017 21:19:09 +0300
>> Subject: [PATCH] lavc/libvpxenc: add -row-mt option
>>
>> ---
>>  libavcodec/libvpxenc.c | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> [...]
>>  [VP9E_SET_TARGET_LEVEL]= "VP9E_SET_TARGET_LEVEL",
>>  [VP9E_GET_LEVEL]   = "VP9E_GET_LEVEL",
>>  #endif
>> +#if VPX_ENCODER_ABI_VERSION >= 13
> 
> Better to use #ifdef VPX_CTRL_VP9E_SET_ROW_MT.
> 
>> [...]
>> +#if VPX_ENCODER_ABI_VERSION >= 13
>> +{"row-mt", "Row based multi-threading", OFFSET(row_mt), 
>> AV_OPT_TYPE_INT, {.i64 = -1}, -1, 1, VE},
>> +#endif
> 
> We could use -thread_type/-slices here, though this is in line with
> vpxenc. I'll leave this open to comment.

Updated. I don't think -slices would fit logically because -row-mt is boolean 
and -slices is integer.

---
 libavcodec/libvpxenc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index de0d0b6bcb..7c567a0d1d 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -108,6 +108,7 @@ typedef struct VPxEncoderContext {
 int noise_sensitivity;
 int vpx_cs;
 float level;
+int row_mt;
 } VPxContext;
 
 /** String mappings for enum vp8e_enc_control_id */
@@ -139,6 +140,9 @@ static const char *const ctlidstr[] = {
 [VP9E_SET_TARGET_LEVEL]= "VP9E_SET_TARGET_LEVEL",
 [VP9E_GET_LEVEL]   = "VP9E_GET_LEVEL",
 #endif
+#ifdef VPX_CTRL_VP9E_SET_ROW_MT
+[VP9E_SET_ROW_MT]  = "VP9E_SET_ROW_MT",
+#endif
 #endif
 };
 
@@ -720,6 +724,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
 #if VPX_ENCODER_ABI_VERSION >= 12
 codecctl_int(avctx, VP9E_SET_TARGET_LEVEL, ctx->level < 0 ? 255 : 
lrint(ctx->level * 10));
 #endif
+#ifdef VPX_CTRL_VP9E_SET_ROW_MT
+if (ctx->row_mt >= 0)
+codecctl_int(avctx, VP9E_SET_ROW_MT, ctx->row_mt);
+#endif
 }
 #endif
 
@@ -1132,6 +1140,9 @@ static const AVOption vp9_options[] = {
 #if VPX_ENCODER_ABI_VERSION >= 12
 {"level", "Specify level", OFFSET(level), AV_OPT_TYPE_FLOAT, {.dbl=-1}, 
-1, 6.2, VE},
 #endif
+#ifdef VPX_CTRL_VP9E_SET_ROW_MT
+{"row-mt", "Row based multi-threading", OFFSET(row_mt), AV_OPT_TYPE_BOOL, 
{.i64 = -1}, -1, 1, VE},
+#endif
 LEGACY_OPTIONS
 { NULL }
 };
-- 
2.11.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

2017-03-03 Thread Hendrik Leppkes 
On Fri, Mar 3, 2017 at 10:00 AM, Carl Eugen Hoyos  wrote:
> 2017-03-03 9:53 GMT+01:00 wm4 :
>
>> Anyway, I've pushed the patches now, with some local modifications.
>
> Somebody please revert this, it was not ok to be pushed.
>

There is no cause for that. The patch was on the ML for several weeks
already, and all reported issues (assuming proper information and/or
samples were available) have been analyzed and fixed if appropriate,
including the crash you requested to be fixed before pushing.

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

Re: [FFmpeg-devel] Vincent Lang

2017-03-03 Thread Paul B Mahol 
On 3/3/17, Carl Eugen Hoyos  wrote:
> Hi Admins!
>
> Please revoke Vincent's commit rights for intentionally braking
> development rules.

If that happens you will need to revoke my rights too, as I will
push his patches if he can not anymore.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] swresample/resample: use uniform normalization

2017-03-03 Thread Muhammad Faiz 
On Wed, Mar 1, 2017 at 10:24 PM, Muhammad Faiz  wrote:
> this gives better frequency response
>
> update swresample fate and other fates
> that depend on resampling
>
> Signed-off-by: Muhammad Faiz 
> ---
>  libswresample/resample.c |  14 +--
>  tests/fate/libswresample.mak | 276 
> +--
>  tests/ref/acodec/roqaudio|   2 +-
>  tests/ref/acodec/s302m   |   6 +-
>  tests/ref/lavf/dv_fmt|   8 +-
>  tests/ref/lavf/gxf   |   8 +-
>  tests/ref/lavf/mxf   |  12 +-
>  7 files changed, 163 insertions(+), 163 deletions(-)
>

Test case, from 44100 to 705600 (16*44100)
ffmpeg -filter_complex "aevalsrc='if(n-300,0,1)',
aresample=osr=705600:filter_size=16" -f f32le - | ./freq-resp >
freq-resp.txt


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

Re: [FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

2017-03-03 Thread Carl Eugen Hoyos 
2017-03-03 9:55 GMT+01:00 wm4 :
> On Thu, 2 Mar 2017 16:32:36 -0300
> James Almer  wrote:
>
>> On 3/2/2017 2:27 PM, wm4 wrote:
>> > Well, you already announced that you'd leave the project a few months
>> > ago or so, but nothing happened. As an (apparently involuntary) de-facto
>> > project leader who refuses to fix the leadership associated problems of
>> > the project, it's of course not strange that you get attacked once in a
>> > while. Even if you deny being a project leader, you hold a tad too many
>> > central key positions.
>> >
>> > I realize you probably just want to write code and not deal with these
>> > issues. But on the other hand it seems you're stuck in this position
>> > whether or not you or we want it. The best idea I can come up is to
>> > nominate a new project leader, but I don't know who could do that _and_
>> > keep the project together.
>>
>> Big project decisions pass through the voting committee now. Is it flawed
>> and too crowded? yes, but it's better than total anarchy.
>>
>> Nothing Michael's doing in this thread by reviewing your patchset is even
>> remotely related to being a project leader. His emails and regression
>> reports could have come from anyone else and have the same effect on this
>> patchset.
>
> Those remarks were more in general. Michael has a special status even
> if it's just about those patch reviews though, because he's officially
> maintainer of ffmpeg.c.
>
>>
>> I understand your frustration, as i also had to go through several
>> iterations of a big merge like this one after Michael pointed out some
>> regressions, including identifying some false positives like the timebase
>> change he reported earlier today, but it doesn't justify lashing out at
>> people who are simply pointing out issues.
>
> Again, it was about the way he did. (Low quality reports with
> particularly bad timing.)
>
>>
>> >
>> > Currently, we as a project can't make decisions, and nobody even knows
>> > the damn rules we're supposed to play by. If it's just me, could
>> > someone please set me straight?
>>
>> This is not true, we have had several votes by now with different results.
>> API decisions, deprecation/removal decisions, etc.
>> I liked some, i hated others, but respected all of them. Everyone did.
>
> If you believe it.
> ___
> 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 v3 0/7] Merge lazy filter initialization in ffmpeg CLI

2017-03-03 Thread Carl Eugen Hoyos 
2017-03-03 9:53 GMT+01:00 wm4 :

> Anyway, I've pushed the patches now, with some local modifications.

Somebody please revert this, it was not ok to be pushed.

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

Re: [FFmpeg-devel] [PATCH] lavc/videotoolbox: set kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey

2017-03-03 Thread wm4 
On Fri, 3 Mar 2017 16:53:37 +0800
Wang Bin  wrote:

> >
> > So what happens on iOS with the current code?  
> 
> 
> Compile error. VLC uses kCVPixelBufferOpenGLESCompatibilityKey for iOS and
> kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey for OSX. Should I send
> a patch?

That would be great.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

2017-03-03 Thread wm4 
On Thu, 2 Mar 2017 16:32:36 -0300
James Almer  wrote:

> On 3/2/2017 2:27 PM, wm4 wrote:
> > Well, you already announced that you'd leave the project a few months
> > ago or so, but nothing happened. As an (apparently involuntary) de-facto
> > project leader who refuses to fix the leadership associated problems of
> > the project, it's of course not strange that you get attacked once in a
> > while. Even if you deny being a project leader, you hold a tad too many
> > central key positions.
> > 
> > I realize you probably just want to write code and not deal with these
> > issues. But on the other hand it seems you're stuck in this position
> > whether or not you or we want it. The best idea I can come up is to
> > nominate a new project leader, but I don't know who could do that _and_
> > keep the project together.  
> 
> Big project decisions pass through the voting committee now. Is it flawed
> and too crowded? yes, but it's better than total anarchy.
> 
> Nothing Michael's doing in this thread by reviewing your patchset is even
> remotely related to being a project leader. His emails and regression
> reports could have come from anyone else and have the same effect on this
> patchset.

Those remarks were more in general. Michael has a special status even
if it's just about those patch reviews though, because he's officially
maintainer of ffmpeg.c.

> 
> I understand your frustration, as i also had to go through several
> iterations of a big merge like this one after Michael pointed out some
> regressions, including identifying some false positives like the timebase
> change he reported earlier today, but it doesn't justify lashing out at
> people who are simply pointing out issues.

Again, it was about the way he did. (Low quality reports with
particularly bad timing.)

> 
> > 
> > Currently, we as a project can't make decisions, and nobody even knows
> > the damn rules we're supposed to play by. If it's just me, could
> > someone please set me straight?  
> 
> This is not true, we have had several votes by now with different results.
> API decisions, deprecation/removal decisions, etc.
> I liked some, i hated others, but respected all of them. Everyone did.

If you believe it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

2017-03-03 Thread wm4 
On Thu, 2 Mar 2017 20:31:53 +0100
Michael Niedermayer  wrote:

> On Thu, Mar 02, 2017 at 06:27:29PM +0100, wm4 wrote:
> > On Thu, 2 Mar 2017 17:12:04 +0100
> > Michael Niedermayer  wrote:
> > 
> > > On Thu, Mar 02, 2017 at 02:37:09PM +0100, wm4 wrote:
> > > > On Thu, 2 Mar 2017 14:03:18 +0100
> > > > Michael Niedermayer  wrote:
> > > >   
> > > > > On Thu, Mar 02, 2017 at 09:53:02AM +0100, wm4 wrote:  
> > > > > > These patches merge the previously skipped Libav commits, which made
> > > > > > avconv lazily initialize libavfilter graphs. This means the filters
> > > > > > are initialized with the actual output format, instead of whatever
> > > > > > libavformat reports.
> > > > > > 
> > > > > > It's a prerequisite to making hardware decoding support saner, as
> > > > > > hardware decoders will output a different pixfmt than the software
> > > > > > format reported by libavformat. This can be seen on ffmpeg_qsv.c
> > > > > > and ffmpeg_cuvid.c, which don't lose any functionality, even though
> > > > > > half of the code is removed.
> > > > > > 
> > > > > > There are some differences in how ffmpeg.c and avconv.c filter-flow
> > > > > > works. Also, avconv.c doesn't have sub2video. Relatively intrusive
> > > > > > changes were required.
> > > > > > 
> > > > > > I will push this tomorrow, except if critical failures are found.   
> > > > > >  
> > > > > 
> > > > > I think the patchset improved in terms of regressions but there are
> > > > > still several
> > > > >   
> > > [...]
> > > >  
> > > > > 
> > > > > also this code crashes with some private files:
> > > > > ==7506== Process terminating with default action of signal 11 
> > > > > (SIGSEGV)
> > > > > ==7506==  Access not within mapped region at address 0x8
> > > > > ==7506==at 0x471529: av_buffersink_get_frame_rate 
> > > > > (buffersink.c:193)
> > > > > ==7506==by 0x435B54: init_output_stream_encode (ffmpeg.c:3217)
> > > > > ==7506==by 0x4364A8: init_output_stream (ffmpeg.c:3351)
> > > > > ==7506==by 0x42E4DB: reap_filters (ffmpeg.c:1428)
> > > > > ==7506==by 0x43AA44: transcode_step (ffmpeg.c:4452)
> > > > > ==7506==by 0x43AB28: transcode (ffmpeg.c:4496)
> > > > > ==7506==by 0x43B2FD: main (ffmpeg.c:4701)  
> > > > 
> > > > I don't know if you're shitting me on purpose. I can't fix what I can't
> > > > reproduce, and you never gave me access to those files. Fix it yourself
> > > > if you think it's important. Seriously, what is this.  
> > > 
> > > I ofered access to this file to someone wanting to work on this
> > > previously
> > > "If this backtrace is not sufficient i can share the file privatly
> > >  with someone who wants to work on fixing this"
> > > 
> > > Noone asked for the file, if you want to work on this and keep the file
> > > private, i can share it with you.
> > > 
> > > Its not nice from you to ignore my ofer and then attack me pretending
> > > there was no such offer
> > 
> > OK, I missed that part. Sorry. I guess I overlooked it when I tried to
> > collect all the new test cases and tried to find the required samples
> > (for which you only provided a path on your local disk, and I had to
> > look them up from the ticker number in that path). So I apologize, but
> > I'm still grumpy.
> > 
> > Anyway, _please_ don't report bugs to me in the future without providing
> > a direct sample link (sure, you can do it privately if necessary).
> > 
> 
> > In the mean time, I somehow expected you'd provide me a sample for the
> > case above (in private), since you know that I obviously want and don't
> > have it, but you didn't yet. Why make me ask.
> 
> because i have no permission to share the file unless its neccessary.

Well, you either report it and share the sample, or you don't report
it. Sometimes it's possible to guess the bug from a backtrace, but
usually it's not enough. Maybe some consideration?

> 
> > 
> > Btw., I've tested every single case you pointed out and which I could
> > test.
> 
> you missed one case it seems
> ./ffmpeg -skip_frame nokey -ss 20  -i ~/tickets/2024/dvbsubtest.ts -qscale 2  
> -scodec dvbsub -t 6   -an file.ts
> 
> displays fewer subtitles than before the patchset, i did report this
> case previously

No, your original complaint about this was fixed. After it was fixed,
another issue appeared, but I first decided to ignore it because it
happened only with -skip_frame (i.e. obscure close to nonsensical
corner case).

I've looked at it again anyway this morning. It was caused by a DVB sub
special case in ffmpeg.c that hardcoded the target container's timebase
to 1/9 (originally added by Fabrice Bellard over a decade ago).
This was overlooked by the original Libav patch author. It works now.

> 
> > 
> > > 
> > > >   
> > > > > This one produces a silent audio channel as previous patchsets did too
> > > > > ./ffmpeg -i ~/tickets/1726/Mono.thd out.wav  
> > > > 
> > > > While libavformat signals a mono channel configuration, the decoder
> > > > actually outputs stereo, with one

Re: [FFmpeg-devel] [PATCH] lavc/videotoolbox: set kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey

2017-03-03 Thread Wang Bin 
>
> So what happens on iOS with the current code?


Compile error. VLC uses kCVPixelBufferOpenGLESCompatibilityKey for iOS and
kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey for OSX. Should I send
a patch?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavf/dashenc: update bitrates on dash_write_trailer

2017-03-03 Thread Przemysław Sobala 
From: Przemysław Sobala 

Provides a way to change bandwidth parameter inside DASH manifest after a 
non-CBR H.264 encoding.
Caller now is able to compute the bitrate by itself, after all packets have 
been written, and then set that value in 
AVFormatContext->streams->codecpar->bit_rate before calling av_write_trailer. 
As a result that value will be set in DASH manifest.
---
 libavformat/dashenc.c | 42 ++
 1 file changed, 30 insertions(+), 12 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index fa56505..011d2ea 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -561,6 +561,30 @@ static int write_manifest(AVFormatContext *s, int final)
 return 0;
 }
 
+static int set_bitrate(AVFormatContext *s)
+{
+DASHContext *c = s->priv_data;
+int i;
+
+for (i = 0; i < s->nb_streams; i++) {
+OutputStream *os = &c->streams[i];
+
+os->bit_rate = s->streams[i]->codecpar->bit_rate;
+if (os->bit_rate) {
+snprintf(os->bandwidth_str, sizeof(os->bandwidth_str),
+ " bandwidth=\"%d\"", os->bit_rate);
+} else {
+int level = s->strict_std_compliance >= FF_COMPLIANCE_STRICT ?
+AV_LOG_ERROR : AV_LOG_WARNING;
+av_log(s, level, "No bit rate set for stream %d\n", i);
+if (s->strict_std_compliance >= FF_COMPLIANCE_STRICT)
+return AVERROR(EINVAL);
+}
+}
+
+return 0;
+}
+
 static int dash_init(AVFormatContext *s)
 {
 DASHContext *c = s->priv_data;
@@ -597,6 +621,10 @@ static int dash_init(AVFormatContext *s)
 if (!c->streams)
 return AVERROR(ENOMEM);
 
+ret = set_bitrate(s);
+if (ret < 0)
+return ret;
+
 for (i = 0; i < s->nb_streams; i++) {
 OutputStream *os = &c->streams[i];
 AVFormatContext *ctx;
@@ -604,18 +632,6 @@ static int dash_init(AVFormatContext *s)
 AVDictionary *opts = NULL;
 char filename[1024];
 
-os->bit_rate = s->streams[i]->codecpar->bit_rate;
-if (os->bit_rate) {
-snprintf(os->bandwidth_str, sizeof(os->bandwidth_str),
- " bandwidth=\"%d\"", os->bit_rate);
-} else {
-int level = s->strict_std_compliance >= FF_COMPLIANCE_STRICT ?
-AV_LOG_ERROR : AV_LOG_WARNING;
-av_log(s, level, "No bit rate set for stream %d\n", i);
-if (s->strict_std_compliance >= FF_COMPLIANCE_STRICT)
-return AVERROR(EINVAL);
-}
-
 ctx = avformat_alloc_context();
 if (!ctx)
 return AVERROR(ENOMEM);
@@ -981,6 +997,8 @@ static int dash_write_trailer(AVFormatContext *s)
 {
 DASHContext *c = s->priv_data;
 
+set_bitrate(s);
+
 if (s->nb_streams > 0) {
 OutputStream *os = &c->streams[0];
 // If no segments have been written so far, try to do a crude
-- 
2.7.4

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

[FFmpeg-devel] Vincent Lang

2017-03-03 Thread Carl Eugen Hoyos 
Hi Admins!

Please revoke Vincent's commit rights for intentionally braking
development rules.

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