Re: [FFmpeg-devel] [PATCH] vf_lut: Add support for RGB48 and RGBA64

[Steven Robertson]

Done, thanks.



On Tue, Oct 13, 2015 at 12:51 AM, Paul B Mahol  wrote:

> On 10/11/15, Steven Robertson  wrote:
> > Thanks for taking a look!
> >
> > Steve
> >
>
> lgtm, do you need to update fate?
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


0001-vf_lut-Add-support-for-RGB48-and-RGBA64.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] x86/intmath: allow the source operand for icc/icl ff_ctzll to be a memory location

[Matt Oliver]

On 25 October 2015 at 22:16, Hendrik Leppkes  wrote:

> On Sun, Oct 25, 2015 at 11:26 AM, Matt Oliver 
> wrote:
> > On 25 October 2015 at 12:22, Ganesh Ajjanagadde 
> wrote:
> >
> >> On Sat, Oct 24, 2015 at 7:03 PM, James Almer  wrote:
> >> > On 10/24/2015 7:48 PM, Ganesh Ajjanagadde wrote:
> >> >> On Sat, Oct 24, 2015 at 6:08 PM, James Almer 
> wrote:
> >> >>> This gives the compiler some flexibility
> >> >>>
> >> >>> Signed-off-by: James Almer 
> >> >>> ---
> >> >>>  libavutil/x86/intmath.h | 2 +-
> >> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >>>
> >> >>> diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
> >> >>> index 7881e3c..10d3e7f 100644
> >> >>> --- a/libavutil/x86/intmath.h
> >> >>> +++ b/libavutil/x86/intmath.h
> >> >>> @@ -36,7 +36,7 @@ static av_always_inline av_const int
> >> ff_ctzll_x86(long long v)
> >> >>>  {
> >> >>>  #   if ARCH_X86_64
> >> >>>  uint64_t c;
> >> >>> -__asm__("bsfq %1,%0" : "=r" (c) : "r" (v));
> >> >>> +__asm__ ("bsfq %1,%0" : "=r" (c) : "rm" (v));
> >> >>>  return c;
> >> >>>  #   else
> >> >>>  return ((uint32_t)v == 0) ? _bit_scan_forward((uint32_t)(v >>
> >> 32)) + 32 : _bit_scan_forward((uint32_t)v);
> >> >>> --
> >> >>> 2.6.2
> >> >>
> >> >> This question may be silly, but can you clarify when this asm code is
> >> >> used instead of __builtin_ctzll? For instance, I think on GNU/Linux,
> >> >> x86-64, sufficiently modern GCC (even with asm enabled), we should
> >> >> always use the builtin: the compiler knows best what to do with its
> >> >> builtin.
> >> >
> >> > This is ICC/ICL, not GCC.
> >>
> >> Ah, now I recall that _bit_scan_forward64 was not always available on
> >> ICC. Anyway, this is just a heads up to whoever uses ICC/ICL and the
> >> like: you may want to find out to which versions this built in
> >> applies.
> >
> >
> > bit_scan_forward64 isnt available on ICL at all, hence the use of asm.
> >
>
> Intels intrinsic guide lists _BitScanForward64 as the intrinsic to use,
> however.
>
> https://software.intel.com/sites/landingpage/IntrinsicsGuide/#techs=Other=373


 _BitScanForward64 is a msvc intrinsic only available on windows platforms
so not usable with ICC. The native asm implementation also performs better
with ICL hence its use.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Use ff_thread_once() to initialize sin/cos static tables.

[Michael Niedermayer]

On Sun, Oct 25, 2015 at 11:19:53AM +, Derek Buitenhuis wrote:
> On 10/25/2015 11:09 AM, Michael Niedermayer wrote:
> > on ARM (cubox) this changes
> > time ./ffmpeg -i ~/fate-suite/qt-surge-suite/surge-2-16-B-QDM2.mov
> > from
> > real0m0.028s
> > user0m0.010s
> > sys 0m0.010s
> > 
> > real0m0.028s
> > user0m0.020s
> > sys 0m0.000s
> > 
> > 
> > to
> > 
> > real0m0.050s
> > user0m0.020s
> > sys 0m0.030s
> > 
> > real0m0.050s
> > user0m0.030s
> > sys 0m0.010s
> 
> One could argue this is not a representative sample. It's a single small file,
> which must always init (as opposed to a longer running process such as Chrome.
> Whereas if you have a longer sample, it wouldn't even be within the margin of
> error, I bet.

If the usecase is to probe many files, then file duration would not
help hideing the init time. (to fill a GUI list or whatever)

Also startup time for normal playback itself does matter, as its
part of user vissible responsiveness, the user clicks play in his
players playlist and if that isnt instantaneaously starting playback
the user notices. So IMO startup time is not irrelevant

on arm:

time for i in  `seq 100` ; do ./ffprobe 
~/fate-suite/qt-surge-suite/surge-2-16-B-QDM2.mov >& /dev/null ; done
test is also run twice and the system is completely unused, nothing
else running

from:
real0m2.208s
user0m0.320s
sys 0m0.900s

real0m2.197s
user0m0.300s
sys 0m0.910s

to:

real0m4.371s
user0m3.350s
sys 0m0.860s

real0m4.375s
user0m3.300s
sys 0m0.910s


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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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

Re: [FFmpeg-devel] [PATCH] Use ff_thread_once() to initialize sin/cos static tables.

[Derek Buitenhuis]

On 10/25/2015 11:56 AM, Michael Niedermayer wrote:
> the problem that causes the slowdown should be due to initializing all
> table sizes when only 1 or a few small ones are needed
> making the init more fine grained (as it was) should solve this
> that could be done with a single mutex (not of once type) and
> initializing only the needed table when its not already inited
> or with a once mutex for each table size
> there are certainly also other options

Seems reasonable to me. Probably would prefer once, to avoid possible
lock contention.

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

Re: [FFmpeg-devel] [PATCH] x86/intmath: allow the source operand for icc/icl ff_ctzll to be a memory location

[Henrik Gramner]

On Sun, Oct 25, 2015 at 12:08 AM, James Almer  wrote:
> +__asm__ ("bsfq %1,%0" : "=r" (c) : "rm" (v));

Shouldn't we be using tzcnt instead of bsf? Or rep bsf (which is the
same opcode as tzcnt) if we need to support ancient compilers. tzcnt
is generally faster than bsf on modern CPUs and backwards-compatible
with older CPUs.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavc/proresdec2: Fix slice_count for very high resolutions

[Carl Eugen Hoyos]

Hi!

Attached patch intends to fix an issue reported by forum user Koracas:
For slice_count > 0x1 FFmpeg fails to decode a frame, QT seems to 
ignore the value.

Please comment, Carl Eugen
diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index 932f85f..7d06a0b 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@ -153,6 +153,7 @@ static int decode_picture_header(AVCodecContext *avctx, 
const uint8_t *buf, cons
 int log2_slice_mb_width, log2_slice_mb_height;
 int slice_mb_count, mb_x, mb_y;
 const uint8_t *data_ptr, *index_ptr;
+const int mb_height_pow2[] = { 1, 2, 4, 8 };
 
 hdr_size = buf[0] >> 3;
 if (hdr_size < 8 || hdr_size > buf_size) {
@@ -181,6 +182,9 @@ static int decode_picture_header(AVCodecContext *avctx, 
const uint8_t *buf, cons
 ctx->mb_height = (avctx->height + 15) >> 4;
 
 slice_count = AV_RB16(buf + 5);
+// QT ignores the written value
+slice_count = FFMAX(slice_count,
+ctx->mb_width * ctx->mb_height / 
mb_height_pow2[log2_slice_mb_width]);
 
 if (ctx->slice_count != slice_count || !ctx->slices) {
 av_freep(>slices);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#2]

[Nicolas George]

Le quartidi 4 brumaire, an CCXXIV, Michael Niedermayer a écrit :
> Heres another suggested addition to the voting committee
> also off topic but i wonder if "[DECISSION]" in the subject is the best
> choice for this

Remember: before voting, there is campaigning. Basically: first propose
something and let people discuss bugs in your shell one-liner and whether 19
is a better threshold than 20, or if someone should be included for other
reasons than commits. Then, when the discussion is settled, post the list of
names with "DECISION".

> The newly added developers would be
> Ganesh Ajjanagadde
> Lou Logan
> Marton Balint
> Philip Langdale
> Reimar Döffinger

Fine by me. Actually, I intended to do a similar search, but I was waiting
for Clément to proclaim the results of the last vote (hint, hint).

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] x86/intmath: allow the source operand for icc/icl ff_ctzll to be a memory location

[Hendrik Leppkes]

On Sun, Oct 25, 2015 at 11:26 AM, Matt Oliver  wrote:
> On 25 October 2015 at 12:22, Ganesh Ajjanagadde  wrote:
>
>> On Sat, Oct 24, 2015 at 7:03 PM, James Almer  wrote:
>> > On 10/24/2015 7:48 PM, Ganesh Ajjanagadde wrote:
>> >> On Sat, Oct 24, 2015 at 6:08 PM, James Almer  wrote:
>> >>> This gives the compiler some flexibility
>> >>>
>> >>> Signed-off-by: James Almer 
>> >>> ---
>> >>>  libavutil/x86/intmath.h | 2 +-
>> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>>
>> >>> diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
>> >>> index 7881e3c..10d3e7f 100644
>> >>> --- a/libavutil/x86/intmath.h
>> >>> +++ b/libavutil/x86/intmath.h
>> >>> @@ -36,7 +36,7 @@ static av_always_inline av_const int
>> ff_ctzll_x86(long long v)
>> >>>  {
>> >>>  #   if ARCH_X86_64
>> >>>  uint64_t c;
>> >>> -__asm__("bsfq %1,%0" : "=r" (c) : "r" (v));
>> >>> +__asm__ ("bsfq %1,%0" : "=r" (c) : "rm" (v));
>> >>>  return c;
>> >>>  #   else
>> >>>  return ((uint32_t)v == 0) ? _bit_scan_forward((uint32_t)(v >>
>> 32)) + 32 : _bit_scan_forward((uint32_t)v);
>> >>> --
>> >>> 2.6.2
>> >>
>> >> This question may be silly, but can you clarify when this asm code is
>> >> used instead of __builtin_ctzll? For instance, I think on GNU/Linux,
>> >> x86-64, sufficiently modern GCC (even with asm enabled), we should
>> >> always use the builtin: the compiler knows best what to do with its
>> >> builtin.
>> >
>> > This is ICC/ICL, not GCC.
>>
>> Ah, now I recall that _bit_scan_forward64 was not always available on
>> ICC. Anyway, this is just a heads up to whoever uses ICC/ICL and the
>> like: you may want to find out to which versions this built in
>> applies.
>
>
> bit_scan_forward64 isnt available on ICL at all, hence the use of asm.
>

Intels intrinsic guide lists _BitScanForward64 as the intrinsic to use, however.
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#techs=Other=373
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Use ff_thread_once() to initialize sin/cos static tables.

[Derek Buitenhuis]

On 10/25/2015 11:44 AM, Michael Niedermayer wrote:
>> One could argue this is not a representative sample. It's a single small 
>> file,
>> which must always init (as opposed to a longer running process such as 
>> Chrome.
>> Whereas if you have a longer sample, it wouldn't even be within the margin of
>> error, I bet.
> 
> If the usecase is to probe many files, then file duration would not
> help hideing the init time. (to fill a GUI list or whatever)

I reject this notion. You are completely discounting that people use
libavcodec *as a library*, and not via CLI.

> Also startup time for normal playback itself does matter, as its
> part of user vissible responsiveness, the user clicks play in his
> players playlist and if that isnt instantaneaously starting playback
> the user notices. So IMO startup time is not irrelevant

I agree, but neither is thread-safety. Perhaps there is a middle ground.

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

Re: [FFmpeg-devel] [PATCH] Adds support parsing the QuickTime Metadata Keys.

[wm4]

On Sun, 25 Oct 2015 12:39:08 +0100
Nicolas George  wrote:

> Le quartidi 4 brumaire, an CCXXIV, Derek Buitenhuis a écrit :
> > Perhaps wm4 or Michael or someone can chime in... I don't know of a single 
> > good
> > way to handle this. Just failing if the locale has a radix point as a comma 
> > instead
> > of a period seems less bad than mucking with the thread/process locale 
> > inside a
> > library.  
> 
> Personally, I consider that users setting locale variables other than
> LC_CTYPE and LC_MESSAGES mean literally "please break random programs on my
> system"; I am convinced of this since more than fifteen years when initing
> Gtk in the OCaml toplevel would cause "let pi = 3.14" to set pi to 3.0.

Well, I'm not sure if this only affects LC_NUMERIC and maybe LC_COLLATE?

On the other hand, setting LC_CTYPE could have some bad effects too.

> Therefore, my opinion on this is: let us document that for all FFmpeg
> libraries, setting any locale except these two to anything other than
> C/POSIX yields undefined behaviours.

I'd be fine with that, but then we should maybe check the current
locale for sanity at certain points, and raise a clear error if it's
broken.

Many programs set locale by default, including GUI toolkits like Qt (!).
Qt in particular document this explicitly:

http://doc.qt.io/qt-5/qcoreapplication.html#locale-settings

So we shouldn't silently break everything. But again, breaking loudly
is ok IMHO.

> If people want to write applications using various locales, they should use
> the version with explicit locale argument introduced in the latest version
> of the standard.

You could demand the same from FFmpeg. It's impractical because not all
systems support these functions.

PS:

I think we don't need to block the patch on this issue anymore, because:
1. We don't have any workarounds in place this patch could use,
2. Lots of other code is probably affected anyway
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/huffman: replace qsort with AV_QSORT

[Michael Niedermayer]

On Sat, Oct 24, 2015 at 09:05:21AM -0400, Ganesh Ajjanagadde wrote:
> On Thu, Oct 22, 2015 at 10:25 PM, Ganesh Ajjanagadde
>  wrote:
> >
> > On Thu, Oct 22, 2015 at 9:28 PM, Timothy Gu  wrote:
> > > On Thu, Oct 22, 2015 at 5:01 PM Ganesh Ajjanagadde 
> > > 
> > > wrote:
> > >>
> > >> Sample benchmark (x86-64, Haswell, GNU/Linux), fraps-v2 from FATE:
> > >> new:
> > >> 280110 decicycles in qsort,   1 runs,  0 skips
> > >> 268260 decicycles in qsort,   2 runs,  0 skips
> > >>
> > >> old:
> > >> 1469910 decicycles in qsort,   1 runs,  0 skips
> > >>  952950 decicycles in qsort,   2 runs,  0 skips
> > >
> > >
> > > Usually it takes more than 2 runs to make sure something is faster than 
> > > the
> > > other (try -stream_loop 1 on the input).
> >
> > In this case the gain should be obvious due to inlining. Nevertheless,
> > here are new numbers. I chose vp6 for two reasons:
> > 1. Above was for fraps-v2, giving vp6 for more "completeness".
> > 2. stream_loop throws errors: Error while decoding stream #0:0:
> > Invalid data found when processing input for fraps-v2.
> >
> > Here they are:
> > vp6 (old):
> >   78930 decicycles in qsort,   1 runs,  0 skips
> >   45330 decicycles in qsort,   2 runs,  0 skips
> >   27825 decicycles in qsort,   4 runs,  0 skips
> >   17471 decicycles in qsort,   8 runs,  0 skips
> >   12296 decicycles in qsort,  16 runs,  0 skips
> >9554 decicycles in qsort,  32 runs,  0 skips
> >8404 decicycles in qsort,  64 runs,  0 skips
> >7405 decicycles in qsort, 128 runs,  0 skips
> >6740 decicycles in qsort, 256 runs,  0 skips
> >7540 decicycles in qsort, 512 runs,  0 skips
> >9498 decicycles in qsort,1024 runs,  0 skips
> >9938 decicycles in qsort,2048 runs,  0 skips
> >8043 decicycles in qsort,4095 runs,  1 skips
> >
> > vp6 (new):
> >   15880 decicycles in qsort,   1 runs,  0 skips
> >   10730 decicycles in qsort,   2 runs,  0 skips
> >   10155 decicycles in qsort,   4 runs,  0 skips
> >7805 decicycles in qsort,   8 runs,  0 skips
> >6883 decicycles in qsort,  16 runs,  0 skips
> >6305 decicycles in qsort,  32 runs,  0 skips
> >5854 decicycles in qsort,  64 runs,  0 skips
> >5152 decicycles in qsort, 128 runs,  0 skips
> >4452 decicycles in qsort, 256 runs,  0 skips
> >4161 decicycles in qsort, 511 runs,  1 skips
> >4081 decicycles in qsort,1023 runs,  1 skips
> >4072 decicycles in qsort,2047 runs,  1 skips
> >4004 decicycles in qsort,4095 runs,  1 skips
> 
> ping

LGTM

thanks

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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

Re: [FFmpeg-devel] [PATCH] Use ff_thread_once() to initialize sin/cos static tables.

[Michael Niedermayer]

On Fri, Oct 23, 2015 at 03:35:15PM -0700, Dale Curtis wrote:
> Changes from partial initialization which happens for every
> initialize call to a full initialization once per process. Changes
> as discussed on list by wm4 and rbultje.
> 
> Passes fft-test and fate suite.

on ARM (cubox) this changes
time ./ffmpeg -i ~/fate-suite/qt-surge-suite/surge-2-16-B-QDM2.mov
from
real0m0.028s
user0m0.010s
sys 0m0.010s

real0m0.028s
user0m0.020s
sys 0m0.000s


to

real0m0.050s
user0m0.020s
sys 0m0.030s

real0m0.050s
user0m0.030s
sys 0m0.010s


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

It is what and why we do it that matters, not just one of them.


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

Re: [FFmpeg-devel] [PATCH] Use ff_thread_once() to initialize sin/cos static tables.

[Derek Buitenhuis]

On 10/25/2015 11:09 AM, Michael Niedermayer wrote:
> on ARM (cubox) this changes
> time ./ffmpeg -i ~/fate-suite/qt-surge-suite/surge-2-16-B-QDM2.mov
> from
> real0m0.028s
> user0m0.010s
> sys 0m0.010s
> 
> real0m0.028s
> user0m0.020s
> sys 0m0.000s
> 
> 
> to
> 
> real0m0.050s
> user0m0.020s
> sys 0m0.030s
> 
> real0m0.050s
> user0m0.030s
> sys 0m0.010s

One could argue this is not a representative sample. It's a single small file,
which must always init (as opposed to a longer running process such as Chrome.
Whereas if you have a longer sample, it wouldn't even be within the margin of
error, I bet.

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

Re: [FFmpeg-devel] [PATCH] Don't needlessly reinitialize ff_cos_## tables.

[wm4]

On Sat, 24 Oct 2015 19:30:26 -0400
"Ronald S. Bultje"  wrote:

> On Sat, Oct 24, 2015 at 6:45 PM, Michael Niedermayer  > wrote:  
> 
> > either way, this subject is rather uninterresting ill try to do
> > something more usefull for FFmpeg than arguing about these
> > hypothetical cases ...  
> 
> 
> +100.
> 
> Many of these tools are like -Wpedantic. Reminds me of my rants about
> helgrind.

I still don't think expecting the compiler to treat all memory accesses
as volatile and/or weak atomic accesses is going to work out.

Concurrency is hard, let's not make it harder?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Adds support parsing the QuickTime Metadata Keys.

[Derek Buitenhuis]

On 10/25/2015 12:06 PM, wm4 wrote:
> I think we don't need to block the patch on this issue anymore, because:
> 1. We don't have any workarounds in place this patch could use,
> 2. Lots of other code is probably affected anyway

I agree, it is beyond the scope of this patch.

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

Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#2]

[wm4]

On Sun, 25 Oct 2015 01:53:07 +0200
Michael Niedermayer  wrote:

> Hi all
> 
> Heres another suggested addition to the voting committee
> also off topic but i wonder if "[DECISSION]" in the subject is the best
> choice for this
> 
> I Suggest to add all people who pushed or pull-requested 20 or more commits
> according to the commiter field in the last year (the initial voting committee
> members where based on the Author field)
> 
> I used the following to generate the list (this sadly can still change if
> people push changes with commit dates in the past, i suggest that such cases
> wont be considered)
> The command explicitly excludes "enemy merges" as these have not been
> requested by the commiters
> excluding all merges results in a list with the same people just
> somewhat different numbers
> 
> git log libav/master..master --no-merges  --since=2014-10-25T00:00:00Z 
> --until 2015-10-25T00:00:00Z --pretty=fuller | grep '^Commit:' | sed 
> 's/<.*//' |sort | uniq -c | sort -nr
> 
> most of these developers are already in the voting committee
> here is the list that command generated locally at around 1 o clock local time
> 
>3691 Commit: Michael Niedermayer
> 334 Commit: Paul B Mahol
> 242 Commit: Clément Bœsch
> 205 Commit: Carl Eugen Hoyos
> 203 Commit: James Almer
> 154 Commit: Ronald S. Bultje
> 115 Commit: Rostislav Pehlivanov
>  88 Commit: Lukasz Marek
>  77 Commit: Andreas Cadhalpun
>  64 Commit: Reynaldo H. Verdejo Pinochet
>  56 Commit: Stefano Sabatini
>  44 Commit: Hendrik Leppkes
>  40 Commit: Marton Balint
>  39 Commit: Nicolas George
>  38 Commit: Philip Langdale
>  37 Commit: Timothy Gu
>  29 Commit: wm4
>  27 Commit: Ganesh Ajjanagadde
>  20 Commit: Reimar Döffinger
>  20 Commit: Lou Logan
> 
> The newly added developers would be
> Ganesh Ajjanagadde
> Lou Logan
> Marton Balint
> Philip Langdale
> Reimar Döffinger
> 
> All of them have also contributed significantly outside of just self
> pushed commits.
> I belive they all should be on the voting comittee
> 
> Identical to the last suggested addition,
> I suggest a deadline for making a decision on these 5 people of 15 days
> starting now.
> 
> also, if there are any mistakes in the list or the command used to
> generate it please complain now or dont complain later
> 

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

Re: [FFmpeg-devel] [PATCH] Don't needlessly reinitialize ff_cos_## tables.

[Ronald S. Bultje]

Hi,

On Sun, Oct 25, 2015 at 8:11 AM, wm4  wrote:

> On Sat, 24 Oct 2015 19:30:26 -0400
> "Ronald S. Bultje"  wrote:
>
> > On Sat, Oct 24, 2015 at 6:45 PM, Michael Niedermayer
>  > > wrote:
> >
> > > either way, this subject is rather uninterresting ill try to do
> > > something more usefull for FFmpeg than arguing about these
> > > hypothetical cases ...
> >
> >
> > +100.
> >
> > Many of these tools are like -Wpedantic. Reminds me of my rants about
> > helgrind.
>
> I still don't think expecting the compiler to treat all memory accesses
> as volatile and/or weak atomic accesses is going to work out.


These are two extremes. What we're looking for is tools that find bugs.
I've brought this up before so I apologize for repeating myself (I've
explained this to the tsan guys also), but I'd really prefer if tsan was
rewritten entirely to be like Microsoft Chess. Infinitely more useful, and
all bugs are real (like valgrind/asan).

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

Re: [FFmpeg-devel] [RFC] mem: facilitate imports into GPU memory space.

[Nicolas George]

Le quartidi 4 brumaire, an CCXXIV, Gwenole Beauchesne a écrit :
> Allow for av_malloc() to allocate memory that could be mapped into
> the GPU address space. This requires allocations on page boundaries.
> On the video memory buffers side, this requires minimal alignment of
> strides to 64 bytes.
> 
> Option 1: use heuristics in av_malloc()
> - break down into mem, frame, and avcodec changes.

Heuristics are fragile, and the result would probably be many false
positive, wasting quite a lot of memory.

> Option 2: use a finer decision model
> - mem: add av_malloc_aligned()
> - buffer: add av_buffer_alloc2() with align and/or flags
> - frame/avcodec: use new APIs

I would go for flags all the way: with an explicit align value, people will
hardcode a random value based on whichever example they looked at, and it
will break when CPUs are upgraded to a larger value.

The API should probably include some kind of "av_foobar_get_align_flags()"
for each foobar domain where alignment can become visible to the
application.

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] x86/intmath: allow the source operand for icc/icl ff_ctzll to be a memory location

[Hendrik Leppkes]

On Sun, Oct 25, 2015 at 12:30 PM, Matt Oliver  wrote:
> On 25 October 2015 at 22:16, Hendrik Leppkes  wrote:
>
>> On Sun, Oct 25, 2015 at 11:26 AM, Matt Oliver 
>> wrote:
>> > On 25 October 2015 at 12:22, Ganesh Ajjanagadde 
>> wrote:
>> >
>> >> On Sat, Oct 24, 2015 at 7:03 PM, James Almer  wrote:
>> >> > On 10/24/2015 7:48 PM, Ganesh Ajjanagadde wrote:
>> >> >> On Sat, Oct 24, 2015 at 6:08 PM, James Almer 
>> wrote:
>> >> >>> This gives the compiler some flexibility
>> >> >>>
>> >> >>> Signed-off-by: James Almer 
>> >> >>> ---
>> >> >>>  libavutil/x86/intmath.h | 2 +-
>> >> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >> >>>
>> >> >>> diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
>> >> >>> index 7881e3c..10d3e7f 100644
>> >> >>> --- a/libavutil/x86/intmath.h
>> >> >>> +++ b/libavutil/x86/intmath.h
>> >> >>> @@ -36,7 +36,7 @@ static av_always_inline av_const int
>> >> ff_ctzll_x86(long long v)
>> >> >>>  {
>> >> >>>  #   if ARCH_X86_64
>> >> >>>  uint64_t c;
>> >> >>> -__asm__("bsfq %1,%0" : "=r" (c) : "r" (v));
>> >> >>> +__asm__ ("bsfq %1,%0" : "=r" (c) : "rm" (v));
>> >> >>>  return c;
>> >> >>>  #   else
>> >> >>>  return ((uint32_t)v == 0) ? _bit_scan_forward((uint32_t)(v >>
>> >> 32)) + 32 : _bit_scan_forward((uint32_t)v);
>> >> >>> --
>> >> >>> 2.6.2
>> >> >>
>> >> >> This question may be silly, but can you clarify when this asm code is
>> >> >> used instead of __builtin_ctzll? For instance, I think on GNU/Linux,
>> >> >> x86-64, sufficiently modern GCC (even with asm enabled), we should
>> >> >> always use the builtin: the compiler knows best what to do with its
>> >> >> builtin.
>> >> >
>> >> > This is ICC/ICL, not GCC.
>> >>
>> >> Ah, now I recall that _bit_scan_forward64 was not always available on
>> >> ICC. Anyway, this is just a heads up to whoever uses ICC/ICL and the
>> >> like: you may want to find out to which versions this built in
>> >> applies.
>> >
>> >
>> > bit_scan_forward64 isnt available on ICL at all, hence the use of asm.
>> >
>>
>> Intels intrinsic guide lists _BitScanForward64 as the intrinsic to use,
>> however.
>>
>> https://software.intel.com/sites/landingpage/IntrinsicsGuide/#techs=Other=373
>
>
>  _BitScanForward64 is a msvc intrinsic only available on windows platforms
> so not usable with ICC. The native asm implementation also performs better
> with ICL hence its use.

The "Intel(R) C++ Compiler User and Reference Guide" would care to
disagree with you.

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

Re: [FFmpeg-devel] [PATCH] Adds support parsing the QuickTime Metadata Keys.

[Derek Buitenhuis]

On 10/23/2015 7:41 PM, Tinglin Liu wrote:
> ​
> http://stackoverflow.com/questions/3457968/snprintf-simple-way-to-force-as-radix
> ​
> Here it mentioned using the setlocale() function, but I didn't find any
> examples elsewhere though
> 
> Derek, would you do the amend and push? Let me know if you need me to
> resend an amended patch. Thanks.

This may be enough of a pain that it needs a wrapper function... e.g. on POSIX,
it says the locale is common to all threads in a process, but on Windows, you
have _configthreadlocale, to define the behavior, and I'm not sure how systems
like Solaris work. I'm not sure how setting the locale could mess with other
bits of the library running concurrently, or worse, a user application which
links to libavformat may/will be affected.

I hate to hold up this patch for spec-arguign reasons, but this *should* 
probably
be addressed somehow. Lordy, C locales are crap.

Perhaps wm4 or Michael or someone can chime in... I don't know of a single good
way to handle this. Just failing if the locale has a radix point as a comma 
instead
of a period seems less bad than mucking with the thread/process locale inside a
library.

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

Re: [FFmpeg-devel] [PATCH] Use ff_thread_once() to initialize sin/cos static tables.

[Michael Niedermayer]

On Sun, Oct 25, 2015 at 11:48:12AM +, Derek Buitenhuis wrote:
> On 10/25/2015 11:44 AM, Michael Niedermayer wrote:
> >> One could argue this is not a representative sample. It's a single small 
> >> file,
> >> which must always init (as opposed to a longer running process such as 
> >> Chrome.
> >> Whereas if you have a longer sample, it wouldn't even be within the margin 
> >> of
> >> error, I bet.
> > 
> > If the usecase is to probe many files, then file duration would not
> > help hideing the init time. (to fill a GUI list or whatever)
> 
> I reject this notion. You are completely discounting that people use
> libavcodec *as a library*, and not via CLI.
> 
> > Also startup time for normal playback itself does matter, as its
> > part of user vissible responsiveness, the user clicks play in his
> > players playlist and if that isnt instantaneaously starting playback
> > the user notices. So IMO startup time is not irrelevant
> 
> I agree, but neither is thread-safety. Perhaps there is a middle ground.

the problem that causes the slowdown should be due to initializing all
table sizes when only 1 or a few small ones are needed
making the init more fine grained (as it was) should solve this
that could be done with a single mutex (not of once type) and
initializing only the needed table when its not already inited
or with a once mutex for each table size
there are certainly also other options

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

The educated differ from the uneducated as much as the living from the
dead. -- 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] Use ff_thread_once() to initialize sin/cos static tables.

[Ronald S. Bultje]

Hi,

On Sun, Oct 25, 2015 at 7:48 AM, Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:

> On 10/25/2015 11:44 AM, Michael Niedermayer wrote:
> >> One could argue this is not a representative sample. It's a single
> small file,
> >> which must always init (as opposed to a longer running process such as
> Chrome.
> >> Whereas if you have a longer sample, it wouldn't even be within the
> margin of
> >> error, I bet.
> >
> > If the usecase is to probe many files, then file duration would not
> > help hideing the init time. (to fill a GUI list or whatever)
>
> I reject this notion. You are completely discounting that people use
> libavcodec *as a library*, and not via CLI.
>
> > Also startup time for normal playback itself does matter, as its
> > part of user vissible responsiveness, the user clicks play in his
> > players playlist and if that isnt instantaneaously starting playback
> > the user notices. So IMO startup time is not irrelevant
>
> I agree, but neither is thread-safety. Perhaps there is a middle ground.


So this is likely because we init all tables instead of just these that we
need, right? So how about having one ff_once per table? That should be
trivial to implement.

Obviously anyone using shell scripts and calls to CLI ffmpeg versions to do
probing of production-level numbers of files on production systems deserves
the results (s)he'll be getting.

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

Re: [FFmpeg-devel] [PATCH] Use ff_thread_once() to initialize sin/cos static tables.

[Derek Buitenhuis]

On 10/25/2015 11:56 AM, Ronald S. Bultje wrote:
> So this is likely because we init all tables instead of just these that we
> need, right? So how about having one ff_once per table? That should be
> trivial to implement.

Yep.

> Obviously anyone using shell scripts and calls to CLI ffmpeg versions to do
> probing of production-level numbers of files on production systems deserves
> the results (s)he'll be getting.

I'll agree. I just dislike the CLI-centric approach usually taken in this list.

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

Re: [FFmpeg-devel] [PATCH] avformat/aiffdec: give message if compressed codec tag is unsupported

[Carl Eugen Hoyos]

Paul B Mahol  gmail.com> writes:

> +if (codec->codec_id == AV_CODEC_ID_NONE)
> +avpriv_request_sample(s, "unknown or 
> unsupported codec tag: 0x%X", codec->codec_tag);

You could use av_get_codec_tag_string() to make 
this more readable.
Looks good either way, Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] Use ff_thread_once() to initialize sin/cos static tables.

[Ronald S. Bultje]

Hi,

On Sun, Oct 25, 2015 at 9:39 AM, wm4  wrote:

> On Sun, 25 Oct 2015 07:56:49 -0400
> "Ronald S. Bultje"  wrote:
>
> > Hi,
> >
> > On Sun, Oct 25, 2015 at 7:48 AM, Derek Buitenhuis <
> > derek.buitenh...@gmail.com> wrote:
> >
> > > On 10/25/2015 11:44 AM, Michael Niedermayer wrote:
> > > >> One could argue this is not a representative sample. It's a single
> > > small file,
> > > >> which must always init (as opposed to a longer running process such
> as
> > > Chrome.
> > > >> Whereas if you have a longer sample, it wouldn't even be within the
> > > margin of
> > > >> error, I bet.
> > > >
> > > > If the usecase is to probe many files, then file duration would not
> > > > help hideing the init time. (to fill a GUI list or whatever)
> > >
> > > I reject this notion. You are completely discounting that people use
> > > libavcodec *as a library*, and not via CLI.
> > >
> > > > Also startup time for normal playback itself does matter, as its
> > > > part of user vissible responsiveness, the user clicks play in his
> > > > players playlist and if that isnt instantaneaously starting playback
> > > > the user notices. So IMO startup time is not irrelevant
> > >
> > > I agree, but neither is thread-safety. Perhaps there is a middle
> ground.
> >
> >
> > So this is likely because we init all tables instead of just these that
> we
> > need, right? So how about having one ff_once per table? That should be
> > trivial to implement.
> >
> > Obviously anyone using shell scripts and calls to CLI ffmpeg versions to
> do
> > probing of production-level numbers of files on production systems
> deserves
> > the results (s)he'll be getting.
>
> Having more AVOnce to reduce the load might be ok.
>
> But am I the only one who thinks it's ridiculous to reject a patch
> fixing thread-safety issues, because someone MIGHT probe 100s of small
> files on a weak ARM? I'd say correctness first, then performance.


The result is not incorrect, not on any real platform. Show me any real
platform where an actual bug occurs.

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

Re: [FFmpeg-devel] [PATCH] all: simplify qsort comparators, and add const-correctness

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 9:38 PM, Mark Harris  wrote:
>>>
>>>  static int compare_int64(const void *a, const void *b)
>>>  {
>>> -int64_t va = *(int64_t *)a, vb = *(int64_t *)b;
>>> -return va < vb ? -1 : va > vb ? +1 : 0;
>>> +return *(const int64_t *)a - *(const int64_t *)b;
>>>  }
>>>
>>
>> What if the result doesn't fit in int? The input is not int.
>
> Even for int this transformation is not valid assuming that the full
> range of int is possible.  For example if *a = INT_MAX and *b = -1
> then *a - *b = INT_MAX+1 which is negative when cast to an int.

point taken, but this will need to be checked more carefully: for
instance, sometimes the integers fit in only the lower 24/16 bits,
etc. I have decided the following: this patch will only address the
const-ness. The next patch will be a scan through the qsort
comparators, and appropriately modifying the comparator by fixing
existing issues (if any) related to your point, and avoiding branches
when possibles.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] all: simplify qsort comparators, and add const-correctness

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 9:32 PM, Ronald S. Bultje  wrote:
> Hi,
>
> On Sat, Oct 24, 2015 at 9:02 PM, Ganesh Ajjanagadde 
> wrote:
>>
>> All the comparator API needs is > 0, < 0, or = 0 signalling: it does not
>> need +1, -1, 0. This avoids some useless branching.
>> [..]
>>
>> diff --git a/cmdutils_opencl.c b/cmdutils_opencl.c
>> index 61478e2..d9095b6 100644
>> --- a/cmdutils_opencl.c
>> +++ b/cmdutils_opencl.c
>> @@ -206,7 +206,7 @@ end:
>>
>>  static int compare_ocl_device_desc(const void *a, const void *b)
>>  {
>> -return ((OpenCLDeviceBenchmark*)a)->runtime -
>> ((OpenCLDeviceBenchmark*)b)->runtime;
>> +return ((const OpenCLDeviceBenchmark*)a)->runtime - ((const
>> OpenCLDeviceBenchmark*)b)->runtime;
>>  }
>
>
> OK.
>
>>
>> @@ -2578,8 +2578,7 @@ static InputStream *get_input_stream(OutputStream
>> *ost)
>>
>>  static int compare_int64(const void *a, const void *b)
>>  {
>> -int64_t va = *(int64_t *)a, vb = *(int64_t *)b;
>> -return va < vb ? -1 : va > vb ? +1 : 0;
>> +return *(const int64_t *)a - *(const int64_t *)b;
>>  }
>
>
> What if the result doesn't fit in int? The input is not int.
>
>>
>> @@ -367,7 +367,7 @@ static int cmp_intervals(const void *a, const void *b)
>>  int64_t ts_diff = i1->start_ts - i2->start_ts;
>>  int ret;
>>
>> -ret = ts_diff > 0 ? 1 : ts_diff < 0 ? -1 : 0;
>> +ret = ts_diff;
>>  return ret == 0 ? i1->index - i2->index : ret;
>>  }
>
>
> Same here.
>
>>
>>  static int cmp_int(const void *p1, const void *p2)
>>  {
>> -int left = *(const int *)p1;
>> -int right = *(const int *)p2;
>> -
>> -return ((left > right) - (left < right));
>> +return *(const int *)p1 - *(const int *)p2;
>>  }
>
>
> OK.
>
>>
>> @@ -146,12 +146,9 @@ static int cmp_pkt_sub_ts_pos(const void *a, const
>> void *b)
>>  {
>>  const AVPacket *s1 = a;
>>  const AVPacket *s2 = b;
>> -if (s1->pts == s2->pts) {
>> -if (s1->pos == s2->pos)
>> -return 0;
>> -return s1->pos > s2->pos ? 1 : -1;
>> -}
>> -return s1->pts > s2->pts ? 1 : -1;
>> +if (s1->pts == s2->pts)
>> +return s1->pos - s2->pos;
>> +return s1->pts - s2->pts;
>>  }
>
>
> pos is also int64_t.
>
>>
>> -static int cmp(const int *a, const int *b){
>> -return *a - *b;
>> +static int cmp(const void *a, const void *b){
>> +return *(const int *)a - *(const int *)b;
>>  }
>
>
> OK.
>
>>
>> -qsort(remaining_tests + max_tests - num_tests, num_tests,
>> sizeof(remaining_tests[0]), (void*)cmp);
>> +qsort(remaining_tests + max_tests - num_tests, num_tests,
>> sizeof(remaining_tests[0]), cmp);
>
>
> I thought all qsorts were changed to AV_QSORT?

Such a wholesale change was not liked by wm4 and Clement due to the
increase in binary size. I have a patch for one such instance that I
believe should be replaced: the performance hit of per frame calls to
qsort as opposed to AV_QSORT in avcodec has bigger impact than the
increase in binary size IMO. This has been ok'ed by Michael.

Thus, this change will be done gradually, with performance measurements.

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

Re: [FFmpeg-devel] [PATCH] x86/intmath: allow the source operand for icc/icl ff_ctzll to be a memory location

[Matt Oliver]

On 25 October 2015 at 12:22, Ganesh Ajjanagadde  wrote:

> On Sat, Oct 24, 2015 at 7:03 PM, James Almer  wrote:
> > On 10/24/2015 7:48 PM, Ganesh Ajjanagadde wrote:
> >> On Sat, Oct 24, 2015 at 6:08 PM, James Almer  wrote:
> >>> This gives the compiler some flexibility
> >>>
> >>> Signed-off-by: James Almer 
> >>> ---
> >>>  libavutil/x86/intmath.h | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
> >>> index 7881e3c..10d3e7f 100644
> >>> --- a/libavutil/x86/intmath.h
> >>> +++ b/libavutil/x86/intmath.h
> >>> @@ -36,7 +36,7 @@ static av_always_inline av_const int
> ff_ctzll_x86(long long v)
> >>>  {
> >>>  #   if ARCH_X86_64
> >>>  uint64_t c;
> >>> -__asm__("bsfq %1,%0" : "=r" (c) : "r" (v));
> >>> +__asm__ ("bsfq %1,%0" : "=r" (c) : "rm" (v));
> >>>  return c;
> >>>  #   else
> >>>  return ((uint32_t)v == 0) ? _bit_scan_forward((uint32_t)(v >>
> 32)) + 32 : _bit_scan_forward((uint32_t)v);
> >>> --
> >>> 2.6.2
> >>
> >> This question may be silly, but can you clarify when this asm code is
> >> used instead of __builtin_ctzll? For instance, I think on GNU/Linux,
> >> x86-64, sufficiently modern GCC (even with asm enabled), we should
> >> always use the builtin: the compiler knows best what to do with its
> >> builtin.
> >
> > This is ICC/ICL, not GCC.
>
> Ah, now I recall that _bit_scan_forward64 was not always available on
> ICC. Anyway, this is just a heads up to whoever uses ICC/ICL and the
> like: you may want to find out to which versions this built in
> applies.


bit_scan_forward64 isnt available on ICL at all, hence the use of asm.

Patch works with ICL fine, LGTM.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Adds support parsing the QuickTime Metadata Keys.

[Nicolas George]

Le quartidi 4 brumaire, an CCXXIV, Derek Buitenhuis a écrit :
> Perhaps wm4 or Michael or someone can chime in... I don't know of a single 
> good
> way to handle this. Just failing if the locale has a radix point as a comma 
> instead
> of a period seems less bad than mucking with the thread/process locale inside 
> a
> library.

Personally, I consider that users setting locale variables other than
LC_CTYPE and LC_MESSAGES mean literally "please break random programs on my
system"; I am convinced of this since more than fifteen years when initing
Gtk in the OCaml toplevel would cause "let pi = 3.14" to set pi to 3.0.

Therefore, my opinion on this is: let us document that for all FFmpeg
libraries, setting any locale except these two to anything other than
C/POSIX yields undefined behaviours.

If people want to write applications using various locales, they should use
the version with explicit locale argument introduced in the latest version
of the standard.

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] avformat/aiffdec: give message if compressed codec tag is unsupported

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavformat/aiffdec.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/aiffdec.c b/libavformat/aiffdec.c
index f26951d..7de103b 100644
--- a/libavformat/aiffdec.c
+++ b/libavformat/aiffdec.c
@@ -128,6 +128,8 @@ static int get_aiff_header(AVFormatContext *s, int size,
 } else if (version == AIFF_C_VERSION1) {
 codec->codec_tag = avio_rl32(pb);
 codec->codec_id  = ff_codec_get_id(ff_codec_aiff_tags, 
codec->codec_tag);
+if (codec->codec_id == AV_CODEC_ID_NONE)
+avpriv_request_sample(s, "unknown or unsupported codec tag: 0x%X", 
codec->codec_tag);
 size -= 4;
 }
 
-- 
1.9.1

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

Re: [FFmpeg-devel] [RFC] mem: facilitate imports into GPU memory space.

[wm4]

On Sun, 25 Oct 2015 06:46:45 +0100
Gwenole Beauchesne  wrote:

> Allow for av_malloc() to allocate memory that could be mapped into
> the GPU address space. This requires allocations on page boundaries.
> On the video memory buffers side, this requires minimal alignment of
> strides to 64 bytes.
> 
> Option 1: use heuristics in av_malloc()
> - break down into mem, frame, and avcodec changes.
> 
> Option 2: use a finer decision model
> - mem: add av_malloc_aligned()
> - buffer: add av_buffer_alloc2() with align and/or flags
> - frame/avcodec: use new APIs

My first reaction would be having special allocator functions for such
special cases, instead of changing av_malloc() in such subtle ways for
everyone (and why should a generic malloc function have a CIF
heuristic...).

av_malloc_aligned() actually sounds like a good idea; not sure how much
complexity it will cause, but it sounds preferable over this patch.

> Signed-off-by: Gwenole Beauchesne 
> ---
>  configure |  1 +
>  libavcodec/internal.h |  4 +++-
>  libavutil/mem.c   | 42 +++---
>  3 files changed, 43 insertions(+), 4 deletions(-)
> 
> diff --git a/configure b/configure
> index a38b290..25081a8 100755
> --- a/configure
> +++ b/configure
> @@ -6262,6 +6262,7 @@ cat > $TMPH <  #define BUILDSUF "$build_suffix"
>  #define SLIBSUF "$SLIBSUF"
>  #define HAVE_MMX2 HAVE_MMXEXT
> +#define HAVE_GPU (CONFIG_OPENCL || CONFIG_VAAPI)
>  #define SWS_MAX_FILTER_SIZE $sws_max_filter_size
>  EOF
>  
> diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> index 0abe17f..e12e01a 100644
> --- a/libavcodec/internal.h
> +++ b/libavcodec/internal.h
> @@ -69,7 +69,9 @@
>  
>  #define FF_SIGNBIT(x) ((x) >> CHAR_BIT * sizeof(x) - 1)
>  
> -#if HAVE_AVX
> +#if HAVE_GPU
> +#   define STRIDE_ALIGN 64
> +#elif HAVE_AVX
>  #   define STRIDE_ALIGN 32
>  #elif HAVE_SIMD_ALIGN_16
>  #   define STRIDE_ALIGN 16
> diff --git a/libavutil/mem.c b/libavutil/mem.c
> index 323b183..b707d7e 100644
> --- a/libavutil/mem.c
> +++ b/libavutil/mem.c
> @@ -35,6 +35,9 @@
>  #if HAVE_MALLOC_H
>  #include 
>  #endif
> +#if HAVE_UNISTD_H
> +#include 
> +#endif
>  
>  #include "avassert.h"
>  #include "avutil.h"
> @@ -61,7 +64,33 @@ void  free(void *ptr);
>  
>  #include "mem_internal.h"
>  
> -#define ALIGN (HAVE_AVX ? 32 : 16)
> +#define ALIGN (HAVE_GPU ? 64 : (HAVE_AVX ? 32 : 16))
> +
> +static size_t get_page_size(void)
> +{
> +static size_t page_size;
> +
> +if (!page_size) {
> +#ifdef HAVE_UNISTD_H
> +page_size = getpagesize();
> +#else
> +page_size = 4096;
> +#endif
> +}
> +return page_size;
> +}
> +
> +static void get_malloc_props(size_t *size_ptr, size_t *align_ptr)
> +{
> +size_t align = ALIGN;
> +
> +/* Heuristic: use GPU mappable buffers for at least CIF resolutions */
> +if (HAVE_GPU && *size_ptr > 288 * FFALIGN(352, align)) {
> +align = get_page_size();
> +*size_ptr = FFALIGN(*size_ptr, align);
> +}
> +*align_ptr = align;
> +}
>  
>  /* NOTE: if you want to override these functions with your own
>   * implementations (not recommended) you have to link libav* as
> @@ -80,11 +109,18 @@ void *av_malloc(size_t size)
>  #if CONFIG_MEMALIGN_HACK
>  long diff;
>  #endif
> +#if HAVE_POSIX_MEMALIGN || HAVE_MEMALIGN
> +size_t align;
> +#endif
>  
>  /* let's disallow possibly ambiguous cases */
>  if (size > (max_alloc_size - 32))
>  return NULL;
>  
> +#if HAVE_POSIX_MEMALIGN || HAVE_MEMALIGN
> +get_malloc_props(, );
> +#endif
> +
>  #if CONFIG_MEMALIGN_HACK
>  ptr = malloc(size + ALIGN);
>  if (!ptr)
> @@ -94,13 +130,13 @@ void *av_malloc(size_t size)
>  ((char *)ptr)[-1] = diff;
>  #elif HAVE_POSIX_MEMALIGN
>  if (size) //OS X on SDK 10.6 has a broken posix_memalign implementation
> -if (posix_memalign(, ALIGN, size))
> +if (posix_memalign(, align, size))
>  ptr = NULL;
>  #elif HAVE_ALIGNED_MALLOC
>  ptr = _aligned_malloc(size, ALIGN);
>  #elif HAVE_MEMALIGN
>  #ifndef __DJGPP__
> -ptr = memalign(ALIGN, size);
> +ptr = memalign(align, size);
>  #else
>  ptr = memalign(size, ALIGN);
>  #endif

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

Re: [FFmpeg-devel] [PATCH]lavc/proresdec2: Fix slice_count for very high resolutions

[Carl Eugen Hoyos]

Carl Eugen Hoyos  ag.or.at> writes:

> +slice_count = FFMAX(slice_count,
> +ctx->mb_width * ctx->mb_height / 
> mb_height_pow2[log2_slice_mb_width]);

This is not correct, please ignore.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] Use ff_thread_once() to initialize sin/cos static tables.

[wm4]

On Sun, 25 Oct 2015 07:56:49 -0400
"Ronald S. Bultje"  wrote:

> Hi,
> 
> On Sun, Oct 25, 2015 at 7:48 AM, Derek Buitenhuis <
> derek.buitenh...@gmail.com> wrote:  
> 
> > On 10/25/2015 11:44 AM, Michael Niedermayer wrote:  
> > >> One could argue this is not a representative sample. It's a single  
> > small file,  
> > >> which must always init (as opposed to a longer running process such as  
> > Chrome.  
> > >> Whereas if you have a longer sample, it wouldn't even be within the  
> > margin of  
> > >> error, I bet.  
> > >
> > > If the usecase is to probe many files, then file duration would not
> > > help hideing the init time. (to fill a GUI list or whatever)  
> >
> > I reject this notion. You are completely discounting that people use
> > libavcodec *as a library*, and not via CLI.
> >  
> > > Also startup time for normal playback itself does matter, as its
> > > part of user vissible responsiveness, the user clicks play in his
> > > players playlist and if that isnt instantaneaously starting playback
> > > the user notices. So IMO startup time is not irrelevant  
> >
> > I agree, but neither is thread-safety. Perhaps there is a middle ground.  
> 
> 
> So this is likely because we init all tables instead of just these that we
> need, right? So how about having one ff_once per table? That should be
> trivial to implement.
> 
> Obviously anyone using shell scripts and calls to CLI ffmpeg versions to do
> probing of production-level numbers of files on production systems deserves
> the results (s)he'll be getting.

Having more AVOnce to reduce the load might be ok.

But am I the only one who thinks it's ridiculous to reject a patch
fixing thread-safety issues, because someone MIGHT probe 100s of small
files on a weak ARM? I'd say correctness first, then performance.

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

Re: [FFmpeg-devel] [PATCH] Adds support parsing the QuickTime Metadata Keys.

[Nicolas George]

Le quartidi 4 brumaire, an CCXXIV, wm4 a écrit :
> Well, I'm not sure if this only affects LC_NUMERIC and maybe LC_COLLATE?

I grant you that LC_PAPER or LC_TELEPHONE are probably harmless; they were
added after I made my mental list. It should work by whitelist, not by
blacklist.

> On the other hand, setting LC_CTYPE could have some bad effects too.

Very true. Unfortunately, some genius decided to use LC_CTYPE to determine
the tty's encoding, instead of $TERM, this makes LC_CTYPE unavoidable.

> I'd be fine with that, but then we should maybe check the current
> locale for sanity at certain points, and raise a clear error if it's
> broken.
> 
> Many programs set locale by default, including GUI toolkits like Qt (!).
> Qt in particular document this explicitly:
> 
> http://doc.qt.io/qt-5/qcoreapplication.html#locale-settings
> 
> So we shouldn't silently break everything. But again, breaking loudly
> is ok IMHO.

Agree.

> You could demand the same from FFmpeg. It's impractical because not all
> systems support these functions.

Exactly. Printing number with a localized separator is a minor and optional
feature, and rather easy to reimplement in the application. Parsing floating
point numbers is used everywhere and hard to do if you want to keep the full
precision. Which one should work by default is really a no-brainer.

(Well, actually, I consider localizing the decimal separator to be
completely stupid. Numbers are numbers.)

> I think we don't need to block the patch on this issue anymore, because:

Agree too.

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] avcodec: disallow hwaccel with frame threads

[Hendrik Leppkes]

On Fri, Oct 23, 2015 at 1:54 PM, Hendrik Leppkes  wrote:
> HWAccels with frame threads are fundamentally flawed in avcodecs current
> design, and there are several known problems ranging from image corruption
> to driver crashes.
>
> These problems come down to two design problems in the interaction of
> threads and HWAccel decoding:
>
> (1)
> While avcodec prevents parallel decoding and as such simultaneous access
> to the hardware accelerator from the decoding threads, it cannot account
> for the user code and its access to the hardware surfaces and the hardware
> itself.
>
> This can result in image corruption or even driver crashes if the
> user code locks image surfaces while they are being used by the decoder
> threads as reference frames.
>
> The current HWAccel API does not offer any way to ensure exclusive access
> to the hardware or the surfaces if frame threading is used.
>
> (2)
> Initialization of the HWAccel with frame threads is non-trivial, and many
> decoders had and still have issues that cause excess calls to the
> get_format callback.
>
> This will potentially cause duplicate HWAccel initialization, which in
> extreme cases can even lead to driver crashes if the HWAccel is
> re-initialized while the user code is actively accessing the hardware
> surfaces associated with it, or lead to image corruption due to lost
> reference frames.
>
> While both of these issues are solvable, fixing (1) would at least require
> a huge API redesign which would move a lot of complexity into the user
> code.
>
> The only reason the combination of frame threads and HWAccel was
> considered useful is to allow a seamless fallback to multi-threaded
> software decoding if the HWAccel is not available, however the issues
> outlined above far outweight this.
>
> The proper solution for a fallback is to re-open the AVCodecContext with
> threading enabled if the HWAccel failed, which is a practice commonly used
> by various user applications using avcodec today already.
>
> Reviewed-by: Gwenole Beauchesne 
> Reviewed-by: wm4 
> Signed-off-by: Hendrik Leppkes 
> ---
>  libavcodec/utils.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 83a2078..6a58056 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -1007,6 +1007,12 @@ static int setup_hwaccel(AVCodecContext *avctx,
>  AVHWAccel *hwa = find_hwaccel(avctx->codec_id, fmt);
>  int ret= 0;
>
> +if (avctx->active_thread_type & FF_THREAD_FRAME) {
> +av_log(avctx, AV_LOG_ERROR,
> +   "Hardware accelerated decoding with frame threading is not 
> supported.\n");
> +return AVERROR(EINVAL);
> +}
> +
>  if (!hwa) {
>  av_log(avctx, AV_LOG_ERROR,
> "Could not find an AVHWAccel for the pixel format: %s",
> --
> 2.6.2.windows.1
>

Last call for tangible feedback, otherwise its going in tomorrow!

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

Re: [FFmpeg-devel] [PATCH] lavfi: add realtime filter.

[Mark Harris]

> +static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
> +{
> +AVFilterContext *ctx = inlink->dst;
> +RealtimeContext *s = ctx->priv;
> +
> +if (frame->pts != AV_NOPTS_VALUE) {
> +int64_t pts = av_rescale_q(frame->pts, inlink->time_base, 
> AV_TIME_BASE_Q);
> +int64_t now = av_gettime_relative();
> +int64_t sleep = pts - now + s->delta;
> +if (!s->inited) {
> +s->inited = 1;
> +sleep = 0;
> +s->delta = now - pts;
> +}
> +if (sleep > s->limit || sleep < -s->limit) {
> +av_log(ctx, AV_LOG_WARNING,
> +   "time discontinuity detected: %"PRIi64" us, resetting\n",
> +   sleep);

Won't this also be shown when there is no discontinuity but it isn't
able to keep up with realtime (e.g. due to a very high frame rate)?
The message is misleading in that situation.

> +sleep = 0;
> +s->delta = now - pts;
> +}
> +if (sleep > 0) {
> +av_log(ctx, AV_LOG_DEBUG, "sleeping %"PRIi64" us\n", sleep);
> +av_usleep(sleep);
> +}
> +}
> +return ff_filter_frame(inlink->dst->outputs[0], frame);
> +}
> +
> +#define OFFSET(x) offsetof(RealtimeContext, x)
> +#define FLAGS AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_AUDIO_PARAM | 
> AV_OPT_FLAG_FILTERING_PARAM
> +static const AVOption options[] = {
> +{ "limit", "sleep time limit", OFFSET(limit), AV_OPT_TYPE_DURATION, { 
> .i64 = 200 }, 0, INT64_MAX, FLAGS },
> +{ NULL }
> +};

The argument to av_usleep() is an unsigned int.  Should the maximum
limit be UINT_MAX rather than INT64_MAX?  Alternatively it could call
av_usleep() in a loop if the value is too large for one call.

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

Re: [FFmpeg-devel] [PATCH] avutil/opt: print more meaningful default flags values

[Clément Bœsch]

On Sat, Oct 24, 2015 at 07:02:50PM +0200, Michael Niedermayer wrote:
> On Sat, Oct 24, 2015 at 03:14:33PM +0200, Clément Bœsch wrote:
> > Example:
> > % ./ffmpeg -h encoder=gif
> > [...]
> > GIF encoder AVOptions:
> >   -gifflagsE..V set GIF flags (default 
> > offsetting+transdiff)
> >  offsetting   E..V enable picture offsetting
> >  transdiffE..V enable transparency detection 
> > between frames
> > ---
> >  libavutil/opt.c| 32 ++--
> >  tests/ref/fate/opt |  2 +-
> >  2 files changed, 31 insertions(+), 3 deletions(-)
> 
> LGTM
> 
> thanks
> 

Applied

-- 
Clément B.


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

[FFmpeg-devel] [PATCH] MAINTAINERS: add key fingerprint

[Ganesh Ajjanagadde]

Patch on hold until the results of the "DECISION" call are given. This
patch just signifies intent.

Signed-off-by: Ganesh Ajjanagadde 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 25cff79..96dab5e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -590,6 +590,7 @@ Clément Bœsch 52D0 3A82 D445 F194 DB8B 2B16 
87EE 2CB8 F4B8 FCF
 Daniel Verkamp78A6 07ED 782C 653E C628 B8B9 F0EB 8DD8 2F0E 21C7
 Diego Biurrun 8227 1E31 B6D9 4994 7427 E220 9CAE D6CC 4757 FCC5
 FFmpeg release signing keyFCF9 86EA 15E6 E293 A564 4F10 B432 2F04 D676 58D8
+Ganesh AjjanagaddeC96A 848E 97C3 CEA2 AB72 5CE4 45F9 6A2D 3C36 FB1B
 Gwenole Beauchesne2E63 B3A6 3E44 37E2 017D 2704 53C7 6266 B153 99C4
 Jaikrishnan Menon 61A1 F09F 01C9 2D45 78E1 C862 25DC 8831 AF70 D368
 Jean Delvare  7CA6 9F44 60F1 BDC4 1FD2 C858 A552 6B9B B3CD 4E6A
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add key fingerprint

[Michael Niedermayer]

On Sun, Oct 25, 2015 at 06:02:33PM -0400, Ganesh Ajjanagadde wrote:
> Patch on hold until the results of the "DECISION" call are given. This
> patch just signifies intent.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)

please apply
the list of gpg fingerprints are in there for the primary reason of
ensuring everyone knows the fingerprint and can verify and encrypt
mails if they (ever) feel the need to


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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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

Re: [FFmpeg-devel] [PATCH] all: simplify qsort comparators, and add const-correctness

[Ganesh Ajjanagadde]

On Sun, Oct 25, 2015 at 9:46 AM, Ganesh Ajjanagadde
 wrote:
> On Sat, Oct 24, 2015 at 9:38 PM, Mark Harris  wrote:

  static int compare_int64(const void *a, const void *b)
  {
 -int64_t va = *(int64_t *)a, vb = *(int64_t *)b;
 -return va < vb ? -1 : va > vb ? +1 : 0;
 +return *(const int64_t *)a - *(const int64_t *)b;
  }

>>>
>>> What if the result doesn't fit in int? The input is not int.
>>
>> Even for int this transformation is not valid assuming that the full
>> range of int is possible.  For example if *a = INT_MAX and *b = -1
>> then *a - *b = INT_MAX+1 which is negative when cast to an int.
>
> point taken, but this will need to be checked more carefully: for
> instance, sometimes the integers fit in only the lower 24/16 bits,
> etc. I have decided the following: this patch will only address the
> const-ness. The next patch will be a scan through the qsort
> comparators, and appropriately modifying the comparator by fixing
> existing issues (if any) related to your point, and avoiding branches
> when possibles.

pushed just the const correctness changes that were ok'ed by Ronald.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavf/xwma: Support wmapro

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #4963 for me.

Please comment, Carl Eugen
diff --git a/libavformat/xwma.c b/libavformat/xwma.c
index 9edad7d..6c8bb79 100644
--- a/libavformat/xwma.c
+++ b/libavformat/xwma.c
@@ -85,7 +85,8 @@ static int xwma_read_header(AVFormatContext *s)
  * extradata for that. Thus, ask the user for feedback, but try to go on
  * anyway.
  */
-if (st->codec->codec_id != AV_CODEC_ID_WMAV2) {
+if (st->codec->codec_id != AV_CODEC_ID_WMAV2 &&
+st->codec->codec_id != AV_CODEC_ID_WMAPRO) {
 avpriv_request_sample(s, "Unexpected codec (tag 0x04%x; id %d)",
   st->codec->codec_tag, st->codec->codec_id);
 } else {
@@ -103,6 +104,13 @@ static int xwma_read_header(AVFormatContext *s)
  */
 avpriv_request_sample(s, "Unexpected extradata (%d bytes)",
   st->codec->extradata_size);
+} else if (st->codec->codec_id == AV_CODEC_ID_WMAPRO) {
+if (ff_alloc_extradata(st->codec, 18))
+return AVERROR(ENOMEM);
+
+memset(st->codec->extradata, 0, st->codec->extradata_size);
+st->codec->extradata[ 0] =  24;
+st->codec->extradata[14] = 224;
 } else {
 if (ff_alloc_extradata(st->codec, 6))
 return AVERROR(ENOMEM);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/5] concatdec: move duration calculating code to open_file

[Marton Balint]

On Sun, 25 Oct 2015, Nicolas George wrote:


Le tridi 3 brumaire, an CCXXIV, Marton Balint a écrit :

Signed-off-by: Marton Balint 
---
 libavformat/concatdec.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index 7686f28..f262d44 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -316,6 +316,14 @@ static int open_file(AVFormatContext *avf, unsigned fileno)
cat->files[fileno - 1].duration;
 file->file_start_time = (cat->avf->start_time == AV_NOPTS_VALUE) ? 0 : 
cat->avf->start_time;
 file->file_inpoint = (file->inpoint == AV_NOPTS_VALUE) ? 
file->file_start_time : file->inpoint;



+if (file->duration == AV_NOPTS_VALUE) {
+file->duration = cat->avf->duration;
+if (file->inpoint != AV_NOPTS_VALUE)
+file->duration -= (file->inpoint - file->file_start_time);
+if (file->outpoint != AV_NOPTS_VALUE)
+file->duration -= cat->avf->duration - (file->outpoint - 
file->file_start_time);
+}


At this point, the file duration is not reliable, so unless I am mistaken
this change would produce wrong timestamps when stitching, for example, MP3
files without extra headers.



Hmm. I need this computed here for the next patch. Maybe we could 
calcualate the duration here and then update it in open_next_file as well?


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

Re: [FFmpeg-devel] [PATCH 3/3] avutil/tree: add additional const qualifier to the comparator

[Ganesh Ajjanagadde]

On Sun, Oct 25, 2015 at 12:35 PM, Michael Niedermayer
 wrote:
> On Sat, Oct 24, 2015 at 09:03:03PM -0400, Ganesh Ajjanagadde wrote:
>> On Sat, Oct 24, 2015 at 7:17 PM, Henrik Gramner  wrote:
>> > On Sun, Oct 25, 2015 at 12:02 AM, Ganesh Ajjanagadde
>> >  wrote:
>> >> -static int cmp(void *key, const void *node)
>> >> +static int cmp(const void *key, const void *node)
>> >>  {
>> >>  return (*(int64_t *) key) - ((const CacheEntry *) node)->logical_pos;
>> >>  }
>> >
>> >> -int ff_nut_sp_pos_cmp(const Syncpoint *a, const Syncpoint *b)
>> >> +int ff_nut_sp_pos_cmp(const void *a, const void *b)
>> >>  {
>> >> -return ((a->pos - b->pos) >> 32) - ((b->pos - a->pos) >> 32);
>> >> +Syncpoint va = *(Syncpoint *)a, vb = *(Syncpoint *)b;
>> >> +return ((va.pos - vb.pos) >> 32) - ((vb.pos - va.pos) >> 32);
>> >>  }
>> >
>> >> -int ff_nut_sp_pts_cmp(const Syncpoint *a, const Syncpoint *b)
>> >> +int ff_nut_sp_pts_cmp(const void *a, const void *b)
>> >>  {
>> >> -return ((a->ts - b->ts) >> 32) - ((b->ts - a->ts) >> 32);
>> >> +Syncpoint va = *(Syncpoint *)a, vb = *(Syncpoint *)b;
>> >> +return ((va.ts - vb.ts) >> 32) - ((vb.ts - va.ts) >> 32);
>> >>  }
>> >
>> > Casts discards const qualifiers.
>>
>> Good catch, changed. There is some more such constness being discarded
>> in comparators, and some needlessly complex comparator logic in some
>> places. Submitted a patch.
>>
>> >
>> > Furthermore, why are you changing the two last functions to copy the
>> > entire struct to a temporary local copy?
>>
>> Sorry, forgot they were structs.
>> Fixed all, pushed. Thanks.
>
> i think this results in some new warnings for the tree test build
>
> libavutil/tree.c: In function ‘main’:
> libavutil/tree.c:238:9: warning: passing argument 3 of ‘av_tree_insert’ from 
> incompatible pointer type [enabled by default]
> libavutil/tree.c:59:7: note: expected ‘int (*)(const void *, const void *)’ 
> but argument is of type ‘int (*)(void *, const void *)’
> libavutil/tree.c:244:13: warning: passing argument 3 of ‘av_tree_insert’ from 
> incompatible pointer type [enabled by default]
> libavutil/tree.c:59:7: note: expected ‘int (*)(const void *, const void *)’ 
> but argument is of type ‘int (*)(void *, const void *)’
> libavutil/tree.c:245:13: warning: passing argument 3 of ‘av_tree_find’ from 
> incompatible pointer type [enabled by default]

Easy fix, and pushed. Sorry.
BTW, how did you enable the test build?

>
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Freedom in capitalist society always remains about the same as it was in
> ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avutil/tree: add additional const qualifier to the comparator

[Michael Niedermayer]

On Sun, Oct 25, 2015 at 12:46:31PM -0400, Ganesh Ajjanagadde wrote:
> On Sun, Oct 25, 2015 at 12:35 PM, Michael Niedermayer
>  wrote:
> > On Sat, Oct 24, 2015 at 09:03:03PM -0400, Ganesh Ajjanagadde wrote:
> >> On Sat, Oct 24, 2015 at 7:17 PM, Henrik Gramner  wrote:
> >> > On Sun, Oct 25, 2015 at 12:02 AM, Ganesh Ajjanagadde
> >> >  wrote:
> >> >> -static int cmp(void *key, const void *node)
> >> >> +static int cmp(const void *key, const void *node)
> >> >>  {
> >> >>  return (*(int64_t *) key) - ((const CacheEntry *) 
> >> >> node)->logical_pos;
> >> >>  }
> >> >
> >> >> -int ff_nut_sp_pos_cmp(const Syncpoint *a, const Syncpoint *b)
> >> >> +int ff_nut_sp_pos_cmp(const void *a, const void *b)
> >> >>  {
> >> >> -return ((a->pos - b->pos) >> 32) - ((b->pos - a->pos) >> 32);
> >> >> +Syncpoint va = *(Syncpoint *)a, vb = *(Syncpoint *)b;
> >> >> +return ((va.pos - vb.pos) >> 32) - ((vb.pos - va.pos) >> 32);
> >> >>  }
> >> >
> >> >> -int ff_nut_sp_pts_cmp(const Syncpoint *a, const Syncpoint *b)
> >> >> +int ff_nut_sp_pts_cmp(const void *a, const void *b)
> >> >>  {
> >> >> -return ((a->ts - b->ts) >> 32) - ((b->ts - a->ts) >> 32);
> >> >> +Syncpoint va = *(Syncpoint *)a, vb = *(Syncpoint *)b;
> >> >> +return ((va.ts - vb.ts) >> 32) - ((vb.ts - va.ts) >> 32);
> >> >>  }
> >> >
> >> > Casts discards const qualifiers.
> >>
> >> Good catch, changed. There is some more such constness being discarded
> >> in comparators, and some needlessly complex comparator logic in some
> >> places. Submitted a patch.
> >>
> >> >
> >> > Furthermore, why are you changing the two last functions to copy the
> >> > entire struct to a temporary local copy?
> >>
> >> Sorry, forgot they were structs.
> >> Fixed all, pushed. Thanks.
> >
> > i think this results in some new warnings for the tree test build
> >
> > libavutil/tree.c: In function ‘main’:
> > libavutil/tree.c:238:9: warning: passing argument 3 of ‘av_tree_insert’ 
> > from incompatible pointer type [enabled by default]
> > libavutil/tree.c:59:7: note: expected ‘int (*)(const void *, const void *)’ 
> > but argument is of type ‘int (*)(void *, const void *)’
> > libavutil/tree.c:244:13: warning: passing argument 3 of ‘av_tree_insert’ 
> > from incompatible pointer type [enabled by default]
> > libavutil/tree.c:59:7: note: expected ‘int (*)(const void *, const void *)’ 
> > but argument is of type ‘int (*)(void *, const void *)’
> > libavutil/tree.c:245:13: warning: passing argument 3 of ‘av_tree_find’ from 
> > incompatible pointer type [enabled by default]
> 
> Easy fix, and pushed. Sorry.

> BTW, how did you enable the test build?

make libavutil/tree-test
or
make fate

builds it

[...]
-- 
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

[FFmpeg-devel] [PATCH] swr: do not reject channel layouts that use channel 63

[wm4]

Channel layouts are essentially uint64_t, and every value is valid.
---
 libswresample/options.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libswresample/options.c b/libswresample/options.c
index 0bcb102..2bf8ab1 100644
--- a/libswresample/options.c
+++ b/libswresample/options.c
@@ -51,10 +51,10 @@ static const AVOption options[]={
 {"out_sample_fmt"   , "set output sample format", 
OFFSET(out_sample_fmt ), AV_OPT_TYPE_SAMPLE_FMT , {.i64=AV_SAMPLE_FMT_NONE}, -1 
  , INT_MAX, PARAM},
 {"tsf"  , "set internal sample format"  , 
OFFSET(user_int_sample_fmt), AV_OPT_TYPE_SAMPLE_FMT , 
{.i64=AV_SAMPLE_FMT_NONE}, -1   , INT_MAX, PARAM},
 {"internal_sample_fmt"  , "set internal sample format"  , 
OFFSET(user_int_sample_fmt), AV_OPT_TYPE_SAMPLE_FMT , 
{.i64=AV_SAMPLE_FMT_NONE}, -1   , INT_MAX, PARAM},
-{"icl"  , "set input channel layout", 
OFFSET(user_in_ch_layout ), AV_OPT_TYPE_CHANNEL_LAYOUT, {.i64=0   }, 0  
  , INT64_MAX , PARAM, "channel_layout"},
-{"in_channel_layout", "set input channel layout", 
OFFSET(user_in_ch_layout ), AV_OPT_TYPE_CHANNEL_LAYOUT, {.i64=0   }, 0  
  , INT64_MAX , PARAM, "channel_layout"},
-{"ocl"  , "set output channel layout"   , 
OFFSET(user_out_ch_layout), AV_OPT_TYPE_CHANNEL_LAYOUT, {.i64=0   }, 0  
  , INT64_MAX , PARAM, "channel_layout"},
-{"out_channel_layout"   , "set output channel layout"   , 
OFFSET(user_out_ch_layout), AV_OPT_TYPE_CHANNEL_LAYOUT, {.i64=0   }, 0  
  , INT64_MAX , PARAM, "channel_layout"},
+{"icl"  , "set input channel layout", 
OFFSET(user_in_ch_layout ), AV_OPT_TYPE_CHANNEL_LAYOUT, {.i64=0   }, 
INT64_MIN, INT64_MAX , PARAM, "channel_layout"},
+{"in_channel_layout", "set input channel layout", 
OFFSET(user_in_ch_layout ), AV_OPT_TYPE_CHANNEL_LAYOUT, {.i64=0   }, 
INT64_MIN, INT64_MAX , PARAM, "channel_layout"},
+{"ocl"  , "set output channel layout"   , 
OFFSET(user_out_ch_layout), AV_OPT_TYPE_CHANNEL_LAYOUT, {.i64=0   }, 
INT64_MIN, INT64_MAX , PARAM, "channel_layout"},
+{"out_channel_layout"   , "set output channel layout"   , 
OFFSET(user_out_ch_layout), AV_OPT_TYPE_CHANNEL_LAYOUT, {.i64=0   }, 
INT64_MIN, INT64_MAX , PARAM, "channel_layout"},
 {"clev" , "set center mix level", OFFSET(clev  
 ), AV_OPT_TYPE_FLOAT, {.dbl=C_30DB}, -32, 32, 
PARAM},
 {"center_mix_level" , "set center mix level", OFFSET(clev  
 ), AV_OPT_TYPE_FLOAT, {.dbl=C_30DB}, -32, 32, 
PARAM},
 {"slev" , "set surround mix level"  , OFFSET(slev  
 ), AV_OPT_TYPE_FLOAT, {.dbl=C_30DB}, -32, 32, 
PARAM},
-- 
2.6.1

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

Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: rewrite showcqt and add features

[Muhammad Faiz]

On Sun, Oct 25, 2015 at 9:51 AM, Michael Niedermayer
 wrote:
> On Sun, Oct 25, 2015 at 08:43:07AM +0700, Muhammad Faiz wrote:
>>  doc/filters.texi  |  181 +++--
>>  libavfilter/avf_showcqt.c | 1546 
>> +++---
>>  libavfilter/avf_showcqt.h |  104 +++
>>  libavfilter/version.h |2
>>  4 files changed, 1294 insertions(+), 539 deletions(-)
>> 3f83a0d334d780da3defa7d1fa3f09b3beb1db2d  
>> 0001-avfilter-avf_showcqt-rewrite-showcqt-and-add-feature.patch
>> From 337a659f96ef5dcf87aad1d541e745b7c262cbb9 Mon Sep 17 00:00:00 2001
>> From: Muhammad Faiz 
>> Date: Sat, 24 Oct 2015 00:44:42 +0700
>> Subject: [PATCH] avfilter/avf_showcqt: rewrite showcqt and add features
>
> this fails to build on "arm-linux-gnueabi-gcc-4.5 (Ubuntu/Linaro 
> 4.5.3-12ubuntu2) 4.5.3"
> In file included from ffmpeg/libavfilter/avf_showcqt.c:41:0:
> ffmpeg/libavfilter/avf_showcqt.h:39:30: warning: declaration does not declare 
> anything
> ffmpeg/libavfilter/avf_showcqt.h:40:30: warning: declaration does not declare 
> anything
> ffmpeg/libavfilter/avf_showcqt.c: In function ‘rgb_from_cqt’:
> ffmpeg/libavfilter/avf_showcqt.c:668:13: error: ‘ColorFloat’ has no member 
> named ‘r’
> ffmpeg/libavfilter/avf_showcqt.c:669:13: error: ‘ColorFloat’ has no member 
> named ‘g’
> ffmpeg/libavfilter/avf_showcqt.c:670:13: error: ‘ColorFloat’ has no member 
> named ‘b’
> ffmpeg/libavfilter/avf_showcqt.c: In function ‘yuv_from_cqt’:
> ffmpeg/libavfilter/avf_showcqt.c:682:13: error: ‘ColorFloat’ has no member 
> named ‘y’
> ffmpeg/libavfilter/avf_showcqt.c:683:13: error: ‘ColorFloat’ has no member 
> named ‘u’
> ffmpeg/libavfilter/avf_showcqt.c:684:13: error: ‘ColorFloat’ has no member 
> named ‘v’


revision: do not use anonymous struct, it seems it is not supported on
some platforms

thanks


0001-avfilter-avf_showcqt-rewrite-showcqt-and-add-feature.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavfi/drawutils: add const to blending mask.

[Michael Niedermayer]

On Sun, Oct 25, 2015 at 04:47:07PM +0100, Nicolas George wrote:
> Signed-off-by: Nicolas George 
> ---
>  libavfilter/drawutils.c | 9 +
>  libavfilter/drawutils.h | 2 +-
>  2 files changed, 6 insertions(+), 5 deletions(-)

LGTM

thx

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

Re: [FFmpeg-devel] [PATCH 3/3] avutil/tree: add additional const qualifier to the comparator

[Ganesh Ajjanagadde]

On Sun, Oct 25, 2015 at 1:03 PM, Michael Niedermayer
 wrote:
> On Sun, Oct 25, 2015 at 12:46:31PM -0400, Ganesh Ajjanagadde wrote:
>> On Sun, Oct 25, 2015 at 12:35 PM, Michael Niedermayer
>>  wrote:
>> > On Sat, Oct 24, 2015 at 09:03:03PM -0400, Ganesh Ajjanagadde wrote:
>> >> On Sat, Oct 24, 2015 at 7:17 PM, Henrik Gramner  
>> >> wrote:
>> >> > On Sun, Oct 25, 2015 at 12:02 AM, Ganesh Ajjanagadde
>> >> >  wrote:
>> >> >> -static int cmp(void *key, const void *node)
>> >> >> +static int cmp(const void *key, const void *node)
>> >> >>  {
>> >> >>  return (*(int64_t *) key) - ((const CacheEntry *) 
>> >> >> node)->logical_pos;
>> >> >>  }
>> >> >
>> >> >> -int ff_nut_sp_pos_cmp(const Syncpoint *a, const Syncpoint *b)
>> >> >> +int ff_nut_sp_pos_cmp(const void *a, const void *b)
>> >> >>  {
>> >> >> -return ((a->pos - b->pos) >> 32) - ((b->pos - a->pos) >> 32);
>> >> >> +Syncpoint va = *(Syncpoint *)a, vb = *(Syncpoint *)b;
>> >> >> +return ((va.pos - vb.pos) >> 32) - ((vb.pos - va.pos) >> 32);
>> >> >>  }
>> >> >
>> >> >> -int ff_nut_sp_pts_cmp(const Syncpoint *a, const Syncpoint *b)
>> >> >> +int ff_nut_sp_pts_cmp(const void *a, const void *b)
>> >> >>  {
>> >> >> -return ((a->ts - b->ts) >> 32) - ((b->ts - a->ts) >> 32);
>> >> >> +Syncpoint va = *(Syncpoint *)a, vb = *(Syncpoint *)b;
>> >> >> +return ((va.ts - vb.ts) >> 32) - ((vb.ts - va.ts) >> 32);
>> >> >>  }
>> >> >
>> >> > Casts discards const qualifiers.
>> >>
>> >> Good catch, changed. There is some more such constness being discarded
>> >> in comparators, and some needlessly complex comparator logic in some
>> >> places. Submitted a patch.
>> >>
>> >> >
>> >> > Furthermore, why are you changing the two last functions to copy the
>> >> > entire struct to a temporary local copy?
>> >>
>> >> Sorry, forgot they were structs.
>> >> Fixed all, pushed. Thanks.
>> >
>> > i think this results in some new warnings for the tree test build
>> >
>> > libavutil/tree.c: In function ‘main’:
>> > libavutil/tree.c:238:9: warning: passing argument 3 of ‘av_tree_insert’ 
>> > from incompatible pointer type [enabled by default]
>> > libavutil/tree.c:59:7: note: expected ‘int (*)(const void *, const void 
>> > *)’ but argument is of type ‘int (*)(void *, const void *)’
>> > libavutil/tree.c:244:13: warning: passing argument 3 of ‘av_tree_insert’ 
>> > from incompatible pointer type [enabled by default]
>> > libavutil/tree.c:59:7: note: expected ‘int (*)(const void *, const void 
>> > *)’ but argument is of type ‘int (*)(void *, const void *)’
>> > libavutil/tree.c:245:13: warning: passing argument 3 of ‘av_tree_find’ 
>> > from incompatible pointer type [enabled by default]
>>
>> Easy fix, and pushed. Sorry.
>
>> BTW, how did you enable the test build?
>
> make libavutil/tree-test
> or
> make fate
>
> builds it

Thanks.
>
> [...]
> --
> 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.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 04/11] libavformat/mxfdec.c: Try to increment current edit before rejecting a klv that spans onto next edit unit.

[Tomas Härdin]

On Thu, 2015-10-22 at 19:47 +0200, Alexis Ballier wrote:
> On Wed, 21 Oct 2015 23:45:07 +0200
> Tomas Härdin  wrote:
> 
> > On Wed, 2015-10-21 at 18:00 +0200, Alexis Ballier wrote:
> > > Some files such as those from tickets #2817 & #2776 claim to have
> > > constant edit unit size but, in fact, have some of them that are
> > > smaller. This confuses the demuxer that tries to infer the current
> > > edit unit from the position in the file. By trying to increment the
> > > current edit unit before rejecting the packet for this reason, we
> > > try to make it fit into its proper edit unit, which fixes demuxing
> > > of those files while preserving the check for misprobed OpAtom
> > > files. Seeking is not accurate but the files provide no way to
> > > properly find the relevant edit unit.
> > > 
> > > Fixes tickets #2817 & #2776.
> > > ---
> > >  libavformat/mxfdec.c | 12 
> > >  1 file changed, 12 insertions(+)
> > > 
> > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > > index 593604e..526eca6 100644
> > > --- a/libavformat/mxfdec.c
> > > +++ b/libavformat/mxfdec.c
> > > @@ -2956,6 +2956,18 @@ static int
> > > mxf_read_packet_old(AVFormatContext *s, AVPacket *pkt) next_ofs =
> > > mxf_set_current_edit_unit(mxf, klv.offset); 
> > >  if (next_ofs >= 0 && next_klv > next_ofs) {
> > > +/* Samples from tickets #2817 and #2776 claim to
> > > have
> > > + * constant edit unit size. However, some of them
> > > are smaller.  
> > 
> > What does "them" refer to here? The edit units or the KLVs?
> > 
> > > + * Just after those smaller edit units,  
> > 
> > Right, the edit units. Maybe rework the grammar slightly.
> > 
> > > + * Just after those smaller edit units, klv.offset
> > > is still in
> > > + * the same edit unit according to the
> > > computations from the
> > > + * constant edit unit size. If the klv finishes
> > > after, the next
> > > + * check would truncate the packet and prevent
> > > proper demuxing.
> > > + * Try to increment the current edit unit before
> > > doing that. */  
> > 
> > Let's see if I understand this correctly. For say EUBC = 10, there can
> > still be KLVs that are some size larger than 10, but smaller than
> > 2*EUBC = 20? So that the next edit unit would extend past the end of
> > the KLV, and thus be bogus?
> > 
> >   KLV: |header|---|header|--|
> > Edit unit:|0123456789|bogus<10|  |0123456789|bgs|
> > 
> > IIRC with MXF the bogus parts should still count as part of the
> > essence stream. Maybe I'm missing something.
> 
> It's simpler than that, and if you don't understand then the comment
> likely needs improving :) let's see:
> 
> H = header, V = video, A,B,C = audio tracks, F = fill item
> 
> mxf file defines a proper edit unit, with EUBC = 10 to be something
> like:
> 
> 1234567890
> HVVVAFBFCF
> 
> now, in the samples, in some edit units, video is shorter; mxf spec
> says it should be padded by fill items, but they're not and look like:
> 
> 1234567890
> HVAFBFCF
> 
> when continuing to read, we have:
> 
> 12345678901234567890
> HVAFBFCFHVVVAFBFCF
> | eu 1   || eu 2   |
> 
> as you can see, 2nd video packet is still in the first edit unit
> according to EUBC, and extends to next one.

Ah, that makes it a lot clearer :)

> that's what the patch is about: try to increment edit unit before
> rejecting the packet.
> 
> in 'MXF_DVCAM_not_demuxable.mxf', those smaller video packets seem to
> correspond to a black frame inserted between two scenes.
> 
> I've tried hard to get something better, but nothing seemed to work
> properly; best other option I had was to increment edit unit when
> seeing a system item, which worked but broke tests and in which I'm not
> so confident it won't break with other broken files...

Yeah, breaking existing tests is obviously not OK. But increasing
current_edit_unit like that seems a bit too suspect.

What your patch seems to end up doing with that
max_set_current_edit_unit() call is call mxf_edit_unit_absolute_offset()
like:

mxf_edit_unit_absolute_offset(mxf, t, mxf->current_edit_unit + 1, NULL, 
_ofs, 0)

Maybe you could make use of just that function call (with
mxf->current_edit_unit + *2*), instead of potentially messing
current_edit_unit up for some corner cases..

/Tomas


signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/huffman: replace qsort with AV_QSORT

[Ganesh Ajjanagadde]

On Sun, Oct 25, 2015 at 8:12 AM, Michael Niedermayer
 wrote:
> On Sat, Oct 24, 2015 at 09:05:21AM -0400, Ganesh Ajjanagadde wrote:
>> On Thu, Oct 22, 2015 at 10:25 PM, Ganesh Ajjanagadde
>>  wrote:
>> >
>> > On Thu, Oct 22, 2015 at 9:28 PM, Timothy Gu  wrote:
>> > > On Thu, Oct 22, 2015 at 5:01 PM Ganesh Ajjanagadde 
>> > > 
>> > > wrote:
>> > >>
>> > >> Sample benchmark (x86-64, Haswell, GNU/Linux), fraps-v2 from FATE:
>> > >> new:
>> > >> 280110 decicycles in qsort,   1 runs,  0 skips
>> > >> 268260 decicycles in qsort,   2 runs,  0 skips
>> > >>
>> > >> old:
>> > >> 1469910 decicycles in qsort,   1 runs,  0 skips
>> > >>  952950 decicycles in qsort,   2 runs,  0 skips
>> > >
>> > >
>> > > Usually it takes more than 2 runs to make sure something is faster than 
>> > > the
>> > > other (try -stream_loop 1 on the input).
>> >
>> > In this case the gain should be obvious due to inlining. Nevertheless,
>> > here are new numbers. I chose vp6 for two reasons:
>> > 1. Above was for fraps-v2, giving vp6 for more "completeness".
>> > 2. stream_loop throws errors: Error while decoding stream #0:0:
>> > Invalid data found when processing input for fraps-v2.
>> >
>> > Here they are:
>> > vp6 (old):
>> >   78930 decicycles in qsort,   1 runs,  0 skips
>> >   45330 decicycles in qsort,   2 runs,  0 skips
>> >   27825 decicycles in qsort,   4 runs,  0 skips
>> >   17471 decicycles in qsort,   8 runs,  0 skips
>> >   12296 decicycles in qsort,  16 runs,  0 skips
>> >9554 decicycles in qsort,  32 runs,  0 skips
>> >8404 decicycles in qsort,  64 runs,  0 skips
>> >7405 decicycles in qsort, 128 runs,  0 skips
>> >6740 decicycles in qsort, 256 runs,  0 skips
>> >7540 decicycles in qsort, 512 runs,  0 skips
>> >9498 decicycles in qsort,1024 runs,  0 skips
>> >9938 decicycles in qsort,2048 runs,  0 skips
>> >8043 decicycles in qsort,4095 runs,  1 skips
>> >
>> > vp6 (new):
>> >   15880 decicycles in qsort,   1 runs,  0 skips
>> >   10730 decicycles in qsort,   2 runs,  0 skips
>> >   10155 decicycles in qsort,   4 runs,  0 skips
>> >7805 decicycles in qsort,   8 runs,  0 skips
>> >6883 decicycles in qsort,  16 runs,  0 skips
>> >6305 decicycles in qsort,  32 runs,  0 skips
>> >5854 decicycles in qsort,  64 runs,  0 skips
>> >5152 decicycles in qsort, 128 runs,  0 skips
>> >4452 decicycles in qsort, 256 runs,  0 skips
>> >4161 decicycles in qsort, 511 runs,  1 skips
>> >4081 decicycles in qsort,1023 runs,  1 skips
>> >4072 decicycles in qsort,2047 runs,  1 skips
>> >4004 decicycles in qsort,4095 runs,  1 skips
>>
>> ping
>
> LGTM
>
> thanks

pushed, thanks

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> While the State exists there can be no freedom; when there is freedom there
> will be no State. -- Vladimir Lenin
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] lavfi/drawutils: add const to blending mask.

[Nicolas George]

Signed-off-by: Nicolas George 
---
 libavfilter/drawutils.c | 9 +
 libavfilter/drawutils.h | 2 +-
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
index 91fffd5..1724a82 100644
--- a/libavfilter/drawutils.c
+++ b/libavfilter/drawutils.c
@@ -408,7 +408,7 @@ void ff_blend_rectangle(FFDrawContext *draw, FFDrawColor 
*color,
 }
 
 static void blend_pixel(uint8_t *dst, unsigned src, unsigned alpha,
-uint8_t *mask, int mask_linesize, int l2depth,
+const uint8_t *mask, int mask_linesize, int l2depth,
 unsigned w, unsigned h, unsigned shift, unsigned xm0)
 {
 unsigned xm, x, y, t = 0;
@@ -432,7 +432,7 @@ static void blend_pixel(uint8_t *dst, unsigned src, 
unsigned alpha,
 
 static void blend_line_hv(uint8_t *dst, int dst_delta,
   unsigned src, unsigned alpha,
-  uint8_t *mask, int mask_linesize, int l2depth, int w,
+  const uint8_t *mask, int mask_linesize, int l2depth, 
int w,
   unsigned hsub, unsigned vsub,
   int xm, int left, int right, int hband)
 {
@@ -457,12 +457,13 @@ static void blend_line_hv(uint8_t *dst, int dst_delta,
 
 void ff_blend_mask(FFDrawContext *draw, FFDrawColor *color,
uint8_t *dst[], int dst_linesize[], int dst_w, int dst_h,
-   uint8_t *mask,  int mask_linesize, int mask_w, int mask_h,
+   const uint8_t *mask,  int mask_linesize, int mask_w, int 
mask_h,
int l2depth, unsigned endianness, int x0, int y0)
 {
 unsigned alpha, nb_planes, nb_comp, plane, comp;
 int xm0, ym0, w_sub, h_sub, x_sub, y_sub, left, right, top, bottom, y;
-uint8_t *p0, *p, *m;
+uint8_t *p0, *p;
+const uint8_t *m;
 
 clip_interval(dst_w, , _w, );
 clip_interval(dst_h, , _h, );
diff --git a/libavfilter/drawutils.h b/libavfilter/drawutils.h
index 5e7..e247dd6 100644
--- a/libavfilter/drawutils.h
+++ b/libavfilter/drawutils.h
@@ -130,7 +130,7 @@ void ff_blend_rectangle(FFDrawContext *draw, FFDrawColor 
*color,
  */
 void ff_blend_mask(FFDrawContext *draw, FFDrawColor *color,
uint8_t *dst[], int dst_linesize[], int dst_w, int dst_h,
-   uint8_t *mask, int mask_linesize, int mask_w, int mask_h,
+   const uint8_t *mask, int mask_linesize, int mask_w, int 
mask_h,
int l2depth, unsigned endianness, int x0, int y0);
 
 /**
-- 
2.6.1

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

Re: [FFmpeg-devel] [PATCH 2/2] lavfi: add testsrc2 test source.

[Nicolas George]

Le quartidi 4 brumaire, an CCXXIV, Nicolas George a écrit :
> Similar to testsrc, but using drawutils and therefore
> supporting a lot of pixel formats instead of just rgb24.
> This allows using it as input for other tests without
> requiring a format conversion.
> It is also slightly faster than testsrc for some reason.
> 
> Signed-off-by: Nicolas George 

Forgot to add: to see what it looks like without applying and compiling:

http://www.normalesup.org/~george/tmp/testsrc2.mp4
http://www.normalesup.org/~george/tmp/testsrc2.png

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]lavf/xwma: Support wmapro

[Paul B Mahol]

On 10/25/15, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch fixes ticket #4963 for me.
>
> Please comment, Carl Eugen
>

The 24 should be 16, lgtm otherwise.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] x86/intmath: allow the source operand for icc/icl ff_ctzll to be a memory location

[Matt Oliver]

On 26 October 2015 at 00:43, Hendrik Leppkes  wrote:

> On Sun, Oct 25, 2015 at 12:30 PM, Matt Oliver 
> wrote:
> > On 25 October 2015 at 22:16, Hendrik Leppkes 
> wrote:
> >
> >> On Sun, Oct 25, 2015 at 11:26 AM, Matt Oliver 
> >> wrote:
> >> > On 25 October 2015 at 12:22, Ganesh Ajjanagadde 
> >> wrote:
> >> >
> >> >> On Sat, Oct 24, 2015 at 7:03 PM, James Almer 
> wrote:
> >> >> > On 10/24/2015 7:48 PM, Ganesh Ajjanagadde wrote:
> >> >> >> On Sat, Oct 24, 2015 at 6:08 PM, James Almer 
> >> wrote:
> >> >> >>> This gives the compiler some flexibility
> >> >> >>>
> >> >> >>> Signed-off-by: James Almer 
> >> >> >>> ---
> >> >> >>>  libavutil/x86/intmath.h | 2 +-
> >> >> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >> >>>
> >> >> >>> diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
> >> >> >>> index 7881e3c..10d3e7f 100644
> >> >> >>> --- a/libavutil/x86/intmath.h
> >> >> >>> +++ b/libavutil/x86/intmath.h
> >> >> >>> @@ -36,7 +36,7 @@ static av_always_inline av_const int
> >> >> ff_ctzll_x86(long long v)
> >> >> >>>  {
> >> >> >>>  #   if ARCH_X86_64
> >> >> >>>  uint64_t c;
> >> >> >>> -__asm__("bsfq %1,%0" : "=r" (c) : "r" (v));
> >> >> >>> +__asm__ ("bsfq %1,%0" : "=r" (c) : "rm" (v));
> >> >> >>>  return c;
> >> >> >>>  #   else
> >> >> >>>  return ((uint32_t)v == 0) ? _bit_scan_forward((uint32_t)(v
> >>
> >> >> 32)) + 32 : _bit_scan_forward((uint32_t)v);
> >> >> >>> --
> >> >> >>> 2.6.2
> >> >> >>
> >> >> >> This question may be silly, but can you clarify when this asm
> code is
> >> >> >> used instead of __builtin_ctzll? For instance, I think on
> GNU/Linux,
> >> >> >> x86-64, sufficiently modern GCC (even with asm enabled), we should
> >> >> >> always use the builtin: the compiler knows best what to do with
> its
> >> >> >> builtin.
> >> >> >
> >> >> > This is ICC/ICL, not GCC.
> >> >>
> >> >> Ah, now I recall that _bit_scan_forward64 was not always available on
> >> >> ICC. Anyway, this is just a heads up to whoever uses ICC/ICL and the
> >> >> like: you may want to find out to which versions this built in
> >> >> applies.
> >> >
> >> >
> >> > bit_scan_forward64 isnt available on ICL at all, hence the use of asm.
> >> >
> >>
> >> Intels intrinsic guide lists _BitScanForward64 as the intrinsic to use,
> >> however.
> >>
> >>
> https://software.intel.com/sites/landingpage/IntrinsicsGuide/#techs=Other=373
> >
> >
> >  _BitScanForward64 is a msvc intrinsic only available on windows
> platforms
> > so not usable with ICC. The native asm implementation also performs
> better
> > with ICL hence its use.
>
> The "Intel(R) C++ Compiler User and Reference Guide" would care to
> disagree with you.
>

Well ill be... I dont have ICC on hand to check it but ill take Intels word
for it. Its interesting that Intel decided to support that intrinsic as
opposed to just extending there own version to 64b (i.e.
_bit_scan_forward64). _BitScanForward64 as far as I know was introduced by
msvc and made available in "winnt.h" hence the different naming convention
to other intrinsics. That said the inline asm version is still preferable
with Intel as the intrinsic passes the result via pointer which when tested
with msvc11 and 12 crt's resulted in horrible performance hits as the
compiler didnt optimise out the memory access in order to keep the result
in register (works fine with newer ICL 16 and msvcrt14 though).

Using tzcnt would be the more interesting option. Changing the asm to tzcnt
works with ICL. But also the use of the tzcnt intrinsic (_tzcnt_u64) would
be possible with both intel and msvc. I dont have anything older than
Haswell or Piledriver to double check but I have seen its use in several
other projects without issue so in theory it shouldnt be a problem.

If tzcnt is preferable I can make up a patch to convert the intel and msvc
versions to use the required intrinsic.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/5] concatdec: add metadata for file start time and duration

[Nicolas George]

Le tridi 3 brumaire, an CCXXIV, Marton Balint a écrit :
> Signed-off-by: Marton Balint 
> ---
>  libavformat/concatdec.c| 6 ++
>  tests/ref/fate/concat-demuxer-lavf-mxf | 2 +-
>  tests/ref/fate/concat-demuxer-lavf-mxf_d10 | 2 +-
>  tests/ref/fate/concat-demuxer-lavf-ts  | 2 +-
>  4 files changed, 9 insertions(+), 3 deletions(-)

I suspect that a basic run of ffmpeg to remux:

ffmpeg -i list.concat -c copy out.mkv

... would result in out.mkv having the metadata strings in it, which would
not be ok IMHO.

> 
> diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
> index f262d44..51b9703 100644
> --- a/libavformat/concatdec.c
> +++ b/libavformat/concatdec.c
> @@ -289,6 +289,7 @@ static int open_file(AVFormatContext *avf, unsigned 
> fileno)
>  {
>  ConcatContext *cat = avf->priv_data;
>  ConcatFile *file = >files[fileno];
> +AVDictionaryEntry *entry;
>  int ret;
>  
>  if (cat->avf)
> @@ -324,6 +325,11 @@ static int open_file(AVFormatContext *avf, unsigned 
> fileno)
>  file->duration -= cat->avf->duration - (file->outpoint - 
> file->file_start_time);
>  }
>  

> +if (!(entry = av_dict_get(file->metadata, "lavf.concatdec.start_time", 
> NULL, 0)))
> +av_dict_set_int(>metadata, "lavf.concatdec.start_time", 
> file->start_time, 0);
> +if (!(entry = av_dict_get(file->metadata, "lavf.concatdec.duration", 
> NULL, 0)))
> +av_dict_set_int(>metadata, "lavf.concatdec.duration", 
> file->duration, 0);

Since the metadata is properly namespaced, I do not think the test are
necessary.

> +
>  if ((ret = match_streams(avf)) < 0)
>  return ret;
>  if (file->inpoint != AV_NOPTS_VALUE) {
> diff --git a/tests/ref/fate/concat-demuxer-lavf-mxf 
> b/tests/ref/fate/concat-demuxer-lavf-mxf
> index a6fa554..d6c82d6 100644
> --- a/tests/ref/fate/concat-demuxer-lavf-mxf
> +++ b/tests/ref/fate/concat-demuxer-lavf-mxf
> @@ -1 +1 @@

> -56359998da34c3957124a8928fb58f3d 
> *tests/data/fate/concat-demuxer-lavf-mxf.ffprobe
> +23cd3acf3db9ee19228f381f05f1f3b9 
> *tests/data/fate/concat-demuxer-lavf-mxf.ffprobe

If the ref files were not hashed, it would be easier to be sure the change
is valid.

> diff --git a/tests/ref/fate/concat-demuxer-lavf-mxf_d10 
> b/tests/ref/fate/concat-demuxer-lavf-mxf_d10
> index 018d631..08777f7 100644
> --- a/tests/ref/fate/concat-demuxer-lavf-mxf_d10
> +++ b/tests/ref/fate/concat-demuxer-lavf-mxf_d10
> @@ -1 +1 @@
> -89c81149b4673c60aba7cf5f27cec823 
> *tests/data/fate/concat-demuxer-lavf-mxf_d10.ffprobe
> +bd1c6cc871fe5193186a03554ebc84c1 
> *tests/data/fate/concat-demuxer-lavf-mxf_d10.ffprobe
> diff --git a/tests/ref/fate/concat-demuxer-lavf-ts 
> b/tests/ref/fate/concat-demuxer-lavf-ts
> index 2e8ba46..a01f712 100644
> --- a/tests/ref/fate/concat-demuxer-lavf-ts
> +++ b/tests/ref/fate/concat-demuxer-lavf-ts
> @@ -1 +1 @@
> -1993b3613952fa76da8c5c260a16a96a 
> *tests/data/fate/concat-demuxer-lavf-ts.ffprobe
> +728e773e5009f7f652c1677573b6c8d2 
> *tests/data/fate/concat-demuxer-lavf-ts.ffprobe

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] all: simplify qsort comparators, and add const-correctness

[Ganesh Ajjanagadde]

On Sun, Oct 25, 2015 at 9:46 AM, Ganesh Ajjanagadde
 wrote:
> On Sat, Oct 24, 2015 at 9:38 PM, Mark Harris  wrote:

  static int compare_int64(const void *a, const void *b)
  {
 -int64_t va = *(int64_t *)a, vb = *(int64_t *)b;
 -return va < vb ? -1 : va > vb ? +1 : 0;
 +return *(const int64_t *)a - *(const int64_t *)b;
  }

>>>
>>> What if the result doesn't fit in int? The input is not int.
>>
>> Even for int this transformation is not valid assuming that the full
>> range of int is possible.  For example if *a = INT_MAX and *b = -1
>> then *a - *b = INT_MAX+1 which is negative when cast to an int.
>
> point taken, but this will need to be checked more carefully: for
> instance, sometimes the integers fit in only the lower 24/16 bits,
> etc. I have decided the following: this patch will only address the
> const-ness. The next patch will be a scan through the qsort
> comparators, and appropriately modifying the comparator by fixing
> existing issues (if any) related to your point, and avoiding branches
> when possibles.

Seems like the (x > y) - (x < y) trick works very well: GCC optimizes
it to branch-less code, and it is overflow safe:
https://stackoverflow.com/questions/10996418/efficient-integer-compare-function/10997428#10997428

Will submit patch to convert all qsort comparators (the ones for
integers) to this form, yielding two benefits:
1. Branchless code.
2. Consistency across the codebase.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] all: simplify qsort comparators, and add const-correctness

[Ganesh Ajjanagadde]

On Sun, Oct 25, 2015 at 11:12 AM, Nicolas George  wrote:
> Le quartidi 4 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> Seems like the (x > y) - (x < y) trick works very well: GCC optimizes
>> it to branch-less code, and it is overflow safe:
>> https://stackoverflow.com/questions/10996418/efficient-integer-compare-function/10997428#10997428
>>
>> Will submit patch to convert all qsort comparators (the ones for
>> integers) to this form, yielding two benefits:
>
> Nice. Maybe make it a macro: AV_DIFFSIGN(x, y).

Maybe more like FFDIFFSIGN, I don't think the AV_ prefix is ideal. FF
also has the advantage of being consistent with existing FFMIN, FFMAX,
FFABS, etc. Nevertheless, this is off-topic for this thread. We can
discuss further when I submit the patches.

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

[FFmpeg-devel] [PATCH 2/2] lavfi: add testsrc2 test source.

[Nicolas George]

Similar to testsrc, but using drawutils and therefore
supporting a lot of pixel formats instead of just rgb24.
This allows using it as input for other tests without
requiring a format conversion.
It is also slightly faster than testsrc for some reason.

Signed-off-by: Nicolas George 
---
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/vsrc_testsrc.c | 271 +
 tests/fate/filter-video.mak|   9 ++
 tests/ref/fate/filter-testsrc2-rgb24   |  71 +
 tests/ref/fate/filter-testsrc2-yuv420p |  71 +
 tests/ref/fate/filter-testsrc2-yuv444p |  71 +
 7 files changed, 495 insertions(+)
 create mode 100644 tests/ref/fate/filter-testsrc2-rgb24
 create mode 100644 tests/ref/fate/filter-testsrc2-yuv420p
 create mode 100644 tests/ref/fate/filter-testsrc2-yuv444p

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 8e776c1..dd4f547 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -263,6 +263,7 @@ OBJS-$(CONFIG_RGBTESTSRC_FILTER) += 
vsrc_testsrc.o
 OBJS-$(CONFIG_SMPTEBARS_FILTER)  += vsrc_testsrc.o
 OBJS-$(CONFIG_SMPTEHDBARS_FILTER)+= vsrc_testsrc.o
 OBJS-$(CONFIG_TESTSRC_FILTER)+= vsrc_testsrc.o
+OBJS-$(CONFIG_TESTSRC2_FILTER)   += vsrc_testsrc.o
 
 OBJS-$(CONFIG_NULLSINK_FILTER)   += vsink_nullsink.o
 
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 9385fdf..8e363a0 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -284,6 +284,7 @@ void avfilter_register_all(void)
 REGISTER_FILTER(SMPTEBARS,  smptebars,  vsrc);
 REGISTER_FILTER(SMPTEHDBARS,smptehdbars,vsrc);
 REGISTER_FILTER(TESTSRC,testsrc,vsrc);
+REGISTER_FILTER(TESTSRC2,   testsrc2,   vsrc);
 
 REGISTER_FILTER(NULLSINK,   nullsink,   vsink);
 
diff --git a/libavfilter/vsrc_testsrc.c b/libavfilter/vsrc_testsrc.c
index f63c861..1fca3e7 100644
--- a/libavfilter/vsrc_testsrc.c
+++ b/libavfilter/vsrc_testsrc.c
@@ -41,6 +41,7 @@
 #include "libavutil/imgutils.h"
 #include "libavutil/intreadwrite.h"
 #include "libavutil/parseutils.h"
+#include "libavutil/xga_font_data.h"
 #include "avfilter.h"
 #include "drawutils.h"
 #include "formats.h"
@@ -679,6 +680,276 @@ AVFilter ff_vsrc_testsrc = {
 
 #endif /* CONFIG_TESTSRC_FILTER */
 
+#if CONFIG_TESTSRC2_FILTER
+
+static const AVOption testsrc2_options[] = {
+COMMON_OPTIONS
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(testsrc2);
+
+static void set_color(TestSourceContext *s, FFDrawColor *color, uint32_t argb)
+{
+uint8_t rgba[4] = { (argb >> 16) & 0xFF,
+(argb >>  8) & 0xFF,
+(argb >>  0) & 0xFF,
+(argb >> 24) & 0xFF, };
+ff_draw_color(>draw, color, rgba);
+}
+
+static uint32_t color_gradient(unsigned index)
+{
+unsigned si = index & 0xFF, sd = 0xFF - si;
+switch (index >> 8) {
+case 0: return 0xFF + (si <<  8);
+case 1: return 0x00FF00 + (sd << 16);
+case 2: return 0x00FF00 + (si <<  0);
+case 3: return 0xFF + (sd <<  8);
+case 4: return 0xFF + (si << 16);
+case 5: return 0xFF + (sd <<  0);
+}
+av_assert0(0);
+}
+
+static void draw_text(TestSourceContext *s, AVFrame *frame, FFDrawColor *color,
+  int x0, int y0, const uint8_t *text)
+{
+int x = x0;
+
+for (; *text; text++) {
+if (*text == '\n') {
+x = x0;
+y0 += 16;
+continue;
+}
+ff_blend_mask(>draw, color, frame->data, frame->linesize,
+  frame->width, frame->height,
+  avpriv_vga16_font + *text * 16, 1, 8, 16, 0, 0, x, y0);
+x += 8;
+}
+}
+
+static void test2_fill_picture(AVFilterContext *ctx, AVFrame *frame)
+{
+TestSourceContext *s = ctx->priv;
+FFDrawColor color;
+
+/* colored background */
+{
+unsigned i, x = 0, x2;
+
+x = 0;
+for (i = 1; i < 7; i++) {
+x2 = av_rescale(i, s->w, 6);
+x2 = ff_draw_round_to_sub(>draw, 0, 0, x2);
+set_color(s, , ((i & 1) ? 0xFF : 0) |
+ ((i & 2) ? 0x00FF00 : 0) |
+ ((i & 4) ? 0xFF : 0));
+ff_fill_rectangle(>draw, , frame->data, frame->linesize,
+  x, 0, x2 - x, frame->height);
+x = x2;
+}
+}
+
+/* oblique gradient */
+/* note: too slow if using blending */
+if (s->h >= 64) {
+unsigned x, dx, y0, y, g0, g;
+
+dx = ff_draw_round_to_sub(>draw, 0, +1, 1);
+y0 = av_rescale_q(s->pts, s->time_base, av_make_q(2, s->h - 16));
+g0 = av_rescale_q(s->pts, s->time_base, av_make_q(1, 128));
+for (x = 0; x < s->w; x += dx) {
+g = (av_rescale(x, 6 * 256, 

Re: [FFmpeg-devel] [PATCH 2/5] fate: add concat demuxer tests

[Marton Balint]

On Sun, 25 Oct 2015, Nicolas George wrote:

[...]


--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -249,6 +249,20 @@ gapless(){
 do_md5sum $decfile3
 }

+concat(){



+template=$(target_path $1)


Should it really be target_path? The template is in the source.


You are right, target path is unneeded here.


+sample=$(target_path $2)
+
+concatfile="${outdir}/${test}.ffconcat"
+packetfile="${outdir}/${test}.ffprobe"
+cleanfiles="$concatfile $packetfile"
+
+awk "{gsub(/%SRCFILE%/, \"$sample\"); print}" $template > $concatfile
+run ffprobe${PROGSUF} -show_streams -show_packets -v 0 -fflags keepside -f 
concat $concatfile > $packetfile
+



+do_md5sum $packetfile


Since the output files are text, I would prefer it being the reference as
is, without a hash. With a hash, you need two extra steps to know what you
just broke.


I used the md5 hash because the packet files are quite big - around 
3000-1 lines each. It seemed like a waste of space in the repository 
for relatively little benefit.





+}
+
 mkdir -p "$outdir"

 # Disable globbing: command arguments may contain globbing characters and
diff --git a/tests/fate/concatdec.mak b/tests/fate/concatdec.mak
new file mode 100644
index 000..89d5409
--- /dev/null
+++ b/tests/fate/concatdec.mak
@@ -0,0 +1,12 @@
+FATE_CONCAT_TEMPLATE=tests/test_template.ffconcat
+
+FATE_CONCAT_DEMUXER_LAVF-$(call ENCDEC2, MPEG2VIDEO, MP2, MPEGTS)+= ts
+FATE_CONCAT_DEMUXER_LAVF-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF) += mxf
+FATE_CONCAT_DEMUXER_LAVF-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF) += mxf_d10
+
+$(foreach D,$(FATE_CONCAT_DEMUXER_LAVF-yes),$(eval 
fate-concat-demuxer-lavf-$(D): ffprobe$(PROGSSUF)$(EXESUF) fate-lavf-$(D)))
+$(foreach D,$(FATE_CONCAT_DEMUXER_LAVF-yes),$(eval 
fate-concat-demuxer-lavf-$(D): CMD = concat $(FATE_CONCAT_TEMPLATE) 
tests/data/lavf/lavf.$(D)))
+
+FATE_CONCAT_DEMUXER-$(CONFIG_CONCAT_DEMUXER) += 
$(FATE_CONCAT_DEMUXER_LAVF-yes:%=fate-concat-demuxer-lavf-%)
+
+FATE-$(CONFIG_FFPROBE) += $(FATE_CONCAT_DEMUXER-yes)


I am not fluent enough in make, I will trust you on this.


I am not very fluent either, I only hope I've made it right...

[...]


diff --git a/tests/test_template.ffconcat b/tests/test_template.ffconcat
new file mode 100644
index 000..e9b685d
--- /dev/null
+++ b/tests/test_template.ffconcat
@@ -0,0 +1,112 @@



+#ffconcat version 1.0
+# ^ header is commented out to avoid probing therefore enable unsafe paths


Probably better to pass "-safe 0" explicitly.


OK.


+
+file  %SRCFILE%
+
+file  %SRCFILE%
+file_packet_metadata dummy=1
+duration  1
+



+file  %SRCFILE%
+inpoint   00:00.00
+outpoint  00:00.04
+
+file  %SRCFILE%
+inpoint   00:00.04
+outpoint  00:00.08



Does it need that many in/outpoints?


I used this many (25 1-frame segment) because this is also a seek test for 
open gop mxf. I can reduce it but in that case I will have to maintain my 
own out of tree tests for it which is counter-productive IMHO.


Let me know what you think, I can change any point you still find 
unjustified.


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

Re: [FFmpeg-devel] [PATCH 2/2] lavfi: add testsrc2 test source.

[Paul B Mahol]

On 10/25/15, Nicolas George  wrote:
> Le quartidi 4 brumaire, an CCXXIV, Nicolas George a ecrit :
>> Similar to testsrc, but using drawutils and therefore
>> supporting a lot of pixel formats instead of just rgb24.
>> This allows using it as input for other tests without
>> requiring a format conversion.
>> It is also slightly faster than testsrc for some reason.
>>
>> Signed-off-by: Nicolas George 
>
> Forgot to add: to see what it looks like without applying and compiling:
>
> http://www.normalesup.org/~george/tmp/testsrc2.mp4
> http://www.normalesup.org/~george/tmp/testsrc2.png
>

WOW, really looks nice. I slightly dislike name, have no better
alternative though.

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

Re: [FFmpeg-devel] [PATCH] avfilter: add vibrato filter

[Ganesh Ajjanagadde]

On Sun, Oct 25, 2015 at 12:00 PM, Paul B Mahol  wrote:
> On 10/24/15, Kyle Swanson  wrote:
>> Signed-off-by: Kyle Swanson 
>> ---
>>  Changelog|   2 +-
>>  doc/filters.texi |  16 
>>  libavfilter/Makefile |   1 +
>>  libavfilter/af_vibrato.c | 210
>> +++
>>  libavfilter/allfilters.c |   1 +
>>  libavfilter/version.h|   2 +-
>>  6 files changed, 230 insertions(+), 2 deletions(-)
>>  create mode 100644 libavfilter/af_vibrato.c
>>
>
> Will apply in next 24 hours if nobody have comments.

are basic tests part of the requirements of a new filter, or can that
be done in a separate commit?

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

Re: [FFmpeg-devel] [PATCH 3/3] avutil/tree: add additional const qualifier to the comparator

[Michael Niedermayer]

On Sat, Oct 24, 2015 at 09:03:03PM -0400, Ganesh Ajjanagadde wrote:
> On Sat, Oct 24, 2015 at 7:17 PM, Henrik Gramner  wrote:
> > On Sun, Oct 25, 2015 at 12:02 AM, Ganesh Ajjanagadde
> >  wrote:
> >> -static int cmp(void *key, const void *node)
> >> +static int cmp(const void *key, const void *node)
> >>  {
> >>  return (*(int64_t *) key) - ((const CacheEntry *) node)->logical_pos;
> >>  }
> >
> >> -int ff_nut_sp_pos_cmp(const Syncpoint *a, const Syncpoint *b)
> >> +int ff_nut_sp_pos_cmp(const void *a, const void *b)
> >>  {
> >> -return ((a->pos - b->pos) >> 32) - ((b->pos - a->pos) >> 32);
> >> +Syncpoint va = *(Syncpoint *)a, vb = *(Syncpoint *)b;
> >> +return ((va.pos - vb.pos) >> 32) - ((vb.pos - va.pos) >> 32);
> >>  }
> >
> >> -int ff_nut_sp_pts_cmp(const Syncpoint *a, const Syncpoint *b)
> >> +int ff_nut_sp_pts_cmp(const void *a, const void *b)
> >>  {
> >> -return ((a->ts - b->ts) >> 32) - ((b->ts - a->ts) >> 32);
> >> +Syncpoint va = *(Syncpoint *)a, vb = *(Syncpoint *)b;
> >> +return ((va.ts - vb.ts) >> 32) - ((vb.ts - va.ts) >> 32);
> >>  }
> >
> > Casts discards const qualifiers.
> 
> Good catch, changed. There is some more such constness being discarded
> in comparators, and some needlessly complex comparator logic in some
> places. Submitted a patch.
> 
> >
> > Furthermore, why are you changing the two last functions to copy the
> > entire struct to a temporary local copy?
> 
> Sorry, forgot they were structs.
> Fixed all, pushed. Thanks.

i think this results in some new warnings for the tree test build

libavutil/tree.c: In function ‘main’:
libavutil/tree.c:238:9: warning: passing argument 3 of ‘av_tree_insert’ from 
incompatible pointer type [enabled by default]
libavutil/tree.c:59:7: note: expected ‘int (*)(const void *, const void *)’ but 
argument is of type ‘int (*)(void *, const void *)’
libavutil/tree.c:244:13: warning: passing argument 3 of ‘av_tree_insert’ from 
incompatible pointer type [enabled by default]
libavutil/tree.c:59:7: note: expected ‘int (*)(const void *, const void *)’ but 
argument is of type ‘int (*)(void *, const void *)’
libavutil/tree.c:245:13: warning: passing argument 3 of ‘av_tree_find’ from 
incompatible pointer type [enabled by default]


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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

[FFmpeg-devel] [PATCH] lavfi: add realtime filter.

[Nicolas George]

Similar to the -re option in ffmpeg that only works for input files.
Can be used at any place in the filter graph.

Signed-off-by: Nicolas George 
---
 Changelog|   1 +
 doc/filters.texi |  16 ++
 libavfilter/Makefile |   2 +
 libavfilter/allfilters.c |   2 +
 libavfilter/f_realtime.c | 130 +++
 5 files changed, 151 insertions(+)
 create mode 100644 libavfilter/f_realtime.c

diff --git a/Changelog b/Changelog
index abaac19..1c8fe37 100644
--- a/Changelog
+++ b/Changelog
@@ -25,6 +25,7 @@ version :
 - wve demuxer
 - zero-copy Intel QSV transcoding in ffmpeg
 - shuffleframes filter
+- realtime filter
 
 
 version 2.8:
diff --git a/doc/filters.texi b/doc/filters.texi
index 5a35bde..141394c 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -13052,6 +13052,22 @@ following one, the permission might not be received as 
expected in that
 following filter. Inserting a @ref{format} or @ref{aformat} filter before the
 perms/aperms filter can avoid this problem.
 
+@section realtime, arealtime
+
+Slow down filtering to match real time approximatively.
+
+These filters will pause the filtering for a variable amount of time to
+match the output rate with the input timestamps.
+They are similar to the @option{re} option to @code{ffmpeg}.
+
+They accept the following options:
+
+@table @option
+@item limit
+Time limit for the pauses. Any pause longer than that will be considered
+a timestamp discontinuity and reset the timer. Default is 2 seconds.
+@end table
+
 @section select, aselect
 
 Select frames to pass in output.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index dd4f547..9c07d98 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -39,6 +39,7 @@ OBJS-$(CONFIG_ANULL_FILTER)  += af_anull.o
 OBJS-$(CONFIG_APAD_FILTER)   += af_apad.o
 OBJS-$(CONFIG_APERMS_FILTER) += f_perms.o
 OBJS-$(CONFIG_APHASER_FILTER)+= af_aphaser.o 
generate_wave_table.o
+OBJS-$(CONFIG_AREALTIME_FILTER)  += f_realtime.o
 OBJS-$(CONFIG_ARESAMPLE_FILTER)  += af_aresample.o
 OBJS-$(CONFIG_AREVERSE_FILTER)   += f_reverse.o
 OBJS-$(CONFIG_ASELECT_FILTER)+= f_select.o
@@ -196,6 +197,7 @@ OBJS-$(CONFIG_PSNR_FILTER)   += vf_psnr.o 
dualinput.o framesync.
 OBJS-$(CONFIG_PULLUP_FILTER) += vf_pullup.o
 OBJS-$(CONFIG_QP_FILTER) += vf_qp.o
 OBJS-$(CONFIG_RANDOM_FILTER) += vf_random.o
+OBJS-$(CONFIG_REALTIME_FILTER)   += f_realtime.o
 OBJS-$(CONFIG_REMOVEGRAIN_FILTER)+= vf_removegrain.o
 OBJS-$(CONFIG_REMOVELOGO_FILTER) += bbox.o lswsutils.o lavfutils.o 
vf_removelogo.o
 OBJS-$(CONFIG_REPEATFIELDS_FILTER)   += vf_repeatfields.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 8e363a0..239fbb5 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -61,6 +61,7 @@ void avfilter_register_all(void)
 REGISTER_FILTER(APAD,   apad,   af);
 REGISTER_FILTER(APERMS, aperms, af);
 REGISTER_FILTER(APHASER,aphaser,af);
+REGISTER_FILTER(AREALTIME,  arealtime,  af);
 REGISTER_FILTER(ARESAMPLE,  aresample,  af);
 REGISTER_FILTER(AREVERSE,   areverse,   af);
 REGISTER_FILTER(ASELECT,aselect,af);
@@ -217,6 +218,7 @@ void avfilter_register_all(void)
 REGISTER_FILTER(PULLUP, pullup, vf);
 REGISTER_FILTER(QP, qp, vf);
 REGISTER_FILTER(RANDOM, random, vf);
+REGISTER_FILTER(REALTIME,   realtime,   vf);
 REGISTER_FILTER(REMOVEGRAIN,removegrain,vf);
 REGISTER_FILTER(REMOVELOGO, removelogo, vf);
 REGISTER_FILTER(REPEATFIELDS,   repeatfields,   vf);
diff --git a/libavfilter/f_realtime.c b/libavfilter/f_realtime.c
new file mode 100644
index 000..a50141c
--- /dev/null
+++ b/libavfilter/f_realtime.c
@@ -0,0 +1,130 @@
+/*
+ * Copyright (c) 2015 Nicolas George
+ *
+ * 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 "libavutil/opt.h"
+#include "libavutil/time.h"

Re: [FFmpeg-devel] [PATCH]lavc/proresdec2: Fix slice_count for very high resolutions

[Carl Eugen Hoyos]

On Sunday 25 October 2015 01:37:15 pm Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch intends to fix an issue reported by forum user Koracas:
> For slice_count > 0x1 FFmpeg fails to decode a frame, QT seems to
> ignore the value.

New patch attached.

Please comment, Carl Eugen
diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index 932f85f..2d47a13 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@ -180,7 +180,10 @@ static int decode_picture_header(AVCodecContext *avctx, 
const uint8_t *buf, cons
 else
 ctx->mb_height = (avctx->height + 15) >> 4;
 
-slice_count = AV_RB16(buf + 5);
+// QT ignores the written value
+// slice_count = AV_RB16(buf + 5);
+slice_count = ctx->mb_height * ((ctx->mb_width >> log2_slice_mb_width) +
+av_popcount(ctx->mb_width & (1 << 
log2_slice_mb_width) - 1));
 
 if (ctx->slice_count != slice_count || !ctx->slices) {
 av_freep(>slices);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avutil/tree: improve documentation for av_tree_find, av_tree_insert

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 6:02 PM, Ganesh Ajjanagadde
 wrote:
> This documents the additional constness, and provides a useful libc
> reference for the API specification of the comparator.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/tree.h | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/tree.h b/libavutil/tree.h
> index a14fa91..16dd8de 100644
> --- a/libavutil/tree.h
> +++ b/libavutil/tree.h
> @@ -56,6 +56,8 @@ struct AVTreeNode *av_tree_node_alloc(void);
>   * @param next If next is not NULL, then next[0] will contain the previous
>   * element and next[1] the next element. If either does not 
> exist,
>   * then the corresponding entry in next is unchanged.
> + * @param cmp compare function used to compare elements in the tree,
> + *API identical to that of libc's qsort
>   * @return An element with cmp(key, elem) == 0 or NULL if no such element
>   * exists in the tree.
>   */
> @@ -99,7 +101,8 @@ void *av_tree_find(const struct AVTreeNode *root, void 
> *key,
>   * return av_tree_insert(rootp, key, cmp, next);
>   * }
>   * @endcode
> - * @param cmp compare function used to compare elements in the tree
> + * @param cmp compare function used to compare elements in the tree, API 
> identical
> + *to that of libc's qsort
>   * @return If no insertion happened, the found element; if an insertion or
>   * removal happened, then either key or NULL will be returned.
>   * Which one it is depends on the tree state and the implementation. 
> You
> --
> 2.6.2
>

pushed as part of the set.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/5] concatdec: add metadata for file start time and duration

[Marton Balint]

On Sun, 25 Oct 2015, Nicolas George wrote:


Le tridi 3 brumaire, an CCXXIV, Marton Balint a écrit :

Signed-off-by: Marton Balint 
---
 libavformat/concatdec.c| 6 ++
 tests/ref/fate/concat-demuxer-lavf-mxf | 2 +-
 tests/ref/fate/concat-demuxer-lavf-mxf_d10 | 2 +-
 tests/ref/fate/concat-demuxer-lavf-ts  | 2 +-
 4 files changed, 9 insertions(+), 3 deletions(-)


I suspect that a basic run of ffmpeg to remux:

ffmpeg -i list.concat -c copy out.mkv

... would result in out.mkv having the metadata strings in it, which would
not be ok IMHO.


I couldn't actually reproduce this neither with mkv nor with nut, but I 
see that you are worried that the metadata may be kept in the output.


I'd rather keep this as it is, the user has to control the metadata he 
wants in his output, we never promised there won't be additional packet 
string metadata in a certain format, and the way I see it only NUT muxer 
actually parses AV_PKT_DATA_STRINGS_METADATA, and none of the encoders 
parse AVFrame metadata, so it does not really affect anybody.


If you still think this is problematic, I can do one or both of these 
options:

- Add a demuxer option which controls if the demuxer produces this
metadata or not.
- Add an ffconcat file global option which controls this.



diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index f262d44..51b9703 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -289,6 +289,7 @@ static int open_file(AVFormatContext *avf, unsigned fileno)
 {
 ConcatContext *cat = avf->priv_data;
 ConcatFile *file = >files[fileno];
+AVDictionaryEntry *entry;
 int ret;

 if (cat->avf)
@@ -324,6 +325,11 @@ static int open_file(AVFormatContext *avf, unsigned fileno)
 file->duration -= cat->avf->duration - (file->outpoint - 
file->file_start_time);
 }




+if (!(entry = av_dict_get(file->metadata, "lavf.concatdec.start_time", 
NULL, 0)))
+av_dict_set_int(>metadata, "lavf.concatdec.start_time", 
file->start_time, 0);
+if (!(entry = av_dict_get(file->metadata, "lavf.concatdec.duration", NULL, 
0)))
+av_dict_set_int(>metadata, "lavf.concatdec.duration", 
file->duration, 0);


Since the metadata is properly namespaced, I do not think the test are
necessary.


Ok.




+
 if ((ret = match_streams(avf)) < 0)
 return ret;
 if (file->inpoint != AV_NOPTS_VALUE) {
diff --git a/tests/ref/fate/concat-demuxer-lavf-mxf 
b/tests/ref/fate/concat-demuxer-lavf-mxf
index a6fa554..d6c82d6 100644
--- a/tests/ref/fate/concat-demuxer-lavf-mxf
+++ b/tests/ref/fate/concat-demuxer-lavf-mxf
@@ -1 +1 @@



-56359998da34c3957124a8928fb58f3d 
*tests/data/fate/concat-demuxer-lavf-mxf.ffprobe
+23cd3acf3db9ee19228f381f05f1f3b9 
*tests/data/fate/concat-demuxer-lavf-mxf.ffprobe


If the ref files were not hashed, it would be easier to be sure the change
is valid.


diff --git a/tests/ref/fate/concat-demuxer-lavf-mxf_d10 
b/tests/ref/fate/concat-demuxer-lavf-mxf_d10
index 018d631..08777f7 100644
--- a/tests/ref/fate/concat-demuxer-lavf-mxf_d10
+++ b/tests/ref/fate/concat-demuxer-lavf-mxf_d10
@@ -1 +1 @@
-89c81149b4673c60aba7cf5f27cec823 
*tests/data/fate/concat-demuxer-lavf-mxf_d10.ffprobe
+bd1c6cc871fe5193186a03554ebc84c1 
*tests/data/fate/concat-demuxer-lavf-mxf_d10.ffprobe
diff --git a/tests/ref/fate/concat-demuxer-lavf-ts 
b/tests/ref/fate/concat-demuxer-lavf-ts
index 2e8ba46..a01f712 100644
--- a/tests/ref/fate/concat-demuxer-lavf-ts
+++ b/tests/ref/fate/concat-demuxer-lavf-ts
@@ -1 +1 @@
-1993b3613952fa76da8c5c260a16a96a 
*tests/data/fate/concat-demuxer-lavf-ts.ffprobe
+728e773e5009f7f652c1677573b6c8d2 
*tests/data/fate/concat-demuxer-lavf-ts.ffprobe




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

Re: [FFmpeg-devel] [PATCH]lavf/xwma: Support wmapro

[Carl Eugen Hoyos]

Paul B Mahol  gmail.com> writes:

> > Attached patch fixes ticket #4963 for me.
> >
> > Please comment, Carl Eugen
> >
> 
> The 24 should be 16, lgtm otherwise.

Applied using bps from the waveformatex header.

Thank you, Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] avutil/opt: Support max > INT64_MAX in write_number() with AV_OPT_TYPE_INT64

[Ronald S. Bultje]

Hi,

On Sun, Oct 25, 2015 at 3:12 PM, wm4  wrote:

> On Sun, 25 Oct 2015 19:46:42 +0100
> Michael Niedermayer  wrote:
>
> > From: Michael Niedermayer 
> >
> > This allows for example to set max to UINT64_MAX and set values in that
> > range
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavutil/opt.c |   12 +++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/opt.c b/libavutil/opt.c
> > index 36eeeb0..157179c 100644
> > --- a/libavutil/opt.c
> > +++ b/libavutil/opt.c
> > @@ -102,7 +102,17 @@ static int write_number(void *obj, const AVOption
> *o, void *dst, double num, int
> >  case AV_OPT_TYPE_INT:   *(int   *)dst= llrint(num/den)*intnum;
> break;
> >  case AV_OPT_TYPE_DURATION:
> >  case AV_OPT_TYPE_CHANNEL_LAYOUT:
> > -case AV_OPT_TYPE_INT64: *(int64_t   *)dst= llrint(num/den)*intnum;
> break;
> > +case AV_OPT_TYPE_INT64:
> > +// We must special case uint64_t here as llrint() does not
> support values
> > +// outside the int64_t range and there is no portable function
> which does
> > +// "INT64_MAX + 1ULL" is used as it is representable exactly as
> IEEE double
> > +// while INT64_MAX is not
> > +if (o->max > INT64_MAX + 1ULL && num/den > INT64_MAX + 1ULL) {
> > +*(uint64_t *)dst = (llrint(num/den - (INT64_MAX + 1ULL)) +
> (INT64_MAX + 1ULL))*intnum;
> > +} else {
> > +*(int64_t  *)dst = llrint(num/den)*intnum;
> > +}
> > +break;
> >  case AV_OPT_TYPE_FLOAT: *(float *)dst= num*intnum/den;
>  break;
> >  case AV_OPT_TYPE_DOUBLE:*(double*)dst= num*intnum/den;
>  break;
> >  case AV_OPT_TYPE_RATIONAL:
>
> Introducing AV_OPT_TYPE_UINT64 would be cleaner...


+1.

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

Re: [FFmpeg-devel] [PATCH 1/2] lavfi/drawutils: add const to blending mask.

[Nicolas George]

Le quartidi 4 brumaire, an CCXXIV, Michael Niedermayer a écrit :
> LGTM

Thanks, pushed.

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] avfilter/vf_removegrain: replace qsort with AV_QSORT

[Ganesh Ajjanagadde]

filter_slice calls qsort, so qsort is in a performance critical
position. AV_QSORT is substantially faster due to the inlining of the
comparison callback. Thus, the increase in performance is worth the
increase in binary size.

Sample benchmark (x86-64, Haswell, GNU/Linux),
filter-removegrain-mode-02 (from FATE)
new:
  24060 decicycles in qsort,   1 runs,  0 skips
  15690 decicycles in qsort,   2 runs,  0 skips
   9307 decicycles in qsort,   4 runs,  0 skips
   5572 decicycles in qsort,   8 runs,  0 skips
   3485 decicycles in qsort,  16 runs,  0 skips
   2517 decicycles in qsort,  32 runs,  0 skips
   1979 decicycles in qsort,  64 runs,  0 skips
   1911 decicycles in qsort, 128 runs,  0 skips
   1568 decicycles in qsort, 256 runs,  0 skips
   1596 decicycles in qsort, 512 runs,  0 skips
   1614 decicycles in qsort,1024 runs,  0 skips
   1874 decicycles in qsort,2046 runs,  2 skips
   2186 decicycles in qsort,4094 runs,  2 skips

old:
 246960 decicycles in qsort,   1 runs,  0 skips
 135765 decicycles in qsort,   2 runs,  0 skips
  70920 decicycles in qsort,   4 runs,  0 skips
  37710 decicycles in qsort,   8 runs,  0 skips
  20831 decicycles in qsort,  16 runs,  0 skips
  12225 decicycles in qsort,  32 runs,  0 skips
   8083 decicycles in qsort,  64 runs,  0 skips
   6270 decicycles in qsort, 128 runs,  0 skips
   5321 decicycles in qsort, 256 runs,  0 skips
   4860 decicycles in qsort, 512 runs,  0 skips
   4424 decicycles in qsort,1024 runs,  0 skips
   4191 decicycles in qsort,2046 runs,  2 skips
   4934 decicycles in qsort,4094 runs,  2 skips

Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/vf_removegrain.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_removegrain.c b/libavfilter/vf_removegrain.c
index da17f6a..3a28b15 100644
--- a/libavfilter/vf_removegrain.c
+++ b/libavfilter/vf_removegrain.c
@@ -24,6 +24,7 @@
 #include "libavutil/imgutils.h"
 #include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
+#include "libavutil/qsort.h"
 #include "avfilter.h"
 #include "formats.h"
 #include "internal.h"
@@ -92,7 +93,7 @@ static int mode02(int c, int a1, int a2, int a3, int a4, int 
a5, int a6, int a7,
 {
 int a[8] = { a1, a2, a3, a4, a5, a6, a7, a8 };
 
-qsort(, 8, sizeof(a[0]), cmp_int);
+AV_QSORT(a, 8, int, cmp_int);
 
 return av_clip(c, a[2 - 1 ], a[7 - 1]);
 }
@@ -101,7 +102,7 @@ static int mode03(int c, int a1, int a2, int a3, int a4, 
int a5, int a6, int a7,
 {
 int a[8] = { a1, a2, a3, a4, a5, a6, a7, a8 };
 
-qsort(, 8, sizeof(a[0]), cmp_int);
+AV_QSORT(a, 8, int, cmp_int);
 
 return av_clip(c, a[3 - 1 ], a[6 - 1]);
 }
@@ -110,7 +111,7 @@ static int mode04(int c, int a1, int a2, int a3, int a4, 
int a5, int a6, int a7,
 {
 int a[8] = { a1, a2, a3, a4, a5, a6, a7, a8 };
 
-qsort(, 8, sizeof(a[0]), cmp_int);
+AV_QSORT(a, 8, int, cmp_int);
 
 return av_clip(c, a[4 - 1 ], a[5 - 1]);
 }
-- 
2.6.2

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