Re: [FFmpeg-devel] [PATCH 1/2] avutil/internal: Add ff_elog()

2017-02-22 Thread wm4
On Wed, 22 Feb 2017 19:16:46 +0100
Michael Niedermayer  wrote:

> This enables the extra error messages in case of DEBUG or high assrtion 
> levels.
> High assertion levels imply slow checks in inner loops so any extra error 
> should
> be insignificant.
> Is it preferred to have a separate switch for ff_elog() so it doesnt depend on
> DEBUG/assertion level ?
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavutil/internal.h | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/libavutil/internal.h b/libavutil/internal.h
> index 7780a9a791..208f8f474f 100644
> --- a/libavutil/internal.h
> +++ b/libavutil/internal.h
> @@ -262,6 +262,12 @@ void avpriv_request_sample(void *avc,
>  #   define ff_dlog(ctx, ...) do { if (0) av_log(ctx, AV_LOG_DEBUG, 
> __VA_ARGS__); } while (0)
>  #endif
>  
> +#if defined(DEBUG) || ASSERT_LEVEL > 1
> +#   define ff_elog(ctx, ...) av_log(ctx, AV_LOG_ERROR, __VA_ARGS__)
> +#else
> +#   define ff_elog(ctx, ...) do { if (0) av_log(ctx, AV_LOG_ERROR, 
> __VA_ARGS__); } while (0)
> +#endif
> +
>  // For debuging we use signed operations so overflows can be detected (by 
> ubsan)
>  // For production we use unsigned so there are no undefined operations
>  #ifdef CHECKED

Not really a fan of this. (And neither ff_dlog.) But I guess I don't
mean to stop you.

In my opinion, code that checks for overflow and fuzz issues should be
as small and unintrusive as possible, or preferably not exist.

It seems like all these fuzz fixes make code less readable. (Not just
because of the additional logging and control flow, also because of all
those unobvious tricky checks.)

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


Re: [FFmpeg-devel] [PATCH] avcodec/h264_ps: Check chroma_qp_index_offset

2017-02-22 Thread Paul B Mahol
On 2/23/17, Michael Niedermayer  wrote:
> On Wed, Feb 22, 2017 at 07:40:24PM +0100, Paul B Mahol wrote:
>> On 2/22/17, Michael Niedermayer  wrote:
>> > On Wed, Feb 22, 2017 at 04:41:43PM +0100, Paul B Mahol wrote:
>> >> On 2/22/17, Michael Niedermayer  wrote:
>> >> > On Wed, Feb 22, 2017 at 02:29:00PM +0100, Paul B Mahol wrote:
>> >> >> On 2/22/17, Michael Niedermayer  wrote:
>> >> >> > Fixes: 647/clusterfuzz-testcase-5195745823031296
>> >> >> >
>> >> >> > Found-by: continuous fuzzing process
>> >> >> > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
>> >> >> > Signed-off-by: Michael Niedermayer 
>> >> >> > ---
>> >> >> >  libavcodec/h264_ps.c | 11 +++
>> >> >> >  1 file changed, 11 insertions(+)
>> >> >> >
>> >> >> > diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
>> >> >> > index 8090178395..f4a4a01fbe 100644
>> >> >> > --- a/libavcodec/h264_ps.c
>> >> >> > +++ b/libavcodec/h264_ps.c
>> >> >> > @@ -828,6 +828,12 @@ int
>> >> >> > ff_h264_decode_picture_parameter_set(GetBitContext
>> >> >> > *gb, AVCodecContext *avct
>> >> >> >  pps->init_qp  = get_se_golomb(gb)
>> >> >> > +
>> >> >> > 26
>> >> >> > +
>> >> >> > qp_bd_offset;
>> >> >> >  pps->init_qs  = get_se_golomb(gb)
>> >> >> > +
>> >> >> > 26
>> >> >> > +
>> >> >> > qp_bd_offset;
>> >> >> >  pps->chroma_qp_index_offset[0]=
>> >> >> > get_se_golomb(gb);
>> >> >> > +if (pps->chroma_qp_index_offset[0] < -12 ||
>> >> >> > pps->chroma_qp_index_offset[0] > 12) {
>> >> >> > +av_log(avctx, AV_LOG_ERROR, "chroma_qp_index_offset[0]
>> >> >> > %d
>> >> >> > is
>> >> >>
>> >> >> This is nonsense. Please remove.
>> >> >
>> >> > Id like to keep the error messages or id like to have someone else
>> >> > take over h264 maintaince in ffmpeg.
>> >>
>> >> Than why you are posting patches at all, if you do not want to listen
>> >> to reviews.
>> >
>> > ive posted a patchset with ff_elog() instead
>> >
>> > do people prefer that ?
>> >
>> > [...]
>>
>> You could right now start adding such messages at every error path.
>
> ill push my patch without the error messages, i think i failed to
> realize how much the error messages annoy you.

You can apply elog variant if you really need it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH]lavc/libx265: Add gray10 and gray12 encoding support

2017-02-22 Thread Paul B Mahol
On 2/23/17, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch adds gray10 and gray12 native endian encoding support
> to libx265.
>
> Please comment, Carl Eugen
>

Does this get decoded with native hevc?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/qdrw: add support for 0x0001 code

2017-02-22 Thread Paul B Mahol
On 2/23/17, Michael Niedermayer  wrote:
> On Wed, Feb 22, 2017 at 09:25:04PM +0100, Paul B Mahol wrote:
>> ffmpeg | branch: master | Paul B Mahol  | Wed Feb 22
>> 15:32:26 2017 +0100| [fb5c9be82ea870fd0a7643214ebf8728d8e29991] |
>> committer: Paul B Mahol
>>
>> avcodec/qdrw: add support for 0x0001 code
>>
>> Fixes decoding of files which sets frame width/height this way.
>>
>> Signed-off-by: Paul B Mahol 
>>
>> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=fb5c9be82ea870fd0a7643214ebf8728d8e29991
>> ---
>>
>>  libavcodec/qdrw.c | 13 -
>>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> This breaks decoding of food.pct
> i can upload or mail it if you dont have it

I dont have it.

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


Re: [FFmpeg-devel] [PATCH] avcodec/dnxhddec: fix decoding of DNxHR HQX 10-bit

2017-02-22 Thread Paul B Mahol
On 2/23/17, Carl Eugen Hoyos  wrote:
> 2017-02-22 14:51 GMT+01:00 Paul B Mahol :
>> On 2/22/17, Paul B Mahol  wrote:
>>> Signed-off-by: Paul B Mahol 
>>> ---
>>>  libavcodec/dnxhddec.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
>>> index 70ce264..cdbc0bc 100644
>>> --- a/libavcodec/dnxhddec.c
>>> +++ b/libavcodec/dnxhddec.c
>>> @@ -435,7 +435,7 @@ static int dnxhd_decode_dct_block_8(const
>>> DNXHDContext
>>> *ctx,
>>>  static int dnxhd_decode_dct_block_10(const DNXHDContext *ctx,
>>>   RowContext *row, int n)
>>>  {
>>> -return dnxhd_decode_dct_block(ctx, row, n, 6, 8, 4, 0);
>>> +return dnxhd_decode_dct_block(ctx, row, n, 6, 32, 6, 0);
>>>  }
>>>
>>>  static int dnxhd_decode_dct_block_10_444(const DNXHDContext *ctx,
>>> --
>>> 2.9.3
>>>
>>>
>>
>> File can be found here:
>> https://drive.google.com/open?id=0B1hdyiz226iBV1llcDl3LW80U2c
>
> The file does not decode here with your patch applied:
> $ md5sum test.mov
> 25e45b380250bb76296f623fee9d43f1  test.mov

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


Re: [FFmpeg-devel] [PATCH] avdevice/decklink: Remove pthread dependency

2017-02-22 Thread wm4
On Wed, 22 Feb 2017 14:55:23 -0800
Kyle Schwarz  wrote:

> DeckLink depends on pthread, and is silently disabled if pthread is missing.
> 
> Also fixes w32pthreads to support C++.
> ---


>  
> -sem_post(>semaphore);
> +pthread_mutex_unlock(>mutex);
>  
>  return S_OK;

> @@ -248,7 +246,7 @@ static int decklink_write_video_packet(AVFormatContext 
> *avctx, AVPacket *pkt)
>  }
>  
>  /* Always keep at most one second of frames buffered. */
> -sem_wait(>semaphore);
> +pthread_cond_wait(>cond, >mutex);
>  
>  /* Schedule frame for playback. */
>  hr = ctx->dlo->ScheduleVideoFrame((struct IDeckLinkVideoFrame *) frame,

That doesn't really look convincing. These operations do different
things. Moreover, calling pthread_mutex_unlock without a preceding
pthread_mutex_lock is invalid. Calling pthread_cond_wait without
locking the mutex is an error.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] mjpegenc: make optimal huffman coding the default

2017-02-22 Thread Michael Niedermayer
On Wed, Feb 22, 2017 at 10:47:13PM +, Rostislav Pehlivanov wrote:
> Its been extensively tested and it gives gain for practically free, so
> make it enabled by default.
> 
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/mjpegenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
> index cc917edb7f..03c3d0ab13 100644
> --- a/libavcodec/mjpegenc.c
> +++ b/libavcodec/mjpegenc.c
> @@ -444,7 +444,7 @@ FF_MPV_COMMON_OPTS
>  { "left",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 1 }, INT_MIN, INT_MAX, 
> VE, "pred" },
>  { "plane",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 2 }, INT_MIN, INT_MAX, 
> VE, "pred" },
>  { "median", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 3 }, INT_MIN, INT_MAX, 
> VE, "pred" },
> -{ "huffman", "Huffman table strategy", OFFSET(huffman), AV_OPT_TYPE_INT, { 
> .i64 = HUFFMAN_TABLE_DEFAULT }, 0, NB_HUFFMAN_TABLE_OPTION - 1, VE, "huffman" 
> },
> +{ "huffman", "Huffman table strategy", OFFSET(huffman), AV_OPT_TYPE_INT, { 
> .i64 = HUFFMAN_TABLE_OPTIMAL }, 0, NB_HUFFMAN_TABLE_OPTION - 1, VE, "huffman" 
> },
>  { "default", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = HUFFMAN_TABLE_DEFAULT 
> }, INT_MIN, INT_MAX, VE, "huffman" },
>  { "optimal", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = HUFFMAN_TABLE_OPTIMAL 
> }, INT_MIN, INT_MAX, VE, "huffman" },
>  { NULL},
> -- 
> 2.12.0.rc1.440.g5b76565f74


./ffmpeg -i lena.pnm   -threads 2 -thread_type slice file.jpg

fails with

Assertion n <= 31 && value < (1U << n) failed at libavcodec/put_bits.h:157

I dont think slice threads work with optimal huffman 

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

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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


Re: [FFmpeg-devel] [PATCH] mjpegenc: make optimal huffman coding the default

2017-02-22 Thread Michael Niedermayer
On Wed, Feb 22, 2017 at 11:03:58PM -0300, James Almer wrote:
> On 2/22/2017 10:56 PM, Michael Niedermayer wrote:
> > On Wed, Feb 22, 2017 at 10:47:13PM +, Rostislav Pehlivanov wrote:
> >> Its been extensively tested and it gives gain for practically free, so
> >> make it enabled by default.
> >>
> >> Signed-off-by: Rostislav Pehlivanov 
> >> ---
> >>  libavcodec/mjpegenc.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
> >> index cc917edb7f..03c3d0ab13 100644
> >> --- a/libavcodec/mjpegenc.c
> >> +++ b/libavcodec/mjpegenc.c
> >> @@ -444,7 +444,7 @@ FF_MPV_COMMON_OPTS
> >>  { "left",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 1 }, INT_MIN, 
> >> INT_MAX, VE, "pred" },
> >>  { "plane",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 2 }, INT_MIN, 
> >> INT_MAX, VE, "pred" },
> >>  { "median", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 3 }, INT_MIN, 
> >> INT_MAX, VE, "pred" },
> >> -{ "huffman", "Huffman table strategy", OFFSET(huffman), AV_OPT_TYPE_INT, 
> >> { .i64 = HUFFMAN_TABLE_DEFAULT }, 0, NB_HUFFMAN_TABLE_OPTION - 1, VE, 
> >> "huffman" },
> >> +{ "huffman", "Huffman table strategy", OFFSET(huffman), AV_OPT_TYPE_INT, 
> >> { .i64 = HUFFMAN_TABLE_OPTIMAL }, 0, NB_HUFFMAN_TABLE_OPTION - 1, VE, 
> >> "huffman" },
> >>  { "default", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
> >> HUFFMAN_TABLE_DEFAULT }, INT_MIN, INT_MAX, VE, "huffman" },
> >>  { "optimal", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
> >> HUFFMAN_TABLE_OPTIMAL }, INT_MIN, INT_MAX, VE, "huffman" },
> >>  { NULL},
> > 
> > breaks fate
> > 
> > --- ./tests/ref/vsynth/vsynth1-amv  2017-02-20 17:22:51.769108273 +0100
> > +++ tests/data/fate/vsynth1-amv 2017-02-23 02:54:42.983732697 +0100
> > @@ -1,4 +1,4 @@
> > -9e155fcedb3b853876e9ea4233971803 *tests/data/fate/vsynth1-amv.avi
> > -1365500 tests/data/fate/vsynth1-amv.avi
> > -e38681b9527b6d2531942f8a176a0265 *tests/data/fate/vsynth1-amv.out.rawvideo
> > -stddev:   10.07 PSNR: 28.06 MAXDIFF:   98 bytes:  7603200/  7603200
> > +1ab7232e1948a9ae92c745b6ed1dc0b4 *tests/data/fate/vsynth1-amv.avi
> > +1283516 tests/data/fate/vsynth1-amv.avi
> > +58b9ac246e9888c71a7b4e502abb898b *tests/data/fate/vsynth1-amv.out.rawvideo
> > +stddev:  117.66 PSNR:  6.72 MAXDIFF:  239 bytes:  7603200/  7603200
> > Test vsynth1-amv failed. Look at tests/data/fate/vsynth1-amv.err for 
> > details.
> > make: *** [fate-vsynth1-amv] Error 1
> 
> Aren't those numbers worse for that matter?

yes, thats why i quoted that one
there are other fate tests changing but not getting worse.
the amv ones get worse IIRC

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

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


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


Re: [FFmpeg-devel] [PATCH] mjpegenc: make optimal huffman coding the default

2017-02-22 Thread James Almer
On 2/22/2017 10:56 PM, Michael Niedermayer wrote:
> On Wed, Feb 22, 2017 at 10:47:13PM +, Rostislav Pehlivanov wrote:
>> Its been extensively tested and it gives gain for practically free, so
>> make it enabled by default.
>>
>> Signed-off-by: Rostislav Pehlivanov 
>> ---
>>  libavcodec/mjpegenc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
>> index cc917edb7f..03c3d0ab13 100644
>> --- a/libavcodec/mjpegenc.c
>> +++ b/libavcodec/mjpegenc.c
>> @@ -444,7 +444,7 @@ FF_MPV_COMMON_OPTS
>>  { "left",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 1 }, INT_MIN, INT_MAX, 
>> VE, "pred" },
>>  { "plane",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 2 }, INT_MIN, INT_MAX, 
>> VE, "pred" },
>>  { "median", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 3 }, INT_MIN, INT_MAX, 
>> VE, "pred" },
>> -{ "huffman", "Huffman table strategy", OFFSET(huffman), AV_OPT_TYPE_INT, { 
>> .i64 = HUFFMAN_TABLE_DEFAULT }, 0, NB_HUFFMAN_TABLE_OPTION - 1, VE, 
>> "huffman" },
>> +{ "huffman", "Huffman table strategy", OFFSET(huffman), AV_OPT_TYPE_INT, { 
>> .i64 = HUFFMAN_TABLE_OPTIMAL }, 0, NB_HUFFMAN_TABLE_OPTION - 1, VE, 
>> "huffman" },
>>  { "default", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = HUFFMAN_TABLE_DEFAULT 
>> }, INT_MIN, INT_MAX, VE, "huffman" },
>>  { "optimal", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = HUFFMAN_TABLE_OPTIMAL 
>> }, INT_MIN, INT_MAX, VE, "huffman" },
>>  { NULL},
> 
> breaks fate
> 
> --- ./tests/ref/vsynth/vsynth1-amv  2017-02-20 17:22:51.769108273 +0100
> +++ tests/data/fate/vsynth1-amv 2017-02-23 02:54:42.983732697 +0100
> @@ -1,4 +1,4 @@
> -9e155fcedb3b853876e9ea4233971803 *tests/data/fate/vsynth1-amv.avi
> -1365500 tests/data/fate/vsynth1-amv.avi
> -e38681b9527b6d2531942f8a176a0265 *tests/data/fate/vsynth1-amv.out.rawvideo
> -stddev:   10.07 PSNR: 28.06 MAXDIFF:   98 bytes:  7603200/  7603200
> +1ab7232e1948a9ae92c745b6ed1dc0b4 *tests/data/fate/vsynth1-amv.avi
> +1283516 tests/data/fate/vsynth1-amv.avi
> +58b9ac246e9888c71a7b4e502abb898b *tests/data/fate/vsynth1-amv.out.rawvideo
> +stddev:  117.66 PSNR:  6.72 MAXDIFF:  239 bytes:  7603200/  7603200
> Test vsynth1-amv failed. Look at tests/data/fate/vsynth1-amv.err for details.
> make: *** [fate-vsynth1-amv] Error 1

Aren't those numbers worse for that matter?

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


Re: [FFmpeg-devel] [PATCH] mjpegenc: make optimal huffman coding the default

2017-02-22 Thread Michael Niedermayer
On Wed, Feb 22, 2017 at 10:47:13PM +, Rostislav Pehlivanov wrote:
> Its been extensively tested and it gives gain for practically free, so
> make it enabled by default.
> 
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/mjpegenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
> index cc917edb7f..03c3d0ab13 100644
> --- a/libavcodec/mjpegenc.c
> +++ b/libavcodec/mjpegenc.c
> @@ -444,7 +444,7 @@ FF_MPV_COMMON_OPTS
>  { "left",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 1 }, INT_MIN, INT_MAX, 
> VE, "pred" },
>  { "plane",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 2 }, INT_MIN, INT_MAX, 
> VE, "pred" },
>  { "median", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 3 }, INT_MIN, INT_MAX, 
> VE, "pred" },
> -{ "huffman", "Huffman table strategy", OFFSET(huffman), AV_OPT_TYPE_INT, { 
> .i64 = HUFFMAN_TABLE_DEFAULT }, 0, NB_HUFFMAN_TABLE_OPTION - 1, VE, "huffman" 
> },
> +{ "huffman", "Huffman table strategy", OFFSET(huffman), AV_OPT_TYPE_INT, { 
> .i64 = HUFFMAN_TABLE_OPTIMAL }, 0, NB_HUFFMAN_TABLE_OPTION - 1, VE, "huffman" 
> },
>  { "default", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = HUFFMAN_TABLE_DEFAULT 
> }, INT_MIN, INT_MAX, VE, "huffman" },
>  { "optimal", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = HUFFMAN_TABLE_OPTIMAL 
> }, INT_MIN, INT_MAX, VE, "huffman" },
>  { NULL},

breaks fate

--- ./tests/ref/vsynth/vsynth1-amv  2017-02-20 17:22:51.769108273 +0100
+++ tests/data/fate/vsynth1-amv 2017-02-23 02:54:42.983732697 +0100
@@ -1,4 +1,4 @@
-9e155fcedb3b853876e9ea4233971803 *tests/data/fate/vsynth1-amv.avi
-1365500 tests/data/fate/vsynth1-amv.avi
-e38681b9527b6d2531942f8a176a0265 *tests/data/fate/vsynth1-amv.out.rawvideo
-stddev:   10.07 PSNR: 28.06 MAXDIFF:   98 bytes:  7603200/  7603200
+1ab7232e1948a9ae92c745b6ed1dc0b4 *tests/data/fate/vsynth1-amv.avi
+1283516 tests/data/fate/vsynth1-amv.avi
+58b9ac246e9888c71a7b4e502abb898b *tests/data/fate/vsynth1-amv.out.rawvideo
+stddev:  117.66 PSNR:  6.72 MAXDIFF:  239 bytes:  7603200/  7603200
Test vsynth1-amv failed. Look at tests/data/fate/vsynth1-amv.err for details.
make: *** [fate-vsynth1-amv] Error 1

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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


Re: [FFmpeg-devel] [PATCH] fixup! avcodec/mips: version 1 of vc1dsp optimizations for loongson mmi

2017-02-22 Thread Michael Niedermayer
On Wed, Feb 22, 2017 at 03:48:35PM +0100, Jacek Manko wrote:
> ---
>  libavcodec/mips/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

thx

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

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


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


Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/qdrw: add support for 0x0001 code

2017-02-22 Thread Michael Niedermayer
On Wed, Feb 22, 2017 at 09:25:04PM +0100, Paul B Mahol wrote:
> ffmpeg | branch: master | Paul B Mahol  | Wed Feb 22 
> 15:32:26 2017 +0100| [fb5c9be82ea870fd0a7643214ebf8728d8e29991] | committer: 
> Paul B Mahol
> 
> avcodec/qdrw: add support for 0x0001 code
> 
> Fixes decoding of files which sets frame width/height this way.
> 
> Signed-off-by: Paul B Mahol 
> 
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=fb5c9be82ea870fd0a7643214ebf8728d8e29991
> ---
> 
>  libavcodec/qdrw.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)

This breaks decoding of food.pct
i can upload or mail it if you dont have it

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] configure/rtmpdh: Fix OpenSSL 1.1.0 support

2017-02-22 Thread Michael Niedermayer
On Wed, Feb 22, 2017 at 11:15:45PM +, Stefan _ wrote:
> The rtmpdh patch was kinda (completly) broken, fixed patch is attached.
> 
> Concerning LibreSSL:
> They use OPENSSL_VERSION_NUMBER = 0x2050200fL which breaks the other 
> openssl code in tls_openssl.c anyway,
> so LibreSSL support should probably be worried about in a different patch.

>  rtmpdh.c |   94 
> +--
>  rtmpdh.h |   13 +++-
>  2 files changed, 49 insertions(+), 58 deletions(-)
> 98f748d1ed2d6b28214fc053762e7b5a22073cba  
> 0002-rtmpdh-Stop-using-OpenSSL-provided-DH-functions-to-s.patch
> From 0edf1d179824fa6400031c6d05b3f464f01abf36 Mon Sep 17 00:00:00 2001

> From: sfan5 

Is it intended that theres no full name in the git author field ?

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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


Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: fix PoC negative issue

2017-02-22 Thread Jun Zhao
Ping?  I know the commit "eefa4b" give a fix, but I think this one more better 
for this issue :)

On 2017/2/8 15:39, Jun Zhao wrote:
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 4/4] lavfi: Add VAAPI deinterlacer

2017-02-22 Thread Jun Zhao


On 2017/2/20 1:23, Mark Thompson wrote:
> (cherry picked from commit ade370a4d7eab1866b6023c91c135d27c77ca465)
> (cherry picked from commit 2d518aec4c781316092be65893b47922c8f71b67)
> ---
>  configure  |   1 +
>  libavfilter/Makefile   |   1 +
>  libavfilter/allfilters.c   |   1 +
>  libavfilter/version.h  |   2 +-
 cut
> +AVFilter ff_vf_deinterlace_vaapi = {
> +.name   = "deinterlace_vaapi",
> +.description= NULL_IF_CONFIG_SMALL("Deinterlacing of VAAPI 
> surfaces"),
> +.priv_size  = sizeof(DeintVAAPIContext),
> +.init   = _vaapi_init,
> +.uninit = _vaapi_uninit,
> +.query_formats  = _vaapi_query_formats,
> +.inputs = deint_vaapi_inputs,
> +.outputs= deint_vaapi_outputs,
> +.priv_class = _vaapi_class,
> +};
> 

Tested and verified in the KBL, it's working well 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/wrapped_avframe: allocate a buffer with padding

2017-02-22 Thread Marton Balint


On Wed, 22 Feb 2017, wm4 wrote:


>
> Patch looks good, and I like it better than checking the codec ID. 


Ok, will apply soon.


OK


Thanks, pushed.

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


Re: [FFmpeg-devel] [PATCH] avcodec/h264_ps: Check chroma_qp_index_offset

2017-02-22 Thread Michael Niedermayer
On Wed, Feb 22, 2017 at 07:40:24PM +0100, Paul B Mahol wrote:
> On 2/22/17, Michael Niedermayer  wrote:
> > On Wed, Feb 22, 2017 at 04:41:43PM +0100, Paul B Mahol wrote:
> >> On 2/22/17, Michael Niedermayer  wrote:
> >> > On Wed, Feb 22, 2017 at 02:29:00PM +0100, Paul B Mahol wrote:
> >> >> On 2/22/17, Michael Niedermayer  wrote:
> >> >> > Fixes: 647/clusterfuzz-testcase-5195745823031296
> >> >> >
> >> >> > Found-by: continuous fuzzing process
> >> >> > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> >> >> > Signed-off-by: Michael Niedermayer 
> >> >> > ---
> >> >> >  libavcodec/h264_ps.c | 11 +++
> >> >> >  1 file changed, 11 insertions(+)
> >> >> >
> >> >> > diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
> >> >> > index 8090178395..f4a4a01fbe 100644
> >> >> > --- a/libavcodec/h264_ps.c
> >> >> > +++ b/libavcodec/h264_ps.c
> >> >> > @@ -828,6 +828,12 @@ int
> >> >> > ff_h264_decode_picture_parameter_set(GetBitContext
> >> >> > *gb, AVCodecContext *avct
> >> >> >  pps->init_qp  = get_se_golomb(gb) +
> >> >> > 26
> >> >> > +
> >> >> > qp_bd_offset;
> >> >> >  pps->init_qs  = get_se_golomb(gb) +
> >> >> > 26
> >> >> > +
> >> >> > qp_bd_offset;
> >> >> >  pps->chroma_qp_index_offset[0]= get_se_golomb(gb);
> >> >> > +if (pps->chroma_qp_index_offset[0] < -12 ||
> >> >> > pps->chroma_qp_index_offset[0] > 12) {
> >> >> > +av_log(avctx, AV_LOG_ERROR, "chroma_qp_index_offset[0] %d
> >> >> > is
> >> >>
> >> >> This is nonsense. Please remove.
> >> >
> >> > Id like to keep the error messages or id like to have someone else
> >> > take over h264 maintaince in ffmpeg.
> >>
> >> Than why you are posting patches at all, if you do not want to listen
> >> to reviews.
> >
> > ive posted a patchset with ff_elog() instead
> >
> > do people prefer that ?
> >
> > [...]
> 
> You could right now start adding such messages at every error path.

ill push my patch without the error messages, i think i failed to
realize how much the error messages annoy you.

[...]
-- 
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] avdevice/decklink: Remove pthread dependency

2017-02-22 Thread Kyle Schwarz
On Wed, Feb 22, 2017 at 6:55 PM, Marton Balint  wrote:
>
> On Wed, 22 Feb 2017, Kyle Schwarz wrote:
>
>> DeckLink depends on pthread, and is silently disabled if pthread is
>> missing.
>>
>> Also fixes w32pthreads to support C++.
>
>
> You should split this into two patches, one the w32pthreads C++ support,
> other the decklink patch.

Would it be best to resubmit as two new threads for both, or simply
split and reply to this thread?

> Also, I checked the decklink part, and I am a bit confused. I don't see how
> you ensure that ctx->frames_buffer number of frames are scheduled. Also, are
> you sure you use the condition/mutexes properly? Your code does not even
> contains a pthread_mutex_lock call, that seems odd.
>
> What I would expect is to protect the scheduled frame counter with a mutex,
> and do a cond_signal in the scheduled frame completed callback. Or do you
> have something else in mind?

I'm not terribly familiar with mutex and pthread, so you're probably right.

I'll look into your suggestions and come up with a revision.

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


Re: [FFmpeg-devel] [PATCH 0/1] Add ETC1 encoder/decoder

2017-02-22 Thread Carl Eugen Hoyos
2017-02-22 18:38 GMT+01:00 Devin Heitmueller :
> This patch adds support for encoding and decoding the Ericsson Texture
> Compression 1 (ETC1) format.  This includes support for the PKM file
> format.
>
> Note the actual codec uses Google's ETC1 implementation from Android

> (Apache 2 licensed).

Then you at least have to make sure that the code only gets compiled
if both --enable-version3 and --enable-gpl were provided for configure.

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


Re: [FFmpeg-devel] [PATCH] avdevice/decklink: Remove pthread dependency

2017-02-22 Thread Marton Balint


On Wed, 22 Feb 2017, Kyle Schwarz wrote:


DeckLink depends on pthread, and is silently disabled if pthread is missing.

Also fixes w32pthreads to support C++.


You should split this into two patches, one the w32pthreads C++ support, 
other the decklink patch.


Also, I checked the decklink part, and I am a bit confused. I don't see 
how you ensure that ctx->frames_buffer number of frames are scheduled. 
Also, are you sure you use the condition/mutexes properly? Your code does 
not even contains a pthread_mutex_lock call, that seems odd.


What I would expect is to protect the scheduled frame counter with a 
mutex, and do a cond_signal in the scheduled frame completed callback. Or 
do you have something else in mind?


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


Re: [FFmpeg-devel] [PATCH] avcodec/dnxhddec: fix decoding of DNxHR HQX 10-bit

2017-02-22 Thread Carl Eugen Hoyos
2017-02-22 14:51 GMT+01:00 Paul B Mahol :
> On 2/22/17, Paul B Mahol  wrote:
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/dnxhddec.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
>> index 70ce264..cdbc0bc 100644
>> --- a/libavcodec/dnxhddec.c
>> +++ b/libavcodec/dnxhddec.c
>> @@ -435,7 +435,7 @@ static int dnxhd_decode_dct_block_8(const DNXHDContext
>> *ctx,
>>  static int dnxhd_decode_dct_block_10(const DNXHDContext *ctx,
>>   RowContext *row, int n)
>>  {
>> -return dnxhd_decode_dct_block(ctx, row, n, 6, 8, 4, 0);
>> +return dnxhd_decode_dct_block(ctx, row, n, 6, 32, 6, 0);
>>  }
>>
>>  static int dnxhd_decode_dct_block_10_444(const DNXHDContext *ctx,
>> --
>> 2.9.3
>>
>>
>
> File can be found here:
> https://drive.google.com/open?id=0B1hdyiz226iBV1llcDl3LW80U2c

The file does not decode here with your patch applied:
$ md5sum test.mov
25e45b380250bb76296f623fee9d43f1  test.mov

$ ffmpeg -i test.mov -f null -
ffmpeg version N-83619-g6a22d24 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl --enable-libx265
  libavutil  55. 47.100 / 55. 47.100
  libavcodec 57. 81.100 / 57. 81.100
  libavformat57. 66.102 / 57. 66.102
  libavdevice57.  2.100 / 57.  2.100
  libavfilter 6. 73.100 /  6. 73.100
  libswscale  4.  3.101 /  4.  3.101
  libswresample   2.  4.100 /  2.  4.100
  libpostproc54.  2.100 / 54.  2.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test.mov':
  Metadata:
major_brand : qt
minor_version   : 512
compatible_brands: qt
encoder : Lavf57.59.100
make: Atomos
make-eng: Atomos
  Duration: 00:00:00.17, start: 0.00, bitrate: 697811 kb/s
Stream #0:0(eng): Video: dnxhd (DNXHR HQX) (AVdh / 0x68645641),
yuv422p10le(tv, bt709/unknown/unknown), 3840x2160, 698439 kb/s, SAR
1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 24k tbn, 24k tbc (default)
Metadata:
  handler_name: DataHandler
  encoder : Avid DNxHR Codec
  timecode: 00:00:00:00
Stream #0:1(eng): Data: none (tmcd / 0x64636D74), 0 kb/s
Metadata:
  handler_name: DataHandler
  timecode: 00:00:00:00
Output #0, null, to 'pipe:':
  Metadata:
major_brand : qt
minor_version   : 512
compatible_brands: qt
make-eng: Atomos
make: Atomos
encoder : Lavf57.66.102
Stream #0:0(eng): Video: wrapped_avframe, yuv422p10le, 3840x2160
[SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 23.98 fps, 23.98 tbn, 23.98 tbc
(default)
Metadata:
  handler_name: DataHandler
  timecode: 00:00:00:00
  encoder : Lavc57.81.100 wrapped_avframe
Stream mapping:
  Stream #0:0 -> #0:0 (dnxhd (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
frame=0 fps=0.0 q=0.0 Lsize=N/A time=00:00:00.00 bitrate=N/A speed=   0x
video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: unknown
Output file is empty, nothing was encoded (check -ss / -t / -frames
parameters if used)

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


Re: [FFmpeg-devel] [PATCH] avdevice/decklink: Remove pthread dependency

2017-02-22 Thread Kyle Schwarz
Indeed, an unintended change. 644 is preferred.

On Wed, Feb 22, 2017 at 6:26 PM, Ricardo Constantino 
wrote:

> On 22 February 2017 at 22:55, Kyle Schwarz  wrote:
>
> > DeckLink depends on pthread, and is silently disabled if pthread is
> > missing.
> >
> > Also fixes w32pthreads to support C++.
> > ---
> >  compat/w32pthreads.h| 31 +++
> >  configure   |  4 ++--
> >  libavdevice/decklink_common.cpp |  3 ---
> >  libavdevice/decklink_common.h   |  4 +++-
> >  libavdevice/decklink_dec.cpp|  3 ---
> >  libavdevice/decklink_enc.cpp| 14 ++
> >  6 files changed, 30 insertions(+), 29 deletions(-)
> >  mode change 100644 => 100755 compat/w32pthreads.h
> >  mode change 100644 => 100755 libavdevice/decklink_common.cpp
> >  mode change 100644 => 100755 libavdevice/decklink_common.h
> >  mode change 100644 => 100755 libavdevice/decklink_dec.cpp
> >  mode change 100644 => 100755 libavdevice/decklink_enc.cpp
> >
> >
> These modes are probably unintended?
> ___
> 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] avdevice/decklink: Remove pthread dependency

2017-02-22 Thread Carl Eugen Hoyos
2017-02-22 23:55 GMT+01:00 Kyle Schwarz :
> DeckLink depends on pthread, and is silently disabled if pthread is missing.

> Also fixes w32pthreads to support C++.

Please make this a separate patch.

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


[FFmpeg-devel] [PATCH]lavc/libx265: Add gray10 and gray12 encoding support

2017-02-22 Thread Carl Eugen Hoyos
Hi!

Attached patch adds gray10 and gray12 native endian encoding support 
to libx265.

Please comment, Carl Eugen
From f3ce6a1bfc6a5d3201541d51fc4547b1b0b555f8 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Thu, 23 Feb 2017 00:28:22 +0100
Subject: [PATCH] lavc/libx265: Add gray10 and gray12 encoding support.

---
 libavcodec/libx265.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index f9b287e..5ca937a 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -167,6 +167,8 @@ static av_cold int libx265_encode_init(AVCodecContext 
*avctx)
 ctx->params->internalCsp = X265_CSP_I444;
 break;
 case AV_PIX_FMT_GRAY8:
+case AV_PIX_FMT_GRAY10:
+case AV_PIX_FMT_GRAY12:
 if (ctx->api->api_build_number < 85) {
 av_log(avctx, AV_LOG_ERROR,
"libx265 version is %d, must be at least 85 for gray 
encoding.\n",
@@ -349,6 +351,7 @@ static const enum AVPixelFormat x265_csp_ten[] = {
 AV_PIX_FMT_YUV422P10,
 AV_PIX_FMT_YUV444P10,
 AV_PIX_FMT_GBRP10,
+AV_PIX_FMT_GRAY10,
 AV_PIX_FMT_GRAY8,
 AV_PIX_FMT_NONE
 };
@@ -366,6 +369,8 @@ static const enum AVPixelFormat x265_csp_twelve[] = {
 AV_PIX_FMT_YUV422P12,
 AV_PIX_FMT_YUV444P12,
 AV_PIX_FMT_GBRP12,
+AV_PIX_FMT_GRAY12,
+AV_PIX_FMT_GRAY10,
 AV_PIX_FMT_GRAY8,
 AV_PIX_FMT_NONE
 };
-- 
1.7.10.4

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


Re: [FFmpeg-devel] [PATCH] avdevice/decklink: Remove pthread dependency

2017-02-22 Thread Ricardo Constantino
On 22 February 2017 at 22:55, Kyle Schwarz  wrote:

> DeckLink depends on pthread, and is silently disabled if pthread is
> missing.
>
> Also fixes w32pthreads to support C++.
> ---
>  compat/w32pthreads.h| 31 +++
>  configure   |  4 ++--
>  libavdevice/decklink_common.cpp |  3 ---
>  libavdevice/decklink_common.h   |  4 +++-
>  libavdevice/decklink_dec.cpp|  3 ---
>  libavdevice/decklink_enc.cpp| 14 ++
>  6 files changed, 30 insertions(+), 29 deletions(-)
>  mode change 100644 => 100755 compat/w32pthreads.h
>  mode change 100644 => 100755 libavdevice/decklink_common.cpp
>  mode change 100644 => 100755 libavdevice/decklink_common.h
>  mode change 100644 => 100755 libavdevice/decklink_dec.cpp
>  mode change 100644 => 100755 libavdevice/decklink_enc.cpp
>
>
These modes are probably unintended?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avdevice/decklink: Remove pthread dependency

2017-02-22 Thread Kyle Schwarz
DeckLink depends on pthread, and is silently disabled if pthread is missing.

Also fixes w32pthreads to support C++.
---
 compat/w32pthreads.h| 31 +++
 configure   |  4 ++--
 libavdevice/decklink_common.cpp |  3 ---
 libavdevice/decklink_common.h   |  4 +++-
 libavdevice/decklink_dec.cpp|  3 ---
 libavdevice/decklink_enc.cpp| 14 ++
 6 files changed, 30 insertions(+), 29 deletions(-)
 mode change 100644 => 100755 compat/w32pthreads.h
 mode change 100644 => 100755 libavdevice/decklink_common.cpp
 mode change 100644 => 100755 libavdevice/decklink_common.h
 mode change 100644 => 100755 libavdevice/decklink_dec.cpp
 mode change 100644 => 100755 libavdevice/decklink_enc.cpp

diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
old mode 100644
new mode 100755
index 4ac2a99..45c565a
--- a/compat/w32pthreads.h
+++ b/compat/w32pthreads.h
@@ -77,7 +77,7 @@ typedef struct pthread_cond_t {
 
 static av_unused unsigned __stdcall attribute_align_arg 
win32thread_worker(void *arg)
 {
-pthread_t *h = arg;
+pthread_t *h = (pthread_t*)arg;
 h->ret = h->func(h->arg);
 return 0;
 }
@@ -270,7 +270,7 @@ static av_unused int pthread_cond_init(pthread_cond_t 
*cond, const void *unused_
 }
 
 /* non native condition variables */
-win32_cond = av_mallocz(sizeof(win32_cond_t));
+win32_cond = (win32_cond_t*)av_mallocz(sizeof(win32_cond_t));
 if (!win32_cond)
 return ENOMEM;
 cond->Ptr = win32_cond;
@@ -288,7 +288,7 @@ static av_unused int pthread_cond_init(pthread_cond_t 
*cond, const void *unused_
 
 static av_unused int pthread_cond_destroy(pthread_cond_t *cond)
 {
-win32_cond_t *win32_cond = cond->Ptr;
+win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr;
 /* native condition variables do not destroy */
 if (cond_init)
 return 0;
@@ -305,7 +305,7 @@ static av_unused int pthread_cond_destroy(pthread_cond_t 
*cond)
 
 static av_unused int pthread_cond_broadcast(pthread_cond_t *cond)
 {
-win32_cond_t *win32_cond = cond->Ptr;
+win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr;
 int have_waiter;
 
 if (cond_broadcast) {
@@ -337,7 +337,7 @@ static av_unused int pthread_cond_broadcast(pthread_cond_t 
*cond)
 
 static av_unused int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t 
*mutex)
 {
-win32_cond_t *win32_cond = cond->Ptr;
+win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr;
 int last_waiter;
 if (cond_wait) {
 cond_wait(cond, mutex, INFINITE);
@@ -369,7 +369,7 @@ static av_unused int pthread_cond_wait(pthread_cond_t 
*cond, pthread_mutex_t *mu
 
 static av_unused int pthread_cond_signal(pthread_cond_t *cond)
 {
-win32_cond_t *win32_cond = cond->Ptr;
+win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr;
 int have_waiter;
 if (cond_signal) {
 cond_signal(cond);
@@ -397,20 +397,27 @@ static av_unused int pthread_cond_signal(pthread_cond_t 
*cond)
 static av_unused void w32thread_init(void)
 {
 #if _WIN32_WINNT < 0x0600
+typedef void (*init_cond_var)(pthread_cond_t*);
+typedef void (*wake_all_cond_var)(pthread_cond_t*);
+typedef void (*wake_cond_var)(pthread_cond_t*);
+typedef BOOL (*sleep_cond_var)(pthread_cond_t*, pthread_mutex_t*, DWORD);
+typedef BOOL (*init_once_begin_init)(pthread_once_t*, DWORD, BOOL*, 
void**);
+typedef BOOL (*init_once_complete)(pthread_once_t*, DWORD, void*);
+
 HANDLE kernel_dll = GetModuleHandle(TEXT("kernel32.dll"));
 /* if one is available, then they should all be available */
 cond_init  =
-(void*)GetProcAddress(kernel_dll, "InitializeConditionVariable");
+(init_cond_var)GetProcAddress((HMODULE)kernel_dll, 
"InitializeConditionVariable");
 cond_broadcast =
-(void*)GetProcAddress(kernel_dll, "WakeAllConditionVariable");
+(wake_all_cond_var)GetProcAddress((HMODULE)kernel_dll, 
"WakeAllConditionVariable");
 cond_signal=
-(void*)GetProcAddress(kernel_dll, "WakeConditionVariable");
+(wake_cond_var)GetProcAddress((HMODULE)kernel_dll, 
"WakeConditionVariable");
 cond_wait  =
-(void*)GetProcAddress(kernel_dll, "SleepConditionVariableCS");
+(sleep_cond_var)GetProcAddress((HMODULE)kernel_dll, 
"SleepConditionVariableCS");
 initonce_begin =
-(void*)GetProcAddress(kernel_dll, "InitOnceBeginInitialize");
+(init_once_begin_init)GetProcAddress((HMODULE)kernel_dll, 
"InitOnceBeginInitialize");
 initonce_complete =
-(void*)GetProcAddress(kernel_dll, "InitOnceComplete");
+(init_once_complete)GetProcAddress((HMODULE)kernel_dll, 
"InitOnceComplete");
 #endif
 
 }
diff --git a/configure b/configure
index 6431313..ab9e005 100755
--- a/configure
+++ b/configure
@@ -2977,9 +2977,9 @@ avfoundation_indev_extralibs="-framework CoreVideo 
-framework Foundation -framew
 avfoundation_indev_select="avfoundation"
 

Re: [FFmpeg-devel] [PATCH] configure/rtmpdh: Fix OpenSSL 1.1.0 support

2017-02-22 Thread Stefan _
The rtmpdh patch was kinda (completly) broken, fixed patch is attached.

Concerning LibreSSL:
They use OPENSSL_VERSION_NUMBER = 0x2050200fL which breaks the other 
openssl code in tls_openssl.c anyway,
so LibreSSL support should probably be worried about in a different patch.
From 0edf1d179824fa6400031c6d05b3f464f01abf36 Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Wed, 22 Feb 2017 15:38:16 +0100
Subject: [PATCH 2/2] rtmpdh: Stop using OpenSSL-provided DH functions to
 support 1.1.0

DH (struct dh_st) was made private in the 1.1 series, instead
DH is now done the same way as with gcrypt / libgmp.
---
 libavformat/rtmpdh.c | 94 
 libavformat/rtmpdh.h | 13 +++-
 2 files changed, 49 insertions(+), 58 deletions(-)

diff --git a/libavformat/rtmpdh.c b/libavformat/rtmpdh.c
index 1876fd44f9..1ec1286d23 100644
--- a/libavformat/rtmpdh.c
+++ b/libavformat/rtmpdh.c
@@ -54,7 +54,6 @@
 "F71C35FDAD44CFD2D74F9208BE258FF324943328F67329C0" \
 ""
 
-#if CONFIG_GMP || CONFIG_GCRYPT
 #if CONFIG_GMP
 #define bn_new(bn)  \
 do {\
@@ -93,7 +92,11 @@
 else\
 ret = 1;\
 } while (0)
-#define bn_modexp(bn, y, q, p)  mpz_powm(bn, y, q, p)
+#define bn_modexp(bn, y, q, p, ret) \
+do {\
+mpz_powm(bn, y, q, p);  \
+ret = 1;\
+} while(0)
 #define bn_random(bn, num_bits)   \
 do {  \
 int bits = num_bits;  \
@@ -125,8 +128,34 @@
 #define bn_bn2bin(bn, buf, len) gcry_mpi_print(GCRYMPI_FMT_USG, buf, len, NULL, bn)
 #define bn_bin2bn(bn, buf, len) gcry_mpi_scan(, GCRYMPI_FMT_USG, buf, len, NULL)
 #define bn_hex2bn(bn, buf, ret) ret = (gcry_mpi_scan(, GCRYMPI_FMT_HEX, buf, 0, 0) == 0)
-#define bn_modexp(bn, y, q, p)  gcry_mpi_powm(bn, y, q, p)
+#define bn_modexp(bn, y, q, p, ret) \
+do {\
+cry_mpi_powm(bn, y, q, p);  \
+ret = 1;\
+} while (0)
 #define bn_random(bn, num_bits) gcry_mpi_randomize(bn, num_bits, GCRY_WEAK_RANDOM)
+#elif CONFIG_OPENSSL
+#define bn_new(bn)  bn = BN_new()
+#define bn_free(bn) BN_free(bn)
+#define bn_set_word(bn, w)  BN_set_word(bn, w)
+#define bn_cmp(a, b)BN_cmp(a, b)
+#define bn_copy(to, from)   BN_copy(to, from)
+#define bn_sub_word(bn, w)  BN_sub_word(bn, w)
+#define bn_cmp_1(bn)BN_cmp(bn, BN_value_one())
+#define bn_num_bytes(bn)BN_num_bytes(bn)
+#define bn_bn2bin(bn, buf, len) BN_bn2bin(bn, buf)
+#define bn_bin2bn(bn, buf, len) bn = BN_bin2bn(buf, len, 0)
+#define bn_hex2bn(bn, buf, ret) ret = BN_hex2bn(, buf)
+#define bn_modexp(bn, y, q, p, ret)  \
+do { \
+BN_CTX *ctx = BN_CTX_new();  \
+if (!ctx)\
+ret = 0; \
+else \
+ret = BN_mod_exp(bn, y, q, p, ctx);  \
+BN_CTX_free(ctx);\
+} while (0)
+#define bn_random(bn, num_bits)BN_rand(bn, num_bits, 0, 0)
 #endif
 
 #define MAX_BYTES 18000
@@ -135,7 +164,7 @@
 
 static FFBigNum dh_generate_key(FF_DH *dh)
 {
-int num_bytes;
+int num_bytes, ret;
 
 num_bytes = bn_num_bytes(dh->p) - 1;
 if (num_bytes <= 0 || num_bytes > MAX_BYTES)
@@ -152,7 +181,9 @@ static FFBigNum dh_generate_key(FF_DH *dh)
 return NULL;
 }
 
-bn_modexp(dh->pub_key, dh->g, dh->priv_key, dh->p);
+bn_modexp(dh->pub_key, dh->g, dh->priv_key, dh->p, ret);
+if (!ret)
+return NULL;
 
 return dh->pub_key;
 }
@@ -161,12 +192,15 @@ static int dh_compute_key(FF_DH *dh, FFBigNum pub_key_bn,
   uint32_t secret_key_len, uint8_t *secret_key)
 {
 FFBigNum k;
+int ret;
 
 bn_new(k);
 if (!k)
 return -1;
 
-bn_modexp(k, pub_key_bn, dh->priv_key, dh->p);
+bn_modexp(k, pub_key_bn, dh->priv_key, dh->p, ret);
+if (!ret)
+return -1;
 bn_bn2bin(k, secret_key, secret_key_len);
 bn_free(k);
 
@@ -184,53 +218,11 @@ void ff_dh_free(FF_DH *dh)
 bn_free(dh->priv_key);
 av_free(dh);
 }
-#elif CONFIG_OPENSSL
-#define bn_new(bn)  bn = BN_new()
-#define bn_free(bn) BN_free(bn)
-#define bn_set_word(bn, w)  BN_set_word(bn, w)
-#define bn_cmp(a, b)BN_cmp(a, b)
-#define bn_copy(to, from)   BN_copy(to, from)
-#define bn_sub_word(bn, w)  BN_sub_word(bn, w)
-#define bn_cmp_1(bn)BN_cmp(bn, BN_value_one())
-#define bn_num_bytes(bn)

[FFmpeg-devel] [PATCH] mjpegenc: make optimal huffman coding the default

2017-02-22 Thread Rostislav Pehlivanov
Its been extensively tested and it gives gain for practically free, so
make it enabled by default.

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/mjpegenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
index cc917edb7f..03c3d0ab13 100644
--- a/libavcodec/mjpegenc.c
+++ b/libavcodec/mjpegenc.c
@@ -444,7 +444,7 @@ FF_MPV_COMMON_OPTS
 { "left",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 1 }, INT_MIN, INT_MAX, 
VE, "pred" },
 { "plane",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 2 }, INT_MIN, INT_MAX, 
VE, "pred" },
 { "median", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 3 }, INT_MIN, INT_MAX, 
VE, "pred" },
-{ "huffman", "Huffman table strategy", OFFSET(huffman), AV_OPT_TYPE_INT, { 
.i64 = HUFFMAN_TABLE_DEFAULT }, 0, NB_HUFFMAN_TABLE_OPTION - 1, VE, "huffman" },
+{ "huffman", "Huffman table strategy", OFFSET(huffman), AV_OPT_TYPE_INT, { 
.i64 = HUFFMAN_TABLE_OPTIMAL }, 0, NB_HUFFMAN_TABLE_OPTION - 1, VE, "huffman" },
 { "default", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = HUFFMAN_TABLE_DEFAULT }, 
INT_MIN, INT_MAX, VE, "huffman" },
 { "optimal", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = HUFFMAN_TABLE_OPTIMAL }, 
INT_MIN, INT_MAX, VE, "huffman" },
 { NULL},
-- 
2.12.0.rc1.440.g5b76565f74

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


[FFmpeg-devel] [PATCH 4/4] avdevice/decklink_dec: remove AVFMT_RAWPICTURE

2017-02-22 Thread Marton Balint
It has no effect for input devices.

Signed-off-by: Marton Balint 
---
 libavdevice/decklink_dec_c.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavdevice/decklink_dec_c.c b/libavdevice/decklink_dec_c.c
index 543d16b..31818d2 100644
--- a/libavdevice/decklink_dec_c.c
+++ b/libavdevice/decklink_dec_c.c
@@ -77,7 +77,7 @@ static const AVClass decklink_demuxer_class = {
 AVInputFormat ff_decklink_demuxer = {
 .name   = "decklink",
 .long_name  = NULL_IF_CONFIG_SMALL("Blackmagic DeckLink input"),
-.flags  = AVFMT_NOFILE | AVFMT_RAWPICTURE,
+.flags  = AVFMT_NOFILE,
 .priv_class = _demuxer_class,
 .priv_data_size = sizeof(struct decklink_cctx),
 .read_header   = ff_decklink_read_header,
-- 
2.10.2

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


Re: [FFmpeg-devel] [PATCH v1 1/2] codec: vrawdepay: add decoder for RFC4175

2017-02-22 Thread Kieran Kunhya
On Wed, 22 Feb 2017, 21:39 Rostislav Pehlivanov, 
wrote:

> On 22 February 2017 at 20:18, Damien Riegel <
> damien.rie...@savoirfairelinux.com> wrote:
>
> > On Fri, Feb 17, 2017 at 03:01:05PM -0500, Damien Riegel wrote:
> > > Hi,
> > >
> > > On Thu, Feb 16, 2017 at 06:19:00PM +, Rostislav Pehlivanov wrote:
> > > > >
> > > > > No, do this in libavfilter and do not introduce another useless
> > pseudo
> > > > > codec
> > > > >
> > > >
> > > > *libavformat, sorry
> > >
> > > The advantage of using a pseudo codec just to depack the stream is that
> > > the input and the codec are in separate threads in ffmpeg, so it can
> > > handle a heavier workload.
> >
> > Please find attached a v2, with the implementation in libavformat. Note
> > that I don't want to send it as a patch of its own because the
> > performance issue is not addressed.
> >
> > Basically, our test case is a raw input stream YUV 4:2:2 10 bits 1080p
> > at 60fps. With the pseudo-codec, we are able to transcode it to h264 and
> > dump it to a file. With unpacking done in the libavformat, the input
> > thread gets too busy and can't stand the load.
> >
> > In the implementation you made [1] unpacking was done in libavcodec, so
> > why is it not an acceptable solution for mainline?
> >
> >
> I now think it was ok to have a custom codec format because V210 is
> implemented in such a way in lavc. So I think the first version of your
> patch was better. You just didn't bother to list a valid reason besides
> "offload it to another thread" and I didn't think of V210 at the time.
> libavformat has no support for assembly so putting the unpacking there
> would be slower too. I suggest posting a v3 of the patch which is like v1
> (but please rename the codec name to something better) and which uses the
> assembly for unpacking from the repository you linked.
>
> PS: In that repo its _not_ done in lavc and it was never done in lavc, the
> point was to use lavc's assembly framework so that if you linked to it and
> used the private functions you'd be able to use them _outside_ of lavc.
> This was because upipe, which is something made to handle the stinkiest
> kind of crap broadcasting people invent because ffmpeg couldn't (and it
> absolutely doesn't have to), didn't have any support for assembly.
> Eventually support for that was added and everything from the repo plus
> more has been implemented there.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Further to what Rostislav said, please mark this as experimental. You're
not going to be able to do more than one stream for architectural reasons
and I don't want people blaming FFmpeg.

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


[FFmpeg-devel] [PATCH 3/4] avdevice/decklink_enc: convert AVFMT_RAWPICTURE to AV_CODEC_ID_WRAPPED_AVFRAME

2017-02-22 Thread Marton Balint
Signed-off-by: Marton Balint 
---
 libavdevice/decklink_enc.cpp | 78 +---
 libavdevice/decklink_enc_c.c |  4 +--
 libavdevice/version.h|  4 +--
 3 files changed, 42 insertions(+), 44 deletions(-)

diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
index 8fb6a9c..8892d19 100644
--- a/libavdevice/decklink_enc.cpp
+++ b/libavdevice/decklink_enc.cpp
@@ -28,6 +28,7 @@ extern "C" {
 #include "libavformat/avformat.h"
 #include "libavformat/internal.h"
 #include "libavutil/imgutils.h"
+#include "libavutil/atomic.h"
 }
 
 #include "decklink_common.h"
@@ -38,33 +39,43 @@ extern "C" {
 class decklink_frame : public IDeckLinkVideoFrame
 {
 public:
-decklink_frame(struct decklink_ctx *ctx, AVFrame *avframe, long width,
-   long height, void *buffer) :
-   _ctx(ctx), _avframe(avframe), _width(width),
-   _height(height), _buffer(buffer), _refs(0) { }
-
-virtual long   STDMETHODCALLTYPE GetWidth  (void)  { 
return _width; }
-virtual long   STDMETHODCALLTYPE GetHeight (void)  { 
return _height; }
-virtual long   STDMETHODCALLTYPE GetRowBytes   (void)  { 
return _width<<1; }
+decklink_frame(struct decklink_ctx *ctx, AVFrame *avframe) :
+   _ctx(ctx), _avframe(avframe),  _refs(1) { }
+
+virtual long   STDMETHODCALLTYPE GetWidth  (void)  { 
return _avframe->width; }
+virtual long   STDMETHODCALLTYPE GetHeight (void)  { 
return _avframe->height; }
+virtual long   STDMETHODCALLTYPE GetRowBytes   (void)  { 
return _avframe->linesize[0] < 0 ? -_avframe->linesize[0] : 
_avframe->linesize[0]; }
 virtual BMDPixelFormat STDMETHODCALLTYPE GetPixelFormat(void)  { 
return bmdFormat8BitYUV; }
-virtual BMDFrameFlags  STDMETHODCALLTYPE GetFlags  (void)  { 
return bmdVideoOutputFlagDefault; }
-virtual HRESULTSTDMETHODCALLTYPE GetBytes  (void **buffer) { 
*buffer = _buffer; return S_OK; }
+virtual BMDFrameFlags  STDMETHODCALLTYPE GetFlags  (void)  { 
return _avframe->linesize[0] < 0 ? bmdFrameFlagFlipVertical : 
bmdFrameFlagDefault; }
+virtual HRESULTSTDMETHODCALLTYPE GetBytes  (void **buffer)
+{
+if (_avframe->linesize[0] < 0)
+*buffer = (void *)(_avframe->data[0] + _avframe->linesize[0] * 
(_avframe->height - 1));
+else
+*buffer = (void *)(_avframe->data[0]);
+return S_OK;
+}
 
 virtual HRESULT STDMETHODCALLTYPE GetTimecode (BMDTimecodeFormat 
format, IDeckLinkTimecode **timecode) { return S_FALSE; }
 virtual HRESULT STDMETHODCALLTYPE 
GetAncillaryData(IDeckLinkVideoFrameAncillary **ancillary)   { 
return S_FALSE; }
 
 virtual HRESULT STDMETHODCALLTYPE QueryInterface(REFIID iid, LPVOID *ppv) 
{ return E_NOINTERFACE; }
-virtual ULONG   STDMETHODCALLTYPE AddRef(void)
{ return ++_refs; }
-virtual ULONG   STDMETHODCALLTYPE Release(void)   
{ if (!--_refs) {delete this; return 0;} return _refs; }
+virtual ULONG   STDMETHODCALLTYPE AddRef(void)
{ return avpriv_atomic_int_add_and_fetch(&_refs, 1); }
+virtual ULONG   STDMETHODCALLTYPE Release(void)
+{
+int ret = avpriv_atomic_int_add_and_fetch(&_refs, -1);
+if (!ret) {
+av_frame_free(&_avframe);
+delete this;
+}
+return ret;
+}
 
 struct decklink_ctx *_ctx;
 AVFrame *_avframe;
 
 private:
-long  _width;
-long  _height;
-void *_buffer;
-int   _refs;
+volatile int   _refs;
 };
 
 class decklink_output_callback : public IDeckLinkVideoOutputCallback
@@ -76,7 +87,7 @@ public:
 struct decklink_ctx *ctx = frame->_ctx;
 AVFrame *avframe = frame->_avframe;
 
-av_frame_free();
+av_frame_unref(avframe);
 
 sem_post(>semaphore);
 
@@ -209,41 +220,27 @@ static int decklink_write_video_packet(AVFormatContext 
*avctx, AVPacket *pkt)
 {
 struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
 struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
-AVPicture *avpicture = (AVPicture *) pkt->data;
-AVFrame *avframe, *tmp;
+AVFrame *avframe, *tmp = (AVFrame *)pkt->data;
 decklink_frame *frame;
 buffercount_type buffered;
 HRESULT hr;
 
-/* HACK while av_uncoded_frame() isn't implemented */
-int ret;
-
-tmp = av_frame_alloc();
-if (!tmp)
-return AVERROR(ENOMEM);
-tmp->format = AV_PIX_FMT_UYVY422;
-tmp->width  = ctx->bmd_width;
-tmp->height = ctx->bmd_height;
-ret = av_frame_get_buffer(tmp, 32);
-if (ret < 0) {
-av_frame_free();
-return ret;
+if (tmp->format != AV_PIX_FMT_UYVY422 ||
+tmp->width  != ctx->bmd_width ||
+

[FFmpeg-devel] [PATCH 2/4] avdevice/decklink_enc: add support to specify field order

2017-02-22 Thread Marton Balint
Signed-off-by: Marton Balint 
---
 doc/outdevs.texi|  4 ++--
 libavdevice/decklink_common.cpp | 29 +++--
 libavdevice/decklink_common.h   |  2 +-
 libavdevice/decklink_enc.cpp|  4 ++--
 libavdevice/version.h   |  2 +-
 5 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/doc/outdevs.texi b/doc/outdevs.texi
index e68653f..df41cc8 100644
--- a/doc/outdevs.texi
+++ b/doc/outdevs.texi
@@ -131,8 +131,8 @@ and @code{--extra-ldflags}.
 On Windows, you need to run the IDL files through @command{widl}.
 
 DeckLink is very picky about the formats it supports. Pixel format is always
-uyvy422, framerate and video size must be determined for your device with
-@command{-list_formats 1}. Audio sample rate is always 48 kHz.
+uyvy422, framerate, field order and video size must be determined for your
+device with @command{-list_formats 1}. Audio sample rate is always 48 kHz.
 
 @subsection Options
 
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index a3bc58d..92b4545 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -130,9 +130,23 @@ static int decklink_select_input(AVFormatContext *avctx, 
BMDDeckLinkConfiguratio
 return 0;
 }
 
+static DECKLINK_BOOL field_order_eq(enum AVFieldOrder field_order, 
BMDFieldDominance bmd_field_order)
+{
+if (field_order == AV_FIELD_UNKNOWN)
+return true;
+if (field_order == AV_FIELD_TT && bmd_field_order == bmdUpperFieldFirst)
+return true;
+if (field_order == AV_FIELD_BB && bmd_field_order == bmdLowerFieldFirst)
+return true;
+if (field_order == AV_FIELD_PROGRESSIVE && (bmd_field_order == 
bmdProgressiveFrame || bmd_field_order == bmdProgressiveSegmentedFrame))
+return true;
+return false;
+}
+
 int ff_decklink_set_format(AVFormatContext *avctx,
int width, int height,
int tb_num, int tb_den,
+   enum AVFieldOrder field_order,
decklink_direction_t direction, int num)
 {
 struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
@@ -143,8 +157,8 @@ int ff_decklink_set_format(AVFormatContext *avctx,
 int i = 1;
 HRESULT res;
 
-av_log(avctx, AV_LOG_DEBUG, "Trying to find mode for frame size %dx%d, 
frame timing %d/%d, direction %d, mode number %d\n",
-width, height, tb_num, tb_den, direction, num);
+av_log(avctx, AV_LOG_DEBUG, "Trying to find mode for frame size %dx%d, 
frame timing %d/%d, field order %d, direction %d, mode number %d\n",
+width, height, tb_num, tb_den, field_order, direction, num);
 
 if (ctx->duplex_mode) {
 DECKLINK_BOOL duplex_supported = false;
@@ -187,18 +201,21 @@ int ff_decklink_set_format(AVFormatContext *avctx,
 BMDTimeValue bmd_tb_num, bmd_tb_den;
 int bmd_width  = mode->GetWidth();
 int bmd_height = mode->GetHeight();
+BMDFieldDominance bmd_field_dominance = mode->GetFieldDominance();
 
 mode->GetFrameRate(_tb_num, _tb_den);
 AVRational mode_tb = av_make_q(bmd_tb_num, bmd_tb_den);
 
-if ((bmd_width == width && bmd_height == height &&
-!av_cmp_q(mode_tb, target_tb)) || i == num) {
+if ((bmd_width == width &&
+ bmd_height == height &&
+ !av_cmp_q(mode_tb, target_tb) &&
+ field_order_eq(field_order, bmd_field_dominance)) || i == num) {
 ctx->bmd_mode   = mode->GetDisplayMode();
 ctx->bmd_width  = bmd_width;
 ctx->bmd_height = bmd_height;
 ctx->bmd_tb_den = bmd_tb_den;
 ctx->bmd_tb_num = bmd_tb_num;
-ctx->bmd_field_dominance = mode->GetFieldDominance();
+ctx->bmd_field_dominance = bmd_field_dominance;
 av_log(avctx, AV_LOG_INFO, "Found Decklink mode %d x %d with rate 
%.2f%s\n",
 bmd_width, bmd_height, 1/av_q2d(mode_tb),
 (ctx->bmd_field_dominance==bmdLowerFieldFirst || 
ctx->bmd_field_dominance==bmdUpperFieldFirst)?"(i)":"");
@@ -230,7 +247,7 @@ int ff_decklink_set_format(AVFormatContext *avctx,
 }
 
 int ff_decklink_set_format(AVFormatContext *avctx, decklink_direction_t 
direction, int num) {
-return ff_decklink_set_format(avctx, 0, 0, 0, 0, direction, num);
+return ff_decklink_set_format(avctx, 0, 0, 0, 0, AV_FIELD_UNKNOWN, 
direction, num);
 }
 
 int ff_decklink_list_devices(AVFormatContext *avctx)
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index bfa2b08..4753287 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -128,7 +128,7 @@ static const BMDVideoConnection 
decklink_video_connection_map[] = {
 };
 
 HRESULT ff_decklink_get_display_name(IDeckLink *This, const char 
**displayName);
-int ff_decklink_set_format(AVFormatContext *avctx, int width, int height, int 
tb_num, int 

[FFmpeg-devel] [PATCH 1/4] avdevice/decklink_enc: convert to codecpar

2017-02-22 Thread Marton Balint
Signed-off-by: Marton Balint 
---
 libavdevice/decklink_enc.cpp | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
index ad00224..944e9d3 100644
--- a/libavdevice/decklink_enc.cpp
+++ b/libavdevice/decklink_enc.cpp
@@ -92,20 +92,20 @@ static int decklink_setup_video(AVFormatContext *avctx, 
AVStream *st)
 {
 struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
 struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
-AVCodecContext *c = st->codec;
+AVCodecParameters *c = st->codecpar;
 
 if (ctx->video) {
 av_log(avctx, AV_LOG_ERROR, "Only one video stream is supported!\n");
 return -1;
 }
 
-if (c->pix_fmt != AV_PIX_FMT_UYVY422) {
+if (c->format != AV_PIX_FMT_UYVY422) {
 av_log(avctx, AV_LOG_ERROR, "Unsupported pixel format!"
" Only AV_PIX_FMT_UYVY422 is supported.\n");
 return -1;
 }
 if (ff_decklink_set_format(avctx, c->width, c->height,
-c->time_base.num, c->time_base.den)) {
+st->time_base.num, st->time_base.den)) {
 av_log(avctx, AV_LOG_ERROR, "Unsupported video size or framerate!"
" Check available formats with -list_formats 1.\n");
 return -1;
@@ -121,8 +121,8 @@ static int decklink_setup_video(AVFormatContext *avctx, 
AVStream *st)
 ctx->dlo->SetScheduledFrameCompletionCallback(ctx->output_callback);
 
 /* Start video semaphore. */
-ctx->frames_preroll = c->time_base.den * ctx->preroll;
-if (c->time_base.den > 1000)
+ctx->frames_preroll = st->time_base.den * ctx->preroll;
+if (st->time_base.den > 1000)
 ctx->frames_preroll /= 1000;
 
 /* Buffer twice as many frames as the preroll. */
@@ -131,7 +131,7 @@ static int decklink_setup_video(AVFormatContext *avctx, 
AVStream *st)
 sem_init(>semaphore, 0, ctx->frames_buffer);
 
 /* The device expects the framerate to be fixed. */
-avpriv_set_pts_info(st, 64, c->time_base.num, c->time_base.den);
+avpriv_set_pts_info(st, 64, st->time_base.num, st->time_base.den);
 
 ctx->video = 1;
 
@@ -142,7 +142,7 @@ static int decklink_setup_audio(AVFormatContext *avctx, 
AVStream *st)
 {
 struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
 struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
-AVCodecContext *c = st->codec;
+AVCodecParameters *c = st->codecpar;
 
 if (ctx->audio) {
 av_log(avctx, AV_LOG_ERROR, "Only one audio stream is supported!\n");
@@ -352,7 +352,7 @@ av_cold int ff_decklink_write_header(AVFormatContext *avctx)
 ret = AVERROR(EIO);
 for (n = 0; n < avctx->nb_streams; n++) {
 AVStream *st = avctx->streams[n];
-AVCodecContext *c = st->codec;
+AVCodecParameters *c = st->codecpar;
 if(c->codec_type == AVMEDIA_TYPE_AUDIO) {
 if (decklink_setup_audio(avctx, st))
 goto error;
@@ -380,9 +380,9 @@ int ff_decklink_write_packet(AVFormatContext *avctx, 
AVPacket *pkt)
 
 ctx->last_pts = FFMAX(ctx->last_pts, pkt->pts);
 
-if  (st->codec->codec_type == AVMEDIA_TYPE_VIDEO)
+if  (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO)
 return decklink_write_video_packet(avctx, pkt);
-else if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO)
+else if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO)
 return decklink_write_audio_packet(avctx, pkt);
 
 return AVERROR(EIO);
-- 
2.10.2

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


Re: [FFmpeg-devel] [PATCH] configure/rtmpdh: Fix OpenSSL 1.1.0 support

2017-02-22 Thread Ricardo Constantino
On 22 February 2017 at 15:17, Stefan _  wrote:

> 1) configure only looks for OPENSSL_init_ssl using pkg-config, this
> breaks in case pkg-config is not available (cross-compiling)
>
>
> 2) The rtmpdh code uses the DH struct from OpenSSL which was made
> private in the 1.1 series
>
>
Any idea if this works with LibreSSL? They use OPENSSL_VERSION_NUMBER >=
0x101fL
but don't necessarily support anything that OpenSSL >1.1.0 does.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avutil/tests/lfg.c: added proper normality test

2017-02-22 Thread Michael Niedermayer
oops forgot to reply to all, this one went only to thomas by mistake

On Tue, Feb 21, 2017 at 08:12:57PM -0800, Thomas Turner wrote:
> 
> 
> On 02/17/2017 02:15 PM, Michael Niedermayer wrote:
> > On Thu, Feb 16, 2017 at 08:29:38PM -0800, Thomas Turner wrote:
> >> The Chen-Shapiro(CS) test was used to test normality for
> >> Lagged Fibonacci PRNG.
> >>
> >> Normality Hypothesis Test:
> >>
> >> The null hypothesis formally tests if the population
> >> the sample represents is normally-distributed. For
> >> CS, when the normality hypothesis is True, the
> >> distribution of QH will have a mean close to 1.
> >>
> >> Information on CS can be found here:
> >>
> >> http://www.stata-journal.com/sjpdf.html?articlenum=st0264
> >> http://www.originlab.com/doc/Origin-Help/NormalityTest-Algorithm
> >>
> >> Signed-off-by: Thomas Turner 
> >> ---
> >>  libavutil/tests/lfg.c|  170 ++--
> >>  tests/fate/libavutil.mak |4 +
> >>  tests/ref/fate/lfg   | 1007 
> >> ++
> >>  3 files changed, 1157 insertions(+), 24 deletions(-)
> >>  create mode 100644 tests/ref/fate/lfg
> > 
> > works on x86_64 linux but fails on x86_32
> 
> What if we force gcc compiler to use IEEE 754 floating-point semantics...Will 
> adding the following gcc compilation flags to ffmpeg configuration allow the 
> test to pass? : -msse2 -mfpmath=sse

there is no gurantee that the hardware this runs on supports sse
nor that the compiler is gcc

C has a somewhat loose definition of floating point operations,
that allows C compilers to perform more optimizations and run on more
hardware. There isnt much that can be done about this, short of not
using floating point

But why does it not work with default options?
or is that unknown ?
did you succeed in reproduring the issue ?

[...]

-- 
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 v1 1/2] codec: vrawdepay: add decoder for RFC4175

2017-02-22 Thread Rostislav Pehlivanov
On 22 February 2017 at 20:18, Damien Riegel <
damien.rie...@savoirfairelinux.com> wrote:

> On Fri, Feb 17, 2017 at 03:01:05PM -0500, Damien Riegel wrote:
> > Hi,
> >
> > On Thu, Feb 16, 2017 at 06:19:00PM +, Rostislav Pehlivanov wrote:
> > > >
> > > > No, do this in libavfilter and do not introduce another useless
> pseudo
> > > > codec
> > > >
> > >
> > > *libavformat, sorry
> >
> > The advantage of using a pseudo codec just to depack the stream is that
> > the input and the codec are in separate threads in ffmpeg, so it can
> > handle a heavier workload.
>
> Please find attached a v2, with the implementation in libavformat. Note
> that I don't want to send it as a patch of its own because the
> performance issue is not addressed.
>
> Basically, our test case is a raw input stream YUV 4:2:2 10 bits 1080p
> at 60fps. With the pseudo-codec, we are able to transcode it to h264 and
> dump it to a file. With unpacking done in the libavformat, the input
> thread gets too busy and can't stand the load.
>
> In the implementation you made [1] unpacking was done in libavcodec, so
> why is it not an acceptable solution for mainline?
>
>
I now think it was ok to have a custom codec format because V210 is
implemented in such a way in lavc. So I think the first version of your
patch was better. You just didn't bother to list a valid reason besides
"offload it to another thread" and I didn't think of V210 at the time.
libavformat has no support for assembly so putting the unpacking there
would be slower too. I suggest posting a v3 of the patch which is like v1
(but please rename the codec name to something better) and which uses the
assembly for unpacking from the repository you linked.

PS: In that repo its _not_ done in lavc and it was never done in lavc, the
point was to use lavc's assembly framework so that if you linked to it and
used the private functions you'd be able to use them _outside_ of lavc.
This was because upipe, which is something made to handle the stinkiest
kind of crap broadcasting people invent because ffmpeg couldn't (and it
absolutely doesn't have to), didn't have any support for assembly.
Eventually support for that was added and everything from the repo plus
more has been implemented there.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/wrapped_avframe: allocate a buffer with padding

2017-02-22 Thread wm4
On Wed, 22 Feb 2017 21:00:31 +0100 (CET)
Marton Balint  wrote:

> On Wed, 22 Feb 2017, wm4 wrote:
> 
> > On Wed, 22 Feb 2017 00:14:32 +0100
> > Marton Balint  wrote:
> >  
> >> This ensures that the wrapped avframe will not get reallocated later, which
> >> would invalidate internal references such as extended data.
> >> 
> >> Signed-off-by: Marton Balint 
> >> ---
> >>  libavcodec/wrapped_avframe.c | 16 ++--
> >>  1 file changed, 14 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/libavcodec/wrapped_avframe.c b/libavcodec/wrapped_avframe.c
> >> index 13c8d8a..1436032 100644
> >> --- a/libavcodec/wrapped_avframe.c
> >> +++ b/libavcodec/wrapped_avframe.c
> >> @@ -43,19 +43,31 @@ static int wrapped_avframe_encode(AVCodecContext 
> >> *avctx, AVPacket *pkt,
> >>   const AVFrame *frame, int *got_packet)
> >>  {
> >>  AVFrame *wrapped = av_frame_clone(frame);
> >> +uint8_t *data;
> >> +int size = sizeof(*wrapped) + AV_INPUT_BUFFER_PADDING_SIZE;
> >>
> >>  if (!wrapped)
> >>  return AVERROR(ENOMEM);
> >> 
> >> -pkt->buf = av_buffer_create((uint8_t *)wrapped, sizeof(*wrapped),
> >> +data = av_mallocz(size);
> >> +if (!data) {
> >> +av_frame_free();
> >> +return AVERROR(ENOMEM);
> >> +}
> >> +
> >> +pkt->buf = av_buffer_create(data, size,
> >>  wrapped_avframe_release_buffer, NULL,
> >>  AV_BUFFER_FLAG_READONLY);
> >>  if (!pkt->buf) {
> >>  av_frame_free();
> >> +av_freep();
> >>  return AVERROR(ENOMEM);
> >>  }
> >> 
> >> -pkt->data = (uint8_t *)wrapped;
> >> +av_frame_move_ref((AVFrame*)data, wrapped);
> >> +av_frame_free();  
> >
> > I think this could be done as just
> >
> >  av_frame_ref((AVFrame*)data, frame);
> >
> > without calling av_frame_clone(), but it doesn't hurt either. (Changing
> > it might be an optional, minor improvement.)  
> 
> You are right, yet I used av_frame_move_ref, because it overwrites the 
> contents of AVFrame directly, so it does not matter that I allocated it 
> with mallocz instead of av_frame_alloc, and av_frame_ref docs explicitly 
> requires an unref-ed or alloc-ed AVFrame. So this seemed more safe, even 
> if it involves a few more code lines.

Shouldn't make a difference.

I'm also just seeing that this violates ABI by using sizeof(AVFrame)
(how typical of FFmpeg/Libav code to violate its own complicated ABI
rules), but it was like this before and can't be fixed. Probably
another thing that could be fixed with the next ABI bump.

> >  
> >> +
> >> +pkt->data = data;
> >>  pkt->size = sizeof(*wrapped);
> >>
> >>  pkt->flags |= AV_PKT_FLAG_KEY;  
> >
> > Patch looks good, and I like it better than checking the codec ID.  
> 
> Ok, will apply soon.

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


Re: [FFmpeg-devel] [PATCH v1 1/2] codec: vrawdepay: add decoder for RFC4175

2017-02-22 Thread Damien Riegel
On Fri, Feb 17, 2017 at 03:01:05PM -0500, Damien Riegel wrote:
> Hi,
> 
> On Thu, Feb 16, 2017 at 06:19:00PM +, Rostislav Pehlivanov wrote:
> > >
> > > No, do this in libavfilter and do not introduce another useless pseudo
> > > codec
> > >
> > 
> > *libavformat, sorry
> 
> The advantage of using a pseudo codec just to depack the stream is that
> the input and the codec are in separate threads in ffmpeg, so it can
> handle a heavier workload.

Please find attached a v2, with the implementation in libavformat. Note
that I don't want to send it as a patch of its own because the
performance issue is not addressed.

Basically, our test case is a raw input stream YUV 4:2:2 10 bits 1080p
at 60fps. With the pseudo-codec, we are able to transcode it to h264 and
dump it to a file. With unpacking done in the libavformat, the input
thread gets too busy and can't stand the load.

In the implementation you made [1] unpacking was done in libavcodec, so
why is it not an acceptable solution for mainline?

[1] https://github.com/funman/ffmpeg-sdi

Thanks,
-- 
Damien
>From c81e69979433ed519932354e848889a90d25f1c5 Mon Sep 17 00:00:00 2001
From: Damien Riegel 
Date: Wed, 16 Nov 2016 15:27:13 -0500
Subject: [PATCH v2] rtp: rawvideo: add handler for YCbCr-4:2:2

This adds partial support for the RFC 4175 (raw video over RTP). The
only supported formats are the YCbCr-4:2:2 8 and 10 bit.

For 8-bit depth, the format is similar to AV_PIX_FMT_UYVY422, and for
10-bit, the stream is repacked to the planar format
AV_PIX_FMT_YUV422P10LE.

Signed-off-by: Damien Riegel 
---
 libavformat/Makefile  |   1 +
 libavformat/rtpdec.c  |   1 +
 libavformat/rtpdec_formats.h  |   1 +
 libavformat/rtpdec_rawvideo.c | 259 ++
 4 files changed, 262 insertions(+)
 create mode 100644 libavformat/rtpdec_rawvideo.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index fc2d76067b..e17ba95c23 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -55,6 +55,7 @@ OBJS-$(CONFIG_RTPDEC)+= rdt.o   \
 rtpdec_qcelp.o  \
 rtpdec_qdm2.o   \
 rtpdec_qt.o \
+rtpdec_rawvideo.o   \
 rtpdec_svq3.o   \
 rtpdec_vc2hq.o  \
 rtpdec_vp8.o\
diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
index 53cdad7396..345318c32c 100644
--- a/libavformat/rtpdec.c
+++ b/libavformat/rtpdec.c
@@ -114,6 +114,7 @@ void ff_register_rtp_dynamic_payload_handlers(void)
 ff_register_dynamic_payload_handler(_qt_rtp_vid_handler);
 ff_register_dynamic_payload_handler(_quicktime_rtp_aud_handler);
 ff_register_dynamic_payload_handler(_quicktime_rtp_vid_handler);
+ff_register_dynamic_payload_handler(_rawvideo_rtp_handler);
 ff_register_dynamic_payload_handler(_svq3_dynamic_handler);
 ff_register_dynamic_payload_handler(_theora_dynamic_handler);
 ff_register_dynamic_payload_handler(_vc2hq_dynamic_handler);
diff --git a/libavformat/rtpdec_formats.h b/libavformat/rtpdec_formats.h
index 3292a3d265..fab12fd139 100644
--- a/libavformat/rtpdec_formats.h
+++ b/libavformat/rtpdec_formats.h
@@ -82,6 +82,7 @@ extern RTPDynamicProtocolHandler ff_qt_rtp_aud_handler;
 extern RTPDynamicProtocolHandler ff_qt_rtp_vid_handler;
 extern RTPDynamicProtocolHandler ff_quicktime_rtp_aud_handler;
 extern RTPDynamicProtocolHandler ff_quicktime_rtp_vid_handler;
+extern RTPDynamicProtocolHandler ff_rawvideo_rtp_handler;
 extern RTPDynamicProtocolHandler ff_svq3_dynamic_handler;
 extern RTPDynamicProtocolHandler ff_theora_dynamic_handler;
 extern RTPDynamicProtocolHandler ff_vc2hq_dynamic_handler;
diff --git a/libavformat/rtpdec_rawvideo.c b/libavformat/rtpdec_rawvideo.c
new file mode 100644
index 00..7edde84306
--- /dev/null
+++ b/libavformat/rtpdec_rawvideo.c
@@ -0,0 +1,259 @@
+/*
+ * RTP Depacketization of RAW video (TR-03)
+ * Copyright (c) 2016 Savoir-faire Linux, Inc
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with 

Re: [FFmpeg-devel] [PATCH] avcodec/wrapped_avframe: allocate a buffer with padding

2017-02-22 Thread Marton Balint


On Wed, 22 Feb 2017, wm4 wrote:


On Wed, 22 Feb 2017 00:14:32 +0100
Marton Balint  wrote:


This ensures that the wrapped avframe will not get reallocated later, which
would invalidate internal references such as extended data.

Signed-off-by: Marton Balint 
---
 libavcodec/wrapped_avframe.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/libavcodec/wrapped_avframe.c b/libavcodec/wrapped_avframe.c
index 13c8d8a..1436032 100644
--- a/libavcodec/wrapped_avframe.c
+++ b/libavcodec/wrapped_avframe.c
@@ -43,19 +43,31 @@ static int wrapped_avframe_encode(AVCodecContext *avctx, 
AVPacket *pkt,
  const AVFrame *frame, int *got_packet)
 {
 AVFrame *wrapped = av_frame_clone(frame);
+uint8_t *data;
+int size = sizeof(*wrapped) + AV_INPUT_BUFFER_PADDING_SIZE;

 if (!wrapped)
 return AVERROR(ENOMEM);

-pkt->buf = av_buffer_create((uint8_t *)wrapped, sizeof(*wrapped),
+data = av_mallocz(size);
+if (!data) {
+av_frame_free();
+return AVERROR(ENOMEM);
+}
+
+pkt->buf = av_buffer_create(data, size,
 wrapped_avframe_release_buffer, NULL,
 AV_BUFFER_FLAG_READONLY);
 if (!pkt->buf) {
 av_frame_free();
+av_freep();
 return AVERROR(ENOMEM);
 }

-pkt->data = (uint8_t *)wrapped;
+av_frame_move_ref((AVFrame*)data, wrapped);
+av_frame_free();


I think this could be done as just

 av_frame_ref((AVFrame*)data, frame);

without calling av_frame_clone(), but it doesn't hurt either. (Changing
it might be an optional, minor improvement.)


You are right, yet I used av_frame_move_ref, because it overwrites the 
contents of AVFrame directly, so it does not matter that I allocated it 
with mallocz instead of av_frame_alloc, and av_frame_ref docs explicitly 
requires an unref-ed or alloc-ed AVFrame. So this seemed more safe, even 
if it involves a few more code lines.





+
+pkt->data = data;
 pkt->size = sizeof(*wrapped);

 pkt->flags |= AV_PKT_FLAG_KEY;


Patch looks good, and I like it better than checking the codec ID.


Ok, will apply soon.

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


Re: [FFmpeg-devel] [PATCH] doc: drawtext options update

2017-02-22 Thread Lou Logan
On Tue, 21 Feb 2017 21:24:55 -0900, Lou Logan wrote:

> This can occur if the patch itself is directly edited, but I can fix it
> and apply within 24 hours.

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


Re: [FFmpeg-devel] minterpolate filter

2017-02-22 Thread Michael Niedermayer
On Wed, Feb 22, 2017 at 08:02:00AM +, Ural wrote:
> Hello all. First, thanks for doing great and hard work. I can't imagine
> any video-(pre/post)processing exist without ffmpeg.
> I am posting my question in devel, because I am not asking how to do
> something. What I am trying to do works, but bad.
> 
> I create videos from pictures and need to make them as smooth as
> possible. I found, that what I need called 'motion interpolation'. I
> started to search all forums, and found only 3 things can help me:
> slowmovideo, butterflow and new ffmpeg's filter minterpolate.
> 
> 
> slowmovideo needs many configuration, I was not able to get it to work
> as I want. with butterflow, I tried anything. From installing OpenCL,
> OpenGL and other stuff to switching to nvidia binary drivers and
> installing all sdk tools and cuda. It never worked. Some error about
> cuda, and google don't know about it.
> 
> 
> So third option was the only one available. When I tried it, it did
> exactly what I want! But it is incredibly SLOW. I have 8-core CPU, and
> it processes about 0.1-0.3 fps. And uses just 1 CORE, no video card.
> 
> Guys, do you have some plans about this awesome filter? Like to port it
> to opencl, or use at least all cores? There are no any option available,
> so all hopes only to this filter. Or maybe some other
> alternatives/patches exist?

theres mcfps
https://github.com/michaelni/FFmpeg/tree/mcfps

its not really designed for speed but if you switch it to use non
iterative ME (see diff below) it does around 12fps here with matrixbench

mcfps is far from finished, i had many ideas on how to improve it
and as funding was mentioned in another reply in this thread and i
think i didnt mention it before, there was a company funding the mcfps
work. The ideas people had during review of the mcfps work conflicted
with my ideas to improve the motion estimation code though and without
these improvments, the quality the company would expect would not be
achievable. Which kind of halted the project

minterpolate came after that as a gsoc project and was supposed to
be based on mcfps but wasnt really, so each of mcfps and minterpolate
are better at some things and worse at others.
Also noone is working on minterpolate anymore AFAIK

Both mcfps and minterpolate are quality wise not as good as id like
There were alot of ideas/improvments that should be tried.
Optimizing the existing code should come after improving it quality
wise, except were such optimizations arent in the way of improving the
code.

If i find the motivation to work on improving the quality of the
now in git minterpolate, i guess i could check if that company still
is interrested in funding that or if they dont want to hear anything
from me and that filter anymore ... its quite a while.
not saying that this would be boring work id only do if its payed

diff --git a/libavfilter/vf_mcfps.c b/libavfilter/vf_mcfps.c
index 0aa951e7a0..788d600f28 100644
--- a/libavfilter/vf_mcfps.c
+++ b/libavfilter/vf_mcfps.c
@@ -258,7 +258,7 @@ av_log(0,0, "FPS %d/%d\n", mcfps->frame_rate.num, 
mcfps->frame_rate.den);
 avctx_enc->flags |= CODEC_FLAG_QPEL;
 avctx_enc->strict_std_compliance = FF_COMPLIANCE_EXPERIMENTAL;
 avctx_enc->global_quality = 12;
-avctx_enc->me_method = ME_ITER;
+avctx_enc->me_method = ME_EPZS;
 // avctx_enc->dia_size = 16;
 avctx_enc->mb_decision = FF_MB_DECISION_RD;
 avctx_enc->scenechange_threshold = 20;
[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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


[FFmpeg-devel] [PATCH] configure/rtmpdh: Fix OpenSSL 1.1.0 support

2017-02-22 Thread Stefan _
1) configure only looks for OPENSSL_init_ssl using pkg-config, this 
breaks in case pkg-config is not available (cross-compiling)


2) The rtmpdh code uses the DH struct from OpenSSL which was made 
private in the 1.1 series


From 5cc140f85d8d7551ac0a2c51d5023bd8ba75ba4b Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Wed, 22 Feb 2017 15:35:57 +0100
Subject: [PATCH 1/2] configure: Support OpenSSL 1.1.0 without pkg-config

---
 configure | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index 6431313814..16db9edc1b 100755
--- a/configure
+++ b/configure
@@ -5892,6 +5892,7 @@ enabled omx   && { check_header OMX_Core.h ||
die "ERROR: OpenMAX IL headers not found"; }
 enabled openssl   && { use_pkg_config openssl openssl/ssl.h OPENSSL_init_ssl ||
use_pkg_config openssl openssl/ssl.h SSL_library_init ||
+   check_lib openssl/ssl.h OPENSSL_init_ssl -lssl -lcrypto ||
check_lib openssl/ssl.h SSL_library_init -lssl -lcrypto ||
check_lib openssl/ssl.h SSL_library_init -lssl32 -leay32 ||
check_lib openssl/ssl.h SSL_library_init -lssl -lcrypto -lws2_32 -lgdi32 ||
-- 
2.11.1

From ee02425f851d0c9cfb8a892f385394efe5b4fdda Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Wed, 22 Feb 2017 15:38:16 +0100
Subject: [PATCH 2/2] rtmpdh: Support OpenSSL 1.1.0

DH (struct dh_st) was made private in the 1.1 series, a replacement
similar to the FF_DH struct for gcrypt/gmp is used instead.
---
 libavformat/rtmpdh.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/libavformat/rtmpdh.h b/libavformat/rtmpdh.h
index 2b250f595d..2d1489b193 100644
--- a/libavformat/rtmpdh.h
+++ b/libavformat/rtmpdh.h
@@ -48,10 +48,19 @@ typedef struct FF_DH {
 #elif CONFIG_OPENSSL
 #include 
 #include 
+#include 
 
 typedef BIGNUM *FFBigNum;
+#if OPENSSL_VERSION_NUMBER >= 0x101fL
+typedef struct {
+BIGNUM *p, *g;
+BIGNUM *pub_key, *priv_key;
+long length;
+} FF_DH;
+#else
 typedef DH FF_DH;
 #endif
+#endif
 
 /**
  * Initialize a Diffie-Hellmann context.
-- 
2.11.1

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


Re: [FFmpeg-devel] [PATCH] avcodec/h264_ps: Check chroma_qp_index_offset

2017-02-22 Thread Paul B Mahol
On 2/22/17, Michael Niedermayer  wrote:
> On Wed, Feb 22, 2017 at 04:41:43PM +0100, Paul B Mahol wrote:
>> On 2/22/17, Michael Niedermayer  wrote:
>> > On Wed, Feb 22, 2017 at 02:29:00PM +0100, Paul B Mahol wrote:
>> >> On 2/22/17, Michael Niedermayer  wrote:
>> >> > Fixes: 647/clusterfuzz-testcase-5195745823031296
>> >> >
>> >> > Found-by: continuous fuzzing process
>> >> > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
>> >> > Signed-off-by: Michael Niedermayer 
>> >> > ---
>> >> >  libavcodec/h264_ps.c | 11 +++
>> >> >  1 file changed, 11 insertions(+)
>> >> >
>> >> > diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
>> >> > index 8090178395..f4a4a01fbe 100644
>> >> > --- a/libavcodec/h264_ps.c
>> >> > +++ b/libavcodec/h264_ps.c
>> >> > @@ -828,6 +828,12 @@ int
>> >> > ff_h264_decode_picture_parameter_set(GetBitContext
>> >> > *gb, AVCodecContext *avct
>> >> >  pps->init_qp  = get_se_golomb(gb) +
>> >> > 26
>> >> > +
>> >> > qp_bd_offset;
>> >> >  pps->init_qs  = get_se_golomb(gb) +
>> >> > 26
>> >> > +
>> >> > qp_bd_offset;
>> >> >  pps->chroma_qp_index_offset[0]= get_se_golomb(gb);
>> >> > +if (pps->chroma_qp_index_offset[0] < -12 ||
>> >> > pps->chroma_qp_index_offset[0] > 12) {
>> >> > +av_log(avctx, AV_LOG_ERROR, "chroma_qp_index_offset[0] %d
>> >> > is
>> >>
>> >> This is nonsense. Please remove.
>> >
>> > Id like to keep the error messages or id like to have someone else
>> > take over h264 maintaince in ffmpeg.
>>
>> Than why you are posting patches at all, if you do not want to listen
>> to reviews.
>
> ive posted a patchset with ff_elog() instead
>
> do people prefer that ?
>
> [...]

You could right now start adding such messages at every error path.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/1] Add support for Ericsson Texture Compression 1 (ETC1)

2017-02-22 Thread Paul B Mahol
On 2/22/17, Devin Heitmueller  wrote:
> This patch adds support for encoding/decoding ETC1 compressed
> textures.  This includes support for the PKM file format.
>
> Example usage:
>
> ./ffmpeg -i input_image.jpg new.pkm
> ./ffmpeg -i new.pkm foo.jpg
>
> Signed-off-by: Devin Heitmueller 
> ---
>  libavcodec/Makefile |   2 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/avcodec.h|   1 +
>  libavcodec/codec_desc.c |   7 +
>  libavcodec/etc1.c   | 707
> 
>  libavcodec/etc1.h   | 114 
>  libavcodec/etc1dec.c|  81 ++
>  libavcodec/etc1enc.c|  90 ++
>  libavcodec/utils.c  |   3 +-
>  libavformat/img2.c  |   1 +
>  libavformat/img2enc.c   |   2 +-
>  11 files changed, 1007 insertions(+), 2 deletions(-)
>  create mode 100644 libavcodec/etc1.c
>  create mode 100644 libavcodec/etc1.h
>  create mode 100644 libavcodec/etc1dec.c
>  create mode 100644 libavcodec/etc1enc.c
>

Apache 2.0 license is bad in combination with LGPL.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/h264_ps: Check chroma_qp_index_offset

2017-02-22 Thread Michael Niedermayer
On Wed, Feb 22, 2017 at 04:41:43PM +0100, Paul B Mahol wrote:
> On 2/22/17, Michael Niedermayer  wrote:
> > On Wed, Feb 22, 2017 at 02:29:00PM +0100, Paul B Mahol wrote:
> >> On 2/22/17, Michael Niedermayer  wrote:
> >> > Fixes: 647/clusterfuzz-testcase-5195745823031296
> >> >
> >> > Found-by: continuous fuzzing process
> >> > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> >> > Signed-off-by: Michael Niedermayer 
> >> > ---
> >> >  libavcodec/h264_ps.c | 11 +++
> >> >  1 file changed, 11 insertions(+)
> >> >
> >> > diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
> >> > index 8090178395..f4a4a01fbe 100644
> >> > --- a/libavcodec/h264_ps.c
> >> > +++ b/libavcodec/h264_ps.c
> >> > @@ -828,6 +828,12 @@ int
> >> > ff_h264_decode_picture_parameter_set(GetBitContext
> >> > *gb, AVCodecContext *avct
> >> >  pps->init_qp  = get_se_golomb(gb) + 26
> >> > +
> >> > qp_bd_offset;
> >> >  pps->init_qs  = get_se_golomb(gb) + 26
> >> > +
> >> > qp_bd_offset;
> >> >  pps->chroma_qp_index_offset[0]= get_se_golomb(gb);
> >> > +if (pps->chroma_qp_index_offset[0] < -12 ||
> >> > pps->chroma_qp_index_offset[0] > 12) {
> >> > +av_log(avctx, AV_LOG_ERROR, "chroma_qp_index_offset[0] %d is
> >>
> >> This is nonsense. Please remove.
> >
> > Id like to keep the error messages or id like to have someone else
> > take over h264 maintaince in ffmpeg.
> 
> Than why you are posting patches at all, if you do not want to listen
> to reviews.

ive posted a patchset with ff_elog() instead

do people prefer that ?

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

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


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


[FFmpeg-devel] [PATCH 1/2] avutil/internal: Add ff_elog()

2017-02-22 Thread Michael Niedermayer
This enables the extra error messages in case of DEBUG or high assrtion levels.
High assertion levels imply slow checks in inner loops so any extra error should
be insignificant.
Is it preferred to have a separate switch for ff_elog() so it doesnt depend on
DEBUG/assertion level ?

Signed-off-by: Michael Niedermayer 
---
 libavutil/internal.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavutil/internal.h b/libavutil/internal.h
index 7780a9a791..208f8f474f 100644
--- a/libavutil/internal.h
+++ b/libavutil/internal.h
@@ -262,6 +262,12 @@ void avpriv_request_sample(void *avc,
 #   define ff_dlog(ctx, ...) do { if (0) av_log(ctx, AV_LOG_DEBUG, 
__VA_ARGS__); } while (0)
 #endif
 
+#if defined(DEBUG) || ASSERT_LEVEL > 1
+#   define ff_elog(ctx, ...) av_log(ctx, AV_LOG_ERROR, __VA_ARGS__)
+#else
+#   define ff_elog(ctx, ...) do { if (0) av_log(ctx, AV_LOG_ERROR, 
__VA_ARGS__); } while (0)
+#endif
+
 // For debuging we use signed operations so overflows can be detected (by 
ubsan)
 // For production we use unsigned so there are no undefined operations
 #ifdef CHECKED
-- 
2.11.0

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


[FFmpeg-devel] [PATCH 2/2] avcodec/h264_ps: Check chroma_qp_index_offset

2017-02-22 Thread Michael Niedermayer
Fixes: 647/clusterfuzz-testcase-5195745823031296

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

diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 8090178395..9417b6c037 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -828,6 +828,12 @@ int ff_h264_decode_picture_parameter_set(GetBitContext 
*gb, AVCodecContext *avct
 pps->init_qp  = get_se_golomb(gb) + 26 + 
qp_bd_offset;
 pps->init_qs  = get_se_golomb(gb) + 26 + 
qp_bd_offset;
 pps->chroma_qp_index_offset[0]= get_se_golomb(gb);
+if (pps->chroma_qp_index_offset[0] < -12 || pps->chroma_qp_index_offset[0] 
> 12) {
+ff_elog(avctx, "chroma_qp_index_offset[0] %d is invalid\n", 
pps->chroma_qp_index_offset[0]);
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
+
 pps->deblocking_filter_parameters_present = get_bits1(gb);
 pps->constrained_intra_pred   = get_bits1(gb);
 pps->redundant_pic_cnt_present= get_bits1(gb);
@@ -845,6 +851,11 @@ int ff_h264_decode_picture_parameter_set(GetBitContext 
*gb, AVCodecContext *avct
 pps->scaling_matrix4, pps->scaling_matrix8);
 // second_chroma_qp_index_offset
 pps->chroma_qp_index_offset[1] = get_se_golomb(gb);
+if (pps->chroma_qp_index_offset[1] < -12 || 
pps->chroma_qp_index_offset[1] > 12) {
+ff_elog(avctx, "chroma_qp_index_offset[1] %d is invalid\n", 
pps->chroma_qp_index_offset[1]);
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
 } else {
 pps->chroma_qp_index_offset[1] = pps->chroma_qp_index_offset[0];
 }
-- 
2.11.0

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


[FFmpeg-devel] [PATCH 1/1] Add support for Ericsson Texture Compression 1 (ETC1)

2017-02-22 Thread Devin Heitmueller
This patch adds support for encoding/decoding ETC1 compressed
textures.  This includes support for the PKM file format.

Example usage:

./ffmpeg -i input_image.jpg new.pkm
./ffmpeg -i new.pkm foo.jpg

Signed-off-by: Devin Heitmueller 
---
 libavcodec/Makefile |   2 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   7 +
 libavcodec/etc1.c   | 707 
 libavcodec/etc1.h   | 114 
 libavcodec/etc1dec.c|  81 ++
 libavcodec/etc1enc.c|  90 ++
 libavcodec/utils.c  |   3 +-
 libavformat/img2.c  |   1 +
 libavformat/img2enc.c   |   2 +-
 11 files changed, 1007 insertions(+), 2 deletions(-)
 create mode 100644 libavcodec/etc1.c
 create mode 100644 libavcodec/etc1.h
 create mode 100644 libavcodec/etc1dec.c
 create mode 100644 libavcodec/etc1enc.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index a1ce264..f5eec15 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -280,6 +280,8 @@ OBJS-$(CONFIG_EIGHTSVX_EXP_DECODER)+= 8svx.o
 OBJS-$(CONFIG_EIGHTSVX_FIB_DECODER)+= 8svx.o
 OBJS-$(CONFIG_ESCAPE124_DECODER)   += escape124.o
 OBJS-$(CONFIG_ESCAPE130_DECODER)   += escape130.o
+OBJS-$(CONFIG_ETC1_ENCODER)+= etc1enc.o etc1.o
+OBJS-$(CONFIG_ETC1_DECODER)+= etc1dec.o etc1.o
 OBJS-$(CONFIG_EVRC_DECODER)+= evrcdec.o acelp_vectors.o lsp.o
 OBJS-$(CONFIG_EXR_DECODER) += exr.o
 OBJS-$(CONFIG_FFV1_DECODER)+= ffv1dec.o ffv1.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index f12a54d..cd3a662 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -184,6 +184,7 @@ void avcodec_register_all(void)
 REGISTER_DECODER(EIGHTSVX_FIB,  eightsvx_fib);
 REGISTER_DECODER(ESCAPE124, escape124);
 REGISTER_DECODER(ESCAPE130, escape130);
+REGISTER_ENCDEC (ETC1,  etc1);
 REGISTER_DECODER(EXR,   exr);
 REGISTER_ENCDEC (FFV1,  ffv1);
 REGISTER_ENCDEC (FFVHUFF,   ffvhuff);
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5616fb0..bf86210 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -388,6 +388,7 @@ enum AVCodecID {
 AV_CODEC_ID_DXV,
 AV_CODEC_ID_SCREENPRESSO,
 AV_CODEC_ID_RSCC,
+AV_CODEC_ID_ETC1,
 
 AV_CODEC_ID_Y41P = 0x8000,
 AV_CODEC_ID_AVRP,
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 35846c0..de7695d 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1199,6 +1199,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
 },
 
 {
+.id= AV_CODEC_ID_ETC1,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "etc1",
+.long_name = NULL_IF_CONFIG_SMALL("ETC1 (Ericsson Texture Compression) 
image"),
+.props = AV_CODEC_PROP_LOSSY,
+},
+{
 .id= AV_CODEC_ID_G2M,
 .type  = AVMEDIA_TYPE_VIDEO,
 .name  = "g2m",
diff --git a/libavcodec/etc1.c b/libavcodec/etc1.c
new file mode 100644
index 000..e28d83c
--- /dev/null
+++ b/libavcodec/etc1.c
@@ -0,0 +1,707 @@
+// Copyright 2009 Google Inc.
+//
+// Licensed under the Apache License, Version 2.0 (the "License");
+// you may not use this file except in compliance with the License.
+// You may obtain a copy of the License at
+//
+// http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS,
+// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+// See the License for the specific language governing permissions and
+// limitations under the License.
+
+//
+
+// This is a fork of the AOSP project ETC1 codec. The original code can be 
found
+// at the following web site:
+// 
https://android.googlesource.com/platform/frameworks/native/+/master/opengl/include/ETC1/
+
+//
+
+#include "etc1.h"
+
+//#include 
+#include 
+
+/* From 
http://www.khronos.org/registry/gles/extensions/OES/OES_compressed_ETC1_RGB8_texture.txt
+
+ The number of bits that represent a 4x4 texel block is 64 bits if
+  is given by ETC1_RGB8_OES.
+
+ The data for a block is a number of bytes,
+
+ {q0, q1, q2, q3, q4, q5, q6, q7}
+
+ where byte q0 is located at the lowest memory address and q7 at
+ the highest. The 64 bits specifying the block is then represented
+ by the following 64 bit integer:
+
+ int64bit = 256*(256*(256*(256*(256*(256*(256*q0+q1)+q2)+q3)+q4)+q5)+q6)+q7;
+
+ ETC1_RGB8_OES:
+
+ a) bit layout in bits 63 through 32 if diffbit = 0
+
+ 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48
+ 

[FFmpeg-devel] [PATCH 0/1] Add ETC1 encoder/decoder

2017-02-22 Thread Devin Heitmueller
This patch adds support for encoding and decoding the Ericsson Texture
Compression 1 (ETC1) format.  This includes support for the PKM file
format.

Note the actual codec uses Google's ETC1 implementation from Android
(Apache 2 licensed).  The only changes I made were a couple of very shallow
 fixes to compile in C90 mode (cases where variables were being declared
in-line with code).

Devin Heitmueller (1):
  Add support for Ericsson Texture Compression 1 (ETC1)

 libavcodec/Makefile |   2 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   7 +
 libavcodec/etc1.c   | 707 
 libavcodec/etc1.h   | 114 
 libavcodec/etc1dec.c|  81 ++
 libavcodec/etc1enc.c|  90 ++
 libavcodec/utils.c  |   3 +-
 libavformat/img2.c  |   1 +
 libavformat/img2enc.c   |   2 +-
 11 files changed, 1007 insertions(+), 2 deletions(-)
 create mode 100644 libavcodec/etc1.c
 create mode 100644 libavcodec/etc1.h
 create mode 100644 libavcodec/etc1dec.c
 create mode 100644 libavcodec/etc1enc.c

-- 
1.9.1

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


Re: [FFmpeg-devel] [PATCHv3 3/3] mkv: Export bounds and padding from spherical metadata

2017-02-22 Thread James Almer
On 2/21/2017 7:35 PM, Vittorio Giovara wrote:
> ---
>  libavformat/matroskadec.c  | 64 
> --
>  tests/ref/fate/matroska-spherical-mono |  6 +++-
>  2 files changed, 66 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 7223e94..0a02237 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -1913,16 +1913,65 @@ static int mkv_parse_video_projection(AVStream *st, 
> const MatroskaTrack *track)
>  AVSphericalMapping *spherical;
>  enum AVSphericalProjection projection;
>  size_t spherical_size;
> +size_t l, t, r, b;
> +size_t padding = 0;
>  int ret;
> +GetByteContext gb;
> +
> +bytestream2_init(, track->video.projection.private.data,
> + track->video.projection.private.size);

private.size can be zero and private.data NULL. bytestream2_init()
will trigger an assert in those cases.

> +
> +if (bytestream2_get_byte() != 0) {
> +av_log(NULL, AV_LOG_WARNING, "Unknown spherical metadata\n");
> +return 0;
> +}
> +
> +bytestream2_skip(, 3); // flags
>  
>  switch (track->video.projection.type) {
>  case MATROSKA_VIDEO_PROJECTION_TYPE_EQUIRECTANGULAR:
> -projection = AV_SPHERICAL_EQUIRECTANGULAR;
> +if (track->video.projection.private.size == 0)
> +projection = AV_SPHERICAL_EQUIRECTANGULAR;
> +else if (track->video.projection.private.size == 20) {
> +t = bytestream2_get_be32();
> +b = bytestream2_get_be32();
> +l = bytestream2_get_be32();
> +r = bytestream2_get_be32();
> +
> +if (b >= UINT_MAX - t || r >= UINT_MAX - l) {
> +av_log(NULL, AV_LOG_ERROR,
> +   "Invalid bounding rectangle coordinates "
> +   "%zu,%zu,%zu,%zu\n", l, t, r, b);

Use SIZE_SPECIFIER instead of zu. Msvc doesn't like the latter.
Same with the mov implementation.

> +return AVERROR_INVALIDDATA;
> +}
> +
> +if (l || t || r || b)
> +projection = AV_SPHERICAL_EQUIRECTANGULAR_TILE;
> +else
> +projection = AV_SPHERICAL_EQUIRECTANGULAR;
> +} else {
> +av_log(NULL, AV_LOG_ERROR, "Unknown spherical metadata\n");
> +return AVERROR_INVALIDDATA;
> +}
>  break;

Nit: I still think the Equi case looks better the way i suggested in
my previous email.

>  case MATROSKA_VIDEO_PROJECTION_TYPE_CUBEMAP:
> -if (track->video.projection.private.size < 4)
> +if (track->video.projection.private.size < 4) {
> +av_log(NULL, AV_LOG_ERROR, "Missing projection private 
> properties\n");
> +return AVERROR_INVALIDDATA;
> +} else if (track->video.projection.private.size == 12) {
> +uint32_t layout = bytestream2_get_be32();
> +if (layout == 0) {
> +projection = AV_SPHERICAL_CUBEMAP;
> +} else {
> +av_log(NULL, AV_LOG_WARNING,
> +   "Unknown spherical cubemap layout %"PRIu32"\n", 
> layout);
> +return 0;
> +}
> +padding = bytestream2_get_be32();

Nit: Maybe

   if (layout) {
   // return error
   }
   projection = AV_SPHERICAL_CUBEMAP;
   padding= bytestream2_get_be32();

> +} else {
> +av_log(NULL, AV_LOG_ERROR, "Unknown spherical metadata\n");
>  return AVERROR_INVALIDDATA;
> -projection = AV_SPHERICAL_CUBEMAP;
> +}
>  break;
>  default:
>  return 0;
> @@ -1937,6 +1986,15 @@ static int mkv_parse_video_projection(AVStream *st, 
> const MatroskaTrack *track)
>  spherical->pitch = (int32_t)(track->video.projection.pitch * (1 << 16));
>  spherical->roll  = (int32_t)(track->video.projection.roll  * (1 << 16));
>  
> +spherical->padding = padding;
> +
> +if (spherical->projection == AV_SPHERICAL_EQUIRECTANGULAR_TILE) {
> +spherical->bound_left   = l;
> +spherical->bound_top= t;
> +spherical->bound_right  = r;
> +spherical->bound_bottom = b;

These four could also be zero initialized so you don't need to check
the projection.

> +}
> +
>  ret = av_stream_add_side_data(st, AV_PKT_DATA_SPHERICAL, (uint8_t 
> *)spherical,
>spherical_size);
>  if (ret < 0) {
> diff --git a/tests/ref/fate/matroska-spherical-mono 
> b/tests/ref/fate/matroska-spherical-mono
> index 8048aff..a70d879 100644
> --- a/tests/ref/fate/matroska-spherical-mono
> +++ b/tests/ref/fate/matroska-spherical-mono
> @@ -8,7 +8,11 @@ inverted=0
>  [SIDE_DATA]
>  side_data_type=Spherical Mapping
>  side_data_size=56
> -projection=equirectangular
> +projection=tiled equirectangular
> +bound_left=148
> +bound_top=73
> 

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

2017-02-22 Thread Przemysław Sobala
From: Przemysław Sobala 

Provides a way to change bandwidth (bitrate) parameter after CRF H.264 encoding 
(details: http://ffmpeg.org/pipermail/libav-user/2017-February/010141.html)

Signed-off-by: Przemysław Sobala 
---
 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 = >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 = >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 = >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


Re: [FFmpeg-devel] [PATCH] avcodec/h264_ps: Check chroma_qp_index_offset

2017-02-22 Thread Paul B Mahol
On 2/22/17, Michael Niedermayer  wrote:
> On Wed, Feb 22, 2017 at 02:29:00PM +0100, Paul B Mahol wrote:
>> On 2/22/17, Michael Niedermayer  wrote:
>> > Fixes: 647/clusterfuzz-testcase-5195745823031296
>> >
>> > Found-by: continuous fuzzing process
>> > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
>> > Signed-off-by: Michael Niedermayer 
>> > ---
>> >  libavcodec/h264_ps.c | 11 +++
>> >  1 file changed, 11 insertions(+)
>> >
>> > diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
>> > index 8090178395..f4a4a01fbe 100644
>> > --- a/libavcodec/h264_ps.c
>> > +++ b/libavcodec/h264_ps.c
>> > @@ -828,6 +828,12 @@ int
>> > ff_h264_decode_picture_parameter_set(GetBitContext
>> > *gb, AVCodecContext *avct
>> >  pps->init_qp  = get_se_golomb(gb) + 26
>> > +
>> > qp_bd_offset;
>> >  pps->init_qs  = get_se_golomb(gb) + 26
>> > +
>> > qp_bd_offset;
>> >  pps->chroma_qp_index_offset[0]= get_se_golomb(gb);
>> > +if (pps->chroma_qp_index_offset[0] < -12 ||
>> > pps->chroma_qp_index_offset[0] > 12) {
>> > +av_log(avctx, AV_LOG_ERROR, "chroma_qp_index_offset[0] %d is
>>
>> This is nonsense. Please remove.
>
> Id like to keep the error messages or id like to have someone else
> take over h264 maintaince in ffmpeg.

Than why you are posting patches at all, if you do not want to listen
to reviews.

>
>
> [...]
>
>> Having log message for every error case would make ffmpeg binary very
>> big and slow.
>
> I think the effect of the strings and not executed calls is negligible
> but iam not opposed to use a ff_elog() or av_elog() or avpriv_elog()
> if such macro would exist.
>
> Is anyone against adding and using such a macro ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/h264_ps: Check chroma_qp_index_offset

2017-02-22 Thread Michael Niedermayer
On Wed, Feb 22, 2017 at 02:29:00PM +0100, Paul B Mahol wrote:
> On 2/22/17, Michael Niedermayer  wrote:
> > Fixes: 647/clusterfuzz-testcase-5195745823031296
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/h264_ps.c | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
> > index 8090178395..f4a4a01fbe 100644
> > --- a/libavcodec/h264_ps.c
> > +++ b/libavcodec/h264_ps.c
> > @@ -828,6 +828,12 @@ int ff_h264_decode_picture_parameter_set(GetBitContext
> > *gb, AVCodecContext *avct
> >  pps->init_qp  = get_se_golomb(gb) + 26 +
> > qp_bd_offset;
> >  pps->init_qs  = get_se_golomb(gb) + 26 +
> > qp_bd_offset;
> >  pps->chroma_qp_index_offset[0]= get_se_golomb(gb);
> > +if (pps->chroma_qp_index_offset[0] < -12 ||
> > pps->chroma_qp_index_offset[0] > 12) {
> > +av_log(avctx, AV_LOG_ERROR, "chroma_qp_index_offset[0] %d is
> 
> This is nonsense. Please remove.

Id like to keep the error messages or id like to have someone else
take over h264 maintaince in ffmpeg.


[...]

> Having log message for every error case would make ffmpeg binary very
> big and slow.

I think the effect of the strings and not executed calls is negligible
but iam not opposed to use a ff_elog() or av_elog() or avpriv_elog()
if such macro would exist.

Is anyone against adding and using such a macro ?


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

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


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


[FFmpeg-devel] [PATCH] fixup! avcodec/mips: version 1 of vc1dsp optimizations for loongson mmi

2017-02-22 Thread Jacek Manko
---
 libavcodec/mips/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
index b118558..797df09 100644
--- a/libavcodec/mips/Makefile
+++ b/libavcodec/mips/Makefile
@@ -36,7 +36,7 @@ OBJS-$(CONFIG_MPEGVIDEO)  += 
mips/mpegvideo_init_mips.o
 OBJS-$(CONFIG_MPEGVIDEOENC)   += mips/mpegvideoencdsp_init_mips.o
 OBJS-$(CONFIG_ME_CMP) += mips/me_cmp_init_mips.o
 OBJS-$(CONFIG_MPEG4_DECODER)  += mips/xvididct_init_mips.o
-OBJS-$(CONFIG_VC1_DECODER)+= mips/vc1dsp_init_mips.o
+OBJS-$(CONFIG_VC1DSP) += mips/vc1dsp_init_mips.o
 OBJS-$(CONFIG_WMV2DSP)+= mips/wmv2dsp_init_mips.o
 MSA-OBJS-$(CONFIG_HEVC_DECODER)   += mips/hevcdsp_msa.o\
  mips/hevc_mc_uni_msa.o\
-- 
2.7.4

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


[FFmpeg-devel] [PATCH] avcodec/qdrw: add support for 0x0001 code

2017-02-22 Thread Paul B Mahol
Fixes decoding of files which sets frame width/height this way.

Signed-off-by: Paul B Mahol 
---
 libavcodec/qdrw.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/libavcodec/qdrw.c b/libavcodec/qdrw.c
index e3d69c2..2462e2f 100644
--- a/libavcodec/qdrw.c
+++ b/libavcodec/qdrw.c
@@ -33,6 +33,7 @@
 #include "internal.h"
 
 enum QuickdrawOpcodes {
+CLIP = 0x0001,
 PACKBITSRECT = 0x0098,
 PACKBITSRGN,
 DIRECTBITSRECT,
@@ -309,7 +310,7 @@ static int decode_frame(AVCodecContext *avctx,
 AVFrame * const p  = data;
 GetByteContext gbc;
 int colors;
-int w, h, ret;
+int w, h, x0, y0, x1, y1, ret;
 int ver;
 
 bytestream2_init(, avpkt->data, avpkt->size);
@@ -353,6 +354,16 @@ static int decode_frame(AVCodecContext *avctx,
 int opcode = bytestream2_get_be16();
 
 switch(opcode) {
+case CLIP:
+bytestream2_get_be16();
+y0 = bytestream2_get_be16();
+x0 = bytestream2_get_be16();
+y1 = bytestream2_get_be16();
+x1 = bytestream2_get_be16();
+ret = ff_set_dimensions(avctx, x1 - x0, y1 - y0);
+if (ret < 0)
+return ret;
+break;
 case PACKBITSRECT:
 case PACKBITSRGN:
 av_log(avctx, AV_LOG_DEBUG, "Parsing Packbit opcode\n");
-- 
2.9.3

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


Re: [FFmpeg-devel] minterpolate filter

2017-02-22 Thread Paul B Mahol
On 2/22/17, Ural  wrote:
> Hello all. First, thanks for doing great and hard work. I can't imagine
> any video-(pre/post)processing exist without ffmpeg.
> I am posting my question in devel, because I am not asking how to do
> something. What I am trying to do works, but bad.
>

Maybe perhaps if one provide some kind of bounty.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Using avfilter to watermark a video stream

2017-02-22 Thread Jesse Liu
Hello, Can anyone tell me where I can get the patch? Thanks a lot!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avcodec/dnxhddec: fix decoding of DNxHR HQX 10-bit

2017-02-22 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavcodec/dnxhddec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 70ce264..cdbc0bc 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -435,7 +435,7 @@ static int dnxhd_decode_dct_block_8(const DNXHDContext *ctx,
 static int dnxhd_decode_dct_block_10(const DNXHDContext *ctx,
  RowContext *row, int n)
 {
-return dnxhd_decode_dct_block(ctx, row, n, 6, 8, 4, 0);
+return dnxhd_decode_dct_block(ctx, row, n, 6, 32, 6, 0);
 }
 
 static int dnxhd_decode_dct_block_10_444(const DNXHDContext *ctx,
-- 
2.9.3

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


Re: [FFmpeg-devel] [PATCH] avcodec/dnxhddec: fix decoding of DNxHR HQX 10-bit

2017-02-22 Thread Paul B Mahol
On 2/22/17, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/dnxhddec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
> index 70ce264..cdbc0bc 100644
> --- a/libavcodec/dnxhddec.c
> +++ b/libavcodec/dnxhddec.c
> @@ -435,7 +435,7 @@ static int dnxhd_decode_dct_block_8(const DNXHDContext
> *ctx,
>  static int dnxhd_decode_dct_block_10(const DNXHDContext *ctx,
>   RowContext *row, int n)
>  {
> -return dnxhd_decode_dct_block(ctx, row, n, 6, 8, 4, 0);
> +return dnxhd_decode_dct_block(ctx, row, n, 6, 32, 6, 0);
>  }
>
>  static int dnxhd_decode_dct_block_10_444(const DNXHDContext *ctx,
> --
> 2.9.3
>
>

File can be found here:
https://drive.google.com/open?id=0B1hdyiz226iBV1llcDl3LW80U2c
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/h264_ps: Check chroma_qp_index_offset

2017-02-22 Thread Paul B Mahol
On 2/22/17, Michael Niedermayer  wrote:
> Fixes: 647/clusterfuzz-testcase-5195745823031296
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/h264_ps.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
> index 8090178395..f4a4a01fbe 100644
> --- a/libavcodec/h264_ps.c
> +++ b/libavcodec/h264_ps.c
> @@ -828,6 +828,12 @@ int ff_h264_decode_picture_parameter_set(GetBitContext
> *gb, AVCodecContext *avct
>  pps->init_qp  = get_se_golomb(gb) + 26 +
> qp_bd_offset;
>  pps->init_qs  = get_se_golomb(gb) + 26 +
> qp_bd_offset;
>  pps->chroma_qp_index_offset[0]= get_se_golomb(gb);
> +if (pps->chroma_qp_index_offset[0] < -12 ||
> pps->chroma_qp_index_offset[0] > 12) {
> +av_log(avctx, AV_LOG_ERROR, "chroma_qp_index_offset[0] %d is

This is nonsense. Please remove.

> invalid\n", pps->chroma_qp_index_offset[0]);
> +ret = AVERROR_INVALIDDATA;
> +goto fail;
> +}
> +
>  pps->deblocking_filter_parameters_present = get_bits1(gb);
>  pps->constrained_intra_pred   = get_bits1(gb);
>  pps->redundant_pic_cnt_present= get_bits1(gb);
> @@ -845,6 +851,11 @@ int ff_h264_decode_picture_parameter_set(GetBitContext
> *gb, AVCodecContext *avct
>  pps->scaling_matrix4,
> pps->scaling_matrix8);
>  // second_chroma_qp_index_offset
>  pps->chroma_qp_index_offset[1] = get_se_golomb(gb);
> +if (pps->chroma_qp_index_offset[1] < -12 ||
> pps->chroma_qp_index_offset[1] > 12) {
> +av_log(avctx, AV_LOG_ERROR, "chroma_qp_index_offset[1] %d is
> invalid\n", pps->chroma_qp_index_offset[1]);

ditto.

> +ret = AVERROR_INVALIDDATA;
> +goto fail;
> +}
>  } else {
>  pps->chroma_qp_index_offset[1] = pps->chroma_qp_index_offset[0];
>  }
> --
> 2.11.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Having log message for every error case would make ffmpeg binary very
big and slow.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add ffmpeg-security alias members

2017-02-22 Thread Michael Niedermayer
On Fri, Feb 10, 2017 at 08:55:26PM +0100, Michael Niedermayer wrote:

> Iam listing the reason for each, this is mostly my oppinion and i didnt ask 
> most
> if they agree with the listed reason to be listed with their name, so its 
> largly
> my oppinion. Which is why i will remove the reasons before pushing i just 
> added them
> to be transparent on this but as said its mostly my oppinion, i just talked
> with ubitux and noone else ...

changes made as described previously and pushed


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

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


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


[FFmpeg-devel] [PATCH] avcodec/h264_ps: Check chroma_qp_index_offset

2017-02-22 Thread Michael Niedermayer
Fixes: 647/clusterfuzz-testcase-5195745823031296

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

diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 8090178395..f4a4a01fbe 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -828,6 +828,12 @@ int ff_h264_decode_picture_parameter_set(GetBitContext 
*gb, AVCodecContext *avct
 pps->init_qp  = get_se_golomb(gb) + 26 + 
qp_bd_offset;
 pps->init_qs  = get_se_golomb(gb) + 26 + 
qp_bd_offset;
 pps->chroma_qp_index_offset[0]= get_se_golomb(gb);
+if (pps->chroma_qp_index_offset[0] < -12 || pps->chroma_qp_index_offset[0] 
> 12) {
+av_log(avctx, AV_LOG_ERROR, "chroma_qp_index_offset[0] %d is 
invalid\n", pps->chroma_qp_index_offset[0]);
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
+
 pps->deblocking_filter_parameters_present = get_bits1(gb);
 pps->constrained_intra_pred   = get_bits1(gb);
 pps->redundant_pic_cnt_present= get_bits1(gb);
@@ -845,6 +851,11 @@ int ff_h264_decode_picture_parameter_set(GetBitContext 
*gb, AVCodecContext *avct
 pps->scaling_matrix4, pps->scaling_matrix8);
 // second_chroma_qp_index_offset
 pps->chroma_qp_index_offset[1] = get_se_golomb(gb);
+if (pps->chroma_qp_index_offset[1] < -12 || 
pps->chroma_qp_index_offset[1] > 12) {
+av_log(avctx, AV_LOG_ERROR, "chroma_qp_index_offset[1] %d is 
invalid\n", pps->chroma_qp_index_offset[1]);
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
 } else {
 pps->chroma_qp_index_offset[1] = pps->chroma_qp_index_offset[0];
 }
-- 
2.11.0

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


[FFmpeg-devel] minterpolate filter

2017-02-22 Thread Ural
Hello all. First, thanks for doing great and hard work. I can't imagine
any video-(pre/post)processing exist without ffmpeg.
I am posting my question in devel, because I am not asking how to do
something. What I am trying to do works, but bad.

I create videos from pictures and need to make them as smooth as
possible. I found, that what I need called 'motion interpolation'. I
started to search all forums, and found only 3 things can help me:
slowmovideo, butterflow and new ffmpeg's filter minterpolate.


slowmovideo needs many configuration, I was not able to get it to work
as I want. with butterflow, I tried anything. From installing OpenCL,
OpenGL and other stuff to switching to nvidia binary drivers and
installing all sdk tools and cuda. It never worked. Some error about
cuda, and google don't know about it.


So third option was the only one available. When I tried it, it did
exactly what I want! But it is incredibly SLOW. I have 8-core CPU, and
it processes about 0.1-0.3 fps. And uses just 1 CORE, no video card.

Guys, do you have some plans about this awesome filter? Like to port it
to opencl, or use at least all cores? There are no any option available,
so all hopes only to this filter. Or maybe some other
alternatives/patches exist?

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