No description
2698bfdc93
This test deliberately doesn't exercise the full range of inputs described in
the committee draft VC-1 standard. It says:
input coefficients in frequency domain, D, satisfy -2048 <= D < 2047
intermediate coefficients, E, satisfy -4096 <= E < 4095
fully inverse-transformed coefficients, R, satisfy -512 <= R < 511
For one thing, the inequalities look odd. Did they mean them to go the
other way round? That would make more sense because the equations generally
both add and subtract coefficients multiplied by constants, including powers
of 2. Requiring the most-negative values to be valid extends the number of
bits to represent the intermediate values just for the sake of that one case!
For another thing, the extreme values don't look to occur in real streams -
both in my experience and supported by the following comment in the AArch32
decoder:
tNhalf is half of the value of tN (as described in vc1_inv_trans_8x8_c).
This is done because sometimes files have input that causes tN + tM to
overflow. To avoid this overflow, we compute tNhalf, then compute
tNhalf + tM (which doesn't overflow), and then we use vhadd to compute
(tNhalf + (tNhalf + tM)) >> 1 which does not overflow because it is
one instruction.
My AArch64 decoder goes further than this. It calculates tNhalf and tM
then does an SRA (essentially a fused halve and add) to compute
(tN + tM) >> 1 without ever having to hold (tNhalf + tM) in a 16-bit element
without overflowing. It only encounters difficulties if either tNhalf or
tM overflow in isolation.
I haven't had sight of the final standard, so it's possible that these
issues were dealt with during finalisation, which could explain the lack
of usage of extreme inputs in real streams. Or a preponderance of decoders
that only support 16-bit intermediate values in their inverse transforms
might have caused encoders to steer clear of such cases.
I have effectively followed this approach in the test, and limited the
scale of the coefficients sufficient that both the existing AArch32 decoder
and my new AArch64 decoder both pass.
Signed-off-by: Ben Avison <bavison@riscosopen.org>
Signed-off-by: Martin Storsjö <martin@martin.st>
|
||
|---|---|---|
| compat | ||
| doc | ||
| ffbuild | ||
| fftools | ||
| libavcodec | ||
| libavdevice | ||
| libavfilter | ||
| libavformat | ||
| libavutil | ||
| libpostproc | ||
| libswresample | ||
| libswscale | ||
| presets | ||
| tests | ||
| tools | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| .travis.yml | ||
| Changelog | ||
| configure | ||
| CONTRIBUTING.md | ||
| COPYING.GPLv2 | ||
| COPYING.GPLv3 | ||
| COPYING.LGPLv2.1 | ||
| COPYING.LGPLv3 | ||
| CREDITS | ||
| INSTALL.md | ||
| LICENSE.md | ||
| MAINTAINERS | ||
| Makefile | ||
| README.md | ||
| RELEASE | ||
FFmpeg README
FFmpeg is a collection of libraries and tools to process multimedia content such as audio, video, subtitles and related metadata.
Libraries
libavcodecprovides implementation of a wider range of codecs.libavformatimplements streaming protocols, container formats and basic I/O access.libavutilincludes hashers, decompressors and miscellaneous utility functions.libavfilterprovides means to alter decoded audio and video through a directed graph of connected filters.libavdeviceprovides an abstraction to access capture and playback devices.libswresampleimplements audio mixing and resampling routines.libswscaleimplements color conversion and scaling routines.
Tools
- ffmpeg is a command line toolbox to manipulate, convert and stream multimedia content.
- ffplay is a minimalistic multimedia player.
- ffprobe is a simple analysis tool to inspect multimedia content.
- Additional small tools such as
aviocat,ismindexandqt-faststart.
Documentation
The offline documentation is available in the doc/ directory.
The online documentation is available in the main website and in the wiki.
Examples
Coding examples are available in the doc/examples directory.
License
FFmpeg codebase is mainly LGPL-licensed with optional components licensed under GPL. Please refer to the LICENSE file for detailed information.
Contributing
Patches should be submitted to the ffmpeg-devel mailing list using
git format-patch or git send-email. Github pull requests should be
avoided because they are not part of our review process and will be ignored.