On 29/03/2017 21:15, Ben Chang wrote:
> Thanks for the review. I have scratched the renaming alias. New patch
> has addition of "auto" in -level for both hevc and h264 in nvenc.
Looks good, thank you :)
lu
___
libav-devel mailing list
Hi Lu,
>> The change would break working scripts, you may add compatibility aliases,
>> but not remove the current ones.
Thanks for the review. I have scratched the renaming alias. New patch has
addition of "auto" in -level for both hevc and h264 in nvenc.
Thanks,
Ben
On Wed, 29 Mar 2017, Martin Storsjö wrote:
Previously, the former form always produced a manually aligned,
padded buffer, while the latter can use DECLARE_ALIGNED, if that
amount of stack alignment is supported.
---
The LOCAL_ALIGNED(4) case in hevc_mvs.c had to be removed, since we
don't have
On Wed, Mar 29, 2017 at 7:53 PM, Diego Biurrun wrote:
> On Wed, Mar 29, 2017 at 02:02:30PM +0300, Martin Storsjö wrote:
>> --- a/libavcodec/atrac3plusdsp.c
>> +++ b/libavcodec/atrac3plusdsp.c
>> @@ -177,12 +177,14 @@ static void waves_synth(Atrac3pWaveSynthParams
>>
On Wed, Mar 29, 2017 at 02:02:30PM +0300, Martin Storsjö wrote:
> --- a/libavcodec/atrac3plusdsp.c
> +++ b/libavcodec/atrac3plusdsp.c
> @@ -177,12 +177,14 @@ static void waves_synth(Atrac3pWaveSynthParams
> *synth_param,
> void ff_atrac3p_generate_tones(Atrac3pChanUnitCtx *ch_unit,
>
On Wed, Mar 29, 2017 at 02:02:32PM +0300, Martin Storsjö wrote:
> Previously, the former form always produced a manually aligned,
> padded buffer, while the latter can use DECLARE_ALIGNED, if that
> amount of stack alignment is supported.
> ---
> The LOCAL_ALIGNED(4) case in hevc_mvs.c had to be
On Wed, Mar 29, 2017 at 02:02:31PM +0300, Martin Storsjö wrote:
> The data types within the MvField struct themselves imply 4 byte alignment.
> ---
> libavcodec/hevc_mvs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
OK
Diego
___
On 29/03/2017 13:02, Martin Storsjö wrote:
> Should we settle on using LOCAL_ALIGNED(xx) consistently instead?
I'm all for consistency.
the set looks fine to me btw.
___
libav-devel mailing list
libav-devel@libav.org
On 29/03/2017 12:36, Luca Barbato wrote:
> On 29/03/2017 12:04, Vittorio Giovara wrote:
>> From: Anton Khirnov
>>
>> num_core_channels is always equal to s->audio_header.prim_channels,
>> neither one of those variables ever get changed.
>> ---
>> libavcodec/dcadec.c | 20
This fixes warnings like these with ARMCC:
alignment for an auto object may not be larger than 8
---
libavcodec/atrac3plusdsp.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/libavcodec/atrac3plusdsp.c b/libavcodec/atrac3plusdsp.c
index 468f098383..c1a54ae266
The data types within the MvField struct themselves imply 4 byte alignment.
---
libavcodec/hevc_mvs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hevc_mvs.c b/libavcodec/hevc_mvs.c
index be32e6cd40..27df7c1527 100644
--- a/libavcodec/hevc_mvs.c
+++
Previously, the former form always produced a manually aligned,
padded buffer, while the latter can use DECLARE_ALIGNED, if that
amount of stack alignment is supported.
---
The LOCAL_ALIGNED(4) case in hevc_mvs.c had to be removed, since we
don't have any LOCAL_ALIGNED_4 macro.
This avoids having
On 29/03/2017 12:04, Vittorio Giovara wrote:
> From: Anton Khirnov
>
> num_core_channels is always equal to s->audio_header.prim_channels,
> neither one of those variables ever get changed.
> ---
> libavcodec/dcadec.c | 20
> 1 file changed, 8
From: Anton Khirnov
num_core_channels is always equal to s->audio_header.prim_channels,
neither one of those variables ever get changed.
---
libavcodec/dcadec.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/libavcodec/dcadec.c
On 29/03/2017 01:35, Ben Chang wrote:
> Change profile option high_444 to high444p. And add auto option in
> level. This is to keep consistent naming between libav and ffmpeg and
> avoid confusion for users.
The change would break working scripts, you may add compatibility
aliases, but not remove
15 matches
Mail list logo