[FFmpeg-devel] Please clean up incoming

[Aurelien Jacobs]

The Wanderer wrote:

> Aurelien Jacobs wrote:
> 
> > Robert Swain wrote:
> > 
> >> 2008/10/22 The Wanderer <inverseparadox at comcast.net>:
> 
> >>> 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:
> > 
> >   all
> >   containers
> >     avi
> >     nut
> >     mkv
> >   audio
> >     pcm
> >     mp3
> >     aac
> >   video
> >     theora
> >     vp6
> >     h264
> >   subtitle
> >     dvd
> >     ass
> >   issues
> >     issue510
> >     issue511
> > 
> > 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.

Some other random idea of categories:
 - files with multiple audio tracks
 - files containing attachment objects
 - files containing full metadata
 - files containing chapters description
 - video_fourcc (with all known fourcc as subdirectories)
 - fullHD

> That doesn't sound like a bad idea to me, though there might be
> potentially better ones at some point. It has the downside that it
> doesn't (directly) address the "do we need to keep this file?" question,

Could you list any valid reason why we wouldn't want to keep a file ?
The only one I can think about are:
 - The file never was categorized (left in incoming for more than x days)
 - The file is bigger than xMB and we can't afford keeping such huge file
   (only when free disk space goes under yMB)
In all other situations the files should be kept. They can be useful for
purpose that we will discover later.

> but that ought to be simple enough to handle by one-at-a-time review,
> and then periodically go through the symlink directories and remove any
> dead symlinks.

A cron job removing dead symlinks is trivial.

> Under this scheme, what would we do about files which correspond to bug
> reports and/or unfixed bugs but which have no matching bugtracker issue
> (either because people were lazy or because the report was filed before
> there was a functioning bug tracker)?

Like any other files: symlinks them in all relevant directories (and
if the have no issues/issueXXX symlink that's definitely not a
problem).

> > 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.
> 
> Problem: many of the files in incoming/ have accompanying text files
> describing what the problem with them is (every bug report should have
> such a file, and some non-bug-report files need explanations of what
> they're for as well), and these would need to be available in at least
> the issues/ directories along with their 'partner's. That can't so
> easily be automated the way you describe, I don't think.

2 different simple solutions:
 - put each sample in its own sub-directory in 'all', along with its
   text file
 - enforce text file naming (same name as the sample with .txt appended)

Aurel