No description
7ad13e173b
Codecs call ff_find_unused_picture() to get the index of an unused picture; said picture may have buffers left from using it previously (these buffers are intentionally not unreferenced so that it might be possible to reuse them; they are only reused when they are writable, otherwise they are replaced by new, zeroed buffers). They should not make any assumptions about which picture they get. Yet this is not true for mbskip_table and damaged bitstreams. When one returns old unused slots randomly, the output becomes nondeterministic. This can't happen now (see below), but it will be possible once mpegpicture uses proper pools for the picture tables. The following discussion uses the sample created via ffmpeg -bitexact -i fate-suite/svq3/Vertical400kbit.sorenson3.mov -ps 50 -bf 2 -bitexact -an -qscale 5 -ss 40 -error_rate 4 -threads 1 out.avi When decoding this with one thread, the slots are as follows: Cur 0 (type I), last -1, Next -1; cur refcount -1, not reusing buffers Cur 1 (type P), last -1, Next 0; cur refcount -1, not reusing buffers Cur 2 (type B), last 0, Next 1; cur refcount -1, not reusing buffers Cur 2 (type B), last 0, Next 1; cur refcount 2, not reusing buffers Cur 0 (type P), last 0, Next 1; cur refcount 2, not reusing buffers Cur 2 (type B), last 1, Next 0; cur refcount 1, reusing buffers Cur 2 (type B), last 1, Next 0; cur refcount 2, not reusing buffers Cur 1 (type P), last 1, Next 0; cur refcount 2, not reusing buffers Cur 2 (type B), last 0, Next 1; cur refcount 1, reusing buffers Cur 2 (type B), last 0, Next 1; cur refcount 2, not reusing buffers Cur 0 (type I), last 0, Next 1; cur refcount 2, not reusing buffers Cur 2 (type B), last 1, Next 0; cur refcount 1, reusing buffers Cur 2 (type B), last 1, Next 0; cur refcount 2, not reusing buffers Cur 1 (type P), last 1, Next 0; cur refcount 2, not reusing buffers After the slots have been filled initially, the buffers are only reused for the first B-frame in a B-frame chain: a) When the new picture is an I or a P frame, the slot of the backward reference is cleared and reused for the new frame (as has been said, "cleared" does not mean that the auxiliary buffers have been unreferenced). Given that not only the slot in the picture array, but also MpegEncContext.last_picture contain references to these auxiliary buffers, they are not writable and are therefore not reused, but replaced by new, zero-allocated buffers. b) When the new picture is the first B-frame in a B-frame chain, the two reference slots are kept as-is and one gets a slot that does not share its auxiliary buffers with any of MpegEncContext. current_picture, last_picture, next_picture. The buffers are therefore writable and are reused. c) When the new picture is a B-frame that is not the first frame in a B-frame chain, ff_mpv_frame_start() reuses the slot occupied by the preceding B-frame. Said slot shares its auxilary buffers with MpegEncContext.current_picture, so that they are not considered writable and are therefore not reused. When using frame-threading, the slots are made to match the one from the last thread, so that the above analysis is mostly the same with one exception: Other threads may also have references to these buffers, so that initial B-frames of a B-frame chain need no longer have writable/reusable buffers. In particular, all I and P-frames always use new, zeroed buffers. Because only the mbskip_tables of I- and P-frames are ever used, it follows that there is currently no problem with using stale values for them at all. Yet as the analysis shows this is very fragile: 1. MpegEncContext.(current|last|next)_picture need not have references of their own, but they have them and this influences the writability decision. 2. It would not work if the slots were returned in a truely random fashion or if there were a proper pool used. Therefore this commit always resets said buffer. This is in preparation for actually adding such a pool (where the checksums for said sample would otherwise be depending on the number of threads used for decoding). Future commits will restrict this to only the codecs for which it is necessary (namely the MPEG-4 decoder). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com> |
||
|---|---|---|
| compat | ||
| doc | ||
| ffbuild | ||
| fftools | ||
| libavcodec | ||
| libavdevice | ||
| libavfilter | ||
| libavformat | ||
| libavutil | ||
| libpostproc | ||
| libswresample | ||
| libswscale | ||
| presets | ||
| tests | ||
| tools | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| 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.