- 02 Oct, 2016 21 commits
-
-
Anton Khirnov authored
It has been replaced by C11 stdatomic.h and is now unused.
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
Current code uses a plain int in a racy way, which is UB.
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
Adapted from the code by Rémi Denis-Courmont from VLC
-
Anton Khirnov authored
Adapted from the code by Rémi Denis-Courmont from VLC
-
Anton Khirnov authored
Adapted from the code by Rémi Denis-Courmont from VLC
-
Anton Khirnov authored
Adapted from the code by Rémi Denis-Courmont from VLC
-
Anton Khirnov authored
Adapted from the code by Rémi Denis-Courmont from VLC
-
Anton Khirnov authored
Since this is a C11 feature, it requires -std=c11. Not actually used for anything yet, that will be added in the following commits.
-
Luca Barbato authored
Confirmed to work by checkasm.
-
Luca Barbato authored
-
Alexandra Hájková authored
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
Anton Khirnov authored
Errors during decoding are currently considered non-fatal and do not terminate transcoding, so even if parts of the data are corrupted, the rest may be decodable. However, that should apply only to the actual decoding calls, not to the failures elsewhere (e.g. configuring filters).
-
Anton Khirnov authored
The filtergraph's existence is used in several places to mean that the filtergraph is fully configured. This causes problems if it's allocated, but the initialization fails (e.g. if a non-existent filter is specified).
-
Anton Khirnov authored
-
Anton Khirnov authored
Bug-Id: 966
-
Anton Khirnov authored
The Intel binary iHD driver does not support the VASurfaceAttribMemoryType, so surface allocation will fail when using it.
-
- 30 Sep, 2016 7 commits
-
-
Justin Ruggles authored
Adds a wrapper function for downmixing which detects channel count changes and updates the selected downmix function accordingly. Simplification and porting to current x86inc infrastructure by Diego Biurrun. Signed-off-by: Diego Biurrun <diego@biurrun.de>
-
Justin Ruggles authored
This is about 200% faster for in-decoder downmixing of 5.0 and 5.1 content. Signed-off-by: Diego Biurrun <diego@biurrun.de>
-
Justin Ruggles authored
Also use (float **) instead of (float (*)[2]). This matches the matrix layout in libavresample so we can reuse assembly code between the two. Signed-off-by: Diego Biurrun <diego@biurrun.de>
-
Anton Khirnov authored
-
Anton Khirnov authored
Move the doxy above the definition, change the value itself to the (1 << n) pattern, which is more readable for flags.
-
Anton Khirnov authored
It is supposed to be a flag. The only currently defined value is AVIO_SEEKABLE_NORMAL, but other ones may be added in the future. However all the current lavf code treats this field as a bool (mainly for historical reasons). Change all those cases to properly check for AVIO_SEEKABLE_NORMAL.
-
Hendrik Leppkes authored
This fixes decoding corruption on 64 bit windows. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 29 Sep, 2016 10 commits
-
-
Diego Biurrun authored
This avoids SIMD-optimized functions having to sign-extend their stride argument manually to be able to do pointer arithmetic.
-
Diego Biurrun authored
ptrdiff_t is the correct type for array strides and similar.
-
Diego Biurrun authored
ptrdiff_t is the correct type for array strides and similar.
-
Diego Biurrun authored
ptrdiff_t is the correct type for array strides and similar.
-
Diego Biurrun authored
This avoids SIMD-optimized functions having to sign-extend their stride argument manually to be able to do pointer arithmetic.
-
Diego Biurrun authored
ptrdiff_t is the correct type for array strides and similar.
-
Diego Biurrun authored
ptrdiff_t is the correct type for array strides and similar.
-
Diego Biurrun authored
ptrdiff_t is the correct type for array strides and similar. Also rename all such parameters to "stride" for consistency.
-
Diego Biurrun authored
-
Diego Biurrun authored
-
- 28 Sep, 2016 2 commits
-
-
Mark Thompson authored
-
Mark Thompson authored
While outwardly bizarre, this change makes the behaviour consistent with other VAAPI encoders which sync to the encode /input/ picture in order to wait for /output/ from the encoder. It is not harmful on i965 (because synchronisation already happens in vaRenderPicture(), so it has no effect there), and it allows the encoder to work on mesa/gallium which assumes this behaviour.
-