Given the frequency that new developers, myself included, get the
code style wrong, it is useful to add some examples to clarify how
things should be done.
We started defauling to nasm 8 years ago.
We are still compatible with yasm 0.8.0, released in 2009. **15 years ago**.
The time has more than come to remove support for it.
Maintaining compatibility started cutting into writing new code long ago.
We still can't have 2-argument instructions, preprocessor booleans, and all
AVX2 code must still be wrapped in ifdefs. Newly added code often breaks this.
Codec IDs have split from `avcodec.h` into `codec_id.h` after commit
c6978418b8.
General documentation contents (which are now in
`general_contents.texi`) have split from the header in `general.texi`
after commit 6accb7718a.
Update the developer documentation to match these changes.
Signed-off-by: Marcus B Spencer <marcus@marcusspencer.xyz>
It should be available in all relevant modern compilers and will allow
us to use features like anonymous unions.
Note that stdatomic.h is still emulated on MSVC, as current versions
require the /experimental:c11atomics, and do not support
ATOMIC_VAR_INIT() anyway.
It dates back to pre-2005 days, when people generally tended to commit
their work directly without going through the mailing list. Few
developers do it today, and never outside of their standalone modules.
This item is thus confusing and misleading and is better removed.
The section consistes of a single short paragraph linking to other
chapters. The enclosing chapter also has no other sections, all other
text is placed in the chapter directly.
Keeping a separate section for this paragraph just adds more clutter.
Remove doc/dev_communit markup files completely as they are at the wrong place.
Create a new community page, merging all of doc/dev_community and subsection Code of Conduct into a common place.
The corresponding patch to ffmpeg-web puts the Organisation & Code of Conduct into a seperate community chapter on the FFmpeg website.
Bring it up to date with current practice, as the current text does not
cover everything. Drop the reference to unprefixed exported symbols,
which do not exist anymore.
It describes a general development policy, not code formatting. It is
also not true, as these days we tend to prioritize correctness, safety,
and completeness over code size.
It is currently very out of touch with reality.
* declare we are using C99 fully, rather than C90 plus extensions
* mention our use of stdatomic.h
* mention forbidden C99 features, like VLAs and complex numbers
Drop the reference to directly committing code, because
- it is highly discouraged and very rarely done these days
- there is no good reason NOT to submit patches for review
Add a link to the development policy chapter.
This seems to confuse Github users into thinking that we may accept pull
requests. We do not accept pull requests.
Sending patches to the ffmpeg-devel mailing list is our preferred method
for users to contribute code.
Signed-off-by: Lou Logan <lou@lrcd.com>
The Developer Documentation had instructions to
subscribe to the ffmpeg-cvslog email list. But that is
no longer accurate. For the purposes in this section --
review of patches, discussion of development issues --
ffmpeg_devel is the appropriate email list. Some developers
may want to monitor ffmpeg-cvslog, but it is not mandatory.
This is v3 of this doc, based on discussion in thread
<https://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220528.html>
and in response to docs Maintainer comments in
<https://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221596.html>.
1. In doc/developer.texi, add a new section about
ffmpeg-devel, based on existing text from ffmpeg-cvslog
section regarding discussion of patches and of
development issues. Reflect wording from discussion at
<https://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221199.html>
but with copy-editing to make wording more concise.
2. In doc/developer.texi, rewrite the ffmpeg-cvslog section
to match the current usage of ffmpeg-cvslog. Some
developers choose to follow this list, but it is not
mandatory.
There are a lot of improvements possible to the
Developer Documentation page, beyond this refactoring.
However, making those improvements is a much bigger
and more difficult task. This change is "low hanging
fruit".
Signed-off-by: Jim DeLaHunt <from.ffmpeg-dev@jdlh.com>
Signed-off-by: Timothy Gu <timothygu99@gmail.com>
Previously, the Developer Documentation <ffmpeg.org/developer.html>
contained a single chapter, "1. Developer Guide," with all content under
that single chapter. Thus the document structure was one level deeper
and more complicated than it needed to be. It differed from similar
documents such as /faq.html, which have multiple chapters.
Eliminate the single chapter, and promote each section underneath to
chapter, and each subsection to section. Thus content and relative
structure remains the same, but the overall structure is simpler.
Anchors within the page remain the same.
Signed-off-by: Jim DeLaHunt <from.ffmpeg-dev@jdlh.com>
Signed-off-by: Timothy Gu <timothygu99@gmail.com>
* commit 'b5f19f7478492307e4b4763aeac3180faf50e17f':
aac: Split function to parse ADTS header data into public and private part
Merged-by: James Almer <jamrial@gmail.com>
This makes the currently semi-public avpriv_aac_parse_header() function
private to libavcodec and adds a proper public API function to return
the parts of the ADTS header required in libavformat.
Michael Niedermayer