[FFmpeg-devel] Please clean up incoming

Aurelien Jacobs aurel
Thu Oct 23 00:01:45 CEST 2008

Robert Swain wrote:

> 2008/10/22 The Wanderer <inverseparadox at comcast.net>:
> > Attila Kinali wrote:
> >
> >> On Tue, 21 Oct 2008 10:10:17 -0700 Baptiste Coudurier
> >> <baptiste.coudurier at smartjog.com> wrote:
> >>
> >>> AFAIK, I cannot move the files, so someone else must move them... I
> >>> also guess annoying someone else to move the file will not be very
> >>> efficient.
> >>
> >> Yes, but there are more than enough people who can do that. Just
> >> compile a list of what you'd want to keep and where you'd put it.
> >
> > Prompted by compn, I took a stab at starting to test and potentially
> > organize incoming/ at one point, but ran up against this basic question:
> > in an ideal world where everything were organized correctly, how *would*
> > it be organized?
> >
> > The "everything goes under its bugtracker issue directory" is the only
> > proposition I've seen so far, and it has its downsides - the first one
> > which springs to mind being that not everything is associated with a
> > specific tracker issue (if nothing else, some things should be kept in
> > permanent "sample of this type of file" storage).
> >
> > I don't know how the samples archive should theoretically be organized.
> > I don't know how the non-samples files (present only because they
> > demonstrate an unfixed bug) should be organized. I don't know whether or
> > not there are potentially any files which fall into neither category but
> > should be kept anyway, much less how they should be organized.
> >
> > If answers to these organization questions can be arrived at, I can
> > spend some of my time on testing incoming/ and pointing to where
> > specific files should go. Without that, there's not much I can do but to
> > list whether or not a specific problem seems to still exist.
> Where does one put a file considering each file potentially has:
> - a container
> - a number of audio/video streams using various codecs
> - other features that may be of interest in a sample (metadata?
> probably a plethora of other things...)
> ?

One simple obvious suggestion.
Have the following directory tree:


Then put *all* the actual samples unsorted in the 'all' directory,
and add symlinks in other relevant sub-directories pointing to the
actual sample. More directories/categories can be added at will
when the need arise.
It might be a little painful to setup but it could be partly
automatized using ffmpeg -i on the actual samples to detect their
container/codecs and to generate the symlinks.


More information about the ffmpeg-devel mailing list