[FFmpeg-devel] [PATCH] avutil: Add missing reference files for pixdesc fate test

Commit cd48318035 added support for NV24 and NV42, including several fate tests for these formats, but did not include the reference files for the tests filter-pixdesc-nv24 and filter-pixdesc-nv42. As a result, these two tests were broken. Signed-off-by: Andreas Rheinhardt ---

Re: [FFmpeg-devel] [PATCH] avfilter/vf_stack: Don't modify const strings

On 14-05-2019 09:45 AM, Andreas Rheinhardt wrote: b3b7ba62 introduced undefined behaviour: A (non-modifiable) string literal has been assigned to a modifiable string; said string was indeed modified later via av_strtok. This of course caused compiler warnings because of the discarded

[FFmpeg-devel] [PATCH] avfilter/vf_stack: Don't modify const strings

b3b7ba62 introduced undefined behaviour: A (non-modifiable) string literal has been assigned to a modifiable string; said string was indeed modified later via av_strtok. This of course caused compiler warnings because of the discarded qualifier; these are in particular fixed by this commit.

[FFmpeg-devel] [PATCH 1/3] avfilter/vf_scale_cuda: Fix incorrect scaling of > 8bit content

When i converted the filter to use texture objects instead of texture references, I incorrect dropped the `pixel_size` scaling factor when setting `pitchInBytes`. `src_pitch` is in pixels and so must be scaled up. --- libavfilter/vf_scale_cuda.c | 2 +- 1 file changed, 1 insertion(+), 1

[FFmpeg-devel] [PATCH 0/3] avfilter/vf_scale_cuda: Various improvements

After Sergey's bug report, I went and fixed a couple of other things I noticed while I was looking at the filter. Philip Langdale (3): avfilter/vf_scale_cuda: Fix incorrect scaling of > 8bit content avfilter/vf_scale_cuda: Add support for YUV444P16 avfilter/vf_scale_cuda: Simplify output

[FFmpeg-devel] [PATCH 2/3] avfilter/vf_scale_cuda: Add support for YUV444P16

This format is interesting because it's what you get for decoded 10/12bit HEVC 4:4:4. --- libavfilter/vf_scale_cuda.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c index ecfd6a1c92..a833dcd1a4 100644

[FFmpeg-devel] [PATCH 3/3] avfilter/vf_scale_cuda: Simplify output plane addressing

I'm not sure why this was written the way it was originally. We initialise the plane addresses correctly in hwcontext_cuda so why try and play games to calculate the plane offsets directly in this code? --- libavfilter/vf_scale_cuda.c | 22 +++--- 1 file changed, 11 insertions(+),

Re: [FFmpeg-devel] [PATCH] libavfilter/vf_scale_cuda: fix src_pitch for 10bit videos

On Mon, 13 May 2019 11:18:09 + Sergey Svechnikov wrote: > When scaling a 10bit video using scale_cuda filter (witch uses pixel > format AV_PIX_FMT_P010LE), the output video gets distorted. I think > it has something to do with the differences in processing between > cuda_sdk and ffnvcodec

Re: [FFmpeg-devel] [PATCH] libavformat/utils: Interpolate missing timestamps in H264 and HEVC when no b-frames observed.

On Mon, May 13, 2019 at 03:37:24PM -0400, Andriy Gelman wrote: > Hello, > > On Mon, 13. May 12:04, Michael Niedermayer wrote: > > On Sat, May 11, 2019 at 11:20:51PM -0400, Andriy Gelman wrote: > > > From: Andriy Gelman > > > > > > Fixes Ticket #7895. > > > > > > Currently, timestamp

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

Hi Thomas > On May 13, 2019, at 3:11 PM, Thomas Mundt wrote: > > Hi Baptiste, > > Am Fr., 10. Mai 2019 um 17:51 Uhr schrieb Baptiste Coudurier < > baptiste.coudur...@gmail.com>: > >> --- >> libavformat/Makefile | 2 +- >> libavformat/avc.c| 188 ++ >>

[FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

--- libavformat/Makefile | 2 +- libavformat/avc.c| 186 + libavformat/avc.h| 15 +++ libavformat/hevc.c | 36 +--- libavformat/mxf.h| 1 + libavformat/mxfenc.c | 213 ++- 6 files changed, 372

Re: [FFmpeg-devel] How to correctly use init and uninit

Am 19.04.19 um 14:35 schrieb Paul B Mahol: >>> You do not need to use loop filter on single png. >> I need real pictures to prove the correctness of my hacking. The >> smptebars is not appopriate to see errors in the output e.g. from mirroring. >> >>> Use something like this: >>> >>> ffmpeg -f

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

Hi Baptiste, Am Fr., 10. Mai 2019 um 17:51 Uhr schrieb Baptiste Coudurier < baptiste.coudur...@gmail.com>: > --- > libavformat/Makefile | 2 +- > libavformat/avc.c| 188 ++ > libavformat/avc.h| 15 +++ > libavformat/hevc.c | 36 +--- >

Re: [FFmpeg-devel] [PATCH v3 2/2] avcodec/videotoolbox: add support for full range pixel formats

ping, should i do anything else about this second part of the patch? ___ 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

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

On Mon, May 13, 2019 at 10:53 PM Carl Eugen Hoyos wrote: > > > Release branches provide a guarantee of API, ABI and feature > > stability. > > And we sadly did not always hold that guarantee=-( Mistakes have been made. We shall strive to be better in the future, and not use them as an excuse to

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

Am Mo., 13. Mai 2019 um 22:46 Uhr schrieb Hendrik Leppkes : > > On Mon, May 13, 2019 at 10:37 PM Carl Eugen Hoyos wrote: > > > > Am Mo., 13. Mai 2019 um 22:32 Uhr schrieb James Almer : > > > > > > On 5/13/2019 5:23 PM, Carl Eugen Hoyos wrote: > > > > Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

On 5/13/2019 5:36 PM, Carl Eugen Hoyos wrote: > Am Mo., 13. Mai 2019 um 22:32 Uhr schrieb James Almer : >> >> On 5/13/2019 5:23 PM, Carl Eugen Hoyos wrote: >>> Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer : On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote: > Am Mo., 13. Mai 2019

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

On Mon, May 13, 2019 at 10:37 PM Carl Eugen Hoyos wrote: > > Am Mo., 13. Mai 2019 um 22:32 Uhr schrieb James Almer : > > > > On 5/13/2019 5:23 PM, Carl Eugen Hoyos wrote: > > > Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer : > > >> > > >> On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote: > >

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

Am Mo., 13. Mai 2019 um 22:32 Uhr schrieb James Almer : > > On 5/13/2019 5:23 PM, Carl Eugen Hoyos wrote: > > Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer : > >> > >> On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote: > >>> Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint : > > 1)

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

On 5/13/2019 5:23 PM, Carl Eugen Hoyos wrote: > Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer : >> >> On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote: >>> Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint : On Sun, 28 Apr 2019, Marton Balint wrote: > Hi All, >

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer : > > On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote: > > Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint : > >> > >> On Sun, 28 Apr 2019, Marton Balint wrote: > >> > >>> Hi All, > >>> > >>> There has been discussion on the mailing list

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote: > Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint : >> >> On Sun, 28 Apr 2019, Marton Balint wrote: >> >>> Hi All, >>> >>> There has been discussion on the mailing list several times about the >>> inclusion of support for closed source

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint : > > On Sun, 28 Apr 2019, Marton Balint wrote: > > > Hi All, > > > > There has been discussion on the mailing list several times about the > > inclusion of support for closed source components (codecs, formats, > > filters, etc) in the main

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

On Sun, 28 Apr 2019, Marton Balint wrote: Hi All, There has been discussion on the mailing list several times about the inclusion of support for closed source components (codecs, formats, filters, etc) in the main ffmpeg codebase. Also the removal of libNDI happened without general

[FFmpeg-devel] [PATCH] avformat/hcom: Remove unused variables

The variables huffcount, rsrc_size and data_size were all set but not used. Therefore they have been removed. This fixes -Wunused-but-set-variable warnings in GCC. Signed-off-by: Andreas Rheinhardt --- libavformat/hcom.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git

Re: [FFmpeg-devel] [PATCH] libavformat/utils: Interpolate missing timestamps in H264 and HEVC when no b-frames observed.

Hello, On Mon, 13. May 12:04, Michael Niedermayer wrote: > On Sat, May 11, 2019 at 11:20:51PM -0400, Andriy Gelman wrote: > > From: Andriy Gelman > > > > Fixes Ticket #7895. > > > > Currently, timestamp interpolation is disabled by default in H264 and > > HEVC. This creates playback issues

Re: [FFmpeg-devel] [PATCH] libswcale: Fix possible string overflow in test

Am Mo., 13. Mai 2019 um 20:33 Uhr schrieb Adam Richter : > Thanks for reviewing that possible string overflow found by cppcheck > and proposing to try to make a better fix. I'll assume no further > action on my part for this fix is necessary unless anyone tells me > otherwise. See:

Re: [FFmpeg-devel] [PATCH] libswcale: Fix possible string overflow in test

Hi, Michael. Thanks for reviewing that possible string overflow found by cppcheck and proposing to try to make a better fix. I'll assume no further action on my part for this fix is necessary unless anyone tells me otherwise. Adam Adam On Mon, May 13, 2019 at 4:39 AM Michael Niedermayer

[FFmpeg-devel] [PATCH] avcodec/libdav1d: fine tune thread distribution

As suggested by Ronald, don't map auto threads to frame threads only, and instead distribute them between frame and tile more efficiently. Add a new framethreads override option, similar to the tilethreads one. Signed-off-by: James Almer --- libavcodec/libdav1d.c | 16 +---

Re: [FFmpeg-devel] [PATCH] mpeg12enc: Use all Closed Captions side data

Am Mi., 10. Apr. 2019 um 13:26 Uhr schrieb Mathieu Duponchelle : > No problem I don't see an updated patch. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link

Re: [FFmpeg-devel] [PATCH] mpeg12enc: Use all Closed Captions side data

Ping! On 4/19/19 2:46 PM, Mathieu Duponchelle wrote: > Hello ? :) > > On 4/10/19 1:26 PM, Mathieu Duponchelle wrote: >> No problem, note that the added indentation is because a loop >> was added :) >> >> On 4/10/19 1:14 AM, Carl Eugen Hoyos wrote: >>> 2019-03-23 0:22 GMT+01:00, Mathieu

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/cinepak: Check available input against encoded buffer size

sön 2019-05-12 klockan 23:21 +0200 skrev Michael Niedermayer: > Fixes: Timeout (12sec -> 2sec) > Fixes: > 14606/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5738687561728000 > > Found-by: continuous fuzzing process >

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

sön 2019-05-12 klockan 18:03 +0100 skrev Mark Thompson: > On 12/05/2019 14:47, Tomas Härdin wrote: > > fre 2019-05-10 klockan 08:50 -0700 skrev Baptiste Coudurier: > > > ... > > > +skip_bits(, 2); // reserved_zero_2bits > > > +sps->level_idc = get_bits(, 8); > > > +sps->id =

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

On 5/3/19, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > doc/filters.texi | 11 ++ > libavfilter/Makefile | 1 + > libavfilter/allfilters.c | 1 + > libavfilter/vf_xmedian.c | 325 +++ > 4 files changed, 338 insertions(+) >

[FFmpeg-devel] [PATCH] ffplay: added option always on top for video window

From: Daniel Kucera Signed-off-by: Daniel Kucera --- doc/ffplay.texi | 2 ++ fftools/ffplay.c | 8 2 files changed, 10 insertions(+) diff --git a/doc/ffplay.texi b/doc/ffplay.texi index c305465078..a487c0de8d 100644 --- a/doc/ffplay.texi +++ b/doc/ffplay.texi @@ -66,6 +66,8 @@ Set

Re: [FFmpeg-devel] [PATCH] libswcale: Fix possible string overflow in test

On Sun, May 12, 2019 at 05:40:00AM -0700, Adam Richter wrote: > This is a possible fix for a string overflow in some sscanf calls in > libswcale/tests/swscale.c, in the function fileTest(), found by > cppcheck. Please see the attachment for more discussion of this. > > Thanks in advance for

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

On 5/13/19, Carl Eugen Hoyos wrote: > Am Mo., 13. Mai 2019 um 13:31 Uhr schrieb Paul B Mahol : >> >> On 5/13/19, Carl Eugen Hoyos wrote: >> > Am Mo., 13. Mai 2019 um 13:24 Uhr schrieb Lynne : >> > >> >> I'll ignore Carl's messages for now as I agree with the others that >> >> authorship is

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

Am Mo., 13. Mai 2019 um 13:31 Uhr schrieb Paul B Mahol : > > On 5/13/19, Carl Eugen Hoyos wrote: > > Am Mo., 13. Mai 2019 um 13:24 Uhr schrieb Lynne : > > > >> I'll ignore Carl's messages for now as I agree with the others that > >> authorship is always > >> preserved through git history. > > >

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

On 5/13/19, Carl Eugen Hoyos wrote: > Am Mo., 13. Mai 2019 um 13:24 Uhr schrieb Lynne : > >> I'll ignore Carl's messages for now as I agree with the others that >> authorship is always >> preserved through git history. > >> If he disagrees then it becomes a project-wide issue as >> copyright

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

Am Mo., 13. Mai 2019 um 13:24 Uhr schrieb Lynne : > I'll ignore Carl's messages for now as I agree with the others that > authorship is always > preserved through git history. > If he disagrees then it becomes a project-wide issue as > copyright headers have sometimes not been preserved through

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

On 5/13/19, Carl Eugen Hoyos wrote: > Am Mo., 13. Mai 2019 um 13:24 Uhr schrieb Lynne : > >> I'll ignore Carl's messages for now as I agree with the others that >> authorship is always >> preserved through git history. > > This is not the question here. > >> If he disagrees then it becomes a

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

Am Mo., 13. Mai 2019 um 13:24 Uhr schrieb Lynne : > I'll ignore Carl's messages for now as I agree with the others that > authorship is always > preserved through git history. This is not the question here. > If he disagrees then it becomes a project-wide issue as > copyright headers have

[FFmpeg-devel] [PATCH] libavfilter/vf_scale_cuda: fix src_pitch for 10bit videos

When scaling a 10bit video using scale_cuda filter (witch uses pixel format AV_PIX_FMT_P010LE), the output video gets distorted. I think it has something to do with the differences in processing between cuda_sdk and ffnvcodec with cuda_nvcc (the problem appears after this commit

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

May 13, 2019, 9:53 AM by one...@gmail.com: > On 5/13/19, Carl Eugen Hoyos <> ceffm...@gmail.com > > > wrote: > >> Am Mo., 13. Mai 2019 um 00:55 Uhr schrieb James Almer <>> jamr...@gmail.com >> >> >: >> >>> >>> On 5/12/2019 7:42 PM, Carl Eugen

Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window

Am Mo., 13. Mai 2019 um 11:00 Uhr schrieb Daniel Kucera : > +#ifdef SDL_WINDOW_ALWAYS_ON_TOP > +{ "alwaysontop", OPT_BOOL, { }, "window always on top" }, > +#endif You could remove the condition here... > { "volume", OPT_INT | HAS_ARG, { _volume}, "set startup volume > 0=min

Re: [FFmpeg-devel] [PATCH] libavformat/utils: Interpolate missing timestamps in H264 and HEVC when no b-frames observed.

On Sat, May 11, 2019 at 11:20:51PM -0400, Andriy Gelman wrote: > From: Andriy Gelman > > Fixes Ticket #7895. > > Currently, timestamp interpolation is disabled by default in H264 and > HEVC. This creates playback issues when the demuxer does not output a > valid timestamp. This patch allows

Re: [FFmpeg-devel] [PATCH v1] fftools/ffmpeg: Add support for per frame rotation and flip

On Sat, May 11, 2019 at 10:57:01PM -0700, Jun Li wrote: > On Sat, May 11, 2019 at 10:47 PM Jun Li wrote: > > > Fix #6945 > > Current implementaion for autorotate works fine for stream > > level rotataion but no support for frame level operation > > and frame flip. This patch is for adding flip

Re: [FFmpeg-devel] [PATCH 1/2] VP4 video decoder

On Sun, May 12, 2019 at 10:20:19AM -0300, James Almer wrote: > On 5/12/2019 3:12 AM, Peter Ross wrote: > > --- > > i have incorporated all suggestions from the first patch posted jan 2019. > > > > if there's nothing further to change, i will apply it a good week or so. > > > > cheers, > > > >

Re: [FFmpeg-devel] [PATCH 1/2] VP4 video decoder

On Sun, May 12, 2019 at 12:49:03PM +0200, Carl Eugen Hoyos wrote: > Am So., 12. Mai 2019 um 08:12 Uhr schrieb Peter Ross : > > > i have incorporated all suggestions from the first patch posted jan 2019. > > > > if there's nothing further to change, i will apply it a good week or so. > > > >

Re: [FFmpeg-devel] [PATCH 1/2] VP4 video decoder

On Sun, May 12, 2019 at 09:41:40AM +0200, Paul B Mahol wrote: > On 5/12/19, Peter Ross wrote: > > --- > > i have incorporated all suggestions from the first patch posted jan 2019. > > > > if there's nothing further to change, i will apply it a good week or so. > > > > cheers, > > > > > >

Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window

> > I can at least confirm that 2.0.4, which I have installed on one > machine, doesn't define this in the provided headers, and that ffmpeg > doesn't build against 2.0.4 with this patch. So there should be an > #ifdef SDL_WINDOW_ALWAYS_ON_TOP guard around this, and possibly around > the options

[FFmpeg-devel] [PATCH] ffplay: added option always on top for video window

From: Daniel Kucera Signed-off-by: Daniel Kucera --- doc/ffplay.texi | 2 ++ fftools/ffplay.c | 8 2 files changed, 10 insertions(+) diff --git a/doc/ffplay.texi b/doc/ffplay.texi index c305465078..a487c0de8d 100644 --- a/doc/ffplay.texi +++ b/doc/ffplay.texi @@ -66,6 +66,8 @@ Set

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

On 5/13/19, Carl Eugen Hoyos wrote: > Am Mo., 13. Mai 2019 um 00:55 Uhr schrieb James Almer : >> >> On 5/12/2019 7:42 PM, Carl Eugen Hoyos wrote: >> > Am So., 12. Mai 2019 um 23:58 Uhr schrieb Lynne : >> >> I need *technical* feedback about the API. >> > >> > I understand that. >> >> Then, if you

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

On Mon, May 13, 2019 at 8:57 AM Reimar Döffinger wrote: > > On 13.05.2019, at 04:54, Pedro Arthur wrote: > > > Em dom, 12 de mai de 2019 às 18:11, Hendrik Leppkes > > escreveu: > >> > >> On Sun, May 12, 2019 at 11:05 PM Carl Eugen Hoyos > >> wrote: > >>> > >>> But seriously: We are of course

Re: [FFmpeg-devel] [PATCH] "assert(a && b)" --> "assert(a); assert(b)" for more precise diagnostics, except for libformat

On Sun, May 12, 2019 at 08:24:11AM -0700, Adam Richter wrote: > This patch separates statements of the form "assert(a && b);" into > "assert(a);" and "assert(b);", typically involving an assertion > function like av_assert0. > > This patch covers all of ffmpeg, except for the libavformat, which I

Re: [FFmpeg-devel] [PATCH] libavformat: Separate assertions of the form "av_assertN(a && b)" to "av_assertN(a); av_assertN(b)" for more precise diagnostics.

On Sun, May 12, 2019 at 05:49:00AM -0700, Adam Richter wrote: > This is the first of what I expect to be several patches to convert > assertions of the > form "assert(a && b)" to "assert(a); assert(b)". > > Here are some reasons why I think this would be an improvement. This > lengthy argument

Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window

On Mon, May 13, 2019 at 12:54:58 +0530, Gyan wrote: > >> Since 2.0.6 it works on Windows too. > > Ping. > > Michael needs to confirm whether the build failure he had was due to his > SDL version < 2.0.5 I can at least confirm that 2.0.4, which I have installed on one machine, doesn't define this

Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window

On 13-05-2019 12:49 PM, Daniel Kučera wrote: Is qualified as 'X11 only, >= SDL 2.0.5' at https://wiki.libsdl.org/SDL_WindowFlags Gyan Since 2.0.6 it works on Windows too. Ping. Michael needs to confirm whether the build failure he had was due to his SDL version < 2.0.5 Gyan

Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window

>> >> Is qualified as 'X11 only, >= SDL 2.0.5' at >> https://wiki.libsdl.org/SDL_WindowFlags >> >> Gyan > > > Since 2.0.6 it works on Windows too. Ping. -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

On 13.05.2019, at 04:54, Pedro Arthur wrote: > Em dom, 12 de mai de 2019 às 18:11, Hendrik Leppkes > escreveu: >> >> On Sun, May 12, 2019 at 11:05 PM Carl Eugen Hoyos wrote: >>> >>> But seriously: We are of course not allowed to remove copyright >>> statements, no matter if we consider them