On 21/07/15 02:21, Tom Butterworth wrote:
> Some uses of Snappy require uncompressing to positions within an existing
> buffer. Also adds a function to get the uncompressed length of Snappy data.
> ---
> libavcodec/hapdec.c | 7 ++-
> libavcodec/snappy.c | 24 +---
> liba
return INVALIDDARA if Data Object was not found
---
libavformat/asfdec.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/libavformat/asfdec.c b/libavformat/asfdec.c
index 6613ec6..a625028 100644
--- a/libavformat/asfdec.c
+++ b/libavformat/asfdec.c
@@ -1652,1
On 21/07/15 08:43, Steve Lhomme wrote:
> In case the VideoContext is used by different threads internally or
> other threads externally
> ---
> libavcodec/d3d11va.h | 5 +
> libavcodec/dxva2.c | 15 +--
> libavcodec/version.h | 4 ++--
> 3 files changed, 20 insertions(+), 4 del
On 21/07/15 00:47, Vittorio Giovara wrote:
> ---
> tests/fate/image.mak| 2 +-
> tests/ref/fate/dds-rgba | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
> create mode 100644 tests/ref/fate/dds-rgba
>
Ok, if looks correct.
___
libav-deve
On 21/07/15 00:47, Vittorio Giovara wrote:
> From: Michael Niedermayer
>
> Found-By: ami_stuff
> Signed-off-by: Vittorio Giovara
> ---
> libavcodec/dds.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/dds.c b/libavcodec/dds.c
> index 19f7dd0..1
In case the VideoContext is used by different threads internally or
other threads externally
---
libavcodec/d3d11va.h | 5 +
libavcodec/dxva2.c | 15 +--
libavcodec/version.h | 4 ++--
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/libavcodec/d3d11va.h b/libavc
On 21/07/15 00:47, Vittorio Giovara wrote:
> Red and blue channels were decoded in the wrong order.
>
> Found-By: ami_stuff
> ---
> libavcodec/dds.c | 10 +++---
> tests/ref/fate/dds-pal | 2 +-
> tests/ref/fate/dds-pal-ati | 2 +-
> 3 files changed, 9 insertions(+), 5 deletio
On 16/07/15 3:56 PM, Anton Khirnov wrote:
> The current code is less than straightforward due to the fact that
> output streams can be created based on filtergraph definitions. This
> change should make the code simpler and more readable. It will also be
> useful in the future commits.
This commit
Some uses of Snappy require uncompressing to positions within an existing
buffer. Also adds a function to get the uncompressed length of Snappy data.
---
libavcodec/hapdec.c | 7 ++-
libavcodec/snappy.c | 24 +---
libavcodec/snappy.h | 19 ++-
3 files chan
---
libavcodec/hap.h | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/libavcodec/hap.h b/libavcodec/hap.h
index 1250a6f..3a25544 100644
--- a/libavcodec/hap.h
+++ b/libavcodec/hap.h
@@ -29,12 +29,23 @@
#include "bytestream.h"
#include "texturedsp.h"
---
libavcodec/Makefile | 4 +-
libavcodec/hap.c | 55 ++
libavcodec/hap.h | 37 ++-
libavcodec/hapdec.c | 272 +--
libavcodec/hapenc.c | 187 ++--
tests/fate/video.mak | 3
This change will reject frames with a texture type which doesn't match the
stream description.
---
libavcodec/hapdec.c | 50 --
1 file changed, 28 insertions(+), 22 deletions(-)
diff --git a/libavcodec/hapdec.c b/libavcodec/hapdec.c
index 72db9f4..
On Mon, Jul 20, 2015 at 8:38 PM, wm4 wrote:
> On Mon, 20 Jul 2015 18:24:16 +0100
> Vittorio Giovara wrote:
>
>> Express bitfields more simply.
>>
>> Signed-off-by: Vittorio Giovara
>> ---
>
> +1
>
> Will there be similar patches for the FF_ public symbols?
The remaining FF_ symbols are definite
On Mon, Jul 20, 2015 at 3:56 PM, Luca Barbato wrote:
> uhd1 and uhd2 would be ambigous.
> ---
> doc/avconv.texi| 4 ++--
> libavutil/parseutils.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/doc/avconv.texi b/doc/avconv.texi
> index 43215a0..504b8ed 100644
From: Michael Niedermayer
Found-By: ami_stuff
Signed-off-by: Vittorio Giovara
---
libavcodec/dds.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/libavcodec/dds.c b/libavcodec/dds.c
index 19f7dd0..1266ef2 100644
--- a/libavcodec/dds.c
+++ b/libavcodec/dds.c
@@
---
tests/fate/image.mak| 2 +-
tests/ref/fate/dds-rgba | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
create mode 100644 tests/ref/fate/dds-rgba
diff --git a/tests/fate/image.mak b/tests/fate/image.mak
index 272e023..b7cc30e 100644
--- a/tests/fate/image.mak
+++ b/tests/fate/image.
Red and blue channels were decoded in the wrong order.
Found-By: ami_stuff
---
libavcodec/dds.c | 10 +++---
tests/ref/fate/dds-pal | 2 +-
tests/ref/fate/dds-pal-ati | 2 +-
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/libavcodec/dds.c b/libavcodec/dds.c
ind
On Mon, Jul 20, 2015 at 11:18 PM, Janne Grunau wrote:
> Fixes MSVC compilation.
> ---
> tests/checkasm/h264pred.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Ok.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/m
Fixes MSVC compilation.
---
tests/checkasm/h264pred.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tests/checkasm/h264pred.c b/tests/checkasm/h264pred.c
index a5eb033..40e949a 100644
--- a/tests/checkasm/h264pred.c
+++ b/tests/checkasm/h264pred.c
@@ -87,8 +87,7 @@ static c
On 2015-07-20 22:31:28 +0200, Henrik Gramner wrote:
> On Mon, Jul 20, 2015 at 11:58 AM, Janne Grunau wrote:
> > ---
> > tests/checkasm/h264pred.c | 1 +
> > 1 file changed, 1 insertion(+)
>
> Shouldn't it be NULL instead of 0 since those are pointers?
only to make the intent clearer. it makes n
On Mon, Jul 20, 2015 at 11:58 AM, Janne Grunau wrote:
> ---
> tests/checkasm/h264pred.c | 1 +
> 1 file changed, 1 insertion(+)
Shouldn't it be NULL instead of 0 since those are pointers?
Otherwise OK.
___
libav-devel mailing list
libav-devel@libav.or
On Mon, 20 Jul 2015, Janne Grunau wrote:
Avoids a relocation which might end out of range for thumb2.
Reported-By: Ludovic Fauvet
Bug-Id: https://bugs.webkit.org/show_bug.cgi?id=137022
CC: libav-sta...@libav.org
---
libavcodec/arm/videodsp_armv5te.S | 3 ++-
1 file changed, 2 insertions(+), 1 d
On 20/07/15 21:20, Vittorio Giovara wrote:
> ---
> A quick and extremly simple filter for comparing two images.
> Vittorio
>
> Changelog | 1 +
> doc/filters.texi| 4 +
> libavfilter/Makefile| 1 +
> libavfilter/allfilters.c| 1 +
>
On Mon, 20 Jul 2015 18:24:16 +0100
Vittorio Giovara wrote:
> Express bitfields more simply.
>
> Signed-off-by: Vittorio Giovara
> ---
+1
Will there be similar patches for the FF_ public symbols?
___
libav-devel mailing list
libav-devel@libav.org
htt
---
A quick and extremly simple filter for comparing two images.
Vittorio
Changelog | 1 +
doc/filters.texi| 4 +
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/version.h | 2 +-
libavfilter/vf_di
On 20/07/15 18:24, Vittorio Giovara wrote:
> ---
> Needed by a few default option values.
> Vittorio
>
> libavcodec/mpegvideo.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
> index 66b76af..21ceb3d 100644
> --- a/libavcodec/mpegvideo.h
On 20/07/15 19:30, Vittorio Giovara wrote:
> Convert doxygen to multiline and express bitfields more simply.
>
> Signed-off-by: Vittorio Giovara
> ---
> (missing from the previous thread)
Shouldn't hurt.
___
libav-devel mailing list
libav-devel@libav.o
Yes I'm happy with this.
I'll submit my pthread_slice.c patch here for discussion - seems silly
every codec has to adjust work to the thread-count when it can happen
once in the codebase.
On 20 July 2015 at 18:47, Vittorio Giovara wrote:
> On Fri, Jul 17, 2015 at 2:07 AM, Luca Barbato wrote:
>>
On Fri, Jul 17, 2015 at 2:07 AM, Luca Barbato wrote:
> Enjoy some cache locality and use less threads.
> About 5x speedup (from 60ms to 12ms to decode a 4k frame).
> ---
> libavcodec/hap.h| 2 ++
> libavcodec/hapdec.c | 33 +
> 2 files changed, 27 insertions(+
---
libavcodec/mpegvideo.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index 966f827..206eb13 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -38,6 +38,7 @@
#include "h263dsp.h"
#include "hpeldsp.h"
#include "idctdsp.h"
Signed-off-by: Vittorio Giovara
---
doc/APIchanges | 5 +
libavcodec/avcodec.h | 4
libavcodec/version.h | 7 +--
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 3303d5f..401e729 100644
--- a/doc/APIchanges
+++ b/doc/APIchan
Signed-off-by: Vittorio Giovara
---
avconv.c| 2 +-
doc/examples/avcodec.c | 6 +++---
doc/examples/qsvdec.c | 2 +-
libavcodec/4xm.c| 10 +-
libavcodec/a64multienc.c| 2 +-
libavcodec/aac_adtstoasc
This option is extremely codec specific and only a few codecs employ it.
Move it to codec private options instead: mpegenc family only support 3
values, xavs and x264 use 5, while xvid has a different metric (0-6).
Signed-off-by: Vittorio Giovara
---
Added the compatibility layer to every encoder
---
Needed by a few default option values.
Vittorio
libavcodec/mpegvideo.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index 66b76af..21ceb3d 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -38,6 +38,7 @@
#include "h263d
uhd1 and uhd2 would be ambigous.
---
doc/avconv.texi| 4 ++--
libavutil/parseutils.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/avconv.texi b/doc/avconv.texi
index 43215a0..504b8ed 100644
--- a/doc/avconv.texi
+++ b/doc/avconv.texi
@@ -497,9 +497,9 @@ abbr
On 20/07/15 11:50, Janne Grunau wrote:
> Avoids a relocation which might end out of range for thumb2.
>
> Reported-By: Ludovic Fauvet
> Bug-Id: https://bugs.webkit.org/show_bug.cgi?id=137022
> CC: libav-sta...@libav.org
> ---
> libavcodec/arm/videodsp_armv5te.S | 3 ++-
> 1 file changed, 2 inser
On 20/07/15 14:44, Vittorio Giovara wrote:
> Since most of the code in Libav is referring to ITU, I would recommend
> switching to UHD, that otoh does not differ between 2160 and 4320 . So
> you could either use UHDTV1 and UHDTV2 (from SMPTE) or UHD and SHD
> (ITU/NHK). Alternatively stick to ITU a
On Mon, Jul 20, 2015 at 2:34 PM, Tom Butterworth wrote:
>> Is this change necessary? There are now two switches that carry out
>> the same purpose and the condition above forces cases from both
>> switches to perform the same operation.
>
> Define "necessary" :)
>
> Setting the tex_rat and tex_fun
I'm incorporating most of your suggestions in a revised patch - just to answer
>> @@ -171,11 +297,11 @@ static av_cold int hap_close(AVCodecContext *avctx)
>> #define OFFSET(x) offsetof(HapContext, x)
>> #define FLAGS AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
>> static const AVOp
Thanks for the detailed review to this patch set Vittorio.
>> This change will reject frames with a texture type which doesn't match the
>> stream description.
>
> Is this change required by the format specification or just as a
> precaution for malformed streams?
Just as a precaution for malfor
On Mon, Jul 20, 2015 at 8:48 AM, Anton Khirnov wrote:
> Quoting Vittorio Giovara (2015-07-15 19:41:20)
>> Allocating coded_frame is what most encoders do anyway, so it makes
>> sense to always allocate it in a single place. This bring uniformity to
>> encoder behaviour and prevents applications fr
On Sun, Jul 19, 2015 at 12:12 PM, Kieran Kunhya wrote:
>> +{ "uhd", 3840,2160 },
>
> should be uhd1 and uhd2 imho. If you want map uhd to uhd1.
These are the DVB/EBU names used for distribution, and they both refer
to 3840x2160 (differing by colour space and subsampling). If you
wanted t
On 2015-07-20 11:56:59 +0200, Hendrik Leppkes wrote:
> ---
> tests/checkasm/h264pred.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tests/checkasm/h264pred.c b/tests/checkasm/h264pred.c
> index a5eb033..c88da45 100644
> --- a/tests/checkasm/h264pred.c
> +++ b/tests/checkasm/h264pred.c
---
tests/checkasm/h264pred.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/checkasm/h264pred.c b/tests/checkasm/h264pred.c
index a5eb033..6d59d8c 100644
--- a/tests/checkasm/h264pred.c
+++ b/tests/checkasm/h264pred.c
@@ -88,6 +88,7 @@ static const char * const pred8x8_modes[4][11] = {
---
tests/checkasm/h264pred.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/checkasm/h264pred.c b/tests/checkasm/h264pred.c
index a5eb033..c88da45 100644
--- a/tests/checkasm/h264pred.c
+++ b/tests/checkasm/h264pred.c
@@ -88,6 +88,7 @@ static const char * const pred8x8_modes[4][11] = {
Avoids a relocation which might end out of range for thumb2.
Reported-By: Ludovic Fauvet
Bug-Id: https://bugs.webkit.org/show_bug.cgi?id=137022
CC: libav-sta...@libav.org
---
libavcodec/arm/videodsp_armv5te.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/arm/vi
Quoting Vittorio Giovara (2015-07-15 19:41:22)
> The rationale is that coded_frame was only used to communicate key_frame,
> pict_type and quality to the caller, as well as a few other random fields,
> in a non predictable, let alone consistent way.
>
> There was agreement that there was no use ca
Quoting Vittorio Giovara (2015-07-15 19:41:21)
> This is necessary to preserve the quality information currently exported
> with coded_frame. Add the new side data to every encoder that needs it,
> and use it in avconv.
>
> Signed-off-by: Vittorio Giovara
Fine with me.
--
Anton Khirnov
___
Quoting Vittorio Giovara (2015-07-15 19:41:20)
> Allocating coded_frame is what most encoders do anyway, so it makes
> sense to always allocate it in a single place. This bring uniformity to
> encoder behaviour and prevents applications from erroneusly accessing
> this field when not allocated.
>
Quoting Vittorio Giovara (2015-07-07 13:12:32)
> This option is extremely codec specific and only a few codecs employ it.
> Move it to codec private options instead: mpegenc family only support 3
> values, xavs and x264 use 5, while xvid has a different metric (0-6).
>
> Signed-off-by: Vittorio Gi
50 matches
Mail list logo
