- 31 May, 2015 20 commits
-
-
Vittorio Giovara authored
Signed-off-by:
Luca Barbato <lu_zero@gentoo.org>
-
Andreas Cadhalpun authored
In this case the mov demuxer can return a large number of empty packets. Signed-off-by:
Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com> Signed-off-by:
Luca Barbato <lu_zero@gentoo.org>
-
Andreas Cadhalpun authored
Otherwise the loop can take a lot of time if num_descr is very large. Signed-off-by:
Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com> Signed-off-by:
Luca Barbato <lu_zero@gentoo.org>
-
Luca Barbato authored
It can be reallocated. CC: libav-stable@libav.org
-
Andreas Cadhalpun authored
Signed-off-by:
Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com> Signed-off-by:
Luca Barbato <lu_zero@gentoo.org> CC: libav-stable@libav.org
-
Vittorio Giovara authored
-
James Almer authored
Signed-off-by:
James Almer <jamrial@gmail.com> Signed-off-by:
Luca Barbato <lu_zero@gentoo.org>
-
James Almer authored
Signed-off-by:
James Almer <jamrial@gmail.com> Signed-off-by:
Luca Barbato <lu_zero@gentoo.org>
-
James Almer authored
Signed-off-by:
James Almer <jamrial@gmail.com> Signed-off-by:
Luca Barbato <lu_zero@gentoo.org>
-
Luca Barbato authored
Use a macro to abstract the endianness.
-
Luca Barbato authored
-
Luca Barbato authored
-
Luca Barbato authored
In Little Endian the vec_ld/vec_st operations work as expected only for byte-vectors.
-
Luca Barbato authored
POWER 7 and POWER 8 support VSX and ldbrx. POWER 8 supports additional extended VSX instructions introduced with ISA 2.07.
-
Luca Barbato authored
Add POWER entries.
-
Luca Barbato authored
Should prevent trying to use altivec when it is disabled by the kernel.
-
Luca Barbato authored
-
Luca Barbato authored
-
Luca Barbato authored
The compiler is free to optimize such expressions in any sort of way.
-
wm4 authored
OSX does not know MSG_NOSIGNAL. BSD (which OSX is based on) has got the socket option SO_NOSIGPIPE (even if modern BSDs also support MSG_NOSIGNAL). Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 30 May, 2015 2 commits
-
-
Luca Barbato authored
Bug-Id: CVE-2015-3417 CC: libav-stable@libav.org
-
Luca Barbato authored
As done in msrle_decode_8_16_24_32. Bug-Id: CVE-2015-3395 CC: libav-stable@libav.org
-
- 29 May, 2015 8 commits
-
-
Martin Storsjö authored
Don't use a PRNG for generating it; that defies the intended use within the cryptograhic handshake. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
There was a misunderstanding betewen bits and bytes for the parameter value for generating random big numbers. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This helps if these functions need to be implemented using another crypto API. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 28 May, 2015 9 commits
-
-
wm4 authored
This was probably broken some time ago. The breakage is now part of the ABI. For example, we have: AV_PIX_FMT_XYZ12BE AV_PIX_FMT_NV16 AV_PIX_FMT_NV20LE AV_PIX_FMT_NV20LE is wrong. It has the value 113, but as little-endian format it should be even. This must have been quite obvious when these formats were added (because of the AV_PIX_FMT_XYZ12BE entry), but nobody cared or knew about this. The future libavutil major bump will also break this additionally, because disabling FF_API_VDPAU will remove an odd number of entries from the middle of the enum. Signed-off-by:
Luca Barbato <lu_zero@gentoo.org>
-
Michael Niedermayer authored
Simplifies the code and makes it build on certain compilers running out of registers on x86. CC: libav-stable@libav.org Reported-By: mudler
-
Anton Khirnov authored
-
Anton Khirnov authored
Such tables are not used anywhere currently, but that should change.
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Vittorio Giovara authored
Code is small enough that there is no advantage in a separate function.
-
Martin Storsjö authored
This fixes building with gcrypt-backed gnutls versions, broken in 57cde2b1. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Timothy Gu authored
Silences warning(s) like: libavcodec/x86/fft.asm:93: warning: section flags ignored on section redeclaration The cause of this warning is that because `struc` and `endstruc` attempts to revert to the previous section state [1]. The section state is stored in the macro __SECT__, defined by x86inc.asm to be `.note.GNU-stack ...`, through the `SECTION` directive [2]. Thus, the `.note.GNU-stack` section is defined twice (once in x86inc.asm, once during `endstruc`), causing the warning. That is the first part of the commit: using the primitive `[section]` format for .note.GNU-stack etc., which does not update `__SECT__` [2]. That fixes only half of the problem. Even without any `SECTION` directives, `__SECT__` is predefined as `.text`, which conflicting with the later `SECTION_TEXT` (which expands to `.text align=16`). [1]: http://www.nasm.us/doc/nasmdoc6.html#section-6.4 [2]: http://www.nasm.us/doc/nasmdoc6.html#section-6.3Signed-off-by:
Luca Barbato <lu_zero@gentoo.org>
-
- 26 May, 2015 1 commit
-
-
wm4 authored
There is no need to have this mess in network.c. Signed-off-by:
Martin Storsjö <martin@martin.st>
-