[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Freeform-dev] Re: [Imc-ithaca] proposal for media.py
From: |
Brian Szymanski |
Subject: |
[Freeform-dev] Re: [Imc-ithaca] proposal for media.py |
Date: |
Tue, 8 Oct 2002 02:14:58 -0400 (EDT) |
Hi all,
(Aside: Meeting notes for IMC-Ithaca from Sunday are 90% finished as I
write this, coming up before I go to bed.)
As for media.py, all in all, sounds like a good plan - the "right way" to
do it. However, I think allowing people to upload in whatever format they
desire is important, to avoid any sort of tech-elitism (and yes, I know
oggdrop is extremely simple). But perhaps we should force people to learn
if they want to upload, say, 100M at a time, because that'll cause
significant strain on the server... However, a 64k .wav won't hurt us
much.
Peace,
Brian
PS - I wonder if this conversation is more appropriate on freeform-devel
(or at least CC'd to it, as I have done)?
Arc wrote:
> In another project theres work to modify DropOgg to have it, instead,
> encode to specific bitrates on the user's side and send them to the
> server as pre-encoded oggs. This takes care of the user's end and
> releives CPU load on the server end, not to mention the bandwidth needed
> to send wav/aiff.
>
> DropOgg is available for just about everything, linux, mac, windows,
> etc, is GPL'ed, and can be setup in a way where once installed clicking
> on a "Add Multimedia" brings up a DropOgg window that the user can then
> drag and drop their files into. The fishy spins around, encoding all
> the versions we need and sending them to the server as it produces them.
>
> This is a far better system than was previously done, saves bandwidth,
> releives CPU load on the server, only difference is the user will need
> to download and install software to send multimedia - but it's small and
> GPL'ed. A text-only solution is also feasable, ie, the file that
> contains the info for DropOgg (ie, where to send, what bitrates to
> encode to, etc) could also contain a HTML form for uploading pre-encoded
> media (and instructions for doing so) for Lynx and older systems.
>
> In either case, the server will have to check the bitrates once uploaded
> to ensure they're reasonable, but this is a CPU-friendly task.
- [Freeform-dev] Re: [Imc-ithaca] proposal for media.py,
Brian Szymanski <=