The idea is to use ffmath.h for internal implementations of math functions.
Currently, it is used for variants of libm functions, but is by no means
limited to such things.
Note that this is not exported; use lavu/mathematics for such purposes.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanag@gmail.com>
- Check if av_display_rotation_get() gets the correct degrees
- Check if av_display_rotation_set() sets the correct matrix
- Check if av_display_matrix_flip() changes correct the matrix
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Until now, for formats which were in the spec but not in the encoder's
list of supported formats required the -strict -1 flag. This enables
support for all video formats which are specified, all the way from
QSIF525 to 8K.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Adding early support for a subset of the proposed colour elements
according to the latest version of spec:
https://mailarchive.ietf.org/arch/search/?email_list=cellar&gbt=1&index=hIKLhMdgTMTEwUTeA4ct38h0tmE
Like matroskadec, I've left out elements for pix_fmt related things
as there still seems to be some discussion around these.
The new elements are exposed under strict experimental mode.
Signed-off-by: Neil Birkbeck <neil.birkbeck@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
dv_frame_offset() is static and called only from dv_read_seek(), where
c->sys->frame_size is already used.
This simplifies the incoming codecpar merge where
avctx->{coded_width,coded_height,time_base} are not accessible anymore.
Needed for noStreams.wtv unless something else forces continued parsing (like looking for more than 1
frame in attachments)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Remove achroma filter, as same output can be done with lowpass filter
and multiple components with overlay display.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This is ~2x faster for y not an integer on Haswell+GCC, and should
generally be faster due to the fact that anyway powf essentially does
this under the hood. Made an inline function in lavu/internal.h for this
purpose.
Note that there are some accuracy differences, that should generally be
negligible. In particular, FATE still passes on this platform.
Results in ~ 7% speedup in aac encoding with -march=native, Haswell+GCC.
before:
ffmpeg -i sin.flac -acodec aac -y sin_new.aac 6.05s user 0.06s system 104% cpu 5.821 total
after:
ffmpeg -i sin.flac -acodec aac -y sin_new.aac 5.67s user 0.03s system 105% cpu 5.416 total
This is also faster than an alternative approach that pulls in powf, gets rid of
the crufty NaN checks and other special cases, exploits knowledge about the intervals, etc.
This of course does not exclude smarter approaches; just suggests that
there would need to be significant work on this front of lower utility than
searches for hotspots elsewhere.
Reviewed-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanag@gmail.com>
In some cases this caused the slice size rounding to generate invalid
slice sizes and overwrite some slices.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This zeroes the WebPAnimEncoderOptions.verbose field, silencing library info messages
printed to stderr.
Reviewed-by: James Zern <jzern@google.com>
Signed-off-by: James Almer <jamrial@gmail.com>
