On 28 August 2016 at 19:58, Michael Niedermayer
wrote:
> On Sun, Aug 28, 2016 at 06:50:58PM +1000, Matt Oliver wrote:
> > The dlopen function is modified to prevent loading dll's from the current
> > directory for improved program security for library users. This
The fifo muxer works without pthreads due to the existing pthread wrappers
already available within ffmpeg for other platforms.
---
configure | 1 -
1 file changed, 1 deletion(-)
diff --git a/configure b/configure
index 5c11040..e225b7d 100755
--- a/configure
+++ b/configure
@@ -2834,7 +2834,6 @
The dlopen function is modified to prevent loading dll's from the current
directory for improved program security for library users. This extends
similar functionality from the recently applied SetDllDirectory patch
except that it adds additional security for library users as well (as
opposed to j
On 27 August 2016 at 23:12, Timo Rothenpieler wrote:
> On 8/27/2016 3:07 PM, Thomas Volkert wrote:
> > Hi,
> >
> > On 27.08.2016 14:58, Timo Rothenpieler wrote:
> >> As Nvidia has put the most recent Video Codec SDK behind a double
> >> registration wall, of which one needs manual approval of a l
On 8 August 2016 at 23:27, Hendrik Leppkes wrote:
> ---
> cmdutils.c | 9 +
> cmdutils.h | 5 +
> ffmpeg.c | 2 ++
> ffplay.c | 2 ++
> ffprobe.c | 2 ++
> ffserver.c | 1 +
> 6 files changed, 21 insertions(+)
>
> diff --git a/cmdutils.c b/cmdutils.c
> index 03a4836..6960f8c 100
On 13 June 2016 at 18:29, Benoit Fouet wrote:
> Hi,
>
>
>
> On 13/06/2016 10:21, Clément Bœsch wrote:
>
>> On Mon, Jun 13, 2016 at 05:50:18AM +0200, Matt Oliver wrote:
>>
>>> ffmpeg | branch: master | Matt Oliver | Mon Jun
>>> 6 17:04:39 2016
On 10 June 2016 at 05:30, Michael Niedermayer
wrote:
> On Mon, Jun 06, 2016 at 05:11:34PM +1000, Matt Oliver wrote:
> > ---
> > libavutil/x86/intmath.h | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/libavutil/x86/intmath.h b/libavutil/x86/int
On 6 June 2016 at 19:55, Hendrik Leppkes wrote:
> On Mon, Jun 6, 2016 at 11:34 AM, Matt Oliver wrote:
> > On 6 June 2016 at 19:27, Hendrik Leppkes wrote:
> >
> >> On Mon, Jun 6, 2016 at 9:12 AM, Matt Oliver
> wrote:
> >> > Fixes #819 #5256 #528
On 6 June 2016 at 19:27, Hendrik Leppkes wrote:
> On Mon, Jun 6, 2016 at 9:12 AM, Matt Oliver wrote:
> > Fixes #819 #5256 #5281
> > ---
> > libavformat/file.c | 4
> > libavformat/os_support.h | 24
> > 2 files changed, 28 i
---
libavutil/x86/intmath.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
index f58b0d0..de177dd 100644
--- a/libavutil/x86/intmath.h
+++ b/libavutil/x86/intmath.h
@@ -47,6 +47,7 @@ static av_always_inline av_const int ff_log2_x86(unsigned
Fixes #819 #5256 #5281
---
libavformat/file.c | 4
libavformat/os_support.h | 24
2 files changed, 28 insertions(+)
diff --git a/libavformat/file.c b/libavformat/file.c
index 5765ce7..264542a 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -148,7 +
On 26 April 2016 at 01:49, Carl Eugen Hoyos wrote:
> Matt Oliver gmail.com> writes:
>
> > Even so icl does also suffer from issues when using lto
> > with optimised builds aswell so its not just limited to
> > debug builds.
>
> Can you confirm that this is Windo
On 25 April 2016 at 20:42, Michael Niedermayer
wrote:
> On Mon, Apr 25, 2016 at 06:17:22PM +1000, Matt Oliver wrote:
> > On 23 April 2016 at 23:46, wm4 wrote:
> >
> > > On Sat, 23 Apr 2016 14:52:12 +0200
> > > Reimar Döffinger wrote:
> > >
&
On 23 April 2016 at 23:46, wm4 wrote:
> On Sat, 23 Apr 2016 14:52:12 +0200
> Reimar Döffinger wrote:
>
> > On 23.04.2016, at 13:21, wm4 wrote:
> >
> > > On Sat, 23 Apr 2016 01:16:31 +0200
> > > Hendrik Leppkes wrote:
> > >
> > >> On Sat, Apr 23, 2016 at 1:02 AM, Bruce Dawson
> > >> wrote:
> >
>
> +enabled coreimage_filter && { check_header_objcc QuartzCore/CoreImage.h
> || disable coreimage_filter; }
> +enabled coreimagesrc_filter && { check_header_objcc
> QuartzCore/CoreImage.h || disable coreimagesrc_filter; }
>
Wouldnt it be simpler to just add an item to HEADERS_LIST for
QuartzCor
On 16 March 2016 at 23:10, Hendrik Leppkes wrote:
> On Wed, Mar 16, 2016 at 1:04 PM, wm4 wrote:
> > On Wed, 16 Mar 2016 22:55:09 +1100
> > Matt Oliver wrote:
> >
> >> On 16 March 2016 at 22:32, Clément Bœsch wrote:
> >>
> >> > On Wed,
On 16 March 2016 at 23:04, wm4 wrote:
> On Wed, 16 Mar 2016 22:55:09 +1100
> Matt Oliver wrote:
>
> > On 16 March 2016 at 22:32, Clément Bœsch wrote:
> >
> > > On Wed, Mar 16, 2016 at 12:31:35PM +0100, Matt Oliver wrote:
> > > > ffmpeg | branch: master
On 16 March 2016 at 22:32, Clément Bœsch wrote:
> On Wed, Mar 16, 2016 at 12:31:35PM +0100, Matt Oliver wrote:
> > ffmpeg | branch: master | Matt Oliver | Wed Mar
> 16 22:28:29 2016 +1100| [109dfed7fc265f3e071854d5e6de5dd7f82ff9fb] |
> committer: Matt Oliver
> >
>
On 25 February 2016 at 13:20, Ganesh Ajjanagadde wrote:
> From: Ganesh Ajjanagadde
>
> These use __builtin_expect, and may be useful for optimizing nearly
> certain branches, to yield size and/or speed improvements.
>
> Note that this is used in the Linux kernel for the same purpose. For
> some
This is a really simple patch as apparently when the cuda hwcontext filter
was added a semicolon was forgotten.
For such simple patches as this is it worth even posting to the mailing
list or just directly applying it straight away?
---
libavfilter/vf_hwupload_cuda.c | 2 +-
1 file changed, 1 in
On 19 February 2016 at 09:20, Gerion Entrup
wrote:
> On Donnerstag, 18. Februar 2016 21:02:09 CET wm4 wrote:
> > On Thu, 18 Feb 2016 20:41:29 +0100
> >
> > Gerion Entrup wrote:
> > > On Donnerstag, 18. Februar 2016 20:10:47 CET wm4 wrote:
> > > > On Thu, 18 Feb 2016 18:27:45 +0100
> > > >
> > >
On 13 February 2016 at 05:33, Γιώργος Μεταξάκης wrote:
> checked with patcheck also.
> only "problem" is
> "Missing changelog entry (ignore if minor change)'
>
LGTM, applied.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailm
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 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:
> >
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
>
> 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 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
>
>
> 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
>
> > >>> 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
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]
>>
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 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
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 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
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 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',
>
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
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
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
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 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 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 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 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 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 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 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 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
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.
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
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(-)
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 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 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 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 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 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 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 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 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 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 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
> &
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
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.
__
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
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
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.
> >
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 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 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
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 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
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
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 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
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
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
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 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
__
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
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
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 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
>
>
> 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
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
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
>
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 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
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
>
>
> 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).
>
> 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
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
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
101 - 193 of 193 matches
Mail list logo
