Re: [FFmpeg-devel] [PATCH] fate: add aecho test

2016-05-22 Thread Petru Rares Sincraian 

Hi Michael,

I have found some parameters that produce the same results in x64 and x32 
architectures. Here is the patch :)


Thanks,
Petru Rares.

From: ffmpeg-devel  on behalf of Michael 
Niedermayer 
Sent: Saturday, May 14, 2016 3:50:03 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] fate: add aecho test

On Sat, May 14, 2016 at 09:07:17AM +, Petru Rares Sincraian wrote:
>
>
> Hi there,
>
> Here I add a new test for aecho filter.

>  fate/filter-audio.mak |5
>  ref/fate/filter-aecho |  286 
> ++
>  2 files changed, 291 insertions(+)
> efd0670e8f0c0c23e9d1392052b03ac4b7e047f0  0001-fate-add-aecho-test.patch
> From 25e8de6f4caa08a1903a6756ca718ef06722d116 Mon Sep 17 00:00:00 2001
> From: Petru Rares Sincraian 
> Date: Sat, 14 May 2016 11:04:25 +0200
> Subject: [PATCH] fate: add aecho test

this fails on x86-32

--- ffmpeg/tests/ref/fate/filter-aecho 2016-05-14 13:33:43.477820778 +0200
+++ tests/data/fate/filter-aecho2016-05-14 15:16:00.441950067 +0200
@@ -46,241 +46,241 @@
 0,  40960,  40960, 1024, 4096, 0x7c4ce7e9
 0,  41984,  41984, 1024, 4096, 0x5eddeb19
 0,  43008,  43008, 1024, 4096, 0x351c08c4
-0,  44032,  44032, 1024, 4096, 0x30c6db8f
-0,  45056,  45056, 1024, 4096, 0x1c4b3258
-0,  46080,  46080, 1024, 4096, 0xe32d157e
+0,  44032,  44032, 1024, 4096, 0x4dd4db91
+0,  45056,  45056, 1024, 4096, 0x07ad3256
+0,  46080,  46080, 1024, 4096, 0xe6131580
 0,  47104,  47104, 1024, 4096, 0xbbe9e635
-0,  48128,  48128, 1024, 4096, 0x7e8214dc
-0,  49152,  49152, 1024, 4096, 0xd671e4c1
-0,  50176,  50176, 1024, 4096, 0xd268f457
-0,  51200,  51200, 1024, 4096, 0x6051018e
+0,  48128,  48128, 1024, 4096, 0x8f4014de
+0,  49152,  49152, 1024, 4096, 0xbc53e4bf
+0,  50176,  50176, 1024, 4096, 0xf2b6f459
+0,  51200,  51200, 1024, 4096, 0x83350192


you can test that with somethng like
./configure  --arch=x86_32 --target-os=linux --extra-cflags=-m32 
--extra-ldflags=-m32  --enable-cross-compile

aecho uses floats so rounding and precission differences can cause
differences between platforms
you could improve aecho so it does not depend on floats for filtering
of s16 samples
but maybe you can find parameters that give the same result on all
platforms without that
or a small reference file would need to be added and tiny_psnr used
for comparing

[...]

--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
"Experts will know" - "The seller hopes you are not an expert"
From 5a3be60397e2f7bc0d84232736c8d44508bfbeff Mon Sep 17 00:00:00 2001
From: Petru Rares Sincraian 
Date: Sun, 22 May 2016 09:45:49 +0200
Subject: [PATCH] fate: add aecho test

---
 tests/fate/filter-audio.mak |   5 +
 tests/ref/fate/filter-aecho | 265 
 2 files changed, 270 insertions(+)
 create mode 100644 tests/ref/fate/filter-aecho

diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index 7f7e520..5e5f1f9 100644
--- a/tests/fate/filter-audio.mak
+++ b/tests/fate/filter-audio.mak
@@ -3,6 +3,11 @@ fate-filter-adelay: tests/data/asynth-44100-2.wav
 fate-filter-adelay: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
 fate-filter-adelay: CMD = framecrc -i $(SRC) -af adelay=42
 
+FATE_AFILTER-$(call FILTERDEMDECENCMUX, AECHO, WAV, PCM_S16LE, PCM_S16LE, WAV) += fate-filter-aecho
+fate-filter-aecho: tests/data/asynth-44100-2.wav
+fate-filter-aecho: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
+fate-filter-aecho: CMD = framecrc -i $(SRC) -af aecho=0.5:0.5:32:0.5
+
 tests/data/hls-list.m3u8: TAG = GEN
 tests/data/hls-list.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
 	$(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
diff --git a/tests/ref/fate/filter-aecho b/tests/ref/fate/filter-aecho
new file mode 100644
index 000..f564fcc
--- /dev/null
+++ b/tests/ref/fate/filter-aecho
@@ -0,0 +1,265 @@
+#tb 0: 1/44100
+#media_type 0: audio
+#codec_id 0: pcm_s16le
+#sample_rate 0: 44100
+#channel_layout 0: 3
+0,  0,  0, 1024, 4096, 0x3019edd5
+0,   1024,   1024, 1024, 4096, 0x2df2fe2f
+0,   2048,   2048, 1024, 4096, 0xde37ff37
+0,   3072,   3072, 1024, 4096, 0xe933f6a5
+0,   4096,   4096, 1024, 4096, 0xd5acf1f3
+0,   5120,   5120, 1024, 4096, 0x82a6f903
+0,   6144,   6144, 1024, 4096, 0x1792f923
+0,   7168,   7168, 1024, 4096, 0x01500504
+0,   8192,   8192,

Re: [FFmpeg-devel] [PATCH] libavcodec/mmaldec.c: add needs for deinterlacing

2016-05-22 Thread Jens Ziller 
Am Samstag, den 21.05.2016, 21:57 +0200 schrieb Michael Niedermayer:
> On Sat, May 21, 2016 at 09:20:55PM +0200, Jens Ziller wrote:
> > 
> > for deinterlacing is needed frame->interlaced_frame and format
> > struct. This patch added this.
> > 
> > Signed-off-by: Jens Ziller 
> > ---
> >  libavcodec/mmaldec.c | 16 
> >  1 file changed, 16 insertions(+)
> > 
> > diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
> > index 52232d5..89f19a0 100644
> > --- a/libavcodec/mmaldec.c
> > +++ b/libavcodec/mmaldec.c
> > @@ -88,6 +88,7 @@ typedef struct MMALDecodeContext {
> >  int eos_received;
> >  int eos_sent;
> >  int extradata_sent;
> > +int interlaced_frame;
> >  } MMALDecodeContext;
> >  
> >  // Assume decoder is guaranteed to produce output after at least
> > this
> > many
> > @@ -274,6 +275,7 @@ static int ffmal_update_format(AVCodecContext
> > *avctx)
> the inline patch is corrupted by newlines
> the attached patch is missing the author
> "Patch does not have a valid e-mail address."
> and the whole mail cannot be applied as the inline patch is corrupted
> 
> [...]
> 

Sorry for inconvenience. Attached is the new patch.

Regards Jens.

> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-develFrom f5818bde8e73b778c13b21e89d24f0d687c96714 Mon Sep 17 00:00:00 2001
From: Jens Ziller 
Date: Sun, 22 May 2016 09:49:45 +0200
Subject: [PATCH] for deinterlacing needed

---
 libavcodec/mmaldec.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index 52232d5..89f19a0 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -88,6 +88,7 @@ typedef struct MMALDecodeContext {
 int eos_received;
 int eos_sent;
 int extradata_sent;
+int interlaced_frame;
 } MMALDecodeContext;
 
 // Assume decoder is guaranteed to produce output after at least this many
@@ -274,6 +275,7 @@ static int ffmal_update_format(AVCodecContext *avctx)
 int ret = 0;
 MMAL_COMPONENT_T *decoder = ctx->decoder;
 MMAL_ES_FORMAT_T *format_out = decoder->output[0]->format;
+MMAL_PARAMETER_VIDEO_INTERLACE_TYPE_T interlace_type;
 
 ffmmal_poolref_unref(ctx->pool_out);
 if (!(ctx->pool_out = av_mallocz(sizeof(*ctx->pool_out {
@@ -300,6 +302,15 @@ static int ffmal_update_format(AVCodecContext *avctx)
 if ((status = mmal_port_format_commit(decoder->output[0])))
 goto fail;
 
+interlace_type.hdr.id = MMAL_PARAMETER_VIDEO_INTERLACE_TYPE;
+interlace_type.hdr.size = sizeof(MMAL_PARAMETER_VIDEO_INTERLACE_TYPE_T);
+status = mmal_port_parameter_get(decoder->output[0], &interlace_type.hdr);
+if (status != MMAL_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Cannot read MMAL interlace information!\n");
+} else {
+ctx->interlaced_frame = !(interlace_type.eMode == MMAL_InterlaceProgressive);
+}
+
 if ((ret = ff_set_dimensions(avctx, format_out->es->video.crop.x + format_out->es->video.crop.width,
 format_out->es->video.crop.y + format_out->es->video.crop.height)) < 0)
 goto fail;
@@ -607,7 +618,12 @@ static int ffmal_copy_frame(AVCodecContext *avctx,  AVFrame *frame,
 MMALDecodeContext *ctx = avctx->priv_data;
 int ret = 0;
 
+frame->interlaced_frame = ctx->interlaced_frame;
+
 if (avctx->pix_fmt == AV_PIX_FMT_MMAL) {
+// in data[2] give the format struct for configure deinterlacer and renderer
+frame->data[2] = ctx->decoder->output[0]->format;
+
 if (!ctx->pool_out)
 return AVERROR_UNKNOWN; // format change code failed with OOM previously
 
-- 
2.7.3

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

Re: [FFmpeg-devel] [PATCH] web/contact: correct the condition for op status on IRC

2016-05-22 Thread Michael Niedermayer 
On Sat, May 21, 2016 at 08:34:30PM -0800, Lou Logan wrote:
> On Sat, May 21, 2016, at 03:20 PM, Michael Niedermayer wrote:
> > we gave op status to commiters in the CVS and SVN days
> > since git an entry in MAINTAINERs was generally required to be offered
> > op status and push rights where not required.
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >src/contact |    4 ++--
> >1 file changed, 2 insertions(+), 2 deletions(-)
>  
> Fine with me.

applied

thanks

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

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


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

Re: [FFmpeg-devel] [PATCH] web/contact: correct the condition for op status on IRC

2016-05-22 Thread Michael Niedermayer 
On Sun, May 22, 2016 at 01:20:05AM +0200, Michael Niedermayer wrote:
> we gave op status to commiters in the CVS and SVN days
> since git an entry in MAINTAINERs was generally required to be offered
> op status and push rights where not required.
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  src/contact |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/contact b/src/contact
> index 9ee7392..200cb67 100644
> --- a/src/contact
> +++ b/src/contact
> @@ -99,8 +99,8 @@
>
>  
>FFmpeg has two official channels on the  href="https://freenode.net/";>freenode
> -  IRC network. Both channels are open and unmoderated. Developers 
> with commit
> -  rights have operator status, contributors with patches in FFmpeg
> +  IRC network. Both channels are open and unmoderated. Maintainers
> +  have operator status, contributors with patches in FFmpeg
>have voice in the channels.

also, note to all, if we have maintainers who do not have OP
in IRC (but have a registered nick), please tell me

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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


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

Re: [FFmpeg-devel] [PATCH] fix few compiler warnings

2016-05-22 Thread Mark Thompson 
On 22/05/16 02:51, Davinder Singh wrote:
> Subject: [PATCH 6/7] libavcodec/pngenc: fixed assignment discards qualifier
> warning
>
> ---
> libavcodec/pngenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
> index 00c830e..7f09d6f 100644
> --- a/libavcodec/pngenc.c
> +++ b/libavcodec/pngenc.c
> @@ -271,7 +271,7 @@ static int png_write_row(AVCodecContext *avctx, const 
> uint8_t *data, int size)
> int ret;
>
> s->zstream.avail_in = size;
> - s->zstream.next_in = data;
> + s->zstream.next_in = (Bytef *) data;
> while (s->zstream.avail_in > 0) {
> ret = deflate(&s->zstream, Z_NO_FLUSH);
> if (ret != Z_OK)
> --
> 2.7.4 (Apple Git-66)
> Subject: [PATCH 7/7] libavcodec/tscc: fixed assignment discards qualifier
> warning
>
> ---
> libavcodec/tscc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/tscc.c b/libavcodec/tscc.c
> index bd5fe03..4641545 100644
> --- a/libavcodec/tscc.c
> +++ b/libavcodec/tscc.c
> @@ -78,7 +78,7 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
> int *got_frame,
> av_log(avctx, AV_LOG_ERROR, "Inflate reset error: %d\n", ret);
> return AVERROR_UNKNOWN;
> }
> - c->zstream.next_in = buf;
> + c->zstream.next_in = (Bytef *) buf;
> c->zstream.avail_in = buf_size;
> c->zstream.next_out = c->decomp_buf;
> c->zstream.avail_out = c->decomp_size;
> --
> 2.7.4 (Apple Git-66)

Neither of these should be needed, because ZLIB_CONST should be defined.

configure:6254:
enabled zlib && add_cppflags -DZLIB_CONST

This works correctly for me:

$ make V=1 libavcodec/tscc.o
gcc -I. -Isrc/ -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DZLIB_CONST -DHAVE_AV_CONFIG_H 
-std=c99 -fomit-frame-pointer -pthread -D_GNU_SOURCE=1 -D_REENTRANT 
-I/usr/include/SDL  -g -Wdeclaration-after-statement -Wall 
-Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings 
-Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast 
-Wstrict-prototypes -Wempty-body -Wno-parentheses -Wno-switch 
-Wno-format-zero-length -Wno-pointer-sign -O3 -fno-math-errno -fno-signed-zeros 
-Werror=format-security -Werror=implicit-function-declaration 
-Werror=missing-prototypes -Werror=return-type -Werror=vla -Wformat 
-fdiagnostics-color=auto -Wno-maybe-uninitialized  -MMD -MF libavcodec/tscc.d 
-MT libavcodec/tscc.o -c -o libavcodec/tscc.o src/libavcodec/tscc.c
$

Perhaps instead investigate why it isn't working for you?

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

Re: [FFmpeg-devel] [Vote] Code of Conduct

2016-05-22 Thread Peter Ross 
On Sat, May 21, 2016 at 04:10:39PM +0200, Michael Niedermayer wrote:
> On Wed, May 18, 2016 at 08:40:07PM +0200, Michael Niedermayer wrote:
> > This is the version i had in my pending branch and should be the last 
> > version of the Code of Conduct from march, IIRC there where no further 
> > comments on the last version, so iam calling everyone to vote on this.
> > Everyone because it should be binding to everyone.
> > 
> > Kieran and Thilo asked for a formal vote and i agree that this needs
> > a vote.
> > 
> > I wanted to send this earlier, but was always busy with other things
> > 
> > Please state clearly if you agree to the text or if not.
> > we can extend and tune it later and do another vote if there are more
> >  suggestions
> 
> 3 days passed, 7 people casted a vote, 4 days left
> 
> Everyone please vote (unless you truely dont care either way)

I agree with the text.

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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

[FFmpeg-devel] [PATCH] vaapi: Enable more libva surface formats

2016-05-22 Thread Mark Thompson 
---
These were not already enabled because the other tine does not have suitable 
support for them.

BGR0/RGB0 tested and working.  I don't have any hardware for the others, but I 
believe they should work.

 libavutil/hwcontext_vaapi.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index c2cdaa9..7c3e4bd 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -86,16 +86,16 @@ static struct {
 MAP(YUY2, YUV422,  YUYV422),
 MAP(Y800, YUV400,  GRAY8),
 #ifdef VA_FOURCC_P010
-  //MAP(P010, YUV420_10BPP, P010),
+MAP(P010, YUV420_10BPP, P010),
 #endif
 MAP(BGRA, RGB32,   BGRA),
-  //MAP(BGRX, RGB32,   BGR0),
+MAP(BGRX, RGB32,   BGR0),
 MAP(RGBA, RGB32,   RGBA),
-  //MAP(RGBX, RGB32,   RGB0),
+MAP(RGBX, RGB32,   RGB0),
 MAP(ABGR, RGB32,   ABGR),
-  //MAP(XBGR, RGB32,   0BGR),
+MAP(XBGR, RGB32,   0BGR),
 MAP(ARGB, RGB32,   ARGB),
-  //MAP(XRGB, RGB32,   0RGB),
+MAP(XRGB, RGB32,   0RGB),
 };
 #undef MAP

-- 
2.8.1

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

Re: [FFmpeg-devel] [Vote] Code of Conduct

2016-05-22 Thread Michael Niedermayer 
On Wed, May 18, 2016 at 08:40:07PM +0200, Michael Niedermayer wrote:
> This is the version i had in my pending branch and should be the last 
> version of the Code of Conduct from march, IIRC there where no further 
> comments on the last version, so iam calling everyone to vote on this.
> Everyone because it should be binding to everyone.
> 
> Kieran and Thilo asked for a formal vote and i agree that this needs
> a vote.
> 
> I wanted to send this earlier, but was always busy with other things
> 

> Please state clearly if you agree to the text or if not.

agree

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

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.


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

Re: [FFmpeg-devel] [PATCH] [v2] libavcodec/options.c: handle hw_frames_ctx where necessary

2016-05-22 Thread Mark Thompson 
On 20/05/16 11:31, Andrey Turkin wrote:
> avcodec_copy_context didn't handle hw_frames_ctx references correctly which 
> could cause crashes.
> ---
> 
> Changes from v1: reverted changes to avcodec_free_context
> 
> 
>  libavcodec/options.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/libavcodec/options.c b/libavcodec/options.c
> index ea2563b..08c2259 100644
> --- a/libavcodec/options.c
> +++ b/libavcodec/options.c
> @@ -197,6 +197,7 @@ int avcodec_copy_context(AVCodecContext *dest, const 
> AVCodecContext *src)
>  av_freep(&dest->inter_matrix);
>  av_freep(&dest->extradata);
>  av_freep(&dest->subtitle_header);
> +av_buffer_unref(&dest->hw_frames_ctx);
>  
>  memcpy(dest, src, sizeof(*dest));
>  av_opt_copy(dest, src);
> @@ -225,6 +226,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  dest->inter_matrix= NULL;
>  dest->rc_override = NULL;
>  dest->subtitle_header = NULL;
> +dest->hw_frames_ctx   = NULL;
>  
>  #define alloc_and_copy_or_fail(obj, size, pad) \
>  if (src->obj && size > 0) { \
> @@ -245,6 +247,12 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  av_assert0(dest->subtitle_header_size == src->subtitle_header_size);
>  #undef alloc_and_copy_or_fail
>  
> +if (src->hw_frames_ctx) {
> +dest->hw_frames_ctx = av_buffer_ref(src->hw_frames_ctx);
> +if (!dest->hw_frames_ctx)
> +goto fail;
> +}
> +
>  return 0;
>  
>  fail:
> @@ -255,6 +263,7 @@ fail:
>  av_freep(&dest->subtitle_header);
>  dest->subtitle_header_size = 0;
>  dest->extradata_size = 0;
> +av_buffer_unref(&dest->hw_frames_ctx);
>  av_opt_free(dest);
>  return AVERROR(ENOMEM);
>  }
> 

Looks fine; it does fix an immediate problem.

Note that development around hwcontext is mainly happening in libav, and this 
sort of copy support is not really an intended use.



Thanks,

- Mark

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

Re: [FFmpeg-devel] [PATCH] Updated (v3) -- Add input mode autodetect to the decklink module.

2016-05-22 Thread Marton Balint 


On Sat, 21 May 2016, Felt, Patrick wrote:


On 5/21/16, 3:38 AM, "ffmpeg-devel on behalf of Marton Balint" 
 wrote:


--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -98,6 +98,90 @@ HRESULT ff_decklink_get_display_name(IDeckLink *This, const 
char **displayName)
return hr;
}

+long ff_decklink_mode_to_bm(AVFormatContext *avctx,


Should be BMDDisplayMode, not long.


+   decklink_direction_t direction,
+   int ffmpeg_mode,
+   IDeckLinkDisplayMode **mode)


As far a I see you do not use **mode with a non-NULL arugment in your
code, so you can get rid of it and its functionality.


True, in this patch I do not use **mode, however I noticed that 
elsewhere we did a similar loop.  This could consolidate the code into 
one fuction so we don’t have duplicate code.  That would definitely be 
an unrelated change so I left it open enough to hopefully suffice.  We 
can take it out if we need to.




If you intend to submit that patch as well soon to the mailing list, then 
OK. You can also submit that as a patch series so we can see that keeping 
it is really useful, and no futher changes are necessary in the function.





+{
+struct decklink_cctx *cctx = (struct decklink_cctx *) avctx->priv_data;


unnecessary space before avctx


most of the spaces here are because I copied and pasted those lines from 
other, previously defined functions.  I removed from where I was seeing 
them, however I may have removed some extras.  Please don’t consider 
those a formatting change.


Please, don't mix cleaning up existing code with new features, it makes 
reviewing much harder.





+break;
+}
+
+internal_mode->Release();
+}
+
+itermode->Release();
+if (internal_mode) {


What if there is no match for ffmpeg_mode? Is it documented in the
Decklink SDK that internal_mode will be overwritten to NULL on the last
iteration?


Good catch.  I’ll rework this loop.


+int ff_decklink_mode_to_ffmpeg(AVFormatContext *avctx,
+   decklink_direction_t direction,
+   IDeckLinkDisplayMode **mode)


should use *mode, not **mode, because *mode is not overwritten in this
function


modified this one as there really isn’t a need to send back mode information


+int ff_decklink_device_autodetect(AVFormatContext *avctx)


Probably worth remaining to somehting like
ff_decklink_can_detect_input_format otherwise somebody may be
under the impression that this function will do the autodetection.


I’ve modified this to ff_decklink_device_supports_autodetect


Autodetect what? Sorry, but for me it is still not clear if this means 
supporting the input detection (one card can have multiple inputs), or the 
input format, that is why I would put "input format" somewhere in the name...





@@ -244,6 +245,12 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
BMDTimeValue frameTime;
BMDTimeValue frameDuration;

+/* if we don't have video, we are in the autodetect phase.  skip 
everything and let
+ * autodetect do its magic */
+if (!ctx->video) {
+return S_OK;
+}
+
ctx->frameCount++;

// Handle Video Frame
@@ -393,6 +400,14 @@ HRESULT decklink_input_callback::VideoInputFormatChanged(
BMDVideoInputFormatChangedEvents events, IDeckLinkDisplayMode *mode,
BMDDetectedVideoInputFormatFlags)
{
+
+/* undo all the autodetect stuff so we can move on with life */
+ctx->dli->PauseStreams();
+ctx->dli->FlushStreams();
+
+ctx->mode_num = ff_decklink_mode_to_ffmpeg(avctx, DIRECTION_IN, &mode);
+ctx->video = 1;


I would only do anything in this function, if ctx->auto_detect is set
to 1, and I would also set ctx->auto_detect to 0, so you don't have to
use a separate ->video variable for signalling a successful autodetection.

Also don't you want to StopStreams and DisableAudio/VideoInput here?
Because you will be re-doing the whole initialization stuff later, and I
am not sure you are supposed to call ff_decklink_set_format when the
streams are already running.



The decklink sdk specifically states that there should be a pause here 
and not a stop/start.  Also, ff_decklink_set_format() only checks that a 
mode is supported.  It doesn’t actually do anything else with the 
decklink api.


Okay, but later, on decklink_start_input you create a whole new decklink 
input callback, shouldn't you release the old? Or am I missing something?


Also are you sure when you start the actual capture, no further 
FormatChange callbacks will fire? So even if the streams are paused, will 
the new EnableVideoInput override the old setting with the format 
detection flag?


That is why I think that maybe it is more simple and reliable to stop 
everything and restart the whole stuff after we acquired the format.



@@ -510,34 +525,74 @@ av_cold int ff_decklink_read_header(AVFormatContext 
*avctx)

[FFmpeg-devel] Which additional files need to be modified when adding PPC-specific version of libswscale/input.c

2016-05-22 Thread Dan Parrot 
I am working on a patch to improve ffmpeg performance on PPC by using
vector SIMD facilities for those processor versions that have the
capability. 

There are 50 functions in libswscale/input.c that I am modifying. Adding
#ifdefs in all the functions probably isn't the way to go.

Is there a preferred method to implement such a change?

Thanks.
Dan Parrot.


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

Re: [FFmpeg-devel] [PATCH] libavcodec/mmaldec.c: add needs for deinterlacing

2016-05-22 Thread Jens Ziller 
Am Samstag, den 21.05.2016, 21:57 +0200 schrieb Michael Niedermayer:
> On Sat, May 21, 2016 at 09:20:55PM +0200, Jens Ziller wrote:
> > 
> > for deinterlacing is needed frame->interlaced_frame and format
> > struct. This patch added this.
> > 
> > Signed-off-by: Jens Ziller 
> > ---
> >  libavcodec/mmaldec.c | 16 
> >  1 file changed, 16 insertions(+)
> > 
> > diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
> > index 52232d5..89f19a0 100644
> > --- a/libavcodec/mmaldec.c
> > +++ b/libavcodec/mmaldec.c
> > @@ -88,6 +88,7 @@ typedef struct MMALDecodeContext {
> >  int eos_received;
> >  int eos_sent;
> >  int extradata_sent;
> > +int interlaced_frame;
> >  } MMALDecodeContext;
> >  
> >  // Assume decoder is guaranteed to produce output after at least
> > this
> > many
> > @@ -274,6 +275,7 @@ static int ffmal_update_format(AVCodecContext
> > *avctx)
> the inline patch is corrupted by newlines
> the attached patch is missing the author
> "Patch does not have a valid e-mail address."
> and the whole mail cannot be applied as the inline patch is corrupted
> 
> [...]
> 

Sorry for inconvenience. Attached is the new version.

Regards Jens.
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-develFrom f5818bde8e73b778c13b21e89d24f0d687c96714 Mon Sep 17 00:00:00 2001
From: Jens Ziller 
Date: Sun, 22 May 2016 09:49:45 +0200
Subject: [PATCH] for deinterlacing needed

---
 libavcodec/mmaldec.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index 52232d5..89f19a0 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -88,6 +88,7 @@ typedef struct MMALDecodeContext {
 int eos_received;
 int eos_sent;
 int extradata_sent;
+int interlaced_frame;
 } MMALDecodeContext;
 
 // Assume decoder is guaranteed to produce output after at least this many
@@ -274,6 +275,7 @@ static int ffmal_update_format(AVCodecContext *avctx)
 int ret = 0;
 MMAL_COMPONENT_T *decoder = ctx->decoder;
 MMAL_ES_FORMAT_T *format_out = decoder->output[0]->format;
+MMAL_PARAMETER_VIDEO_INTERLACE_TYPE_T interlace_type;
 
 ffmmal_poolref_unref(ctx->pool_out);
 if (!(ctx->pool_out = av_mallocz(sizeof(*ctx->pool_out {
@@ -300,6 +302,15 @@ static int ffmal_update_format(AVCodecContext *avctx)
 if ((status = mmal_port_format_commit(decoder->output[0])))
 goto fail;
 
+interlace_type.hdr.id = MMAL_PARAMETER_VIDEO_INTERLACE_TYPE;
+interlace_type.hdr.size = sizeof(MMAL_PARAMETER_VIDEO_INTERLACE_TYPE_T);
+status = mmal_port_parameter_get(decoder->output[0], &interlace_type.hdr);
+if (status != MMAL_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Cannot read MMAL interlace information!\n");
+} else {
+ctx->interlaced_frame = !(interlace_type.eMode == MMAL_InterlaceProgressive);
+}
+
 if ((ret = ff_set_dimensions(avctx, format_out->es->video.crop.x + format_out->es->video.crop.width,
 format_out->es->video.crop.y + format_out->es->video.crop.height)) < 0)
 goto fail;
@@ -607,7 +618,12 @@ static int ffmal_copy_frame(AVCodecContext *avctx,  AVFrame *frame,
 MMALDecodeContext *ctx = avctx->priv_data;
 int ret = 0;
 
+frame->interlaced_frame = ctx->interlaced_frame;
+
 if (avctx->pix_fmt == AV_PIX_FMT_MMAL) {
+// in data[2] give the format struct for configure deinterlacer and renderer
+frame->data[2] = ctx->decoder->output[0]->format;
+
 if (!ctx->pool_out)
 return AVERROR_UNKNOWN; // format change code failed with OOM previously
 
-- 
2.7.3

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

Re: [FFmpeg-devel] Which additional files need to be modified when adding PPC-specific version of libswscale/input.c

2016-05-22 Thread Paul B Mahol 
On 5/21/16, Dan Parrot  wrote:
> I am working on a patch to improve ffmpeg performance on PPC by using
> vector SIMD facilities for those processor versions that have the
> capability.
>
> There are 50 functions in libswscale/input.c that I am modifying. Adding
> #ifdefs in all the functions probably isn't the way to go.
>
> Is there a preferred method to implement such a change?

Yes, look how it is done for x86. There is directory named x86 and ppc.
>
> Thanks.
> Dan Parrot.
>
>
> ___
> 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] Tee improvement - discussion

2016-05-22 Thread Marton Balint 


On Wed, 18 May 2016, Jan Sebechlebsky wrote:

[...]

I'm thinking of implementing this queue by wrapping up AVFifoBuffer 
(similarily than AVThreadMessageQueue does but with the configurable 
behaviour as described above).


Exactly what behaviour is missing from AVThreadMessageQueue? Isn't there a 
chance to extend that, or implement all additional logic on top of it?


What is missing is basically just the discussed configurable behaviour how to 
deal with overfilled queue. I originally thought that the queue would flush 
old packets automatically (from the point of view of consumer / producer it 
would be transparent). But if the consumer will be responsible for flushing 
the packets in non-blocking mode I guess the AVThreadMessageQueue will do the 
work. This really simplifies the whole task.


I just wonder, is simply flushing the whole buffer good solution? Shouldn't 
keyframe flag be considered (either flush until next keyframe(s)), or ignore 
packet which arrived after flush until new keyframe arrives? If so this 
wouldrequire some additional functionality to be added to 
AVThreadMessageQueue (since it would be no longer related to general message 
queue it should be probably implemented separately).


A consumer would flush the queue (every packet), then clear the overflow 
flag, and then - like you said - ignore (drop) all incoming packets until 
a keyframe arrives, and from that it would start actually processing 
packets. You don't need this functionality in the message queue, the 
consumer can do this as well.


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

[FFmpeg-devel] [PATCH] avcodec/iff: mention RGB8/RGBN decoder

2016-05-22 Thread Piotr Bandurski 


0001-avcodec-iff-mention-RGB8-RGBN-decoder.diff
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Masked LZ Decompression

2016-05-22 Thread Umair Khan 
On Fri, May 20, 2016 at 11:53 PM, Paul B Mahol  wrote:
> On 5/20/16, Umair Khan  wrote:
>> Hi,
>>
>> I'm working on implementing floating point support in the ALS decoder.
>> In this I've to use masked LZ decompression. I've written the code for
>> myself for masked lz decompression using the help from the reference
>> software.
>> Although, I'm not yet sure if an implementation of masked LZ is
>> already there in FFmpeg or not.
>> If it is already there, it makes no sense to have my own implementation as
>> well.
>>
>> So anybody has any idea if we have masked LZ implementation already or not ?
>
> IMHO we do not. Because its audio related.

Hi Paul,

Any idea about this https://ffmpeg.org/doxygen/2.8/lzw_8c.html ?
This looks like the encoder part - https://ffmpeg.org/doxygen/2.8/lzwenc_8c.html

I'm not sure how masked LZ is different from LZW. There's almost zero
information available on internet about masked lz.
Also, there's a research paper available here -
http://www.aes.org/e-lib/browse.cfm?elib=13068
Any way if we can get this ?

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

Re: [FFmpeg-devel] [PATCH] [v2] libavcodec/options.c: handle hw_frames_ctx where necessary

2016-05-22 Thread Andrey Turkin 
Yeah, I saw that patch series today. Still should be fixed until the
function goes away. I'll send patch to libav as well shortly.

2016-05-22 16:39 GMT+03:00 Mark Thompson :

> Looks fine; it does fix an immediate problem.
>
> Note that development around hwcontext is mainly happening in libav, and
> this sort of copy support is not really an intended use.
>
> 
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Masked LZ Decompression

2016-05-22 Thread Paul B Mahol 
On 5/22/16, Umair Khan  wrote:
> On Fri, May 20, 2016 at 11:53 PM, Paul B Mahol  wrote:
>> On 5/20/16, Umair Khan  wrote:
>>> Hi,
>>>
>>> I'm working on implementing floating point support in the ALS decoder.
>>> In this I've to use masked LZ decompression. I've written the code for
>>> myself for masked lz decompression using the help from the reference
>>> software.
>>> Although, I'm not yet sure if an implementation of masked LZ is
>>> already there in FFmpeg or not.
>>> If it is already there, it makes no sense to have my own implementation
>>> as
>>> well.
>>>
>>> So anybody has any idea if we have masked LZ implementation already or
>>> not ?
>>
>> IMHO we do not. Because its audio related.
>
> Hi Paul,
>
> Any idea about this https://ffmpeg.org/doxygen/2.8/lzw_8c.html ?
> This looks like the encoder part -
> https://ffmpeg.org/doxygen/2.8/lzwenc_8c.html

Different thing, you can look at code.

>
> I'm not sure how masked LZ is different from LZW. There's almost zero
> information available on internet about masked lz.
> Also, there's a research paper available here -
> http://www.aes.org/e-lib/browse.cfm?elib=13068
> Any way if we can get this ?

No need to get it if there is already code for it.

When you will finally send patch?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Masked LZ Decompression

2016-05-22 Thread Umair Khan 
On Sun, May 22, 2016 at 11:11 PM, Paul B Mahol  wrote:
> On 5/22/16, Umair Khan  wrote:
>> On Fri, May 20, 2016 at 11:53 PM, Paul B Mahol  wrote:
>>> On 5/20/16, Umair Khan  wrote:
 Hi,

 I'm working on implementing floating point support in the ALS decoder.
 In this I've to use masked LZ decompression. I've written the code for
 myself for masked lz decompression using the help from the reference
 software.
 Although, I'm not yet sure if an implementation of masked LZ is
 already there in FFmpeg or not.
 If it is already there, it makes no sense to have my own implementation
 as
 well.

 So anybody has any idea if we have masked LZ implementation already or
 not ?
>>>
>>> IMHO we do not. Because its audio related.
>>
>> Hi Paul,
>>
>> Any idea about this https://ffmpeg.org/doxygen/2.8/lzw_8c.html ?
>> This looks like the encoder part -
>> https://ffmpeg.org/doxygen/2.8/lzwenc_8c.html
>
> Different thing, you can look at code.
>
>>
>> I'm not sure how masked LZ is different from LZW. There's almost zero
>> information available on internet about masked lz.
>> Also, there's a research paper available here -
>> http://www.aes.org/e-lib/browse.cfm?elib=13068
>> Any way if we can get this ?
>
> No need to get it if there is already code for it.
>
> When you will finally send patch?

I fixed the error which I was having in which the output of channel 0
was not correct.
I still have some features which are not working properly. I plan to
send the patch before Friday.

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

Re: [FFmpeg-devel] [PATCH] avcodec/iff: mention RGB8/RGBN decoder

2016-05-22 Thread Michael Niedermayer 
On Sun, May 22, 2016 at 06:49:35PM +0200, Piotr Bandurski wrote:


applied

thanks

[...]

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

[FFmpeg-devel] [PATCH] ffplay: simplify display code

2016-05-22 Thread Marton Balint 
And get rid of frame_queue_prev.

Signed-off-by: Marton Balint 
---
 ffplay.c | 43 +--
 1 file changed, 13 insertions(+), 30 deletions(-)

diff --git a/ffplay.c b/ffplay.c
index d5fcde8..11c5091 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -769,14 +769,6 @@ static void frame_queue_next(FrameQueue *f)
 SDL_UnlockMutex(f->mutex);
 }
 
-/* jump back to the previous frame if available by resetting rindex_shown */
-static int frame_queue_prev(FrameQueue *f)
-{
-int ret = f->rindex_shown;
-f->rindex_shown = 0;
-return ret;
-}
-
 /* return the number of undisplayed frames in the queue */
 static int frame_queue_nb_remaining(FrameQueue *f)
 {
@@ -947,7 +939,7 @@ static void video_image_display(VideoState *is)
 SDL_Rect rect;
 int i;
 
-vp = frame_queue_peek(&is->pictq);
+vp = frame_queue_peek_last(&is->pictq);
 if (vp->bmp) {
 if (is->subtitle_st) {
 if (frame_queue_nb_remaining(&is->subpq) > 0) {
@@ -1527,9 +1519,6 @@ static void video_refresh(void *opaque, double 
*remaining_time)
 }
 
 if (is->video_st) {
-int redisplay = 0;
-if (is->force_refresh)
-redisplay = frame_queue_prev(&is->pictq);
 retry:
 if (frame_queue_nb_remaining(&is->pictq) == 0) {
 // nothing to do, no picture to display in the queue
@@ -1543,11 +1532,10 @@ retry:
 
 if (vp->serial != is->videoq.serial) {
 frame_queue_next(&is->pictq);
-redisplay = 0;
 goto retry;
 }
 
-if (lastvp->serial != vp->serial && !redisplay)
+if (lastvp->serial != vp->serial)
 is->frame_timer = av_gettime_relative() / 100.0;
 
 if (is->paused)
@@ -1555,15 +1543,12 @@ retry:
 
 /* compute nominal last_duration */
 last_duration = vp_duration(is, lastvp, vp);
-if (redisplay)
-delay = 0.0;
-else
-delay = compute_target_delay(last_duration, is);
+delay = compute_target_delay(last_duration, is);
 
 time= av_gettime_relative()/100.0;
-if (time < is->frame_timer + delay && !redisplay) {
+if (time < is->frame_timer + delay) {
 *remaining_time = FFMIN(is->frame_timer + delay - time, 
*remaining_time);
-return;
+goto display;
 }
 
 is->frame_timer += delay;
@@ -1571,18 +1556,16 @@ retry:
 is->frame_timer = time;
 
 SDL_LockMutex(is->pictq.mutex);
-if (!redisplay && !isnan(vp->pts))
+if (!isnan(vp->pts))
 update_video_pts(is, vp->pts, vp->pos, vp->serial);
 SDL_UnlockMutex(is->pictq.mutex);
 
 if (frame_queue_nb_remaining(&is->pictq) > 1) {
 Frame *nextvp = frame_queue_peek_next(&is->pictq);
 duration = vp_duration(is, vp, nextvp);
-if(!is->step && (redisplay || framedrop>0 || (framedrop && 
get_master_sync_type(is) != AV_SYNC_VIDEO_MASTER)) && time > is->frame_timer + 
duration){
-if (!redisplay)
-is->frame_drops_late++;
+if(!is->step && (framedrop>0 || (framedrop && 
get_master_sync_type(is) != AV_SYNC_VIDEO_MASTER)) && time > is->frame_timer + 
duration){
+is->frame_drops_late++;
 frame_queue_next(&is->pictq);
-redisplay = 0;
 goto retry;
 }
 }
@@ -1607,16 +1590,16 @@ retry:
 }
 }
 
-display:
-/* display picture */
-if (!display_disable && is->show_mode == SHOW_MODE_VIDEO)
-video_display(is);
-
 frame_queue_next(&is->pictq);
+is->force_refresh = 1;
 
 if (is->step && !is->paused)
 stream_toggle_pause(is);
 }
+display:
+/* display picture */
+if (!display_disable && is->force_refresh && is->show_mode == 
SHOW_MODE_VIDEO && is->pictq.rindex_shown)
+video_display(is);
 }
 is->force_refresh = 0;
 if (show_status) {
-- 
2.6.6

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

Re: [FFmpeg-devel] [PATCH WIPv2 2/2] avdev: add sdl2 device

2016-05-22 Thread Marton Balint 


On Sat, 21 May 2016, Josh de Kock wrote:


Hi Marton,

Sorry for not updating it after we last spoke, I lost my source for the
patch so I was force to do it again. Anyways, here it is. I'm using
SDL_Events for sending the packets, using SDL_WaitEvent to throttle it,
and Conditions to make sure that the queue doesn't build up. Is there
anything I missed?


I think SDL_Init needs to be the first SDL function you call. You may try 
doing only that in write_header, to see if it works. Similarly, you may 
try moving SDL_Quit to write_trailer after joining the event 
thread and destorying all mutexes.


Some more comments below...

[...]


+case SDL_QUIT:
+sdl->quit = 1;
+break;
+case SDL_WINDOWEVENT:
+switch(event.window.event){
+case SDL_WINDOWEVENT_RESIZED:
+case SDL_WINDOWEVENT_SIZE_CHANGED:
+sdl->window_width  = event.window.data1;
+sdl->window_height = event.window.data2;
+SDL_LockMutex(sdl->mutex);


This lock is no longer necessary


+compute_texture_rect(s);
+SDL_UnlockMutex(sdl->mutex);
+break;
+default:
+break;
+}
+break;


[...]



+static int sdl2_write_header(AVFormatContext *s)
+{
+SDLContext *sdl = s->priv_data;
+AVCodecParameters *par = s->streams[0]->codecpar;
+int i, ret = 0;
+
+if (!sdl->window_title)
+sdl->window_title = av_strdup(s->filename);
+
+if (SDL_WasInit(SDL_INIT_VIDEO)) {
+av_log(s, AV_LOG_WARNING,
+   "SDL video subsystem was already inited, you could have multiple SDL 
outputs. This may cause unknown behaviour.\n");
+sdl->init_ret = AVERROR(EINVAL);
+sdl->inited = 1;


Aren't you supposed to directly return error here? Multiple outputs are 
simply not supported. (Also strdup window_title after the initialization 
check, so you don't have to free it in case of error).



+}
+
+if (   s->nb_streams > 1
+|| par->codec_type != AVMEDIA_TYPE_VIDEO
+|| par->codec_id   != AV_CODEC_ID_RAWVIDEO) {
+av_log(s, AV_LOG_ERROR, "Only supports one rawvideo stream\n");
+sdl->init_ret = AVERROR(EINVAL);
+goto fail;
+}
+
+for (i = 0; sdl_texture_pix_fmt_map[i].pix_fmt != AV_PIX_FMT_NONE; i++) {
+if (sdl_texture_pix_fmt_map[i].pix_fmt == par->format) {
+sdl->texture_fmt = sdl_texture_pix_fmt_map[i].texture_fmt;
+break;
+}
+}
+
+if (!sdl->texture_fmt) {
+av_log(s, AV_LOG_ERROR,
+   "Unsupported pixel format '%s'\n",
+   av_get_pix_fmt_name(par->format));
+sdl->init_ret = AVERROR(EINVAL);
+goto fail;
+}
+
+sdl->condition = SDL_CreateCond();
+if (!sdl->condition) {
+av_log(s, AV_LOG_ERROR, "Could not create SDL condition variable: 
%s\n", SDL_GetError());
+ret = AVERROR_EXTERNAL;
+goto fail;
+}
+sdl->mutex = SDL_CreateMutex();
+if (!sdl->mutex) {
+av_log(s, AV_LOG_ERROR, "Could not create SDL mutex: %s\n", 
SDL_GetError());
+ret = AVERROR_EXTERNAL;
+goto fail;
+}
+sdl->event_thread = SDL_CreateThread(event_thread, "event_thread", s);
+if (!sdl->event_thread) {
+av_log(s, AV_LOG_ERROR, "Could not create SDL event thread: %s\n", 
SDL_GetError());
+ret = AVERROR_EXTERNAL;
+goto fail;
+}
+
+/* Wait until the video system has been initiated. */
+SDL_LockMutex(sdl->mutex);
+while (!sdl->inited) {
+SDL_CondWait(sdl->condition, sdl->mutex);
+}
+
+SDL_UnlockMutex(sdl->mutex);
+if (sdl->init_ret < 0) {
+ret = sdl->init_ret;
+goto fail;
+}
+return 0;
+
+fail:
+sdl2_write_trailer(s);


You should also free window_title in sdl2_write_trailer as far as I see.


+return ret;
+}
+
+static int sdl2_write_packet(AVFormatContext *s, AVPacket *pkt)
+{
+SDLContext *sdl = s->priv_data;
+if(sdl->quit)
+return sdl2_write_trailer(s);


Calling write_trailer here is not necessary, the user should take care of 
that. You should simply return AVERROR(EIO) if the event thread has quit.



+
+AVPacket *ref_pkt = av_packet_alloc();
+av_packet_ref(ref_pkt, pkt);
+SDL_Event event;
+event.type = FF_PACKET_EVENT;
+event.user.data1 = ref_pkt;
+SDL_PushEvent(&event);
+
+SDL_LockMutex(sdl->mutex);
+while(!sdl->pkt_sent)
+SDL_CondWait(sdl->condition, sdl->mutex);


In order not to get locked up in this loop you should also handle the case 
when the event thread exited when you were waiting for the packet to reach 
it... You may also miss the signal, so I suggest you use CondWaitTimeout. 
Also you may have to free the packet reference somehow in this case 
yourself, probably

Re: [FFmpeg-devel] [PATCH] fate: add aecho test

2016-05-22 Thread Michael Niedermayer 
On Sun, May 22, 2016 at 08:56:18AM +, Petru Rares Sincraian wrote:
> 
> Hi Michael,
> 
> I have found some parameters that produce the same results in x64 and x32 
> architectures. Here is the patch :)

seem to work on mingw 32/64 and arm/mips qemu too
patch applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes


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

Re: [FFmpeg-devel] [PATCH] fix few compiler warnings

2016-05-22 Thread Michael Niedermayer 
On Sun, May 22, 2016 at 01:51:05AM +, Davinder Singh wrote:
> On Sun, May 22, 2016 at 2:09 AM Michael Niedermayer 
> wrote:
> 
> > On Sat, May 21, 2016 at 02:21:17PM +, Davinder Singh wrote:
> > > hi,
> > >
> > > this patch fixes following compiler warnings:
> > >
> > > libavcodec/cfhd.c:346:78: warning: format specifies type 'unsigned short'
> > > but the argument has type 'int' [-Wformat]
> > > av_log(avctx, AV_LOG_DEBUG, "Small chunk length %"PRIu16"
> > > %s\n", data * 4, tag < 0 ? "optional" : "required");
> > > ~~
> > >   ^~~~
> > > libavcodec/cfhd.c:472:110: warning: format specifies type 'unsigned
> > short'
> > > but the argument has type 'int' [-Wformat]
> > > av_log(avctx, AV_LOG_DEBUG, "Start of lowpass coeffs
> > component
> > > %"PRIu16" height:%d, width:%d\n", s->channel_num, lowpass_height,
> > > lowpass_width);
> > >
> > >  ~~^~
> > > libavcodec/cfhd.c:490:77: warning: format specifies type 'unsigned short'
> > > but the argument has type 'int' [-Wformat]
> > > av_log(avctx, AV_LOG_DEBUG, "Lowpass coefficients
> > %"PRIu16"\n",
> > > lowpass_width * lowpass_height);
> > >   ~~
> > >  ^~
> > >
> > >
> > >
> > > libavcodec/dv_tablegen.c:30:60: warning: format specifies type 'char' but
> > > the argument has type 'uint32_t' (aka 'unsigned int') [-Wformat]
> > >"{0x%"PRIx32", %"PRId8"}", data[i].vlc, data[i].size)
> > > ~~~^~~~
> > > libavcodec/tableprint.h:37:29: note: expanded from macro
> > > 'WRITE_1D_FUNC_ARGV'
> > >printf(" "fmtstr",", __VA_ARGS__);\
> > > ^~~
> > > libavcodec/dv_tablegen.c:30:60: warning: format specifies type 'char' but
> > > the argument has type 'uint32_t' (aka 'unsigned int') [-Wformat]
> > >"{0x%"PRIx32", %"PRId8"}", data[i].vlc, data[i].size)
> > > ~~~^~~~
> > >
> > >
> > >
> > > libavfilter/af_hdcd.c:896:57: warning: shifting a negative signed value
> > is
> > > undefined [-Wshift-negative-value]
> > > state->readahead = readaheadtab[bits & ~(-1 << 8)];
> > >
> > >
> > >
> > > libavfilter/vf_hwdownload.c:59:5: warning: ignoring return value of
> > > function declared with warn_unused_result attribute [-Wunused-result]
> > > ff_formats_ref(infmts,  &avctx->inputs[0]->out_formats);
> > > ^~ ~~~
> > > libavfilter/vf_hwdownload.c:60:5: warning: ignoring return value of
> > > function declared with warn_unused_result attribute [-Wunused-result]
> > > ff_formats_ref(outfmts, &avctx->outputs[0]->in_formats);
> > > ^~ ~~~
> > >
> > >
> > >
> > > libavutil/opencl.c:456:17: warning: variable 'kernel_source' is used
> > > uninitialized whenever 'for' loop exits because its condition is false
> > > [-Wsometimes-uninitialized]
> > > for (i = 0; i < opencl_ctx.kernel_code_count; i++) {
> > > ^~~~
> > > libavutil/opencl.c:466:10: note: uninitialized use occurs here
> > > if (!kernel_source) {
> > >  ^
> > > libavutil/opencl.c:456:17: note: remove the condition if it is always
> > true
> > > for (i = 0; i < opencl_ctx.kernel_code_count; i++) {
> > > ^~~~
> > > libavutil/opencl.c:448:30: note: initialize the variable 'kernel_source'
> > to
> > > silence this warning
> > > const char *kernel_source;
> > >  ^
> > >   = NULL
> >
> > >  libavcodec/cfhd.c   |6 +++---
> > >  libavcodec/dv_tablegen.c|2 +-
> > >  libavfilter/af_hdcd.c   |2 +-
> > >  libavfilter/vf_hwdownload.c |6 --
> > >  libavutil/opencl.c  |2 +-
> >
> > please split this patch
> > the fixed warnings are unrelated to each other and possibly differnt
> > developers would like to reply to different parts
> >
> > [...]
> >
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > I have often repented speaking, but never of holding my tongue.
> > -- Xenocrates
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >

>  af_hdcd.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 0ff76093ae99c1ef8ae87b70d8bf5b6ef92c43b9  
> 0003-libavfilter-af_hdcd-fixed-negative-signed-value-shif.patch
> From c498d1a86f3cdbed94cc8bc4a9af7c87af03b275 Mon Sep 17 00:00:00 2001
> From: dsmudhar 
> Date: Sun, 22 May 2016 06:18:58 +0530
> Subject: [PATCH 3/7] libavfilter/af_hdcd: fixed negative signed valu