I guess, this is based on the irc talk. Thank you again!
Cheers,
Gerion
Am Dienstag 17 Februar 2015, 17:02:31 schrieb Derek Buitenhuis:
> Signed-off-by: Derek Buitenhuis
> ---
> libavcodec/libx265.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/libavcod
On 2/17/2015 11:56 PM, Michael Niedermayer wrote:
> this should be EINVAL too i think
Yep. Changed locally.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Mon, Feb 16, 2015 at 07:49:50PM +0100, Nicolas George wrote:
> 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
> faq.texi | 34
On Wed, Feb 18, 2015 at 01:26:09AM +0530, supraja reddy wrote:
> Hello,
>
> I have made changes as suggested. Please let me know if any further changes
> required.
> I will soon send a patch for adding a fate test too.
>
> Thanks,
> Supraja
>
> On Mon, Feb 16, 2015 at 5:10 PM, Michael Niedermaye
On Tue, Feb 17, 2015 at 05:02:31PM -0500, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis
> ---
> libavcodec/libx265.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
> index c35f6c2..0d546d8 100644
> --
On Tue, Feb 17, 2015 at 05:02:29PM -0500, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis
> ---
> libavcodec/libx265.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
LGTM
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I k
On 2/17/2015 10:10 PM, James Almer wrote:
> Afaik, if the error is based on user input then EINVAL (Invalid argument) is
> correct.
> AVERROR_INVALIDDATA is when the error is in the bitstream/container and not
> an argument the
> user passed to the library.
Right, I conflated the two.
Patch dr
On 17/02/15 7:02 PM, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis
> ---
> libavcodec/libx265.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
> index 9f40e95..c35f6c2 100644
> --- a/libavcodec/libx265.c
> +++ b/li
Signed-off-by: Derek Buitenhuis
---
libavcodec/libx265.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index aee7ae2..9f40e95 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -76,10 +76,6 @@ static av_cold
Signed-off-by: Derek Buitenhuis
---
libavcodec/libx265.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 9f40e95..c35f6c2 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -99,7 +99,7 @@ static av_cold int libx265
Signed-off-by: Derek Buitenhuis
---
libavcodec/libx265.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index c35f6c2..0d546d8 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -25,6 +25,7 @@
#endif
#
Hello,
I have made changes as suggested. Please let me know if any further changes
required.
I will soon send a patch for adding a fate test too.
Thanks,
Supraja
On Mon, Feb 16, 2015 at 5:10 PM, Michael Niedermayer
wrote:
> On Mon, Feb 16, 2015 at 03:11:08PM +0530, supraja reddy wrote:
> > Hel
On 17/02/15 9:21 AM, Michael Niedermayer wrote:
> On Sun, Feb 08, 2015 at 02:54:25PM +0100, Christophe Gisquet wrote:
>> Hi,
>>
>> 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 gener
Matt Oliver gmail.com> writes:
> > > Attached patch intends to fix compilation with msvc
> > > when the vfwcap input device is disabled.
> Disabling vfwcap is not something i ever bothered to
> do. But adding user32.lib is perfectly acceptable as
> its a standard windows library anyway. I havn
On Tue, Feb 17, 2015 at 05:35:05PM +, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/opusdec.c | 2 --
> 1 file changed, 2 deletions(-)
LGTM
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
DNS cache poisoning attacks, popular search e
Hi,
2015-02-17 11:44 GMT+01:00 Michael Niedermayer :
> the following seems to fix it, but i sure do not know why these 2
> lines failed while the others do not seem to fail
> adding , to all works as well
It seems most code in libavcodec/arm passes macros using
comma-separated arguments. If it is
On Tue, Feb 17, 2015 at 02:17:31AM +0100, Stefano Sabatini wrote:
> 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
ive added a landing page for Outreachy as well which points to the
Signed-off-by: Paul B Mahol
---
libavcodec/opusdec.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/opusdec.c b/libavcodec/opusdec.c
index 84fa0ff..f8ca133 100644
--- a/libavcodec/opusdec.c
+++ b/libavcodec/opusdec.c
@@ -43,8 +43,6 @@
#include "libswresample/swresample.h"
#in
> On 16 Feb 2015, at 19:54, Michael Niedermayer wrote:
>
> 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
>>
>>
On Tue, Feb 17, 2015 at 01:52:19PM +0100, wm4 wrote:
> On Tue, 17 Feb 2015 12:40:52 +
> Kevin Wheatley wrote:
>
> > On Tue, Feb 17, 2015 at 12:25 PM, Michael Niedermayer
> > wrote:
> > > if the codec id doesnt match the expected, mov_read_extradata will
> > > return 0 even without any trunc
On Tue, Feb 17, 2015 at 12:40:52PM +, Kevin Wheatley wrote:
> On Tue, Feb 17, 2015 at 12:25 PM, Michael Niedermayer
> wrote:
> > if the codec id doesnt match the expected, mov_read_extradata will
> > return 0 even without any truncation.
> > In this case the error message would be incorrect
>
On Tue, Feb 17, 2015 at 09:40:14AM +0100, Mickaël Raulet wrote:
> Looks better to me.
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
On Tue, 17 Feb 2015 12:40:52 +
Kevin Wheatley wrote:
> On Tue, Feb 17, 2015 at 12:25 PM, Michael Niedermayer
> wrote:
> > if the codec id doesnt match the expected, mov_read_extradata will
> > return 0 even without any truncation.
> > In this case the error message would be incorrect
>
> S
On Tue, Feb 17, 2015 at 12:25 PM, Michael Niedermayer wrote:
> if the codec id doesnt match the expected, mov_read_extradata will
> return 0 even without any truncation.
> In this case the error message would be incorrect
So should I code the test against codec id against the files I have or
the
Hi,
2015-02-17 13:29 GMT+01:00 Michael Niedermayer :
> also, i wonder, should this be extended to also work with C files ?
Again, with asm, macro hell sometimes gives you that. So it makes sense.
I don't know well enough icc/llvm/whatever we handle, so the main
issue might be to ask the compiler
On Tue, Feb 17, 2015 at 01:25:10PM +0100, Christophe Gisquet wrote:
> Hi,
>
> 2015-02-17 13:21 GMT+01:00 Michael Niedermayer :
> > btw, this works too: (without DBG=1)
> > make V=2 libavcodec/x86/vp8dsp_loopfilter.dbg.o
>
> Yeah, once I'm working on a specific file, that's what I do.
>
> But iir
On Tue, Feb 17, 2015 at 11:58:06AM +, Kevin Wheatley wrote:
> Oops, I missed that when I allowed the atom to be added to the end of
> the extradata, updated.
>
> I'm not sure if logging as an error is appropriate in the case when
> the extradata is not large enough, for this to occur the file
Hi,
2015-02-17 13:21 GMT+01:00 Michael Niedermayer :
> btw, this works too: (without DBG=1)
> make V=2 libavcodec/x86/vp8dsp_loopfilter.dbg.o
Yeah, once I'm working on a specific file, that's what I do.
But iirc, you can just do make DBG=1 and wait for any error to mention
the offending .dbg.asm
On Sun, Feb 08, 2015 at 02:54:25PM +0100, Christophe Gisquet wrote:
> Hi,
>
> 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.
>
Oops, I missed that when I allowed the atom to be added to the end of
the extradata, updated.
I'm not sure if logging as an error is appropriate in the case when
the extradata is not large enough, for this to occur the file will
have been truncated somehow and the mov_read_extradata function will
On Tue, Feb 17, 2015 at 08:23:17AM +0100, Christophe Gisquet wrote:
> 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?
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF212
On Tue, Feb 17, 2015 at 09:20:23AM +, Kevin Wheatley wrote:
> Add simple ACLR atom reading to set the color range of the incomming
> track for codec's like DNxHD that utilise AVID's proprietary atom.
>
> Note: for this to work with ffmpeg generated DNxHD QuickTime files you
> need to also us
On Tue, Feb 17, 2015 at 07:33:04AM +, Tomperi Seppo wrote:
>
> > On 16 Feb 2015, at 19:54, Michael Niedermayer
> > wrote:
> >
> > 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 be
On 2015-02-16 20:24, Mark Reid wrote:
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
Add simple ACLR atom reading to set the color range of the incomming
track for codec's like DNxHD that utilise AVID's proprietary atom.
Note: for this to work with ffmpeg generated DNxHD QuickTime files you
need to also use my other patch to prevent ffmpeg generating 'corrupt'
files.
From 561db6
On Tue, Feb 17, 2015 at 04:31:07PM +0800, Zhaoxiu Zeng wrote:
> From bf2964c07fde48c633ca4d8276282010e7c7f084 Mon Sep 17 00:00:00 2001
> From: "zhaoxiu.zeng"
> Date: Tue, 17 Feb 2015 16:03:47 +0800
> Subject: [PATCH 1/1] avcodec: change type of ff_square_tab from uint32_t to
> uint16_t
>
> uint1
On Tue, Feb 17, 2015 at 10:03:29AM +0100, Clément Bœsch wrote:
> On Tue, Feb 17, 2015 at 04:31:07PM +0800, Zhaoxiu Zeng wrote:
> > From bf2964c07fde48c633ca4d8276282010e7c7f084 Mon Sep 17 00:00:00 2001
> > From: "zhaoxiu.zeng"
> > Date: Tue, 17 Feb 2015 16:03:47 +0800
> > Subject: [PATCH 1/1] avco
Looks better to me.
Mickaël
Le mardi 17 février 2015, Christophe Gisquet
a écrit :
> 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, b
>From bf2964c07fde48c633ca4d8276282010e7c7f084 Mon Sep 17 00:00:00 2001
From: "zhaoxiu.zeng"
Date: Tue, 17 Feb 2015 16:03:47 +0800
Subject: [PATCH 1/1] avcodec: change type of ff_square_tab from uint32_t to
uint16_t
uint16_t is big enough except the first element, but the first element
is never
39 matches
Mail list logo
