1 FFmpeg's bug/feature request tracker manual
2 =================================================
7 FFmpeg uses Trac for tracking issues, new issues and changes to
8 existing issues can be done through a web interface.
10 Issues can be different kinds of things we want to keep track of
11 but that do not belong into the source tree itself. This includes
12 bug reports, feature requests and license violations. We
13 might add more items to this list in the future, so feel free to
14 propose a new `type of issue' on the ffmpeg-devel mailing list if
15 you feel it is worth tracking.
17 It is possible to subscribe to individual issues by adding yourself to the
18 Cc list or to subscribe to the ffmpeg-trac mailing list which receives
19 a mail for every change to every issue.
20 (the above does all work already after light testing)
22 The subscription URL for the ffmpeg-trac list is:
23 https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-trac
24 The URL of the webinterface of the tracker is:
25 https://trac.ffmpeg.org
30 Artwork such as photos, music, banners, and logos.
33 An error, flaw, mistake, failure, or fault in FFmpeg or libav* that
34 prevents it from behaving as intended.
36 feature request / enhancement
37 Request of support for encoding or decoding of a new codec, container
39 Request of support for more, less or plain different output or behavior
40 where the current implementation cannot be considered wrong.
43 Ticket to keep track of (L)GPL violations of ffmpeg by others.
46 Developer requests for hardware, software, specifications, money,
50 A task/reminder such as setting up a FATE client, adding filters to
56 Bugs about data loss and security issues.
57 No feature request can be critical.
60 Bugs which make FFmpeg unusable for a significant number of users.
61 Examples here might be completely broken MPEG-4 decoding or a build issue
63 While broken 4xm decoding or a broken OS/2 build would not be important,
64 the separation to normal is somewhat fuzzy.
65 For feature requests this priority would be used for things many people
67 Regressions also should be marked as important, regressions are bugs that
68 don't exist in a past revision or another branch.
71 Default setting. Use this if the bug does not match the other
72 priorities or if you are unsure of what priority to choose.
75 Bugs about things like spelling errors, "mp2" instead of
76 "mp3" being shown and such.
77 Feature requests about things few people want or which do not make a big
81 Something that is desirable to have but that there is no urgency at
82 all to implement, e.g. something completely cosmetic like a website
83 restyle or a personalized doxy template or the FFmpeg logo.
84 This priority is not valid for bugs.
101 Bugs which have been analyzed and where it is understood what causes them
102 and which exact chain of events triggers them. This analysis should be
103 available as a message in the bug report.
104 Note, do not change the status to analyzed without also providing a clear
105 and understandable analysis.
106 This state implicates that the bug either has been reproduced or that
107 reproduction is not needed as the bug is already understood.
113 Initial state of new bugs and feature requests submitted by
117 Issues which have been briefly looked at and which did not look outright
119 This implicates that no real more detailed state applies yet. Conversely,
120 the more detailed states below implicate that the issue has been briefly
124 Bugs or feature requests which are duplicates.
125 Note, if you mark something as duplicate, do not forget setting the
126 superseder so bug reports are properly linked.
129 Bugs caused by user errors, random ineligible or otherwise nonsense stuff.
131 */closed/needs_more_info
132 Issues for which some information has been requested by the developers,
133 but which has not been provided by anyone within reasonable time.
137 Bugs which have to the best of our knowledge been fixed.
140 Bugs which we will not fix. Possible reasons include legality, high
141 complexity for the sake of supporting obscure corner cases, speed loss
142 for similarly esoteric purposes, et cetera.
143 This also means that we would reject a patch.
144 If we are just too lazy to fix a bug then the correct state is open
145 and unassigned. Closed means that the case is closed which is not
146 the case if we are just waiting for a patch.
148 bug/closed/works_for_me
149 Bugs for which sufficient information was provided to reproduce but
150 reproduction failed - that is the code seems to work correctly to the
151 best of our knowledge.
153 feature_request/closed/fixed
154 Feature requests which have been implemented.
156 feature_request/closed/wontfix
157 Feature requests which will not be implemented. The reasons here could
158 be legal, philosophical or others.
160 Note2, if you provide the requested info do not forget to remove the
161 needs_more_info resolution.
167 issues in libavcodec/*
170 issues in libavdevice/*
173 issues in libavfilter/*
176 issues in libavformat/*
179 issues in libavutil/*
182 issues in or related to configure/Makefile
185 issues in or related to doc/*
188 issues in or related to ffmpeg.c
191 issues in or related to ffplay.c
194 issues in or related to ffprobe.c
197 issues in or related to ffserver.c
200 issues in libpostproc/*
203 issues in libswresample/*
206 issues in libswscale/*
209 issues related to our issue tracker
212 default component; choose this if unsure
215 issues related to the website
218 issues related to the wiki