[libav-devel] [PATCH] configure: Support MSVC 2015

2015-06-07 Thread Luca Barbato
The C runtime C99 compatibility had been improved a lot and it now
rejects some of the compatibility defines provided for the older
versions.

Many thanks to Ray for the time spent testing.

Bug-Id: 864
CC: libav-sta...@libav.org
---

Martin does it sound ok for you?

 configure| 22 ++
 libavutil/internal.h | 11 ++-
 2 files changed, 16 insertions(+), 17 deletions(-)

diff --git a/configure b/configure
index 18f0518..c8a799d 100755
--- a/configure
+++ b/configure
@@ -3021,9 +3021,6 @@ probe_cc(){
 _ld_path='-libpath:'
 _flags='-nologo'
 _cflags='-D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS 
-Dinline=__inline -FIstdlib.h -Dstrtoll=_strtoi64'
-if [ $pfx = hostcc ]; then
-append _cflags -Dsnprintf=_snprintf
-fi
 elif $_cc 21 | grep -q Intel; then
 _type=icl
 _ident=$($_cc 21 | head -n1)
@@ -3047,9 +3044,6 @@ probe_cc(){
 # -Qvec- -Qsimd- to prevent miscompilation, -GS for consistency
 # with MSVC which enables it by default.
 _cflags='-D_USE_MATH_DEFINES -FIstdlib.h -Dstrtoll=_strtoi64 -Qms0 
-Qvec- -Qsimd- -GS'
-if [ $pfx = hostcc ]; then
-append _cflags -Dsnprintf=_snprintf
-fi
 elif $_cc --version 2/dev/null | grep -q ^cparser; then
 _type=cparser
 _ident=$($_cc --version | head -n1)
@@ -3743,6 +3737,16 @@ probe_libc(){
 add_${pfx}cppflags -D__printf__=__gnu_printf__
 elif check_${pfx}cpp_condition crtversion.h defined 
_VC_CRT_MAJOR_VERSION; then
 eval ${pfx}libc_type=msvcrt
+if check_${pfx}cpp_condition crtversion.h _VC_CRT_MAJOR_VERSION  
14; then
+if [ $pfx = host_ ]; then
+add_host_cppflags -Dsnprintf=_snprintf
+else
+add_compat strtod.o strtod=avpriv_strtod
+add_compat msvcrt/snprintf.o snprintf=avpriv_snprintf   \
+ _snprintf=avpriv_snprintf  \
+ vsnprintf=avpriv_vsnprintf
+fi
+fi
 # The MSVC 2010 headers (Win 7.0 SDK) set _WIN32_WINNT to
 # 0x601 by default unless something else is set by the user.
 # This can easily lead to us detecting functions only present
@@ -3773,12 +3777,6 @@ case $libc_type in
 bionic)
 add_compat strtod.o strtod=avpriv_strtod
 ;;
-msvcrt)
-add_compat strtod.o strtod=avpriv_strtod
-add_compat msvcrt/snprintf.o snprintf=avpriv_snprintf   \
- _snprintf=avpriv_snprintf  \
- vsnprintf=avpriv_vsnprintf
-;;
 esac

 # hacks for compiler/libc/os combinations
diff --git a/libavutil/internal.h b/libavutil/internal.h
index 800680a..4264c4e 100644
--- a/libavutil/internal.h
+++ b/libavutil/internal.h
@@ -130,11 +130,6 @@

 #include libm.h

-#if defined(_MSC_VER)
-#pragma comment(linker, /include:EXTERN_PREFIXavpriv_strtod)
-#pragma comment(linker, /include:EXTERN_PREFIXavpriv_snprintf)
-#endif
-
 /**
  * Return NULL if CONFIG_SMALL is true, otherwise the argument
  * without modification. Used to disable the definition of strings
@@ -208,6 +203,12 @@ void avpriv_request_sample(void *avc,
const char *msg, ...) av_printf_format(2, 3);

 #if HAVE_LIBC_MSVCRT
+#include crtversion.h
+#if defined(_VC_CRT_MAJOR_VERSION)  _VC_CRT_MAJOR_VERSION  14
+#pragma comment(linker, /include:EXTERN_PREFIXavpriv_strtod)
+#pragma comment(linker, /include:EXTERN_PREFIXavpriv_snprintf)
+#endif
+
 #define avpriv_open ff_open
 #endif

--
1.9.0

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


Re: [libav-devel] [PATCH 5/6] avio: Add avio_read wrapper to simplify error checking

2015-06-07 Thread Luca Barbato
On 07/06/15 16:30, Andreas Cadhalpun wrote:
 It seems Luca accidentally pushed an old version of this patch.
 The pushed version still has the ffio_read_size name and Luca's
 comment about the error handling is also not addressed.

Good thing it is an internal function and thanks for spotting!

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


Re: [libav-devel] [PATCH 5/6] avio: Add avio_read wrapper to simplify error checking

2015-06-07 Thread Andreas Cadhalpun
On 01.06.2015 09:13, Luca Barbato wrote:
 On 01/06/15 00:37, Andreas Cadhalpun wrote:
 Since I don't expect that many people would start using that function before
 a release, I think delaying this doesn't do much good. But then, it doesn't
 do much harm either, for precisely the same reason.

 So do as you see fit. ;)

 But I can't guarantee that I'll think of pinging this at the right moment
 before the release.

 
 I added to the release must-have.

Thanks.

 Do we have other API that would be nice to have exposed?

At least Kodi uses avformat_flush, which is how FFmpeg exposes
ff_read_frame_flush.

Best regards,
Andreas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel


[libav-devel] [PATCH] vp8: check for too large dimensions

2015-06-07 Thread Andreas Cadhalpun
If the dimensions are too large, s-mb_width or s-mb_height can become
too large, leading to an int16_t overflow of s-mv_max.{x,y}.

Signed-off-by: Andreas Cadhalpun andreas.cadhal...@googlemail.com
---
 libavcodec/vp8.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index dbba568..69cf138 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -145,6 +145,8 @@ static VP8Frame *vp8_find_free_buffer(VP8Context *s)
 return frame;
 }
 
+#define MARGIN (16  2)
+#define MAX_MB_SIZE (((INT16_MAX - MARGIN)  6) + 1)
 static av_always_inline
 int update_dimensions(VP8Context *s, int width, int height, int is_vp7)
 {
@@ -160,6 +162,13 @@ int update_dimensions(VP8Context *s, int width, int 
height, int is_vp7)
 return ret;
 }
 
+if (s-avctx-coded_width   MAX_MB_SIZE * 16 ||
+s-avctx-coded_height  MAX_MB_SIZE * 16) {
+av_log(s-avctx, AV_LOG_ERROR, too large dimensions %dx%d\n,
+   s-avctx-coded_width, s-avctx-coded_height);
+return AVERROR_INVALIDDATA;
+}
+
 s-mb_width  = (s-avctx-coded_width  + 15) / 16;
 s-mb_height = (s-avctx-coded_height + 15) / 16;
 
@@ -2177,7 +2186,6 @@ void filter_mb_simple(VP8Context *s, uint8_t *dst, 
VP8FilterStrength *f,
 }
 }
 
-#define MARGIN (16  2)
 static av_always_inline
 void vp78_decode_mv_mb_modes(AVCodecContext *avctx, VP8Frame *curframe,
 VP8Frame *prev_frame, int is_vp7)
-- 
2.1.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel


Re: [libav-devel] [PATCH 5/6] avio: Add avio_read wrapper to simplify error checking

2015-06-07 Thread Andreas Cadhalpun
On 26.05.2015 16:41, Vittorio Giovara wrote:
 On Tue, May 26, 2015 at 3:24 PM, wm4 nfx...@googlemail.com wrote:
 On Tue, 26 May 2015 14:24:38 +0100
 Vittorio Giovara vittorio.giov...@gmail.com wrote:
 +int ffio_read_size(AVIOContext *s, unsigned char *buf, int size)
 +{
 +int ret = avio_read(s, buf, size);
 +if (ret != size)
 +return AVERROR_INVALIDDATA;
 +return ret;
 +}
 +
  int ffio_read_indirect(AVIOContext *s, unsigned char *buf, int size, const 
 unsigned char **data)
  {
  if (s-buf_end - s-buf_ptr = size  !s-write_flag) {

 The name of the function has the wrong color. Wouldn't ffio_read_full()
 be a better name?
 
 yes...
 amended locally

It seems Luca accidentally pushed an old version of this patch.
The pushed version still has the ffio_read_size name and Luca's
comment about the error handling is also not addressed.

Best regards,
Andreas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel


Re: [libav-devel] [PATCH] lavf: add a format flag for separate carriers, and an event for detecting carrier presence.

2015-06-07 Thread John Högberg
Luca Barbato wrote:
 I was waiting for Anton, I'm more and more convinced that the feature is
 important and I'm planning to fit it in the avformat API that will match
 the avcodec API I detailed here[1].

 I'm not sure about the name, but they can be changed later.
 
 lu


 [1]: https://blogs.gentoo.org/lu_zero/2015/03/23/decoupling-an-api/

Cool, it looks like that might solve a few issues of mine. Aside from the blog,
is there a discussion thread for this somewhere?

On topic, should I go ahead with submitting the patch for MPEG-TS?

Regards,
John Högberg
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel


Re: [libav-devel] [PATCH] Introduce a TextureDSP module

2015-06-07 Thread Vittorio Giovara
On Sat, Jun 6, 2015 at 4:27 AM, James Almer jamr...@gmail.com wrote:
 On 02/06/15 8:09 AM, Vittorio Giovara wrote:
 +/* Alpha compression function */
 +static void compress_alpha(uint8_t *dst, ptrdiff_t stride, const uint8_t 
 *block)
 +{
 +int i, j;
 +int dist, bias, dist4, dist2, bits, mask;
 +int mn, mx;
 +
 +/* Find min/max color */
 +mn = mx = block[3];
 +for (j = 0; j  4; j++) {
 +for (i = 0; i  4; i++) {
 +int val = block[3 + i * 4 + j * stride];
 +if (val  mn)
 +mn = val;
 +else if (val  mx)
 +mx = val;
 +}
 +}
 +
 +AV_ZERO64(dst);

 Documentation for AV_ZERO* says Parameters for AV_COPY*, AV_SWAP*,
 AV_ZERO* must be naturally aligned. They may be implemented using MMX,
 so emms_c() must be called before using any float code afterwards.

 Make sure fate passes on x86_32 (targeting anything above i686, which
 is when AV_ZERO64 is implemented with MMX movq) as you're using float
 code all around.
 If it doesn't, then maybe you could bench to see if using AV_WN64 is
 faster than AV_ZERO64 + emms_c().

Meh that's waaay overkill, especially for an encoder like this. Given
the algorithm, only the first two elements need to be zero'd and all
the others are initialized in some way just below. So I'll change the
implementation to AV_RL16(dst, 0) which is simpler and faster anyway.
Thanks for your comment.
-- 
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel


Re: [libav-devel] [PATCH] configure: Support MSVC 2015

2015-06-07 Thread Luca Barbato
On 06/06/15 20:58, Luca Barbato wrote:
 On 05/06/15 19:48, Luca Barbato wrote:
 The C runtime C99 compatibility had been improved a lot and it now
 rejects some of the compatibility defines provided for the older
 versions.

 Many thanks to Ray for the time spent testing.

 Bug-Id: 864
 CC: libav-sta...@libav.org
 ---

 Disable the pragma linking trick as well.

 
 It is in oracle now, I'd merge it once the run finishes successfully.
 

Oracle spotted a mistake =) running it again with the fix.

lu

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