- 31 May, 2017 1 commit
-
-
Martin Storsjö authored
This was actually broken when committed in 46e3936f; the test never succeeded, and thus, _aligned_malloc wasn't actually used on legacy mingw. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 29 May, 2017 2 commits
-
-
Elviss Strazdins authored
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
Luca Barbato authored
Clang support for Altivec/VSX uses a different approach.
-
- 20 May, 2017 6 commits
-
-
Aaron Levinson authored
Add dxva2_pool_release_dummy() and use it in call to av_buffer_create() in dxva2_pool_alloc(). Prior to this change, av_buffer_create() was called with NULL for the third argument, which indicates that av_buffer_default_free() should be used to free the buffer's data. Eventually, it gets to buffer_pool_free() and calls buf->free() on a surface object (which is av_buffer_default_free()). This can result in a crash when the debug version of the C-runtime is used on Windows. While it doesn't appear to result in a crash when the release version of the C-runtime is used on Windows, it likely results in memory corruption, since av_free() is being called on memory that was allocated using IDirectXVideoAccelerationService::CreateSurface(). Signed-off-by: Aaron Levinson <alevinsn@aracnet.com> Reviewed-by: wm4 <nfxjfg@googlemail.com> Reviewed-by: Steven Liu <lingjiujianke@gmail.com> Reviewed-by: Mark Thompson <sw@jkqxz.net> Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
Anton Khirnov authored
Currently it does not work at all. Bug-Id: 1058
-
Anton Khirnov authored
HEVCSEIPictureHash should store only the information extracted from the bitstream and exported to the higher layer (the decoder or the parser). The MD5 context is allocated, used and freed by this higher layer, so it makes more sense for it to also be stored there.
-
James Almer authored
This mimics the behavior of the now unused h264/hevc parser's split() function and fixes decoding some files when extract_extradata bsf is enabled. Signed-off-by: James Almer <jamrial@gmail.com> Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
Anton Khirnov authored
Avoids unnecessary allocs+copies and makes the code slightly simpler.
-
Anton Khirnov authored
-
- 16 May, 2017 4 commits
-
-
Mark Thompson authored
While not yet used, these NAL units do already have some defined semantics and are referred to elsewhere.
-
Mark Thompson authored
This avoids confusion with equivalent H.265 SEI values when both are being used at the same time.
-
Mark Thompson authored
Same as f64d1100, for stream copy rather than encode.
-
Mark Thompson authored
-
- 15 May, 2017 5 commits
-
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
In these cases, the CTTS flag is set, but no edit list is necessary. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This reduces the need for an edit list; streams that start with e.g. dts=-1, pts=0 can be encoded as dts=0, pts=0 (which is valid in mov/mp4) by shifting the dts values of all packets forward. This avoids the need for edit lists for such streams (while they still are needed for audio streams with encoder delay). This eases conformance with the DASH-IF interoperability guidelines. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Loads from this strictly doesn't require alignment, but specify it just for consistency with the arm version. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
clang now (in the upcoming 5.0 version) is capable of building our arm assembly without relying on gas-preprocessor, although clang/LLVM doesn't support .dn register aliases. The VC1 MC assembly was only built and used if the chosen assembler supported the .dn directives though. This was supported as long as gas-preprocessor was used. This means that VC1 decoding got a speed regression on clang 5.0, unless the user manually chose using gas-preprocessor again. By avoiding using the .dn register aliases, we can build the VC1 MC assembly with the latest clang version. Support for the .dn/.qn directives in clang/LLVM isn't actively planned, see https://bugs.llvm.org/show_bug.cgi?id=18199. This partially reverts 896a5bff. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 11 May, 2017 1 commit
-
-
Martin Storsjö authored
This is more correct. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 09 May, 2017 3 commits
-
-
Sean McGovern authored
Bug-Id: 1036 CC: libav-stable@libav.org
-
James Almer authored
It doesn't depend on hevcdec anymore. Signed-off-by: James Almer <jamrial@gmail.com> Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
James Almer authored
Based on the H264 SEI implementation. This will be mainly useful once support for SEI messages that can be used by the hevc parser are implemented, like Picture Timing. Signed-off-by: James Almer <jamrial@gmail.com> Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
- 08 May, 2017 1 commit
-
-
Martin Storsjö authored
When targeting windows, the .arch directive isn't available. So far, when building for windows, we've always used gas-preprocessor, both when using msvc's armasm and when using clang. Lately, clang/llvm has implemented the last missing piece (altmacro support) for building our assembly without gas-preprocessor. This means that we now build for arm/windows with clang without any extra compatibility layer. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 04 May, 2017 2 commits
-
-
Alexandra Hájková authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Alexandra Hájková authored
This doesn't change the actual behaviour of the code but improves readability. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 03 May, 2017 1 commit
-
-
Alex Converse authored
Aliased compressed AAC bytes are almost certainly not meaningful SBR data. In the wild this causes harsh artifacts switching HE-AAC streams that don't have SBR headers aligned with segment boundaries. Turning off SBR falls back to a default set of upsampling parameters that can function as a sort of error concealment. This is consistent with how the decoder handles other sorts of errors. Bug-Id: 1047 CC: libav-stable@libav.org Signed-off-by: Sean McGovern <gseanmcg@gmail.com>
-
- 02 May, 2017 3 commits
-
-
Diego Biurrun authored
This makes the currently semi-public avpriv_aac_parse_header() function private to libavcodec and adds a proper public API function to return the parts of the ADTS header required in libavformat.
-
Luca Barbato authored
This makes the bitstream.h header leaner. Signed-off-by: Diego Biurrun <diego@biurrun.de>
-
Luca Barbato authored
Do not rely on indirectly including it from bitstream.h. Signed-off-by: Diego Biurrun <diego@biurrun.de>
-
- 01 May, 2017 1 commit
-
-
Alexandra Hájková authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 30 Apr, 2017 10 commits
-
-
Mark Thompson authored
This is something of a hack. It allocates a new hwframe context for the target format, then maps it back to the source link and overwrites the input link hw_frames_ctx so that the previous filter will receive the frames we want from ff_get_video_buffer(). It may fail if the previous filter imposes any additional constraints on the frames it wants to use as output.
-
Mark Thompson authored
Also refactor a little and improve error messages to make failure cases easier to understand.
-
Mark Thompson authored
Use the flags argument of av_hwframe_ctx_create_derived() to pass the mapping flags which will be used on allocation. Also, set the format and hardware context on the allocated frame automatically - the user should not be required to do this themselves.
-
Mark Thompson authored
-
Mark Thompson authored
Factorises out existing surface initialisation code to reuse.
-
Mark Thompson authored
Some frames contexts are not usable without additional format-specific state in hwctx. This change adds new functions frames_derive_from and frames_derive_to to initialise this state appropriately when deriving a frames context which will require it to be set.
-
Mark Thompson authored
-
Mark Thompson authored
This only supports one device globally, but more can be used by passing them with input streams in hw_frames_ctx or by deriving new devices inside a filter graph with hwmap.
-
Mark Thompson authored
If -hwaccel foo is supplied without any other device options, and the foo hwaccel is meant to have a device, try to make such a device with default parameters for the hwaccel to use.
-
Mark Thompson authored
This was left over from an earlier version which created the new packet inside the current frame structure. Now it just leaks an unused packet, so remove the allocation entirely.
-