| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
| |
A number of compilers, for example those from TI and IBM, choke on
these initialisers. The current style is also quite ugly.
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
|
|
|
| |
Does not make a difference in this case since sizeof(uint8_t*) ==
sizeof(uint8_t**). Fixes CID703814.
|
|
|
|
| |
Fixes CID732273.
|
|
|
|
| |
Fixes CID732272.
|
|
|
|
|
| |
Prevents writes to freed memory and the leak of the old extended data.
Fixes CID732303.
|
| |
|
|
|
|
|
| |
When there is only 1 channel, the planar and interleaved formats of the same
data type should be treated as identical.
|
|
|
|
| |
Anonymous structs cannot be forward declared and have no benefit.
|
|
|
|
|
|
| |
Fixes Bug 203.
CC:libav-stable@libav.org
|
|
|
|
|
|
| |
This is more consistent with what the rest of Libav does.
This breaks API.
|
|
|
|
|
| |
Right now it incorrectly assumes that the frames are sent in the proper
order, which worked with old ffmpeg and avconv versions by accident.
|
|
|
|
|
| |
Output frames correspond 1:1 to input frames on the main input.
So use the main input timebase for output.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The warning is:
libavfilter/avfiltergraph.c: In function ‘avfilter_graph_config’:
libavfilter/avfiltergraph.c:528:9: warning: ‘best_idx’ may be used uninitialized in this function [-Wuninitialized]
libavfilter/avfiltergraph.c:479:13: note: ‘best_idx’ was declared here
Initialize it to an invalid value and add an assert that it's properly
set later.
|
| |
|
|
|
|
| |
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
| |
|
|
|
|
|
| |
Fixes an infinite loop on flush when avresample_get_delay() still
reports some samples but avresample_convert() doesn't return any data.
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
|
| |
|
|
|
|
|
|
|
| |
Compilation seems to fail on GCC 3.4 due to this duplicate
declaration.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
|
|
| |
This C99 feature is generally not used in the libav codebase,
since it breaks building with some fringe compilers (GCC 2.95,
MSVC).
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
| |
13% faster on penryn, 16% on sandybridge, 15% on bulldozer
Not simd; a compiler should have generated this, but gcc didn't.
|
| |
|
|
|
|
|
| |
Double does not have enough precision to represent all int64 numbers
exactly.
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Under some circumstances, suncc will use a single register for the
address of all memory operands, inserting lea instructions loading
the correct address prior to each memory operand being used in the
code. In the yadif code, the branch in the asm block bypasses such
an lea instruction, causing an incorrect address to be used in the
following load.
This patch replaces the tmpX arrays with a single array and uses a
register operand to hold its address. Although this prevents using
offsets from the stack pointer to access these locations, the code
still builds as 32-bit PIC even with old compilers.
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
| |
|
|
|
|
|
|
|
| |
This puts x86-specific things in the x86/ subdirectory where they
belong.
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
|
|
| |
Found with a clang-scan report on http://fate.libav.org/csa/
|
|
|
|
|
|
| |
Based on a patch by Piotr Bandurski.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
|
|
|
|
|
|
| |
Refactoring mmx2/mmxext YASM code with cpuflags will force renames.
So switching to a consistent naming scheme beforehand is sensible.
The name "mmxext" is more official and widespread and also the name
of the CPU flag, as reported e.g. by the Linux kernel.
|
|
|
|
|
| |
The yadif mmx optimizations contain the pmaxsw and pmaxub mmxext
instructions, causing sigills on CPUs that do not support mmxext.
|
| |
|
|
|
|
|
|
| |
This allows for padding/trimming at the start of stream. By default, no
assumption is made about the first frame's expected pts, so no padding or
trimming is done.
|
|
|
|
| |
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
|
|
|
|
|
| |
11% faster on penryn, 7% on sandybridge, 5% on bulldozer
Negligible change to output.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
|
|
|
|
| |
14% faster on penryn, 2% on sandybridge, 9% on bulldozer
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
|
|
| |
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|