Hi,
On Sun, Dec 4, 2011 at 4:32 PM, Ronald S. Bultje rsbul...@gmail.com wrote:
Who made these up? Microsoft says this (P410 isn't in their list but can
easily be derived):
P010 planar YUV420 10-bit
P210 Planar YUV422 10-bit
P410 planar YUV444 10-bit
These formats are however not
Hi,
here is an updated patch, addressing the one problem Justin mentioned.
- Hendrik
0001-pcm-mpeg-implement-new-audio-decoding-api.patch
Description: Binary data
___
libav-devel mailing list
libav-devel@libav.org
Hi,
attached patch fixes a memory corruption when decoding WavPack 16-bit.
It is caused by the decoder being initialized as S16, and requesting a
buffer for that size, however when decoding the very first frame, the
type can actually change after the buffer was requested, causing it to
write
Hi,
attached patch fixes a small error in the VC-1 interlaced header parsing.
I started validating the VC-1 interlaced header parsing against the
spec and the reference decoder, and i found this mistake.
This change is consistent with both the spec and the reference decoder.
I also found a file
Hi,
attached patch fixes an inconsistency in the VC-1 interlaced fields
header parsing.
I validated the changes against the spec and the reference decoder,
and this does seem more correct.
I don't know if this actually affected any files, i couldn't find one,
but with the state of the VC-1
On 1/23/12, Mashiat Sarker Shakkhar shahriman_...@yahoo.com wrote:
Doesn't mach my copy of spec or the ref-code. BFRACTION is only present
in B-pictures, not P. My copy of ref-code says:
if(vc1_InterlacedField == pPosition-ePictureFormat)
{
if(TRUE ==
On Tue, Feb 11, 2014 at 8:52 AM, Niels Möller ni...@lysator.liu.se wrote:
A couple of questions:
* the libavcodec/dcadec.c file look a bit different in ffmpeg and libav,
and ffmpeg includes handling of the XXCH extension. I'm not yet
familiar enough with dca to say how related this is to
On Sun, Feb 16, 2014 at 4:06 PM, Alexandra Khirnova
alexandra.khirn...@gmail.com wrote:
---
libavformat/matroskaenc.c |3 ++-
libavformat/mux.c |5 +++--
libavformat/utils.c | 17 -
3 files changed, 17 insertions(+), 8 deletions(-)
Using
On Mon, Feb 17, 2014 at 12:06 AM, Vittorio Giovara
vittorio.giov...@gmail.com wrote:
On Sun, Feb 16, 2014 at 11:15 PM, Luca Barbato lu_z...@gentoo.org wrote:
On 16/02/14 23:08, Vittorio Giovara wrote:
---
This profile got dropped in 2005, I think it should be not listed as
supported profile.
On Mon, Feb 17, 2014 at 12:01 AM, Vittorio Giovara
vittorio.giov...@gmail.com wrote:
Also document origin of unknown profiles and
complete checks in ff_h264_decode_seq_parameter_set().
---
Revised patch, with added comments instead of removal.
Vittorio
libavcodec/h264.c | 10
On Tue, Feb 18, 2014 at 9:01 AM, Luca Barbato lu_z...@gentoo.org wrote:
On 18/02/14 03:37, Logan Y. Jeon wrote:
{ 0x24, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_HEVC },
+{ 0x27, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_HEVC },/* HEVC Video
for playing MPEG TS has stream_type 0x27 */
On Tue, Feb 18, 2014 at 9:36 AM, Luca Barbato lu_z...@gentoo.org wrote:
On 18/02/14 09:34, Hendrik Leppkes wrote:
0x24 is HEVC, 0x27 is for SHVC.
So would be more correct using 0x24 or better using 0x27 and be future
proof?
0x24 should definitely be written when muxing HEVC. 0x27
On Tue, Feb 18, 2014 at 4:43 PM, Tim Walker tdskywal...@gmail.com wrote:
On 18 Feb 2014, at 09:04, Luca Barbato lu_z...@gentoo.org wrote:
@@ -54,6 +54,7 @@
#define STREAM_TYPE_AUDIO_AAC 0x0f
#define STREAM_TYPE_VIDEO_MPEG4 0x10
#define STREAM_TYPE_VIDEO_H264 0x1b
+#define
On Tue, Feb 18, 2014 at 3:19 PM, Vittorio Giovara
vittorio.giov...@gmail.com wrote:
On Mon, Feb 17, 2014 at 8:38 AM, Hendrik Leppkes h.lepp...@gmail.com wrote:
On Mon, Feb 17, 2014 at 12:06 AM, Vittorio Giovara
vittorio.giov...@gmail.com wrote:
On Sun, Feb 16, 2014 at 11:15 PM, Luca Barbato
On Wed, Feb 19, 2014 at 9:06 PM, Anton Khirnov an...@khirnov.net wrote:
Newly created side data is not zeroed.
Why isn't it?
Sounds like a problem to be repeated frequently, I remember this
coming up before in some place
- Hendrik
___
libav-devel
On Thu, Feb 20, 2014 at 2:38 AM, Vittorio Giovara
vittorio.giov...@gmail.com wrote:
And use the value from the specification.
Found-by: Mateusz j00ru Jurczyk and Gynvael Coldwind
---
libavcodec/h264.c| 18 ++
libavcodec/h264_loopfilter.c | 8
2 files
On Sun, Mar 2, 2014 at 7:34 PM, Luca Barbato lu_z...@gentoo.org wrote:
Provide f_strict for avconv usage.
---
Spun off the nut patch.
libavformat/avformat.h | 6 ++
libavformat/options_table.h | 5 +
libavformat/version.h | 2 +-
3 files changed, 12 insertions(+), 1
On Wed, Mar 5, 2014 at 6:11 PM, Anton Khirnov an...@khirnov.net wrote:
On Wed, 05 Mar 2014 10:59:20 -0500, Justin Ruggles justin.rugg...@gmail.com
wrote:
On 03/05/2014 09:25 AM, Anton Khirnov wrote:
On Wed, 05 Mar 2014 08:56:52 -0500, Justin Ruggles
justin.rugg...@gmail.com wrote:
On
On Thu, Mar 6, 2014 at 9:17 PM, Tim Walker tdskywal...@gmail.com wrote:
On 06 Mar 2014, at 16:27, Hendrik Leppkes h.lepp...@gmail.com wrote:
On Thu, Mar 6, 2014 at 4:03 PM, Luca Barbato lu_z...@gentoo.org wrote:
On 06/03/14 15:59, Felix Abecassis wrote:
Without this patch, I have
On Fri, Mar 7, 2014 at 12:43 AM, Reinhard Tartler siret...@gmail.com wrote:
On Thu, Mar 6, 2014 at 4:12 PM, Luca Barbato lu_z...@gentoo.org wrote:
On 06/03/14 22:08, James Almer wrote:
On 06/03/14 5:47 PM, Luca Barbato wrote:
On 06/03/14 21:34, Reinhard Tartler wrote:
Do we want this in
On Sun, Mar 9, 2014 at 10:46 AM, Anton Khirnov an...@khirnov.net wrote:
On Sun, 9 Mar 2014 08:14:24 +0100, Vittorio Giovara
vittorio.giov...@gmail.com wrote:
From: Carl Eugen Hoyos ceho...@ag.or.at
Based on work by ami_stuff.
Signed-off-by: Vittorio Giovara vittorio.giov...@gmail.com
On Mon, Mar 10, 2014 at 12:43 PM, Tim Walker tdskywal...@gmail.com wrote:
On 10 Mar 2014, at 11:01, Luca Barbato lu_z...@gentoo.org wrote:
Do not use inline functions that refer to tables present in other
libraries.
---
libavformat/hevc.c | 10 +-
1 file changed, 5 insertions(+), 5
On Mon, Mar 10, 2014 at 1:27 PM, Tim Walker tdskywal...@gmail.com wrote:
On 10 Mar 2014, at 13:24, Luca Barbato lu_z...@gentoo.org wrote:
On 10/03/14 12:43, Tim Walker wrote:
On 10 Mar 2014, at 11:01, Luca Barbato lu_z...@gentoo.org wrote:
Do not use inline functions that refer to tables
On Tue, Mar 11, 2014 at 2:42 PM, Diego Biurrun di...@biurrun.de wrote:
The function is supposed to confirm that the compiler provided enough
alignment, but in practice it is only run in certain code paths and
insufficient alignment problems are restricted to legacy compilers.
---
On Fri, Mar 14, 2014 at 1:51 AM, Vittorio Giovara
vittorio.giov...@gmail.com wrote:
---
cc seems to work on osx and linux, it would allow skipping --cc=clang
at configure on modern osx, but I'm not sure of the overall impact.
Ideas?
Vittorio
configure | 4 ++--
1 file changed, 2
On Tue, Mar 18, 2014 at 9:22 AM, Vittorio Giovara
vittorio.giov...@gmail.com wrote:
---
This is the AVPixformatron I thought for future embedding in AVFrame.
I used this struct in AVCodec too, but maybe a smaller struct could be used
instead?
Vittorio
git add libavutil/pixformatron.h might
On Mon, Mar 24, 2014 at 3:01 AM, Luca Barbato lu_z...@gentoo.org wrote:
From: Anton Khirnov an...@khirnov.net
---
libavcodec/avcodec.h | 23 +++
libavcodec/internal.h | 5 +
libavcodec/utils.c| 34 ++
3 files changed, 58
On Mon, Mar 24, 2014 at 10:12 AM, Luca Barbato lu_z...@gentoo.org wrote:
On 24/03/14 10:07, Hendrik Leppkes wrote:
On Mon, Mar 24, 2014 at 3:01 AM, Luca Barbato lu_z...@gentoo.org wrote:
From: Anton Khirnov an...@khirnov.net
---
libavcodec/avcodec.h | 23
On Mon, Mar 24, 2014 at 9:16 PM, Rémi Denis-Courmont r...@remlab.net wrote:
Le lundi 24 mars 2014, 20:23:05 Anton Khirnov a écrit :
Last I checked, libavcodec did not support hardware acceleration for
anything other than 4:2:0 - just looking at the pixel format lists...
Anyway, is there
On Mon, Mar 24, 2014 at 9:40 PM, Rémi Denis-Courmont r...@remlab.net wrote:
Le lundi 24 mars 2014, 21:24:47 Hendrik Leppkes a écrit :
The point is that currently those surface types are used by 4:2:0 surfaces
only. If support for 4:2:2 or Hi10p or whatever gets added to libavcodec
On Sun, Mar 30, 2014 at 8:07 PM, Luca Barbato lu_z...@gentoo.org wrote:
On 30/03/14 17:23, Derek Buitenhuis wrote:
Build 13 has a crucial fix which makes x265_encode_headers work
as its always been documented.
Previous to this, the check was incorrect.
Also allows for use of the repeat
From: Michael Niedermayer michae...@gmx.at
This resolves compilation warnings and protects against future breakage as
Picture and H264Picture drift apart.
Signed-off-by: Hendrik Leppkes h.lepp...@gmail.com
---
libavcodec/dxva2.c | 12 ++--
libavcodec/dxva2_h264.c | 8
---
I present to you, DXVA2 hwaccel decoding for avconv.
It works OK, doesn't pass fate completely for various reasons:
- MPEG-2 decoding is not bitexact to ffmpeg2, because the specification is not.
- H.264 decoding mostly passes fate, except when it doesn't.
- VC-1 seems mostly fine, except
---
Second pass, most issues resolved.
All of H.264 FATE now passes, except 2 tests which perform cropping (can't crop
a in HW surface),
and two which have invisible pixel differences (h264-conformance-mr6_bt_b
h264-conformance-mr8_bt_b)
diff --git a/Makefile b/Makefile
index 2453dfd..52965f6
---
Makefile | 1 +
avconv.h | 2 +
avconv_dxva2.c | 599 +
avconv_opt.c | 3 +
configure | 3 +
5 files changed, 608 insertions(+)
create mode 100644 avconv_dxva2.c
diff --git a/Makefile b/Makefile
index
On Sun, Apr 27, 2014 at 6:47 PM, Anton Khirnov an...@khirnov.net wrote:
---
libavformat/matroska.c |1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/matroska.c b/libavformat/matroska.c
index 410e2f4..9628abc 100644
--- a/libavformat/matroska.c
+++ b/libavformat/matroska.c
On Mon, Apr 28, 2014 at 2:44 PM, Kostya Shishkov
kostya.shish...@gmail.com wrote:
On Mon, Apr 28, 2014 at 02:35:36PM +0200, Niels Möller wrote:
After implementing proper channel reorder, I think the audio is pretty
close to correct. Peak sample error for Master Audio 5.0 96khz.dts is
now down
This avoids issues with inconsistent headers with different versions of
mingw-w64 and older MSVC variants.
Fixes FATE builds of MSVC 2010.
---
avconv_dxva2.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/avconv_dxva2.c b/avconv_dxva2.c
index
On Fri, May 2, 2014 at 5:54 PM, Josh Allmann joshua.allm...@gmail.com wrote:
Since the scaler is often auto-inserted in video filtergraphs,
this avoids a runtime error when filters are selectively enabled.
I dunno, just because its commonly used at runtime shouldn't mandate
including it all the
This fixes build failures on older mingw chains (before 2012).
---
configure | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 47fd690..bdf4f66 100755
--- a/configure
+++ b/configure
@@ -1505,6 +1505,7 @@ HAVE_LIST=
$TYPES_LIST
On Fri, May 9, 2014 at 1:54 PM, Hendrik Leppkes h.lepp...@gmail.com wrote:
This fixes build failures on older mingw chains (before 2012).
---
configure | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 47fd690..bdf4f66 100755
On Sun, May 11, 2014 at 8:23 AM, Anton Khirnov an...@khirnov.net wrote:
On Thu, 8 May 2014 15:15:06 +0200, Luca Barbato lu_z...@gentoo.org wrote:
It would reduce the boilerplate code users have to write.
---
libavcodec/avcodec.h | 5 +
libavcodec/pthread_frame.c | 4
2
Am 15.05.2014 17:08 schrieb Diego Biurrun di...@biurrun.de:
The feature is of doubtful utility and has no known users.
---
common.mak | 3 +--
configure | 38 +++---
library.mak | 2 +-
3 files changed, 17 insertions(+), 26 deletions(-)
diff --git
Am 15.05.2014 17:08 schrieb Diego Biurrun di...@biurrun.de:
The feature is of doubtful utility and has no known users.
---
I use and need this feature.
Its quite useful on windows as windows by default only loads one shared
library with the same name, so you try to rename those that can easily
From: Mickaël Raulet mrau...@insa-rennes.fr
---
libavcodec/hevcpred_template.c | 372 +
1 file changed, 190 insertions(+), 182 deletions(-)
diff --git a/libavcodec/hevcpred_template.c b/libavcodec/hevcpred_template.c
index 27f4b9e..2787557 100644
---
On Tue, May 20, 2014 at 7:28 PM, Diego Biurrun di...@biurrun.de wrote:
On Fri, May 09, 2014 at 01:54:18PM +0200, Hendrik Leppkes wrote:
This fixes build failures on older mingw chains (before 2012).
---
configure | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
I'm
On Mon, Apr 30, 2012 at 1:25 AM, Ronald S. Bultje rsbul...@gmail.comwrote:
When playing such a file, what happens? Do we simply error out with a
swscale error?
I don't think it errors out. The decoder handles it like any old YUV color
space, and so does swscale, because it doesn't pay
On Wed, May 2, 2012 at 1:38 PM, Tomas Härdin tomas.har...@codemill.sewrote:
AVCOL_SPC_YCOCG perhaps?
/Tomas
The H.264 Spec names it YCgCo, which is where the name was based on.
___
libav-devel mailing list
libav-devel@libav.org
Hi,
see attached patched.
After the pcm_mpeg decoder was converted to the new bytestream api, the
number of consumed bytes returned did no longer include the 4 byte header.
- Hendrik
0001-pcm_mpeg-fix-number-of-consumed-bytes-to-include-the.patch
Description: Binary data
On Wed, May 30, 2012 at 5:09 AM, Mans Rullgard m...@mansr.com wrote:
Override the frame size from the SPS with AVCodecContext values
of the latter specify a smaller size.
What happens if the stream changes frame size during decoding (increases),
wouldn't it then crop to the old value?
On Wed, Jun 20, 2012 at 10:32 AM, Diego Biurrun di...@biurrun.de wrote:
---
libavcodec/x86/h264_intrapred_init.c |6 +++---
libavcodec/x86/h264dsp_mmx.c |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/x86/h264_intrapred_init.c
On Thu, Jun 21, 2012 at 9:45 AM, Martin Storsjö mar...@martin.st wrote:
In the Microsoft Windows SDK (as you get as part of Visual Studio), this
function definition is hidden behind #if _WIN32_WINNT = 0x0600, so as far
as I can see, configure would only find and use this function (and likewise
On Tue, Jun 26, 2012 at 11:16 AM, Martin Storsjö mar...@martin.st wrote:
Rafaël later commented this issue on irc:
11:04 funman i'll move DXVA_* into a dxva.h
11:05 funman released mingw-w64 don't work anyway so IMO it's better to
unconditionally include dxva.h and rely on
The patch looks OK for fixing the buffer overread.
However, it does NOT fix the crash as reported in bug #342. The crash is
still present in git master with this patch applied on top.
___
libav-devel mailing list
libav-devel@libav.org
On Fri, Aug 3, 2012 at 2:22 PM, Kostya Shishkov
kostya.shish...@gmail.comwrote:
On Fri, Aug 03, 2012 at 02:18:46PM +0200, Hendrik Leppkes wrote:
The patch looks OK for fixing the buffer overread.
However, it does NOT fix the crash as reported in bug #342. The crash is
still present in git
You should also check the profile. A lossless profile can be 8-bit 4:2:0,
and will still fail the hardware decoder.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On Sun, Aug 19, 2012 at 6:52 PM, Diego Biurrun di...@biurrun.de wrote:
--- a/libavcodec/vc1dec.c
+++ b/libavcodec/vc1dec.c
@@ -1164,177 +1164,57 @@ static av_always_inline void
get_mvdata_interlaced(VC1Context *v, int *dmv_x,
+static void scale_field_mv(VC1Context *v, int16_t *mv, int
DTS can be lossless, the libav decoder just doesn't support it. Does that
count?
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
---
libavcodec/x86/vp56_arith.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/x86/vp56_arith.h b/libavcodec/x86/vp56_arith.h
index be2dd30..0a69368 100644
--- a/libavcodec/x86/vp56_arith.h
+++ b/libavcodec/x86/vp56_arith.h
@@ -24,7 +24,7 @@
#ifndef
---
libavcodec/x86/mlpdsp.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/x86/mlpdsp.c b/libavcodec/x86/mlpdsp.c
index f81c329..8f886aa 100644
--- a/libavcodec/x86/mlpdsp.c
+++ b/libavcodec/x86/mlpdsp.c
@@ -24,7 +24,7 @@
#include libavcodec/dsputil.h
Currently, implicit function declarations are only considered an error during
building,
but not during configure, which can result in configure mis-detecting the
availability
of some functions (most notably log2 on amd64).
Instead, treat it as an error condition in all stages of building, for a
---
configure |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/configure b/configure
index 7ca262f..e8288cb 100755
--- a/configure
+++ b/configure
@@ -2104,8 +2104,7 @@ msvc_flags(){
-g) echo -Z7 ;;
-Wall)echo -W4
On Sat, Sep 8, 2012 at 8:45 AM, Johan Andersson j...@i19.se wrote:
On Sat, Sep 08, 2012 at 08:41:18AM +0200, Hendrik Leppkes wrote:
---
configure |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Typo in the commit message? it should be -wd and not -we?
No, it actually
On Sat, Sep 8, 2012 at 12:07 PM, Ronald S. Bultje rsbul...@gmail.comwrote:
Why is have_7regs set? Are you building for 64 bits? I haven't tested that
yet. :-).
Ronald
Yes, this is x64. With this fixed, and the other msvc configure change, it
builds and passes fate just fine.
On Sat, Sep 8, 2012 at 12:23 PM, Ronald S. Bultje rsbul...@gmail.comwrote:
Can someone host a x64 cl.exe fate station?
I will once git master builds properly (already setup a 32-bit yesterday)
___
libav-devel mailing list
libav-devel@libav.org
On Sat, Sep 8, 2012 at 12:09 PM, Ronald S. Bultje rsbul...@gmail.comwrote:
This sounds like the wrong fix tbh. The first chunk looks OK but
wouldn't other systems, eg old GCC versions, be similarly affected?
Shouldn't the true fix live elsewhere, ie fix the log2() check?
The log2 check is
On Sat, Sep 8, 2012 at 1:40 PM, Martin Storsjö mar...@martin.st wrote:
On Sat, 8 Sep 2012, Måns Rullgård wrote:
Hendrik Leppkes h.lepp...@gmail.com writes:
On Sat, Sep 8, 2012 at 12:09 PM, Ronald S. Bultje rsbul...@gmail.com
wrote:
This sounds like the wrong fix tbh. The first chunk
On Sat, Sep 8, 2012 at 4:33 PM, Ronald S. Bultje rsbul...@gmail.com wrote:
Hi,
On Sep 8, 2012 2:37 PM, Martin Storsjö mar...@martin.st wrote:
On Sat, 8 Sep 2012, Måns Rullgård wrote:
Hendrik Leppkes h.lepp...@gmail.com writes:
On Sat, Sep 8, 2012 at 1:40 PM, Martin Storsjö mar
On Mon, Sep 10, 2012 at 2:08 PM, Måns Rullgård m...@mansr.com wrote:
Diego Biurrun di...@biurrun.de writes:
On Sat, Sep 08, 2012 at 03:37:18PM +0300, Martin Storsjö wrote:
On Sat, 8 Sep 2012, Måns Rullgård wrote:
Hendrik Leppkes h.lepp...@gmail.com writes:
On Sat, Sep 8, 2012 at 1:40 PM
On Wed, Sep 4, 2013 at 10:08 PM, John Stebbins stebb...@jetheaddev.comwrote:
A change in framesize caused a perpetual loss of synchronization.
So read (and use) the frame size from the frame header instead of
setting it only once.
Won't this patch still trip up on the first frame with the
On Fri, Sep 6, 2013 at 12:02 PM, Vittorio Giovara
vittorio.giov...@gmail.com wrote:
Il giorno venerdì 6 settembre 2013, Luca Barbato ha scritto:
On 03/09/13 16:46, Vittorio Giovara wrote:
---
libavcodec/eamad.c |2 +-
libavcodec/mpeg12dec.c |9 ++---
2 files
On Sun, Sep 8, 2013 at 10:28 PM, Vittorio Giovara
vittorio.giov...@gmail.com wrote:
On Saturday, September 7, 2013, John Stebbins wrote:
This can be optionally disabled whith the showall flags2 option.
When in showall mode, incomplete frames are signalled through
AVFrame.flags
On Mon, Sep 9, 2013 at 3:37 PM, Vittorio Giovara vittorio.giov...@gmail.com
wrote:
---
I performed some more benchmarking and the results at higher bitrates show
that the current implementation is better (by a tiny amount anyway). So I
rebased and reimplemented my change just as code
On Tue, Sep 10, 2013 at 11:43 AM, aviad rozenhek avia...@gmail.com wrote:
URLProtocol is very useful for users of libav, as it allows extending
ffmpeg by defining I/O for new types of devices, memory buffers or
protocols without needing to modify libav itself.
would it be possible to make
From: Loren Merritt pengv...@akuvian.org
Now RET checks whether it immediately follows a branch, so the programmer
dosen't have to keep track of that condition.
REP_RET is still needed manually when it's a branch target, but that's much
rarer.
The implementation involves lots of spurious
From: Henrik Gramner hen...@gramner.com
---
libavutil/x86/x86inc.asm | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index 07512d1..b6edfd9 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -709,7
From: Jason Garrett-Glaser ja...@x264.com
Small backports that sneaked into other asm commits in x264.
---
libavutil/x86/x86inc.asm | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index 9aac013..84f6b19 100644
---
From: Henrik Gramner hen...@gramner.com
The Mach-O bug was fixed in yasm 0.8.0 and we don't support versions that old.
a.out was superseded by ELF on sane systems a few decades ago.
---
libavutil/x86/x86inc.asm | 23 +++
1 file changed, 3 insertions(+), 20 deletions(-)
diff
Hi,
in this set you'll find backports from most of the recent changes to x86inc
from x264.
This is primarily motived by patch 7, which also fixes a crash in avresample in
current
git master (Issue #496)
Important points of note:
A few patches regarding AVX/AVX2/FMA4 have not been backported,
From: Loren Merritt pengv...@akuvian.org
SWAP with =3 named (rather than numbered) args
PERMUTE followed by SWAP with 2 named args
used to produce the wrong permutation
---
libavutil/x86/x86inc.asm | 54
1 file changed, 27 insertions(+), 27
From: Henrik Gramner hen...@gramner.com
Prevents a crash if the misaligned exception mask bit is cleared for some
reason.
Misaligned SSE functions are only used on AMD Phenom CPUs and the benefit is
miniscule.
They also require modifying the MXCSR control register and by removing those
From: Henrik Gramner hen...@gramner.com
Reduces code size because movaps/movups is one byte shorter than movdqa/movdqu.
---
libavutil/x86/x86inc.asm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index b6edfd9..0c27c60
From: Loren Merritt pengv...@akuvian.org
For when we want to mix simd sizes within one function.
---
libavutil/x86/x86inc.asm | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index 9944b8f..6878b35
From: Henrik Gramner hen...@gramner.com
Store XMM6 and XMM7 in the shadow space in functions that clobbers them.
This way we don't have to adjust the stack pointer as often,
reducing the number of instructions as well as code size.
---
libavcodec/x86/fft.asm | 4 +-
From: Derek Buitenhuis derek.buitenh...@gmail.com
This is also a valid value for WIN64.
---
libavutil/x86/x86inc.asm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index 860906c..9aac013 100644
--- a/libavutil/x86/x86inc.asm
+++
On Thu, Sep 12, 2013 at 12:06 PM, Derek Buitenhuis
derek.buitenh...@gmail.com wrote:
On 9/11/2013 4:49 PM, Hendrik Leppkes wrote:
From: Jason Garrett-Glaser ja...@x264.com
Small backports that sneaked into other asm commits in x264.
---
libavutil/x86/x86inc.asm | 7 +++
1 file
On Tue, Sep 17, 2013 at 1:02 AM, Alex Converse alex.conve...@gmail.comwrote:
This does not add support for any error resiliance tools.
---
Changelog | 1 +
libavcodec/aacdec.c | 116
+++-
2 files changed, 107 insertions(+), 10
On Tue, Sep 17, 2013 at 10:10 PM, Luca Barbato lu_z...@gentoo.org wrote:
On 17/09/13 20:53, Kieran Kunhya wrote:
---
libavutil/pixdesc.c | 48
libavutil/pixfmt.h |6 ++
2 files changed, 54 insertions(+)
Looks fine to me
On Tue, Sep 17, 2013 at 11:16 PM, Kieran Kunhya kier...@obe.tv wrote:
I've never heard of NV20, but i know NV16 as 4:2:2 8-bit, similar to NV12
just for 4:2:2, not as 16bpp - so this would conflict with this defintion.
8-bit 4:2:2 is 16 bits per sample (I don't know why bpp is used in that
On Wed, Sep 11, 2013 at 5:49 PM, Hendrik Leppkes h.lepp...@gmail.com wrote:
Hi,
in this set you'll find backports from most of the recent changes to x86inc
from x264.
This is primarily motived by patch 7, which also fixes a crash in avresample
in current
git master (Issue #496
On Thu, Sep 19, 2013 at 3:28 PM, Janne Grunau janne-li...@jannau.net wrote:
configure enables memalign hack if none of the aligned allocation
methods are available.
---
libavutil/mem.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libavutil/mem.c b/libavutil/mem.c
index
On Fri, Oct 4, 2013 at 8:13 PM, Luca Barbato lu_z...@gentoo.org wrote:
On 04/10/13 12:01, Vittorio Giovara wrote:
---
libavcodec/h264.c|6 +++---
libavcodec/libx264.c |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
In preparation of hevc? Why not?
Before asking Why
On Wed, Oct 23, 2013 at 12:32 PM, Luca Barbato lu_z...@gentoo.org wrote:
On 22/10/13 17:05, Vittorio Giovara wrote:
---
I'm not entirely sure about why this is needed, but I'm posting the solution
early so I can get feedback.
Cheers,
Vittorio
Can you check the values fieldorder is
On Sun, Oct 27, 2013 at 12:41 AM, Vittorio Giovara
vittorio.giov...@gmail.com wrote:
---
Luca suggested trying not to use swscale at all, keeping the pixel format
constant. I wasn't able to find a way to force 422 on input, but I solved
this by using GREY input (hey interlaced y8 is all the
On Mon, Oct 28, 2013 at 9:19 AM, Vittorio Giovara
vittorio.giov...@gmail.com wrote:
On Mon, Oct 28, 2013 at 7:49 AM, Anton Khirnov an...@khirnov.net wrote:
On Mon, 28 Oct 2013 03:00:39 +0100, Vittorio Giovara
vittorio.giov...@gmail.com wrote:
---
libavfilter/af_asyncts.c | 2 +-
1 file
On Fri, Nov 1, 2013 at 6:03 PM, Sam Lantinga slou...@libsdl.org wrote:
---
libavutil/common.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavutil/common.h b/libavutil/common.h
index caa6b19..b445adb 100644
--- a/libavutil/common.h
+++ b/libavutil/common.h
@@ -27,7 +27,9 @@
On Sun, Nov 3, 2013 at 11:09 PM, Vittorio Giovara
vittorio.giov...@gmail.com wrote:
This will convert the gcc warning -Wno-maybe-unintialized into
-Wno-sometimes-uninitialized for clang
---
This was originally disabled because GCC is rather bad at this and
emits a lot of false positives. clang
On Mon, Nov 4, 2013 at 1:05 PM, Rémi Denis-Courmont r...@remlab.net wrote:
On Sun, 3 Nov 2013 23:27:45 +0100, Anton Khirnov an...@khirnov.net
wrote:
data[0] may be NULL for valid frames with hwaccel pixel formats.
This looks OK (and VLC already supplies a dummy buf[0] for hwaccel
surfaces)
On Thu, Nov 14, 2013 at 11:47 AM, Luca Barbato lu_z...@gentoo.org wrote:
On 14/11/13 11:36, Anton Khirnov wrote:
On Thu, 14 Nov 2013 11:29:17 +0100, Luca Barbato lu_z...@gentoo.org wrote:
On 14/11/13 11:10, Anton Khirnov wrote:
On Thu, 14 Nov 2013 10:43:42 +0100, Luca Barbato
On Sun, Nov 17, 2013 at 12:14 AM, Tim Walker tdskywal...@gmail.com wrote:
---
libavcodec/dcadec.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/libavcodec/dcadec.c b/libavcodec/dcadec.c
index 7af5e5c..b2e9e8a 100644
--- a/libavcodec/dcadec.c
+++
1 - 100 of 573 matches
Mail list logo
