On 20 November 2014 08:34:54 CET, Jesse Jiang jessejiang0...@outlook.com
wrote:
Add WinRT API supports
At least 2 fairly major issues:
1) using rand() basically never is correct. Use the appropriate
CryptographicBuffer function (yes, that means you need some C++ code
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi,
- Mail original -
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
---
libavcodec/pngdec.c | 30 --
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 57b73c1..e3d61f6 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -411,11 +411,6 @@ static int
Hi,
- Mail original -
---
libavcodec/pngdec.c | 30 --
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 57b73c1..e3d61f6 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@
Hi Reimar,
Because of Windows RT cannot use CryptographicBuffer or _beginthreadex API, so
I try to use rand() instead of it, or we need to write own function instead of
it. If we use WinRT api to instead of these apis, it will cause more bugs.
Best regards,Jesse
From: reimar.doeffin...@gmx.de
Le decadi 30 brumaire, an CCXXIII, Benoit Fouet a écrit :
---
libavcodec/pngdec.c | 30 --
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 57b73c1..e3d61f6 100644
--- a/libavcodec/pngdec.c
+++
---
libavcodec/pngdec.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 57b73c1..8467443 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -924,16 +924,6 @@ static int
This is of course, completly wrong.
The replacement is CryptographicBuffer, allowed in WinRT.
On 20 Nov, Jesse Jiang wrote :
Hi Reimar,
Because of Windows RT cannot use CryptographicBuffer or _beginthreadex API,
so I try to use rand() instead of it, or we need to write own function
instead
On 20 Nov, Jesse Jiang wrote :
Add WinRT API supports
This patch is wrong on almost every level.
rand() is wrong.
modifying configure because your headers are broken is wrong too.
doing an API rewrapper in FFmpeg is the wrong place, look at
Hi,
- Mail original -
Le decadi 30 brumaire, an CCXXIII, Benoit Fouet a écrit :
---
libavcodec/pngdec.c | 30 --
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 57b73c1..e3d61f6
Le decadi 30 brumaire, an CCXXIII, Benoit Fouet a écrit :
---
libavcodec/pngdec.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 57b73c1..8467443 100644
--- a/libavcodec/pngdec.c
+++
Hi,
- Mail original -
Le decadi 30 brumaire, an CCXXIII, Benoit Fouet a écrit :
---
libavcodec/pngdec.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 57b73c1..8467443 100644
---
indentation*
[...]
--
Clément B.
pgpgGb9NhW91e.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Thu, Nov 20, 2014 at 07:36:55AM +, Jesse Jiang wrote:
*restrict has been replaced by av_restrict. I meet this bug when I compiler
for ARM in VS. There should be some other places need to be replaced.
Best regards,Jesse
float_dsp_init_vfp.c |2
Hi JB,
Based on my understanding, mingw-w64 need gcc, so in this way, we need to
linked gcc library into our App. I don't want a big library with our Apps.
I know the mingw is a correct way, but how could it works with MSVC?
Date: Thu, 20 Nov 2014 09:53:27 +0100
From: j...@videolan.org
To:
1. libgcc is not big
2. MSVC 2013 has correctly defined headers to solve the rand issue and
the configure part.
Le 20/11/2014 11:34, Jesse Jiang a écrit :
Hi JB,
Based on my understanding, mingw-w64 need gcc, so in this way, we need to
linked gcc library into our App. I don't want a big
On Thu, Nov 20, 2014 at 09:40:03AM +0100, Benoit Fouet wrote:
Hi,
- Mail original -
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
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/apngdec.c| 409 +++
3 files changed, 411 insertions(+)
create mode 100644 libavformat/apngdec.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index
On 11/20/2014 8:40 AM, Benoit Fouet wrote:
LGTM
http://fate.ffmpeg.org/report.cgi?time=20141120142015slot=i686-windows-icl
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
---
ffplay.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ffplay.c b/ffplay.c
index f79161d..3009c82 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -3169,8 +3169,8 @@ static int read_thread(void *arg)
stream_component_close(is, is-video_stream);
if
On Thu, Nov 20, 2014 at 03:07:17PM +0100, Benoit Fouet wrote:
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 8 +++
libavcodec/pngdec.c | 142
+++-
5 files
On 21 November 2014 01:23, Derek Buitenhuis derek.buitenh...@gmail.com
wrote:
On 11/20/2014 8:40 AM, Benoit Fouet wrote:
LGTM
http://fate.ffmpeg.org/report.cgi?time=20141120142015slot=i686-windows-icl
- Derek
Works fine with lto, but apparently one shouldnt assume the existing code
is
It serves to distinguish if we will (de)packetize the format from an AVFrame or
an AVPacket. We will need AVFrame support for v4l m2m and we can certainly not
use as-is e.g. V4L2_PIX_FMT_YUV420 as AV_PIX_FMT_YUV420P since the former is
pseudo-packed while the later is planar. Also, V4L multi
This code needs lavc for AV_CODEC_ID_* and can be used by lavc lavfi with v4l
m2m support.
---
configure | 6 ++-
libavcodec/Makefile | 1 +
libavcodec/v4l2-common.c | 105 ++
libavcodec/v4l2-common.h | 47
This is the only format supported by MFC5 HW decoders (e.g. Samsung exynos
4412).
---
libavutil/pixdesc.c | 12
libavutil/pixfmt.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 648d014..426dfd4 100644
---
---
libavcodec/v4l2-common.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/libavcodec/v4l2-common.c b/libavcodec/v4l2-common.c
index 815a5c4..80e1365 100644
--- a/libavcodec/v4l2-common.c
+++ b/libavcodec/v4l2-common.c
@@ -58,6 +58,39 @@ const struct
Default buffer settings should work with all drivers (mmaped memory from the
driver) but would imply useless memcpy()'s if used in the standard way.
libavcodec/v4l2.h is now installed to allow applications to get the proper
buffers to avoid these copies.
This has been tested on MFC5, on a
---
Changelog | 2 +-
configure | 1 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_v4l2_m2m.c | 250 ++
5 files changed, 254 insertions(+), 1 deletion(-)
create mode 100644
Hi,
currently the native aac encoder is marked as experimental, while the
libvo_aacenc encoder is not.
However, after reading the wiki [1] and especially the mentioned mail
[2], it seems the native encoder is better.
Thus I'm wondering if it would make sense to no longer mark the native
On 20 Nov, Alexis Ballier wrote :
This is the only format supported by MFC5 HW decoders (e.g. Samsung exynos
4412).
Why not convert it to a normal format?
With my kindest regards,
--
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
On Thu, Nov 20, 2014 at 04:01:27PM +0100, Benoit Fouet wrote:
---
ffplay.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ffplay.c b/ffplay.c
index f79161d..3009c82 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -3169,8 +3169,8 @@ static int read_thread(void *arg)
On Thu, 20 Nov 2014 17:51:54 +0100
Alexis Ballier aball...@gentoo.org wrote:
This is the only format supported by MFC5 HW decoders (e.g. Samsung exynos
4412).
---
libavutil/pixdesc.c | 12
libavutil/pixfmt.h | 1 +
2 files changed, 13 insertions(+)
diff --git
C:\Users\Zach\Development\ffmpeg-20141120-git-4388e78-win32-static\bin
.\ffmpeg -v 9 -loglevel 99 -rtbufsize 1500
f dshow -i video=HP HD Webcam [Fixed] -f dshow -i audio=Stereo Mix (IDT High
Definition -f mpegts -mpegts_pmt_sta
pid 0x40 -mpegts_start_pid 0x45 -vf fps=29.97,scale=704x480 -muxrate
On Thu, Nov 20, 2014 at 05:59:35PM +0100, Andreas Cadhalpun wrote:
Hi,
currently the native aac encoder is marked as experimental, while
the libvo_aacenc encoder is not.
However, after reading the wiki [1] and especially the mentioned
mail [2], it seems the native encoder is better.
On Fri, Nov 21, 2014 at 06:03:36AM +1100, Matt Oliver wrote:
On 21 November 2014 02:28, Matt Oliver protogo...@gmail.com wrote:
On 21 November 2014 01:23, Derek Buitenhuis derek.buitenh...@gmail.com
wrote:
On 11/20/2014 8:40 AM, Benoit Fouet wrote:
LGTM
On Thu, Nov 20, 2014 at 05:51:56PM +0100, Alexis Ballier wrote:
Default buffer settings should work with all drivers (mmaped memory from the
driver) but would imply useless memcpy()'s if used in the standard way.
libavcodec/v4l2.h is now installed to allow applications to get the proper
Hi Lukasz!
On 2014-11-19 00:06 +0100, Lukasz Marek wrote:
On 18.11.2014 22:20, Reynaldo H. Verdejo Pinochet wrote:
Hi. Overall this looks good, thanks. I would move the test to
tests/ though and integrate it with the build/test system as,
say, the way tiny_ssim is:
grep -R tiny_ssim *
rc_eq is an option, so it is copied by av_opt_copy(dest, src); above.
---
libavcodec/options.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/libavcodec/options.c b/libavcodec/options.c
index 9713e8d..44f3e90 100644
--- a/libavcodec/options.c
+++ b/libavcodec/options.c
@@ -209,16
On 21.11.2014 00:14, Alexander Strasser wrote:
Hi Lukasz!
On 2014-11-19 00:06 +0100, Lukasz Marek wrote:
On 18.11.2014 22:20, Reynaldo H. Verdejo Pinochet wrote:
Hi. Overall this looks good, thanks. I would move the test to
tests/ though and integrate it with the build/test system as,
say,
---
ffserver.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/ffserver.c b/ffserver.c
index 40a5faa..5e392f7 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -2253,6 +2253,7 @@ static int http_prepare_data(HTTPContext *c)
c-state = HTTPSTATE_SEND_DATA_TRAILER;
Signed-off-by: Lukasz Marek lukasz.m.lu...@gmail.com
---
ffserver.c| 2 +-
ffserver_config.c | 18 +-
ffserver_config.h | 2 ++
3 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/ffserver.c b/ffserver.c
index 933eb0e..40a5faa 100644
--- a/ffserver.c
+++
On 21.11.2014 00:47, Lukasz Marek wrote:
Signed-off-by: Lukasz Marek lukasz.m.lu...@gmail.com
---
ffserver.c| 2 +-
ffserver_config.c | 18 +-
ffserver_config.h | 2 ++
3 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/ffserver.c b/ffserver.c
index
On Fri, Nov 21, 2014 at 12:23:26AM +0100, Lukasz Marek wrote:
rc_eq is an option, so it is copied by av_opt_copy(dest, src); above.
---
libavcodec/options.c | 10 --
1 file changed, 10 deletions(-)
LGTM
thanks
--
Michael GnuPG fingerprint:
On 21.11.2014 01:08, Michael Niedermayer wrote:
On Fri, Nov 21, 2014 at 12:23:26AM +0100, Lukasz Marek wrote:
rc_eq is an option, so it is copied by av_opt_copy(dest, src); above.
---
libavcodec/options.c | 10 --
1 file changed, 10 deletions(-)
LGTM
pushed
On 20.11.2014 02:17, Michael Niedermayer wrote:
[...]
+{
+AVDictionary *dict = NULL;
+char *buffer = NULL;
+
+printf(Testing av_dict_get_string() and
av_dict_parse_string());
+av_dict_get_string(dict, buffer, '=', ',');
+printf(%s\n, buffer);
+av_freep(buffer);
+
On 18.11.2014 22:50, Reynaldo H. Verdejo Pinochet wrote:
Hi
On 11/16/2014 10:46 PM, Lukasz Marek wrote:
[..]
@@ -3355,6 +3354,9 @@ static int add_av_stream(FFServerStream *feed, AVStream
*st)
fst = add_av_stream1(feed, av, 0);
if (!fst)
return -1;
+if
On 18.11.2014 23:25, Reynaldo H. Verdejo Pinochet wrote:
Hi
On 11/18/2014 06:54 PM, Nicolas George wrote:
L'octidi 28 brumaire, an CCXXIII, Reynaldo H. Verdejo Pinochet a
écrit :
I think I commented about this before but having yesvar novar
options seems redundant. Having var = yes or no if
On 18.11.2014 21:35, Reynaldo H. Verdejo Pinochet wrote:
Hi
On 11/16/2014 10:46 PM, Lukasz Marek wrote:
Signed-off-by: Lukasz Marek lukasz.m.lu...@gmail.com
[..]
@@ -965,43 +881,38 @@ static int ffserver_parse_config_stream(FFServerConfig
*config, const char *cmd,
ret =
On 18.11.2014 21:44, Reynaldo H. Verdejo Pinochet wrote:
Hi Lukasz
On 11/16/2014 10:46 PM, Lukasz Marek wrote:
[..]
@@ -174,13 +174,20 @@ void ffserver_parse_acl_row(FFServerStream *stream,
FFServerStream* feed,
}
/* add a codec and set the default parameters */
-static void
Fixes Ticket3355
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
doc/examples/decoding_encoding.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/doc/examples/decoding_encoding.c b/doc/examples/decoding_encoding.c
index 556fe98..80da664 100644
---
Do you mean that we can use rand() instead of CryptGenRandom in ffmpeg?
Date: Thu, 20 Nov 2014 12:17:10 +0100
From: j...@videolan.org
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] WinRT API support patch
1. libgcc is not big
2. MSVC 2013 has correctly defined headers to solve
On Fri, Nov 21, 2014 at 01:43:29AM +, Jesse Jiang wrote:
Do you mean that we can use rand() instead of CryptGenRandom in ffmpeg?
rand() is completely wrong
its not even doing the correct operation
rand() is pseudo random
the code requires a strong (and non pseudo) random value
[...]
--
On Fri, Nov 14, 2014 at 02:39:46PM +0100, Michael Niedermayer wrote:
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/nellymoserdec.c |9 ++---
libavcodec/nellymoserenc.c | 17 +++--
2 files changed, 17 insertions(+), 9 deletions(-)
applied a while
On Nov 20, 2014, at 02:41, Benoit Fouet benoit.fo...@free.fr wrote:
Hi,
- Mail original -
From b38a1396e2335e2d0ef2619b5a3890f91c31c8a8 Mon Sep 17 00:00:00
2001
From: Rodger Combs rodger.co...@gmail.com
Date: Thu, 20 Nov 2014 01:47:05 -0600
Subject: [PATCH] dashenc: Add a
Hi All,
I did some research, rand() is pseudo random. CryptGenRandom is the system-wide
seed, but it cannot be used in Windows RT.
I try to use CryptographicBuffer, which is Windows RT API, but there is a
problem. This API needs to link Windows.winmd. The Windows.winmd just like a
DLL, but it
On Nov 20, 2014, at 21:47, Rodger Combs rodger.co...@gmail.com wrote:
On Nov 20, 2014, at 02:41, Benoit Fouet benoit.fo...@free.fr
mailto:benoit.fo...@free.fr wrote:
Hi,
- Mail original -
From b38a1396e2335e2d0ef2619b5a3890f91c31c8a8 Mon Sep 17 00:00:00
2001
From: Rodger
(sorry for the delay)
On Sun, Nov 16, 2014 at 10:53:15PM +0100, Marton Balint wrote:
Signed-off-by: Marton Balint c...@passwd.hu
---
doc/filters.texi| 4 ++--
libavfilter/f_ebur128.c | 11 ---
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git
Now, I find a function get_generic_seed()
So, I use this function will work fine?
uint32_t av_get_random_seed(void){uint32_t seed;
#if HAVE_CRYPTGENRANDOMHCRYPTPROV provider;if
(CryptAcquireContext(provider, NULL, NULL, PROV_RSA_FULL,
CRYPT_VERIFYCONTEXT |
On Thu, 20 Nov 2014 21:41:56 +0100
Michael Niedermayer michae...@gmx.at wrote:
On Thu, Nov 20, 2014 at 05:51:56PM +0100, Alexis Ballier wrote:
Default buffer settings should work with all drivers (mmaped memory
from the driver) but would imply useless memcpy()'s if used in the
standard
On Thu, 20 Nov 2014 18:42:19 +0100
wm4 nfx...@googlemail.com wrote:
I think this should be rejected. It's far too special to be useful in
general, and it's not even pixel- or line-addressable (Z-shaped tiles,
seriously?). It's pretty much a raw codec, not a pixel format.
How do you put this in
On Thu, 20 Nov 2014 18:40:18 +0100
Jean-Baptiste Kempf j...@videolan.org wrote:
On 20 Nov, Alexis Ballier wrote :
This is the only format supported by MFC5 HW decoders (e.g. Samsung
exynos 4412).
Why not convert it to a normal format?
That is exactly what the m2m filter is for: on 4412
62 matches
Mail list logo
