- 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 3 commits
-
-
wm4 authored
There is no need to have this mess in network.c. Signed-off-by: Martin Storsjö <martin@martin.st>
-
wm4 authored
Move the OpenSSL and GnuTLS implementations to their own files. Other than the connection code (including options) and some boilerplate, no code is actually shared. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Sebastian Ramacher authored
Signed-off-by: Sebastian Ramacher <sramacher@debian.org> Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
- 25 May, 2015 1 commit
-
-
Steve Lhomme authored
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
- 22 May, 2015 7 commits
-
-
Vittorio Giovara authored
-
Vittorio Giovara authored
-
Vittorio Giovara authored
This skips setting the memory to 0 but allows for reuse on different contextes. Oracle did not report any unsual activity because of it.
-
Vittorio Giovara authored
The field is unused.
-
Vittorio Giovara authored
It is just a duplicate of an AVCodecContext member so use it instead.
-
Vittorio Giovara authored
They are just duplicates of AVCodecContext members so use those instead.
-
James Almer authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 21 May, 2015 3 commits
-
-
Martin Storsjö authored
These aren't necessary any longer. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Since the underlying URLContext read functions are used, they handle interruption, without having to handle it at this level. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This avoids hijacking the fd, by reading using the normal URLContext functions instead. This allowing reading data that has been buffered in the underlying URLContext. This avoids using the libraries own send functions that can cause SIGPIPE. The fd is still used for polling the lowlevel socket, for waiting for retries. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 19 May, 2015 3 commits
-
-
wm4 authored
Personally, I need the decoder to back out if get_format() returns no usable pixel format. This didn't work because the error code was not propagated down the call chain. This in turn happened because the variable declaration removed in this patch shadowed the variable, whose value is returned at the end of the function. Consequently, failures of decode_nal_unit() were ignored in this place. Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com> Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Vittorio Giovara authored
af_ashowinfo, due to the enum AVAudioServiceType use.
-
Vittorio Giovara authored
Some clients incorrectly set 24 as bits_per_coded_sample, while the actual value is preserved in one of the codec headers. In order to work around this, delay the check until decode_frame(). Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
-
- 16 May, 2015 1 commit
-
-
Timothy Gu authored
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
- 13 May, 2015 2 commits
-
-
Stefano Pigozzi authored
This is useful for client programs to ask for nv12 surfaces instead of the current default (uyvy), since those are more efficient to decode to. Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
Gopu Govindaswamy authored
Use the Multi-library interface to load at runtime x265 libraries supporting alternative bit depths (e.g. 8bit and 16bit). The linked library will try to load the library supporting the pixel format if it is not supported by itself. Fallback requesting the native library (passing 0 to x265_api_get) if a library supporting the requested bit depth is not available. Signed-off-by: Gopu Govindaswamy <gopu@multicorewareinc.com> Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com> Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
- 12 May, 2015 1 commit
-
-
Shiina Hideaki authored
The header had a wrong version description. Bug-Id: 808 Signed-off-by: Shiina Hideaki <shiina@yndrd.com> Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
-