Re: [FFmpeg-devel] [DECISION] scaletempo filter

[John Warburton]

On Sat, May 4, 2019 at 3:34 PM Nicolas George  wrote:

> John Warburton (12019-05-04):
>
> > Is there a patch I can use to test scaletempo to compare it against
> atempo?
> > It'll be no trouble to do that with the normal audio that is
> time-adjusted
> > on that radio station. It may be that its increased quality is most
>
> John, we would appreciate your input about whether these new
> implementation of atempo is superior or equal to the existing one with
> regard to your needs.
>

You're welcome. I'm happy to test. My first chance to apply any patches
(and adjust where possible) will be next Wednesday, then I'll get back to
you. Glad to help with examining possible improvements to an already good
algorithm (for our purposes).
JW
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [DECISION] scaletempo filter

[John Warburton]

On Sat, May 4, 2019 at 2:41 PM Nicolas George  wrote:

> Paul B Mahol (12019-05-04):
> > I open votes for 7 days. Voting is about inclusion of scaletempo
> > filter (IMHO it is better than atempo) in FFmpeg.
> >
> > Thanks for voting.
>
> Voting for what? This mail does not look remotely like the voting
> procedure. For starters, a vote must come after a discussion failed to
> reach a consensus. AFACS, this is the first time scaletempo is mentioned
> on this mailing list this year.
>

An earlier post referring to scaletempo, from December 2017, suggested
replacement of atempo. Please may I note that at least one commercial radio
station, that I personally broadcast on daily, uses atempo for adjusting
the timing of news bulletins so they exactly fit a particular time. A
change in its operation, rather than the addition of a new filter, may
cause concern at least that one place.

Is there a patch I can use to test scaletempo to compare it against atempo?
It'll be no trouble to do that with the normal audio that is time-adjusted
on that radio station. It may be that its increased quality is most
welcome, of course.
with best wishes,
JW
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] doc/filters: document the unstability of the shorthand options notation.

[John Warburton]

On Mon, Aug 7, 2017 at 10:03 AM, Nicolas George  wrote:
>> >Lets take a step back and look at this
>> >
>> >There are some rarely used options in multi input filters like
>> >overlay which break.
>> >Noone even noticed except me
...

> Now, to all that stated a negative opinion about this:
>
> I have in the queue a patch series that changes the options in a minor
> way, but at the same time fixes bugs and long-standing limitations of
> lavfi and makes the code more robust and cleaner.
>
> Do you :
>
> 1. propose to implement and test compatibility options yourself?
>
> 2. own up you are blocking these enhancements?
>
> 3. accept the series and the breakage?

I am not a developer (though am learning to read the source code) but
if an old FFmpeg script of mine breaks, as they have on a couple of
occasions, isn't it logical for a user of the command line to go
straight to the documentation, and the answer (and the fix) always
seems to be there? Or just type "ffmpeg -h filter=scale" or similar,
where the order of un-named options isn't even mentioned? In my
experience today, much more so than in the olden days when we used to
type "C> wp.exe mydoc.wpd", CLI users aren't afraid of documentation
and development.

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

Re: [FFmpeg-devel] [PATCH 7/7] lavfi/vf_stack: move to activate design.

[John Warburton]

On Mon, Aug 7, 2017 at 10:08 AM, Nicolas George  wrote:
>
> This issue seems fixed by these changes:
>
> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/214306.html
>
> I thought it could only be triggered with the specific configuration
> caused by dualinput, but you obviously found another way.
>
> The patches in this series need some review before being pushed.

Confirming: applying the patch in
https://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/214306.html causes
multiple vf_stack calls to work again.

It didn't apply first time because I'd incorrectly saved the patch text.

Thank you very much for this suggestion!
J
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 7/7] lavfi/vf_stack: move to activate design.

[John Warburton]

On Mon, Aug 7, 2017 at 10:08 AM, Nicolas George  wrote:
>
> This issue seems fixed by these changes:
>
> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/214306.html
> ...
> Also, it would help deciding stuff if you, as a user, told us: if you
> had to write "scale=w=1536:h=512" instead of "scale=1536:512" to be
> completely sure that your scripts will not break on upgrade, would you
> consider that an unacceptable burden?

Thank you for letting me know about the incoming patch. Two of the
hunks failed to apply but I'll try sorting those out later (need to go
to a meeting right now).

The question about abbreviating parameters to filters: I am fine about
writing in the new way, but there are scripts run here regularly that
will need updating if the abbreviated form is lost. However, the
non-abbreviated form is far easier to read and, therefore, for others
to maintain.

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

Re: [FFmpeg-devel] [PATCH 7/7] lavfi/vf_stack: move to activate design.

[John Warburton]

On Sun, Aug 6, 2017 at 4:39 PM, Gyan  wrote:
> Is ticket #6566 also related?

This test case on ticket #6566 indeed freezes during the overlay on my
patched FFmpeg with the alteration to libav/vf_stack.c taken out. I
have not been able to test it in another way yet.

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

Re: [FFmpeg-devel] [PATCH 7/7] lavfi/vf_stack: move to activate design.

[John Warburton]

On Mon, Jul 17, 2017 at 3:19 PM, Nicolas George  wrote:
>
> Signed-off-by: Nicolas George 
> ---
>  libavfilter/Makefile   |  4 ++--
>  libavfilter/vf_stack.c | 32 +---
>  2 files changed, 15 insertions(+), 21 deletions(-)
>
>
> Works as expected. Including shortest.
> And no longer subject to bufferqueue overflows.

Gentlemen, I am sorry to report that this particular patch to
lavfi/vf_stack.c breaks FFmpeg on-screen output when a vertical stack
(vstack) follows a horizontal stack (hstack). Below, please find a
chain to -filter_complex, cut down from a much more complex chain,
that reproduces the problem.

FFmpeg here is compiled for Windows using mingw-w64 tool chain on Bash
for Windows. I usually make this up nearly every day without incident.

At commit 4e0e9ce2dc67a94c98d40a46e91fe5aa53ad0376 ("lavfi/framesync2:
implement "activate" design"), the following script downloads an audio
stream, and successfully produces three visual representations using
FFmpeg filters, output to the 'SDL' device. 'opengl' also works.

In this script, the avectorscope and showfreqs filters are
horizontally stacked; then this combination is stacked vertically with
an output from the ebur128 filter.

ffmpeg -v debug -i 'http://s3.yesstreaming.net:7001/;stream/'
-filter_complex "[a0]asplit=3[a][b][c];
[a]avectorscope=size=512x512[z]; [b]showfreqs[y]; [z][y]hstack[n];
[c]ebur128=video=1[d][e]; [d]scale=1536:512[g]; [n][g]vstack;
[e]anullsink" -f SDL Test

But once the patch to lavfi_vf_stack is applied, at commit
0dd8320e16bcdbe6b928e99489cf47abd16d3255, the same script results in a
blank, white display window using the SDL device, and a blank black
window using opengl. The text output from the ebur128 filter stops
after one line. Merely applying a single hstack or vstack works: but
the two together fail after this point:

https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/0dd8320e16bcdbe6b928e99489cf47abd16d3255
("lavfi/vf_stack: move to "activate" design")

Furthermore, compiling from today's git master but reversing ONLY the
above patch to vf_stack.c also results in a working FFmpeg when given
the above test case.

Both debug outputs from the parser are identical:

[Parsed_asplit_0 @ 022917a3eb60] Setting 'outputs' to value '3'
[Parsed_avectorscope_1 @ 022917a3e9c0] Setting 'size' to value '512x512'
[Parsed_ebur128_4 @ 022917a3ec20] Setting 'video' to value '1'
[Parsed_ebur128_4 @ 022917a3ec20] EBU +9 scale
[Parsed_scale_5 @ 022917a3e820] Setting 'w' to value '1536'
[Parsed_scale_5 @ 022917a3e820] Setting 'h' to value '512'
[Parsed_scale_5 @ 022917a3e820] w:1536 h:512 flags:'bilinear' interl:0
[graph_0_in_0_0 @ 022917a3f2a0] Setting 'time_base' to value '1/44100'
[graph_0_in_0_0 @ 022917a3f2a0] Setting 'sample_rate' to value '44100'
[graph_0_in_0_0 @ 022917a3f2a0] Setting 'sample_fmt' to value 's16p'
[graph_0_in_0_0 @ 022917a3f2a0] Setting 'channel_layout' to value '0x3'
[graph_0_in_0_0 @ 022917a3f2a0] tb:1/44100 samplefmt:s16p
samplerate:44100 chlayout:0x3
[Parsed_avectorscope_1 @ 022917a3e9c0] auto-inserting filter
'auto_resampler_0' between the filter 'Parsed_asplit_0' and the filter
'Parsed_avectorscope_1'
[Parsed_showfreqs_2 @ 022917a3e740] auto-inserting filter
'auto_resampler_1' between the filter 'Parsed_asplit_0' and the filter
'Parsed_showfreqs_2'
[Parsed_ebur128_4 @ 022917a3ec20] auto-inserting filter
'auto_resampler_2' between the filter 'Parsed_asplit_0' and the filter
'Parsed_ebur128_4'
[AVFilterGraph @ 022917a3d540] query_formats: 10 queried, 12
merged, 9 already done, 0 delayed
[auto_resampler_0 @ 022917a3e8e0] picking s16 out of 2 ref:s16p
[auto_resampler_2 @ 022917a3f440] [SWR @ 022917f34f80] Using
fltp internally between filters
[auto_resampler_2 @ 022917a3f440] ch:2 chl:stereo fmt:s16p
r:44100Hz -> ch:2 chl:stereo fmt:dbl r:48000Hz
[auto_resampler_0 @ 022917a3e8e0] [SWR @ 022917a894c0] Using
s16p internally between filters
[auto_resampler_0 @ 022917a3e8e0] ch:2 chl:stereo fmt:s16p
r:44100Hz -> ch:2 chl:stereo fmt:s16 r:44100Hz
[auto_resampler_1 @ 022917a3ea80] [SWR @ 022917f1ffc0] Using
s16p internally between filters
[auto_resampler_1 @ 022917a3ea80] ch:2 chl:stereo fmt:s16p
r:44100Hz -> ch:2 chl:stereo fmt:fltp r:44100Hz
[Parsed_hstack_3 @ 022917a3f1e0] [framesync @ 022917a2e608]
Selected 1/44100 time base
[Parsed_hstack_3 @ 022917a3f1e0] [framesync @ 022917a2e608] Sync level 1
[swscaler @ 022918081100] Forcing full internal H chroma due to
input having non subsampled chroma
[Parsed_scale_5 @ 022917a3e820] w:640 h:480 fmt:rgb24 sar:1/1 ->
w:1536 h:512 fmt:rgba sar:4/9 flags:0x2
[Parsed_vstack_6 @ 022917a3ed00] [framesync @ 0229177dd5c8]
Selected 1/100 time base
[Parsed_vstack_6 @ 022917a3ed00] [framesync @ 0229177dd5c8] Sync level 1
[sdl,sdl2 @ 022917a4df40] w:1536 h:1024 fmt:rgba -> w:1536 

Re: [FFmpeg-devel] [PATCHv2 1/2] avdevice/decklink_dec: add support for decoding teletext from 10bit ancillary data

[John Warburton]

On Tue, Jul 18, 2017 at 6:10 PM, Marton Balint <c...@passwd.hu> wrote:
> On Sat, 8 Jul 2017, Marton Balint wrote:
>
>> This also add supports for 4K DeckLink cards because they always output the
>> ancillary data in 10-bit.
>>
>> v2:
>> - only try teletext decoding for 576i PAL mode
>> - some comments as requested by Aaron Levinson
>>
>> Signed-off-by: Marton Balint <c...@passwd.hu>
>
> Applied the series, thanks for all the comments.

Since this patch was applied, the mingw-w64 compiler, gcc version
6.4.1, fails to link shared library avdevice-57.dll, giving the
following error. It is as if the const uint8_t ff_reverse[256] that is
found in libavutil/reverse.c somehow isn't being discovered by the
linker. I'm afraid my knowledge beyond this point is zero.

libavdevice/decklink_dec.o:decklink_dec.cpp:(.rdata$.refptr.ff_reverse[.refptr.ff_reverse]+0x0):
undefined reference to `ff_reverse'
collect2: error: ld returned 1 exit status
ffbuild/library.mak:101: recipe for target 'libavdevice/avdevice-57.dll' failed
make: *** [libavdevice/avdevice-57.dll] Error 1
Build failure. Please see error messages above.

Kind regards,
John Warburton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Patch: filter af_amix inputs

[John Warburton]

On Fri, Apr 7, 2017 at 10:25 AM, Michael Niedermayer
<mich...@niedermayer.cc> wrote:
>
> this patch is corrupted by linebreaks

I'm sorry about that. It's attached to this email, from a file made by
git format-patch.
J
--
John Warburton
Tonmeister, Director,
Associate Lecturer, University of Surrey Department of Music and Media


0001-libavfilter-af_amix.c-Increase-sources-from-32-to-10.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Patch: filter af_amix inputs

[John Warburton]

Dear All,

While needing automatically to mix several hundred audio files, I
noticed that the libavfilter module af_amix.c (audio filter 'amix') is
hard-coded to limit inputs to 32. Of course, I believe this to be
sensible as no doubt you do, too.

However, because the code appears to be written robustly, it was
trivial to increase the limit to 1024 and, on a fast machine with SATA
drives, I have used FFmpeg to mix simultaneously over 400 16-bit
stereo wav files (48kHz sample rate) at approximately 2 x realtime. It
starts very slowly, but speed soon builds up.

Naturally, memory use increased. But the job was done. It's generating
files for a sound installation in an art exhibition in Brighton, UK,
where many hundreds of migrant birds' songs must be heard together
("SWAY" at the ONCA Gallery).

Below is the very trivial patch in case the result of this experiment
is of interest.

Thank you for all the work you do to make FFmpeg so incredibly useful.
J

--- libavfilter/af_amix.c.orig 2017-04-05 22:26:26.326379600 +0100
+++ libavfilter/af_amix.c 2017-04-05 18:00:59.291196000 +0100
@@ -177,7 +177,7 @@
 #define F AV_OPT_FLAG_FILTERING_PARAM
 static const AVOption amix_options[] = {
 { "inputs", "Number of inputs.",
-OFFSET(nb_inputs), AV_OPT_TYPE_INT, { .i64 = 2 }, 1, 32, A|F },
+OFFSET(nb_inputs), AV_OPT_TYPE_INT, { .i64 = 2 }, 1, 1024, A|F },
 { "duration", "How to determine the end-of-stream.",
 OFFSET(duration_mode), AV_OPT_TYPE_INT, { .i64 =
DURATION_LONGEST }, 0,  2, A|F, "duration" },
 { "longest",  "Duration of longest input.",  0,
AV_OPT_TYPE_CONST, { .i64 = DURATION_LONGEST  }, INT_MIN, INT_MAX,
A|F, "duration" },





--
John Warburton
Tonmeister, Director,
Associate Lecturer, University of Surrey Department of Music and Media
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi/af_ebur128: update filter to use new ebur128 API

[John Warburton]

On Thu, Nov 17, 2016 at 5:04 PM, Kyle Swanson  wrote:

> Hi,
>
> Here's a couple of patches which update the ebur128 filter to use the
> recently added ebur128 API. This updated filter allows fine-tuned
> control over which EBU R128 parameters are measured, and provides
> modest speed increases over the previous ebur128 filter. Also
> noteworthy: this removes the video output option of the ebur128
> filter.
> ​...
>

​I also would prefer that the video output not be removed unless similar
functionality replaces it without a break. It happens to be a feature I use
in a script that enables us to quickly check incoming files in our
facility​.

Nevertheless, we are grateful for all that the FFmpeg developers do to
maintain this software.
J
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] order T-shirts

[John Warburton]

On Sun, Sep 4, 2016 at 10:34 PM, Thomas Volkert  wrote:

> Hi,
>
> Some guys at the VDD asked for FFmpeg T-shirts.
> I'd like to do a new T-shirt order. The shirts could be given to
> multimedia devs who stop at one of our next booths.
>
> ​I'd *buy* one. XL. Wear it at the lectures I give.​

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

Re: [FFmpeg-devel] [PATCH] lavc/hevc_parse: Don't take a HEVCContext

[John Warburton]

Is it possible that this patch, particularly to libavcodec/hevc.h, is
causing my compilation error today, cross-compiling using mingw-w64
and gcc-5.3.0 from GNU/Linux to Windows 64-bit?

libavcodec/qsvenc_hevc.c: In function 'generate_fake_vps':
libavcodec/qsvenc_hevc.c:71:38: warning: passing argument 2 of
'ff_hevc_extract_rbsp' makes integer from pointer without a cast
[-Wint-conversion]
 ret = ff_hevc_extract_rbsp(NULL, avctx->extradata + 4,
avctx->extradata_size - 4, _nal);
  ^
In file included from libavcodec/qsvenc_hevc.c:33:0:
libavcodec/hevc.h:1083:5: note: expected 'int' but argument is of type
'uint8_t * {aka unsigned char *}'
 int ff_hevc_extract_rbsp(const uint8_t *src, int length,
 ^
libavcodec/qsvenc_hevc.c:71:60: warning: passing argument 3 of
'ff_hevc_extract_rbsp' makes pointer from integer without a cast
[-Wint-conversion]
 ret = ff_hevc_extract_rbsp(NULL, avctx->extradata + 4,
avctx->extradata_size - 4, _nal);
^
In file included from libavcodec/qsvenc_hevc.c:33:0:
libavcodec/hevc.h:1083:5: note: expected 'HEVCNAL * {aka struct
HEVCNAL *}' but argument is of type 'int'
 int ff_hevc_extract_rbsp(const uint8_t *src, int length,
 ^
libavcodec/qsvenc_hevc.c:71:11: error: too many arguments to function
'ff_hevc_extract_rbsp'
 ret = ff_hevc_extract_rbsp(NULL, avctx->extradata + 4,
avctx->extradata_size - 4, _nal);
   ^
In file included from libavcodec/qsvenc_hevc.c:33:0:
libavcodec/hevc.h:1083:5: note: declared here
 int ff_hevc_extract_rbsp(const uint8_t *src, int length,
 ^
common.mak:60: recipe for target 'libavcodec/qsvenc_hevc.o' failed
make: *** [libavcodec/qsvenc_hevc.o] Error 1
Build failure. Please see error messages above.

On Mon, Apr 25, 2016 at 5:27 PM, Michael Niedermayer
 wrote:
> On Mon, Apr 25, 2016 at 02:41:33PM +0100, Derek Buitenhuis wrote:
>>
>>  libavcodec/hevc.c|  2 +-
>>  libavcodec/hevc.h|  4 ++--
>>  libavcodec/hevc_parse.c  | 11 +--
>>  libavcodec/hevc_parser.c |  2 +-
>>  4 files changed, 9 insertions(+), 10 deletions(-)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Avid DNxHR / UK DPP

[John Warburton]

On 25 Jan 2016 23:04, "Kieran Kunhya"  wrote:
>
> If they are considering VC-5 (Cineform) basically point them to this:
>
https://medium.com/@kierank_/reverse-engineering-the-gopro-cineform-codec-7411312bfe1c
>
> tl;dr The VC-5 document isn't enough to implement things in the
> real-world (like many useless SMPTE documents).

Thanks for letting me know. I read your reverse-engineering saga. At the
moment, the DPP workflow guidance is codec-agnostic and does not involve
delivery specifications. My influence is probably negligible (and I do not
speak for them at all) but I'll do my best to encourage delivery codecs for
which source code is readily available under an open licence and in FFmpeg
e.g. VC-2.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Avid DNxHR / UK DPP

[John Warburton]

Gentlemen,

I'm at DPP conference, in the room. Start of UHD delivery standards for UK
just announced. Now on website, we are told.

H.264 codec,
AS-11 encapsulation for MXF,
HLG and SMPTE 2084 both supported for HDR,
WCG framework supported,
Long-GOP in H.264. But I-frame only option for post-delivery requirements.

Tests to be done on high frame rate, live delivery and object-based audio.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Avid DNxHR / UK DPP

[John Warburton]

Tomorrow I'm attending an event run by the Digital Production Partnership,
a body that has brought together mainstream digital television delivery and
workflow standards for UK broadcasters. My production company is a member,
and we assisted a little in the development of their UHD workflow document.

If you don't already have a line of communication open to them, I'm asking
you if there is anything you would like mentioned to them about UHD codecs
in FFmpeg e.g. DNxHR development and assistance in the process?

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

Re: [FFmpeg-devel] [PATCH 0/4] more accurate constants

[John Warburton]

On Fri, Nov 13, 2015 at 4:42 PM, Ganesh Ajjanagadde
 wrote:
>
> 4/4 is a "best effort" patch that maximizes accuracy on all platforms for
> avcodec/faandct. It results in concrete accuracy benefits on the "default" 
> x86-64
> GNU/Linux platform.
>
> Patches tested with FATE. ppc untested.

Sorry to say the libavcodec/faandct.c patch prevents compilation on a
ppc using GCC 5.2.0. In all cases (the first of which are given
below), the GCC "note" states:

"in expansion of macro 'Bn'"

...where n is the digit following B

libavcodec/faandct.c:39:12: error: initializer element is not constant
 #define B1 0.720959822006947913789091890943021267L // (cos(pi*1/16)sqrt(2))^-1
...
libavcodec/faandct.c:40:12: error: initializer element is not constant
 #define B2 0.765366864730179543456919968060797734L // (cos(pi*2/16)sqrt(2))^-1
...
libavcodec/faandct.c:41:12: error: initializer element is not constant
 #define B3 0.850430094767256448766702844371412325L // (cos(pi*3/16)sqrt(2))^-1
...
libavcodec/faandct.c:43:12: error: initializer element is not constant
 #define B5 1.272758580572833938461007018281767032L // (cos(pi*5/16)sqrt(2))^-1
...
libavcodec/faandct.c:44:12: error: initializer element is not constant
 #define B6 1.847759065022573512256366378793576574L // (cos(pi*6/16)sqrt(2))^-1
...
libavcodec/faandct.c:45:12: error: initializer element is not constant
 #define B7 3.624509785411551372409941227504289587L // (cos(pi*7/16)sqrt(2))^-1
...
kind regards,
John
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/4] more accurate constants

[John Warburton]

On Thu, Nov 26, 2015 at 1:26 PM, Ganesh Ajjanagadde  wrote:

>> Does removing the L fix it?

> Read up a bit and suspect it should, and more generally long double is
> a can of worms on ppc with bugs on some compilers:
> https://gcc.gnu.org/wiki/Ieee128PowerPC, ABI in transition,
> https://llvm.org/bugs/show_bug.cgi?id=11933 etc etc. Well known
> projects have gone through pain:
> https://github.com/numpy/numpy/issues/2001.

Thank you for looking into this. I removed the 'L' at the end of each
written-out constant, and the code compiles on PPC.

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

Re: [FFmpeg-devel] [PATCH] lavf/avisynth: fix compilation, remove bundled headers

[John Warburton]

On Wed, Mar 25, 2015 at 7:50 PM, Michael Niedermayer michae...@gmx.at wrote:
 On Wed, Mar 25, 2015 at 01:59:18PM -0400, Stephen Hutchinson wrote:
 On Wed, Mar 25, 2015 at 12:49 PM, Michael Niedermayer michae...@gmx.at 
 wrote:
  ive applied patch 4 from the patchset too, does that fix it ?

 applied the patches

Thank you for updating these headers. FFmpeg now cross-compiles for a
Win64 target under Mingw-w64 (in Cygwin) with one warning:

CC  libavformat/avisynth.o
In file included from libavformat/avisynth.c:33:0:
./compat/avisynth/avisynth_c.h:788:27: warning: function declaration
isn't a prototype [-Wstrict-prototypes]
 AVSC_INLINE AVS_Library * avs_load_library() {
   ^

I'll test it with a real AviSynth+ 64-bit installation later today.
J
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/avisynth: fix compilation, remove bundled headers

[John Warburton]

 On Wed, Mar 25, 2015 at 7:50 PM, Michael Niedermayer michae...@gmx.at wrote:
 On Wed, Mar 25, 2015 at 01:59:18PM -0400, Stephen Hutchinson wrote:
 On Wed, Mar 25, 2015 at 12:49 PM, Michael Niedermayer michae...@gmx.at 
 wrote:
  ive applied patch 4 from the patchset too, does that fix it ?

 applied the patches

Unfortunately, although FFmpeg compiles successfully, a simple
AviSynth+ script that works perfectly in the 64-bit version of MPC-HC
will not work in today's FFmpeg build. The error is unknown error
occurred. If there are additional ways of debugging the interface
between avisynth+ and ffmpeg, I'd be glad to try them.

 ffmpeg -v debug -i test.avs test.mp4
ffmpeg version N-71096-g2139e58-COMPILED_BY_JohnWarburton Copyright
(c) 2000-2015 the FFmpeg developers
  built with gcc 4.9.2 (GCC)
  libavutil  54. 20.101 / 54. 20.101
  libavcodec 56. 30.100 / 56. 30.100
  libavformat56. 26.101 / 56. 26.101
  libavdevice56.  4.100 / 56.  4.100
  libavfilter 5. 13.101 /  5. 13.101
  libswscale  3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
  libpostproc53.  3.100 / 53.  3.100
Splitting the commandline.
Reading option '-v' ... matched as option 'v' (set logging level) with
argument 'debug'.
Reading option '-i' ... matched as input file with argument 'test.avs'.
Reading option 'test.mp4' ... matched as output file.
Finished splitting the commandline.
Parsing a group of options: global .
Applying option v (set logging level) with argument debug.
Successfully parsed a group of options.
Parsing a group of options: input file test.avs.
Successfully parsed a group of options.
Opening an input file: test.avs.
[avisynth @ 044c7be0] Format avisynth probed with size=2048 and score=50
[AVIOContext @ 044d0d80] Statistics: 450 bytes read, 0 seeks
test.avs: Unknown error occurred

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

Re: [FFmpeg-devel] [PATCH 2/4] avisynth: drop support of AviSynth 2.5

[John Warburton]

On Tue, Mar 24, 2015 at 7:33 PM, Hendrik Leppkes h.lepp...@gmail.com wrote:

 On Tue, Mar 24, 2015 at 8:23 PM, Stephen Hutchinson qyo...@gmail.com wrote:
  If the user attempts to use AviSynth 2.5, an error message will
  now tell them they need to upgrade.

Just had avisynth.c fail to compile from a clean tree, whereas
yesterday's compile was fine.

Complete error report is below. I'm certainly not a code expert but is
avisynth.c not finding what it would like to refer to in avisynth_c.h?

CC  libavformat/avisynth.o
In file included from libavformat/avisynth.c:33:0:
./compat/avisynth/avisynth_c.h:806:27: warning: function declaration
isn't a prototype [-Wstrict-prototypes]
 AVSC_INLINE AVS_Library * avs_load_library() {
   ^
libavformat/avisynth.c:69:23: error: unknown type name 'avs_bits_per_pixel_func'
 AVSC_DECLARE_FUNC(avs_bits_per_pixel);
   ^
libavformat/avisynth.c:53:33: note: in definition of macro 'AVSC_DECLARE_FUNC'
 #define AVSC_DECLARE_FUNC(name) name ## _func name
 ^
libavformat/avisynth.c:70:23: error: unknown type name 'avs_get_height_p_func'
 AVSC_DECLARE_FUNC(avs_get_height_p);
   ^
libavformat/avisynth.c:53:33: note: in definition of macro 'AVSC_DECLARE_FUNC'
 #define AVSC_DECLARE_FUNC(name) name ## _func name
 ^
libavformat/avisynth.c:71:23: error: unknown type name 'avs_get_pitch_p_func'
 AVSC_DECLARE_FUNC(avs_get_pitch_p);
   ^
libavformat/avisynth.c:53:33: note: in definition of macro 'AVSC_DECLARE_FUNC'
 #define AVSC_DECLARE_FUNC(name) name ## _func name
 ^
libavformat/avisynth.c:72:23: error: unknown type name 'avs_get_read_ptr_p_func'
 AVSC_DECLARE_FUNC(avs_get_read_ptr_p);
   ^
libavformat/avisynth.c:53:33: note: in definition of macro 'AVSC_DECLARE_FUNC'
 #define AVSC_DECLARE_FUNC(name) name ## _func name
 ^
libavformat/avisynth.c:73:23: error: unknown type name 'avs_get_row_size_p_func'
 AVSC_DECLARE_FUNC(avs_get_row_size_p);
   ^
libavformat/avisynth.c:53:33: note: in definition of macro 'AVSC_DECLARE_FUNC'
 #define AVSC_DECLARE_FUNC(name) name ## _func name
 ^
libavformat/avisynth.c:74:23: error: unknown type name 'avs_is_yv24_func'
 AVSC_DECLARE_FUNC(avs_is_yv24);
   ^
libavformat/avisynth.c:53:33: note: in definition of macro 'AVSC_DECLARE_FUNC'
 #define AVSC_DECLARE_FUNC(name) name ## _func name
 ^
libavformat/avisynth.c:75:23: error: unknown type name 'avs_is_yv16_func'
 AVSC_DECLARE_FUNC(avs_is_yv16);
   ^
libavformat/avisynth.c:53:33: note: in definition of macro 'AVSC_DECLARE_FUNC'
 #define AVSC_DECLARE_FUNC(name) name ## _func name
 ^
libavformat/avisynth.c:76:23: error: unknown type name 'avs_is_yv411_func'
 AVSC_DECLARE_FUNC(avs_is_yv411);
   ^
libavformat/avisynth.c:53:33: note: in definition of macro 'AVSC_DECLARE_FUNC'

libavformat/avisynth.c:77:23: error: unknown type name 'avs_is_y8_func'
 AVSC_DECLARE_FUNC(avs_is_y8);
   ^
libavformat/avisynth.c:53:33: note: in definition of macro 'AVSC_DECLARE_FUNC'
 #define AVSC_DECLARE_FUNC(name) name ## _func name
 ^
libavformat/avisynth.c: In function 'avisynth_load_library':
libavformat/avisynth.c:123:26: warning: assignment makes integer from
pointer without a cast
 avs_library.name = \
  ^
libavformat/avisynth.c:143:5: note: in expansion of macro 'LOAD_AVS_FUNC'
 LOAD_AVS_FUNC(avs_bits_per_pixel, 0);
 ^
libavformat/avisynth.c:123:26: warning: assignment makes integer from
pointer without a cast
 avs_library.name = \
  ^
libavformat/avisynth.c:144:5: note: in expansion of macro 'LOAD_AVS_FUNC'
 LOAD_AVS_FUNC(avs_get_height_p, 0);
 ^
libavformat/avisynth.c:123:26: warning: assignment makes integer from
pointer without a cast
 avs_library.name = \
  ^
libavformat/avisynth.c:145:5: note: in expansion of macro 'LOAD_AVS_FUNC'
 LOAD_AVS_FUNC(avs_get_pitch_p, 0);
 ^
libavformat/avisynth.c:123:26: warning: assignment makes integer from
pointer without a cast
 avs_library.name = \
  ^
libavformat/avisynth.c:146:5: note: in expansion of macro 'LOAD_AVS_FUNC'
 LOAD_AVS_FUNC(avs_get_read_ptr_p, 0);
 ^
libavformat/avisynth.c:123:26: warning: assignment makes integer from
pointer without a cast
 avs_library.name = \
  ^