Re: [FFmpeg-devel] [PATCH] lavfi/framequeue: avoid empty structs.

2016-12-19 Thread Matt Oliver 
On 19 December 2016 at 18:58, Nicolas George  wrote:

> Le nonidi 29 frimaire, an CCXXV, Nicolas George a écrit :
> > Fix compilation on MSVC.
>
> Forgot to write in the comment beore sending: this is obviously
> untested.
>

tested and it fixes the issue. LGTM.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3] af_hdcd: more FATE tests

2016-12-19 Thread Burt P. 
On Sun, Dec 18, 2016 at 6:54 PM, Michael Niedermayer
 wrote:
> On Sun, Dec 18, 2016 at 12:48:45PM -0600, Burt P wrote:
>> Additional/Modified FATE tests improve code coverage from 63.7% to 98.1%.
>>
>> Changed fate-suite sample files:
>> * filter/hdcd-encoding-errors.flac (1.3M) replaced by
>>   a smaller version (140K). It can be replaced because the test
>>   only looks for a non-zero number of errors, so the existing test
>>   will still pass.
>
> IMO replacing files is not ok
> it would change all past instances of the related fate test
> a bug report refering to a fate failure could become unreproduceable
> or otherwise working fate tests could start failing ...
> as much as i prefer to safe a few bytes in this case i prefer to waste
> some space over the potential problems
>
> you can add files, but not remove or replace unless they are truly
> unused by every past checkout

Well, I don't mind if it is kept, I was just trying to offset the additions.
I understand why removing or replacing samples is generally not a good
idea, but I would point out that in this case, the file could be replaced
without changing the result in any past revision of the test.
This particular test outcome is determined by grepping a line out of the
log that reports the number of errors encountered, and it only has to be
non-zero, so the shorter sample with fewer errors (but at least one) still
passes any old revision.

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

[FFmpeg-devel] [PATCH] avutil: Added selftest for libavutil/audio_fifo.c

2016-12-19 Thread Thomas Turner 
Signed-off-by: Thomas Turner 
---
 libavutil/Makefile   |   1 +
 libavutil/tests/audio_fifo.c | 195 
 tests/fate/libavutil.mak |   4 +
 tests/ref/fate/audio_fifo| 228 +++
 4 files changed, 428 insertions(+)
 create mode 100644 libavutil/tests/audio_fifo.c
 create mode 100644 tests/ref/fate/audio_fifo

diff --git a/libavutil/Makefile b/libavutil/Makefile
index 9841645..2dd91b8 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -182,6 +182,7 @@ SKIPHEADERS-$(CONFIG_OPENCL)   += opencl.h
 TESTPROGS = adler32 \
 aes \
 atomic  \
+audio_fifo  \
 avstring\
 base64  \
 blowfish\
diff --git a/libavutil/tests/audio_fifo.c b/libavutil/tests/audio_fifo.c
new file mode 100644
index 000..7e166b1
--- /dev/null
+++ b/libavutil/tests/audio_fifo.c
@@ -0,0 +1,195 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+#include 
+#include 
+#include "libavutil/audio_fifo.c"
+
+#define MAX_CHANNELS32
+
+#define ERROR(str)\
+fprintf(stderr, "%s\n", str); \
+exit(1);
+
+typedef struct TestStruct {
+const enum AVSampleFormat format;
+const int nb_ch;
+void const *data_planes[MAX_CHANNELS];
+int nb_samples_pch;
+} TestStruct;
+
+static const uint8_t data_U8 [] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
};
+static const int16_t data_S16[] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
};
+static const float   data_FLT[] = {0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 
8.0, 9.0, 10.0, 11.0};
+
+
+static const TestStruct test_struct[] = {
+{.format = AV_SAMPLE_FMT_U8   , .nb_ch = 1, .data_planes = {data_U8 ,  
   }, .nb_samples_pch = 12},
+{.format = AV_SAMPLE_FMT_U8P  , .nb_ch = 2, .data_planes = {data_U8 , 
data_U8 +6, }, .nb_samples_pch = 6 },
+{.format = AV_SAMPLE_FMT_S16  , .nb_ch = 1, .data_planes = {data_S16,  
   }, .nb_samples_pch = 12},
+{.format = AV_SAMPLE_FMT_S16P , .nb_ch = 2, .data_planes = {data_S16, 
data_S16+6, }, .nb_samples_pch = 6 },
+{.format = AV_SAMPLE_FMT_FLT  , .nb_ch = 1, .data_planes = {data_FLT,  
   }, .nb_samples_pch = 12},
+{.format = AV_SAMPLE_FMT_FLTP , .nb_ch = 2, .data_planes = {data_FLT, 
data_FLT+6, }, .nb_samples_pch = 6 }
+};
+
+static void* allocate_memory(size_t size)
+{
+void *ptr = malloc(size);
+if (ptr == NULL){
+fprintf(stderr, "failed to allocate memory!\n");
+exit(1);
+}
+return ptr;
+}
+
+static void print_audio_bytes(const TestStruct *test_sample, void 
**data_planes, int nb_samples)
+{
+int p, b, f;
+int byte_offset  = av_get_bytes_per_sample(test_sample->format);
+int buffers  = av_sample_fmt_is_planar(test_sample->format) 
+ ? test_sample->nb_ch : 1;
+int line_size= (buffers > 1) ? nb_samples * byte_offset
+ : nb_samples * byte_offset * 
test_sample->nb_ch;
+for (p = 0; p < buffers; ++p){
+for(b = 0; b < line_size; b+=byte_offset){
+for (f = 0; f < byte_offset; f++){
+int order = !HAVE_BIGENDIAN ? (byte_offset - f - 1) : f;
+printf("%02x", *((uint8_t*)data_planes[p] + b + order));
+}
+putchar(' ');
+}
+putchar('\n');
+}
+}
+
+static int read_samples_from_audio_fifo(AVAudioFifo* afifo, void ***output, 
int nb_samples)
+{
+int i, planes;
+int samples= FFMIN(nb_samples, afifo->nb_samples);
+int tot_elements   = !(planes = av_sample_fmt_is_planar(afifo->sample_fmt))
+ ? samples : afifo->channels * samples;
+void **data_planes = allocate_memory(sizeof(void*) * planes);
+*output=

[FFmpeg-devel] [PATCH] avutil: Improved test coverage for avstring.c

2016-12-19 Thread Thomas Turner 
Signed-off-by: Thomas Turner 
---
 libavutil/tests/avstring.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/libavutil/tests/avstring.c b/libavutil/tests/avstring.c
index 1242b3f..290b170 100644
--- a/libavutil/tests/avstring.c
+++ b/libavutil/tests/avstring.c
@@ -25,7 +25,7 @@
 int main(void)
 {
 int i;
-char *fullpath;
+char *fullpath, *ptr;
 static const char * const strings[] = {
 "''",
 "",
@@ -54,6 +54,8 @@ int main(void)
 "'\\fo\\o:': blahblah",
 "\\'fo\\o\\:':  foo  '  :blahblah"
 };
+const char *haystack = "Education consists mainly in what we have 
unlearned.";
+const char * const needle[] = {"learned.", "unlearned.", "Unlearned"};
 
 printf("Testing av_get_token()\n");
 for (i = 0; i < FF_ARRAY_ELEMS(strings); i++) {
@@ -79,5 +81,27 @@ int main(void)
 TEST_APPEND_PATH_COMPONENT("path", "/comp", "path/comp");
 TEST_APPEND_PATH_COMPONENT("path/", "/comp", "path/comp");
 TEST_APPEND_PATH_COMPONENT("path/path2/", "/comp/comp2", 
"path/path2/comp/comp2");
+
+/*Testing av_strnstr()*/
+#define TEST_STRNSTR(haystack, needle, hay_length, expected) \
+ptr = av_strnstr(haystack, needle, hay_length); \
+if (ptr != expected){ \
+printf("expected: %p, received %p\n", expected, ptr); \
+}
+TEST_STRNSTR(haystack, needle [0], strlen(haystack), haystack+44);
+TEST_STRNSTR(haystack, needle [1], strlen(haystack), haystack+42);
+TEST_STRNSTR(haystack, needle [2], strlen(haystack), NULL   );
+TEST_STRNSTR(haystack, strings[1], strlen(haystack), haystack   );
+
+/*Testing av_d2str()*/
+#define TEST_D2STR(value, expected) \
+if((ptr = av_d2str(value)) == NULL){ \
+printf("error, received null pointer!\n"); \
+} else if(strcmp(ptr, expected) != 0){ \
+printf( "expected: %s, received: %s\n", expected, ptr); \
+}
+TEST_D2STR(0 ,  "0.00");
+TEST_D2STR(-1.2333234, "-1.233323");
+TEST_D2STR(-1.2333237, "-1.233324");
 return 0;
 }
-- 
1.9.1

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

[FFmpeg-devel] [PATCH]lavu/internal: Never use %t and %z on Windows

2016-12-19 Thread Carl Eugen Hoyos 
Hi!

Attached patch is supposed to fix an issue reported by Blake Senftner 
on libav-user.

Please comment, Carl Eugen
From dbb730692ebb81377bc3db0df50b3c32ca0def16 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 20 Dec 2016 03:11:54 +0100
Subject: [PATCH] lavu/internal: Never use %t or %z format specifiers, not
 even with mingw.

Fixes using an av_log() callback with mingw libraries in Visual Studio.
---
 configure|2 ++
 libavutil/internal.h |3 +++
 2 files changed, 5 insertions(+)

diff --git a/configure b/configure
index 9dfd006..70993de 100755
--- a/configure
+++ b/configure
@@ -2052,6 +2052,8 @@ HAVE_LIST="
 dos_paths
 dxva2_lib
 dxva2api_cobj
+libc_mingw32
+libc_mingw64
 libc_msvcrt
 libdc1394_1
 libdc1394_2
diff --git a/libavutil/internal.h b/libavutil/internal.h
index e995af9..e994e8a 100644
--- a/libavutil/internal.h
+++ b/libavutil/internal.h
@@ -245,6 +245,9 @@ void avpriv_request_sample(void *avc,
 
 #define avpriv_open ff_open
 #define avpriv_tempfile ff_tempfile
+#endif
+
+#if HAVE_LIBC_MSVCRT || HAVE_LIBC_MINGW32 || HAVE_LIBC_MINGW64
 #define PTRDIFF_SPECIFIER "Id"
 #define SIZE_SPECIFIER "Iu"
 #else
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] swscale: also save ebx register when using PIE

2016-12-19 Thread Michael Niedermayer 
On Mon, Dec 19, 2016 at 11:28:44PM +0100, Andreas Cadhalpun wrote:
> On 16.12.2016 04:08, Michael Niedermayer wrote:
> > On Fri, Dec 16, 2016 at 02:36:53AM +0100, Andreas Cadhalpun wrote:
> >> Otherwise the build fails when configuring with --toolchain=hardened
> >> --disable-pic on i386 using gcc 4.8:
> >> error: PIC register clobbered by '%ebx' in 'asm'
> >>
> >> Signed-off-by: Andreas Cadhalpun 
> >> ---
> >>  libswscale/x86/hscale_fast_bilinear_simd.c | 20 ++--
> >>  1 file changed, 10 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/libswscale/x86/hscale_fast_bilinear_simd.c 
> >> b/libswscale/x86/hscale_fast_bilinear_simd.c
> >> index 2cba5f0..3f0f5f5 100644
> >> --- a/libswscale/x86/hscale_fast_bilinear_simd.c
> >> +++ b/libswscale/x86/hscale_fast_bilinear_simd.c
> >> @@ -199,7 +199,7 @@ void ff_hyscale_fast_mmxext(SwsContext *c, int16_t 
> >> *dst,
> >>  #if ARCH_X86_64
> >>  uint64_t retsave;
> >>  #else
> >> -#if defined(PIC)
> >> +#if defined(PIC) || defined(__PIE__)
> > 
> > please correct me if iam wrong
> > our configure adds -DPIC to define PIC when its enabled,
> > it does not add that in this case but gcc is still generating PIC code
> > that doesnt seem good
> 
> gcc does not generate PIC, only PIE, which is subtly different.

does all the code under PIC work with
PIE that does not have PIC set ?
the identifier seems used a bit in .asm files


> 
> What's wrong here is that this code in swscale tries to determine, whether
> or not the ebx register can be used for asm, but doesn't check that correctly.
> However, configure has a working check for that, the result of which can
> be used here. Patch doing that is attached.

i see your argument for this and it seems sound.
I hope this doesnt break anything as this logic was that way for a
really long time and worked fine and gcc inline asm can be annoying
that said, no objections to the patch 


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


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] wmavoice: don't error out if we're skipping more bits than available.

2016-12-19 Thread Carl Eugen Hoyos 
2016-12-20 1:10 GMT+01:00 Andreas Cadhalpun :
> On 20.12.2016 00:59, Carl Eugen Hoyos wrote:
>> 2016-12-19 23:45 GMT+01:00 Andreas Cadhalpun 
>> :
>>> On 16.12.2016 14:19, Ronald S. Bultje wrote:
 This reverts 2a4700a4f03280fa8ba4fc0f8a9987bb550f0d1e and implements it
 correctly so streams actually decode the way the encoder intended them
 to.
>>>
>>> Why is it correct?
>>
>> Because the patch introduced an (imo horrible) regression,
>
> I don't think that not triggering an av_assert0 is a regression.
>
>> files that before reported why they couldn't be played suddenly
>> gave no explanation, just a useless error message.
>
> An error message is not no explanation.

Sorry!

I was seriously expecting Ronald to fix 04e9853a
- an untested broken change - but I was wrong.

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

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

2016-12-19 Thread Andreas Cadhalpun 
On 18.12.2016 13:22, Nicolas George wrote:
> av_buffersink_get_frame_rate() did already exist; its argument becomes const.
> 
> TODO minor version bump
> 
> API-Change: libavfilter
> Signed-off-by: Nicolas George 
> ---
>  libavfilter/buffersink.c | 25 +++--
>  libavfilter/buffersink.h | 22 --
>  2 files changed, 39 insertions(+), 8 deletions(-)
> 
> 
> I think the const change is acceptable.

I'm not aware of a user outside of ffmpeg and const changes shouldn't cause big
problems, as only the API changes, not the ABI. So it is probably OK.

> Note: I am introducing the "API-Change" Git tag: I think it will be much
> more convenient than maintaining doc/APIchanges. Later I intend to write a
> script using git log --grep to pretty print it.

I'm not convinced that this is more convenient. APIchanges can still be
changed after a commit, but the commit message can't. Also it can only replace
APIchanges when everyone (including Libav) uses it.
So I'd prefer if you added an APIchanges entry in addition to using this tag.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] wmavoice: don't error out if we're skipping more bits than available.

2016-12-19 Thread Andreas Cadhalpun 
On 20.12.2016 00:59, Carl Eugen Hoyos wrote:
> 2016-12-19 23:45 GMT+01:00 Andreas Cadhalpun 
> :
>> On 16.12.2016 14:19, Ronald S. Bultje wrote:
>>> This reverts 2a4700a4f03280fa8ba4fc0f8a9987bb550f0d1e and implements it
>>> correctly so streams actually decode the way the encoder intended them
>>> to.
>>
>> Why is it correct?
> 
> Because the patch introduced an (imo horrible) regression,

I don't think that not triggering an av_assert0 is a regression.

> files that before reported why they couldn't be played suddenly
> gave no explanation, just a useless error message.

An error message is not no explanation.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH 2/2] wmavoice: don't error out if we're skipping more bits than available.

2016-12-19 Thread Carl Eugen Hoyos 
2016-12-19 23:45 GMT+01:00 Andreas Cadhalpun :
> On 16.12.2016 14:19, Ronald S. Bultje wrote:
>> This reverts 2a4700a4f03280fa8ba4fc0f8a9987bb550f0d1e and implements it
>> correctly so streams actually decode the way the encoder intended them
>> to.
>
> Why is it correct?

Because the patch introduced an (imo horrible) regression, files
that before reported why they couldn't be played suddenly gave
no explanation, just a useless error message.

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavfi: make filter_frame non-recursive.

2016-12-19 Thread Michael Niedermayer 
On Tue, Dec 20, 2016 at 12:33:41AM +0100, Michael Niedermayer wrote:
> On Mon, Dec 19, 2016 at 11:56:27PM +0100, Nicolas George wrote:
> > Le nonidi 29 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > > i dont know if this is a bug or just somethig that by sheer bad luck
> > > becomes vissible after this but
> > > ./ffmpeg -i cvid/dday.mov -vframes 30  -vcodec huffyuv -y -acodec 
> > > pcm_s16le out3b.avi ; md5sum out3b.avi
> > > gives different outputs from time to time
> > > needs threads on the encoder side, huffyuv, vframes (audio codec 
> > > irrelevant)
> > > 
> > > difference in output files looks like this:
> > > valgrind shows nothing (but difference occurs under valgrind)
> > > should be here:
> > > http://samples.ffmpeg.org/V-codecs/CVID/grayscale/dday.mov
> > 
> > I know there are a few glitches that came through. I have started
> > working on fixing the worst one, it requires making buffersink aware of
> > EOF one step earlier.
> > 
> 
> > As for this one and the one you posted a few minutes ago: -vframes with
> > audio frames too is highly dependant on details of the filters
> > scheduling, and can change slightly under perfectly normal
> > circumstances, starting with threading.
> 
> heres another similar issue
> ./ffmpeg -i ~/tickets/860/jpeg2000.mov -vframes 3  -vcodec huffyuv -y test.avi
> 
> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket860/jpeg2000.mov

(to clarify, the output of this one changes here between runs)

can some bitexact flag be used to eliminate these (admitably) rare
cases ?


[...]

-- 
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] [FFmpeg-cvslog] lavfi: make filter_frame non-recursive.

2016-12-19 Thread Michael Niedermayer 
On Mon, Dec 19, 2016 at 11:56:27PM +0100, Nicolas George wrote:
> Le nonidi 29 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > i dont know if this is a bug or just somethig that by sheer bad luck
> > becomes vissible after this but
> > ./ffmpeg -i cvid/dday.mov -vframes 30  -vcodec huffyuv -y -acodec pcm_s16le 
> > out3b.avi ; md5sum out3b.avi
> > gives different outputs from time to time
> > needs threads on the encoder side, huffyuv, vframes (audio codec irrelevant)
> > 
> > difference in output files looks like this:
> > valgrind shows nothing (but difference occurs under valgrind)
> > should be here:
> > http://samples.ffmpeg.org/V-codecs/CVID/grayscale/dday.mov
> 
> I know there are a few glitches that came through. I have started
> working on fixing the worst one, it requires making buffersink aware of
> EOF one step earlier.
> 

> As for this one and the one you posted a few minutes ago: -vframes with
> audio frames too is highly dependant on details of the filters
> scheduling, and can change slightly under perfectly normal
> circumstances, starting with threading.

heres another similar issue
./ffmpeg -i ~/tickets/860/jpeg2000.mov -vframes 3  -vcodec huffyuv -y test.avi

http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket860/jpeg2000.mov

[...]

-- 
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] [FFmpeg-cvslog] lavfi: make filter_frame non-recursive.

2016-12-19 Thread Nicolas George 
Le nonidi 29 frimaire, an CCXXV, Michael Niedermayer a écrit :
> i dont know if this is a bug or just somethig that by sheer bad luck
> becomes vissible after this but
> ./ffmpeg -i cvid/dday.mov -vframes 30  -vcodec huffyuv -y -acodec pcm_s16le 
> out3b.avi ; md5sum out3b.avi
> gives different outputs from time to time
> needs threads on the encoder side, huffyuv, vframes (audio codec irrelevant)
> 
> difference in output files looks like this:
> valgrind shows nothing (but difference occurs under valgrind)
> should be here:
> http://samples.ffmpeg.org/V-codecs/CVID/grayscale/dday.mov

I know there are a few glitches that came through. I have started
working on fixing the worst one, it requires making buffersink aware of
EOF one step earlier.

As for this one and the one you posted a few minutes ago: -vframes with
audio frames too is highly dependant on details of the filters
scheduling, and can change slightly under perfectly normal
circumstances, starting with threading.

I will keep your mails near at hand and look if they show something
worrying. Thanks for testing.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavfi: make filter_frame non-recursive.

2016-12-19 Thread Michael Niedermayer 
On Sun, Dec 18, 2016 at 10:49:36AM +0100, Nicolas George wrote:
> ffmpeg | branch: master | Nicolas George  | Sun Jan  3 
> 15:44:42 2016 +0100| [02aa0701ae0dc2def8db640c9e3c06dc1b5de70c] | committer: 
> Nicolas George
> 
> lavfi: make filter_frame non-recursive.
> 
> A lot of changes happen at the same time:
> 
> - Add a framequeue fifo to AVFilterLink.
> 
> - split AVFilterLink.status into status_in and status_out: requires
>   changes to the few filters and programs that use it directly
>   (f_interleave, split, filtfmts).
> 
> - Add a field ready to AVFilterContext, marking when the filter is ready
>   and its activation priority.
> 
> - Add flags to mark blocked links.
> 
> - Change ff_filter_frame() to enqueue the frame.
> 
> - Change all filtering functions to update the ready field and the
>   blocked flags.
> 
> - Update ff_filter_graph_run_once() to use the ready field.
> 
> - buffersrc: always push the frame immediately.
> 
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=02aa0701ae0dc2def8db640c9e3c06dc1b5de70c
> ---

i dont know if this is a bug or just somethig that by sheer bad luck
becomes vissible after this but
./ffmpeg -i cvid/dday.mov -vframes 30  -vcodec huffyuv -y -acodec pcm_s16le 
out3b.avi ; md5sum out3b.avi
gives different outputs from time to time
needs threads on the encoder side, huffyuv, vframes (audio codec irrelevant)

difference in output files looks like this:
valgrind shows nothing (but difference occurs under valgrind)
should be here:
http://samples.ffmpeg.org/V-codecs/CVID/grayscale/dday.mov

--- A   2016-12-19 23:36:43.297001535 +0100
+++ B   2016-12-19 23:36:47.605001627 +0100
@@ -50,9 +50,7 @@
 0, 16, 16,1,54316, 0xdca6a02a
 1,  18728,  18728, 1024, 2048, 0xf24df16c
 0, 17, 17,1,55204, 0xa93a73e6
-1,  19752,  19752, 1024, 2048, 0x27c11d5c
 0, 18, 18,1,54872, 0x8b01d9b0
-1,  20776,  20776, 1024, 2048, 0x77e00ab9
 0, 19, 19,1,54544, 0x752b168f
 0, 20, 20,1,58916, 0x1596d7cf
 0, 21, 21,1,53868, 0x0f286854



[...]
--
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 2/2] wmavoice: don't error out if we're skipping more bits than available.

2016-12-19 Thread Andreas Cadhalpun 
On 16.12.2016 14:19, Ronald S. Bultje wrote:
> This reverts 2a4700a4f03280fa8ba4fc0f8a9987bb550f0d1e and implements it
> correctly so streams actually decode the way the encoder intended them
> to.

Why is it correct?
Is this behavior defined in a specification or reference decoder?

> ---
>  libavcodec/wmavoice.c | 20 
>  1 file changed, 4 insertions(+), 16 deletions(-)
> 
> diff --git a/libavcodec/wmavoice.c b/libavcodec/wmavoice.c
> index 0f29bdd..f1b5369 100644
> --- a/libavcodec/wmavoice.c
> +++ b/libavcodec/wmavoice.c
> @@ -1900,16 +1900,10 @@ static int wmavoice_decode_packet(AVCodecContext 
> *ctx, void *data,
>  cnt += s->spillover_nbits;
>  s->skip_bits_next = cnt & 7;
>  res = cnt >> 3;
> -if (res > avpkt->size) {
> -av_log(ctx, AV_LOG_ERROR,
> -   "Trying to skip %d bytes in packet of size 
> %d\n",
> -   res, avpkt->size);
> -return AVERROR_INVALIDDATA;
> -}
> -return res;
> +return FFMIN(avpkt->size, res);
>  } else
> -skip_bits_long (gb, s->spillover_nbits - cnt +
> -get_bits_count(gb)); // resync
> +skip_bits_long(gb, s->spillover_nbits - cnt +
> +   get_bits_count(gb)); // resync

Please do cosmetic changes in a separate commit.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/7] avutil: add FF_BAIL_ON_OVERFLOW

2016-12-19 Thread Andreas Cadhalpun 
On 16.12.2016 17:22, wm4 wrote:
> On Fri, 16 Dec 2016 03:32:07 +0100
> Andreas Cadhalpun  wrote:
> 
>> Suggested-by: Rodger Combs 
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavutil/common.h | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/libavutil/common.h b/libavutil/common.h
>> index 8142b31..00b7504 100644
>> --- a/libavutil/common.h
>> +++ b/libavutil/common.h
>> @@ -99,6 +99,8 @@
>>  #define FFSWAP(type,a,b) do{type SWAP_tmp= b; b= a; a= SWAP_tmp;}while(0)
>>  #define FF_ARRAY_ELEMS(a) (sizeof(a) / sizeof((a)[0]))
>>  
>> +#define FF_BAIL_ON_OVERFLOW(ctx, x) if (x) {av_log(ctx, AV_LOG_ERROR, 
>> "Overflow check failed: " #x"\n"); return AVERROR_INVALIDDATA;}
>> +
>>  /* misc math functions */
>>  
>>  #ifdef HAVE_AV_CONFIG_H
> 
> Are you sure we need the message?

Yes, since such an overflow could just be a sign of a limitation in our
framework (think of bit_rate being int32_t) and does not necessarily mean
that the sample is invalid.

> It's quite ugly.

Do you have any suggestions for improving it?

> Also maybe call it "FF_RETURN_ON_OVERFLOW".

That sounds a bit better, so changed locally.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] swscale: also save ebx register when using PIE

2016-12-19 Thread Andreas Cadhalpun 
On 16.12.2016 04:08, Michael Niedermayer wrote:
> On Fri, Dec 16, 2016 at 02:36:53AM +0100, Andreas Cadhalpun wrote:
>> Otherwise the build fails when configuring with --toolchain=hardened
>> --disable-pic on i386 using gcc 4.8:
>> error: PIC register clobbered by '%ebx' in 'asm'
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libswscale/x86/hscale_fast_bilinear_simd.c | 20 ++--
>>  1 file changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/libswscale/x86/hscale_fast_bilinear_simd.c 
>> b/libswscale/x86/hscale_fast_bilinear_simd.c
>> index 2cba5f0..3f0f5f5 100644
>> --- a/libswscale/x86/hscale_fast_bilinear_simd.c
>> +++ b/libswscale/x86/hscale_fast_bilinear_simd.c
>> @@ -199,7 +199,7 @@ void ff_hyscale_fast_mmxext(SwsContext *c, int16_t *dst,
>>  #if ARCH_X86_64
>>  uint64_t retsave;
>>  #else
>> -#if defined(PIC)
>> +#if defined(PIC) || defined(__PIE__)
> 
> please correct me if iam wrong
> our configure adds -DPIC to define PIC when its enabled,
> it does not add that in this case but gcc is still generating PIC code
> that doesnt seem good

gcc does not generate PIC, only PIE, which is subtly different.

What's wrong here is that this code in swscale tries to determine, whether
or not the ebx register can be used for asm, but doesn't check that correctly.
However, configure has a working check for that, the result of which can
be used here. Patch doing that is attached.

Best regards,
Andreas
>From 7b5d0714482a0ec42d317fa1e9fa095180e39ccd Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun 
Date: Fri, 16 Dec 2016 02:29:56 +0100
Subject: [PATCH] swscale: save ebx register when it is not available

Configure checks if the ebx register can be used for asm and it has to
be saved if and only if this is not the case.
Without this the build fails when configuring with --toolchain=hardened
--disable-pic on i386 using gcc 4.8:
error: PIC register clobbered by '%ebx' in 'asm'

In that case gcc 4.8 reserves the ebx register for the GOT needed for
PIE, so it can't be used in asm directly.

Signed-off-by: Andreas Cadhalpun 
---
 libswscale/x86/hscale_fast_bilinear_simd.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/libswscale/x86/hscale_fast_bilinear_simd.c b/libswscale/x86/hscale_fast_bilinear_simd.c
index 2cba5f0a1c..60a2cbfc50 100644
--- a/libswscale/x86/hscale_fast_bilinear_simd.c
+++ b/libswscale/x86/hscale_fast_bilinear_simd.c
@@ -199,7 +199,7 @@ void ff_hyscale_fast_mmxext(SwsContext *c, int16_t *dst,
 #if ARCH_X86_64
 uint64_t retsave;
 #else
-#if defined(PIC)
+#if !HAVE_EBX_AVAILABLE
 uint64_t ebxsave;
 #endif
 #endif
@@ -209,7 +209,7 @@ void ff_hyscale_fast_mmxext(SwsContext *c, int16_t *dst,
 "mov   -8(%%rsp), %%"FF_REG_a"\n\t"
 "mov%%"FF_REG_a", %5  \n\t"  // retsave
 #else
-#if defined(PIC)
+#if !HAVE_EBX_AVAILABLE
 "mov%%"FF_REG_b", %5  \n\t"  // ebxsave
 #endif
 #endif
@@ -255,7 +255,7 @@ void ff_hyscale_fast_mmxext(SwsContext *c, int16_t *dst,
 "mov  %5, %%"FF_REG_a" \n\t"
 "mov%%"FF_REG_a", -8(%%rsp)\n\t"
 #else
-#if defined(PIC)
+#if !HAVE_EBX_AVAILABLE
 "mov  %5, %%"FF_REG_b" \n\t"
 #endif
 #endif
@@ -264,12 +264,12 @@ void ff_hyscale_fast_mmxext(SwsContext *c, int16_t *dst,
 #if ARCH_X86_64
   ,"m"(retsave)
 #else
-#if defined(PIC)
+#if !HAVE_EBX_AVAILABLE
   ,"m" (ebxsave)
 #endif
 #endif
 : "%"FF_REG_a, "%"FF_REG_c, "%"FF_REG_d, "%"FF_REG_S, "%"FF_REG_D
-#if ARCH_X86_64 || !defined(PIC)
+#if ARCH_X86_64 || HAVE_EBX_AVAILABLE
  ,"%"FF_REG_b
 #endif
 );
@@ -289,7 +289,7 @@ void ff_hcscale_fast_mmxext(SwsContext *c, int16_t *dst1, int16_t *dst2,
 #if ARCH_X86_64
 DECLARE_ALIGNED(8, uint64_t, retsave);
 #else
-#if defined(PIC)
+#if !HAVE_EBX_AVAILABLE
 DECLARE_ALIGNED(8, uint64_t, ebxsave);
 #endif
 #endif
@@ -298,7 +298,7 @@ void ff_hcscale_fast_mmxext(SwsContext *c, int16_t *dst1, int16_t *dst2,
 "mov  -8(%%rsp), %%"FF_REG_a"\n\t"
 "mov   %%"FF_REG_a", %7  \n\t"  // retsave
 #else
-#if defined(PIC)
+#if !HAVE_EBX_AVAILABLE
 "mov   %%"FF_REG_b", %7  \n\t"  // ebxsave
 #endif
 #endif
@@ -332,7 +332,7 @@ void ff_hcscale_fast_mmxext(SwsContext *c, int16_t *dst1, int16_t *dst2,
 "mov%7, %%"FF_REG_a" \n\t"
 "mov  %%"FF_REG_a", -8(%%rsp)\n\t"
 #else
-#if defined(PIC)
+#if !HAVE_EBX_AVAILABLE
 "mov %7, %%"FF_REG_b"\n\t"
 #endif
 #endif
@@ -341,12 +341,12 @@ void ff_hcscale_fast_mmxext(SwsContext *c, int16_t *dst1, int16_t *dst2,
 #if ARCH_X86_64
   ,"m"(retsave)
 #else
-#if defined(PIC)
+#if !HAVE_EBX_AVAILABLE
   ,"m" (ebxsave)
 #endif
 #endif
 : "%"FF_REG_a, "%"FF_REG_c, "%"FF_REG_d, "%"FF_REG_S, "%"FF_REG_D
-#if ARCH_X86_64 || !defined(PIC)
+#if ARCH_X86_64 ||

Re: [FFmpeg-devel] [PATCH 1/7] avutil: add FF_BAIL_ON_OVERFLOW

2016-12-19 Thread Andreas Cadhalpun 
On 16.12.2016 07:36, Muhammad Faiz wrote:
> On 12/16/16, Andreas Cadhalpun  wrote:
>> Suggested-by: Rodger Combs 
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavutil/common.h | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/libavutil/common.h b/libavutil/common.h
>> index 8142b31..00b7504 100644
>> --- a/libavutil/common.h
>> +++ b/libavutil/common.h
>> @@ -99,6 +99,8 @@
>>  #define FFSWAP(type,a,b) do{type SWAP_tmp= b; b= a; a= SWAP_tmp;}while(0)
>>  #define FF_ARRAY_ELEMS(a) (sizeof(a) / sizeof((a)[0]))
>>
>> +#define FF_BAIL_ON_OVERFLOW(ctx, x) if (x) {av_log(ctx, AV_LOG_ERROR,
>> "Overflow check failed: " #x"\n"); return AVERROR_INVALIDDATA;}
> 
> Where is the overflow check calculation?

The parameter 'x' is the overflow check used in 'if (x)'.

> What about functions that need clean up with goto before return?

This is only needed rarely, e.g. in none of the patches I sent.
It happens occasionally for the more common checks needed to
validate codec parameters that I'm working on, but these can be
handled on a case by case basis.
The general macros are only for the common, trivial cases.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] Make the process of uuid-xmp atom faster.

2016-12-19 Thread Michael Niedermayer 
On Fri, Nov 11, 2016 at 11:42:26AM +0800, Chen Meng wrote:
> Ya. It’s really annoying everyone using patchwork. (So lng text.) I’m 
> trying to fix it.
> Please use my name, Chen Meng, if nothing changed in a short time.
> 
> 2016-11-11 10:36 GMT+08:00 Chen Meng :
> ---
>  libavformat/mov.c | 32 ++--
>  1 file changed, 18 insertions(+), 14 deletions(-)

applied

thx

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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

Re: [FFmpeg-devel] [PATCH] lavfi/atempo: Avoid false triggering an assertion failure

2016-12-19 Thread Marton Balint 


On Mon, 19 Dec 2016, Marton Balint wrote:



On Sat, 17 Dec 2016, pkoshe...@gmail.com wrote:


From: Pavel Koshevoy 

Steps to reproduce:
./ffmpeg_g -f s16be -i /dev/null -af atempo=0.5 -y /tmp/atempo.wav
---
libavfilter/af_atempo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
index 59b08ec..a487882 100644
--- a/libavfilter/af_atempo.c
+++ b/libavfilter/af_atempo.c
@@ -914,8 +914,8 @@ static int yae_flush(ATempoContext *atempo,

atempo->state = YAE_FLUSH_OUTPUT;

-if (atempo->position[0] == frag->position[0] + frag->nsamples &&
-atempo->position[1] == frag->position[1] + frag->nsamples) {
+if (atempo->position[0] >= frag->position[0] + frag->nsamples &&
+atempo->position[1] >= frag->position[1] + frag->nsamples) {
// the current fragment is already flushed:
return 0;
}


Thanks, this indeed fixes the assertion I came accross. Do you want me to 
apply?




Thanks, applied.

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavfi: make filter_frame non-recursive.

2016-12-19 Thread Michael Niedermayer 
On Sun, Dec 18, 2016 at 10:49:36AM +0100, Nicolas George wrote:
> ffmpeg | branch: master | Nicolas George  | Sun Jan  3 
> 15:44:42 2016 +0100| [02aa0701ae0dc2def8db640c9e3c06dc1b5de70c] | committer: 
> Nicolas George
> 
> lavfi: make filter_frame non-recursive.
> 
> A lot of changes happen at the same time:
> 
> - Add a framequeue fifo to AVFilterLink.
> 
> - split AVFilterLink.status into status_in and status_out: requires
>   changes to the few filters and programs that use it directly
>   (f_interleave, split, filtfmts).
> 
> - Add a field ready to AVFilterContext, marking when the filter is ready
>   and its activation priority.
> 
> - Add flags to mark blocked links.
> 
> - Change ff_filter_frame() to enqueue the frame.
> 
> - Change all filtering functions to update the ready field and the
>   blocked flags.
> 
> - Update ff_filter_graph_run_once() to use the ready field.
> 
> - buffersrc: always push the frame immediately.
> 
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=02aa0701ae0dc2def8db640c9e3c06dc1b5de70c
> ---

this breaks

./ffmpeg -i ~/tickets/4329/bogus_video.mp4 -vframes 50 -vf crop=720:404   
test.mov

(no audio in the output)

one has to increase vframes to 70
to get some audi oto appear at the begin, this seems odd
file should be this:
http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4329/bogus_video.mp4

0,   -800,  0,  400,  794, 0x3ad604c7
0,   -400,800,  400,   22, 0x3a09051b, F=0x0
1,  -1024,  -1024, 1024,6, 0x037a013d, F=0x5, S=1,   
10, 0x00240004
0,  0,400,  400,   20, 0x21b203c2, F=0x0
1,  0,  0, 1024,6, 0x037a013d
1,   1024,   1024, 1024,6, 0x037a013d
0,400,   1200,  400,12769, 0x9a399624, F=0x0
1,   2048,   2048, 1024,6, 0x037a013d
1,   3072,   3072, 1024,6, 0x037a013d
0,800,   2000,  400, 5653, 0x395c3070, F=0x0
1,   4096,   4096, 1024,6, 0x037a013d
0,   1200,   1600,  400, 2146, 0x94f1304b, F=0x0
1,   5120,   5120, 1024,  470, 0xe6a7ed9f
1,   6144,   6144, 1024,  332, 0x64fca77e
0,   1600,   2800,  400, 5723, 0xe9ee0c94, F=0x0
1,   7168,   7168, 1024,  405, 0x4b7dc5db
0,   2000,   2400,  400, 1851, 0xe10c8e42, F=0x0
1,   8192,   8192, 1024, 1207, 0x4076622a
1,   9216,   9216, 1008,  634, 0x25e31eab
0,   2400,   3600,  400, 6172, 0x438f1c86, F=0x0
0,   2800,   3200,  400, 1993, 0x4dd4f5dd, F=0x0
0,   3200,   4400,  400, 5876, 0x47264a92, F=0x0
0,   3600,   4000,  400, 2060, 0x678ffcd6, F=0x0
0,   4000,   5200,  400, 6296, 0xc4fc26bd, F=0x0
0,   4400,   4800,  400, 2376, 0x56209df9, F=0x0
0,   4800,   6000,  400, 7232, 0x4ee9fc93, F=0x0
0,   5200,   5600,  400, 2461, 0xf39bd2ac, F=0x0
0,   5600,   6800,  400, 6890, 0xc26e86cd, F=0x0
0,   6000,   6400,  400, 1861, 0x3b6d90d4, F=0x0
0,   6400,   7600,  400, 5593, 0x39bfc6d7, F=0x0
0,   6800,   7200,  400, 1489, 0x9342de08, F=0x0
0,   7200,   8400,  400, 5673, 0x508b00d7, F=0x0
0,   7600,   8000,  400, 1336, 0xc5287c4d, F=0x0
0,   8000,   9200,  400, 4875, 0x14755c98, F=0x0
0,   8400,   8800,  400, 1160, 0xaf9b46dd, F=0x0
0,   8800,  1,  400, 4665, 0x9f5bffb6, F=0x0
0,   9200,   9600,  400, 1167, 0xf4964f57, F=0x0
0,   9600,  10800,  400, 3243, 0x4734579f, F=0x0
0,  1,  10400,  400, 1136, 0xb4b33f0a, F=0x0
0,  10400,  11200,  400, 8957, 0x61f15da3
0,  10800,  11600,  400, 5228, 0x33b41a30, F=0x0
0,  11200,  12000,  400, 5252, 0x53095cf9, F=0x0
0,  11600,  12400,  400, 5148, 0x8f881708, F=0x0
0,  12000,  12800,  400, 5722, 0x64230ea4, F=0x0
0,  12400,  13200,  400, 3836, 0x1c9d7023, F=0x0
0,  12800,  13600,  400, 4098, 0xcd85effa, F=0x0
0,  13200,  14000,  400, 6465, 0x2e9fae5e, F=0x0
0,  13600,  14400,  400, 6251, 0xaa0d4c0e, F=0x0
0,  14000,  14800,  400, 5825, 0xd6a282f2, F=0x0
0,  14400,  15200,  400, 5614, 0xef5d05a4, F=0x0
0,  14800,  15600,  400, 5438, 0x599a99f2, F=0x0
0,  15200,  16000,  400, 5026, 0x83fba1b0, F=0x0
0,  15600,  16400,  400, 5069, 0x51d8da52, F=0x0
0,  16000,  16800,  400, 5762, 0xff3d5071, F=0x0
0,  16400,  17200,  400, 5541, 0xf31ac340, F=0x0
0,  16800,  17600,  400, 5457, 0xdb7a926f, F=0x0
0,  17200,  18000,  400,23449, 0x

Re: [FFmpeg-devel] [PATCH] avcodec: add Apple Pixlet decoder

2016-12-19 Thread Paul B Mahol 
On 12/19/16, James Almer  wrote:
> On 12/19/2016 11:18 AM, Paul B Mahol wrote:
>> +static int read_low_coeffs(AVCodecContext *avctx, int16_t *dst, int size)
>> +{
>> +PixletContext *ctx = avctx->priv_data;
>> +GetBitContext *b = &ctx->gbit;
>> +unsigned value, cnt1, nbits, j, i = 0;
>> +int rlen, flag = 0, escape;
>> +int64_t rparam = 3;
>> +
>> +while (i < size) {
>> +nbits = FFMIN(ff_clz((rparam >> 8) + 3) ^ 0x1F, 14);
>> +
>> +cnt1 = get_unary(b, 0, 8);
>> +if (cnt1 < 8) {
>> +value = show_bits(b, nbits);
>> +if (value <= 1) {
>> +skip_bits(b, nbits - 1);
>> +escape = ((1 << nbits) - 1) * cnt1;
>> +} else {
>> +skip_bits(b, nbits);
>> +escape = value + ((1 << nbits) - 1) * cnt1 - 1;
>> +}
>> +} else {
>> +escape = get_bits(b, 16);
>> +}
>> +
>> +rlen = -((escape + flag) & 1) | 1;
>> +dst[i++] = rlen * ((escape + flag + 1) >> 1);
>> +rparam += 120 * (escape + flag) - (120 * rparam >> 8);
>> +flag = 0;
>> +
>> +if (rparam * 4 > 0xFF || i >= size)
>> +continue;
>> +
>> +nbits = ((rparam + 8) >> 5) + (rparam ? ff_clz(rparam) : 32) -
>> 24;
>> +escape = 16383 & ((1 << nbits) - 1);
>
> escape = av_mod_uintp2(16383, nbits);
>

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

Re: [FFmpeg-devel] [PATCH] doc/examples/decoder_targeted: Limit max pixels for fuzzing

2016-12-19 Thread Michael Niedermayer 
On Sat, Dec 17, 2016 at 06:40:53PM +0100, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  doc/examples/decoder_targeted.c | 3 +++
>  1 file changed, 3 insertions(+)

applied

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

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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

Re: [FFmpeg-devel] [PATCH 6/6] lavfi: make AVFilterLink opaque in two major bumps.

2016-12-19 Thread Michael Niedermayer 
On Mon, Dec 19, 2016 at 05:39:53PM +0100, Nicolas George wrote:
> Le nonidi 29 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > Changing from AVFilterFrame to AVFrame could have been done using
> > a new set of API functions and deprecating the old.
> > 
> > Things like that were not done as it wasnt needed without a public
> > API, i dont think theres anything we really needed to do that we
> > would not have been able to with a public API if that was the
> > constraint under which we worked.
> > Most projects work under the constraint of a stable public API.
> 
> > Theres a big difference between the "wish to redesign" and the "need to
> > redesign"
> > more so the "wish to redesign" might not end before the loss of
> > interrest in the code as such, And the next developer might have a new
> > and different "wish to redesign".
> > With this you might never reach the point of having a stable API no
> > matter what man power you have as with more man might come more
> > wishes.
> 
> All this is certainly true, but it requires manpower. We do not have it;
> mostly, we only have me.

> 
> > I really think we should draw a line at some point and commit ourselfs
> > to some stable API.
> 
> I agree, but it should be done only when the API and design are good
> enough. I do not think they are right now. A clue to prove that: when
> something breaks around libavfilter in ffmpeg.c, you have to ask me,
> showing that the code is complex, more than it should be and I think I
> can make it simpler.

I would very much be in favor of this
though i wonder what mistake we did to end here, the original design
was intended to be very simple ...


> 
> And even larger projects with plenty of manpower and API stability, from
> time to time, decide to start fresh.
> 
> > But theres another issue we should keep in mind. I think if someone
> > forked libavfilter, documented it well, added a plugin interface and
> > commited himself to a stable API and had a bit PR success iam not sure
> > which side would win.
> 
> That would be great! That would mean a version of libavfilter with good
> documentation, stable API and a plugin interface. We could merge it and
> I could start working on something else entirely, possibly asynchronous
> I/O.

>
> But before that would happen, I would expect the people interested to
> make contact, on the mailing-list or with me personally, and we could
> discuss how to do it together, without forking. That would be, of
> course, even better.
> 
> Alas, the state of affairs now is that I cannot even find someone to
> discuss fine points of API evolution.

my interrest is having a stable public API and a plugin interface
and iam interrested discussing that.
Iam also interrested in discussing clearly defined problems,
reproducable issues and solutions.
about fine details i dont really care
and your libavfilter patches are sometimes complex making it not a
trivial quick thing to discuss them


> 
> More to the point: is this discussion meant to be an objection to the
> patch itself?

its not an objection to the patch


> 
> Right now, because a not of necessary structures and functions are
> internal, plugins are not possible, so this patch is not making things
> any worse. I am all in favour of allowing plugins eventually, but I
> think the only reasonable course of action is: first a good API, then
> make it stable, then make it public.

You complain that noone else is working on libavfilter
how many people know what _NEEDS_ to be done to make the API good
enough for a first public and stable API ?

while i have a long todo and maybe no time for this, as it is i cant
even work on making libavfilter public+stable. Its not a technical
issue, its one of peoples requirements on what they require to be
changed first.


[...]

-- 
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] [PATCH] avcodec: add Apple Pixlet decoder

2016-12-19 Thread James Almer 
On 12/19/2016 11:18 AM, Paul B Mahol wrote:
> +static int read_low_coeffs(AVCodecContext *avctx, int16_t *dst, int size)
> +{
> +PixletContext *ctx = avctx->priv_data;
> +GetBitContext *b = &ctx->gbit;
> +unsigned value, cnt1, nbits, j, i = 0;
> +int rlen, flag = 0, escape;
> +int64_t rparam = 3;
> +
> +while (i < size) {
> +nbits = FFMIN(ff_clz((rparam >> 8) + 3) ^ 0x1F, 14);
> +
> +cnt1 = get_unary(b, 0, 8);
> +if (cnt1 < 8) {
> +value = show_bits(b, nbits);
> +if (value <= 1) {
> +skip_bits(b, nbits - 1);
> +escape = ((1 << nbits) - 1) * cnt1;
> +} else {
> +skip_bits(b, nbits);
> +escape = value + ((1 << nbits) - 1) * cnt1 - 1;
> +}
> +} else {
> +escape = get_bits(b, 16);
> +}
> +
> +rlen = -((escape + flag) & 1) | 1;
> +dst[i++] = rlen * ((escape + flag + 1) >> 1);
> +rparam += 120 * (escape + flag) - (120 * rparam >> 8);
> +flag = 0;
> +
> +if (rparam * 4 > 0xFF || i >= size)
> +continue;
> +
> +nbits = ((rparam + 8) >> 5) + (rparam ? ff_clz(rparam) : 32) - 24;
> +escape = 16383 & ((1 << nbits) - 1);

escape = av_mod_uintp2(16383, nbits);

> +cnt1 = get_unary(b, 0, 8);
> +if (cnt1 > 7) {
> +rlen = get_bits(b, 16);
> +} else {
> +value = show_bits(b, nbits);
> +if (value > 1) {
> +skip_bits(b, nbits);
> +rlen = value + escape * cnt1 - 1;
> +} else {
> +if (nbits - 1 > 0)
> +skip_bits(b, nbits - 1);
> +rlen = escape * cnt1;
> +}
> +}
> +
> +if (i + rlen > size)
> +return AVERROR_INVALIDDATA;
> +
> +for (j = 0; j < rlen; j++)
> +dst[i++] = 0;
> +
> +rparam = 0;
> +flag = rlen < 0x ? 1 : 0;
> +}
> +
> +align_get_bits(b);
> +return get_bits_count(b) >> 3;
> +}

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

Re: [FFmpeg-devel] [PATCH 6/6] lavfi: make AVFilterLink opaque in two major bumps.

2016-12-19 Thread Nicolas George 
Le nonidi 29 frimaire, an CCXXV, Michael Niedermayer a écrit :
> Changing from AVFilterFrame to AVFrame could have been done using
> a new set of API functions and deprecating the old.
> 
> Things like that were not done as it wasnt needed without a public
> API, i dont think theres anything we really needed to do that we
> would not have been able to with a public API if that was the
> constraint under which we worked.
> Most projects work under the constraint of a stable public API.

> Theres a big difference between the "wish to redesign" and the "need to
> redesign"
> more so the "wish to redesign" might not end before the loss of
> interrest in the code as such, And the next developer might have a new
> and different "wish to redesign".
> With this you might never reach the point of having a stable API no
> matter what man power you have as with more man might come more
> wishes.

All this is certainly true, but it requires manpower. We do not have it;
mostly, we only have me.

> I really think we should draw a line at some point and commit ourselfs
> to some stable API.

I agree, but it should be done only when the API and design are good
enough. I do not think they are right now. A clue to prove that: when
something breaks around libavfilter in ffmpeg.c, you have to ask me,
showing that the code is complex, more than it should be and I think I
can make it simpler.

And even larger projects with plenty of manpower and API stability, from
time to time, decide to start fresh.

> But theres another issue we should keep in mind. I think if someone
> forked libavfilter, documented it well, added a plugin interface and
> commited himself to a stable API and had a bit PR success iam not sure
> which side would win.

That would be great! That would mean a version of libavfilter with good
documentation, stable API and a plugin interface. We could merge it and
I could start working on something else entirely, possibly asynchronous
I/O.

But before that would happen, I would expect the people interested to
make contact, on the mailing-list or with me personally, and we could
discuss how to do it together, without forking. That would be, of
course, even better.

Alas, the state of affairs now is that I cannot even find someone to
discuss fine points of API evolution.

More to the point: is this discussion meant to be an objection to the
patch itself?

Right now, because a not of necessary structures and functions are
internal, plugins are not possible, so this patch is not making things
any worse. I am all in favour of allowing plugins eventually, but I
think the only reasonable course of action is: first a good API, then
make it stable, then make it public.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH] avcodec: add Apple Pixlet decoder

2016-12-19 Thread Paul B Mahol 
Signed-off-by: Paul B Mahol 
---
 doc/general.texi|   1 +
 libavcodec/Makefile |   1 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   7 +
 libavcodec/pixlet.c | 726 
 libavformat/isom.c  |   2 +
 7 files changed, 739 insertions(+)
 create mode 100644 libavcodec/pixlet.c

diff --git a/doc/general.texi b/doc/general.texi
index 9ea3ba3..8f88b37 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -627,6 +627,7 @@ following image formats are supported:
 @item ANSI/ASCII art @tab @tab  X
 @item Apple Intermediate Codec @tab @tab  X
 @item Apple MJPEG-B  @tab @tab  X
+@item Apple Pixlet   @tab @tab  X
 @item Apple ProRes   @tab  X  @tab  X
 @item Apple QuickDraw@tab @tab  X
 @tab fourcc: qdrw
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 23e41dd..5e8eb67 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -452,6 +452,7 @@ OBJS-$(CONFIG_PGMYUV_DECODER)  += pnmdec.o pnm.o
 OBJS-$(CONFIG_PGMYUV_ENCODER)  += pnmenc.o
 OBJS-$(CONFIG_PGSSUB_DECODER)  += pgssubdec.o
 OBJS-$(CONFIG_PICTOR_DECODER)  += pictordec.o cga_data.o
+OBJS-$(CONFIG_PIXLET_DECODER)  += pixlet.o
 OBJS-$(CONFIG_PJS_DECODER) += textdec.o ass.o
 OBJS-$(CONFIG_PNG_DECODER) += png.o pngdec.o pngdsp.o
 OBJS-$(CONFIG_PNG_ENCODER) += png.o pngenc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index bbcecce..9df6390 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -281,6 +281,7 @@ void avcodec_register_all(void)
 REGISTER_ENCDEC (PGM,   pgm);
 REGISTER_ENCDEC (PGMYUV,pgmyuv);
 REGISTER_DECODER(PICTOR,pictor);
+REGISTER_DECODER(PIXLET,pixlet);
 REGISTER_ENCDEC (PNG,   png);
 REGISTER_ENCDEC (PPM,   ppm);
 REGISTER_ENCDEC (PRORES,prores);
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 098debf..9699f70 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -412,6 +412,7 @@ enum AVCodecID {
 AV_CODEC_ID_SHEERVIDEO,
 AV_CODEC_ID_YLC,
 AV_CODEC_ID_PSD,
+AV_CODEC_ID_PIXLET,
 
 /* various PCM "codecs" */
 AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the 
start of audio codecs
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 29ffcb9..f09d047 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1339,6 +1339,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("YUY2 Lossless Codec"),
 .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
 },
+{
+.id= AV_CODEC_ID_PIXLET,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "pixlet",
+.long_name = NULL_IF_CONFIG_SMALL("Apple Pixlet"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
+},
 
 /* image codecs */
 {
diff --git a/libavcodec/pixlet.c b/libavcodec/pixlet.c
new file mode 100644
index 000..3059d3b
--- /dev/null
+++ b/libavcodec/pixlet.c
@@ -0,0 +1,726 @@
+/*
+ * Apple Pixlet decoder
+ * Copyright (c) 2016 Paul B Mahol
+ * Copyright (c) 2015 Vittorio Giovara 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+
+#include "libavutil/imgutils.h"
+#include "libavutil/intmath.h"
+#include "libavutil/opt.h"
+
+#include "avcodec.h"
+#include "bytestream.h"
+#include "get_bits.h"
+#include "unary.h"
+#include "internal.h"
+#include "thread.h"
+
+#define NB_LEVELS 4
+
+#define H 0
+#define V 1
+
+typedef struct SubBand {
+unsigned width;
+unsigned height;
+unsigned size;
+int16_t *coeffs;
+} SubBand;
+
+typedef struct LowPass {
+unsigned width;
+unsigned height;
+int16_t top_left;
+int16_t *top_row;
+int16_t *left_column;
+int16_t *rest;
+int16_t *prediction;
+} LowPass;
+
+typedef struct PixletContext {
+AVClass *class;
+
+GetByteContext gbc;
+GetBitContext gbit;
+
+int levels;
+int lowres;
+int h, w;
+
+int16_t *filter[2];
+float scaling[4][2

Re: [FFmpeg-devel] [PATCH 1/1] Fixing 3GPP Timed Text (TTXT / tx3g / mov_text) encoding for UTF-8 (ticket 6021)

2016-12-19 Thread Michael Niedermayer 
On Sun, Dec 18, 2016 at 10:09:54PM +, Erik Bråthen Solem wrote:
> Good question. Since text_pos_chars never exceeds the existing 
> variable text_pos, I did not think about this.
> 
> No, there are no checks. The spec says that "Authors should limit the
> string in each text sample to not more than 2048 bytes, for maximum
> terminal interoperability", but the code does not enforce this limit
> (or the maximum uint16_t value of 65535 for that matter). The likeli-
> hood of exceeding this limit is very small, but it does not hurt to
> add a check. In any case text_pos >= text_pos_chars, so it should be
> sufficient to check just text_pos. In mov_text_new_line_cb we only
> increment by 1, so checking if s->text_pos == 0 after that is enough.
> In mov_text_text_cb this check can be used instead, placed before the
> length len is added to text_pos:
> if (len > UINT16_MAX || (s->text_pos > UINT16_MAX - len)) // Overflow
> 

> I am new to the project's source code and do not know how errors and
> warnings should be handled, but could it be an idea to print a
> warning if text_pos > 2048, and print an error message and abort in
> case of overflow? Or should the rest of the text just be truncated?

i dont know about the 2048 case, but yes at the point were it
would overflow error and returning an error (with cleanup if needed)
is what we normally do. (something else would make sense if it occurs
in real world files and isnt just an error/damagd unsalvagable blob)

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

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


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

Re: [FFmpeg-devel] [PATCH 6/6] lavfi: make AVFilterLink opaque in two major bumps.

2016-12-19 Thread Michael Niedermayer 
On Mon, Dec 19, 2016 at 09:25:14AM +0100, Nicolas George wrote:
> L'octidi 28 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > i know, but at the time all this closing down of the API happened it
> > was said that this was temporary (not by you and i dont remember who
> > said so and not limited to libavfilter) and now over 4 years later
> > temporary seems to be changing into the permanent end.
> > 
> > IMHO if you want libavfilter to be a success in the long term it needs
> > to be a open system with clean API that anyone can use and add filters
> > to.
> > 
> > As it is libavfilter is limited to what ffmpeg developers want INSIDE
> > ffmpeg. If a filter doesnt fit into that it will likely be rejected.
> > Which makes sense if there are external filters / plugins. But if the
> > only way to use a filter in libavfilter is through it being accepted
> > into main ffmpeg git that just makes libavfilter unfit as a _general_
> > filter framework.
> 
> Well, all you write here is entirely true. Making it possible to use
> application-provided and plugin-provided filters in libavfilter is a
> worthy goal.
> 
> But you have to consider the other side of the coin: all the genericness
> of libavfilter requires a very complex API for filters, and keeping this
> API stable would put a tremendous constraint on its evolution.
> 

> Just consider Marton's recent patch to make support of unknown channel
> layouts the default. He could do it because he could review all the
> existing filters, check they were ready and make the small adjustments
> necessary. If there were foreign filters to accommodate, it would have
> been impossible.

changing a default is not a needed change, and this one was even
rolled back and forth on the ML a while


> 
> Removing the recursiveness in request_frame() (last year's patch
> series), threading, the move to real frames, etc., would have been
> equally impossible.

Changing from AVFilterFrame to AVFrame could have been done using
a new set of API functions and deprecating the old.

Things like that were not done as it wasnt needed without a public
API, i dont think theres anything we really needed to do that we
would not have been able to with a public API if that was the
constraint under which we worked.
Most projects work under the constraint of a stable public API.


> 
> The short of it is that libavfilter is still too young to allow that.
> The age must not be measured in years, but in manpower.

Theres a big difference between the "wish to redesign" and the "need to
redesign"
more so the "wish to redesign" might not end before the loss of
interrest in the code as such, And the next developer might have a new
and different "wish to redesign".
With this you might never reach the point of having a stable API no
matter what man power you have as with more man might come more
wishes.

I really think we should draw a line at some point and commit ourselfs
to some stable API.

But theres another issue we should keep in mind. I think if someone
forked libavfilter, documented it well, added a plugin interface and
commited himself to a stable API and had a bit PR success iam not sure
which side would win.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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/6] lavfi/buffersink: add accessors for the stream properties.

2016-12-19 Thread Nicolas George 
L'octidi 28 frimaire, an CCXXV, wm4 a écrit :
> For buffersink, you could simply return a struct with the parameters.
> As a value type, it'd be a copy and wouldn't need accessors.

You mean a single structure returned by a single accessor with all the
stream's properties instead of individual accessors for individual
properties? Well, the naive methods of returning a structure to the
caller would make the size of the structure part of the API, but there
are ways around it.

I do not dislike the idea, if that is what people prefer.

(AVCodecParameter would have been an obvious candidate for that, but it
lacks a few necessary fields. And it has a lot of extra fields, which
goes against what you write below.)


> Since you moved the discussion to general API issues...
> 
> Using public fields and such "internal" structs is functionally
> equivalent to having an opaque struct with trivial accessors. It's
> basically a style issue.

This is true, but "functionally equivalent" is a very myopic criterion.
It misses all the impact of the design on the code readability. Just
look at all the "->inputs[0]" that this patch allows to eliminate (and
that James missed, I think).

> The difference between them is essentially syntax only. Both of them
> have multiple disadvantages:
> - too much to deal with at once (whether it's fields or
>   setters/getters), no logical separation of functionality that is
>   lesser needed or doesn't make sense in some contexts. (Consider all
>   these AVCodecContext fields for tuning encoders - what do they do for
>   decoding? What do fields, which are audio-only, do if video is
>   encoded or decoded?)

It feels more a mater of documentation and auto-documentation than
anything else. "There is a crf field, does it apply to the x262 encder?"
and "There is a crf option, does it apply to the x262 encoder?" are
exactly the same question, the only difference being that options are
auto-documenting and answer the question automatically. But we could
have found a way for fields as well.

> - it's unclear when these fields can be set or not. (Why _can_ you set
>   a field if the graph is already "configured"? What happens then? How
>   is the user supposed to know when it's ok to set them?)
> - even if you argue that the previous point can be fixed by having the
>   setters check the state and return an error value on misuse, it's
>   complex for both API implementer and user

All considered, the complexity is in the task: video encoding is an
incredibly complex subject. API can only do so much to ease it.

> - many uses of this hide internal fields from the public API user,
>   which is good. But at the same time, this moves away from the
>   (probably worthy) goal of allowing outside implementation of
>   codecs, (de)muxers, filters.

This calls to my recent answer to Michael about making AVFilterLink and
AVFilterPad opaque: allowing foreign modules requires stability for APIs
that are currently internal, and make development that much harder.

> So I would suggest that instead of changing the whole API to use
> accessors, we should make the API more "transactional", and force
> correct use by API design.

Unfortunately, if doing that was simple, we would already be doing it.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 6/6] lavfi: make AVFilterLink opaque in two major bumps.

2016-12-19 Thread Nicolas George 
L'octidi 28 frimaire, an CCXXV, Michael Niedermayer a écrit :
> i know, but at the time all this closing down of the API happened it
> was said that this was temporary (not by you and i dont remember who
> said so and not limited to libavfilter) and now over 4 years later
> temporary seems to be changing into the permanent end.
> 
> IMHO if you want libavfilter to be a success in the long term it needs
> to be a open system with clean API that anyone can use and add filters
> to.
> 
> As it is libavfilter is limited to what ffmpeg developers want INSIDE
> ffmpeg. If a filter doesnt fit into that it will likely be rejected.
> Which makes sense if there are external filters / plugins. But if the
> only way to use a filter in libavfilter is through it being accepted
> into main ffmpeg git that just makes libavfilter unfit as a _general_
> filter framework.

Well, all you write here is entirely true. Making it possible to use
application-provided and plugin-provided filters in libavfilter is a
worthy goal.

But you have to consider the other side of the coin: all the genericness
of libavfilter requires a very complex API for filters, and keeping this
API stable would put a tremendous constraint on its evolution.

Just consider Marton's recent patch to make support of unknown channel
layouts the default. He could do it because he could review all the
existing filters, check they were ready and make the small adjustments
necessary. If there were foreign filters to accommodate, it would have
been impossible.

Removing the recursiveness in request_frame() (last year's patch
series), threading, the move to real frames, etc., would have been
equally impossible.

The short of it is that libavfilter is still too young to allow that.
The age must not be measured in years, but in manpower.

Regards,

-- 
  Nicolas George


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