The buffers are only allocated once, although it can happen from
any of a few different places, so there is no need to use realloc.
Using av_malloc() ensures they are aligned suitably for SIMD
optimisations.
Signed-off-by: Mans Rullgard <mans@mansr.com>
In Smooth Streaming, the fragments are addressed by time, and
the manifest only stores one list of time offests for all streams,
so all streams need to have identical fragment offsets. Warn if
this isn't the case, so that the user can fix the files instead of
getting failures at runtime when the fragments can't be found.
Signed-off-by: Martin Storsjö <martin@martin.st>
Currently, --enable-small turns av_always_inline into plain inline,
which is more or less ignored by the compiler. While the intent of
this is probably to reduce code size by avoiding some inlining, it
has more far-reaching effects.
We use av_always_inline in two situations:
1. The body of a function is smaller than the call overhead.
Instances of these are abundant in libavutil, the bswap.h
functions being good examples.
2. The function is a template relying on constant propagation
through inlined calls for sane code generation. These are
often found in motion compensation code.
Both of these types of functions should be inlined even if targeting
small code size.
Although GCC has heuristics for detecting the first of these types,
it is not always reliable, especially when the function uses inline
assembler, which is often the reason for having those functions in
the first place, so making it explicit is generally a good idea.
The size increase from inlining template-type functions is usually
much smaller than it seems due to different branches being mutually
exclusive between the different invocations. The dead branches can,
however, only be removed after inlining and constant propagation have
been performed, which means the initial cost estimate for inlining
these is much higher than is actually the case, resulting in GCC
often making bad choices if left to its own devices.
Furthermore, the GCC inliner limits how much it allows a function to
grow due to automatic inlining of calls, and this appears to not take
call overhead into account. When nested inlining is used, the limit
may be hit before the innermost level is reached. In some cases, this
has prevented inlining of type 1 functions as defined above, resulting
in significant performance loss.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Do not assume avpacket and the decoded frames are independent.
To be absolutely sure and not sprinkle av_free_packet around the code
the call had been placed before getting the frame and on the error path.
intfloat.h is a public header, and is now (since a1245d5ca) included
by mathematics.h, which many external callers include.
This fixes building third party applications that include
mathematics.h in a language that doesn't support designated
initalizers.
Signed-off-by: Martin Storsjö <martin@martin.st>
These files use NAN/INFINITY but didn't include mathematics.h to get
the fallback definitions if the system lacks the macros.
Signed-off-by: Martin Storsjö <martin@martin.st>
Some compilers, MSVC among them, don't recognize the divisions by
zero as meaning infinity/nan.
These macros should, according to the standard, expand to constant
expressions, but this shouldn't matter for our usage.
Signed-off-by: Martin Storsjö <martin@martin.st>
ff_wma_init is used only by wmadec and wmaenc, and neither of them
can handle more than 2 channels.
This fixes crashes with invalid files.
Based on patch by Piotr Bandurski and Michael Niedermayer.
Signed-off-by: Martin Storsjö <martin@martin.st>
This adds macros for accessing the EFLAGS register and uses
these instead of coding the entire check in inline asm.
Signed-off-by: Mans Rullgard <mans@mansr.com>
This creates proper position independent code when accessing
data symbols if CONFIG_PIC is set.
References to external symbols should now use the movrelx macro.
Some additional code changes are required since this macro may
need a register to hold the GOT pointer.
Signed-off-by: Mans Rullgard <mans@mansr.com>
