[FFmpeg-devel] Please clean up incoming
Thu Oct 23 11:51:02 CEST 2008
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:
> 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
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
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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel