On date Saturday 2015-10-10 09:14:02 -0400, Ganesh Ajjanagadde encoded:
> Signed-off-by: Ganesh Ajjanagadde
> ---
> doc/developer.texi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Already applied.
--
FFmpeg = Fancy and Freak Muttering Pacific Excellent
On Thu, Oct 8, 2015 at 8:37 AM, Michael Niedermayer
wrote:
> Hi
>
> ill make 2.8.1 soon from release/2.8
> if you want something backported push it to release/2.8 soon!
> (or ask me to pull from your git tree, or if its trivial without
> conflicts then the commit hash to
On Sat, Oct 10, 2015 at 12:54:33PM -0400, Ganesh Ajjanagadde wrote:
> Proper names should be capitalized in all user facing API as far as
> possible. The option names themselves have not been changed since:
> 1. We consistently keep option names in lower case.
> 2. Changing them would break
During a build, a lot of *.o.-hash files are created - had not noticed
this as they are usually dumped in tmpfs on Linux. However, they
sometimes are present during a long build in the project directory, making it
annoying to commit while the project is being built.
These have been observed with
Proper names should be capitalized in all user facing API as far as
possible. The option names themselves have not been changed since:
1. We consistently keep option names in lower case.
2. Changing them would break existing scripts.
The converse is also true: improper names should not be
On Sat, Oct 10, 2015 at 4:36 AM, Ronald S. Bultje wrote:
> @@ -674,6 +715,24 @@ cglobal vp9_idct_idct_8x8_add_10, 4, 6 + ARCH_X86_64,
> 10, \
[...]
> +shl skipd, 1
> +lea blockq, [blockq+skipq*(mmsize>>1)]
add skipd, skipd
Nit: mmsize/2 is
Le nonidi 19 vendémiaire, an CCXXIV, wm4 a écrit :
> This looks suspicious. Like some code above this does unclean tricks
> with keeping side-data somehow referenced, instead of using proper
> methods like creating a new AVPacket reference.
It is the same code than in ffmpeg.c, but I must admit I
Partially fixes Ticket 4727.
-duration is not a safe expression, since duration can be INT_MIN.
One might ask how it can become INT_MIN.
Although it is true that line 2574 is no longer reached with INT_MIN due
to commit 053e80f6eaf8d87521fe58ea96886b6ee0bbe59d (which fixed another
integer
On Sat, Oct 10, 2015 at 05:31:55PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/sipr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
LGTM
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you
On date Saturday 2015-10-10 09:13:47 -0400, Ganesh Ajjanagadde encoded:
> Signed-off-by: Ganesh Ajjanagadde
> ---
> doc/build_system.txt | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
Already applied.
--
FFmpeg = F**king Fiendish Most
On Sat, Oct 3, 2015 at 4:43 PM, Ganesh Ajjanagadde wrote:
> ping
Please note that I am pasting the patch here as a reference, it may be
mangled by gmail:
Removes unnecessary isatty(), fixes Ticket2964
Signed-off-by: Ganesh Ajjanagadde
---
ffmpeg.c | 8 +---
1 file
On Sat, Oct 10, 2015 at 7:20 AM Ganesh Ajjanagadde wrote:
> On Thu, Oct 8, 2015 at 8:37 AM, Michael Niedermayer
> wrote:
> > Hi
> >
> > ill make 2.8.1 soon from release/2.8
> > if you want something backported push it to release/2.8 soon!
> > (or ask me
Signed-off-by: Paul B Mahol
---
libavcodec/sipr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/sipr.c b/libavcodec/sipr.c
index 4602a42..595097a 100644
--- a/libavcodec/sipr.c
+++ b/libavcodec/sipr.c
@@ -537,7 +537,7 @@ static int
Proper names should be capitalized in all user facing API as far as
possible. The option names themselves have not been changed since:
1. We consistently keep option names in lower case.
2. Changing them would break existing scripts.
3. I suspect that we want to be similar to Sox and its relevant
On Sat, Oct 10, 2015 at 05:51:09PM +0800, Zhang Rui wrote:
> ---
> libavformat/async.c | 41 +
> tests/ref/fate/async | 2 ++
> 2 files changed, 43 insertions(+)
applied
thanks
[...]
--
Michael GnuPG fingerprint:
On Sat, Oct 10, 2015 at 05:51:08PM +0800, Zhang Rui wrote:
> av_fifo_generic_write() does not return any error code.
> ---
> libavformat/async.c | 28 ++--
> 1 file changed, 22 insertions(+), 6 deletions(-)
applied
thanks
[...]
--
Michael GnuPG fingerprint:
On Sat, Oct 10, 2015 at 10:59 AM, Timothy Gu wrote:
> On Sat, Oct 10, 2015 at 7:20 AM Ganesh Ajjanagadde wrote:
>
>> On Thu, Oct 8, 2015 at 8:37 AM, Michael Niedermayer
>> wrote:
>> > Hi
>> >
>> > ill make 2.8.1 soon from
On date Thursday 2015-10-08 16:11:49 -0400, Ganesh Ajjanagadde encoded:
> On Thu, Oct 8, 2015 at 10:05 AM, Moritz Barsnick wrote:
> > On Thu, Oct 08, 2015 at 09:01:38 -0400, Ganesh Ajjanagadde wrote:
> >> For variables and functions visible outside of file scope, but only used
Hi,
2015-10-10 13:20 GMT+02:00 Michael Niedermayer :
> On Fri, Oct 09, 2015 at 11:53:45PM +0200, Christophe Gisquet wrote:
>> ---
>> libavcodec/x86/dct-test.c | 13 -
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> with this patch
> libavcodec/dct-test
On Sat, Oct 10, 2015 at 12:36:27PM -0400, Ganesh Ajjanagadde wrote:
> During a build, a lot of *.o.-hash files are created - had not noticed
> this as they are usually dumped in tmpfs on Linux. However, they
> sometimes are present during a long build in the project directory, making it
> annoying
2015.10.10. 19:33 keltezéssel, Nicolas George írta:
L'octidi 18 vendémiaire, an CCXXIV, Bodecs Bela a écrit :
I have altered the code to work correctly in situations with multiple
streams. I have also tested it with your command.
Thanks, it looks almost good for apply.
Your other patches
On Sat, Oct 10, 2015 at 9:50 AM, Stefano Sabatini wrote:
> On date Thursday 2015-10-08 11:14:40 -0400, Ganesh Ajjanagadde encoded:
>> On Thu, Oct 8, 2015 at 10:29 AM, Stefano Sabatini wrote:
>> > On date Thursday 2015-10-08 09:01:04 -0400, Ganesh
2015.10.10. 16:14 keltezéssel, Nicolas George írta:
Le nonidi 19 vendémiaire, an CCXXIV, Bodecs Bela a écrit :
using tee pseudo muxer I faced an issue.
Sorry for the duplicated work, I already submitted an identical patch:
http://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/180686.html
On Sat, 10 Oct 2015 15:19:43 +0200
Nicolas George wrote:
> Similar to 33fefdb44.
> Fix trac ticket #4921.
>
> Signed-off-by: Nicolas George
> ---
> libavformat/tee.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/tee.c
L'octidi 18 vendémiaire, an CCXXIV, Bodecs Bela a écrit :
> I have altered the code to work correctly in situations with multiple
> streams. I have also tested it with your command.
Thanks, it looks almost good for apply.
Your other patches were made with git format-patch, so that is ok; do not
On Sat, Oct 10, 2015 at 06:14:13PM +0200, Christophe Gisquet wrote:
> Hi,
>
> 2015-10-10 13:20 GMT+02:00 Michael Niedermayer :
> > On Fri, Oct 09, 2015 at 11:53:45PM +0200, Christophe Gisquet wrote:
> >> ---
> >> libavcodec/x86/dct-test.c | 13 -
> >> 1 file
L'octidi 18 vendémiaire, an CCXXIV, Alex Agranovsky a écrit :
> Thanks for your comments. I’m attaching the amended patch, hopefully it
> addresses all of them. Please let me know if something else is out of
> order.
Thanks, I was about to apply, after fixing myself very minor details
(trailing
Le septidi 17 vendémiaire, an CCXXIV, Rodger Combs a écrit :
> ---
> libavformat/tee.c | 43 ++-
> 1 file changed, 2 insertions(+), 41 deletions(-)
LGTM, thanks for taking care of it.
Did you read this patch:
2015.10.10. 16:11 keltezéssel, Bodecs Bela írta:
Dear All,
using tee pseudo muxer I faced an issue.
During applying bit stream filters, when the main packet data buffer
is changed, filter_packet function uses a temporary new packet
(new_pkt) to store that buffer, frees the original packet
Hi — are there still outstanding issues with the patch, or is it good to go?
Thanks,
- Alex
On October 9, 2015 at 8:57:22 AM, Alex Agranovsky (a...@sighthound.com) wrote:
Thanks for your comments. I’m attaching the amended patch, hopefully it
addresses all of them. Please let me know if
On Tue, Oct 6, 2015 at 9:59 PM, Ronald S. Bultje wrote:
> +cglobal vp9_idct_idct_4x4_add_12, 4, 4, 6, dst, stride, block, eob
[...]
> +movdm0, coefd
> +punpcklwd m0, m0
> +pshufd m0, m0, q
pshuflw + punpcklqdq is faster
On Sat, Oct 10, 2015 at 9:39 AM, Ganesh Ajjanagadde
wrote:
> During a build, a lot of *.o.-hash files are created - had not noticed
> this as they are usually dumped in tmpfs on Linux. However, they
> sometimes are present during a long build in the project directory,
On Sat, Oct 10, 2015 at 06:22:38PM +0200, Christophe Gisquet wrote:
> 2015-10-10 13:12 GMT+02:00 Michael Niedermayer :
> > this breaks testing the (i)dcts with other bits than 8 bits
> >
> > example:
> > libavcodec/dct-test 0 9
> > libavcodec/dct-test -i 0 9
>
> OK, I
On Fri, Oct 09, 2015 at 07:00:44PM +0200, Nicolas George wrote:
> L'octidi 18 vendémiaire, an CCXXIV, Jean-Baptiste Kempf a écrit :
> > > +HEADERS-$(CONFIG_JNI) += jni.h
> > You are going to install a jni.h header?
>
> I am not very fond of having java-related stuff in FFmpeg,
On Sat, Oct 10, 2015 at 12:48:08PM -0400, Ganesh Ajjanagadde wrote:
> Proper names should be capitalized in all user facing API as far as
> possible. The option names themselves have not been changed since:
> 1. We consistently keep option names in lower case.
> 2. Changing them would break
On October 10, 2015 at 1:10:25 PM, Nicolas George (geo...@nsup.org) wrote:
Thanks, I was about to apply, after fixing myself very minor details
(trailing spaces, >80 chars lines in the doc and H:M:S -> HH:MM::SS), but I
noticed that your patch is missing the "Signed-Off" tag; we have not been
On Sat, Oct 10, 2015 at 7:14 PM, Michael Niedermayer
wrote:
> On Sat, Oct 10, 2015 at 11:32:06PM +0200, Henrik Gramner wrote:
>> On Sat, Oct 10, 2015 at 11:06 PM, Ganesh Ajjanagadde
>> wrote:
>> > This uses Stein's binary GCD algorithm:
>> >
On Sat, Oct 10, 2015 at 8:22 PM, Michael Niedermayer
wrote:
> On Sun, Oct 11, 2015 at 02:13:59AM +0200, Michael Niedermayer wrote:
>> On Sat, Oct 10, 2015 at 07:45:17PM -0400, Ganesh Ajjanagadde wrote:
>> > On Sat, Oct 10, 2015 at 7:14 PM, Michael Niedermayer
>> >
---
libavcodec/samidec.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/libavcodec/samidec.c b/libavcodec/samidec.c
index 95f35ab..8dd2749 100644
--- a/libavcodec/samidec.c
+++ b/libavcodec/samidec.c
@@ -46,6 +46,7 @@ static int
On Sat, Oct 10, 2015 at 6:10 PM, James Darnley wrote:
> On 2015-10-10 23:06, Ganesh Ajjanagadde wrote:
>> ...
>
> Is the greatest common denominator (yes, I had to look that up) actually
> used anywhere that is slow and needs to be fast?
>
> All the uses of 'av_gcd' found
Signed-off-by: James Almer
---
libavfilter/x86/vf_w3fdif.asm | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/libavfilter/x86/vf_w3fdif.asm b/libavfilter/x86/vf_w3fdif.asm
index f02319b..f2001a4 100644
--- a/libavfilter/x86/vf_w3fdif.asm
+++
Hi all,
Turns out that the De-Bruijn method can be used to speed up av_ctz as
well. But before going about it, I was curious as to why such an
interface is actually public. It makes absolutely zero sense to me:
usage is limited exactly to one location, namely libavcodec/flacenc.c.
Was this an
hex_to_data should probably move to lavu before this is merged.
This is probably a good case for sub_charenc to run _after_ the decoder.
I could see an argument that this should go in the demuxer instead. Thoughts?
---
libavcodec/samidec.c | 78
On Sat, Oct 10, 2015 at 11:32:06PM +0200, Henrik Gramner wrote:
> On Sat, Oct 10, 2015 at 11:06 PM, Ganesh Ajjanagadde
> wrote:
> > This uses Stein's binary GCD algorithm:
> > https://en.wikipedia.org/wiki/Binary_GCD_algorithm
> > to get a reported 1.7-2.1x speedup over
On Sun, Oct 11, 2015 at 02:13:59AM +0200, Michael Niedermayer wrote:
> On Sat, Oct 10, 2015 at 07:45:17PM -0400, Ganesh Ajjanagadde wrote:
> > On Sat, Oct 10, 2015 at 7:14 PM, Michael Niedermayer
> > wrote:
> > > On Sat, Oct 10, 2015 at 11:32:06PM +0200, Henrik Gramner
On Sat, Oct 10, 2015 at 8:13 PM, Michael Niedermayer
wrote:
> On Sat, Oct 10, 2015 at 07:45:17PM -0400, Ganesh Ajjanagadde wrote:
>> On Sat, Oct 10, 2015 at 7:14 PM, Michael Niedermayer
>> wrote:
>> > On Sat, Oct 10, 2015 at 11:32:06PM +0200,
On Sat, Oct 10, 2015 at 8:37 PM, Ganesh Ajjanagadde wrote:
> On Sat, Oct 10, 2015 at 8:34 PM, Ganesh Ajjanagadde wrote:
>> On Sat, Oct 10, 2015 at 8:22 PM, Michael Niedermayer
>> wrote:
>>> On Sun, Oct 11, 2015 at 02:13:59AM +0200,
Hi,
On Sat, Oct 10, 2015 at 6:07 PM, Ganesh Ajjanagadde
wrote:
> On Sat, Oct 10, 2015 at 5:45 PM, Ganesh Ajjanagadde
> wrote:
> > On Sat, Oct 10, 2015 at 5:32 PM, Henrik Gramner
> wrote:
> >> On Sat, Oct 10, 2015 at 11:06 PM, Ganesh
On Sat, Oct 10, 2015 at 11:32:06PM +0200, Henrik Gramner wrote:
> On Sat, Oct 10, 2015 at 11:06 PM, Ganesh Ajjanagadde
> wrote:
> > This uses Stein's binary GCD algorithm:
> > https://en.wikipedia.org/wiki/Binary_GCD_algorithm
> > to get a reported 1.7-2.1x speedup over
On Sat, Oct 10, 2015 at 8:34 PM, Ganesh Ajjanagadde wrote:
> On Sat, Oct 10, 2015 at 8:22 PM, Michael Niedermayer
> wrote:
>> On Sun, Oct 11, 2015 at 02:13:59AM +0200, Michael Niedermayer wrote:
>>> On Sat, Oct 10, 2015 at 07:45:17PM -0400, Ganesh
On Sat, Oct 10, 2015 at 5:32 PM, Henrik Gramner wrote:
> On Sat, Oct 10, 2015 at 11:06 PM, Ganesh Ajjanagadde
> wrote:
>> This uses Stein's binary GCD algorithm:
>> https://en.wikipedia.org/wiki/Binary_GCD_algorithm
>> to get a reported 1.7-2.1x
On Sat, Oct 10, 2015 at 5:45 PM, Ganesh Ajjanagadde wrote:
> On Sat, Oct 10, 2015 at 5:32 PM, Henrik Gramner wrote:
>> On Sat, Oct 10, 2015 at 11:06 PM, Ganesh Ajjanagadde
>> wrote:
>>> This uses Stein's binary GCD algorithm:
>>>
On Sun, Oct 11, 2015 at 12:10:39AM +0200, James Darnley wrote:
> On 2015-10-10 23:06, Ganesh Ajjanagadde wrote:
> > ...
>
> Is the greatest common denominator (yes, I had to look that up) actually
> used anywhere that is slow and needs to be fast?
>
> All the uses of 'av_gcd' found by grep
On 2015-10-10 23:06, Ganesh Ajjanagadde wrote:
> ...
Is the greatest common denominator (yes, I had to look that up) actually
used anywhere that is slow and needs to be fast?
All the uses of 'av_gcd' found by grep appear be dealing with timing. I
see framerate, timebase, scale. I do see uses
On Sat, Oct 10, 2015 at 07:45:17PM -0400, Ganesh Ajjanagadde wrote:
> On Sat, Oct 10, 2015 at 7:14 PM, Michael Niedermayer
> wrote:
> > On Sat, Oct 10, 2015 at 11:32:06PM +0200, Henrik Gramner wrote:
> >> On Sat, Oct 10, 2015 at 11:06 PM, Ganesh Ajjanagadde
> >>
This uses Stein's binary GCD algorithm:
https://en.wikipedia.org/wiki/Binary_GCD_algorithm
to get a reported 1.7-2.1x speedup over Euclidean GCD on standard architectures.
Have not benchmarked, so I can't comment.
Note that there may be some room for optimization of the bit operations.
Quick note
On Sat, Oct 10, 2015 at 11:06 PM, Ganesh Ajjanagadde
wrote:
> This uses Stein's binary GCD algorithm:
> https://en.wikipedia.org/wiki/Binary_GCD_algorithm
> to get a reported 1.7-2.1x speedup over Euclidean GCD on standard
> architectures.
> Have not benchmarked, so I
On Sun, Oct 11, 2015 at 01:14:27AM +0200, Michael Niedermayer wrote:
> On Sat, Oct 10, 2015 at 11:32:06PM +0200, Henrik Gramner wrote:
> > On Sat, Oct 10, 2015 at 11:06 PM, Ganesh Ajjanagadde
> > wrote:
> > > This uses Stein's binary GCD algorithm:
> > >
This uses Stein's binary GCD algorithm:
https://en.wikipedia.org/wiki/Binary_GCD_algorithm
to get a roughly 4x speedup over Euclidean GCD on standard architectures
with a compiler intrinsic for ctzll, and a roughly 2x speedup otherwise.
At the moment, the compiler intrinsic is used on GCC and
On 10/10/2015 11:44 PM, Ganesh Ajjanagadde wrote:
> Hi all,
>
> Turns out that the De-Bruijn method can be used to speed up av_ctz as
> well. But before going about it, I was curious as to why such an
> interface is actually public. It makes absolutely zero sense to me:
> usage is limited exactly
On Sat, Oct 10, 2015 at 09:58:47PM -0400, Ganesh Ajjanagadde wrote:
> This uses Stein's binary GCD algorithm:
> https://en.wikipedia.org/wiki/Binary_GCD_algorithm
> to get a roughly 4x speedup over Euclidean GCD on standard architectures
> with a compiler intrinsic for ctzll, and a roughly 2x
On Wed, Oct 7, 2015 at 5:39 PM, Derek Buitenhuis
wrote:
> This becomes unuseful in the following commit.
>
> This reverts commit 092d1977cc7146f20c8db2155e7d648afb300de7.
>
> Signed-off-by: Derek Buitenhuis
> ---
> libavcodec/Makefile
On Wed, Oct 7, 2015 at 5:39 PM, Derek Buitenhuis
wrote:
> From: Anton Khirnov
>
> There's not much reason to generate such a small table at runtime.
>
> Signed-off-by: Derek Buitenhuis
> ---
> libavcodec/cabac.c
On Wed, Oct 7, 2015 at 6:29 PM, 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+,
從我的 iPhone 傳送壓縮啊啊轉
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Le decadi 30 fructidor, an CCXXIII, Michael Niedermayer a écrit :
> ffmpeg | branch: master | Michael Niedermayer | Wed
> Sep 16 01:39:18 2015 +0200| [3496a20bb92570aaa82849f0d5409f2e29fe2d2b] |
> committer: Michael Niedermayer
>
> avformat/flvdec: Change packet loop to
> Could you please fix it?
>
> Thanks
>
> Best regards
curl
https://github.com/BtbN/FFmpeg/commit/29294c283a656cf809461cbae21d612b5a0f2159.patch
| git apply
That works for me, the patch is not in git format-patch format, so git
am can't apply it.
I also attached the two patches in
av_fifo_generic_write() does not return any error code.
---
libavformat/async.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/libavformat/async.c b/libavformat/async.c
index a01673d..9172f5d 100644
--- a/libavformat/async.c
+++
---
libavformat/async.c | 41 +
tests/ref/fate/async | 2 ++
2 files changed, 43 insertions(+)
diff --git a/libavformat/async.c b/libavformat/async.c
index 9172f5d..a8c8f54 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -387,6 +387,9 @@
On Fri, Oct 09, 2015 at 11:53:44PM +0200, Christophe Gisquet wrote:
> ---
> libavcodec/arm/dct-test.c | 10 --
> libavcodec/dct-test.c | 41 +++--
> libavcodec/ppc/dct-test.c | 10 --
> libavcodec/x86/dct-test.c | 9 +++--
> 4 files
Michael Niedermayer niedermayer.cc> writes:
> ill make 2.8.1 soon from release/2.8
I backported a few regression fixes into 2.8.
The following tickets look like regressions
wrt 2.7:
https://trac.ffmpeg.org/ticket/4881
https://trac.ffmpeg.org/ticket/4899
https://trac.ffmpeg.org/ticket/4903
On 2015-10-10 00:43, Ganesh Ajjanagadde wrote:
> During a build, a lot of *.o-hash files are created - had not noticed
> this as they are usually dumped in tmpfs on Linux. However, they
> sometimes are present during a long build in the project directory, making it
> annoying to commit while the
On 2015-10-09 14:46, Nicolas George wrote:
> Le quartidi 4 vendémiaire, an CCXXIV, James Darnley a écrit :
>> I can. You should find it attached to this email. I cleaned it up and
>> put two test cases of data into the file. You will need Lua and the
>> Lua-iconv module. If your package
On Fri, Oct 09, 2015 at 11:53:45PM +0200, Christophe Gisquet wrote:
> ---
> libavcodec/x86/dct-test.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
with this patch
libavcodec/dct-test -i 0 10
end in "Error: 1." after testing SIMPLE10-C
libavcodec/dct-test 0 10
tests
On Fri, Oct 09, 2015 at 11:53:40PM +0200, Christophe Gisquet wrote:
> Modeled from the prores version. Clips to [0;1023] and is bitexact.
> Bitexactness requires to add an offset in a different place compared
> to prores or C, and makes the function approximately 2% slower.
>
> For 16 frames of a
On Sat, Oct 10, 2015 at 7:40 AM, James Darnley wrote:
> On 2015-10-10 00:43, Ganesh Ajjanagadde wrote:
>> During a build, a lot of *.o-hash files are created - had not noticed
>> this as they are usually dumped in tmpfs on Linux. However, they
>> sometimes are present
Hi
On Sat, Oct 10, 2015 at 09:43:55AM +0200, Luca Barbato wrote:
> ffmpeg | branch: master | Luca Barbato | Mon Oct 5
> 20:49:55 2015 +0200| [8b830ee9a26d47b138f12a82085cdb372f407f1e] | committer:
> Luca Barbato
>
> avconv: Do not try to configure filter outputs without
Similar to 33fefdb44.
Fix trac ticket #4921.
Signed-off-by: Nicolas George
---
libavformat/tee.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/tee.c b/libavformat/tee.c
index c619eae..a86952b 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -403,6
This uses the av_warn_unused_result attribute liberally to catch some forms of
improper
usage of functions defined in avfilter/formats.h.
Signed-off-by: Ganesh Ajjanagadde
---
libavfilter/formats.h | 9 +
1 file changed, 9 insertions(+)
diff --git
On Sat, Oct 10, 2015 at 9:19 AM, Nicolas George wrote:
> Similar to 33fefdb44.
> Fix trac ticket #4921.
>
> Signed-off-by: Nicolas George
> ---
> libavformat/tee.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/tee.c b/libavformat/tee.c
On Sat, Oct 10, 2015 at 9:18 AM, Michael Niedermayer
wrote:
> Hi
>
> On Sat, Oct 10, 2015 at 09:43:55AM +0200, Luca Barbato wrote:
>> ffmpeg | branch: master | Luca Barbato | Mon Oct 5
>> 20:49:55 2015 +0200|
Hi all,
Once again, apologies for sending patch as an attachment, gmail smtp
sendmail is still broken.
The patch uses Nicolas's ideas to achieve a substantial improvement in
readability.
Regards,
Ganesh
From 64f45a7938c8e34dbbd77110fea3f19a78e77c78 Mon Sep 17 00:00:00 2001
From: Ganesh
On Fri, Oct 09, 2015 at 03:59:04PM -0400, Ganesh Ajjanagadde wrote:
> This should fix the undefined behavior reported in:
> https://trac.ffmpeg.org/ticket/4727.
>
> I can reproduce this at runtime: simply stick in an abort call in
> asym_quant to check if c < 0 and run FATE. I don't know ac3 so I
On Sat, Oct 10, 2015 at 09:34:21AM -0400, Ganesh Ajjanagadde wrote:
[...]
> diff --git a/libavfilter/vsrc_life.c b/libavfilter/vsrc_life.c
> index 314746d..0e31ef7 100644
> --- a/libavfilter/vsrc_life.c
> +++ b/libavfilter/vsrc_life.c
> @@ -417,6 +417,7 @@ static int query_formats(AVFilterContext
During a build, a lot of *.o.-hash files are created - had not noticed
this as they are usually dumped in tmpfs on Linux. However, they
sometimes are present during a long build in the project directory, making it
annoying to commit while the project is being built.
These have been observed with
On Sat, Oct 10, 2015 at 9:10 AM, Ganesh Ajjanagadde wrote:
> On Sat, Oct 10, 2015 at 7:40 AM, James Darnley
> wrote:
>> On 2015-10-10 00:43, Ganesh Ajjanagadde wrote:
>>> During a build, a lot of *.o-hash files are created - had not noticed
>>> this as
On Sat, Oct 10, 2015 at 9:40 AM, Clément Bœsch wrote:
> On Sat, Oct 10, 2015 at 09:34:21AM -0400, Ganesh Ajjanagadde wrote:
> [...]
>> diff --git a/libavfilter/vsrc_life.c b/libavfilter/vsrc_life.c
>> index 314746d..0e31ef7 100644
>> --- a/libavfilter/vsrc_life.c
>> +++
Le nonidi 19 vendémiaire, an CCXXIV, Clement Boesch a écrit :
> You could change that last function to return AVERROR(ENOMEM) in case a
> parameter is NULL, but that's weird semantic.
Since it is an internal function, it is not really a problem, and it makes
for nice simplifications.
Regards,
On date Thursday 2015-10-08 11:14:40 -0400, Ganesh Ajjanagadde encoded:
> On Thu, Oct 8, 2015 at 10:29 AM, Stefano Sabatini wrote:
> > On date Thursday 2015-10-08 09:01:04 -0400, Ganesh Ajjanagadde encoded:
> >> Signed-off-by: Ganesh Ajjanagadde
> >>
89 matches
Mail list logo