On 2 July 2017 at 00:29, Matt Oliver wrote:
> On 2 July 2017 at 00:14, Hendrik Leppkes wrote:
>
>> On Sat, Jul 1, 2017 at 3:18 PM, Matt Oliver wrote:
>> > This only enables dlls that are packaged with the application to be
>> > loaded. Due to the limitations of
---
libavformat/os_support.h | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/libavformat/os_support.h b/libavformat/os_support.h
index 6e245a88d8..91220e9716 100644
--- a/libavformat/os_support.h
+++ b/libavformat/os_support.h
@@ -146,18 +146,6 @@ int ff_poll(str
On 12 July 2017 at 20:27, wm4 wrote:
> On Wed, 12 Jul 2017 20:05:08 +1000
> Matt Oliver wrote:
>
> > ---
> > libavformat/os_support.h | 14 +-
> > 1 file changed, 1 insertion(+), 13 deletions(-)
> >
> > diff --git a/libavformat/os_support
On 12 July 2017 at 20:31, wm4 wrote:
> On Sat, 1 Jul 2017 23:18:25 +1000
> Matt Oliver wrote:
>
> > This only enables dlls that are packaged with the application to be
> > loaded. Due to the limitations of WinRT/UWP it is not allowed to load
> > external/system dlls
On 16 July 2017 at 23:01, Henrik Gramner wrote:
> `./configure && make` results in "libavfilter/vf_libvmaf.c:29:21:
> fatal error: libvmaf.h: No such file or directory".
>
> I don't have libvmaf installed, but it configures it as enabled and
> detects it as installed anyway.
Im getting the same
On 17 July 2017 at 01:12, Derek Buitenhuis
wrote:
> On 7/16/2017 3:15 PM, Matt Oliver wrote:
> > Im getting the same error. The patch had an error in it as this line is
> > wrong:
> > +vmaf_filter_deps="libvmaf"
> >
> > It should be:
> > +libvm
ac3dsp.c uses tables from ac3.c
ac3.c uses tables from ac3tab.c
hevc_ps uses tables from hevc_data.c
intrax8.c uses tables from msmpeg4data.c
---
libavcodec/Makefile | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 357fa
MSVC/ICL does not have unistd.h as standard and instead declares read/close
functions in io.h. This is currently handled in some files but not in a
couple. Adding an include for io.h where needed adds the correct
declarations.
0001-msvc-fix-implicitly-declared-read-close.patch
Description: Binary
On 28 September 2014 18:49, Reimar Döffinger
wrote:
> On Sun, Sep 21, 2014 at 10:17:15AM +0100, Reimar Döffinger wrote:
> > Allows 32 bit version of FFmpeg to use up to 4 GB of RAM
> > instead of just 2 GB on Windows if the OS can provide it.
>
> Any other comments?
> Note the documentation for t
>
> Patch welcome. I don't want to add things I can't easily test
Updated patch with additional flags set for msvc/icl aswell. Also set it so
it is only explicitly enabled on 32 bit builds as it is used by default on
64bit anyway.
Tested on both mingw and msvc (and obviously all works fine).
00
>
>
> Only tested with Mingw-w64 v3.
> Can someone test MSVC or ICL? I know the former defines the struct, so the
> configure check should succeed on that one at least.
>
Works fine on both MSVC and ICL (ICL uses the same headers as MSVC so not
normally an issue - I tested anyway though).
This stops headers based on disabled functionality from being installed.
Things like VDA and VDPAU dont work on windows etc. So any attempt to use
these headers will result in compilation errors so best not to install them
to avoid confusion. Also no point having a header for functionality that
was
On 20 October 2014 17:57, Reimar Döffinger wrote:
> On 19.10.2014, at 20:53, Matt Oliver wrote:
> > This stops headers based on disabled functionality from being installed.
> > Things like VDA and VDPAU dont work on windows etc. So any attempt to use
> > these headers will
intmath.h already uses the gcc builtin intrinsics for log2 and ctz. This
patch just adds the equivalent icl and msvc intrinsics. All added
intrinsics have the same function (i.e. with respect to input 0s etc.) as
the existing gcc builtins.
0001-avutil-intmath-enable-builtin-intrinsics-for-icl-and
On 26 October 2014 21:31, Michael Niedermayer wrote:
> On Sun, Oct 26, 2014 at 08:49:07PM +1100, Matt Oliver wrote:
>
> > intmath.h already uses the gcc builtin intrinsics for log2 and ctz. This
>
> > patch just adds the equivalent icl and msvc intrinsics. All added
>
SDL_QueryTexture and SDL_DestroyTexture require that the input texture
pointer be non-null. Debug builds of SDL will correctly check for this
and break program execution. This patch fixes this by checking the
status of the texture pointer.
Signed-off-by: Matt Oliver
---
fftools/ffplay.c | 5
vf_nlmeans and vf_atadenoisedont contain any code on 32bit x86 so dont
build them.
---
libavfilter/x86/Makefile | 4
1 file changed, 4 insertions(+)
diff --git a/libavfilter/x86/Makefile b/libavfilter/x86/Makefile
index e87481bd7a..9a68b9204b 100644
--- a/libavfilter/x86/Makefile
+++ b/lib
Multiple asm files dont contain any valid code when compiled under 32bit
x86 so they should be skipped.
---
libavcodec/x86/Makefile | 8
1 file changed, 8 insertions(+)
diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 118daca333..bafba207ca 100644
--- a/libavcodec/x8
Currently the extra filters provided by mpcodecs require inline asm support
to compile. However these filters all provide non-asm alternatives that can
be used with the correct pre-processor guard.
Based on some recent discussions it appears that some of these filters are
still used but with the r
>
>
> did you post this to mplayer-dev ?
>
No not as yet, thought I would put it up here for feedback first. Also
someone more familiar with mpcodecs in mplayer might know of other places
that could benefit from a similar change.
___
ffmpeg-devel mailing
On 17 November 2014 21:02, Jesse Jiang wrote:
> Hi All,
> I want to move ffmpeg to WinRT platform, like Windows Store and Windows
> Phone. As the GCC cannot compiler to ARM-COFF, so I convert the GNU-style
> assembly codes to ARM-style codes. Also the codes are open-sourced, here
> https://github
Intel compiler xilink will also output the information from the underlying
Microsoft linker. A result is that both the Intel info header and the
Microsoft info header are output. This means that currently the Intel
linker will get detected as the msvc linker incorrectly as configure checks
for the
On 21 November 2014 01:23, Derek Buitenhuis
wrote:
> On 11/20/2014 8:40 AM, Benoit Fouet wrote:
> > LGTM
>
> http://fate.ffmpeg.org/report.cgi?time=20141120142015&slot=i686-windows-icl
>
> - Derek
>
Works fine with lto, but apparently one shouldnt assume the existing code
is correct for the othe
On 21 November 2014 02:28, Matt Oliver wrote:
> On 21 November 2014 01:23, Derek Buitenhuis
> wrote:
>
>> On 11/20/2014 8:40 AM, Benoit Fouet wrote:
>> > LGTM
>>
>>
>> http://fate.ffmpeg.org/report.cgi?time=20141120142015&slot=i686-windows-icl
The recently added apngdec code does not compile under msvc.
See:
http://fate.ffmpeg.org/report.cgi?time=20141122053145&slot=x86_32-msvc12-windows-native
Attached is a patch to fix it.
0001-lavf-fix-apngdec-under-msvc.patch
Description: Binary data
__
This fixes an error when using static lzma libs with msvc compiler. Without
it the lzma.h header defaults to forcing dll (shared) linkage which breaks
when using static libs. The fix requires adding a simple define before the
header is included that only affects lzma.h on win32 and only with msvc/i
The patch "lavf: Use wchar functions for filenames on windows for
mkdir/rmdir/rename/unlink" that was recently added has broken msvc/icl
builds. see:
http://fate.ffmpeg.org/report.cgi?time=20141126233318&slot=x86_32-msvc12-windows-native
This is because winsock2.h must be included before windows.h
On 1 January 2015 at 07:51, wm4 wrote:
> On Wed, 31 Dec 2014 19:32:23 +0100
> Jean-Baptiste Kempf wrote:
>
> > On 31 Dec, wm4 wrote :
> > > On Wed, 31 Dec 2014 14:11:20 +0100
> > > Clément Bœsch wrote:
> > >
> > > > On Wed, Dec 31, 2014 at 12:14:03PM +, Carl Eugen Hoyos wrote:
> > > > > Nic
On 10 January 2015 at 21:18, Derek Buitenhuis
wrote:
> On 1/10/2015 8:40 AM, Timotius Margo wrote:
> > This causes a problem with autoconf and prevents
> > user from building FFmpeg successfully without applying a workaround.
>
> I forgot to mention this is fixed in newer make.exe's, and I think
This uses the appropriate libvpx accessor function for accessing the codec
interface correctly on any platform which correct link errors on windows.
Reasoning is that the default libvpx msvc build uses module definitions to
export data. Data exports in msvc like this are actually exported as
pointe
On 30 September 2015 at 02:48, wm4 wrote:
> On Wed, 23 Sep 2015 12:04:43 -0600
> Roger Pack wrote:
>
> > From 6a972dda58bd5ab31524cd4e5326b4bcdeaeaa8c Mon Sep 17 00:00:00 2001
> > From: rogerdpack
> > Date: Wed, 23 Sep 2015 12:03:27 -0600
> > Subject: [PATCH] gdigrab: grab right desktop size if
On 3 October 2015 at 21:05, Ronald S. Bultje wrote:
> ---
> libavcodec/x86/Makefile | 1 +
> libavcodec/x86/constants.c | 4 +
> libavcodec/x86/constants.h | 2 +
> libavcodec/x86/h264_idct_10bit.asm | 5 +-
> libavcodec/x86/
On 5 October 2015 at 19:29, Matt Oliver wrote:
> On 30 September 2015 at 02:48, wm4 wrote:
>
>> On Wed, 23 Sep 2015 12:04:43 -0600
>> Roger Pack wrote:
>>
>> > From 6a972dda58bd5ab31524cd4e5326b4bcdeaeaa8c Mon Sep 17 00:00:00 2001
>> > From: rogerd
On 6 October 2015 at 07:51, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Oct 5, 2015 at 7:39 AM, Ronald S. Bultje
> wrote:
>
> > Hi,
> >
> > On Mon, Oct 5, 2015 at 5:54 AM, Henrik Gramner
> wrote:
> >
> >> On Mon, Oct 5, 2015 at 10:55 AM, Matt O
On 2 October 2015 at 05:14, Hendrik Leppkes wrote:
> On Thu, Oct 1, 2015 at 9:05 PM, wm4 wrote:
> > On Fri, 2 Oct 2015 02:58:52 +0800
> > Wang Bin wrote:
> >
> >> From b8b5ad2d6510778111c2a03ae5cfbe727ee6 Mon Sep 17 00:00:00 2001
> >> From: wang-bin
> >> Date: Tue, 29 Sep 2015 18:11:03 +08
On 8 October 2015 at 02:39, Derek Buitenhuis
wrote:
> This makes the h.264 decoder threadsafe to initialize.
>
> Signed-off-by: Derek Buitenhuis
> ---
> libavcodec/h264.c | 7 ++-
> libavcodec/h264.h | 10 ++
> 2 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/libav
On 6 October 2015 at 21:36, Hendrik Leppkes wrote:
> The emulation uses native InitOnce* APIs on Windows Vista+, and a
> lock-free/allocation-free approach using atomics and spinning for Windows
> XP.
> ---
>
> This is in preparation to use pthread_once for global static init
> functions,
> and e
On 8 October 2015 at 03:29, Hendrik Leppkes wrote:
> On Wed, Oct 7, 2015 at 6:23 PM, Matt Oliver wrote:
> > On 6 October 2015 at 21:36, Hendrik Leppkes wrote:
> >
> >> The emulation uses native InitOnce* APIs on Windows Vista+, and a
> >> lock-free/allocatio
On 8 October 2015 at 04:15, Hendrik Leppkes wrote:
> On Wed, Oct 7, 2015 at 7:06 PM, Matt Oliver wrote:
> > On 8 October 2015 at 03:29, Hendrik Leppkes wrote:
> >
> >> On Wed, Oct 7, 2015 at 6:23 PM, Matt Oliver
> wrote:
> >> > On 6 October
On 14 October 2015 at 09:46, Ganesh Ajjanagadde wrote:
> On Tue, Oct 13, 2015 at 9:12 AM, Ganesh Ajjanagadde
> wrote:
> > On Tue, Oct 13, 2015 at 4:02 AM, Clément Bœsch wrote:
> >> On Tue, Oct 13, 2015 at 09:25:03AM +0200, Paul B Mahol wrote:
> >> [...]
> >>> What about fmax/FFMAX?
> >>
> >> Fe
On 15 October 2015 at 07:35, Michael Niedermayer
wrote:
> On Thu, Oct 15, 2015 at 02:46:21AM +0800, Wang Bin wrote:
> >
>
> > compat/w32pthreads.h |5 +
> > configure|7 +++
> > libavutil/cpu.c |8 +++-
> > 3 files changed, 19 insertions(+), 1 deletion(-)
Some of the existing msvc/icl optimised versions for ctz and log2 use
intrinsics that are only usable on x86 systems. This patch moves them from
intmath.h to x86/intmath.h. This is technically where such functions should
go but this will also fix any issues with trying to use msvc to compile arm
co
This patch just adds the msvc and icl equivalent ctzll optimisations to
correspond with the recently added gcc variant
0001-lavu-intmath.h-Add-msvc-icl-ctzll-optimisations.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.
On 16 October 2015 at 03:47, James Almer wrote:
> On 10/15/2015 11:07 AM, Matt Oliver wrote:
> > This patch just adds the msvc and icl equivalent ctzll optimisations to
> > correspond with the recently added gcc variant
> >
> >
> > 0001-lavu-intmath.h-Add-m
On 16 October 2015 at 01:10, Matt Oliver wrote:
> Some of the existing msvc/icl optimised versions for ctz and log2 use
> intrinsics that are only usable on x86 systems. This patch moves them from
> intmath.h to x86/intmath.h. This is technically where such functions should
> go b
On 16 October 2015 at 09:46, James Almer wrote:
> On 10/15/2015 7:25 PM, Matt Oliver wrote:
> > ICC defines __GNUC__ but ICL does not! ICC (being the linux variant)
> > supports all the same functions as gcc so theres no need in this case for
> > special handling. However IC
On 16 October 2015 at 12:25, Matt Oliver wrote:
> On 16 October 2015 at 09:46, James Almer wrote:
>
>> On 10/15/2015 7:25 PM, Matt Oliver wrote:
>> > ICC defines __GNUC__ but ICL does not! ICC (being the linux variant)
>> > supports all the same functions as gcc
On 16 October 2015 at 16:13, James Almer wrote:
> On 10/15/2015 10:26 PM, Matt Oliver wrote:
> > On 16 October 2015 at 01:10, Matt Oliver wrote:
> >
> >> > Some of the existing msvc/icl optimised versions for ctz and log2 use
> >> > intrinsics that are
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: Ja
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
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 26 October 2015 at 04:46, James Almer wrote:
> On 10/25/2015 1:39 PM, Matt Oliver wrote:
> > On 26 October 2015 at 00:43, Hendrik Leppkes
> wrote:
> >
> >> On Sun, Oct 25, 2015 at 12:30 PM, Matt Oliver
> >> wrote:
> >>> On 25 Oc
On 5 October 2015 at 20:05, Matt Oliver wrote:
> On 5 October 2015 at 19:29, Matt Oliver wrote:
>
>> On 30 September 2015 at 02:48, wm4 wrote:
>>
>>> On Wed, 23 Sep 2015 12:04:43 -0600
>>> Roger Pack wrote:
>>>
>>> > From 6a972dda
The existing bswap code causes incorrect code generation with icl which was
breaking fate (apparently we dont have a dedicated icl fate client
anymore). This patch adds in msvc intrinsics for bswap operations which
aids both msvc and icl (although msvc previously generated correct code the
intrinsi
It would appear that ICC 12.0.4 doesnt have a definition of the tzcnt
intrinsics which brakes compilation. Current FATE tests show that atleast
version 12.1.6 has the required intrinsic however im not certain at what
version number it was introduced (I could not find any relevant info in the
intel
On 17 November 2015 at 12:12, Hans Wennborg wrote:
> Hello ffmpeg developers,
>
> This commit [1] is causing problems when compiling with Clang on Windows:
>
> ..\..\third_party\ffmpeg\libavutil/x86/intmath.h(53,33) : error:
> always_inline function '__tzcnt_u32' requires target feature 'bmi',
>
On 15 November 2015 at 01:09, Ricardo Constantino wrote:
> Enables RTMP(T)E support with SChannel
>
> (Not sure if this is the right way to enable this)
>
> Signed-off-by: Ricardo Constantino
> ---
> configure | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/configu
On 19 November 2015 at 00:42, Ricardo Constantino wrote:
> I previously had an option for gcrypt too but it seemed to not work
> (FFmpeg crashed, iirc), so I just gave up on it.
>
If ffmpeg crashes when using gcrypt then thats a separate bug not related
to configure. So you should post a bug rep
Adding rtmp(t)e support when not using openssl or librtmp uses either gmp
or gcrypt to implement the required Diffie-Hellmann code. Since this code
can be compiled using either gmp or gcrypt a command line option to
enable/disable either of those libs needs to be provided.
Currently configure seem
On 22 November 2015 at 03:48, Ricardo Constantino wrote:
> >+ --enable-gcrypt enable gmp, needed for rtmp(t)e support
> >+ if openssl, librtmp or gmp is not used [no]
>
> Probably meant "enable gcrypt" there?
>
>
Damn, cant believe I missed that one, will updat
configure: Add user options to enable gcrypt/gmp for rtmp(t)e
support.
Signed-off-by: Matt Oliver
---
configure | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/configure b/configure
index 4a28836..fd439ec 100755
--- a/configure
+++ b/configure
@@ -199,6
On 22 November 2015 at 04:20, Matt Oliver wrote:
> On 22 November 2015 at 03:48, Ricardo Constantino
> wrote:
>
>> >+ --enable-gcrypt enable gmp, needed for rtmp(t)e support
>> >+ if openssl, librtmp or gmp is not used [no]
>>
>
> > >>> What is a system library depends on the system.
> > >>> For example, Debian (main) does not even include libcuda or
> > >>> libnvidia-encode, so they certainly cannot be system libraries there.
> > >>
>
Im not sure that Debian not including libcuda is a valid argument for it
not being a
>
>
> I don't mind disabling it by default, if that alleviates some concerns.
>
One caveat to my previous comments is that just like avisynth I think that
nvenc should be disabled by default aswell.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
h
On 11 December 2015 at 04:23, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> On 10.12.2015 17:42, Matt Oliver wrote:
> >>
> >>>>>> What is a system library depends on the system.
> >>>>>> For example, Debian (main) do
>
> When running ffmpeg on Debian (main), where these Nvidia blobs
> are not present and not needed (because nouveau is used as driver),
> no component of the operating system, major or not,
> has been distributed with Nvidia's blobs, so the system library
> exception does not apply.
>
> I'm not su
On 29 December 2015 at 11:51, Ganesh Ajjanagadde
wrote:
> On Mon, Dec 28, 2015 at 8:22 AM, Paul B Mahol wrote:
> > On 12/27/15, Ganesh Ajjanagadde wrote:
> >> Replaces by real arithmetic. Tested the validity of these
> transformations
> >> separately.
> >>
> >> Signed-off-by: Ganesh Ajjanagadde
On 30 December 2015 at 03:15, Ganesh Ajjanagadde wrote:
> On Mon, Dec 28, 2015 at 10:27 PM, Matt Oliver
> wrote:
> > On 29 December 2015 at 11:51, Ganesh Ajjanagadde >
> > wrote:
> >
> >> On Mon, Dec 28, 2015 at 8:22 AM, Paul B Mahol wrote:
> >
within mux itself it
can be used directly without needing a new ref.
Signed-off-by: Matt Oliver
---
libavformat/mux.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index 2da8cf2..cf1fb5c 100644
--- a/libavformat/mux.c
+++
On 24 July 2015 at 17:47, Steve Lhomme wrote:
> On Fri, Jul 24, 2015 at 12:55 AM, Michael Niedermayer
> wrote:
> > On Thu, Jul 23, 2015 at 07:25:44PM +0200, Steve Lhomme wrote:
> >> The -nologo- option is the inverse of -nologo, reenabling printing the
> >> "logo" version header. This is useful
On 12 September 2015 at 19:40, Peter Belkner wrote:
> On 12.09.2015 11:15, Geek.Song wrote:
>
>> diff -u
>
>
LGTM.
I had an identical patch ready to fix the same problem so this one is fine.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://f
On 9 September 2015 at 06:53, Ganesh Ajjanagadde wrote:
> On Tue, Sep 8, 2015 at 4:22 PM, Hendrik Leppkes
> wrote:
> > On Tue, Sep 8, 2015 at 9:17 PM, Ganesh Ajjanagadde
> > wrote:
> >> Previous color support relies on existence of tput.
> >> Unfortunately, tput is not available on windows.
> >
Some functions in the native win32 thread wrappers dont return a value.
Since the pthread functions they are simulating do return a value (aswell
as the equivalent os2 version) this patch updates them accordingly. This
makes the win32 variants more compatible with the pthread functions they
are emu
Allows async to be compiled and used when using native win32/os2 threads
aswell as pthreads.
0002-avformat-async-Allow-compilation-with-native-threads.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org
Allows the decklink device to be used with native win32/os2 threads instead
of just pthreads.
Note: I dont have a decklink device to test this but It just allows the use
of the already tested win32/os2 pthread simulation functions so there
shouldnt be any issues.
__
On 25 September 2015 at 17:58, Matt Oliver wrote:
> Allows the decklink device to be used with native win32/os2 threads
> instead of just pthreads.
>
> Note: I dont have a decklink device to test this but It just allows the
> use of the already tested win32/os2 pthread simulati
On 26 September 2015 at 04:08, Michael Niedermayer wrote:
> On Fri, Sep 25, 2015 at 09:41:59PM +1000, Matt Oliver wrote:
> > On 25 September 2015 at 17:58, Matt Oliver wrote:
> >
> > > Allows the decklink device to be used with native win32/os2 threads
> &
A recent commit has broken msvc compilation.
http://fate.ffmpeg.org/report.cgi?time=20150203090035&slot=x86_32-msvc12-windows-native
Attached is the corresponding fix.
avformat-mpegtsenc-Fix-build-with-msvc.patch
Description: Binary data
___
ffmpeg-dev
On 16 February 2015 at 21:26, Michael Niedermayer wrote:
> On Sun, Feb 08, 2015 at 08:57:52PM +0100, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached patch intends to fix compilation with msvc
> > when the vfwcap input device is disabled.
> > Tested by Bernhard Döbler
> >
> > Please comment, Carl
On 11 April 2015 at 03:05, Michael Niedermayer wrote:
> On Fri, Apr 10, 2015 at 11:48:11PM +1000, Matt Oliver wrote:
> > Recent merge fe25194c5870f21ba10f615f036b64d0c84fca48 broke compilation
> > under windows by changing the inclusion order of winsock.h and windows.h
> >
On 26 April 2015 at 18:01, Hendrik Leppkes wrote:
> On Sun, Apr 26, 2015 at 8:45 AM, Anton Fedchin wrote:
> > Hi,
> >
> > I'm working on porting our project Kodi to DirectX11. We also use ffmpeg
> > and I've implemented patch to ffmpeg dxva related code to work with d3d11
> > video API. It works
g (to keep the old behaviour) but that requires some complex
configure changes.
Signed-off-by: Matt Oliver
---
configure| 8 +++-
libavcodec/libx264.c | 4
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/configure b/configure
index ede8f9777b..b35728aace 10
On Wed, 29 Dec 2021 at 23:37, Michael Niedermayer
wrote:
> On Wed, Dec 29, 2021 at 05:16:25PM +1100, Matt Oliver wrote:
> > Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"
> >
> > Setting X264_API_IMPORTS only affects msvc builds and it breaks
On Fri, 28 Jul 2023 at 20:55, Nicolas George wrote:
> Reimar Döffinger (12023-07-28):
> > I assume the issue is missing symbols during linking?
> > If you really want this, why not create a file that provides dummy
> > symbols for all that are missing, concentrating the #if mess in
> > a single p
From: Matt Oliver
Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"
Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since
From: Matt Oliver
Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"
Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since
From: Matt Oliver
Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"
Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since
From: Matt Oliver
Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"
Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since
From: Matt Oliver
Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"
Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since
From: Matt Oliver
Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"
Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since
On Sun, 15 Jan 2023 at 19:09, Matt Oliver wrote:
> Multiple asm files dont contain any valid code when compiled under 32bit
> x86 so they should be skipped.
>
> ---
> libavcodec/x86/Makefile | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/libavcodec/x
On Sun, 15 Jan 2023 at 19:08, Matt Oliver wrote:
> vf_nlmeans and vf_atadenoisedont contain any code on 32bit x86 so dont
> build them.
>
> ---
> libavfilter/x86/Makefile | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavfilter/x86/Makefile b/libavfil
On Sun, 12 Feb 2023 at 04:00, Nicolas George wrote:
> Hi.
>
> Matt Oliver (12023-01-15):
> > vf_nlmeans and vf_atadenoisedont contain any code on 32bit x86 so dont
> > build them.
>
> Hi
>
> This sentence seems to be missing a few words.
>
>
M
101 - 193 of 193 matches
Mail list logo
