On 03/01/2016 08:14 AM, Mats Peterson wrote:
This patch set adds support for non-raw codecs that use a palette.
Try to do stream copy to and from avi with the files below:
QuickTime Animation (RLE):
https://drive.google.com/open?id=0B3_pEBoLs0faREo1SlRydmV1LU0
QuickTime Graphics (SMC):
https:/
Slightly more detailed doxy documentation.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From ffdd2d19cfe2f87e9a12601a3b809521af5fa89b Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Tue, 1 Mar 2016 09:38:37 +0100
Subject: [PATCH v3 5/5 v2] lavf/internal.h: Add declaration for ff_get_raw
ping
2016.02.23. 9:21 keltezéssel, Bodecs Bela írta:
ping
2016.02.17. 14:13 keltezéssel, Bodecs Bela írta:
2016.02.16. 10:42 keltezéssel, Nicolas George írta:
L'octidi 28 pluviôse, an CCXXIV, Bodecs Bela a écrit :
Do you have any suggestion for me what to do now?
Please give me a hint whe
Hi!
A user claims that not all (Solaris) systems have a sufficiently new msghdr
struct. Attached patch adds an additional check.
Please comment, Carl Eugen
diff --git a/configure b/configure
index 8491fa1..2831ce4 100755
--- a/configure
+++ b/configure
@@ -1929,6 +1929,7 @@ TYPES_LIST="
str
On Mon, Feb 29, 2016 at 07:37:35PM +0100, Paul B Mahol wrote:
> On 2/29/16, Clement Boesch wrote:
> > From: Clement Boesch
> >
> > ---
> > TODO: doc, bump, Changelog
> >
> > example: -vf bench=start,gradfun,format=rgba,hqx,bench=stop
>
> Nice, LGTM with documentation changes.
Added average/min/
On Monday 29 February 2016 01:44:13 pm Michael Niedermayer wrote:
> On Mon, Feb 29, 2016 at 11:52:24AM +0100, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached patch fixes ticket #5271 for me.
> >
> > Please comment, Carl Eugen
> >
> > mov.c |5 +
> > 1 file changed, 5 insertions(+)
> > ef0
---
Changelog| 1 +
configure| 10 +
libavcodec/Makefile | 5 +
libavcodec/allcodecs.c | 10 +-
libavcodec/audiotoolboxenc.c | 471 +++
libavcodec/version.h | 2 +-
6 files changed, 493 i
This series adds decoders and encoders based on OSX's AudioToolbox framework.
They may be faster than the native ones (particularly in cases where they can
be hardware-accelerated), the encoders are competitive on quality, and some
users may find them convenient from a licensing perspective.
ADPCM
---
Changelog| 1 +
configure| 24
libavcodec/Makefile | 14 ++
libavcodec/allcodecs.c | 14 ++
libavcodec/audiotoolboxdec.c | 334 +++
libavcodec/version.h | 2 +-
6 files changed, 3
Hi!
https://summerofcode.withgoogle.com/organizations/6504812191416320/
FFmpeg was accepted for GSoC 2016, thank you to everybody who
helped with the wiki page and / or added himself as a mentor!
If you have an idea for a doable, strictly defined project
that a student has a chance to finish,
Le nonidi 29 pluviôse, an CCXXIV, Bodecs Bela a écrit :
> I have checked the code where and when duration filled and made some
> reasoning about it.
> Duration value for input files has been populated some time after opening.
> (estimate_timings function in utils.c) And never again corrected or cal
Rodger Combs gmail.com> writes:
> This series adds decoders and encoders based on OSX's AudioToolbox
framework. They may be faster than the native ones (particularly in
> cases where they can be hardware-accelerated), the encoders are
> competitive on quality, and some
I think this is a great
On Mon, Feb 29, 2016 at 10:55:49AM +0100, Clément Bœsch wrote:
> From: Clément Bœsch
>
> ---
> Changes since latest version:
> - remove unused 32-bit path
> - make 16-bit path more accurate by mirroring the MMX code (still not
> bitexact)
> - the code as originally trying to process 2 lines at a
On Tue, Mar 01, 2016 at 10:57:57AM +0100, Nicolas George wrote:
> Le nonidi 29 pluviôse, an CCXXIV, Bodecs Bela a écrit :
> > I have checked the code where and when duration filled and made some
> > reasoning about it.
> > Duration value for input files has been populated some time after opening.
>
On Tue, Mar 01, 2016 at 10:32:55 +0100, Carl Eugen Hoyos wrote:
> A user claims that not all (Solaris) systems have a sufficiently new msghdr
> struct. Attached patch adds an additional check.
This disables the sctp protocol on those systems then? Probably fine,
but *searchengine* tells me that s
On Tue, Mar 01, 2016 at 01:40:53PM +0800, Rick Kern wrote:
> Autodetected by default. Encode using -codec:v vtenc.
[...]
> +static void set_async_error(VTEncContext *vtctx, int err)
> +{
> +BufNode *info;
> +
> +pthread_mutex_lock(&vtctx->lock);
> +
> +vtctx->async_error = err;
> +
> +
wm4 googlemail.com> writes:
> Adding dozens of small very specialized features leads to
> unmaintainable and unusable software, even if the change
> itself is inoffensive.
I don't think this is a "small" feature, I consider it a
very useful request.
I also wonder why it is "very specialized":
Moritz Barsnick gmx.net> writes:
> On Tue, Mar 01, 2016 at 10:32:55 +0100, Carl Eugen Hoyos wrote:
> > A user claims that not all (Solaris) systems have a sufficiently
> > new msghdr struct. Attached patch adds an additional check.
>
> This disables the sctp protocol on those systems then? Prob
On Tue, 1 Mar 2016 11:31:18 +0100
Michael Niedermayer wrote:
> On Tue, Mar 01, 2016 at 01:40:53PM +0800, Rick Kern wrote:
> > Autodetected by default. Encode using -codec:v vtenc.
> [...]
> > +static void set_async_error(VTEncContext *vtctx, int err)
> > +{
> > +BufNode *info;
> > +
> > +
On Tue, Mar 01, 2016 at 12:01:10 +, Carl Eugen Hoyos wrote:
> Which of the links you provided is related to msghdr?
Possibly only the first one. I assumed that CMSG_SPACE was related, but
that was my mind running amok.
It would be easier to see if we had the Solaris headers or a Solaris
insta
On 3/1/2016 3:21 AM, Ganesh Ajjanagadde wrote:
[...]
> ---
> libavcodec/aacenc_utils.h | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Cool. Looks like an obvious/easy win, assuming it's identical.
- Derek
___
ffmpeg-devel mailing list
ffmp
Hi,
On Tue, Mar 1, 2016 at 7:00 AM, Carl Eugen Hoyos wrote:
> wm4 googlemail.com> writes:
>
> > Adding dozens of small very specialized features leads to
> > unmaintainable and unusable software, even if the change
> > itself is inoffensive.
>
> I don't think this is a "small" feature, I consid
Ronald S. Bultje gmail.com> writes:
> > So how does this mechanism look like for the requested
> > use case?
>
> man ln.
As said, this is a completely ridiculous argument:
FFmpeg has always tried to provide new features, no
matter if other solutions existed or not.
Apart from the fact that ln
From: Shivraj Patil
For mips P5600/I6400 configure, assembler throws errors at check_inline_asm for
loongson2, loongson3 and mmi as the instructions opcode not supported on this
processor. Hence disabled loongson2, loongson3 and mmi in non loogson mips cpus.
Signed-off-by: Shivraj Patil
---
From: Shivraj Patil
For P5600 mips cpu, cpuflags="-march=p5600" sets mips32r5 by default.
Current configuration sets mips32r2 for p5600 cpu, hence ldflag check results
in,
error: '-mips32r2' conflicts with the other architecture options, which specify
a mips32r5 processor
Due to above error, m
On Tue, Mar 01, 2016 at 14:00:14 +0100, Moritz Barsnick wrote:
> Possibly only the first one. I assumed that CMSG_SPACE was related, but
> that was my mind running amok.
Actually, other sources hint that they are all related, defined as
X/Open Unix Extensions. And these need to be enabled under So
Hi,
On Tue, Mar 1, 2016 at 8:04 AM, Carl Eugen Hoyos wrote:
> Ronald S. Bultje gmail.com> writes:
>
> > > So how does this mechanism look like for the requested
> > > use case?
> >
> > man ln.
>
> As said, this is a completely ridiculous argument:
> FFmpeg has always tried to provide new featur
On Tue, 1 Mar 2016 11:31:18 +0100
Michael Niedermayer wrote:
> On Tue, Mar 01, 2016 at 01:40:53PM +0800, Rick Kern wrote:
> > Autodetected by default. Encode using -codec:v vtenc.
> [...]
> > +static void set_async_error(VTEncContext *vtctx, int err)
> > +{
> > +BufNode *info;
> > +
> > +
On 1 March 2016 at 03:21, Ganesh Ajjanagadde wrote:
> It makes no sense whatsoever to do this at each function call; we
> already have a table for this.
>
> Yields a 2x improvement in find_min_book (x86-64, Haswell+GCC):
> ffmpeg -i sin.flac -acodec aac -y sin.aac
> find_min_book
> old
> 605
On 3/1/16, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Mar 1, 2016 at 8:04 AM, Carl Eugen Hoyos wrote:
>
>> Ronald S. Bultje gmail.com> writes:
>>
>> > > So how does this mechanism look like for the requested
>> > > use case?
>> >
>> > man ln.
>>
>> As said, this is a completely ridiculous argumen
On Mon, Feb 29, 2016 at 7:00 PM, Ronald S. Bultje wrote:
>
> Do you have a sample+commandline to reproduce? The thing is, in all cases
> where we use this, only one thread writes to a specific progress[n]. Two
> threads may write to progress[], one per field, but one will write to
> progress[0] an
Hi,
On Mon, Feb 29, 2016 at 9:42 PM Rick Kern wrote:
> Autodetected by default. Encode using -codec:v vtenc.
>
> Signed-off-by: Rick Kern
> ---
> MAINTAINERS|1 +
> configure | 19 +
> libavcodec/Makefile|1 +
> libavcodec/allcodecs.c |1 +
> libavcod
Hi,
I have some remarks on this patch.
1. This patch is an alternative fix for the data races in the access
to frame progress values in ff_thread_report_progress and
ff_thread_await_progress. Between the two patches I submitted, I
prefer the first patch
(http://ffmpeg.org/pipermail/ffmpeg-devel/2
Hi,
On Tue, Mar 1, 2016 at 9:34 AM, Wan-Teh Chang
wrote:
> By the way, I'm also wondering why ff_thread_report_progress is
> sometimes called with progress[field] >= n? I saw it happen when I ran
> make fate-h264, but did not investigate it.
I don't know, which sample (test name) specifically?
On Tue, Mar 01, 2016 at 08:01:26AM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Mar 1, 2016 at 7:00 AM, Carl Eugen Hoyos wrote:
>
> > wm4 googlemail.com> writes:
> >
> > > Adding dozens of small very specialized features leads to
> > > unmaintainable and unusable software, even if the chang
On Tue, 01 Mar 2016 14:57:29 +
Timothy Gu wrote:
> Hi,
>
> On Mon, Feb 29, 2016 at 9:42 PM Rick Kern wrote:
>
> > Autodetected by default. Encode using -codec:v vtenc.
> >
> > Signed-off-by: Rick Kern
> > ---
> > MAINTAINERS|1 +
> > configure | 19 +
> > l
Hello
I've been working on assembly for the vc2 encoder and have reached an
impasse. My code results in very visible errors, very obvious vertical
streaks in the bottom-right half of the image and some low-frequency
effect (I think).
I cannot see the problem in my code so I need some fresh eyes
On Tue, Mar 01, 2016 at 11:11:36AM +0100, Clément Bœsch wrote:
> On Mon, Feb 29, 2016 at 10:55:49AM +0100, Clément Bœsch wrote:
> > From: Clément Bœsch
> >
> > ---
> > Changes since latest version:
> > - remove unused 32-bit path
> > - make 16-bit path more accurate by mirroring the MMX code (sti
On Tue, Mar 01, 2016 at 05:18:36PM +0100, Michael Niedermayer wrote:
> On Tue, Mar 01, 2016 at 11:11:36AM +0100, Clément Bœsch wrote:
> > On Mon, Feb 29, 2016 at 10:55:49AM +0100, Clément Bœsch wrote:
> > > From: Clément Bœsch
> > >
> > > ---
> > > Changes since latest version:
> > > - remove unu
From: Matthieu Bouron
---
libavcodec/mjpegdec.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index f41f3a5..1e83e88 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -614,6 +614,13 @@ unk_pixfmt:
return AVERROR_
Correct the order of the load/store operation and the memory barrier in
avpriv_atomic_int_get and avpriv_atomic_int_set.
Signed-off-by: Wan-Teh Chang
---
libavutil/atomic.c | 48
libavutil/atomic.h | 45
On Mon, Feb 29, 2016 at 10:40:02PM +0300, Pavel Nikiforov wrote:
> Hello !
>
> This patch enables background sending of UDP packets with specified delay.
> When sending packets without a delay some devices with small RX buffer
> ( MAG200 STB, for example) will drop tail packets in burst causing
>
Hi all,
This is my first patch. git send-mail did not work for me. Sending the
patch via gmail gui. Please review my patch.
Thank you,
NagaChaitanya Vellanki
0001-Add-test-for-avpriv_get_trc_function_from_trc-functi.patch
Description: Binary data
___
f
Hi,
I removed the ff_thread_report_progress and ff_thread_await_progress
changes from this patch. This patch now only changes
libavutil/atomic*. I also added some comments to libavutil/atomic.h to
describe how the acquire and release operations are intended to be
used.
While working on the commen
This fixes a data race warning by ThreadSanitizer.
FrameThreadContext.die is read by all the worker threads but is not
protected by any mutex. Move it to PerThreadContext so that each worker
thread reads its own copy of |die|, which can then be protected with
PerThreadContext.mutex.
Signed-off-by:
On Fri, Feb 26, 2016 at 12:14 PM, Ronald S. Bultje wrote:
>
> Is probably OK since it doesn't introduce new lock/unlock pairs, yes. We
> typically don't care about a few bytes of memory.
Hi Ronald,
I just signed off this patch and submitted it in
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-Mar
This has been often discussed, and everyone agreed it was a good idea.
Here are patches which add such an API, but without making proper use
of it yet.
wm4 (6):
lavu: improve documentation of some AVFrame functions
lavc: factor apply_param_change() AV_EF_EXPLODE handling
lavc: introduce a ne
Until now, the decoding API was restricted to outputting 0 or 1 frames
per input packet. It also enforces a somewhat rigid dataflow in general.
This new API seeks to relax these restrictions by decoupling input and
output. Instead of doing a single call on each decode step, which may
consume the p
---
libavutil/frame.h | 12
1 file changed, 12 insertions(+)
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 76a8123..2d6299b 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -591,6 +591,10 @@ void av_frame_free(AVFrame **frame);
* If src is not reference counted,
Remove the duplicated code for handling failure of apply_param_change().
---
libavcodec/utils.c | 34 +++---
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index f435588..86236f8 100644
--- a/libavcodec/utils.c
++
---
Unfortunately requires a hack to make FATE pass: ffmpeg.c will pass
a flush AVPacket (data/size are null) with the dts field set, and will
expect to get the dts back with the flushed frame. Should probably be
fixed somehow. I'm not even sure if this is valid API usage (with the
old API).
---
f
It's not practical to keep this with the new decode API.
---
ffmpeg.c | 7 ---
ffmpeg.h | 1 -
2 files changed, 8 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index d148588..f24ee41 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -2313,13 +2313,6 @@ static int process_input_packet(InputStream *ist,
---
I'm wondering if the ost->sync_opts++; and ost->frame_number++; lines
in do_video_out() should be moved into the loop.
---
ffmpeg.c | 71 +---
1 file changed, 46 insertions(+), 25 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index 5
Improve coverage by adding test.
NagaChaitanya Vellanki (1):
Add test for avpriv_get_trc_function_from_trc function
libavutil/Makefile | 1 +
libavutil/color_utils.c | 52 +
2 files changed, 53 insertions(+)
--
2.7.2
---
libavutil/Makefile | 1 +
libavutil/color_utils.c | 52 +
2 files changed, 53 insertions(+)
diff --git a/libavutil/Makefile b/libavutil/Makefile
index a4d79cd..934564f 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -176,6 +176
Hi Ronald,
On Fri, Feb 26, 2016 at 12:16 PM, Ronald S. Bultje wrote:
>
> This will be slower, right? Is this an actual issue? Like, can you point to
> cases like [1] (i.e. a real-world race condition with real-world
> consequences) that were fixed with your patch?
>
> Ronald
>
> https://blogs.gno
On Fri, Feb 26, 2016 at 05:36:40PM +0100, Matthieu Bouron wrote:
> On Fri, Feb 26, 2016 at 4:41 PM, Matthieu Bouron
> wrote:
>
> > On Mon, Feb 22, 2016 at 12:20:35PM +0100, Matthieu Bouron wrote:
> > > From: Matthieu Bouron
> > >
> >
>
> [...]
>
>
> >
> > Patch updated with the following diff
Hi,
On Tue, Mar 1, 2016 at 1:15 PM, Wan-Teh Chang
wrote:
> On Fri, Feb 26, 2016 at 12:14 PM, Ronald S. Bultje
> wrote:
> >
> > Is probably OK since it doesn't introduce new lock/unlock pairs, yes. We
> > typically don't care about a few bytes of memory.
>
> Hi Ronald,
>
> I just signed off this
On Tue, 1 Mar 2016 19:52:08 +0100
Matthieu Bouron wrote:
> On Fri, Feb 26, 2016 at 05:36:40PM +0100, Matthieu Bouron wrote:
> > On Fri, Feb 26, 2016 at 4:41 PM, Matthieu Bouron
> > wrote:
> >
> > > On Mon, Feb 22, 2016 at 12:20:35PM +0100, Matthieu Bouron wrote:
> > > > From: Matthieu Bouro
On Sat, Feb 27, 2016 at 04:28:43PM +0100, Michael Niedermayer wrote:
> On Fri, Feb 26, 2016 at 04:54:47PM +0100, Matthieu Bouron wrote:
> > On Tue, Feb 23, 2016 at 11:28:01AM +0100, wm4 wrote:
> > > On Tue, 23 Feb 2016 09:53:43 +0100
> > > Matthieu Bouron wrote:
> > >
> > > > On Mon, Feb 22, 2016
On Tue, Mar 01, 2016 at 07:56:30PM +0100, wm4 wrote:
> On Tue, 1 Mar 2016 19:52:08 +0100
> Matthieu Bouron wrote:
>
> > On Fri, Feb 26, 2016 at 05:36:40PM +0100, Matthieu Bouron wrote:
> > > On Fri, Feb 26, 2016 at 4:41 PM, Matthieu Bouron
> > >
> > > wrote:
> > >
> > > > On Mon, Feb 22, 201
On Tue, 1 Mar 2016 20:10:50 +0100
Matthieu Bouron wrote:
> On Tue, Mar 01, 2016 at 07:56:30PM +0100, wm4 wrote:
> > On Tue, 1 Mar 2016 19:52:08 +0100
> > Matthieu Bouron wrote:
> >
> > > On Fri, Feb 26, 2016 at 05:36:40PM +0100, Matthieu Bouron wrote:
> > > > On Fri, Feb 26, 2016 at 4:41 PM
On Mon, Feb 29, 2016 at 08:08:14PM -0800, Mark Harris wrote:
> ---
> libavformat/sdp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
https://tools.ietf.org/html/draft-ietf-payload-rtp-opus-11 uses "="
in the example
so ok and applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF
Hi,
On Tue, Mar 1, 2016 at 1:47 PM, Wan-Teh Chang
wrote:
> Hi Ronald,
>
> On Fri, Feb 26, 2016 at 12:16 PM, Ronald S. Bultje
> wrote:
> >
> > This will be slower, right? Is this an actual issue? Like, can you point
> to
> > cases like [1] (i.e. a real-world race condition with real-world
> > co
On Tue, Mar 01, 2016 at 08:13:48PM +0100, wm4 wrote:
> On Tue, 1 Mar 2016 20:10:50 +0100
> Matthieu Bouron wrote:
>
> > On Tue, Mar 01, 2016 at 07:56:30PM +0100, wm4 wrote:
> > > On Tue, 1 Mar 2016 19:52:08 +0100
> > > Matthieu Bouron wrote:
> > >
> > > > On Fri, Feb 26, 2016 at 05:36:40PM +0
On Tue, Mar 01, 2016 at 10:41:32AM -0800, NagaChaitanya Vellanki wrote:
> ---
> libavutil/Makefile | 1 +
> libavutil/color_utils.c | 52
> +
> 2 files changed, 53 insertions(+)
>
I'm afraid testing the result of a switch with an array has a
On Tue, Mar 01, 2016 at 08:24:27PM +0100, Matthieu Bouron wrote:
> On Tue, Mar 01, 2016 at 08:13:48PM +0100, wm4 wrote:
> > On Tue, 1 Mar 2016 20:10:50 +0100
> > Matthieu Bouron wrote:
> >
> > > On Tue, Mar 01, 2016 at 07:56:30PM +0100, wm4 wrote:
> > > > On Tue, 1 Mar 2016 19:52:08 +0100
> > > >
On Tue, 1 Mar 2016 20:33:14 +0100
Matthieu Bouron wrote:
> On Tue, Mar 01, 2016 at 08:24:27PM +0100, Matthieu Bouron wrote:
> > On Tue, Mar 01, 2016 at 08:13:48PM +0100, wm4 wrote:
> > > On Tue, 1 Mar 2016 20:10:50 +0100
> > > Matthieu Bouron wrote:
> > >
> > > > On Tue, Mar 01, 2016 at 07:
---
libavutil/Makefile | 1 +
libavutil/color_utils.c | 53 +
2 files changed, 54 insertions(+)
diff --git a/libavutil/Makefile b/libavutil/Makefile
index a4d79cd..934564f 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -176,6 +176
On 3/1/16, Matthieu Bouron wrote:
> From: Matthieu Bouron
>
> ---
> libavcodec/mjpegdec.c | 7 +++
> 1 file changed, 7 insertions(+)
>
probbably ok
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-dev
On Tue, Mar 01, 2016 at 08:38:04PM +0100, wm4 wrote:
> On Tue, 1 Mar 2016 20:33:14 +0100
> Matthieu Bouron wrote:
>
> > On Tue, Mar 01, 2016 at 08:24:27PM +0100, Matthieu Bouron wrote:
> > > On Tue, Mar 01, 2016 at 08:13:48PM +0100, wm4 wrote:
> > > > On Tue, 1 Mar 2016 20:10:50 +0100
> > > > M
On Tue, Mar 01, 2016 at 10:46:17AM +0100, Carl Eugen Hoyos wrote:
> On Monday 29 February 2016 01:44:13 pm Michael Niedermayer wrote:
> > On Mon, Feb 29, 2016 at 11:52:24AM +0100, Carl Eugen Hoyos wrote:
> > > Hi!
> > >
> > > Attached patch fixes ticket #5271 for me.
> > >
> > > Please comment, Car
On Tue, Mar 01, 2016 at 08:55:23PM +0100, Matthieu Bouron wrote:
> On Tue, Mar 01, 2016 at 08:38:04PM +0100, wm4 wrote:
> > On Tue, 1 Mar 2016 20:33:14 +0100
> > Matthieu Bouron wrote:
> >
> > > On Tue, Mar 01, 2016 at 08:24:27PM +0100, Matthieu Bouron wrote:
> > > > On Tue, Mar 01, 2016 at 08:13
On Tue, Mar 01, 2016 at 11:37:37AM -0800, NagaChaitanya Vellanki wrote:
> ---
> libavutil/Makefile | 1 +
> libavutil/color_utils.c | 53
> +
> 2 files changed, 54 insertions(+)
to test avpriv_get_trc_function_from_trc(), one could
for each i
On Tue, Mar 01, 2016 at 09:11:21PM +0100, Michael Niedermayer wrote:
> On Tue, Mar 01, 2016 at 11:37:37AM -0800, NagaChaitanya Vellanki wrote:
> > ---
> > libavutil/Makefile | 1 +
> > libavutil/color_utils.c | 53
> > +
> > 2 files changed, 5
On Tue, 1 Mar 2016 20:57:12 +0100
Matthieu Bouron wrote:
> On Tue, Mar 01, 2016 at 08:55:23PM +0100, Matthieu Bouron wrote:
> > On Tue, Mar 01, 2016 at 08:38:04PM +0100, wm4 wrote:
> > > On Tue, 1 Mar 2016 20:33:14 +0100
> > > Matthieu Bouron wrote:
> > >
> > > > On Tue, Mar 01, 2016 at 08:
Hi,
On Tue, Mar 1, 2016 at 10:26 AM, Wan-Teh Chang wrote:
> I'd like to reiterate that this is difficult for many good
> programmers.
I think you just hit the nail right on the head :). I think my personal
problem is that I don't quite understand what the actual problem is (your
wiki page on m
On Tue, Mar 01, 2016 at 07:21:37PM +0100, wm4 wrote:
> Remove the duplicated code for handling failure of apply_param_change().
> ---
> libavcodec/utils.c | 34 +++---
> 1 file changed, 19 insertions(+), 15 deletions(-)
LGTM
thanks
[...]
--
Michael GnuPG fingerp
I cannot see any point whatsoever to use
double here instead of float.
Using float allows for use of SIMD.
---
libavcodec/aacenc_utils.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/aacenc_utils.h b/libavcodec/aacenc_utils.h
index cb5bc8d..571b1e6 100644
---
On Tue, Mar 01, 2016 at 08:01:45PM +0100, Matthieu Bouron wrote:
> On Sat, Feb 27, 2016 at 04:28:43PM +0100, Michael Niedermayer wrote:
> > On Fri, Feb 26, 2016 at 04:54:47PM +0100, Matthieu Bouron wrote:
> > > On Tue, Feb 23, 2016 at 11:28:01AM +0100, wm4 wrote:
> > > > On Tue, 23 Feb 2016 09:53:4
On Tue, Mar 01, 2016 at 06:41:17PM +0530, shivraj.pa...@imgtec.com wrote:
> From: Shivraj Patil
>
> For mips P5600/I6400 configure, assembler throws errors at check_inline_asm
> for loongson2, loongson3 and mmi as the instructions opcode not supported on
> this processor. Hence disabled loongso
On Tue, Mar 01, 2016 at 06:41:18PM +0530, shivraj.pa...@imgtec.com wrote:
> From: Shivraj Patil
>
> For P5600 mips cpu, cpuflags="-march=p5600" sets mips32r5 by default.
> Current configuration sets mips32r2 for p5600 cpu, hence ldflag check results
> in,
> error: '-mips32r2' conflicts with the
Avoids trashing the CPU cache each time the
cost cache is cleared.
---
libavcodec/aaccoder_twoloop.h | 20
libavcodec/aacenc.c | 7 +--
libavcodec/aacenc.h | 4 +---
libavcodec/aacenc_quantization_misc.h | 17 +++--
On Tue, Mar 1, 2016 at 7:44 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Mar 1, 2016 at 9:34 AM, Wan-Teh Chang
> wrote:
>
>> By the way, I'm also wondering why ff_thread_report_progress is
>> sometimes called with progress[field] >= n? I saw it happen when I ran
>> make fate-h264, but did not in
Michael Niedermayer niedermayer.cc> writes:
> > New patch attached.
> >
> > Please comment, Carl Eugen
>
> probably ok
Patch applied.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffm
On Mon, Feb 29, 2016 at 09:37:51PM +0100, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/seek-test.c |2 ++
> 1 file changed, 2 insertions(+)
applied
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Its not that you shou
On Mon, Feb 29, 2016 at 09:36:55PM +0100, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> tests/fate/seek.mak |2 ++
> tests/ref/seek/cache-pipe | 49
> +
> 2 files changed, 51 insertions(+)
> create mode 100644 tes
Michael Niedermayer niedermayer.cc> writes:
> and ffmpeg supports alot more than files, one could want to do
>
> -reverse 1 -i http://foobar.com/image%d.jpeg
This patch is unrelated to demuxing, it is meant
to implement:
$ ffmpeg -i input -reverse 1 -start_number xyz out%3d.jpg
Carl Eugen
__
Hopefully the last version of the patch set.
Try to do stream copy to and from avi/mov with the files below:
QuickTime Animation (RLE):
https://drive.google.com/open?id=0B3_pEBoLs0faREo1SlRydmV1LU0
QuickTime Graphics (SMC):
https://drive.google.com/open?id=0B3_pEBoLs0faODd5RVBldkdvVGc
Microsof
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From e4246cb978aa165cf2c1b51e62a97733398f5149 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Wed, 2 Mar 2016 03:12:17 +0100
Subject: [PATCH v4 2/5] lavf/movenc: Add support for palette side data packets
---
libavformat/movenc.c | 45
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From bb8b4c33f782d8c121a0575c5175739036906d27 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Wed, 2 Mar 2016 03:13:14 +0100
Subject: [PATCH v4 3/5] lavf/riffenc: Handle palette for non-raw codecs
---
libavformat/riffenc.c | 20 ++
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 403d4db37d2690a8263db53b28225409eeb9bb8c Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Wed, 2 Mar 2016 03:14:05 +0100
Subject: [PATCH v4 4/5] lavf/utils: New function ff_get_packet_palette()
---
libavformat/utils.c | 16 +++
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 0fab64e2c08519302c3b44ae53ab01cfb3322812 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Wed, 2 Mar 2016 03:14:34 +0100
Subject: [PATCH v4 5/5] lavf/internals.h: Add declaration for ff_get_packet_palette()
---
libavformat/internal.h |
Hi all,
This is my first patch. git send-mail did not work for me. Sending the
patch via gmail gui. Please review my patch.
Thank you,
NagaChaitanya Vellanki
0001-Add-test-for-avpriv_get_trc_function_from_trc-functi.patch
Description: Binary data
___
f
On Tue, Mar 1, 2016 at 6:34 PM, Reimar Döffinger
wrote:
> Avoids trashing the CPU cache each time the
> cost cache is cleared.
Just curious as to roughly the magnitude of perf improvement? No
comments on the patch itself.
[...]
___
ffmpeg-devel mailing
On Tue, Mar 1, 2016 at 9:17 AM, Paul B Mahol wrote:
> On 3/1/16, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Tue, Mar 1, 2016 at 8:04 AM, Carl Eugen Hoyos wrote:
>>
>>> Ronald S. Bultje gmail.com> writes:
>>>
>>> > > So how does this mechanism look like for the requested
>>> > > use case?
>>> >
>>>
On Tue, Mar 1, 2016 at 4:55 PM, Reimar Döffinger
wrote:
> I cannot see any point whatsoever to use
> double here instead of float.
There can be some negligible accuracy differences, but I do not see
any harm myself; aac anyway sticks to floats in most places.
> Using float allows for use of SIMD
On Tue, Mar 1, 2016 at 7:52 AM, Derek Buitenhuis
wrote:
> On 3/1/2016 3:21 AM, Ganesh Ajjanagadde wrote:
>
> [...]
>
>> ---
>> libavcodec/aacenc_utils.h | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> Cool. Looks like an obvious/easy win, assuming it's identical.
They are not prec
On Tue, Mar 1, 2016 at 9:14 AM, Rostislav Pehlivanov
wrote:
> On 1 March 2016 at 03:21, Ganesh Ajjanagadde wrote:
>>
>> It makes no sense whatsoever to do this at each function call; we
>> already have a table for this.
>>
>> Yields a 2x improvement in find_min_book (x86-64, Haswell+GCC):
>> ffmp
I noticed that you, Paul, added a patch somewhere in 2012 with the
purpose of making it possible to use FLI(C) in AVI. It doesn't work very
well in my book. Try the following command with the file below:
ffmpeg -i 3DMORPH.FLI -vcodec copy 3dmorph.avi
File:
https://drive.google.com/open?id=0B3_
1 - 100 of 104 matches
Mail list logo
