On Sat, Aug 1, 2009 at 12:13 AM, Michael Dalemdale@wikimedia.org wrote:
true... people will never upload to site without instant gratification ( cough youtube cough ) ...
Hm? I just tried uploading to youtube and there was a video up right away. Other sizes followed within a minute or two.
At any rate its not replacing the firefogg that has instant gratification at point of upload its ~just another option~...
As another option— Okay. But video support on the site stinks because of lack of server side 'thumbnailing' for video. People upload multi-megabit videos, which is a good thing for editing, but then they don't play well for most users.
Just doing it locally is hard— we've had failed SOC projects for this— doing it distributed has all the local complexity and then some.
Also I should add that this wiki@home system just gives us distributed transcoding as a bonus side effect ... its real purpose will be to distribute the flattening of edited sequences. So that 1) IE users can view them 2) We can use effects that for the time being are too computationally expensive to render out in real-time in javascript 3) you can download and play the sequences with normal video players and 4) we can transclude sequences and use templates with changes propagating to flattened versions rendered on the wiki@home distributed computer
I'm confused as to why this isn't being done locally at Wikimedia. Creating some whole distributed thing seems to be trading off something inexpensive (machine cycles) for something there is less supply of— skilled developer time. Processing power is really inexpensive.
Some old copy of ffmpeg2theora on a single core of my core2 desktop process a 352x288 input video at around 100mbit/sec (input video consumption rate). Surely the time and cost required to send a bunch of source material to remote hosts is going to offset whatever benefit this offers.
We're also creating a whole additional layer of cost in that someone have to police the results.
Perhaps my tyler durden reference was too indirect:
* Create a new account * splice some penises 30 minutes into some talking head video * extreme lulz.
Tracking down these instance and blocking these users seems like it would be a fulltime job for a couple of people and it would only be made worse if the naughtyness could be targeted at particular resolutions or fallbacks. (Making it less likely that clueful people will see the vandalism)
While presently many machines in the wikimedia internal server cluster grind away at parsing and rendering html from wiki-text the situation is many orders of magnitude more costly with using transclution and temples with video ... so its good to get this type of extension out in the wild and warmed up for the near future ;)
In terms of work per byte of input the wikitext parser is thousands of times slower than the theora encoder. Go go inefficient software. As a result the difference may be less than many would assume.
Once you factor in the ratio of video to non-video content for the for-seeable future this comes off looking like a time wasting boondoggle.
Unless the basic functionality— like downsampled videos that people can actually play— is created I can't see there ever being a time where some great distributed thing will do any good at all.
The segmenting is going to significant harm compression efficiency for any inter-frame coded output format unless you perform a two pass encode with the first past on the server to do keyframe location detection. Because the stream will restart at cut points.
also true. Good thing theora-svn now supports two pass encoding :) ...
Yea, great, except doing the first pass for segmentation is pretty similar to the computational cost as simply doing a one-pass encode of the video.
but an extra key frame every 30 seconds properly wont hurt your compression efficiency too much..
It's not just about keyframes locations— if you encode separately and then merge you lose the ability to provide continuous rate control. So there would be large bitrate spikes at the splice intervals which will stall streaming for anyone without significantly more bandwidth than the clip.
vs the gain of having your hour long interview trans-code a hundred times faster than non-distributed conversion. (almost instant gratification)
Well tuned you can expect a distributed system to improve throughput at the expense of latency.
Sending out source material to a bunch of places, having them crunch on it on whatever slow hardware they have, then sending it back may win on the dollars per throughput front, but I can't see that having good latency.
true... You also have to log in to upload to commons.... It will make life easier and make abuse of the system more difficult.. plus it can
Having to create an account does pretty much nothing to discourage malicious activity.
act as a motivation factor with distributed@home teams, personal stats and all that jazz. Just as people like to have their name show up on the "donate" wall when making small financial contributions.
"But why donate? Wikimedia is all distributed, right?"
But whatever— It seems that the goal here is to create trendy buzzword technology while basic functionality like simple thumbnailing sits completely unaddressed.