|
|
|
|
FFmpeg's bug/patch/feature request tracker manual
|
|
|
|
|
=================================================
|
|
|
|
|
|
|
|
|
|
NOTE: This is a draft.
|
|
|
|
|
|
|
|
|
|
Overview:
|
|
|
|
|
---------
|
|
|
|
|
FFmpeg uses Trac for tracking issues, new issues and changes to
|
|
|
|
|
existing issues can be done through a web interface.
|
|
|
|
|
It is possible to subscribe to individual issues by adding yourself to the
|
|
|
|
|
Cc list or to subscribe to the ffmpeg-trac mailing list which receives
|
|
|
|
|
a mail for every change to every issue.
|
|
|
|
|
(the above does all work already after light testing)
|
|
|
|
|
The subscription URL for the ffmpeg-trac list is:
|
|
|
|
|
http(s)://ffmpeg.org/mailman/listinfo/ffmpeg-trac
|
|
|
|
|
The URL of the webinterface of the tracker is:
|
|
|
|
|
http(s)://ffmpeg.org/trac/ffmpeg
|
|
|
|
|
|
|
|
|
|
NOTE: issue = (bug report || patch || feature request || license violation)
|
|
|
|
|
|
|
|
|
|
Type:
|
|
|
|
|
-----
|
|
|
|
|
bug / defect
|
|
|
|
|
An error, flaw, mistake, failure, or fault in FFmpeg or libav* that
|
|
|
|
|
prevents it from behaving as intended.
|
|
|
|
|
|
|
|
|
|
feature request / enhancement
|
|
|
|
|
Request of support for encoding or decoding of a new codec, container
|
|
|
|
|
or variant.
|
|
|
|
|
Request of support for more, less or plain different output or behavior
|
|
|
|
|
where the current implementation cannot be considered wrong.
|
|
|
|
|
|
|
|
|
|
license violation
|
|
|
|
|
ticket to keep track of (L)GPL violations of ffmpeg by others
|
|
|
|
|
|
|
|
|
|
patch
|
|
|
|
|
A patch as generated by diff which conforms to the patch submission and
|
|
|
|
|
development policy.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Priority:
|
|
|
|
|
---------
|
|
|
|
|
critical
|
|
|
|
|
Bugs and patches which deal with data loss and security issues.
|
|
|
|
|
No feature request can be critical.
|
|
|
|
|
|
|
|
|
|
important
|
|
|
|
|
Bugs which make FFmpeg unusable for a significant number of users, and
|
|
|
|
|
patches fixing them.
|
|
|
|
|
Examples here might be completely broken MPEG-4 decoding or a build issue
|
|
|
|
|
on Linux.
|
|
|
|
|
While broken 4xm decoding or a broken OS/2 build would not be important,
|
|
|
|
|
the separation to normal is somewhat fuzzy.
|
|
|
|
|
For feature requests this priority would be used for things many people
|
|
|
|
|
want.
|
|
|
|
|
Regressions also should be marked as important, regressions are bugs that
|
|
|
|
|
don't exist in a past revision or another branch.
|
|
|
|
|
|
|
|
|
|
normal
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
minor
|
|
|
|
|
Bugs and patches about things like spelling errors, "mp2" instead of
|
|
|
|
|
"mp3" being shown and such.
|
|
|
|
|
Feature requests about things few people want or which do not make a big
|
|
|
|
|
difference.
|
|
|
|
|
|
|
|
|
|
wish
|
|
|
|
|
Something that is desirable to have but that there is no urgency at
|
|
|
|
|
all to implement, e.g. something completely cosmetic like a website
|
|
|
|
|
restyle or a personalized doxy template or the FFmpeg logo.
|
|
|
|
|
This priority is not valid for bugs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Status:
|
|
|
|
|
-------
|
|
|
|
|
new
|
|
|
|
|
initial state
|
|
|
|
|
|
|
|
|
|
open
|
|
|
|
|
intermediate states
|
|
|
|
|
|
|
|
|
|
closed
|
|
|
|
|
final state
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Analyzed flag:
|
|
|
|
|
--------------
|
|
|
|
|
Bugs which have been analyzed and where it is understood what causes them
|
|
|
|
|
and which exact chain of events triggers them. This analysis should be
|
|
|
|
|
available as a message in the bug report.
|
|
|
|
|
Note, do not change the status to analyzed without also providing a clear
|
|
|
|
|
and understandable analysis.
|
|
|
|
|
This state implicates that the bug either has been reproduced or that
|
|
|
|
|
reproduction is not needed as the bug is already understood.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Type/Status/Substatus:
|
|
|
|
|
----------
|
|
|
|
|
*/new/new
|
|
|
|
|
Initial state of new bugs, patches and feature requests submitted by
|
|
|
|
|
users.
|
|
|
|
|
|
|
|
|
|
*/open/open
|
|
|
|
|
Issues which have been briefly looked at and which did not look outright
|
|
|
|
|
invalid.
|
|
|
|
|
This implicates that no real more detailed state applies yet. Conversely,
|
|
|
|
|
the more detailed states below implicate that the issue has been briefly
|
|
|
|
|
looked at.
|
|
|
|
|
|
|
|
|
|
*/closed/duplicate
|
|
|
|
|
Bugs, patches or feature requests which are duplicates.
|
|
|
|
|
Note that patches dealing with the same thing in a different way are not
|
|
|
|
|
duplicates.
|
|
|
|
|
Note, if you mark something as duplicate, do not forget setting the
|
|
|
|
|
superseder so bug reports are properly linked.
|
|
|
|
|
|
|
|
|
|
*/closed/invalid
|
|
|
|
|
Bugs caused by user errors, random ineligible or otherwise nonsense stuff.
|
|
|
|
|
|
|
|
|
|
*/closed/needs_more_info
|
|
|
|
|
Issues for which some information has been requested by the developers,
|
|
|
|
|
but which has not been provided by anyone within reasonable time.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bug/closed/fixed
|
|
|
|
|
Bugs which have to the best of our knowledge been fixed.
|
|
|
|
|
|
|
|
|
|
bug/closed/wont_fix
|
|
|
|
|
Bugs which we will not fix. Possible reasons include legality, high
|
|
|
|
|
complexity for the sake of supporting obscure corner cases, speed loss
|
|
|
|
|
for similarly esoteric purposes, et cetera.
|
|
|
|
|
This also means that we would reject a patch.
|
|
|
|
|
If we are just too lazy to fix a bug then the correct state is open
|
|
|
|
|
and unassigned. Closed means that the case is closed which is not
|
|
|
|
|
the case if we are just waiting for a patch.
|
|
|
|
|
|
|
|
|
|
bug/closed/works_for_me
|
|
|
|
|
Bugs for which sufficient information was provided to reproduce but
|
|
|
|
|
reproduction failed - that is the code seems to work correctly to the
|
|
|
|
|
best of our knowledge.
|
|
|
|
|
|
|
|
|
|
patch/open/approved
|
|
|
|
|
Patches which have been reviewed and approved by a developer.
|
|
|
|
|
Such patches can be applied anytime by any other developer after some
|
|
|
|
|
reasonable testing (compile + regression tests + does the patch do
|
|
|
|
|
what the author claimed).
|
|
|
|
|
|
|
|
|
|
patch/open/needs_changes
|
|
|
|
|
Patches which have been reviewed and need changes to be accepted.
|
|
|
|
|
|
|
|
|
|
patch/closed/applied
|
|
|
|
|
Patches which have been applied.
|
|
|
|
|
|
|
|
|
|
patch/closed/rejected
|
|
|
|
|
Patches which have been rejected.
|
|
|
|
|
|
|
|
|
|
feature_request/closed/implemented
|
|
|
|
|
Feature requests which have been implemented.
|
|
|
|
|
|
|
|
|
|
feature_request/closed/wont_implement
|
|
|
|
|
Feature requests which will not be implemented. The reasons here could
|
|
|
|
|
be legal, philosophical or others.
|
|
|
|
|
|
|
|
|
|
Note, please do not use type-status-substatus combinations other than the
|
|
|
|
|
above without asking on ffmpeg-dev first!
|
|
|
|
|
|
|
|
|
|
Note2, if you provide the requested info do not forget to remove the
|
|
|
|
|
needs_more_info substatus.
|
|
|
|
|
|
|
|
|
|
Component:
|
|
|
|
|
----------
|
|
|
|
|
|
|
|
|
|
avcodec
|
|
|
|
|
issues in libavcodec/*
|
|
|
|
|
|
|
|
|
|
avformat
|
|
|
|
|
issues in libavformat/*
|
|
|
|
|
|
|
|
|
|
avutil
|
|
|
|
|
issues in libavutil/*
|
|
|
|
|
|
|
|
|
|
regression test
|
|
|
|
|
issues in tests/*
|
|
|
|
|
|
|
|
|
|
ffmpeg
|
|
|
|
|
issues in or related to ffmpeg.c
|
|
|
|
|
|
|
|
|
|
ffplay
|
|
|
|
|
issues in or related to ffplay.c
|
|
|
|
|
|
|
|
|
|
ffprobe
|
|
|
|
|
issues in or related to ffprobe.c
|
|
|
|
|
|
|
|
|
|
ffserver
|
|
|
|
|
issues in or related to ffserver.c
|
|
|
|
|
|
|
|
|
|
build system
|
|
|
|
|
issues in or related to configure/Makefile
|
|
|
|
|
|
|
|
|
|
regression
|
|
|
|
|
bugs which were not present in a past revision
|
|
|
|
|
|
|
|
|
|
trac
|
|
|
|
|
issues related to our issue tracker
|
