[Freeform-dev] Re: [Imc-ithaca] proposal for media.py

[Brian Szymanski]

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.