On Sat, Oct 1, 2016 at 5:35 PM, Martin Storsjö wrote:
> On Sat, 1 Oct 2016, Vittorio Giovara wrote:
>
>> On Wed, Sep 28, 2016 at 2:01 AM, Anton Khirnov wrote:
>>>
>>> Quoting Vittorio Giovara (2016-09-28 00:12:00)
---
libavformat/avidec.c | 6 +-
1 file changed, 1 inserti
On 10/1/2016 10:48 AM, Anton Khirnov wrote:
> Quoting Mark Thompson (2016-10-01 11:26:09)
>> ---
>> Tested on Kaby Lake.
>
> Looks simple enough to be ok. I guess it also deserves a changelog
> entry.
>
>>
>> CQP (well, C q_idx) and CBR mode implemented. Some vestigial B-frame-alike
>> support,
On Sat, 1 Oct 2016, Vittorio Giovara wrote:
On Wed, Sep 28, 2016 at 2:01 AM, Anton Khirnov wrote:
Quoting Vittorio Giovara (2016-09-28 00:12:00)
---
libavformat/avidec.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index
On 01/10/16 21:22, Anton Khirnov wrote:
> Errors during decoding are currently considered non-fatal and do not
> terminate transcoding, so even if parts of the data are corrupted, the
> rest may be decodable.
>
> However, that should apply only to the actual decoding calls, not to the
> failures e
On Wed, Sep 28, 2016 at 2:01 AM, Anton Khirnov wrote:
> Quoting Vittorio Giovara (2016-09-28 00:12:00)
>> ---
>> libavformat/avidec.c | 6 +-
>> 1 file changed, 1 insertion(+), 5 deletions(-)
>>
>> diff --git a/libavformat/avidec.c b/libavformat/avidec.c
>> index 3666b57..92ff428 100644
>> --
On Sat, Oct 1, 2016 at 3:22 PM, Anton Khirnov wrote:
> The filtergraph's existence is used in several places to mean that the
> filtergraph is fully configured. This causes problems if it's allocated,
> but the initialization fails (e.g. if a non-existent filter is
> specified).
> ---
> avconv_fi
On Sat, Oct 1, 2016 at 3:30 PM, Luca Barbato wrote:
> Confirmed to work by checkasm.
> ---
> libavcodec/ppc/huffyuvdsp_altivec.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/ppc/huffyuvdsp_altivec.c
> b/libavcodec/ppc/huffyuvdsp_altivec.c
> index 33
On Sat, Oct 1, 2016 at 3:26 PM, Luca Barbato wrote:
> ---
> libavcodec/huffyuvdsp.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/huffyuvdsp.c b/libavcodec/huffyuvdsp.c
> index b5a714d..0fd6fd7 100644
> --- a/libavcodec/huffyuvdsp.c
> +++ b/libavcodec/huffyuvdsp.c
> @@ -12
Confirmed to work by checkasm.
---
libavcodec/ppc/huffyuvdsp_altivec.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/ppc/huffyuvdsp_altivec.c
b/libavcodec/ppc/huffyuvdsp_altivec.c
index 337328a..7c34a67 100644
--- a/libavcodec/ppc/huffyuvdsp_altivec.c
+++
On 01/10/16 20:54, Alexandra Hájková wrote:
> ---
> The name of the file with the test was changed to huffyuv.c
>
> tests/checkasm/Makefile |1 +
> tests/checkasm/checkasm.c |3 ++
> tests/checkasm/checkasm.h |1 +
> tests/checkasm/huffyuv.c | 74
> ++
---
libavcodec/huffyuvdsp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/huffyuvdsp.c b/libavcodec/huffyuvdsp.c
index b5a714d..0fd6fd7 100644
--- a/libavcodec/huffyuvdsp.c
+++ b/libavcodec/huffyuvdsp.c
@@ -129,4 +129,6 @@ av_cold void ff_huffyuvdsp_init(HuffYUVDSPContext *c)
The filtergraph's existence is used in several places to mean that the
filtergraph is fully configured. This causes problems if it's allocated,
but the initialization fails (e.g. if a non-existent filter is
specified).
---
avconv_filter.c | 16 ++--
1 file changed, 10 insertions(+), 6
Errors during decoding are currently considered non-fatal and do not
terminate transcoding, so even if parts of the data are corrupted, the
rest may be decodable.
However, that should apply only to the actual decoding calls, not to the
failures elsewhere (e.g. configuring filters).
---
avconv.c |
---
The name of the file with the test was changed to huffyuv.c
tests/checkasm/Makefile |1 +
tests/checkasm/checkasm.c |3 ++
tests/checkasm/checkasm.h |1 +
tests/checkasm/huffyuv.c | 74 +
4 files changed, 79 insertions(+)
create mo
On 01/10/16 17:54, alexan...@oboro.libav.org wrote:
> tests/checkasm/huffyuv_add_bytes.c | 74
>
The context has more fields, please rename the filename to huffyuv for
consistency.
lu
___
libav-devel mailing list
On 01/10/16 10:44, Anton Khirnov wrote:
> The Intel binary iHD driver does not support the
> VASurfaceAttribMemoryType, so surface allocation will fail when using
> it.
> ---
> doc/APIchanges | 3 +++
> libavutil/hwcontext_vaapi.c | 8 +++-
> libavutil/hwcontext_vaapi.h | 6 ++
On 01/10/16 16:23, Mark Thompson wrote:
> This did fix the ordering problem, but Anton noted that it was still wrong.
> Here's another go...
Probably ok.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-
On Sat, Oct 1, 2016 at 4:12 AM, Anton Khirnov wrote:
> Bug-Id: 966
> ---
> libavcodec/h264dec.c | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index 2c5a7db..330a74d 100644
> --- a/libavcodec/h264dec.c
> +
From: Alexandra Hájková
---
tests/checkasm/Makefile|1 +
tests/checkasm/checkasm.c |3 ++
tests/checkasm/checkasm.h |1 +
tests/checkasm/huffyuv_add_bytes.c | 74
4 files changed, 79 insertions(+)
create mode 10064
A decoder may need this to be set correctly to output frames in the
right order.
---
On 30/09/16 17:56, Mark Thompson wrote:
> stuff
This did fix the ordering problem, but Anton noted that it was still wrong.
Here's another go...
libavcodec/vaapi_encode_h265.c | 8
1 file changed, 4
On 01/10/16 11:03, Mark Thompson wrote:
> ---
> Indirectly requested by Anton.
>
> No B-frames:
>
> @162 VUI: bitstream_restriction_flag 1 ( 1)
> @163 VUI: motion_vectors_over_pic_boundaries_flag 0 ( 0)
> @164 VUI: max_bytes_per_pic_denom
On 01/10/16 09:44, Anton Khirnov wrote:
> The Intel binary iHD driver does not support the
> VASurfaceAttribMemoryType, so surface allocation will fail when using
> it.
> ---
> doc/APIchanges | 3 +++
> libavutil/hwcontext_vaapi.c | 8 +++-
> libavutil/hwcontext_vaapi.h | 6 ++
Quoting Mark Thompson (2016-10-01 11:26:09)
> ---
> Tested on Kaby Lake.
Looks simple enough to be ok. I guess it also deserves a changelog
entry.
>
> CQP (well, C q_idx) and CBR mode implemented. Some vestigial B-frame-alike
> support, but not actually working: it will need some more thought
On 01/10/16 10:12, Anton Khirnov wrote:
> Bug-Id: 966
> ---
> libavcodec/h264dec.c | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
sounds ok.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mail
Quoting Mark Thompson (2016-10-01 11:36:36)
> ---
> framerate is upside down. (Not noticed earlier because it is rarely set, and
> never by avconv.)
>
>
> libavcodec/vaapi_encode_h264.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode_h264.c
From: Alexandra Hájková
---
All the review comments applied.
libavcodec/x86/hevc_idct.asm | 776 +++--
libavcodec/x86/hevcdsp_init.c | 42 +++
2 files changed, 797 insertions(+), 21 deletions(-)
diff --git a/libavcodec/x86/hevc_idct.asm b/libavcodec/x86/
On 01/10/16 10:47, Anton Khirnov wrote:
> ---
> avconv.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/avconv.c b/avconv.c
> index 59eb300..87923b9 100644
> --- a/avconv.c
> +++ b/avconv.c
> @@ -1978,6 +1978,8 @@ static int init_output_stream_encode(OutputStream *ost)
>
---
Indirectly requested by Anton.
No B-frames:
@162 VUI: bitstream_restriction_flag 1 ( 1)
@163 VUI: motion_vectors_over_pic_boundaries_flag 0 ( 0)
@164 VUI: max_bytes_per_pic_denom 1 ( 0)
@165 VUI: max_bi
---
avconv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/avconv.c b/avconv.c
index 59eb300..87923b9 100644
--- a/avconv.c
+++ b/avconv.c
@@ -1978,6 +1978,8 @@ static int init_output_stream_encode(OutputStream *ost)
ost->filter->filter->inputs[0]->sample_aspect_ratio;
---
framerate is upside down. (Not noticed earlier because it is rarely set, and
never by avconv.)
libavcodec/vaapi_encode_h264.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 020f892..e90ed64 10064
---
Tested on Kaby Lake.
CQP (well, C q_idx) and CBR mode implemented. Some vestigial B-frame-alike
support, but not actually working: it will need some more thought about how to
construct the superframes from the output buffers.
configure | 3 +
libavcodec/Makefile
The Intel binary iHD driver does not support the
VASurfaceAttribMemoryType, so surface allocation will fail when using
it.
---
doc/APIchanges | 3 +++
libavutil/hwcontext_vaapi.c | 8 +++-
libavutil/hwcontext_vaapi.h | 6 ++
libavutil/version.h | 2 +-
4 files changed,
Bug-Id: 966
---
libavcodec/h264dec.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 2c5a7db..330a74d 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -530,7 +530,24 @@ static int decode_nal_un
33 matches
Mail list logo
