x29 (FP) is a callee saved register and should be restored on
return. Instead of backing up x29 and restoring it here, back up
sp in a register that we are allowed to overwrite.
This fixes crashes in checkasm on aarch64 since f1b3e1313851.
For some reason, gcc builds didn't crash, but clang builds
This can be useful to filter out noise in known-broken scenarios like
miscompilation by legacy compilers and similar.
---
Now adds a "fate-" prefix to the test name on its own.
configure | 4
tests/Makefile | 2 ++
2 files changed, 6 insertions(+)
diff --git a/configure b/configure
in
Useful to test protocols that require options to be used.
---
tools/aviocat.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/tools/aviocat.c b/tools/aviocat.c
index 59244a8..fffcbe3 100644
--- a/tools/aviocat.c
+++ b/tools/aviocat.c
@@ -26,7 +26,8 @@
On Tue, 18 Oct 2016, Luca Barbato wrote:
Useful to test protocols that require options to be used.
---
tools/aviocat.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/tools/aviocat.c b/tools/aviocat.c
index 59244a8..fffcbe3 100644
--- a/tools/aviocat.c
On Tue, 18 Oct 2016, Diego Biurrun wrote:
This can be useful to filter out noise in known-broken scenarios like
miscompilation by legacy compilers and similar.
---
Now adds a "fate-" prefix to the test name on its own.
configure | 4
tests/Makefile | 2 ++
2 files changed, 6 insertions
The previous commit lacked this.
---
Looks like the hashes weren't updated...
tests/ref/fate/filter-pixfmts-scale | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/ref/fate/filter-pixfmts-scale
b/tests/ref/fate/filter-pixfmts-scale
index 97f29be..2a60f72 100644
--- a/tes
On Tue, 18 Oct 2016, Martin Storsjö wrote:
x29 (FP) is a callee saved register and should be restored on
return. Instead of backing up x29 and restoring it here, back up
sp in a register that we are allowed to overwrite.
This fixes crashes in checkasm on aarch64 since f1b3e1313851.
For some rea
On 18/10/2016 14:55, Martin Storsjö wrote:
> Should the dictionary be freed afterwards (in case it contained options
> that weren't used), to make sure it doesn't show any leaks if ran in
> valgrind?
You are absolutely right! Thank you, locally updated =)
lu
__
On Tue, 18 Oct 2016, Luca Barbato wrote:
The previous commit lacked this.
---
Looks like the hashes weren't updated...
tests/ref/fate/filter-pixfmts-scale | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/ref/fate/filter-pixfmts-scale
b/tests/ref/fate/filter-pixfmts-sca
On 18/10/2016 16:10, Vittorio Giovara wrote:
> How about
>
>
> fate: Update gbrap12le hash
>
> Missing from be9dba5c8abc6ecf0b8ee4ccb11c7850327fcf8d.
>
>
Fine for me.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailma
How about
fate: Update gbrap12le hash
Missing from be9dba5c8abc6ecf0b8ee4ccb11c7850327fcf8d.
On Tue, Oct 18, 2016 at 9:00 AM, Luca Barbato wrote:
> The previous commit lacked this.
> ---
>
> Looks like the hashes weren't updated...
>
> tests/ref/fate/filter-pixfmts-scale | 2 +-
> 1 file cha
This work is sponsored by, and copyright, Google.
These are ported from the ARM version; thanks to the larger
amount of registers available, we can do the 16x16 and 32x32
transforms in slices 8 pixels wide instead of 4. This gives
a speedup of around 1.4x compared to the 32 bit version.
The fact
This work is sponsored by, and copyright, Google.
For the transforms up to 8x8, we can fit all the data (including
temporaries) in registers and just do a straightforward transform
of all the data. For 16x16, we do a transform of 4x16 pixels in
4 slices, using a temporary buffer. For 32x32, we tra
Avoids superfluous error message spam after
8e2ea691351c5079cdab245ff7bfa5c0f3e3bfe4
---
libavformat/utils.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 1c93326..37ba5a8 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@
On 18/10/2016 20:50, Anton Khirnov wrote:
> Avoids superfluous error message spam after
> 8e2ea691351c5079cdab245ff7bfa5c0f3e3bfe4
> ---
> libavformat/utils.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 1c93326..37ba5a8 10
Those values are decoder-independent and are also use by the VA-API
encoder.
---
Sorry for the previous breakage, updated my libva-dev so it shouldn't happen
again.
I think this is the more proper thing to do, the intent is that hevcdec.h should
only be included by the decoder itself.
---
libavco
---
libavcodec/hevcdec.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index db45608..e58d5f8 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -1684,6 +1684,8 @@ static void hls_prediction_unit(H
Quoting Diego Biurrun (2016-10-14 01:15:32)
> On Fri, Oct 14, 2016 at 01:13:42AM +0200, Diego Biurrun wrote:
> > On Thu, Oct 13, 2016 at 07:03:01PM -0400, Vittorio Giovara wrote:
> > > --- /dev/null
> > > +++ b/tests/fate/mov.mak
> > > @@ -0,0 +1,12 @@
> > > +FATE_MOV += fate-mov-display-matrix
> >
Quoting Vittorio Giovara (2016-10-14 00:23:08)
> This is needed for improved fate testing and it is modeled after
> -show_format_entry. The main behavioral difference is that when a print
> function is called with an empty key, rather than discarding it, the
> closes key in the hierarchy is used in
Quoting Vittorio Giovara (2016-10-14 00:23:10)
> This matrix needs to be applied after all others have (currently only
> display matrix from trak), but cannot be handled in movie box, since
> streams are not allocated yet.
>
> So store it in main context and if not identity, apply it when appropri
On Tue, Oct 18, 2016 at 3:24 PM, Anton Khirnov wrote:
> Those values are decoder-independent and are also use by the VA-API
> encoder.
> ---
possibly ok
--
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/list
On Tue, Oct 18, 2016 at 3:24 PM, Anton Khirnov wrote:
> ---
> libavcodec/hevcdec.c | 20
> 1 file changed, 8 insertions(+), 12 deletions(-)
ok i think
--
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.li
On Tue, Oct 18, 2016 at 3:38 PM, Anton Khirnov wrote:
> Quoting Vittorio Giovara (2016-10-14 00:23:08)
>> This is needed for improved fate testing and it is modeled after
>> -show_format_entry. The main behavioral difference is that when a print
>> function is called with an empty key, rather than
---
libavcodec/options_table.h | 1 +
libavutil/pixdesc.c| 1 +
libavutil/pixfmt.h | 1 +
3 files changed, 3 insertions(+)
diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index 5090806..04cb20d 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_t
For 'nclx', the latest edition of the standard switched from JPEG XR
to 23001-8, which matches the current order of our entries.
For 'nclc', qtff edition 2016-09-13 introduced a few new entries.
Signed-off-by: Vittorio Giovara
---
libavformat/mov.c | 16 ++--
1 file changed, 6 insert
It didn't take into account the new pattern used for bitstream filters
and protocols.
---
Makefile | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 34f0c9c..d76173c 100644
--- a/Makefile
+++ b/Makefile
@@ -121,8 +121,14 @@ $(TOOLS): %$(EXESUF): %
26 matches
Mail list logo