2015-02-17 8:28 GMT+01:00 Mickaël Raulet :
> It seems to me that you are affecting 8 when it is avx2 instead of 11.
> Shouldn't it be the opposite? At least this what the commit message says.
Huh, brainfart... And the fact that I can't easily test avx2 doesn't help.
So here's a patch with the va
It seems to me that you are affecting 8 when it is avx2 instead of 11.
Shouldn't it be the opposite? At least this what the commit message says.
Mickaël
Le mardi 17 février 2015, Christophe Gisquet
a écrit :
> Hi,
>
> here's an updated patch, which takes into account the fact avx2
> sometimes u
Hi,
2015-02-07 23:11 GMT+01:00 Michael Niedermayer :
> this breaks building shared libs:
>
> /usr/bin/ld: libavcodec/x86/hevc_mc.o: relocation R_X86_64_32 against `.text'
> can not be used when making a shared object; recompile with -fPIC
> libavcodec/x86/hevc_mc.o: could not read symbols: Bad va
Hi,
2015-02-08 14:54 GMT+01:00 Christophe Gisquet :
> 2015-02-08 14:07 GMT+01:00 Carl Eugen Hoyos :
>> Doesn't this also need an update for "make clean"?
>
> Right, here's an updated one, also improving dependency generation and
> allowing more genering (for now) code.
Ping?
I can probably live
Hi,
2015-02-08 14:53 GMT+01:00 Christophe Gisquet :
> This one is specifically for "might be insn set a or b, but reg size
> makes it clearer".
Ping?
--
Christophe
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinf
Hi,
here's an updated patch, which takes into account the fact avx2
sometimes uses additional intermediate xmm regs.
Maybe the fix is actually changing the avx2 code, but avx2 and x86_32
is a really weird combination.
--
Christophe
From 2955eea46501d096a47fbf2fb1824daa622f6031 Mon Sep 17 00:00:
On Mon, Feb 16, 2015 at 10:22:17PM +0100, Nicolas George wrote:
> The current value, 8, is too low to be really useful.
> The heuristic tries to allocate enough room for 10 seconds.
>
> Signed-off-by: Nicolas George
> ---
> ffmpeg.c | 26 --
> 1 file changed, 24 insertion
On Mon, Feb 16, 2015 at 10:22:16PM +0100, Nicolas George wrote:
> This can help finding the source of A-V desync with live input.
>
> Signed-off-by: Nicolas George
> ---
> ffmpeg.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
LGTM
[...]
--
Michael GnuPG fingerprint: 9FF2
On Sat, 14 Feb 2015, Clément Bœsch wrote:
On Sat, Feb 14, 2015 at 02:08:15AM +0100, Marton Balint wrote:
Signed-off-by: Marton Balint
---
Makefile | 1 +
doc/ffplay.texi | 4 +
ffplay.c | 336 +-
Hi folks,
we decided to participate in GSOC 2015 also this year, and we setup a
page on the wiki:
http://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2015
Check also:
http://www.google-melange.com/gsoc/events/google/gsoc2015
Michael, Reynaldo, and me will act as administrators for the
program. A
On 16/02/15 6:46 PM, Clément Bœsch wrote:
> On Mon, Feb 16, 2015 at 09:48:25PM +0100, James Almer wrote:
>> ffmpeg | branch: master | James Almer | Mon Feb 16
>> 16:53:31 2015 -0300| [22596383f3b8c7cd8a06570957face3875a73d3b] | committer:
>> James Almer
>>
>> avcodec/hevcdsp: optimize pixel comp
On Mon, Feb 16, 2015 at 09:48:25PM +0100, James Almer wrote:
> ffmpeg | branch: master | James Almer | Mon Feb 16
> 16:53:31 2015 -0300| [22596383f3b8c7cd8a06570957face3875a73d3b] | committer:
> James Almer
>
> avcodec/hevcdsp: optimize pixel comparison in sao_edge_filter
>
> GCC 4.9.2 on a Co
The current value, 8, is too low to be really useful.
The heuristic tries to allocate enough room for 10 seconds.
Signed-off-by: Nicolas George
---
ffmpeg.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
On my hardware, recording from v4l2 and ALSA produces A
The value tells the typical size of a packet from the demuxer.
Signed-off-by: Nicolas George
---
libavdevice/alsa-audio-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavdevice/alsa-audio-common.c b/libavdevice/alsa-audio-common.c
index bf876ed..f4b86bb 100644
---
This can help finding the source of A-V desync with live input.
Signed-off-by: Nicolas George
---
ffmpeg.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index becd5df..a52de20 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -3356,6 +3356,7 @@ static int c
On Mon, Feb 16, 2015 at 08:19:01PM +0100, Christophe Gisquet wrote:
> 2015-02-16 10:43 GMT+01:00 Christophe Gisquet :
> > Obviously I shouldn't unconditionally use r3srcq or equivalent, as
> > !PIC just directly access the %%table
> > I probably need to define an intermediate, say TABLE, which is e
On 16/02/15 5:45 PM, Michael Niedermayer wrote:
> On Mon, Feb 16, 2015 at 05:06:20PM -0300, James Almer wrote:
>> GCC 4.9.2 on a Core i5-4200U @ 1.60GHz, Linux x86_64
>>
>> Before
>> 715487 decicycles in sao_edge_filter_8, 262144 runs, 0 skips
>>
>> After
>> 672104 decicycles in sao_edge_filter_8,
On Mon, Feb 16, 2015 at 05:06:20PM -0300, James Almer wrote:
> GCC 4.9.2 on a Core i5-4200U @ 1.60GHz, Linux x86_64
>
> Before
> 715487 decicycles in sao_edge_filter_8, 262144 runs, 0 skips
>
> After
> 672104 decicycles in sao_edge_filter_8, 262144 runs, 0 skips
>
> Signed-off-by: James Almer
>
Dear ffmpeg coderz,
I work for Laoviland Experience, a digital innovation start-up based in
Montpellier, France. We develop creative software for inspiration and
automation of graphical creations.(see our website www.laoviland.com for
additional info).
We are searching for specific technical
Hi Michael,
Here is a totally shot in a dark fix attempt for NEON register clobbering for
deblocking. Could you test it with qemu and check if it works.
-Seppo
From: Michael Niedermayer [mich...@niedermayer.cc]
Sent: Monday, February 16, 2015 3:28 AM
To
GCC 4.9.2 on a Core i5-4200U @ 1.60GHz, Linux x86_64
Before
715487 decicycles in sao_edge_filter_8, 262144 runs, 0 skips
After
672104 decicycles in sao_edge_filter_8, 262144 runs, 0 skips
Signed-off-by: James Almer
---
Not like the C versions of these functions matter to a CPU like the above, b
On Tue, Feb 17, 2015 at 04:47:47AM +1100, Matt Oliver wrote:
> 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 dev
On Mon, Feb 16, 2015 at 07:31:42PM +0100, wm4 wrote:
> Not allocating the pls->ctx will crash in libavformat/hls.c:1410, where
> it tries to dereference the field.
>
> Sample: http://ec24.rtp.pt/liverepeater/rtpn.smil/playlist.m3u8
> ---
> libavformat/hls.c | 6 +++---
> 1 file changed, 3 inserti
On Mon, Feb 16, 2015 at 4:07 AM, wrote:
> On 2015-02-13 01:36, Mark Reid wrote:
>
>> /**
>> + * Convert an UTF-8 string to UTF-16BE and write it.
>> + * @return number of bytes written.
>> + */
>> +int avio_put_str16be(AVIOContext *s, const char *str);
>>
>
> You could maybe split this patch up
2015-02-16 10:43 GMT+01:00 Christophe Gisquet :
> Obviously I shouldn't unconditionally use r3srcq or equivalent, as
> !PIC just directly access the %%table
> I probably need to define an intermediate, say TABLE, which is either
> r3srcq or %%table, and use it for loading the xmm regs.
The new att
I though an extra configure option would have been the most logical way
of removing warnings but you are probably right: I will use
--extra-cflags instead. Thanks for the feedback.
On Sat, Feb 14, 2015 at 9:55 AM, Reimar Döffinger
wrote:
On 12.02.2015, at 19:56, Gautier Pelloux-Prayer
wro
L'octidi 28 pluviôse, an CCXXIII, Clement Boesch a écrit :
> A lot of users will want to know how to avoid the transcode.
True. New patch attached.
Regards,
--
Nicolas George
From db3ed4560061be5cbfad5547ef7a2d9af7ccb874 Mon Sep 17 00:00:00 2001
From: Nicolas George
Date: Mon, 9 Feb 2015 16:
On Mon, Feb 16, 2015 at 07:34:52PM +0100, Nicolas George wrote:
> Le primidi 21 pluviôse, an CCXXIII, Kieran Kunhya a écrit :
> > The DAR for analogue compatible media (e.g. SD DVB) comes from the
> > active samples and not from the "full image".
>
> The exact meaning of DAR in this context is ent
On Tue, Feb 17, 2015 at 12:38:53AM +0800, zhaoxiu.zeng wrote:
> 在 2015/2/14 23:48, Hendrik Leppkes 写道:
> > On Sat, Feb 14, 2015 at 4:11 PM, zhaoxiu.zeng
> > wrote:
> >> From a67cc93ea550ba2670003f5be024626a093a06fd Mon Sep 17 00:00:00 2001
> >> From: Zeng Zhaoxiu
> >> Date: Sat, 14 Feb 2015 21:0
Le primidi 21 pluviôse, an CCXXIII, Kieran Kunhya a écrit :
> The DAR for analogue compatible media (e.g. SD DVB) comes from the
> active samples and not from the "full image".
The exact meaning of DAR in this context is entirely for us to decide. And
that means collectively, not you alone. And a
Not allocating the pls->ctx will crash in libavformat/hls.c:1410, where
it tries to dereference the field.
Sample: http://ec24.rtp.pt/liverepeater/rtpn.smil/playlist.m3u8
---
libavformat/hls.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/hls.c b/libavforma
On Mon, Feb 16, 2015 at 12:47:36PM +, Tomperi Seppo wrote:
> More NEON optimizations for testing. fate-hevc passes on Tegra K1, but these
> haven't been tested for NEON clobbering.
>
> -Seppo
>
>
> From: Tomperi Seppo
> Sent: Monday, February 16, 2015
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 Fri, Feb 13, 2015 at 10:51:32PM +0100, Gilles Chanteperdrix wrote:
> Signed-off-by: Gilles Chanteperdrix
> ---
> libavformat/rtpdec_mpeg4.c | 84
> +-
> 1 file changed, 76 insertions(+), 8 deletions(-)
Hi, what about this patch?
Regards.
--
On Mon, Feb 16, 2015 at 05:05:28PM +, Kevin Wheatley wrote:
> This time with patch...
>
> On Mon, Feb 16, 2015 at 4:58 PM, Kevin Wheatley
> wrote:
> > Whilst compiling with -DDEBUG I get the following...
> >
> > libavformat/rtpdec_h264.c: In function 'h264_handle_packet_stap_a':
> > libavform
This time with patch...
On Mon, Feb 16, 2015 at 4:58 PM, Kevin Wheatley
wrote:
> Whilst compiling with -DDEBUG I get the following...
>
> libavformat/rtpdec_h264.c: In function 'h264_handle_packet_stap_a':
> libavformat/rtpdec_h264.c:208: error: 'data' undeclared (first use in
> this function)
>
Whilst compiling with -DDEBUG I get the following...
libavformat/rtpdec_h264.c: In function 'h264_handle_packet_stap_a':
libavformat/rtpdec_h264.c:208: error: 'data' undeclared (first use in
this function)
libavformat/rtpdec_h264.c:208: error: (Each undeclared identifier is
reported only once
liba
在 2015/2/15 2:42, Christophe Gisquet 写道:
> 2015-02-14 17:14 GMT+01:00 Michael Niedermayer :
>> On Sat, Feb 14, 2015 at 11:03:13PM +0800, zhaoxiu.zeng wrote:
>>> From 7e4038fe1291b857261584e69323486fc955cfb2 Mon Sep 17 00:00:00 2001
>>> From: Zeng Zhaoxiu
>>> Date: Sat, 14 Feb 2015 20:08:48 +0800
>
在 2015/2/15 8:38, Michael Niedermayer 写道:
> On Fri, Feb 13, 2015 at 01:51:30PM +0800, Zhaoxiu Zeng wrote:
>> From 52be21b15e078fb52a841aefcf78409a408fe8b4 Mon Sep 17 00:00:00 2001
>> From: Zeng Zhaoxiu
>> Date: Fri, 13 Feb 2015 13:37:46 +0800
>> Subject: [PATCH 2/2] avcodec/h264: simplify h264_spl
在 2015/2/14 23:48, Hendrik Leppkes 写道:
> On Sat, Feb 14, 2015 at 4:11 PM, zhaoxiu.zeng wrote:
>> From a67cc93ea550ba2670003f5be024626a093a06fd Mon Sep 17 00:00:00 2001
>> From: Zeng Zhaoxiu
>> Date: Sat, 14 Feb 2015 21:09:28 +0800
>> Subject: [PATCH 4/5] avcodec/vc1_mc: create some helper functio
On Mon, 16 Feb 2015 13:31:40 -0300
James Almer wrote:
> On 16/02/15 1:22 PM, Alexis Ballier wrote:
> > [50cd43f2c] changed that silently, while no modern cpu has mmxext:
> > https://en.wikipedia.org/wiki/Extended_MMX
>
> In this case, mmxext refers to the integer instructions introduced
> with S
On 16/02/15 1:22 PM, Alexis Ballier wrote:
> [50cd43f2c] changed that silently, while no modern cpu has mmxext:
> https://en.wikipedia.org/wiki/Extended_MMX
In this case, mmxext refers to the integer instructions introduced with SSE,
and
not this Cyrix set.
AMD cpus pre-Athlon XP featured the in
[50cd43f2c] changed that silently, while no modern cpu has mmxext:
https://en.wikipedia.org/wiki/Extended_MMX
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 1d14d0a..ae73970 100755
--- a/configure
+++ b/configure
@@ -2010,7 +2010,7 @@
On Mon, Feb 16, 2015 at 11:30:26AM +, Tomperi Seppo wrote:
> Hi Michael,
>
> Here is a totally shot in a dark fix attempt for NEON register clobbering for
> deblocking. Could you test it with qemu and check if it works.
seems working,
will apply it to ffmpeg
thanks!
[...]
--
Michael
On 2015-02-13 01:36, Mark Reid wrote:
/**
+ * Convert an UTF-8 string to UTF-16BE and write it.
+ * @return number of bytes written.
+ */
+int avio_put_str16be(AVIOContext *s, const char *str);
You could maybe split this patch up by making the part that adds this
function a separate patch. No
On Mon, Feb 16, 2015 at 03:11:08PM +0530, supraja reddy wrote:
> Hello,
>
> I have attached a patch with optimization for twofish. Please let me know
> if any further changes required.
>
> Following are the results for crypto_bench after optimization.
>
> lavu TWOFISH size: 1048576
ffmpeg and qtdump could not decode pasp/colr atoms in the files made by ffmpeg,
when outputting DNxHD due to the incorrect padding placement. Now we add the
padding in the correct place, we also always add padding for Final Cut
compatibility.
Tidy up FATE changes due to padding changes.
Kevin
Fro
On Sat, Feb 14, 2015 at 11:38:40PM +0800, zhaoxiu.zeng wrote:
> 在 2015/2/14 23:18, Paul B Mahol 写道:
> > On 2/14/15, zhaoxiu.zeng wrote:
> >> From 2f68090470ce1f4eb738e7a4af80c78a7b5d461a Mon Sep 17 00:00:00 2001
> >> From: Zeng Zhaoxiu
> >> Date: Sat, 14 Feb 2015 21:11:18 +0800
> >> Subject: [PAT
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 Eugen
probably ok but i am no msvc guy and the msvc people seem not to
Hi,
2015-02-16 4:51 GMT+01:00 Michael Niedermayer :
> On Sat, Feb 07, 2015 at 06:49:38PM +, Christophe Gisquet wrote:
>> The 3*stride value stored in r3src can be loaded much later,
>> so use r3src instead of a dedicated gpr when possible.
>> ---
>> libavcodec/x86/hevc_mc.asm | 65
>> +++
Hello,
I have attached a patch with optimization for twofish. Please let me know
if any further changes required.
Following are the results for crypto_bench after optimization.
lavu TWOFISH size: 1048576 runs: 1024 time: 18.799 +- 0.132
gcrypt TWOFISH size: 1048576 run
51 matches
Mail list logo
