date:20171228

Hi/2.

Derek Buitenhuis wrote:
> On 12/28/2017 2:44 PM, KO Myung-Hun wrote:
>> On OS/2, '_' is not prepended to a function name.
>> ---
>>  configure | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> It's not immediately clear to be how checking a header instead relates
> to function name mangling (or lack thereof)?

Sorry about that.

SDL2 uses SDLCALL to specify a calling convention. On OS/2, it's defined
to `_System' which is similar to `_cdecl' but does not prepend '_'.

After all, without a header, a function is used without `_System'. And
linker will try to `_func' but fail because the function is `func' not
`_func'.

-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM

Korean OS/2 User Community : http://www.os2.kr/

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

Re: [FFmpeg-devel] [PATCH] compat/os2threads: support static mutexes

Hi/2.

wm4 wrote:
> On Thu, 28 Dec 2017 22:03:56 +0900
> KO Myung-Hun  wrote:
> 
>> ---
>>  compat/os2threads.h | 14 --
>>  1 file changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/compat/os2threads.h b/compat/os2threads.h
>> index 40a119ffe1..2177a033ec 100644
>> --- a/compat/os2threads.h
>> +++ b/compat/os2threads.h
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 2011 KO Myung-Hun 
>> + * Copyright (c) 2011-2017 KO Myung-Hun 
>>   *
>>   * This file is part of FFmpeg.
>>   *
>> @@ -46,9 +46,11 @@ typedef struct {
>>  
>>  typedef void pthread_attr_t;
>>  
>> -typedef HMTX pthread_mutex_t;
>> +typedef _fmutex pthread_mutex_t;
>>  typedef void pthread_mutexattr_t;
>>  
>> +#define PTHREAD_MUTEX_INITIALIZER _FMUTEX_INITIALIZER
>> +
>>  typedef struct {
>>  HEV event_sem;
>>  HEV ack_sem;
>> @@ -98,28 +100,28 @@ static av_always_inline int pthread_join(pthread_t 
>> thread, void **value_ptr)
>>  static av_always_inline int pthread_mutex_init(pthread_mutex_t *mutex,
>> const pthread_mutexattr_t 
>> *attr)
>>  {
>> -DosCreateMutexSem(NULL, (PHMTX)mutex, 0, FALSE);
>> +_fmutex_create(mutex, 0);
>>  
>>  return 0;
>>  }
>>  
>>  static av_always_inline int pthread_mutex_destroy(pthread_mutex_t *mutex)
>>  {
>> -DosCloseMutexSem(*(PHMTX)mutex);
>> +_fmutex_close(mutex);
>>  
>>  return 0;
>>  }
>>  
>>  static av_always_inline int pthread_mutex_lock(pthread_mutex_t *mutex)
>>  {
>> -DosRequestMutexSem(*(PHMTX)mutex, SEM_INDEFINITE_WAIT);
>> +_fmutex_request(mutex, 0);
>>  
>>  return 0;
>>  }
>>  
>>  static av_always_inline int pthread_mutex_unlock(pthread_mutex_t *mutex)
>>  {
>> -DosReleaseMutexSem(*(PHMTX)mutex);
>> +_fmutex_release(mutex);
>>  
>>  return 0;
>>  }
> 
> LGTM. Does this actually switch to futex-like light weight mutexes? (I
> don't know anything about OS/2, but it does sound like PHMTX was the
> equivalent of a win32 HANDLE mutex kernel object, that required kernel
> entry on each lock/unlock, while _fmutex is possibly like Vista+ SRWs.)

_fmutex is not futex-like light-weight mutex. Unlike HMTX, however,
_fmutex supports static mutexes.

-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM

Korean OS/2 User Community : http://www.os2.kr/

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

Re: [FFmpeg-devel] [PATCH] h264: add AVOption to set x264_build default

On 12/28/2017 10:19 PM, Carl Eugen Hoyos wrote:
> I care much less about what he says (did he really talk to you?) or
> writes, more about what he does.

For the record: Nobody talked to me. There is no conspiracy.

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

Re: [FFmpeg-devel] [MSVC toolchain] Patch to allow building FFmpeg with Linux bash on Windows (WSL)

2017-12-28 Thread Aaron Levinson

On 12/28/2017 6:43 PM, Cyber Sinh wrote:

The attached patch changes the configure script for FFmpeg (and associated
shell scripts) to call MSVC tools including their extensions (cl.exe instead
of cl for example). This is necessary, because WSL can automatically launch
Windows processes from the Linux side but only if the process is in the path
and includes the full name. Linux doesn't automatically append .exe and such
to invoke a file.

I haven't confirmed yet that this works in the msys2 environment on
Windows, although according to
https://blogs.msdn.microsoft.com/gillesk/2016/12/02/building-ffmpeg-using-wsl/
, it supposedly shouldn't cause any issues with building under msys2 or WSL.

It appears all of the contents of this patch have been taken from
another patch, available at
https://github.com/Microsoft/FFmpegInterop/blob/gillesk/wsl/0001-Updating-scripts-to-run-under-WSL.patch
, although its reasonable that the author of this patch would have come
up with it on their own since it is so simple. It would be reasonable
to give credit to Gilles Khouzam in the patch description, if the author
of this patch (Cyber Sinh) and Gilles Khouzam are not the same individual.

Also, Gilles's patch does more to get FFmpeg to build properly under
WSL, so just adding the file extension may not be sufficient to get
FFmpeg to build under WSL.

On a separate note, building under WSL, as opposed to msys2, seems
promising if only from a build performance perspective. According to
the blog post, it builds at least twice as fast under WSL than it does
with msys2.

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

Re: [FFmpeg-devel] [PATCH] avfilter/vidstab: set bytesPerPixel only for packed formats.

On Thu, Dec 28, 2017 at 12:50:00PM -0900, Lou Logan wrote:
> On Thu, Dec 28, 2017, at 11:51 AM, Michael Niedermayer wrote:
> >
> > who maintains vf_vidstabtransform.c ?
> 
> Realistically, nobody. Ideally, should have been Georg Martius who is the 
> original author of the filter and also of vid.stab itself. Consider CCing him 
> at "martius at mis.mpg.de" or "georg.martius at web.de".

ok, cc added

Georg, do you want to maintain vf_vidstabtransform.c ?

If not, who wants to maintain vf_vidstabtransform.c ?

If noone then iam not sure who will test or apply this, i think many
dont have the dependancy installed ...

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu

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

[FFmpeg-devel] [MSVC toolchain] Patch to allow building FFmpeg with Linux bash on Windows (WSL)

2017-12-28 Thread Cyber Sinh

The attached patch changes the configure script for FFmpeg (and associated
shell scripts) to call MSVC tools including their extensions (cl.exe instead
of cl for example). This is necessary, because WSL can automatically launch
Windows processes from the Linux side but only if the process is in the path
and includes the full name. Linux doesn't automatically append .exe and such
to invoke a file.



build_with_wsl.diff
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] PR new filter gltransition

2017-12-28 Thread Rostislav Pehlivanov

On 27 December 2017 at 23:13, Travis Fischer  wrote:

> Hello,
>
> This is my first time contributing to ffmpeg, so please go easy on me :)
>
> I have a git diff here
>  which add a
> new filter to apply a GLSL transition between two video streams.  The
> github repo for this patch includes all of the relevant documentation and
> usage examples.
>
> (sorry, I'm not sure how to formally define the patch, as I'm used to just
> submitting PRs on github)
>
> I created this filter because of my frustration with how difficult and
> limited the *transition* possibilities were with current concat filter
> chains. Anything aside from basic video cross-fades isn't really possible.
>
> After releasing the filter as a standalone extension and seeing some other
> devs adopt it, I received a lot of feedback that this functionality should
> be merged info ffmpeg, so I wanted to get the ball rolling and see what
> everyone thinks on this list.
>
> Thanks!
> -- Travis Fischer 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

I don't see the point of such a filter. Redundant. We already have a
properly implemented OpenCL filter support (and there's a patch to make it
accept generic kernels). This is a quick hack which requires 2 copies and
that's slow and inefficient.
Instead, how about a tutorial on how to convert glsl to opencl kernels?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/exr: Check buf_size more completely

Fixes: Out of heap array read
Fixes: 4683/clusterfuzz-testcase-minimized-6152313673613312

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

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index b1ecde4ebd..454dc74cfb 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -1051,7 +1051,7 @@ static int decode_block(AVCodecContext *avctx, void 
*tdata,
 line_offset = AV_RL64(s->gb.buffer + jobnr * 8);
 
 if (s->is_tile) {
-if (line_offset > buf_size - 20)
+if (buf_size < 20 || line_offset > buf_size - 20)
 return AVERROR_INVALIDDATA;
 
 src  = buf + line_offset + 20;
@@ -1062,7 +1062,7 @@ static int decode_block(AVCodecContext *avctx, void 
*tdata,
 tile_level_y = AV_RL32(src - 8);
 
 data_size = AV_RL32(src - 4);
-if (data_size <= 0 || data_size > buf_size)
+if (data_size <= 0 || data_size > buf_size - line_offset - 20)
 return AVERROR_INVALIDDATA;
 
 if (tile_level_x || tile_level_y) { /* tile level, is not the full res 
level */
@@ -1095,7 +1095,7 @@ static int decode_block(AVCodecContext *avctx, void 
*tdata,
 td->channel_line_size = td->xsize * s->current_channel_offset;/* 
uncompress size of one line */
 uncompressed_size = td->channel_line_size * (uint64_t)td->ysize;/* 
uncompress size of the block */
 } else {
-if (line_offset > buf_size - 8)
+if (buf_size < 8 || line_offset > buf_size - 8)
 return AVERROR_INVALIDDATA;
 
 src  = buf + line_offset + 8;
@@ -1105,7 +1105,7 @@ static int decode_block(AVCodecContext *avctx, void 
*tdata,
 return AVERROR_INVALIDDATA;
 
 data_size = AV_RL32(src - 4);
-if (data_size <= 0 || data_size > buf_size)
+if (data_size <= 0 || data_size > buf_size - line_offset - 8)
 return AVERROR_INVALIDDATA;
 
 td->ysize  = FFMIN(s->scan_lines_per_block, s->ymax - line + 
1); /* s->ydelta - line ?? */
-- 
2.15.1

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

[FFmpeg-devel] [PATCH v2] libavcodec/mediacodecdec: switch to new decoder api

2017-12-28 Thread Aman Gupta

From: Aman Gupta 

Using the new API gives the decoder the ability to produce
N frames per input packet. This is particularly useful with
mpeg2 decoders on some android devices, which automatically
deinterlace video and produce one frame per field.

Signed-off-by: Aman Gupta 
---
 libavcodec/mediacodecdec.c | 77 +++---
 1 file changed, 45 insertions(+), 32 deletions(-)

diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index b698ceaef9..90497c64da 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -31,6 +31,7 @@
 #include "libavutil/pixfmt.h"
 
 #include "avcodec.h"
+#include "decode.h"
 #include "h264_parse.h"
 #include "hevc_parse.h"
 #include "hwaccel.h"
@@ -424,29 +425,13 @@ static int mediacodec_process_data(AVCodecContext *avctx, 
AVFrame *frame,
 return ff_mediacodec_dec_decode(avctx, s->ctx, frame, got_frame, pkt);
 }
 
-static int mediacodec_decode_frame(AVCodecContext *avctx, void *data,
-   int *got_frame, AVPacket *avpkt)
+static int mediacodec_receive_frame(AVCodecContext *avctx, AVFrame *frame)
 {
 MediaCodecH264DecContext *s = avctx->priv_data;
-AVFrame *frame= data;
 int ret;
-
-/* buffer the input packet */
-if (avpkt->size) {
-AVPacket input_pkt = { 0 };
-
-if (av_fifo_space(s->fifo) < sizeof(input_pkt)) {
-ret = av_fifo_realloc2(s->fifo,
-   av_fifo_size(s->fifo) + sizeof(input_pkt));
-if (ret < 0)
-return ret;
-}
-
-ret = av_packet_ref(_pkt, avpkt);
-if (ret < 0)
-return ret;
-av_fifo_generic_write(s->fifo, _pkt, sizeof(input_pkt), NULL);
-}
+int got_frame = 0;
+int is_eof = 0;
+AVPacket pkt = {0};
 
 /*
  * MediaCodec.flush() discards both input and output buffers, thus we
@@ -470,26 +455,51 @@ static int mediacodec_decode_frame(AVCodecContext *avctx, 
void *data,
  */
 if (ff_mediacodec_dec_is_flushing(avctx, s->ctx)) {
 if (!ff_mediacodec_dec_flush(avctx, s->ctx)) {
-return avpkt->size;
+return 0;
 }
+return AVERROR(EAGAIN);
+}
+
+ret = ff_decode_get_packet(avctx, );
+if (ret == AVERROR_EOF)
+is_eof = 1;
+else if (ret == AVERROR(EAGAIN))
+; // no input packet, but fallthrough to check for pending frames
+else if (ret < 0)
+return ret;
+
+/* buffer the input packet */
+if (pkt.size) {
+if (av_fifo_space(s->fifo) < sizeof(pkt)) {
+ret = av_fifo_realloc2(s->fifo,
+   av_fifo_size(s->fifo) + sizeof(pkt));
+if (ret < 0) {
+av_packet_unref();
+return ret;
+}
+}
+av_fifo_generic_write(s->fifo, , sizeof(pkt), NULL);
 }
 
 /* process buffered data */
-while (!*got_frame) {
+while (!got_frame) {
 /* prepare the input data */
 if (s->buffered_pkt.size <= 0) {
 av_packet_unref(>buffered_pkt);
 
 /* no more data */
 if (av_fifo_size(s->fifo) < sizeof(AVPacket)) {
-return avpkt->size ? avpkt->size :
-ff_mediacodec_dec_decode(avctx, s->ctx, frame, got_frame, 
avpkt);
+AVPacket null_pkt = {0};
+if (is_eof)
+return ff_mediacodec_dec_decode(avctx, s->ctx, frame,
+_frame, _pkt);
+return AVERROR(EAGAIN);
 }
 
 av_fifo_generic_read(s->fifo, >buffered_pkt, 
sizeof(s->buffered_pkt), NULL);
 }
 
-ret = mediacodec_process_data(avctx, frame, got_frame, 
>buffered_pkt);
+ret = mediacodec_process_data(avctx, frame, _frame, 
>buffered_pkt);
 if (ret < 0)
 return ret;
 
@@ -497,7 +507,10 @@ static int mediacodec_decode_frame(AVCodecContext *avctx, 
void *data,
 s->buffered_pkt.data += ret;
 }
 
-return avpkt->size;
+if (got_frame)
+return 0;
+
+return AVERROR(EAGAIN);
 }
 
 static void mediacodec_decode_flush(AVCodecContext *avctx)
@@ -537,7 +550,7 @@ AVCodec ff_h264_mediacodec_decoder = {
 .id = AV_CODEC_ID_H264,
 .priv_data_size = sizeof(MediaCodecH264DecContext),
 .init   = mediacodec_decode_init,
-.decode = mediacodec_decode_frame,
+.receive_frame  = mediacodec_receive_frame,
 .flush  = mediacodec_decode_flush,
 .close  = mediacodec_decode_close,
 .capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING | 
AV_CODEC_CAP_HARDWARE,
@@ -556,7 +569,7 @@ AVCodec ff_hevc_mediacodec_decoder = {
 .id = AV_CODEC_ID_HEVC,
 .priv_data_size = sizeof(MediaCodecH264DecContext),
 .init   = mediacodec_decode_init,
-.decode =

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

2017-11-26 15:10 GMT+01:00 Nicolas George :

> -> our code depends on pthreads for this filters, it must be expressed
> in configure: Carl Eugen's patch is right

Pushed with pthreads, as this is currently used.

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

Re: [FFmpeg-devel] [PATCH]lavf/mov: Do not blindly allocate stts entries

2017-11-28 21:32 GMT+01:00 Michael Niedermayer :
> On Mon, Nov 27, 2017 at 05:24:14AM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch avoids allocations >1GB for (short and) invalid mov
>> files with only reasonable speed impact.
>>
>> Please review, Carl Eugen
>
>>  mov.c |   16 +---
>>  1 file changed, 13 insertions(+), 3 deletions(-)
>> 980861e4c47c80c850d4e849043df2510a3d1d32  
>> 0001-lavf-mov-Do-not-blindly-allocate-huge-memory-blocks-.patch
>> From 0d243bad5fdd9850ff41d49a32a06274a3cd9756 Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Mon, 27 Nov 2017 05:13:25 +0100
>> Subject: [PATCH] lavf/mov: Do not blindly allocate huge memory blocks for
>>  stts entries.
>>
>> Fixes large allocations for short files with invalid stts entry.
>> Fixes bugzilla 1102.
>> ---
>>  libavformat/mov.c |   16 +---
>>  1 file changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index ddb1e59..9d353bf 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -2838,14 +2838,24 @@ static int mov_read_stts(MOVContext *c, AVIOContext 
>> *pb, MOVAtom atom)
>>  if (sc->stts_data)
>>  av_log(c->fc, AV_LOG_WARNING, "Duplicated STTS atom\n");
>>  av_free(sc->stts_data);
>> -sc->stts_count = 0;
>> -sc->stts_data = av_malloc_array(entries, sizeof(*sc->stts_data));
>> +sc->stts_count = FFMIN(1024 * 1024, entries);
>> +sc->stts_data = av_realloc_array(NULL, sc->stts_count, 
>> sizeof(*sc->stts_data));
>>  if (!sc->stts_data)
>>  return AVERROR(ENOMEM);
>
> i dont know if leaving stts_count random on return is a good idea

Fixed.

>>  for (i = 0; i < entries && !pb->eof_reached; i++) {
>> -int sample_duration;
>> +int sample_duration, ret;
>>  unsigned int sample_count;
>> +if (i > sc->stts_count) {
>> +ret = av_reallocp_array(>stts_data,
>> +FFMIN(sc->stts_count * 2LL, entries),
>> +sizeof(*sc->stts_data));
>
> this should use a variant of av_fast_realloc

New patch attached, only tested with fate.

Thank you, Carl Eugen
From 85620d03b313f5a684a5e9c06e445180601592f5 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Fri, 29 Dec 2017 02:08:48 +0100
Subject: [PATCH] lavf/mov: Do not blindly allocate huge memory blocks for
 stts entries.

Fixes large allocations for short files with invalid stts entry.
Fixes bugzilla 1102.
---
 libavformat/mov.c |   23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2064473..df7a40f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2849,14 +2849,29 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 if (sc->stts_data)
 av_log(c->fc, AV_LOG_WARNING, "Duplicated STTS atom\n");
 av_free(sc->stts_data);
-sc->stts_count = 0;
-sc->stts_data = av_malloc_array(entries, sizeof(*sc->stts_data));
-if (!sc->stts_data)
+if (INT_MAX / sizeof(*sc->stts_data) <= entries)
 return AVERROR(ENOMEM);
+sc->stts_count = FFMIN(1024 * 1024, entries);
+sc->stts_data = av_realloc_array(NULL, sc->stts_count, sizeof(*sc->stts_data));
+if (!sc->stts_data) {
+sc->stts_count = 0;
+return AVERROR(ENOMEM);
+}
 
 for (i = 0; i < entries && !pb->eof_reached; i++) {
 int sample_duration;
-unsigned int sample_count;
+unsigned int sample_count, alloc_size = sc->stts_count * sizeof(*sc->stts_data);
+if (i > sc->stts_count) {
+MOVStts *stts_data = av_fast_realloc(sc->stts_data, _size,
+ FFMIN(sc->stts_count * 2LL, entries) * sizeof(*sc->stts_data));
+if (!stts_data) {
+av_freep(>stts_data);
+sc->stts_count = 0;
+return AVERROR(ENOMEM);
+}
+sc->stts_count = FFMIN(sc->stts_count * 2, entries);
+sc->stts_data = stts_data;
+}
 
 sample_count=avio_rb32(pb);
 sample_duration = avio_rb32(pb);
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH] libavcodec/mediacodecdec: update to use new decoding api

2017-12-28 Thread Aman Gupta

From: Aman Gupta 

---
 libavcodec/mediacodecdec.c | 75 ++
 1 file changed, 43 insertions(+), 32 deletions(-)

diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index b698ceaef9..29f1076bb0 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -31,6 +31,7 @@
 #include "libavutil/pixfmt.h"
 
 #include "avcodec.h"
+#include "decode.h"
 #include "h264_parse.h"
 #include "hevc_parse.h"
 #include "hwaccel.h"
@@ -424,29 +425,12 @@ static int mediacodec_process_data(AVCodecContext *avctx, 
AVFrame *frame,
 return ff_mediacodec_dec_decode(avctx, s->ctx, frame, got_frame, pkt);
 }
 
-static int mediacodec_decode_frame(AVCodecContext *avctx, void *data,
-   int *got_frame, AVPacket *avpkt)
+static int mediacodec_receive_frame(AVCodecContext *avctx, AVFrame *frame)
 {
 MediaCodecH264DecContext *s = avctx->priv_data;
-AVFrame *frame= data;
 int ret;
-
-/* buffer the input packet */
-if (avpkt->size) {
-AVPacket input_pkt = { 0 };
-
-if (av_fifo_space(s->fifo) < sizeof(input_pkt)) {
-ret = av_fifo_realloc2(s->fifo,
-   av_fifo_size(s->fifo) + sizeof(input_pkt));
-if (ret < 0)
-return ret;
-}
-
-ret = av_packet_ref(_pkt, avpkt);
-if (ret < 0)
-return ret;
-av_fifo_generic_write(s->fifo, _pkt, sizeof(input_pkt), NULL);
-}
+int got_frame = 0, pkt_size = 0;
+AVPacket pkt = {0}, *avpkt = 
 
 /*
  * MediaCodec.flush() discards both input and output buffers, thus we
@@ -470,26 +454,50 @@ static int mediacodec_decode_frame(AVCodecContext *avctx, 
void *data,
  */
 if (ff_mediacodec_dec_is_flushing(avctx, s->ctx)) {
 if (!ff_mediacodec_dec_flush(avctx, s->ctx)) {
-return avpkt->size;
+return 0;
+}
+return AVERROR(EAGAIN);
+}
+
+ret = ff_decode_get_packet(avctx, avpkt);
+if (ret < 0 && ret != AVERROR_EOF)
+return ret;
+pkt_size = avpkt->size;
+
+/* buffer the input packet */
+if (avpkt->size) {
+AVPacket input_pkt = { 0 };
+
+if (av_fifo_space(s->fifo) < sizeof(input_pkt)) {
+ret = av_fifo_realloc2(s->fifo,
+   av_fifo_size(s->fifo) + sizeof(input_pkt));
+if (ret < 0)
+return ret;
 }
+
+ret = av_packet_ref(_pkt, avpkt);
+if (ret < 0)
+return ret;
+av_fifo_generic_write(s->fifo, _pkt, sizeof(input_pkt), NULL);
 }
+av_packet_unref(avpkt);
 
 /* process buffered data */
-while (!*got_frame) {
+while (!got_frame) {
 /* prepare the input data */
 if (s->buffered_pkt.size <= 0) {
 av_packet_unref(>buffered_pkt);
 
 /* no more data */
 if (av_fifo_size(s->fifo) < sizeof(AVPacket)) {
-return avpkt->size ? avpkt->size :
-ff_mediacodec_dec_decode(avctx, s->ctx, frame, got_frame, 
avpkt);
+return pkt_size ? AVERROR(EAGAIN) :
+ff_mediacodec_dec_decode(avctx, s->ctx, frame, _frame, 
avpkt);
 }
 
 av_fifo_generic_read(s->fifo, >buffered_pkt, 
sizeof(s->buffered_pkt), NULL);
 }
 
-ret = mediacodec_process_data(avctx, frame, got_frame, 
>buffered_pkt);
+ret = mediacodec_process_data(avctx, frame, _frame, 
>buffered_pkt);
 if (ret < 0)
 return ret;
 
@@ -497,7 +505,10 @@ static int mediacodec_decode_frame(AVCodecContext *avctx, 
void *data,
 s->buffered_pkt.data += ret;
 }
 
-return avpkt->size;
+if (got_frame)
+return 0;
+
+return AVERROR(EAGAIN);
 }
 
 static void mediacodec_decode_flush(AVCodecContext *avctx)
@@ -537,7 +548,7 @@ AVCodec ff_h264_mediacodec_decoder = {
 .id = AV_CODEC_ID_H264,
 .priv_data_size = sizeof(MediaCodecH264DecContext),
 .init   = mediacodec_decode_init,
-.decode = mediacodec_decode_frame,
+.receive_frame  = mediacodec_receive_frame,
 .flush  = mediacodec_decode_flush,
 .close  = mediacodec_decode_close,
 .capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING | 
AV_CODEC_CAP_HARDWARE,
@@ -556,7 +567,7 @@ AVCodec ff_hevc_mediacodec_decoder = {
 .id = AV_CODEC_ID_HEVC,
 .priv_data_size = sizeof(MediaCodecH264DecContext),
 .init   = mediacodec_decode_init,
-.decode = mediacodec_decode_frame,
+.receive_frame  = mediacodec_receive_frame,
 .flush  = mediacodec_decode_flush,
 .close  = mediacodec_decode_close,
 .capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING | 
AV_CODEC_CAP_HARDWARE,
@@ -575,7 +586,7 @@ AVCodec ff_mpeg2_mediacodec_decoder = {
 .id =

Re: [FFmpeg-devel] [PATCH] h264: add AVOption to set x264_build default

2017-12-28 Thread Hendrik Leppkes

On Thu, Dec 28, 2017 at 11:19 PM, Carl Eugen Hoyos  wrote:
> 2017-12-28 16:43 GMT+01:00 Derek Buitenhuis :
>> On 12/28/2017 12:44 AM, Carl Eugen Hoyos wrote:
 out of nowhere without being provoked is not a welcome behavior at all.
>>>
>>> That doesn't sound correct to me.
>>
>> He literally said nothing to you on this thread before you insulted him.
>
> I care much less about what he says (did he really talk to you?) or
> writes, more about what he does.
>

You have also not commented on any behavior, but directly went to
insults. And apparently you don't recognize that you are violating
various rules here.
As others have said, cut it out.

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

Re: [FFmpeg-devel] [PATCH] h264: add AVOption to set x264_build default

2017-12-28 16:43 GMT+01:00 Derek Buitenhuis :
> On 12/28/2017 12:44 AM, Carl Eugen Hoyos wrote:
>>> out of nowhere without being provoked is not a welcome behavior at all.
>>
>> That doesn't sound correct to me.
>
> He literally said nothing to you on this thread before you insulted him.

I care much less about what he says (did he really talk to you?) or
writes, more about what he does.

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

Re: [FFmpeg-devel] [PATCH] reinterlace filter

2017-12-28 13:52 GMT+01:00 Vasile Toncu :

> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 8916588..b2e9a50 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -213,6 +213,7 @@ OBJS-$(CONFIG_PULLUP_FILTER) += 
> vf_pullup.o
>  OBJS-$(CONFIG_QP_FILTER) += vf_qp.o
>  OBJS-$(CONFIG_RANDOM_FILTER) += vf_random.o
>  OBJS-$(CONFIG_REALTIME_FILTER)   += f_realtime.o
> +OBJS-$(CONFIG_REINTERLACE_FILTER)+= vf_reinterlace.o
>  OBJS-$(CONFIG_REMOVEGRAIN_FILTER)+= vf_removegrain.o
>  OBJS-$(CONFIG_REMOVELOGO_FILTER) += bbox.o lswsutils.o 
> lavfutils.o vf_removelogo.o
>  OBJS-$(CONFIG_REPEATFIELDS_FILTER)   += vf_repeatfields.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index fa7d304..5333ac1 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -233,6 +233,7 @@ void avfilter_register_all(void)
>  REGISTER_FILTER(QP, qp, vf);
>  REGISTER_FILTER(RANDOM, random, vf);
>  REGISTER_FILTER(REALTIME,   realtime,   vf);
> +REGISTER_FILTER(REINTERLACE,reinterlace,vf);
>  REGISTER_FILTER(REMOVEGRAIN,removegrain,vf);
>  REGISTER_FILTER(REMOVELOGO, removelogo, vf);
>  REGISTER_FILTER(REPEATFIELDS,   repeatfields,   vf);

These changes do not apply.

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

Re: [FFmpeg-devel] [PATCH] added reitnerlace filter

2017-12-28 16:12 GMT+01:00 Vasile Toncu :

> Is there anything that I can do to the current version of reinterlace
> so that the filter can be accepted?

Wasn't this already explained?
Add the existing (GPL'd) asm optimizations to your new filter (and
make sure the filter works both with and without --enable-gpl).

Or do I miss something?

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

Re: [FFmpeg-devel] Licensing question.

2017-12-27 22:17 GMT+01:00 Lewis Hornsby :
> I would like to include libffmpeg.dylib in the application.

Please read http://ffmpeg.org/legal.html or post your license
questions on the user mailing list, do not top-post there!

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

Re: [FFmpeg-devel] PR new filter gltransition

2017-12-28 0:13 GMT+01:00 Travis Fischer :

> This is my first time contributing to ffmpeg, so please go easy on me :)
>
> I have a git diff here
> 

The new file needs a license header (please copy it from
another filter) and configure needs to check if the
necessary headers are available.
Commit locally and create a patch with "git format-patch"
and send it as an attachment to this mailing list to get a
review.

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

Re: [FFmpeg-devel] [PATCH] avfilter/vidstab: set bytesPerPixel only for packed formats.

2017-12-28 Thread Lou Logan

On Thu, Dec 28, 2017, at 11:51 AM, Michael Niedermayer wrote:
>
> who maintains vf_vidstabtransform.c ?

Realistically, nobody. Ideally, should have been Georg Martius who is the 
original author of the filter and also of vid.stab itself. Consider CCing him 
at "martius at mis.mpg.de" or "georg.martius at web.de".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vidstab: set bytesPerPixel only for packed formats.

On Thu, Dec 28, 2017 at 09:52:20AM +0530, Gyan Doshi wrote:
> On 12/24/2017 10:36 AM, Gyan Doshi wrote:
> >
> >On 12/23/2017 4:39 PM, Gyan Doshi wrote:
> >>Patch for ticket #6736.
> 
> Ping.

who maintains vf_vidstabtransform.c ?

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

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


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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/flacdec: avoid undefined shift

On Tue, Dec 26, 2017 at 11:24:43PM +0100, Michael Niedermayer wrote:
> Fixes: shift exponent 32 is too large for 32-bit type 'unsigned int'
> Fixes: 4688/clusterfuzz-testcase-minimized-6572210748653568
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/flacdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

patchset applied

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

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


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

Re: [FFmpeg-devel] [PATCH] Add android_capture indev

On Fri, Dec 22, 2017 at 09:36:59PM +0100, Felix Matouschek wrote:
> Am 22.12.2017 20:50, schrieb Lou Logan:
> >
> >I think you forgot to attach the patch.
> 
> Sorry, flaky mail client... attached it again.
[...]

> +static void image_available(void *context, AImageReader *reader)
> +{
> +AVFormatContext *avctx = context;
> +AndroidCameraCtx *ctx = avctx->priv_data;
> +media_status_t media_status;
> +int ret = 0;
> +
> +AImage *image;
> +int64_t image_timestamp;
> +int32_t image_linestrides[4];
> +uint8_t *image_plane_data[4];
> +int plane_data_length[4];
> +
> +AVPacket pkt;
> +int pkt_buffer_size = 0;
> +
> +media_status = AImageReader_acquireLatestImage(reader, );
> +if (media_status != AMEDIA_OK) {
> +if (media_status == AMEDIA_IMGREADER_NO_BUFFER_AVAILABLE) {
> +av_log(avctx, AV_LOG_WARNING,
> +   "An image reader frame was discarded");
> +} else {
> +av_log(avctx, AV_LOG_ERROR,
> +   "Failed to acquire latest image from image reader, error: 
> %s.\n",
> +   media_status_string(media_status));
> +ret = AVERROR_EXTERNAL;
> +}
> +goto error;
> +}
> +
> +// Silently drop frames when exit is set
> +if (atomic_load(>exit)) {
> +goto error;
> +}
> +
> +// Determine actual image format
> +if (!atomic_load(>got_image_format)) {
> +ret = get_image_format(avctx, image);
> +if (ret < 0) {
> +av_log(avctx, AV_LOG_ERROR,
> +   "Could not get image format of camera.\n");
> +goto error;
> +} else {
> +atomic_store(>got_image_format, 1);
> +}
> +}
> +
> +pkt_buffer_size = av_image_get_buffer_size(ctx->image_format, 
> ctx->width, ctx->height, 32);
> +AImage_getTimestamp(image, _timestamp);
> +
> +AImage_getPlaneRowStride(image, 0, _linestrides[0]);
> +AImage_getPlaneData(image, 0, _plane_data[0], 
> _data_length[0]);
> +
> +switch (ctx->image_format) {
> +case AV_PIX_FMT_YUV420P:
> +AImage_getPlaneRowStride(image, 1, _linestrides[1]);
> +AImage_getPlaneData(image, 1, _plane_data[1], 
> _data_length[1]);
> +AImage_getPlaneRowStride(image, 2, _linestrides[2]);
> +AImage_getPlaneData(image, 2, _plane_data[2], 
> _data_length[2]);
> +break;
> +case AV_PIX_FMT_NV12:
> +AImage_getPlaneRowStride(image, 1, _linestrides[1]);
> +AImage_getPlaneData(image, 1, _plane_data[1], 
> _data_length[1]);
> +break;
> +case AV_PIX_FMT_NV21:
> +AImage_getPlaneRowStride(image, 2, _linestrides[1]);
> +AImage_getPlaneData(image, 2, _plane_data[1], 
> _data_length[1]);
> +break;
> +default:
> +av_log(avctx, AV_LOG_ERROR, "Unsupported camera image 
> format.\n");
> +ret = AVERROR(ENOSYS);
> +goto error;
> +}
> +
> +ret = av_new_packet(, pkt_buffer_size);
> +if (ret < 0) {
> +av_log(avctx, AV_LOG_ERROR,
> +   "Failed to create new av packet, error: %s.\n", 
> av_err2str(ret));
> +goto error;
> +}
> +
> +pkt.stream_index = VIDEO_STREAM_INDEX;
> +pkt.pts = image_timestamp;
> +av_image_copy_to_buffer(pkt.data, pkt_buffer_size,
> +(const uint8_t * const *) image_plane_data,
> +image_linestrides, ctx->image_format,
> +ctx->width, ctx->height, 32);

Is the copy needed ?
can the data not be put in a AVPacket without copy but by pointing to the image?
the AVPackets deallocation can be overridden to free the image 
[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] Licensing question.

2017-12-28 Thread Lewis Hornsby

I would like to include libffmpeg.dylib in the application. FFMPEG is used only 
for previewing mp4 videos inside the application. 

Thanks for your time. Lewis


> On 27 Dec 2017, at 21:14, Lou Logan  wrote:
> 
> On Wed, 27 Dec 2017 19:48:52 +
> Lewis Hornsby  wrote:
> 
>> Hey there, I saw on your facebook page that you were giving out this
>> email address for enquiries regarding FFMPEG licensing.
>> 
>> I am developing a closed source application in NW.JS. It is a
>> Wordpress theme builder. There is a part of my application that lets
>> people browse their available media. I would like to know if for
>> something as simple as playback of an mp4 file in this context, I
>> would need a licence.   The application does not nor ever will
>> convert files.
>> 
>> Many thanks, Lewis Hornsby. 
> 
> Are you distributing anything from FFmpeg? How is FFmpeg involved in
> your application?
> 
> CCing as you are not currently subscribed. Check archives for possible
> other replies:
> 
> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/

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

[FFmpeg-devel] PR new filter gltransition

2017-12-28 Thread Travis Fischer

Hello,

This is my first time contributing to ffmpeg, so please go easy on me :)

I have a git diff here
 which add a
new filter to apply a GLSL transition between two video streams.  The
github repo for this patch includes all of the relevant documentation and
usage examples.

(sorry, I'm not sure how to formally define the patch, as I'm used to just
submitting PRs on github)

I created this filter because of my frustration with how difficult and
limited the *transition* possibilities were with current concat filter
chains. Anything aside from basic video cross-fades isn't really possible.

After releasing the filter as a standalone extension and seeing some other
devs adopt it, I received a lot of feedback that this functionality should
be merged info ffmpeg, so I wanted to get the ball rolling and see what
everyone thinks on this list.

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

Re: [FFmpeg-devel] [PATCH] lavr: deprecate the entire library

2017-12-28 Thread wm4

On Thu, 28 Dec 2017 13:25:45 -0300
James Almer  wrote:

> On 12/25/2017 2:53 PM, Rostislav Pehlivanov wrote:
> > diff --git a/libavresample/avresample.h b/libavresample/avresample.h
> > index 193443e2a6..57889c572c 100644
> > --- a/libavresample/avresample.h
> > +++ b/libavresample/avresample.h
> > @@ -103,10 +103,10 @@
> >  
> >  #define AVRESAMPLE_MAX_CHANNELS 32
> >  
> > -typedef struct AVAudioResampleContext AVAudioResampleContext;
> > +typedef attribute_deprecated struct AVAudioResampleContext 
> > AVAudioResampleContext;
> >  
> >  /** Mixing Coefficient Types */
> > -enum AVMixCoeffType {
> > +enum attribute_deprecated AVMixCoeffType {
> >  AV_MIX_COEFF_TYPE_Q8,   /** 16-bit 8.8 fixed-point 
> >  */
> >  AV_MIX_COEFF_TYPE_Q15,  /** 32-bit 17.15 fixed-point   
> >  */
> >  AV_MIX_COEFF_TYPE_FLT,  /** floating-point 
> >  */
> > @@ -114,13 +114,13 @@ enum AVMixCoeffType {
> >  };
> >  
> >  /** Resampling Filter Types */
> > -enum AVResampleFilterType {
> > +enum attribute_deprecated AVResampleFilterType {
> >  AV_RESAMPLE_FILTER_TYPE_CUBIC,  /**< Cubic */
> >  AV_RESAMPLE_FILTER_TYPE_BLACKMAN_NUTTALL,   /**< Blackman Nuttall 
> > Windowed Sinc */
> >  AV_RESAMPLE_FILTER_TYPE_KAISER, /**< Kaiser Windowed Sinc 
> > */
> >  };
> >  
> > -enum AVResampleDitherMethod {
> > +enum attribute_deprecated AVResampleDitherMethod {
> >  AV_RESAMPLE_DITHER_NONE,/**< Do not use dithering */
> >  AV_RESAMPLE_DITHER_RECTANGULAR, /**< Rectangular Dither */
> >  AV_RESAMPLE_DITHER_TRIANGULAR,  /**< Triangular Dither*/  
> 
> wm4 found out that deprecating enums does basically nothing. some
> compilers complain about the attribute, and others don't say anything at
> all (aka, not warn when the enum is being used). I don't know if that
> also applies to structs, but it might be a good idea to find out.
> 
> I'd say just add the deprecated attribute to functions as per usual.

I've put it before the enum keyword. I didn't check whether putting it
after the keyword helps. Might actually be worth investigating if we
need to deprecate enums more often.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavr: deprecate the entire library

2017-12-28 Thread James Almer

On 12/25/2017 2:53 PM, Rostislav Pehlivanov wrote:
> diff --git a/libavresample/avresample.h b/libavresample/avresample.h
> index 193443e2a6..57889c572c 100644
> --- a/libavresample/avresample.h
> +++ b/libavresample/avresample.h
> @@ -103,10 +103,10 @@
>  
>  #define AVRESAMPLE_MAX_CHANNELS 32
>  
> -typedef struct AVAudioResampleContext AVAudioResampleContext;
> +typedef attribute_deprecated struct AVAudioResampleContext 
> AVAudioResampleContext;
>  
>  /** Mixing Coefficient Types */
> -enum AVMixCoeffType {
> +enum attribute_deprecated AVMixCoeffType {
>  AV_MIX_COEFF_TYPE_Q8,   /** 16-bit 8.8 fixed-point  
> */
>  AV_MIX_COEFF_TYPE_Q15,  /** 32-bit 17.15 fixed-point
> */
>  AV_MIX_COEFF_TYPE_FLT,  /** floating-point  
> */
> @@ -114,13 +114,13 @@ enum AVMixCoeffType {
>  };
>  
>  /** Resampling Filter Types */
> -enum AVResampleFilterType {
> +enum attribute_deprecated AVResampleFilterType {
>  AV_RESAMPLE_FILTER_TYPE_CUBIC,  /**< Cubic */
>  AV_RESAMPLE_FILTER_TYPE_BLACKMAN_NUTTALL,   /**< Blackman Nuttall 
> Windowed Sinc */
>  AV_RESAMPLE_FILTER_TYPE_KAISER, /**< Kaiser Windowed Sinc */
>  };
>  
> -enum AVResampleDitherMethod {
> +enum attribute_deprecated AVResampleDitherMethod {
>  AV_RESAMPLE_DITHER_NONE,/**< Do not use dithering */
>  AV_RESAMPLE_DITHER_RECTANGULAR, /**< Rectangular Dither */
>  AV_RESAMPLE_DITHER_TRIANGULAR,  /**< Triangular Dither*/

wm4 found out that deprecating enums does basically nothing. some
compilers complain about the attribute, and others don't say anything at
all (aka, not warn when the enum is being used). I don't know if that
also applies to structs, but it might be a good idea to find out.

I'd say just add the deprecated attribute to functions as per usual.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavr: deprecate the entire library

On 12/25/2017 5:53 PM, Rostislav Pehlivanov wrote:
> Deprecate the entire library. Merged years ago to provide compatibility
> with Libav, it remained unmaintained by the FFmpeg project and duplicated
> functionality provided by libswresample.
> 
> In order to improve consistency and reduce attack surface, as well as to ease
> burden on maintainers, it has been deprecated. Users of this library are asked
> to migrate to libswresample, which, as well as providing more functionality,
> is faster and has higher accuracy.
> 
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  configure  |  4 ++--
>  doc/APIchanges | 10 ++
>  libavresample/avresample.h | 30 +-
>  3 files changed, 37 insertions(+), 7 deletions(-)

[...]

> +2017-xx-xx - xxx - lavr 4.0.0 - avresample.h
> +  Deprecate the entire library. Merged years ago to provide compatibility
> +  with Libav, it remained unmaintained by the FFmpeg project and duplicated
> +  functionality provided by libswresample.
> +
> +  In order to improve consistency and reduce attack surface, as well as to 
> ease
> +  burden on maintainers, it has been deprecated. Users of this library are 
> asked
> +  to migrate to libswresample, which, as well as providing more 
> functionality,
> +  is faster and has higher accuracy.

Maybe drop 'burden on maintainers', since it says directly above that it is
unmaintained, which is a direct contradiction.

> diff --git a/libavresample/avresample.h b/libavresample/avresample.h
> index 193443e2a6..57889c572c 100644
> --- a/libavresample/avresample.h
> +++ b/libavresample/avresample.h
> @@ -103,10 +103,10 @@

Doxygen should be updated with the @deprecated tag, and a pointer to swresample
on everything.

Other than that, I think it is OK to go ahead and push this soon. Thanks for
giving it a bit of time post-Christmas.

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

Re: [FFmpeg-devel] [PATCH 1/2] lavu/qsv: add log message for libmfx version

On 12/28/2017 9:27 AM, Zhong Li wrote:
> +av_log(ctx, AV_LOG_VERBOSE,
> +   "Initialize MFX session: API version is %d.%d, implementation 
> version is %d.%d\n",
> +   MFX_VERSION_MAJOR, MFX_VERSION_MINOR, ver.Major, ver.Minor);

Maybe AV_LOG_DEBUG?

I have no strong opinion, though.

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

Re: [FFmpeg-devel] [PATCH 2/2] examples/qsvdec: remove the deprecated filed refcounted_frames

On 12/28/2017 9:27 AM, Zhong Li wrote:
> It was just useful for deprecated API (avcodec_decode_video2),
> but useless for new decode APIs (avcodec_send_packet/avcodec_receive_frame).
> 
> Signed-off-by: Zhong Li 
> ---
>  doc/examples/qsvdec.c | 1 -
>  1 file changed, 1 deletion(-)

LGTM if the typo in the subject is fixed.

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

Re: [FFmpeg-devel] [PATCH] configure: check SDL2 function with a header

On 12/28/2017 2:44 PM, KO Myung-Hun wrote:
> On OS/2, '_' is not prepended to a function name.
> ---
>  configure | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

It's not immediately clear to be how checking a header instead relates
to function name mangling (or lack thereof)?

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

Re: [FFmpeg-devel] [PATCH] h264: add AVOption to set x264_build default

On 12/28/2017 12:44 AM, Carl Eugen Hoyos wrote:
>> out of nowhere without being provoked is not a welcome behavior at all.
> 
> That doesn't sound correct to me.

He literally said nothing to you on this thread before you insulted him.

Cut it out.

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

Re: [FFmpeg-devel] [PATCH] added reitnerlace filter

Vasile Toncu (2017-12-28):
>  Is submision to an older version
> possible?

No. Branches are only maintained for bugs. New development only happens
on Git head.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] added reitnerlace filter

On Thu, 28 Dec 2017 at 17:14, Nicolas George  wrote:

> Vasile Toncu (2017-12-28):
> > Is there anything that I can do to the current version of reinterlace so
> > that the filter can be accepted?
>
> For me, yes: make it fully compatible with tinterlace and call it that.
>

The reinterlace is compatible with tinterlace on ffmpeg version n3.0.2

Will the same issues regarding the submission rise if I trie to submit the
filter to an older branch (3.0.2n)?  Is submision to an older version
possible?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] added reitnerlace filter

Vasile Toncu (2017-12-28):
> Is there anything that I can do to the current version of reinterlace so
> that the filter can be accepted?

For me, yes: make it fully compatible with tinterlace and call it that.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] added reitnerlace filter

On Thu, 28 Dec 2017 at 15:41, Nicolas George  wrote:

> Vasile Toncu (2017-12-28):
> > There are some features that tinterlace has and reinterlace does not.
> >
> > Tinterlace has some more flags, reinterlace has only simple low pass
> filter.
> > Also, in a newer version, tinterlace does support input formats on 16
> bit.
> >
> > Expecting these two, there are no other special features.
>
> Thanks for that. I suspect that tinterlace is also faster. I suggest you
> run some benchmarks.

I run  some benchmarks and reinterlace has basicaly the same performance as
tinterlace. For some modes, tinterlace is up to 5% faster. I run my tests
on an win64 machine and on an linux x64.

>
> > Can one simply change the tinterlace from GPL to LGPL?
>
> Of course not. There are two non-simple courses of action to achieve it:
>
> - Get the approval of all copyright holders. It has been done in the
>   past for other filters.
>
> - Remove the GPL tinterlace and at the same time add a new LGPL filter
>   that does the same thing and is also called tinterlace.
>
> The second is probably only acceptable if the new filter has all the
> features and performance of the old one.

Is there anything that I can do to the current version of reinterlace so
that the filter can be accepted?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] configure: check SDL2 function with a header

On OS/2, '_' is not prepended to a function name.
---
 configure | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 70de780f82..f937ddf2be 100755
--- a/configure
+++ b/configure
@@ -6019,14 +6019,14 @@ fi
 if enabled sdl2; then
 SDL2_CONFIG="${cross_prefix}sdl2-config"
 if test_pkg_config sdl2 "sdl2 >= 2.0.1 sdl2 < 2.1.0" SDL_events.h 
SDL_PollEvent; then
-check_func SDL_Init $sdl2_extralibs $sdl2_cflags ||
+check_func_headers SDL.h SDL_Init $sdl2_extralibs $sdl2_cflags ||
 disable sdl2
 elif "${SDL2_CONFIG}" --version > /dev/null 2>&1; then
 sdl2_cflags=$("${SDL2_CONFIG}" --cflags)
 sdl2_extralibs=$("${SDL2_CONFIG}" --libs)
 check_cpp_condition SDL.h "(SDL_MAJOR_VERSION<<16 | 
SDL_MINOR_VERSION<<8 | SDL_PATCHLEVEL) >= 0x020001" $sdl2_cflags &&
 check_cpp_condition SDL.h "(SDL_MAJOR_VERSION<<16 | 
SDL_MINOR_VERSION<<8 | SDL_PATCHLEVEL) < 0x020100" $sdl2_cflags &&
-check_func SDL_Init $sdl2_extralibs $sdl2_cflags &&
+check_func_headers SDL.h SDL_Init $sdl2_extralibs $sdl2_cflags &&
 enable sdl2
 fi
 if test $target_os = "mingw32"; then
-- 
2.13.3

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

Re: [FFmpeg-devel] [PATCH] added reitnerlace filter




On 28.12.2017 15:17, Nicolas George wrote:

Vasile Toncu (2017-12-28):

Are there any features that tinterlace has and this new filter has not?
If not, then I think it would be better to just replace tinterlace
entirely.

You did not answer the question. I asked if there are features in
tinterlace that are not in reinterlace. You answered the opposite
question.



There are some features that tinterlace has and reinterlace does not.

Tinterlace has some more flags, reinterlace has only simple low pass filter.
Also, in a newer version, tinterlace does support input formats on 16 bit.

Expecting these two, there are no other special features.



I can answer myself: tinterlace has asm optimizations. This is not for
me only to decide, but I am rather against having duplicated features
just for licensing reasons.
In this particular instance, I think you could use the GPL asm
optimizations while having the filter itself LGPL.

Your arguments are valid, but what happens if I want to use a GPL tinterlace
in an closed source application that will be distributed.

You cannot.

But making tinterlace LGPL would solve that for you just the same as
adding yet another filter that does the same thing.


Can one simply change the tinterlace from GPL to LGPL?

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

Re: [FFmpeg-devel] [PATCH] added reitnerlace filter

Vasile Toncu (2017-12-28):
> There are some features that tinterlace has and reinterlace does not.
> 
> Tinterlace has some more flags, reinterlace has only simple low pass filter.
> Also, in a newer version, tinterlace does support input formats on 16 bit.
> 
> Expecting these two, there are no other special features.

Thanks for that. I suspect that tinterlace is also faster. I suggest you
run some benchmarks.

> Can one simply change the tinterlace from GPL to LGPL?

Of course not. There are two non-simple courses of action to achieve it:

- Get the approval of all copyright holders. It has been done in the
  past for other filters.

- Remove the GPL tinterlace and at the same time add a new LGPL filter
  that does the same thing and is also called tinterlace.

The second is probably only acceptable if the new filter has all the
features and performance of the old one.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] compat/os2threads: support static mutexes

2017-12-28 Thread wm4

On Thu, 28 Dec 2017 22:03:56 +0900
KO Myung-Hun  wrote:

> ---
>  compat/os2threads.h | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/compat/os2threads.h b/compat/os2threads.h
> index 40a119ffe1..2177a033ec 100644
> --- a/compat/os2threads.h
> +++ b/compat/os2threads.h
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2011 KO Myung-Hun 
> + * Copyright (c) 2011-2017 KO Myung-Hun 
>   *
>   * This file is part of FFmpeg.
>   *
> @@ -46,9 +46,11 @@ typedef struct {
>  
>  typedef void pthread_attr_t;
>  
> -typedef HMTX pthread_mutex_t;
> +typedef _fmutex pthread_mutex_t;
>  typedef void pthread_mutexattr_t;
>  
> +#define PTHREAD_MUTEX_INITIALIZER _FMUTEX_INITIALIZER
> +
>  typedef struct {
>  HEV event_sem;
>  HEV ack_sem;
> @@ -98,28 +100,28 @@ static av_always_inline int pthread_join(pthread_t 
> thread, void **value_ptr)
>  static av_always_inline int pthread_mutex_init(pthread_mutex_t *mutex,
> const pthread_mutexattr_t 
> *attr)
>  {
> -DosCreateMutexSem(NULL, (PHMTX)mutex, 0, FALSE);
> +_fmutex_create(mutex, 0);
>  
>  return 0;
>  }
>  
>  static av_always_inline int pthread_mutex_destroy(pthread_mutex_t *mutex)
>  {
> -DosCloseMutexSem(*(PHMTX)mutex);
> +_fmutex_close(mutex);
>  
>  return 0;
>  }
>  
>  static av_always_inline int pthread_mutex_lock(pthread_mutex_t *mutex)
>  {
> -DosRequestMutexSem(*(PHMTX)mutex, SEM_INDEFINITE_WAIT);
> +_fmutex_request(mutex, 0);
>  
>  return 0;
>  }
>  
>  static av_always_inline int pthread_mutex_unlock(pthread_mutex_t *mutex)
>  {
> -DosReleaseMutexSem(*(PHMTX)mutex);
> +_fmutex_release(mutex);
>  
>  return 0;
>  }

LGTM. Does this actually switch to futex-like light weight mutexes? (I
don't know anything about OS/2, but it does sound like PHMTX was the
equivalent of a win32 HANDLE mutex kernel object, that required kernel
entry on each lock/unlock, while _fmutex is possibly like Vista+ SRWs.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] added reitnerlace filter

Vasile Toncu (2017-12-28):
> >Are there any features that tinterlace has and this new filter has not?
> >If not, then I think it would be better to just replace tinterlace
> >entirely.
> The main difference between those those two filters is that reinterlace
> processes
> planes of output frames in parallel.
> 
> Another difference is that reinterlace introduces two new modes, which are
> described at [1]

You did not answer the question. I asked if there are features in
tinterlace that are not in reinterlace. You answered the opposite
question.

> >I can answer myself: tinterlace has asm optimizations. This is not for
> >me only to decide, but I am rather against having duplicated features
> >just for licensing reasons.
> >In this particular instance, I think you could use the GPL asm
> >optimizations while having the filter itself LGPL.
> Your arguments are valid, but what happens if I want to use a GPL tinterlace
> in an closed source application that will be distributed.

You cannot.

But making tinterlace LGPL would solve that for you just the same as
adding yet another filter that does the same thing.

As I said, I oppose duplicated features, except for very good reasons.
Licensing is not a good reason from my point of view.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] added reitnerlace filter




On 27.12.2017 15:31, Nicolas George wrote:

Vasile Toncu (2017-12-27):

It is because of licencing issues. I wanted the new filter to be LGPL.

Thanks for the explanation. That is a valid reason.

But as is, it would result would be duplicated code for people who do
not worry about licensing.

Are there any features that tinterlace has and this new filter has not?
If not, then I think it would be better to just replace tinterlace
entirely.
The main difference between those those two filters is that reinterlace 
processes

planes of output frames in parallel.

Another difference is that reinterlace introduces two new modes, which 
are described at [1]

I can answer myself: tinterlace has asm optimizations. This is not for
me only to decide, but I am rather against having duplicated features
just for licensing reasons.
In this particular instance, I think you could use the GPL asm
optimizations while having the filter itself LGPL.
Your arguments are valid, but what happens if I want to use a GPL 
tinterlace in an closed source application that will be distributed.


[1] http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/223066.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] compat/os2threads: support static mutexes

---
 compat/os2threads.h | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/compat/os2threads.h b/compat/os2threads.h
index 40a119ffe1..2177a033ec 100644
--- a/compat/os2threads.h
+++ b/compat/os2threads.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2011 KO Myung-Hun 
+ * Copyright (c) 2011-2017 KO Myung-Hun 
  *
  * This file is part of FFmpeg.
  *
@@ -46,9 +46,11 @@ typedef struct {
 
 typedef void pthread_attr_t;
 
-typedef HMTX pthread_mutex_t;
+typedef _fmutex pthread_mutex_t;
 typedef void pthread_mutexattr_t;
 
+#define PTHREAD_MUTEX_INITIALIZER _FMUTEX_INITIALIZER
+
 typedef struct {
 HEV event_sem;
 HEV ack_sem;
@@ -98,28 +100,28 @@ static av_always_inline int pthread_join(pthread_t thread, 
void **value_ptr)
 static av_always_inline int pthread_mutex_init(pthread_mutex_t *mutex,
const pthread_mutexattr_t *attr)
 {
-DosCreateMutexSem(NULL, (PHMTX)mutex, 0, FALSE);
+_fmutex_create(mutex, 0);
 
 return 0;
 }
 
 static av_always_inline int pthread_mutex_destroy(pthread_mutex_t *mutex)
 {
-DosCloseMutexSem(*(PHMTX)mutex);
+_fmutex_close(mutex);
 
 return 0;
 }
 
 static av_always_inline int pthread_mutex_lock(pthread_mutex_t *mutex)
 {
-DosRequestMutexSem(*(PHMTX)mutex, SEM_INDEFINITE_WAIT);
+_fmutex_request(mutex, 0);
 
 return 0;
 }
 
 static av_always_inline int pthread_mutex_unlock(pthread_mutex_t *mutex)
 {
-DosReleaseMutexSem(*(PHMTX)mutex);
+_fmutex_release(mutex);
 
 return 0;
 }
-- 
2.13.3

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

Re: [FFmpeg-devel] [PATCH] reinterlace filter

Vasile Toncu (2017-12-28):
> Reinterlace filter is a new video filter that does various
> interlace/interleave/merge ops between lines of consecutive frames.
> 
> It adds two new modes to the already existing tinterlace filter,
> merge_bff and merge_tff.
> 
> It is under LGPL license and starts from ffmpeg version n3.0.2.
> 
> This is my second submision attempt, with some modifications from last
> attempt.

You did not address nor answer the concerns I voiced there:

https://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/223029.html

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH] reinterlace filter