Re: [libav-devel] [PATCH] intreadwrite: Use __unaligned in MSVC for ARM64 as well

2018-01-16 Thread Luca Barbato 

On 16/01/2018 14:41, Martin Storsjö wrote:

This attribute is supported for this architecture in MSVC as well
(but produces errors if used for 32 bit x86).
---
  libavutil/intreadwrite.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/intreadwrite.h b/libavutil/intreadwrite.h
index 84685f0..94abb6c 100644
--- a/libavutil/intreadwrite.h
+++ b/libavutil/intreadwrite.h
@@ -192,7 +192,7 @@ union unaligned_16 { uint16_t l; } __attribute__((packed)) 
av_alias;
  #   define AV_RN(s, p) (((const union unaligned_##s *) (p))->l)
  #   define AV_WN(s, p, v) union unaligned_##s *) (p))->l) = (v))
  
-#elif defined(_MSC_VER) && (defined(_M_ARM) || defined(_M_X64)) && AV_HAVE_FAST_UNALIGNED

+#elif defined(_MSC_VER) && (defined(_M_ARM) || defined(_M_X64) || defined(_M_ARM64)) 
&& AV_HAVE_FAST_UNALIGNED
  
  #   define AV_RN(s, p) (*((const __unaligned uint##s##_t*)(p)))

  #   define AV_WN(s, p, v) (*((__unaligned uint##s##_t*)(p)) = (v))



Interesting :)

(patch ok)

lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH] intreadwrite: Use __unaligned in MSVC for ARM64 as well

2018-01-16 Thread Martin Storsjö 
This attribute is supported for this architecture in MSVC as well
(but produces errors if used for 32 bit x86).
---
 libavutil/intreadwrite.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/intreadwrite.h b/libavutil/intreadwrite.h
index 84685f0..94abb6c 100644
--- a/libavutil/intreadwrite.h
+++ b/libavutil/intreadwrite.h
@@ -192,7 +192,7 @@ union unaligned_16 { uint16_t l; } __attribute__((packed)) 
av_alias;
 #   define AV_RN(s, p) (((const union unaligned_##s *) (p))->l)
 #   define AV_WN(s, p, v) union unaligned_##s *) (p))->l) = (v))
 
-#elif defined(_MSC_VER) && (defined(_M_ARM) || defined(_M_X64)) && 
AV_HAVE_FAST_UNALIGNED
+#elif defined(_MSC_VER) && (defined(_M_ARM) || defined(_M_X64) || 
defined(_M_ARM64)) && AV_HAVE_FAST_UNALIGNED
 
 #   define AV_RN(s, p) (*((const __unaligned uint##s##_t*)(p)))
 #   define AV_WN(s, p, v) (*((__unaligned uint##s##_t*)(p)) = (v))
-- 
2.7.4

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [RFC] [PATCH] Set video strides to a custom type in preparation of a change to ptrdiff_t

2018-01-16 Thread Luca Barbato 

On 16/01/2018 12:41, wm4 wrote:

So, do we want this or not?


I like it a lot.

lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [RFC] [PATCH] Set video strides to a custom type in preparation of a change to ptrdiff_t

2018-01-16 Thread wm4 
On Fri,  5 Jan 2018 22:06:42 +0100
Vittorio Giovara  wrote:

> This patch introduces a new type, av_stride, which is set for any
> representation of strides or linesize, including AVFrame and av_image_*
> APIs. This is done in preparation of a future switch to ptrdiff_t, a
> better suited type to represent this type of data, in a way that it is
> atomically changed at the version bump.
> ---
> 
> This is a work in progress change that I was preparing and briefly discussed
> on IRC today, based on suggestion by wm4. I wanted to share this early to
> thread waters, as well as gather feedback on this approach. As a matter of
> fact I haven't fully tested this yet, but if the idea is welcome, I will
> extensively test it on Oracle.
> 
> The rationale of introducing this "temporary" type is to minimize impact on
> downstream, allowing a long enough transition time to API users to change
> their code. I say temporary because it is possible that in the very distant
> future it would be nice to be able to just the standard type instead of a
> custom one.
> 
> We considered other ideas, such as deprecating the current APIs and frame
> fields and introducing setters and getters but they seemed less elegant and
> more likely to induce annoying code breaks to our users.

I like this (at least more than the other alternatives). In addition to
being cleaner, this would allow us to support images with higher
resolutions, without having to fear to overflow stride calculations.

So, do we want this or not?
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel