Re: [FFmpeg-devel] [GSoC] avcodec/als: Add ALS encoder

2016-08-28 Thread Paul B Mahol 
Hi,

On Sun, Aug 28, 2016 at 10:04 AM, Umair Khan  wrote:

> Hi,
>
> Patches attached. :)


Inline asm is unacceptable to get into master.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym functions.

2016-08-28 Thread Matt Oliver 
The dlopen function is modified to prevent loading dll's from the current
directory for improved program security for library users. This extends
similar functionality from the recently applied  SetDllDirectory patch
except that it adds additional security for library users as well (as
opposed to just program users).


0001-lavf-os_support-Add-safe-win32-dlopen-dlclose-dlsym-.patch
Description: Binary data


0002-Modify-existing-dll-loading-to-use-new-safe-dlopen-f.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] [PATCH 1/2] lavc/lpc: Add min_shift parameter in LPC

2016-08-28 Thread Michael Niedermayer 
On Tue, Aug 23, 2016 at 02:32:04AM +0530, Jai Luthra wrote:
> The min_shift parameter is needed by the MLP encoder
> 
> Signed-off-by: Jai Luthra 
> ---
>  libavcodec/alacenc.c  |  4 +++-
>  libavcodec/flacenc.c  |  3 ++-
>  libavcodec/lpc.c  | 13 -
>  libavcodec/lpc.h  |  2 +-
>  libavcodec/ra144enc.c |  2 +-
>  5 files changed, 15 insertions(+), 9 deletions(-)

applied

thanks


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

No great genius has ever existed without some touch of madness. -- Aristotle


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

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

2016-08-28 Thread Paul B Mahol 
On Sat, Aug 27, 2016 at 2:45 PM, Robert Krüger 
wrote:
>
> what is the way to best contribute with test cases? I have two samples that
> I use for testing, so far the results look very, very promising but there
> are still a few artefact problems, so these could maybe serve as a good
> test case. In some cases the artefacts almost certainly look like there is
> a bug in motion vector calculation as a very large area suddenly begins to
> move in which really only a small part is/should be moving.
>
> How do I make this available to you or other devs at this stage? Just trac
> tickets or is it too early for that and you would like to work on this
> differently? After all it is always a grey area, when this can be
> considered solved, as it is a process of gradual improvements, so maybe
> it's not well-suited for a ticket.
>
> Let me know. Happy to contribute samples and some testing time here and
> there.


You can provide them either publicly or privately to any of devs interested.
I'm always interested in short samples exhibiting the problem.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym functions.

2016-08-28 Thread Michael Niedermayer 
On Sun, Aug 28, 2016 at 06:50:58PM +1000, Matt Oliver wrote:
> The dlopen function is modified to prevent loading dll's from the current
> directory for improved program security for library users. This extends
> similar functionality from the recently applied  SetDllDirectory patch
> except that it adds additional security for library users as well (as
> opposed to just program users).

>  os_support.h |   49 +
>  1 file changed, 49 insertions(+)
> 89c775ecc8ac03d001131dd50e043ba57ffe5420  
> 0001-lavf-os_support-Add-safe-win32-dlopen-dlclose-dlsym-.patch
> From 666ab2f7d64cfa94984881aca83035993365 Mon Sep 17 00:00:00 2001
> From: Matt Oliver 
> Date: Sun, 21 Aug 2016 16:06:59 +1000
> Subject: [PATCH 1/2] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym
>  functions.

breaks mingw32

In file included from src/libavformat/internal.h:28:0,
 from src/libavdevice/lavfi.c:44:
src/libavformat/os_support.h: In function ‘win32_dlopen’:
src/libavformat/os_support.h:303:46: error: 
‘LOAD_LIBRARY_SEARCH_APPLICATION_DIR’ undeclared (first use in this function)
src/libavformat/os_support.h:303:46: note: each undeclared identifier is 
reported only once for each function it appears in
src/libavformat/os_support.h:303:84: error: ‘LOAD_LIBRARY_SEARCH_SYSTEM32’ 
undeclared (first use in this function)
In file included from src/libavformat/internal.h:28:0,
 from src/libavdevice/gdigrab.c:32:
src/libavformat/os_support.h: In function ‘win32_dlopen’:
src/libavformat/os_support.h:303:46: error: 
‘LOAD_LIBRARY_SEARCH_APPLICATION_DIR’ undeclared (first use in this function)
src/libavformat/os_support.h:303:46: note: each undeclared identifier is 
reported only once for each function it appears in
src/libavformat/os_support.h:303:84: error: ‘LOAD_LIBRARY_SEARCH_SYSTEM32’ 
undeclared (first use in this function)
make: *** [libavdevice/lavfi.o] Error 1


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH 4/4] lavf/mov: Add support for edit list parsing.

2016-08-28 Thread Michael Niedermayer 
On Sat, Aug 27, 2016 at 03:30:24PM -0700, Sasi Inguva wrote:
> On Fri, Aug 26, 2016 at 5:55 PM, Michael Niedermayer  > wrote:
> 
> > On Fri, Aug 26, 2016 at 12:49:19PM -0700, Sasi Inguva wrote:
> > > I think there is some bug in mp3 decoder which is making skip
> > > samples -1431655766 for ~/tickets/5528/fire.mp3 . For now I have removed
> > > the assert from the 3rd commit.
> > > For the file one.mov , I think the audio has edit list with start time
> > > correspending to the second sample - (which should be media time 1024 if
> > I
> > > guess correctly). This indicates that the first sample be used for
> > encoder
> > > delay.
> > >  Previously without edit  list parsing , we used to offset the start_dts
> > by
> > > -1024 to make the second sample timestamp start from zero.
> > >  sc->time_offset = start_time - empty_duration;
> > > -current_dts = -sc->time_offset;
> > >  if (sc->ctts_count>0 && sc->stts_count>0 &&
> > >
> > > But now edit list parsing handles the rebasing of timestamps to zero,
> > > because it will  assign increasing timestamps  starting from zero, to
> > > samples present in the edit list.
> >
> > > Because the first sample is not in the
> > > edit list, we mark it as DISCARD, which flag av_decode_audio4 will look
> > at
> > > and decode-and-discard that frame. So it wouldn't matter what the first
> > > sample timestamp should be assigned because it is anyway discarded after
> > > decode.
> >
> > current applications using libavformat have no knowledge of the
> > discard flag you can add the DISCARD flag, you can set it on packets but
> > applications written or built for libavformat 57 dont have to know
> > this flag and can treat the packets like any other packet.
> >
> 
> Yes. they can treat the packet like any other packet. They don't have to
> know about the discard flag.
> 
> Adding this feature without a major version bump requires things to
> > still work reasonable with the old semantics that apps are build
> > around. That should be possible unless iam missing something
> 
> 
> As I have pointed out earlier this code will change the timestamps of the
> packets. In the case of multiple edit lists, the code will also repeat some
> packets, and might make the timestamps non-monotonous. I don't know if the
> last behavior is not  an acceptable expectation from av_read_frame.

if timestamps repeat then it will not be possible to seek in the file
by timestamp (to all positions) and i suspect also not by byte position.
How would one seek then ?
or do i misunderstand ?


> However as I've pointed out, we are already showing the wrong packets for
> videos with multiple edit lists by not parsing the edit lists currently,
> which will introduce AVSync issues. So this patch wont make things any
> worse for those cases in my view.

Is it difficult to adjust the timestamps of discarded packets to avoid
timestamp discontinuities ? (for the cases where this is possible of
course only)
the timestamps for discarded packets i would assume are meaningless in
the new semenatics but they matter for the old semantics 
again, please correct me if iam wrong

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

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


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

Re: [FFmpeg-devel] [GSoC] avcodec/als: Add ALS encoder

2016-08-28 Thread Umair Khan 
On Sun, Aug 28, 2016 at 1:56 PM, Paul B Mahol  wrote:
> Hi,
>
> On Sun, Aug 28, 2016 at 10:04 AM, Umair Khan  wrote:
>
>> Hi,
>>
>> Patches attached. :)
>
>
> Inline asm is unacceptable to get into master.

How should that case be handled then?

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

Re: [FFmpeg-devel] [GSoC] avcodec/als: Add ALS encoder

2016-08-28 Thread Hendrik Leppkes 
On Sun, Aug 28, 2016 at 12:48 PM, Umair Khan  wrote:
> On Sun, Aug 28, 2016 at 1:56 PM, Paul B Mahol  wrote:
>> Hi,
>>
>> On Sun, Aug 28, 2016 at 10:04 AM, Umair Khan  wrote:
>>
>>> Hi,
>>>
>>> Patches attached. :)
>>
>>
>> Inline asm is unacceptable to get into master.
>
> How should that case be handled then?
>

Convert it to YASM.

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

Re: [FFmpeg-devel] [GSoC] avcodec/als: Add ALS encoder

2016-08-28 Thread Michael Niedermayer 
On Sun, Aug 28, 2016 at 01:34:46PM +0530, Umair Khan wrote:
> Hi,
> 
> Patches attached. :)
> 
> - Umair

>  Changelog |1 +
>  1 file changed, 1 insertion(+)
> d3f30e62d803d967bd5c27dc5dfad278ce5c02e9  
> 0001-Changelog-Add-entry-for-ALS-encoder.patch
> From 020370545a82c8c1304ec9c177a75e27e59b84e8 Mon Sep 17 00:00:00 2001
> From: Umair Khan 
> Date: Sat, 27 Aug 2016 22:22:02 +0530
> Subject: [PATCH 1/2] Changelog: Add entry for ALS encoder
> 
> Signed-off-by: Umair Khan 
> ---
>  Changelog | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Changelog b/Changelog
> index b903e31..90c15ad 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -15,6 +15,7 @@ version :
>  - True Audio (TTA) muxer
>  - crystalizer audio filter
>  - acrusher audio filter
> +- ALS encoder
>  
>  
>  version 3.1:
> -- 
> 2.7.4 (Apple Git-66)
> 

[...]
> +static int calc_short_term_prediction(ALSEncContext *ctx, ALSBlock *block,
> +   int order)
> +{
> +ALSSpecificConfig *sconf = &ctx->sconf;
> +int i, j;
> +
> +int32_t *res_ptr = block->res_ptr;
> +int32_t *smp_ptr = block->cur_ptr;
> +
> +assert(order > 0);

should be av_assertX (X=0/1/2)


[...]
> +int ff_window_init(WindowContext *wctx, enum WindowType type, int length,
> +   double param)
> +{
> +if (!length || length < -1)
> +return AVERROR(EINVAL);
> +
> +wctx->type   = type;
> +wctx->length = length;
> +wctx->param  = param;
> +
> +switch (type) {
> +case WINDOW_TYPE_RECTANGLE:
> +rectangle_init(wctx);
> +break;
> +case WINDOW_TYPE_WELCH:
> +WINDOW_INIT(welch)
> +break;
> +case WINDOW_TYPE_SINERECT:
> +WINDOW_INIT(sinerect)
> +break;
> +case WINDOW_TYPE_HANNRECT:
> +WINDOW_INIT(hannrect)
> +break;
> +default:
> +return AVERROR(EINVAL);
> +}
> +

> +if (HAVE_MMX)
> +ff_window_init_mmx(wctx);

breaks build on non x86 as the function declaration / prototype is
not there in that case


[...]
> +static int als_write_trailer(struct AVFormatContext *s)
> +{
> +AVIOContext *pb = s->pb;
> +AlsEncContext *ctx = s->priv_data;

> +int header_size;
> +
> +header_size = ctx->header_size;
> +
> +if (pb->seekable) {
> +/* rewrite the header */
> +int64_t file_size   = avio_tell(pb);
> +int header_size = ctx->header_size;

there are 2 "int header_size" here


[,..]

something in this patch seems to break fate
--- ./tests/ref/fate/mpeg4-als-conformance-00   2016-08-28 12:44:08.726700510 
+0200
+++ tests/data/fate/mpeg4-als-conformance-002016-08-28 12:46:01.142702882 
+0200
@@ -1 +1 @@
-CRC=0x7e67db0b
+CRC=0x2f028a7d
Test mpeg4-als-conformance-00 failed. Look at 
tests/data/fate/mpeg4-als-conformance-00.err for details.
make: *** [fate-mpeg4-als-conformance-00] Error 1
TESTmpeg4-als-conformance-05
--- ./tests/ref/fate/mpeg4-als-conformance-02   2016-08-28 12:44:08.726700510 
+0200
+++ tests/data/fate/mpeg4-als-conformance-022016-08-28 12:46:01.166702883 
+0200
@@ -1 +1 @@
-CRC=0x7e67db0b
+CRC=0xe1118061
Test mpeg4-als-conformance-02 failed. Look at 
tests/data/fate/mpeg4-als-conformance-02.err for details.
make: *** [fate-mpeg4-als-conformance-02] Error 1
TESTamrnb-4k75
--- ./tests/ref/fate/mpeg4-als-conformance-03   2016-08-28 12:44:08.726700510 
+0200
+++ tests/data/fate/mpeg4-als-conformance-032016-08-28 12:46:01.214702884 
+0200
@@ -1 +1 @@
-CRC=0x7e67db0b
+CRC=0xf6bddab8
Test mpeg4-als-conformance-03 failed. Look at 
tests/data/fate/mpeg4-als-conformance-03.err for details.
make: *** [fate-mpeg4-als-conformance-03] Error 1
TESTamrnb-5k15
TESTamrnb-5k9
--- ./tests/ref/fate/mpeg4-als-conformance-04   2016-08-28 12:44:08.726700510 
+0200
+++ tests/data/fate/mpeg4-als-conformance-042016-08-28 12:46:01.226702884 
+0200
@@ -1 +1 @@
-CRC=0x7e67db0b
+CRC=0x0f585e71
Test mpeg4-als-conformance-04 failed. Look at 
tests/data/fate/mpeg4-als-conformance-04.err for details.
make: *** [fate-mpeg4-als-conformance-04] Error 1
TESTamrnb-6k7
TESTamrnb-7k4
--- ./tests/ref/fate/mpeg4-als-conformance-01   2016-08-28 12:44:08.726700510 
+0200
+++ tests/data/fate/mpeg4-als-conformance-012016-08-28 12:46:01.278702885 
+0200
@@ -1 +1 @@
-CRC=0x7e67db0b
+CRC=0x84528af2
TESTamrnb-10k2
Test mpeg4-als-conformance-01 failed. Look at 
tests/data/fate/mpeg4-als-conformance-01.err for details.
make: *** [fate-mpeg4-als-conformance-01] Error 1
TESTamrnb-12k2
--- ./tests/ref/fate/mpeg4-als-conformance-05   2016-08-28 12:44:08.726700510 
+0200
+++ tests/data/fate/mpeg4-als-conformance-052016-08-28 12:46:01.282702885 
+0200
@@ -1 +1 @@
-CRC=0x7e67db0b
+CRC=0xa1730577
Test mpeg4-als-conformance-05 failed. Look at 
tests/data/fate/mpeg4-als-conformance-05.err for details.
make: *** [fate-mpeg4-als-conformance-05] Error 1


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who w

[FFmpeg-devel] [RFC/PATCH]lavc/vp8: Read a frame to set pix_fmt

2016-08-28 Thread Carl Eugen Hoyos 
Hi!

Currently, FFmpeg reports "1920x1080" for 
fate-suite/vp8/frame_size_change.webm although the first 
frame is 160x90.
This is different for "--enable-libvpx --disable-decoder=vp8" 
and would be different if the sample used vp9 or h264 or hevc.
I believe this will be different once the native vp8 decoder 
supports transparency.
So I think attached patch is not unreasonable.
Strong objections?

The sample from #5803 is broken and should not be used in the 
reasoning.

Please comment, Carl Eugen
From 3eb747ad1b4ba37b4a4e0b80ce204ff0e47d0cd4 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 28 Aug 2016 13:17:08 +0200
Subject: [PATCH] lavc/vp8: Read a frame to set pix_fmt.

This is what libvpx does and what is done for other codecs with similar 
use-cases
and what will have to be done for VP8A.

Fixes ticket #5803.
---
 libavcodec/vp8.c   |2 +-
 libavcodec/webp.c  |1 +
 tests/ref/fate/vp8-size-change |   62 
 3 files changed, 33 insertions(+), 32 deletions(-)

diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index c1c3eb7..2fa7248 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -2585,6 +2585,7 @@ int vp78_decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame,
 ret = AVERROR_INVALIDDATA;
 goto err;
 }
+avctx->pix_fmt = AV_PIX_FMT_YUV420P;
 
 curframe->tf.f->key_frame = s->keyframe;
 curframe->tf.f->pict_type = s->keyframe ? AV_PICTURE_TYPE_I
@@ -2728,7 +2729,6 @@ int vp78_decode_init(AVCodecContext *avctx, int is_vp7)
 
 s->avctx = avctx;
 s->vp7   = avctx->codec->id == AV_CODEC_ID_VP7;
-avctx->pix_fmt = AV_PIX_FMT_YUV420P;
 avctx->internal->allocate_progress = 1;
 
 ff_videodsp_init(&s->vdsp, 8);
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 45abfdc..723bfb7 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -1326,6 +1326,7 @@ static int vp8_lossy_decode_frame(AVCodecContext *avctx, 
AVFrame *p,
 
 if (!s->initialized) {
 ff_vp8_decode_init(avctx);
+avctx->pix_fmt = AV_PIX_FMT_YUV420P;
 s->initialized = 1;
 if (s->has_alpha)
 avctx->pix_fmt = AV_PIX_FMT_YUVA420P;
diff --git a/tests/ref/fate/vp8-size-change b/tests/ref/fate/vp8-size-change
index 741b6d6..5105bc6 100644
--- a/tests/ref/fate/vp8-size-change
+++ b/tests/ref/fate/vp8-size-change
@@ -4,36 +4,36 @@
 #tb 0: 1/30
 #media_type 0: video
 #codec_id 0: rawvideo
-#dimensions 0: 1920x1080
+#dimensions 0: 160x90
 #sar 0: 1/1
 #stream#, dts,pts, duration, size, hash
-0,  0,  0,1,  3110400, 7dde8cd136ab4b04a95d9856b941697e
-0,  1,  1,1,  3110400, aa885f78cb6374b5bfcc66a4fc57026f
-0,  2,  2,1,  3110400, b69b7b56f549a3f9b0a603940bac85ed
-0,  3,  3,1,  3110400, 20e2e0f0c89c58828b6a3b10d9e175e5
-0,  4,  4,1,  3110400, 483997936e7d6bb849e64d50426ec689
-0,  5,  5,1,  3110400, c85ef97a853ff594e2bfdf0a0a581dcc
-0,  6,  6,1,  3110400, c5e7b9ff4c25391793446da788cb83a9
-0,  7,  7,1,  3110400, 63f93e89d24162e2f6328edbc6716b33
-0,  8,  8,1,  3110400, 0e346ab4831ce8c69001153c72b7b827
-0,  9,  9,1,  3110400, c526c21511d8bec2659d3d43d93734f2
-0, 10, 10,1,  3110400, e95d01d5f9fb81a98bd34305c7ab30f8
-0, 11, 11,1,  3110400, 177e75e7516e8746d31b43ea9d39e6b1
-0, 12, 12,1,  3110400, 489d2bc0da93f118dc9a2697275697a7
-0, 13, 13,1,  3110400, a2dc00d627350ff1ab302bcbad5ca5ac
-0, 14, 14,1,  3110400, 20ce143831b0189f763ee5bee9c51188
-0, 15, 15,1,  3110400, 7822fd908bd81b521c23fa4a639caf9e
-0, 16, 16,1,  3110400, dabc4febbe09734126ac6f5a5180ba8c
-0, 17, 17,1,  3110400, ef88f0d6667feefac1471b065208e1c8
-0, 18, 18,1,  3110400, 7c7fc665a6fd9e19af9358bbdc162a51
-0, 19, 19,1,  3110400, f2bcf32f734f99506bdd0a0376badf82
-0, 20, 20,1,  3110400, 06809c2d277fd3b3918ebb4b65c27661
-0, 21, 21,1,  3110400, e403e9e86fa5d519f65c565b3add84b5
-0, 22, 22,1,  3110400, d2b876730e12245cacb578307794349a
-0, 23, 23,1,  3110400, dfdfd8cb626a96138f6a2c1953dcf5ec
-0, 24, 24,1,  3110400, 0ac58c28575b804d9e63395653c3aef2
-0, 25, 25,1,  3110400, 641f2a78e338c733ef159bd36ec7966f
-0, 26, 26,1,  3110400, 9402d455fa5bd556b85f479c42c3a4d2
-0, 27, 27,1,  3110400, 0044d42b4048bc93112aa59789dbdc2d
-0, 28, 28,1,  3110400, 5d9e5c5ba35f6f452e5f31ccff9e819c
-0, 29, 29,1,  3110400, 307a55a94739b4

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

2016-08-28 Thread Robert Krüger 
On Sun, Aug 28, 2016 at 11:31 AM, Paul B Mahol  wrote:

> On Sat, Aug 27, 2016 at 2:45 PM, Robert Krüger 
> wrote:
> >
> > what is the way to best contribute with test cases? I have two samples
> that
> > I use for testing, so far the results look very, very promising but there
> > are still a few artefact problems, so these could maybe serve as a good
> > test case. In some cases the artefacts almost certainly look like there
> is
> > a bug in motion vector calculation as a very large area suddenly begins
> to
> > move in which really only a small part is/should be moving.
> >
> > How do I make this available to you or other devs at this stage? Just
> trac
> > tickets or is it too early for that and you would like to work on this
> > differently? After all it is always a grey area, when this can be
> > considered solved, as it is a process of gradual improvements, so maybe
> > it's not well-suited for a ticket.
> >
> > Let me know. Happy to contribute samples and some testing time here and
> > there.
>
>
> You can provide them either publicly or privately to any of devs
> interested.
> I'm always interested in short samples exhibiting the problem.
>
>
OK, here are two short samples which I used to check the suitability of
minterpolate to create super-slow-motion shots from suitable motives:

https://www.dropbox.com/s/rklhbi6zxyrvwho/reload-gun.mov?dl=1
https://www.dropbox.com/s/c7kcqd4w8ksgpqv/running.mov?dl=1

for example, I tried this:

ffmpeg -i running.mov -vf
minterpolate=fps=250:mc_mode=obmc:me=epzs:me_mode=bidir:vsbmc=1:search_param=64:mb_size=8
-c:v mpeg4 -q:v 1 -an -y running-250-obmc-bidir-sp64-mb8-vsbmc-epzs-n.mov

Both videos look very good except for a few artefacts:
1) In the reload-gun example parts of the wall (a thin strip underneath the
magazine) move which looks like incorrect motion vectors (ca. 00:00:00:090
in the result)
2) In the running example the hand shows noticeable artefacts, especially
towards the end of the video
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add myself for Motion Estimation and Interpolation filters

2016-08-28 Thread Michael Niedermayer 
On Fri, Aug 26, 2016 at 09:34:39PM +, Davinder Singh wrote:
> patch attached.

>  MAINTAINERS |5 +
>  1 file changed, 5 insertions(+)
> 51ccc94a6198acc33e77db17bf973e88f63801f5  
> 0001-MAINTAINER-add-myself-for-Motion-Estimation-and-Inte.patch
> From 8bd7fa5d13b1e1ffda957656b482d55933557d42 Mon Sep 17 00:00:00 2001
> From: dsmudhar 
> Date: Sat, 27 Aug 2016 03:00:32 +0530
> Subject: [PATCH] MAINTAINER: add myself for Motion Estimation and
>  Interpolation filters
> 
> ---
>  MAINTAINERS | 5 +
>  1 file changed, 5 insertions(+)

applied

thx

[..]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add myself for Motion Estimation and Interpolation filters

2016-08-28 Thread Michael Niedermayer 
On Fri, Aug 26, 2016 at 09:34:39PM +, Davinder Singh wrote:
> patch attached.

>  MAINTAINERS |5 +
>  1 file changed, 5 insertions(+)
> 51ccc94a6198acc33e77db17bf973e88f63801f5  
> 0001-MAINTAINER-add-myself-for-Motion-Estimation-and-Inte.patch
> From 8bd7fa5d13b1e1ffda957656b482d55933557d42 Mon Sep 17 00:00:00 2001

> From: dsmudhar 

btw, forgot to mention last time but please fix the configured
name in your git config unless you want to list dsmudhar instead of
your name as author

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [RFC/PATCH]lavc/vp8: Read a frame to set pix_fmt

2016-08-28 Thread Ronald S. Bultje 
Hi,

On Sun, Aug 28, 2016 at 7:24 AM, Carl Eugen Hoyos  wrote:

> Hi!
>
> Currently, FFmpeg reports "1920x1080" for
> fate-suite/vp8/frame_size_change.webm although the first
> frame is 160x90.
> This is different for "--enable-libvpx --disable-decoder=vp8"
> and would be different if the sample used vp9 or h264 or hevc.
> I believe this will be different once the native vp8 decoder
> supports transparency.
> So I think attached patch is not unreasonable.
> Strong objections?
>
> The sample from #5803 is broken and should not be used in the
> reasoning.
>
> Please comment, Carl Eugen


This is (IMO) mostly a terminology issue, no?

From what I recall (you didn't mention), the issue in the size-change
sample is that the demuxer reads size (AVCodecContext->width/height) from
container (which is 1920x1080), and if decoders sets
(AVCodecContext->)pix_fmt, this satisfies avformat_find_stream_info to not
decode a frame before returning. With your change, AVCodecContext->pix_fmt
is missing and thus the size (along with pix_fmt) is read from the first
frame (160x90). This size is then used by ffmpeg.c to set (default) output
size. Which of these two situations is better? I don't know. It's a
terminology issue. I don't know if there is a correct answer.

Answer me this question (without caring for what libvpx or h264 or vp8 does
right now): if a container says size=AxB for a C-frame sample with first
frame size=DxE and unknown size for any subsequent frame, and A-E are all
integers > 0 (and C > 1, and A!=D||B!=E), what should the (default) output
size be? Why?

(The patch itself is probably fine.)

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

Re: [FFmpeg-devel] [PATCH 3/3] avformat: fix decoded creation_time timestamps

2016-08-28 Thread Marton Balint 



On Tue, 23 Aug 2016, Marton Balint wrote:



On Sun, 14 Aug 2016, Marton Balint wrote:



On Fri, 1 Jul 2016, Marton Balint wrote:


Use proper ISO 8601 timestamps which also signal that they are in UTC.

This changes the format of creation_time and modification_date metadata 

values

from 2016-06-01 22:30:00 to 2016-01-01T22:30:00.00Z

Fixes ticket #5673.



I'd like to apply this soon as well. Changing the format of creation_time 
and modification_time in the metadata might be considered a hostile 
move against library users, so I would not mind some comments that it is 
OK. Maybe an entry in API changes is enough?


Thanks,
Marton


Signed-off-by: Marton Balint 
---
libavformat/matroskadec.c |  7 +--
libavformat/mov.c |  9 +
libavformat/mxfdec.c  | 14 --
libavformat/version.h |  2 +-
4 files changed, 7 insertions(+), 25 deletions(-)



Very last ping for this patch.



Applied.

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

Re: [FFmpeg-devel] [GSoC] avcodec/als: Add ALS encoder

2016-08-28 Thread James Almer 
On 8/28/2016 7:48 AM, Umair Khan wrote:
> On Sun, Aug 28, 2016 at 1:56 PM, Paul B Mahol  wrote:
>> Hi,
>>
>> On Sun, Aug 28, 2016 at 10:04 AM, Umair Khan  wrote:
>>
>>> Hi,
>>>
>>> Patches attached. :)
>>
>>
>> Inline asm is unacceptable to get into master.
> 
> How should that case be handled then?

As Hendrik said, it should be written in nasm/yasm.

In any case, assembly optimizations should be committed as a separate
patch. It will make it easier to differentiate between bugs in the c
code and the handwritten assembly.
Also, the changelog entry line can be part of the encoder patch, no
need to have it separate.

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

Re: [FFmpeg-devel] [PATCH 1/2] ffmpeg: fix -stream_loop with -re

2016-08-28 Thread Marton Balint 


On Fri, 8 Jul 2016, Michael Niedermayer wrote:


On Sun, Jul 03, 2016 at 12:33:31AM +0200, Marton Balint wrote:

Otherwise the stream failed with EAGAIN.

Signed-off-by: Marton Balint 
---
 ffmpeg.c | 4 
 1 file changed, 4 insertions(+)


i think this is ok



Pushed, thanks.

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

[FFmpeg-devel] [PATCH] avformat/mov: aax: pass proper AVClass to av_log()

2016-08-28 Thread Thomas Hebb 
av_log() expects its first parameter to be a pointer to a struct whose
first element is a pointer to an AVClass. In what I can only imagine is
a typo, one call to av_log() in the AAX decryption code instead passes
a pointer to an AVSHA struct, which doesn't even contain a pointer as
its first element, much less a pointer to an AVClass. Change the call to
pass the current MOVContext, as surrounding calls do.

The incorrect AVClass was causing mpv to emit the warning "av_log
callback called with bad parameters" when playing an .aax file.

Signed-off-by: Thomas Hebb 
---
 libavformat/mov.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 6282d8f..f499906 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -997,7 +997,7 @@ static int mov_read_adrm(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 av_log(c->fc, AV_LOG_INFO, "[aax] file checksum == "); // required by 
external tools
 for (i = 0; i < 20; i++)
-av_log(sha, AV_LOG_INFO, "%02x", file_checksum[i]);
+av_log(c->fc, AV_LOG_INFO, "%02x", file_checksum[i]);
 av_log(c->fc, AV_LOG_INFO, "\n");
 
 /* verify activation data */
-- 
2.9.3

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

[FFmpeg-devel] [PATCH 1/2] avfilter: vf_minterpolate: rename chroma log vars

2016-08-28 Thread Davinder Singh 
hi,

this rename confusing chroma variables to one used in AVPixFmtDescriptor.
more consistent.
also removed some useless vars from context.

thanks
DSM_


0001-avfilter-vf_minterpolate-rename-chroma-log-vars.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] avfilter: vf_minterpolate: fix green line issue

2016-08-28 Thread Davinder Singh 
hi,

the mv can be negative. right shifting rounds off it to -ve infinity.
changed to division, doesn't seem to affect speed at all.
this fixes the green line that appear on top or left in bidir mode. also
improved the quality by +0.08dB


thanks,
DSM_


0002-avfilter-vf_minterpolate-fix-green-line-issue.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mov: aax: pass proper AVClass to av_log()

2016-08-28 Thread Michael Niedermayer 
On Sun, Aug 28, 2016 at 12:24:55PM -0400, Thomas Hebb wrote:
> av_log() expects its first parameter to be a pointer to a struct whose
> first element is a pointer to an AVClass. In what I can only imagine is
> a typo, one call to av_log() in the AAX decryption code instead passes
> a pointer to an AVSHA struct, which doesn't even contain a pointer as
> its first element, much less a pointer to an AVClass. Change the call to
> pass the current MOVContext, as surrounding calls do.
> 
> The incorrect AVClass was causing mpv to emit the warning "av_log
> callback called with bad parameters" when playing an .aax file.
> 
> Signed-off-by: Thomas Hebb 
> ---
>  libavformat/mov.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

thx

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

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


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

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add myself for Motion Estimation and Interpolation filters

2016-08-28 Thread Davinder Singh 
On Sun, Aug 28, 2016 at 5:23 PM Michael Niedermayer 
wrote:

> On Fri, Aug 26, 2016 at 09:34:39PM +, Davinder Singh wrote:
> > patch attached.
>
> >  MAINTAINERS |5 +
> >  1 file changed, 5 insertions(+)
> > 51ccc94a6198acc33e77db17bf973e88f63801f5
> 0001-MAINTAINER-add-myself-for-Motion-Estimation-and-Inte.patch
> > From 8bd7fa5d13b1e1ffda957656b482d55933557d42 Mon Sep 17 00:00:00 2001
>
> > From: dsmudhar 
>
> btw, forgot to mention last time but please fix the configured
> name in your git config unless you want to list dsmudhar instead of
> your name as author
>

done.

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

Re: [FFmpeg-devel] [GSoC] avcodec/als: Add ALS encoder

2016-08-28 Thread Michael Niedermayer 
On Sun, Aug 28, 2016 at 12:03:38PM -0300, James Almer wrote:
[...]
> Also, the changelog entry line can be part of the encoder patch, no
> need to have it separate.

actually, i was just thinking having Changelog + version + APIChanges
changes separate from the main patch could make sense as these "always"
conflict and need an extra manual
step to work around. Having them separate makes testing slightly
simpler
not specific to this patch of course 

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

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA


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

Re: [FFmpeg-devel] [GSoC] avcodec/als: Add ALS encoder

2016-08-28 Thread James Almer 
On 8/28/2016 4:21 PM, Michael Niedermayer wrote:
> On Sun, Aug 28, 2016 at 12:03:38PM -0300, James Almer wrote:
> [...]
>> Also, the changelog entry line can be part of the encoder patch, no
>> need to have it separate.
> 
> actually, i was just thinking having Changelog + version + APIChanges
> changes separate from the main patch could make sense as these "always"
> conflict and need an extra manual
> step to work around. Having them separate makes testing slightly
> simpler
> not specific to this patch of course 

I'm not against it, but changelog+version bump should come after
the actual change and not before like in this set.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] avcodec/als: Add ALS encoder

2016-08-28 Thread Hendrik Leppkes 
On Sun, Aug 28, 2016 at 9:21 PM, Michael Niedermayer
 wrote:
> On Sun, Aug 28, 2016 at 12:03:38PM -0300, James Almer wrote:
> [...]
>> Also, the changelog entry line can be part of the encoder patch, no
>> need to have it separate.
>
> actually, i was just thinking having Changelog + version + APIChanges
> changes separate from the main patch could make sense as these "always"
> conflict and need an extra manual
> step to work around. Having them separate makes testing slightly
> simpler
> not specific to this patch of course
>

Perhaps during development, but it should really be squashed in when
its applied then.

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

Re: [FFmpeg-devel] [GSoC] avcodec/als: Add ALS encoder

2016-08-28 Thread Michael Niedermayer 
On Sun, Aug 28, 2016 at 09:50:41PM +0200, Hendrik Leppkes wrote:
> On Sun, Aug 28, 2016 at 9:21 PM, Michael Niedermayer
>  wrote:
> > On Sun, Aug 28, 2016 at 12:03:38PM -0300, James Almer wrote:
> > [...]
> >> Also, the changelog entry line can be part of the encoder patch, no
> >> need to have it separate.
> >
> > actually, i was just thinking having Changelog + version + APIChanges
> > changes separate from the main patch could make sense as these "always"
> > conflict and need an extra manual
> > step to work around. Having them separate makes testing slightly
> > simpler
> > not specific to this patch of course
> >
> 
> Perhaps during development, but it should really be squashed in when
> its applied then.

yes of course


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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

Re: [FFmpeg-devel] [PATCH 1/2] avfilter: vf_minterpolate: rename chroma log vars

2016-08-28 Thread Michael Niedermayer 
On Sun, Aug 28, 2016 at 06:24:14PM +, Davinder Singh wrote:
> hi,
> 
> this rename confusing chroma variables to one used in AVPixFmtDescriptor.
> more consistent.
> also removed some useless vars from context.
> 
> thanks
> DSM_

[...]

> @@ -900,6 +894,8 @@ static void bidirectional_obmc(MIContext *mi_ctx, int 
> alpha)
>  }
>  }
>  
> +
> +
>  static void set_frame_data(MIContext *mi_ctx, int alpha, AVFrame *avf_out)
>  {
>  int x, y, plane;

stray change


> @@ -936,8 +932,8 @@ static void set_frame_data(MIContext *mi_ctx, int alpha, 
> AVFrame *avf_out)
>  for (i = 0; i < pixel->nb; i++) {
>  Frame *frame = &mi_ctx->frames[pixel->refs[i]];
>  if (chroma) {
> -x_mv = (x >> mi_ctx->chroma_h_shift) + 
> (pixel->mvs[i][0] >> mi_ctx->chroma_h_shift);
> -y_mv = (y >> mi_ctx->chroma_v_shift) + 
> (pixel->mvs[i][1] >> mi_ctx->chroma_v_shift);
> +x_mv = (x >> mi_ctx->log2_chroma_w) + 
> (pixel->mvs[i][0] >> mi_ctx->log2_chroma_w);
> +y_mv = (y >> mi_ctx->log2_chroma_h) + 
> (pixel->mvs[i][1] >> mi_ctx->log2_chroma_h);
>  } else {
>  x_mv = x + pixel->mvs[i][0];
>  y_mv = y + pixel->mvs[i][1];
> @@ -949,7 +945,7 @@ static void set_frame_data(MIContext *mi_ctx, int alpha, 
> AVFrame *avf_out)
>  val = ROUNDED_DIV(val, weight_sum);
>  
>  if (chroma)
> -avf_out->data[plane][(x >> mi_ctx->chroma_h_shift) + (y 
> >> mi_ctx->chroma_v_shift) * avf_out->linesize[plane]] = val;
> +avf_out->data[plane][(x >> mi_ctx->log2_chroma_w) + (y 
> >> mi_ctx->log2_chroma_h) * avf_out->linesize[plane]] = val;
>  else
>  avf_out->data[plane][x + y * avf_out->linesize[plane]] = 
> val;
>  }
> @@ -1092,8 +1088,8 @@ static void interpolate(AVFilterLink *inlink, AVFrame 
> *avf_out)
>  int height = avf_out->height;
>  
>  if (plane == 1 || plane == 2) {
> -width = mi_ctx->chroma_width;
> -height = mi_ctx->chroma_height;
> +width = width >> mi_ctx->log2_chroma_w;
> +height = height >> mi_ctx->log2_chroma_h;

this is rounded differntly if wdith / height is odd,
is that intended ?

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


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

Re: [FFmpeg-devel] [PATCH 2/2] avfilter: vf_minterpolate: fix green line issue

2016-08-28 Thread Michael Niedermayer 
On Sun, Aug 28, 2016 at 06:32:21PM +, Davinder Singh wrote:
> hi,
> 
> the mv can be negative. right shifting rounds off it to -ve infinity.
> changed to division, doesn't seem to affect speed at all.
> this fixes the green line that appear on top or left in bidir mode. also
> improved the quality by +0.08dB
> 
> 
> thanks,
> DSM_

>  vf_minterpolate.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 7f04535f4aa373aa3a28cae65fff2dd2a995f10b  
> 0002-avfilter-vf_minterpolate-fix-green-line-issue.patch
> From abe0f4cbe3bf5fc85f509bdc1d0369791d9a9677 Mon Sep 17 00:00:00 2001
> From: Davinder Singh 
> Date: Sun, 28 Aug 2016 23:45:00 +0530
> Subject: [PATCH 2/2] avfilter: vf_minterpolate: fix green line issue

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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

Re: [FFmpeg-devel] Evolution of lavfi's design and API

2016-08-28 Thread Paul B Mahol 
Hi,

On Thu, Oct 30, 2014 at 1:59 PM, Michael Niedermayer 
wrote:

> On Thu, Oct 30, 2014 at 11:50:46AM +0100, Stefano Sabatini wrote:
> > Sorry for the slow reply.
> >
> > On date Wednesday 2014-10-22 23:45:42 +0200, Nicolas George encoded:
> > > [ CCing Anton, as most that is written here also apply to libav too,
> and
> > > this would be a good occasion to try a cross-fork cooperation; if that
> is
> > > not wanted, please let us know so we can drop the cc. ]
> > >
> > > 1. Problems with the current design
> > >
> > >   1.1. Mixed input-/output-driven model
> > >
> > > Currently, lavfi is designed to work in a mixed input-driven and
> > > output-driven model. That means the application needs sometimes to
> add
> > > input to buffersources and sometimes request output to
> buffersinks. This
> > > is a bit of a nuisance, because it requires the application to do
> it
> > > properly: adding input on the wrong input or requesting a frame on
> the
> > > wrong output will cause extra memory consumption or latency.
> > >
> > > With the libav API, it can not work at all since there is no
> mechanism
> > > to determine which input needs a frame in order to proceed.
> > >
> > > The libav API is clearly designed for a more output-driven
> > > implementation, with FIFOs anywhere to prevent input-driven frames
> to
> > > reach unready filters. Unfortunately, since it is impossible from
> the
> > > outside to guess what output will get a frame next, that can cause
> > > frames to accumulate anywhere in the filter graph, eating a lot of
> > > memory unnecessarily.
> > >
> > > FFmpeg's API has eliminated FIFOs in favour of queues in filters
> that
> > > need it, but these queues can not be controlled for unusual filter
> > > graphs with extreme needs. Also, there still is an implicit FIFO
> inside
> > > buffersink.
> > >
> > >   1.2. Recursive implementation
> > >
> > > All work in a filter graph is triggered by recursive invocations
> of the
> > > filters' methods. It makes debugging harder. It also can lead to
> large
> > > stack usage and makes frame- and filter-level multithreading
> harder to
> > > implement. It also prevents some diagnosis from working reliably.
> > >
> > >   1.3. EOF handling
> > >
> > > Currently, EOF is propagated only through the return value of the
> > > request_frame() method. That means it only works in an
> output-driven
> > > scheme. It also means that it has no timestamp attached to it;
> this is
> > > an issue for filters where the duration of the last frame is
> relevant,
> > > like vf_fps.
> > >
> > >   1.4. Latency
> > >
> > > Some filters need to know the timestamp of the next frame in order
> to
> > > know when the current frame will stop and be able to process it:
> > > overlay, fps are two examples. These filters will introduce a
> latency of
> > > one input frame that could otherwise be avoided.
> > >
> > >   1.5. Timestamps
> > >
> > > Some filters do not care about timestamps at all. Some check and
> have a
> > > proper handling of NOPTS values. Some filters just assume the
> frames
> > > will have timestamps, and possibly make extra assumptions on that:
> > > monotony, consistency, etc. That is an inconsistent mess.
> > >
> > >   1.6. Sparse streams
> > >
> > > There is a more severe instance of the latency issue when the input
> > > comes from an interleaved sparse stream: in that case, waiting for
> the
> > > next frame in order to find the end of the current one may require
> > > demuxing a large chunk of input, in turn provoking a lot of
> activity on
> > > other inputs of the graph.
> >
> > Other issues.
> >
>
> > S1. the filtergraph can't properly readapt to mid-stream
> > changes involving assumed invariants (aspect ratio, size, timebase,
> > pixel format, sample_rate). Indeed the framework was designed as
> > though some of these properties (the ones defined by query_formats)
> > were not allowed to change.
>
> no, no and no :)
> the filtergraph should be able adapt to some changes like aspect,
> resolution and pixel / sample format. These are not invariants, some
> of this definitly worked when i tried it long ago
> i posted a (incomplete) patchset that fixes bugs in this relation
> long ago There are filters that can perfectly well handle changes in
> resolution, aspect, formats, ...
> and there are filters which are buggy but could when they are fixed
> also equally well support such changes
> and there are filters which fundamentally do not support some changes,
> these need to either be reinited and loose state/history or a
> scale/aresample be inserted before them when changes on their input
> occur
> for some filters reinit is not appropriate, examples are things that
> are intended to collect global statistics
> Also scale / aresample filters can serve as
> "parameter change barriers", filters afterwar

Re: [FFmpeg-devel] [PATCH 1/2] avfilter: vf_minterpolate: rename chroma log vars

2016-08-28 Thread Paul B Mahol 
On Sun, Aug 28, 2016 at 10:47 PM, Michael Niedermayer <
mich...@niedermayer.cc> wrote:

> On Sun, Aug 28, 2016 at 06:24:14PM +, Davinder Singh wrote:
> > hi,
> >
> > this rename confusing chroma variables to one used in AVPixFmtDescriptor.
> > more consistent.
> > also removed some useless vars from context.
> >
> > thanks
> > DSM_
>
> [...]
>
> > @@ -900,6 +894,8 @@ static void bidirectional_obmc(MIContext *mi_ctx,
> int alpha)
> >  }
> >  }
> >
> > +
> > +
> >  static void set_frame_data(MIContext *mi_ctx, int alpha, AVFrame
> *avf_out)
> >  {
> >  int x, y, plane;
>
> stray change
>
>
> > @@ -936,8 +932,8 @@ static void set_frame_data(MIContext *mi_ctx, int
> alpha, AVFrame *avf_out)
> >  for (i = 0; i < pixel->nb; i++) {
> >  Frame *frame = &mi_ctx->frames[pixel->refs[i]];
> >  if (chroma) {
> > -x_mv = (x >> mi_ctx->chroma_h_shift) +
> (pixel->mvs[i][0] >> mi_ctx->chroma_h_shift);
> > -y_mv = (y >> mi_ctx->chroma_v_shift) +
> (pixel->mvs[i][1] >> mi_ctx->chroma_v_shift);
> > +x_mv = (x >> mi_ctx->log2_chroma_w) +
> (pixel->mvs[i][0] >> mi_ctx->log2_chroma_w);
> > +y_mv = (y >> mi_ctx->log2_chroma_h) +
> (pixel->mvs[i][1] >> mi_ctx->log2_chroma_h);
> >  } else {
> >  x_mv = x + pixel->mvs[i][0];
> >  y_mv = y + pixel->mvs[i][1];
> > @@ -949,7 +945,7 @@ static void set_frame_data(MIContext *mi_ctx, int
> alpha, AVFrame *avf_out)
> >  val = ROUNDED_DIV(val, weight_sum);
> >
> >  if (chroma)
> > -avf_out->data[plane][(x >> mi_ctx->chroma_h_shift)
> + (y >> mi_ctx->chroma_v_shift) * avf_out->linesize[plane]] = val;
> > +avf_out->data[plane][(x >> mi_ctx->log2_chroma_w) +
> (y >> mi_ctx->log2_chroma_h) * avf_out->linesize[plane]] = val;
> >  else
> >  avf_out->data[plane][x + y *
> avf_out->linesize[plane]] = val;
> >  }
> > @@ -1092,8 +1088,8 @@ static void interpolate(AVFilterLink *inlink,
> AVFrame *avf_out)
> >  int height = avf_out->height;
> >
> >  if (plane == 1 || plane == 2) {
> > -width = mi_ctx->chroma_width;
> > -height = mi_ctx->chroma_height;
> > +width = width >> mi_ctx->log2_chroma_w;
> > +height = height >> mi_ctx->log2_chroma_h;
>
> this is rounded differntly if wdith / height is odd,
> is that intended ?
>

It should use AV_CEIL_RSHIFT
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavc/mjpegdec: Only read JFIF thumbnail size if the segment is long enough.

2016-08-28 Thread Carl Eugen Hoyos 
Hi!

Attached patch fixes ticket #5805.

Please comment, Carl Eugen
From 215d45b2226cb5681be09bb4e0a2c135925ed6f5 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Mon, 29 Aug 2016 00:09:06 +0200
Subject: [PATCH] lavc/mjpegdec: Only read JFIF thumbnail size if the segment
 is long enough.

Fixes ticket #5805.
---
 libavcodec/mjpegdec.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 633a8f0..515d2f8 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -1690,6 +1690,8 @@ static int mjpeg_decode_app(MJpegDecodeContext *s)
s->avctx->sample_aspect_ratio.num,
s->avctx->sample_aspect_ratio.den);
 
+len -= 8;
+if (len >= 2) {
 t_w = get_bits(&s->gb, 8);
 t_h = get_bits(&s->gb, 8);
 if (t_w && t_h) {
@@ -1697,7 +1699,8 @@ static int mjpeg_decode_app(MJpegDecodeContext *s)
 if (len -10 - (t_w * t_h * 3) > 0)
 len -= t_w * t_h * 3;
 }
-len -= 10;
+len -= 2;
+}
 goto out;
 }
 
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] added expr evaluation to drawtext - fontsize

2016-08-28 Thread Michael Niedermayer 
On Sat, Aug 27, 2016 at 04:30:05PM -0700, Brett Harrison wrote:
> Fixed patch based on comments.
> 
> This time attaching patch file.
> 
> On Sat, Aug 27, 2016 at 6:21 AM, Moritz Barsnick  wrote:
> 
> > On Fri, Aug 26, 2016 at 14:37:42 -0700, Brett Harrison wrote:
> >
> > > +if (diff != 0) {
> > > +  return diff > 0 ? 1 : diff < 0 ? -1 : 0;
> > > +}
> >
> > If diff != 0, it can only be >0 or <0, nothing else:
> >if (diff != 0)
> >  return diff > 0 ? 1 : -1;
> > (And you can drop the curly brackets.)
> >
> > > +else {
> > > +  int64_t diff = (int64_t)a->fontsize - (int64_t)bb->fontsize;
> > > +  return diff > 0 ? 1 : diff < 0 ? -1 : 0;
> > > +}
> >
> > There's a macro for this:
> >else
> >return FFDIFFSIGN((int64_t)a->fontsize, (int64_t)bb->fontsize);
> >
> > Moritz
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >

>  vf_drawtext.c |   86 
> +-
>  1 file changed, 79 insertions(+), 7 deletions(-)
> dd219d9b4d4f02ca4299a0bfd6ea3d5c15545f2b  
> 0001-added-expr-evaluation-to-drawtext-fontsize.patch
> From 5c9d7d18a5d2f15f48605021d7f5a7890a318cc4 Mon Sep 17 00:00:00 2001
> From: Brett Harrison 
> Date: Fri, 26 Aug 2016 14:29:34 -0700
> Subject: [PATCH] added expr evaluation to drawtext - fontsize

this changes the output and fontsize when fontsize is not explicitly
specified

for example:
-vf drawtext=text=abc:fontcolor=white


> 
> ---
>  libavfilter/vf_drawtext.c | 86 
> +++
>  1 file changed, 79 insertions(+), 7 deletions(-)
> 
> diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
> index 214aef0..5311e29 100644
> --- a/libavfilter/vf_drawtext.c
> +++ b/libavfilter/vf_drawtext.c
> @@ -156,6 +156,8 @@ typedef struct DrawTextContext {
>  int max_glyph_h;///< max glyph height
>  int shadowx, shadowy;
>  int borderw;///< border width
> +char *fontsize_expr;///< expression for fontsize
> +AVExpr *fontsize_pexpr; ///< parsed expressions for fontsize
>  unsigned int fontsize;  ///< font size to use
>  
>  short int draw_box; ///< draw box around text - true or false
> @@ -209,7 +211,7 @@ static const AVOption drawtext_options[]= {
>  {"shadowcolor", "set shadow color", OFFSET(shadowcolor.rgba),   
> AV_OPT_TYPE_COLOR,  {.str="black"}, CHAR_MIN, CHAR_MAX, FLAGS},
>  {"box", "set box",  OFFSET(draw_box),   
> AV_OPT_TYPE_BOOL,   {.i64=0}, 0,1   , FLAGS},
>  {"boxborderw",  "set box border width", OFFSET(boxborderw), 
> AV_OPT_TYPE_INT,{.i64=0}, INT_MIN,  INT_MAX , FLAGS},
> -{"fontsize","set font size",OFFSET(fontsize),   
> AV_OPT_TYPE_INT,{.i64=0}, 0,INT_MAX , FLAGS},
> +{"fontsize","set font size",OFFSET(fontsize_expr),  
> AV_OPT_TYPE_STRING, {.str="16"},  CHAR_MIN, CHAR_MAX , FLAGS},
>  {"x",   "set x expression", OFFSET(x_expr), 
> AV_OPT_TYPE_STRING, {.str="0"},   CHAR_MIN, CHAR_MAX, FLAGS},
>  {"y",   "set y expression", OFFSET(y_expr), 
> AV_OPT_TYPE_STRING, {.str="0"},   CHAR_MIN, CHAR_MAX, FLAGS},
>  {"shadowx", "set shadow x offset",  OFFSET(shadowx),
> AV_OPT_TYPE_INT,{.i64=0}, INT_MIN,  INT_MAX , FLAGS},
> @@ -280,6 +282,7 @@ typedef struct Glyph {
>  FT_Glyph glyph;
>  FT_Glyph border_glyph;
>  uint32_t code;
> +unsigned int fontsize;
>  FT_Bitmap bitmap; ///< array holding bitmaps of font
>  FT_Bitmap border_bitmap; ///< array holding bitmaps of font border
>  FT_BBox bbox;
> @@ -292,7 +295,11 @@ static int glyph_cmp(const void *key, const void *b)
>  {
>  const Glyph *a = key, *bb = b;
>  int64_t diff = (int64_t)a->code - (int64_t)bb->code;
> -return diff > 0 ? 1 : diff < 0 ? -1 : 0;
> +
> +if (diff != 0)
> + return diff > 0 ? 1 : -1;
> +else
> + return FFDIFFSIGN((int64_t)a->fontsize, (int64_t)bb->fontsize);
>  }
>  
>  /**
> @@ -316,6 +323,7 @@ static int load_glyph(AVFilterContext *ctx, Glyph 
> **glyph_ptr, uint32_t code)
>  goto error;
>  }
>  glyph->code  = code;
> +glyph->fontsize = s->fontsize;
>  
>  if (FT_Get_Glyph(s->face->glyph, &glyph->glyph)) {
>  ret = AVERROR(EINVAL);
> @@ -591,12 +599,62 @@ out:
>  }
>  #endif
>  
> +static av_cold int set_fontsize(AVFilterContext *ctx)
> +{
> +int err;
> +DrawTextContext *s = ctx->priv;
> +
> +if (s->face == NULL) {
> +av_log(ctx, AV_LOG_ERROR, "Font not open\n");
> +return AVERROR(EINVAL);
> +}
> +
> +if ((err = FT_Set_Pixel_Sizes(s->face, 0, s->fontsize))) {
> +av_log(ctx, AV_LOG_ERROR, "Could not set

[FFmpeg-devel] The patch fixed the cases of encounter mdat/trak without "moov" or "root"

2016-08-28 Thread chengmo 
Hi All:

I found the patch 'Reimar Döffinger' reimar.doeffin...@gmx.de
  did for ffmpeg in 2012

The url is here:

https://ffmpeg.org/pipermail/ffmpeg-cvslog/2012-March/048841.html

 

the problem about “MOV: bail out to toplevel when encountering a trak
or mdat chunk.”

 

The patch fixed the cases of encounter mdat/trak without “moov” or “root”

Now I use -movflags
“frag_keyframe+empty_moov+default_base_moof+separate_moof”

It will encounter “moof” atom, the fragment including the pairs of moof and
mdat atoms.

 

Should it treated like the way to moov  ? 

Is there could be a mistake so far ? 

I didn’t found it fixed.

 

Mo

 

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

[FFmpeg-devel] [PATCH] configure: Remove fifo muxers dependency on pthreads.

2016-08-28 Thread Matt Oliver 
The fifo muxer works without pthreads due to the existing pthread wrappers
already available within ffmpeg for other platforms.

---
 configure | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configure b/configure
index 5c11040..e225b7d 100755
--- a/configure
+++ b/configure
@@ -2834,7 +2834,6 @@ dv_muxer_select="dvprofile"
 dxa_demuxer_select="riffdec"
 eac3_demuxer_select="ac3_parser"
 f4v_muxer_select="mov_muxer"
-fifo_muxer_deps="pthreads"
 flac_demuxer_select="flac_parser"
 hds_muxer_select="flv_muxer"
 hls_muxer_select="mpegts_muxer"
--


0001-configure-Remove-fifo-muxers-dependency-on-pthreads.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: Remove fifo muxers dependency on pthreads.

2016-08-28 Thread Hendrik Leppkes 
On Mon, Aug 29, 2016 at 8:17 AM, Matt Oliver  wrote:
> The fifo muxer works without pthreads due to the existing pthread wrappers
> already available within ffmpeg for other platforms.
>

It should probably still depend on "threads" at least, assuming the
thread-wrapper we have provides enough threading features for the
muxer.

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

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

2016-08-28 Thread Clément Bœsch 
On Sun, Aug 28, 2016 at 11:31:10AM +0200, Paul B Mahol wrote:
> On Sat, Aug 27, 2016 at 2:45 PM, Robert Krüger 
> wrote:
> >
> > what is the way to best contribute with test cases? I have two samples that
> > I use for testing, so far the results look very, very promising but there
> > are still a few artefact problems, so these could maybe serve as a good
> > test case. In some cases the artefacts almost certainly look like there is
> > a bug in motion vector calculation as a very large area suddenly begins to
> > move in which really only a small part is/should be moving.
> >
> > How do I make this available to you or other devs at this stage? Just trac
> > tickets or is it too early for that and you would like to work on this
> > differently? After all it is always a grey area, when this can be
> > considered solved, as it is a process of gradual improvements, so maybe
> > it's not well-suited for a ticket.
> >
> > Let me know. Happy to contribute samples and some testing time here and
> > there.
> 
> 
> You can provide them either publicly or privately to any of devs interested.
> I'm always interested in short samples exhibiting the problem.

Using http://b.pkh.me/sfx-sky.mov and comparing:

  ./ffplay -flags2 +export_mvs sfx-sky.mov -vf codecview=mv=pf

with

  ./ffplay sfx-sky.mov -vf mestimate,codecview=mv=pf

The encoded mvs looks much more meaningful that the ones found with
mestimate. Typically, if you're looking for a global motion of some sort,
the "native" mvs makes much more clear that there is a mostly static area
at the bottom and a panning one on top with its direction pretty obvious.
With mestimate, it just looks like small noise. Any plan to improve this?

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym functions.

2016-08-28 Thread Matt Oliver 
On 28 August 2016 at 19:58, Michael Niedermayer 
wrote:

> On Sun, Aug 28, 2016 at 06:50:58PM +1000, Matt Oliver wrote:
> > The dlopen function is modified to prevent loading dll's from the current
> > directory for improved program security for library users. This extends
> > similar functionality from the recently applied  SetDllDirectory patch
> > except that it adds additional security for library users as well (as
> > opposed to just program users).
>
> >  os_support.h |   49 +
> >  1 file changed, 49 insertions(+)
> > 89c775ecc8ac03d001131dd50e043ba57ffe5420  0001-lavf-os_support-Add-safe-
> win32-dlopen-dlclose-dlsym-.patch
> > From 666ab2f7d64cfa94984881aca83035993365 Mon Sep 17 00:00:00 2001
> > From: Matt Oliver 
> > Date: Sun, 21 Aug 2016 16:06:59 +1000
> > Subject: [PATCH 1/2] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym
> >  functions.
>
> breaks mingw32
>
> In file included from src/libavformat/internal.h:28:0,
>  from src/libavdevice/lavfi.c:44:
> src/libavformat/os_support.h: In function ‘win32_dlopen’:
> src/libavformat/os_support.h:303:46: error: 
> ‘LOAD_LIBRARY_SEARCH_APPLICATION_DIR’
> undeclared (first use in this function)
> src/libavformat/os_support.h:303:46: note: each undeclared identifier is
> reported only once for each function it appears in
> src/libavformat/os_support.h:303:84: error:
> ‘LOAD_LIBRARY_SEARCH_SYSTEM32’ undeclared (first use in this function)
> In file included from src/libavformat/internal.h:28:0,
>  from src/libavdevice/gdigrab.c:32:
> src/libavformat/os_support.h: In function ‘win32_dlopen’:
> src/libavformat/os_support.h:303:46: error: 
> ‘LOAD_LIBRARY_SEARCH_APPLICATION_DIR’
> undeclared (first use in this function)
> src/libavformat/os_support.h:303:46: note: each undeclared identifier is
> reported only once for each function it appears in
> src/libavformat/os_support.h:303:84: error:
> ‘LOAD_LIBRARY_SEARCH_SYSTEM32’ undeclared (first use in this function)
> make: *** [libavdevice/lavfi.o] Error 1
>

It appears older versions of mingw must not have the appropriate defines
(as the version i tested against worked fine).
Anyway updated patch attached which corrects the issue.


0001-lavf-os_support-Add-safe-win32-dlopen-dlclose-dlsym-.patch
Description: Binary data


0002-Modify-existing-dll-loading-to-use-new-safe-dlopen.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: Remove fifo muxers dependency on pthreads.

2016-08-28 Thread Carl Eugen Hoyos 
Hi!

2016-08-29 8:17 GMT+02:00 Matt Oliver :
> The fifo muxer works without pthreads due to the existing pthread
> wrappers already available within ffmpeg for other platforms.

How did you test this?
(How can I test?)

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