I finally got it ... The explanation is in h264dsp_template.c (big bunch of
macro, yummy !)
De : ffmpeg-devel-boun...@ffmpeg.org ffmpeg-devel-boun...@ffmpeg.org de la
part de Nicolas Derouineau nicolas.derouin...@vitec.com
Envoyé : lundi 1 septembre 2014
On 9/2/14, Michael Niedermayer michae...@gmx.at wrote:
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/rawdec.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
index
+/* Rounding to zero used for simplicity */
+static av_always_inline aac_float_t float_add(aac_float_t a, aac_float_t b)
+{
+int diff;
+
+if (a.mant == 0)
+return b;
+
+if (b.mant == 0)
+return a;
+
+diff = a.expo - b.expo;
+
+if (diff 0) //
Add the feature test macro which is required for building with the
musl toolchain.
The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant
version of strerror_r().
Signed-off-by: Jörg Krause jkra...@posteo.de
---
libavutil/error.c | 1 +
1 file changed, 1 insertion(+)
diff
Add the feature test macro which is required for building with the
musl toolchain.
The required feature test macro is:
nanosleep(): _POSIX_C_SOURCE = 199309L
Signed-off-by: Jörg Krause jkra...@posteo.de
---
libavutil/time.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
On Tue, 2 Sep 2014 17:48:57 +0800
Diaz Soho soho123.2...@gmail.com wrote:
Hi All,
Is there anyone have idea about how to merge fixed point wma decoder
to libav 0.7.6?
because my cpu does not include fpu, when use the wma decoder in
libav , it take a lot of cpu time.
Or is anyone have
On Tue, Sep 02, 2014 at 12:33:26PM +0200, Jörg Krause wrote:
Add the feature test macro which is required for building with the
musl toolchain.
The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant
version of strerror_r().
is there a reason why you dont set it from
Add the feature test macro which is required for building with the
musl toolchain.
The required feature test macro is:
mkstemp(): _POSIX_C_SOURCE = 200112L
Signed-off-by: Jörg Krause jkra...@posteo.de
---
Changes v1 - v2:
- Fixed commit message
---
libavutil/file.c | 2 ++
1 file changed, 2
Hi
Its almost 2 Months since 2.3 and i assume people want a new release
from around the same time of when libav 11 will get released so expect
FFmpeg 2.4 to be released soon!
if you want something in it, now is the time to push/post it
if you want something fixed, now is the time to fix it
On Tue, Sep 02, 2014 at 08:44:47AM +, Paul B Mahol wrote:
On 9/2/14, Michael Niedermayer michae...@gmx.at wrote:
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/rawdec.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
This is currently not supported
Fixes part of Ticket 3539
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavformat/swfdec.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/libavformat/swfdec.c b/libavformat/swfdec.c
index ca2a1c4..528bc23 100644
On Tue, Sep 02, 2014 at 01:52:24PM +0200, Jörg Krause wrote:
Am 02.09.2014 12:40 schrieb Michael Niedermayer:
On Tue, Sep 02, 2014 at 12:33:26PM +0200, Jörg Krause wrote:
Add the feature test macro which is required for building with the
musl toolchain.
The feature test macro
Attached patch adds some whitespace when listing channel layouts with
the -layouts option.
== Output before patch ==
Individual channels:
NAMEDESCRIPTION
FL front left
FR front right
FC front center
[...]
Standard channel layouts:
NAMEDECOMPOSITION
On Tue, 2 Sep 2014 12:33:26 +0200
Jörg Krause jkra...@posteo.de wrote:
Add the feature test macro which is required for building with the
musl toolchain.
The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant
version of strerror_r().
Signed-off-by: Jörg Krause
Hi compn,
how about :
merging the fixed point decoders from rockbox has been on our todo list
for a while.
https://github.com/Rockbox/rockbox/tree/master/lib/rbcodec/codecs
any idea
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Tue, Sep 02, 2014 at 08:05:56AM -0400, Marcus Johnson wrote:
Alright, probably a bad place to post this, but I made a few cosmetic
changes to the dts decoder, the first replaces the request_channels calls
with the request_channel_layout function, and the second removes the code
that
On Tue, Sep 02, 2014 at 05:13:08PM +0200, Pascal Massimino wrote:
Hi,
Much faster.
An example (time ffmpeg -i ... -vf idet -f null /dev/null)
Raw C: user 25.007s
MMX:user 16.818s
MMXEXT: user 16.191s
SSE2: user 15.481s
no idet filter: user 15.025s
YMMV.
skal
On Tue, Sep 02, 2014 at 05:04:31PM +0200, Tobias Rapp wrote:
Attached patch adds some whitespace when listing channel layouts
with the -layouts option.
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst form of inequality is to try to
On Tue, Sep 02, 2014 at 01:48:09AM +0200, Michael Niedermayer wrote:
On Mon, Sep 01, 2014 at 11:26:06PM +0200, Reimar Döffinger wrote:
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
libavcodec/rangecoder.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
LGTM
On Tue, Sep 02, 2014 at 01:54:38AM +0200, Michael Niedermayer wrote:
On Mon, Sep 01, 2014 at 11:36:52PM +0200, Reimar Döffinger wrote:
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
libavfilter/deshake.h| 3 +++
libavfilter/vf_deshake.c | 13 +
2 files
On Tue, Sep 02, 2014 at 01:55:20AM +0200, Michael Niedermayer wrote:
On Mon, Sep 01, 2014 at 11:49:28PM +0200, Reimar Döffinger wrote:
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
libavfilter/deshake.h| 2 ++
libavfilter/vf_deshake.c | 10 ++
2 files
On Tue, Sep 02, 2014 at 04:42:09PM +0530, Parth Shah wrote:
My question is why this timestamps gets changed? Is thereant method to send
MP4 file over socket without changing its timestamp?
Any help or advice? Thank you in advance.
This belongs on ffmpeg-user.
Plus, I'd suggest
Use the UTF-16 BOM to detect UTF-16 encoding. Convert the file contents
to UTF-8 on the fly using FFTextReader, which acts as converting wrapper
around AVIOContext. It also can work on a static buffer, needed for
format probing. The FFTextReader wrapper now also takes care of skipping
the UTF-8
ff_smil_extract_next_chunk() is still used by RealText.
---
libavformat/samidec.c | 17 ++---
libavformat/subtitles.c | 15 ---
libavformat/subtitles.h | 5 +
3 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/libavformat/samidec.c
Ideally the compiler could figure this out on its own,
but it seems it can't.
An alternative that would avoid the messy explicit memcpy
would be to use a sub-struct for the parts that should
be preserved, which can then simply be assigned.
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
On Tue, 2 Sep 2014 20:32:57 +0200
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
A bit more complex than e.g. adding it to the context, but
using the context for something that will be used only during
initialization seemed a bit wasteful.
Signed-off-by: Reimar Döffinger
On Tue, Sep 02, 2014 at 07:41:40PM +0200, Reimar Döffinger wrote:
On Tue, Sep 02, 2014 at 05:03:56PM +0200, Michael Niedermayer wrote:
On Tue, Sep 02, 2014 at 01:52:24PM +0200, Jörg Krause wrote:
Am 02.09.2014 12:40 schrieb Michael Niedermayer:
On Tue, Sep 02, 2014 at 12:33:26PM
On Tue, Sep 02, 2014 at 08:56:09PM +0200, wm4 wrote:
Use the UTF-16 BOM to detect UTF-16 encoding. Convert the file contents
to UTF-8 on the fly using FFTextReader, which acts as converting wrapper
around AVIOContext. It also can work on a static buffer, needed for
format probing. The
On Tuesday, September 02, 2014 20:22:24 James Darnley wrote:
I am looking for someone with an XOP capable CPU to compile and run two
basic fate tests for me. All you have to do is:
- get the ffmpeg source from my git repo (link below)
- checkout the flac_enc_lpc branch: git checkout
On Tue, 2 Sep 2014 21:05:08 +0200
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
On Tue, Sep 02, 2014 at 08:56:09PM +0200, wm4 wrote:
Use the UTF-16 BOM to detect UTF-16 encoding. Convert the file contents
to UTF-8 on the fly using FFTextReader, which acts as converting wrapper
around
On Tue, Sep 02, 2014 at 08:58:50PM +0200, wm4 wrote:
On Tue, 2 Sep 2014 20:32:57 +0200
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
@@ -933,6 +938,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
}
}
}
+av_freep(best_state);
On Tue, 2 Sep 2014 21:18:24 +0200
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
On Tue, Sep 02, 2014 at 08:58:50PM +0200, wm4 wrote:
On Tue, 2 Sep 2014 20:32:57 +0200
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
@@ -933,6 +938,7 @@ static av_cold int encode_init(AVCodecContext
On Tue, Sep 02, 2014 at 09:28:27PM +0200, wm4 wrote:
On Tue, 2 Sep 2014 21:18:24 +0200
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
So I'd prefer to avoid it. However there is the question of which
code mess/benefit ratio we want to accept.
I don't see anything wrong in the patch
On Tue, Sep 02, 2014 at 08:32:57PM +0200, Reimar Döffinger wrote:
A bit more complex than e.g. adding it to the context, but
using the context for something that will be used only during
initialization seemed a bit wasteful.
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
LGTM
On Tue, Sep 02, 2014 at 09:28:27PM +0200, wm4 wrote:
I don't see anything wrong in the patch (well, maybe you should switch
the code to the goto fail; idiom). I was just wondering whether there
was a specific reason for this. Did it fail on a certain system?
Btw. while I did not test it, and
On Tue, 2 Sep 2014 21:54:36 +0200
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
On Tue, Sep 02, 2014 at 09:28:27PM +0200, wm4 wrote:
I don't see anything wrong in the patch (well, maybe you should switch
the code to the goto fail; idiom). I was just wondering whether there
was a
On Tue, Sep 02, 2014 at 09:54:31PM +0200, Gabriel Dume wrote:
ffmpeg | branch: master | Gabriel Dume gabriel.dd...@gmail.com | Mon Sep 1
15:18:57 2014 -0400| [74512f7e369da40e1148c92b58cd8e59f7737b8f] | committer:
Diego Biurrun
8svx: Return proper error codes
Signed-off-by: Diego
On Tue, Sep 02, 2014 at 08:56:09PM +0200, wm4 wrote:
Use the UTF-16 BOM to detect UTF-16 encoding. Convert the file contents
to UTF-8 on the fly using FFTextReader, which acts as converting wrapper
around AVIOContext. It also can work on a static buffer, needed for
format probing. The
The cropdetect filter is prone to reporting negative-sized rectangles,
particularly for dark images. This patch adjusts the limits of the
filter loops, preventing the left/right and top/bottom offsets from
crossing each other, so that such a zero-sized rectangle is reported
instead of a negative
On Tue, Sep 02, 2014 at 01:13:27PM -0700, Peter Kasting wrote:
On Sat, Aug 30, 2014 at 2:21 AM, wm4 nfx...@googlemail.com wrote:
I'd
expect it rather to hide bugs than to expose them. For example, it
could make a static analyzer with value range analysis stop working,
because the casts
On Tue, Sep 02, 2014 at 11:31:39PM +0200, Jörg Krause wrote:
The maintainers of the musl C library states that looking for __GLIBC__ or
__UCLIBC__ and making assumptions about the implemented feature set is not
the best way. Instead features.h should be inspected for the specification
of the
Hi!
Attached patch fixes ticket #3919 for me.
Please comment, Carl Eugen
diff --git a/ffprobe.c b/ffprobe.c
index 2d48070..34c7f1e 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -2170,6 +2170,7 @@ static int show_stream(WriterContext *w, AVFormatContext
*fmt_ctx, int stream_id
else
On Tue, Sep 02, 2014 at 08:56:10PM +0200, wm4 wrote:
---
libavformat/srtdec.c| 22 +++--
libavformat/subtitles.c | 51
+++--
libavformat/subtitles.h | 33 +---
3 files changed, 91 insertions(+), 15
Ideally the compiler could figure this out on its own,
but it seems it can't.
An alternative that would avoid the messy explicit memcpy
would be to use a sub-struct for the parts that should
be preserved, which can then simply be assigned.
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
libavcodec/huffyuvdec.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
index 1df77e0..d661328 100644
--- a/libavcodec/huffyuvdec.c
+++
On Tue, Sep 02, 2014 at 08:56:11PM +0200, wm4 wrote:
ff_smil_extract_next_chunk() is still used by RealText.
---
libavformat/samidec.c | 17 ++---
libavformat/subtitles.c | 15 ---
libavformat/subtitles.h | 5 +
3 files changed, 27 insertions(+), 10
On Fri, 29 Aug 2014 15:44:34 -0700
Peter Kasting pkast...@google.com wrote:
From 1c94e78d2b2037d492ea5abb3edb7960c8e98a1d Mon Sep 17 00:00:00 2001
From: Peter Kasting pkast...@google.com
Date: Fri, 29 Aug 2014 15:31:41 -0700
Subject: [PATCH] Fix MSVC warnings about possible value truncation.
* Remove Burek's builds
These have been halted since 16 July. Burek has been notified several
times, but I have recieved no response. Link will be re-added if
activity resumes.
* Add reference to 32-bit builds to relaxed's link
Thanks to relaxed for quickly volunteering to provide 32-bit builds,
On Tue, 2 Sep 2014 23:18:02 +0200
Clément Bœsch u...@pkh.me wrote:
On Tue, Sep 02, 2014 at 08:56:09PM +0200, wm4 wrote:
Use the UTF-16 BOM to detect UTF-16 encoding. Convert the file contents
to UTF-8 on the fly using FFTextReader, which acts as converting wrapper
around AVIOContext. It
On Wed, Sep 03, 2014 at 12:01:52AM +0200, Reimar Döffinger wrote:
Ideally the compiler could figure this out on its own,
but it seems it can't.
An alternative that would avoid the messy explicit memcpy
would be to use a sub-struct for the parts that should
be preserved, which can then simply
On Tue, 2 Sep 2014 23:54:51 +0200
Clément Bœsch u...@pkh.me wrote:
On Tue, Sep 02, 2014 at 08:56:10PM +0200, wm4 wrote:
---
libavformat/srtdec.c| 22 +++--
libavformat/subtitles.c | 51
+++--
libavformat/subtitles.h | 33
On Wed, 3 Sep 2014 00:03:04 +0200
Clément Bœsch u...@pkh.me wrote:
On Tue, Sep 02, 2014 at 08:56:11PM +0200, wm4 wrote:
ff_smil_extract_next_chunk() is still used by RealText.
---
libavformat/samidec.c | 17 ++---
libavformat/subtitles.c | 15 ---
On Tue, 2 Sep 2014 23:43:33 +0200
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
On Tue, Sep 02, 2014 at 01:13:27PM -0700, Peter Kasting wrote:
On Sat, Aug 30, 2014 at 2:21 AM, wm4 nfx...@googlemail.com wrote:
I'd
expect it rather to hide bugs than to expose them. For example, it
Michael,
On Tue, Sep 2, 2014 at 9:39 AM, Michael Niedermayer michae...@gmx.at
wrote:
On Tue, Sep 02, 2014 at 05:13:08PM +0200, Pascal Massimino wrote:
Hi,
Much faster.
An example (time ffmpeg -i ... -vf idet -f null /dev/null)
Raw C: user 25.007s
MMX:user 16.818s
On 2014-09-02 21:25, James Darnley wrote:
On 2014-09-02 20:39, Kelly Anderson wrote:
TESTacodec-flac-comp-5
TESTacodec-flac-24-comp-5
tests/Makefile:192: recipe for target 'fate-acodec-flac-24-comp-5' failed
make: *** [fate-acodec-flac-24-comp-5] Error 1
Thanks. Good to know
On Aug 31, 2014 3:16 PM, Lou Logan l...@lrcd.com wrote:
+@item ignore_loop
+GIF files can be set to loop infinitely or up to a certain number of
+times.
can contain information to loop...
Can be set sounds like settable from a ffmpeg command.
+
+If @option{ignore_loop} is set to 1, then
Patch not sent to ML so couldn't review:
Why have you only changed the code to favour DESC_types and not other types?
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi,
as discussed in IRC, I was trying to minimal-invasively port
libpostproc (the Debian source package) to x32¹. I could not
test it (for lack of a stand-alone test program) yet, but at
least I got it to build.
As requested, the patch I used is attached. It’s not optimal
as the arch could use
On Tue, Sep 02, 2014 at 10:03:39PM +0200, Clément Bœsch wrote:
On Tue, Sep 02, 2014 at 09:54:31PM +0200, Gabriel Dume wrote:
ffmpeg | branch: master | Gabriel Dume gabriel.dd...@gmail.com | Mon Sep
1 15:18:57 2014 -0400| [74512f7e369da40e1148c92b58cd8e59f7737b8f] |
committer: Diego
On Sep 2, 2014 5:31 PM, Lou Logan l...@lrcd.com wrote:
From d95991c4dd423cc4bc231510255f74dda600afbc Mon Sep 17 00:00:00 2001
From: Lou Logan l...@lrcd.com
Date: Thu, 28 Aug 2014 16:26:11 -0800
Subject: [PATCH] doc/demuxers: document gif demuxer
Signed-off-by: Lou Logan l...@lrcd.com
---
On Wed, Sep 03, 2014 at 12:25:17AM +0200, Reimar Döffinger wrote:
Code is only used during initialization, so malloc/free
should be fine to use.
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
libavcodec/vorbisenc.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
On 3 September 2014 01:40, Michael Niedermayer michae...@gmx.at wrote:
On Wed, Sep 03, 2014 at 12:59:53AM +0100, Kieran Kunhya wrote:
Patch not sent to ML so couldn't review:
Why have you only changed the code to favour DESC_types and not other types?
because thats what was needed to fix
On Wednesday, September 03, 2014 00:51:18 James Darnley wrote:
390c0dc
TESTacodec-flac-comp-5
TESTacodec-flac-24-comp-5
--- ./tests/ref/acodec/flac-24-comp-5 2014-09-02 12:35:11.678786719 -0600
+++ tests/data/fate/acodec-flac-24-comp-5 2014-09-02 19:25:14.73914
-0600
@@ -1,4
On Wed, Sep 03, 2014 at 04:24:29AM +0200, Michael Niedermayer wrote:
On Wed, Sep 03, 2014 at 02:37:48AM +0100, Kieran Kunhya wrote:
On 3 September 2014 01:40, Michael Niedermayer michae...@gmx.at wrote:
On Wed, Sep 03, 2014 at 12:59:53AM +0100, Kieran Kunhya wrote:
Patch not sent to ML so
On 03.09.2014, at 02:16, Peter Kasting pkast...@google.com wrote:
On Tue, Sep 2, 2014 at 5:10 PM, wm4 nfx...@googlemail.com wrote:
In the end, if we do decide to enable this warning, we will have to
insert
some casts that are clearly safe, e.g.
if (x INT_MAX)
return;
int y =
On 03.09.2014, at 06:28, Michael Niedermayer michae...@gmx.at wrote:
On Wed, Sep 03, 2014 at 12:01:54AM +0200, Reimar Döffinger wrote:
We only actually use a tiny part of it.
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
libswresample/rematrix.c | 7 ---
1 file changed, 4
66 matches
Mail list logo
