- 28 Dec, 2016 1 commit
-
-
Diego Biurrun authored
The (required) version numbers disappeared after edb43487.
-
- 25 Dec, 2016 1 commit
-
-
Diego Biurrun authored
-
- 24 Dec, 2016 1 commit
-
-
John Stebbins authored
The codec id for SRT was changed and conditionals were not updated.
-
- 23 Dec, 2016 2 commits
-
-
Martin Storsjö authored
A negative chunk size is illegal and would end up used as length for memcpy, where it would lead to memory accesses out of bounds. Found-by: Paul Cher <paulcher@icloud.com> CC: libav-stable@libav.org Signed-off-by: Martin Storsjö <martin@martin.st>
-
Diego Biurrun authored
-
- 22 Dec, 2016 3 commits
-
-
Diego Biurrun authored
This moves work from the configure to the Make stage where it can be parallelized and ensures that pkgconfig files are updated when library versions change. Bug-Id: 449
-
Diego Biurrun authored
This moves work from the configure to the Make stage where it can be parallelized and ensures that shared libraries are built with the right version number in the filename.
-
Diego Biurrun authored
This unclutters the top-level directory and groups related files together.
-
- 21 Dec, 2016 2 commits
-
-
Diego Biurrun authored
-
Ruta Gadkari authored
By default it is -1. Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
- 19 Dec, 2016 16 commits
-
-
Martin Storsjö authored
This fixes build failures for iOS, broken since cad42fad. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Alexandra Hájková authored
-
Alexandra Hájková authored
-
Alexandra Hájková authored
-
Anton Khirnov authored
Calling ff_h264_field_end() when the per-field state is not properly initialized leads to all kinds of undefined behaviour. CC: libav-stable@libav.org Bug-Id: 977 978 992
-
Anton Khirnov authored
For field picture, the first_field is set based on its previous value. Before this commit, first_field is set when reading the picture coding extension. However, in corrupted files there may be multiple picture coding extension headers, so the final value of first_field that is actually used during decoding can be wrong. That can lead to various undefined behaviour, like predicting from a non-existing field. Fix this problem, by setting first_field in mpeg_field_start(), which should be called exactly once per field. CC: libav-stable@libav.org Bug-ID: 999
-
Anton Khirnov authored
CC: libav-stable@libav.org Bug-Id: 981 Found-By: Agostino Sarubbo
-
Anton Khirnov authored
CC: libav-stable@libav.org Bug-Id: 981 Found-By: Agostino Sarubbo
-
Anton Khirnov authored
When the input string is too large, so the second condition in if () fails, the code will erroneously execute the else branch, indexing the mac_to_unicode table with a negative index. CC: libav-stable@libav.org Bug-Id: 1000 Found-By: Kamil Frankowicz
-
Anton Khirnov authored
-
Anton Khirnov authored
Partially based on a patch by Timo Rothenpieler <timo@rothenpieler.org>. Additional scaling list handling fix by Jun Zhao <mypopydev@gmail.com>.
-
Anton Khirnov authored
-
Anton Khirnov authored
Certain hardware decoding APIs are not guaranteed to be thread-safe, so having the user access decoded hardware surfaces while the decoder is running in another thread can cause failures (this is mainly known to happen with DXVA2). For such hwaccels, only allow the decoding thread to run while the user is inside a lavc decode call (avcodec_send_packet/receive_frame).
-
Anton Khirnov authored
-
Anton Khirnov authored
It should only be set after the decoder state has been fully initialized for using that SPS. Fixes possible invalid reads on get_format() failure. CC: libav-stable@libav.org
-
Anton Khirnov authored
This mapping has nothing to do with decoder implementations, so using decoder names is wrong.
-
- 16 Dec, 2016 4 commits
-
-
Diego Biurrun authored
This allows enabling or disabling the library-related variables from within the function instead of doing it manually outside of it.
-
Diego Biurrun authored
Check for and link against user32 instead, which also fixes the missing dependency of dxva2 on user32 with MSVC.
-
Steve Lhomme authored
Without any optimization flags, MSVC does no dead code elimination (DCE) at all, even for the most trivial cases. DCE is a prerequisite for building libav correctly, otherwise there are undefined references to functions for other architectures and disabled components. -O1 is the minimal optimization flag for MSVC that does include DCE.
-
Steve Lhomme authored
-
- 15 Dec, 2016 2 commits
-
-
Michael Niedermayer authored
When receiving fragmented packets, the first packet declares the size, and the later ones normally are small follow-on packets that don't repeat the size and the other header fields. But technically, the later fragments also can have a full header, declaring a different size than the previous packet. If the follow-on packet declares a larger size than the initial one, we could end up writing outside of the allocation. This fixes out of bounds writes. Found-by: Paul Cher <paulcher@icloud.com> Reviewed-by: Paul Cher <paulcher@icloud.com> CC: libav-stable@libav.org Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This seems to have been added by mistake in 11de006b, by not noticing the negation for the existing condition. This block does not contain any code that accesses the codec field in AVStream. This function is meant to serve as a complement to compute_pkt_fields2, which is guarded by FF_API_COMPUTE_PKT_FIELDS2 && FF_API_LAVF_AVCTX. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 14 Dec, 2016 8 commits
-
-
Janne Grunau authored
The former is not an official pseudo instruction although gas and llvm's internal assembler support it. Fixes a build error with xcode 6.2 reported by Memphiz on github.
-
Diego Biurrun authored
There is no point in keeping the two separate.
-
Diego Biurrun authored
Also move #includes into canonical order where appropriate.
-
Diego Biurrun authored
This is more consistent and fixes compilation with clang.
-
Diego Biurrun authored
-
Wan-Teh Chang authored
This improves commit 59c70227. In ff_thread_report_progress(), the fast code path can load progress[field] with the relaxed memory order, and the slow code path can store progress[field] with the release memory order. These changes are mainly intended to avoid confusion when one inspects the source code. They are unlikely to have measurable performance improvement. ff_thread_report_progress() and ff_thread_await_progress() form a pair. ff_thread_await_progress() reads progress[field] with the acquire memory order (in the fast code path). Therefore, one expects to see ff_thread_report_progress() write progress[field] with the matching release memory order. In the fast code path in ff_thread_report_progress(), the atomic load of progress[field] doesn't need the acquire memory order because the calling thread is trying to make the data it just decoded visible to the other threads, rather than trying to read the data decoded by other threads. In ff_thread_get_buffer(), initialize progress[0] and progress[1] using atomic_init(). Signed-off-by: Wan-Teh Chang <wtc@google.com> Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
Derek Buitenhuis authored
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com> Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
Derek Buitenhuis authored
This could happen when there was a frame number gap and frame threading was used. Debugging-by: Ronald S. Bultje <rsbultje@gmail.com> Debugging-by: Justin Ruggles <justin.ruggles@gmail.com> Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com> CC:libav-stable@libav.org Signed-off-by: Anton Khirnov <anton@khirnov.net>
-