Makes no real difference, but maybe scares coverity less (CID1297578)
Signed-off-by: Michael Niedermayer
---
libavcodec/vp9.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index db3f541..4655e9a 100644
--- a/libavcodec/vp9.c
+++ b/li
Michael Niedermayer gmx.at> writes:
> > I failed to implement an autodetection.
>
> you should be able to autodetect it relatively easily
>
> "Lavf56.33.101" is stored in the flac file
Apart from the fact that this is not an encoder string:
How would libavcodec know about it?
> > typedef str
Le 14/05/2015 18:57, Michael Niedermayer a écrit :
[...]
+reserved
the reserved bit is not defined,
This way one could misunderstand it as if it was allowed to add
such bits in the encoder
I don't see it as something allowed (i.e. as a "user data" for private
use) but you're right, it is not
Hi,
On Fri, May 15, 2015 at 5:10 AM, Michael Niedermayer
wrote:
> Makes no real difference, but maybe scares coverity less (CID1297578)
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/vp9.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/vp9.c
On Fri, May 15, 2015 at 06:59:50AM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Fri, May 15, 2015 at 5:10 AM, Michael Niedermayer
> wrote:
>
> > Makes no real difference, but maybe scares coverity less (CID1297578)
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/vp9.c |3 +
On Fri, May 15, 2015 at 09:27:47AM +, Carl Eugen Hoyos wrote:
> Michael Niedermayer gmx.at> writes:
>
> > > I failed to implement an autodetection.
> >
> > you should be able to autodetect it relatively easily
> >
> > "Lavf56.33.101" is stored in the flac file
>
> Apart from the fact that
On Fri, May 15, 2015 at 09:27:47AM +, Carl Eugen Hoyos wrote:
> Michael Niedermayer gmx.at> writes:
[...]
> > > typedef struct FLACContext {
> > > -FLACSTREAMINFO
> > > +struct FLACStreaminfo flac_stream_info;
> >
> > why not just add AVCLass to FLACCOMMONINFO ? or is
> > there a re
Hi,
following the positive trend as of late, here is a shared discussion
on a proposed API.
There are a couple of formats that are based on texture compression,
usually called DXTn or BCn, and described here:
http://en.wikipedia.org/wiki/S3_Texture_Compression. Currently in
libavcodec only txd us
I am trying to capture the camera-encoded H.264 video stream from a
Logitech C930e webcam.
It seems that there is support for this in the UVC driver and I
understand that guvcview supports this camera:
http://sourceforge.net/p/linux-uvc/mailman/message/33405777/
But, I am operating in a comm
On Fri, May 15, 2015 at 12:45:35PM +0200, Jerome Martinez wrote:
> Le 14/05/2015 18:57, Michael Niedermayer a écrit :
> >[...]
> >>+reserved
> >the reserved bit is not defined,
> >This way one could misunderstand it as if it was allowed to add
> >such bits in the encoder
>
> I don't see it as some
They all overflow in various samples that are considered valid input.
---
libavcodec/x86/vp9itxfm.asm | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/x86/vp9itxfm.asm b/libavcodec/x86/vp9itxfm.asm
index 9cf0d78..a08e1ff 100644
--- a/libavcodec/x86/vp9itxfm.asm
That file is attached
you would have to attach the file generated by git format-patch
also you of course first need to locally commit your changes
and set the commit message and author
see man git commit
[...]
___
ffmpeg-devel mailing list
ffmpeg-de
---
libavcodec/vp9.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index db3f541..a3cecf2 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -153,6 +153,7 @@ typedef struct VP9Context {
uint8_t temporal;
uint
---
libavcodec/vp9.c | 4
libavcodec/vp9_mc_template.c | 5 -
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index a3cecf2..6982eef 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -2833,6 +2833,7 @@ static av_always_in
For idct16, only when called from a adst16x16 variant, so impact is
minor. For idct32, for all, so relatively major impact.
---
libavcodec/x86/vp9itxfm.asm | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/libavcodec/x86/vp9itxfm.asm b/libavcodec/x86/
---
libavcodec/vp9.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 6982eef..c90059e 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -2782,13 +2782,23 @@ static av_always_inline void
mc_chroma_scaled(VP9Con
---
libavcodec/vp9.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index bc2dc0d..8e0d598 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -3108,8 +3108,12 @@ static av_always_inline void mask_edges(uint8_t
(*mask)[8][4], in
This reproduces libvpx behaviour. It seems like it originally only
targeted loopfilter behaviour, but this unfortunately effects following
block contexting and thus directs bitstream sync.
---
libavcodec/vp9.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff
The practical effect of this is that the scaling will wrongly not be
applied to the interpolation edge (the 3/4 constants in this patch).
In other words, we clip to the pre-scaling interpolation, even though
these should be clipped post-scaling. The resulting out-of-frame MVs
are thus automatically
---
libavcodec/vp9.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 8e0d598..23cf99b 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -3314,7 +3314,7 @@ static void decode_b(AVCodecContext *ctx, int row, int
col,
int w
---
libavcodec/vp9.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 8b1ef67..bc88bf9 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -800,9 +800,9 @@ static int decode_frame_header(AVCodecContext *ctx,
sh = s->filt
libvpx (probably accidentally) clears the bits if error_res is set,
along with keyframe/intraonly. This probably wasn't the intention
(since it's local data), but it's behaviour we have to copy...
---
libavcodec/vp9.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavco
---
libavcodec/vp9.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 23cf99b..8b1ef67 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -698,6 +698,15 @@ static int decode_frame_header(AVCodecContext *ctx,
s->framectxid = c = get_
On Fri, May 15, 2015 at 3:43 PM, Ronald S. Bultje
wrote:
> They all overflow in various samples that are considered valid input.
I'm actually not sure about this last bit. I originally considered the
samples "valid", but it looks like parts of the samples I was looking at
are synthetic coeffici
- Original Message -
From: "Vittorio Giovara"
To: "libav development" ; "FFmpeg development discussions and
patches"
Sent: Friday, May 15, 2015 10:09 AM
Subject: [FFmpeg-devel] shared api for exposing a texture
Hi,
following the positive trend as of late, here is a shared discussio
Fixes: CID1257657
Signed-off-by: Michael Niedermayer
---
libavcodec/libutvideoenc.cpp |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libutvideoenc.cpp b/libavcodec/libutvideoenc.cpp
index 3b88fff..cf669d2 100644
--- a/libavcodec/libutvideoenc.cpp
+++ b/libav
On Thu, May 14, 2015 at 03:33:55PM +0200, Nedeljko Babic wrote:
> From: Djordje Pesut
>
> Add fixed point implementation
>
> Signed-off-by: Nedeljko Babic
> ---
> libavcodec/aac.h | 101 --
> libavcodec/aacdec.c | 5 +
> libavcodec/aacdec_fixed.c| 446
>
On Thu, May 14, 2015 at 03:33:56PM +0200, Nedeljko Babic wrote:
> From: Jovan Zelincevic
>
> Build system modified
>
> Signed-off-by: Nedeljko Babic
> ---
> configure | 1 +
> libavcodec/Makefile | 13 ++---
> libavcodec/aacdec.c | 1 -
> libavcodec/aacdec
28 matches
Mail list logo
