- 17 Sep, 2017 1 commit
-
-
Huang, Zhengxu authored
Add common filters of the qsv vpp features including scale,denosie, deinterlace,frc,crop and procAmp. Performance will be significantly reduced in the test if using cascade mode just like qsv framerate + qsv scale + qsv deinterlace + qsv denoise in separated way no matter in system or video memmory cases. And the code is so redundant because so much the same just as session and surface's creation and management. So we add a common qsv filter. Usage: -hwaccel qsv -c:v h264_qsv -r 25 -i in -vf vpp_qsv=w=iw/2:h=400:deinterlace=1:framerate=60:detail=50:denoise=50 -b 2M -maxrate 3M -c:v h264_qsv -y out.h264 Signed-off-by: ChaoX A Liu <chaox.a.liu@gmail.com> Signed-off-by: Zhengxu Huang <zhengxu.maxwell@gmail.com> Signed-off-by: Andrew Zhang <huazh407@gmail.com> Change-Id: I130392ce722138c209ab658c5f03f0009b6e8024 Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>
-
- 14 Sep, 2017 1 commit
-
-
James Almer authored
It must be freed using avio_context_free() starting with commit 99684f3a. Signed-off-by: James Almer <jamrial@gmail.com> Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
- 12 Sep, 2017 10 commits
-
-
Mark Thompson authored
-
Mark Thompson authored
Previously in the mpeg2_metadata filter. Also adds a test.
-
Mark Thompson authored
-
Mark Thompson authored
The bracketing was wrong - '-' binds before '<<'. This would previously incorrectly reject the streams in the WP_A and WP_B conformance tests.
-
Mark Thompson authored
-
Mark Thompson authored
This should be ticks, not time_scale steps - it was wrong for all framerates not a multiple of 1/2.
-
Mark Thompson authored
This reverts commit a14a12ca. The CTU size is always 32x32; the surface size is what actually sets the desired property, and it is already correct.
-
Mark Thompson authored
Whether the udu string should be freed depends on whether the SEI it gets added to was created internally by cbs or externally by the bsf. The current code frees it twice in the former case.
-
Mark Thompson authored
Remove any trailing zeroes from H.26[45] NAL units at the same time.
-
Mark Thompson authored
-
- 11 Sep, 2017 1 commit
-
-
Luca Barbato authored
Only on Windows the software plugin is available. Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
- 04 Sep, 2017 2 commits
-
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
If the metadata packet is corrupted, flv_read_metabody can accidentally read past the start of the next packet. If the start of the next packet had been flushed out of the IO buffer, we would be unable to seek to the right position (on a nonseekable stream). Prefer to clearly error out instead of silently trying to read from a desynced stream which will only be interpreted as garbage. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 02 Sep, 2017 2 commits
-
-
Martin Storsjö authored
This reverts commit 547db1ea. This commit wasn't supposed to be pushed (yet) since it hasn't been reviewed. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
In binutils 2.29, the behavior of the ADR instruction changed so that 1 is added to the address of a Thumb function (previously nothing was added). This allows the loaded address to be passed to a BLX instruction and the correct mode change will occur. See: https://sourceware.org/bugzilla/show_bug.cgi?id=21458 By using adr with a label that isn't annotated as a thumb function, we avoid the new behaviour in binutils 2.29 and get the same behaviour as in prior releases, and as in other assemblers (ms armasm.exe, clang's built in assembler) - an idea that Janne Grunau came up with. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 31 Aug, 2017 7 commits
-
-
Martin Storsjö authored
-
Martin Storsjö authored
When we use dllexport properly for shared libraries on windows, there's no longer any issue with linking the object files for e.g. libavcodec statically into checkasm. (It's still not possible to link the built object files for e.g. libavformat statically to libavcodec though, since libavformat exepcts to load av_export_* symbols from a DLL.) This reverts commit 4e62b57e. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This avoids having to use pseudo relocations. The version script used for exporting functions is skipped as soon as the set of object files contains symbols marked with dllexport, therefore we need to use makedef to produce the full list of symbols to be exported. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This is invoked by setting the NM and AR variables to the names of those specific tools. The ARCH variable also needs to be provided, to choose the symbol prefix (nm doesn't provide any option that dumps the architecture easily). Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This avoids redoing them for each expression in the list. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
We currently only have exported data symbols within libavcodec, but the concept is easy to extend to other libraries if necessary. The attribute declaration needs to be in a private header though, since we can't use CONFIG_SHARED in public installed headers. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
The toolchain for this target is unmaintained since many years. While it has been continuously build tested on fate, it hasn't actually been tested at runtime since many, many years (and back then, only a few codecs in libavcodec were tested). So far, keeping support for it has been mostly effortless, but the compiler does seem to have issues with dllimported data symbols, ending up as internal compiler errors in some cases. Instead of jumping through further hoops to work around that, just remove the target. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 30 Aug, 2017 1 commit
-
-
wm4 authored
Main use-case is proxying avio through a foreign I/O layer and a custom AVIO context, without losing latency and performance characteristics. Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
- 28 Aug, 2017 1 commit
-
-
Derek Buitenhuis authored
Fixes: libswscale/utils.c:1632:5: warning: macro expansion producing 'defined' has undefined behavior [-Wexpansion-to-defined] #if USE_MMAP ^ libswscale/utils.c:1577:49: note: expanded from macro 'USE_MMAP' #define USE_MMAP (HAVE_MMAP && HAVE_MPROTECT && defined MAP_ANONYMOUS) ^ Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com> Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
- 25 Aug, 2017 1 commit
-
-
Martin Storsjö authored
This fixes shared WinRT/UWP builds with d3d11va enabled. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 22 Aug, 2017 2 commits
-
-
Michael Niedermayer authored
Avoid out of bound reads. Bug-Id: 1031 CC: libav-stable@libav.org Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
Martin Storsjö authored
On windows, the offset for the relocation doesn't get stored in the relocation itself, but as an unsigned immediate in the opcode. Therefore, negative offsets has to be handled via a separate sub instruction, just as on MachO. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 21 Aug, 2017 2 commits
-
-
Luca Barbato authored
-
Luca Barbato authored
-
- 20 Aug, 2017 4 commits
-
-
Mark Thompson authored
Since there is no information about the source format, "unspecified" is the correct value to write here. All tests using the MPEG-2 encoder are updated, as this changes the header on all outputs.
-
Mark Thompson authored
-
Mark Thompson authored
Also enable MPEG-2 support in the trace_headers filter.
-
Mark Thompson authored
-
- 18 Aug, 2017 1 commit
-
-
Anton Khirnov authored
pic_num can be at most 17-bit, so uint8_t is not sufficient. Found-By: Bradley Sepos <bradley@bradleysepos.com> CC: libav-stable@libav.org
-
- 13 Aug, 2017 4 commits
-
-
Piotr Bandurski authored
(cherry picked from commit b9c94e82) Signed-off-by: Diego Biurrun <diego@biurrun.de>
-
Diego Biurrun authored
DDS1 chunks are decoded in 2x2 blocks, odd chunk width or height is not allowed in that case. Also ensure that the decode buffer is big enough for all blocks being processed. Bug-Id: CVE-2017-9992 CC: libav-stable@libav.org
-
Mark Thompson authored
It is not necessary to pad to the CTU size. The CB size of 8x8 should be sufficient, but due to constraints in the Intel driver (the one usable implementation of this) it has to be padded to 16x16 like in H.264.
-
Mark Thompson authored
Matching the H.264 encoder.
-