[FFmpeg-devel] Please clean up incoming

[Michael Niedermayer]

On Thu, Oct 23, 2008 at 12:01:45AM +0200, Aurelien Jacobs wrote:
> 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:
> 
>   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.
> 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.

A slightly different but similar system would be
to have file named like
issue123-matrix_trailer-mpeg_ps-aac-mpeg2.mpg
issue123-matrix_trailer-mpeg_ps-aac-mpeg2.txt
in 2 flat directories that is
incoming and samples
files that are uploaded but do not match this naming could be deleted by
a cron job after some time
a second cron job could build a directory structure with symlinks from
the files in samples, that would be
issues
    issue123
        issue123-matrix_trailer-mpeg_ps-aac-mpeg2.mpg
        issue123-matrix_trailer-mpeg_ps-aac-mpeg2.txt
containers
    mpeg_ps
        issue123-matrix_trailer-mpeg_ps-aac-mpeg2.mpg
        issue123-matrix_trailer-mpeg_ps-aac-mpeg2.txt
codecs
    aac
        issue123-matrix_trailer-mpeg_ps-aac-mpeg2.mpg
        issue123-matrix_trailer-mpeg_ps-aac-mpeg2.txt
    mpeg2
        issue123-matrix_trailer-mpeg_ps-aac-mpeg2.mpg
        issue123-matrix_trailer-mpeg_ps-aac-mpeg2.txt

when now the file is renamed or deleted from samples this cronjob
could also trivially update the symlinks and directories

In such a framework the work left to us would be moving files from
a flat incoming to a flat samples directory with occasional fixing
of file names

also allsamples.txt would become unneeded as a simply directory listing
of the flat samples directory would do

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081023/132a66ad/attachment.pgp>