Wed, 18 Aug 2004
I want to recant on my complaining the other day about Epitonic now
having playlist functionality in the Black Box. If it's easy enough
to do that they can crank it out in a week, then my software is
not a saleable product.
thom says:
BlogDigger now has a media page with links to WMV, MP3, MOV, and Torrents.
DownHillBattle.org wants BitTorrent to be easier. There are also projects that work on the "convergence" of RSS and BT.
But the *real* culture is birthing right now with VideoBlogs. Jay at MomentShowing is covering this initiative to have more video produced by people like you and me to proliferate over the Internet. It is amazing the possibilities. Imagine in the very near future, if you will, the ability to sit down at your TV and quickly watch a montage of your friends' and relatives' day?
Ultimately, highly distributed and aggregated video promises even more... like *local* news that *local* again... Experts or on-location reporters providing you with their uncensored, and unfiltered reports.
We're almost there with the technology. I mean, really close. Just a
little more elbow grease and *bing* -- you pop a URL into your laptop
and sit down with a bowl of popcorn. The sole problem is horribly
broken A/V software from the 90s.
Listening: Harold
Gilchrist's audioblog. What strikes me first isn't so much what
he's talking about as how well it works to listen to audioblogs while
you're working. It just fits.
That said, what he's talking about -- "rise of the RSS enclosure
audioblogger" -- is good stuff. He talks about the growth and
increasing sophistication of audiobloggers, famed former television
personality Adam Curry in particular, and comes down against blogging
of third party audio that the rights holders wouldn't want to be out
there.
A proposed modification to RSS enclosures
I have been thinking about the RSS enclosure efficiency problem.
Auto-downloading every referenced A/V element, whether it gets
listened to or not, is a big bandwidth hit with questionable value.
Denial of service attacks are virtually guaranteed. It seems to me
that people who want to incur this should be able to, but others
shouldn't have to risk it.
Proposal #1: RSS enclosures should only be auto-downloaded when there
is a very good reason to assume the author of the feed is providing
the bandwidth for the enclosure. The enclosure will be
auto-downloaded if and only if it is on the same server as the feed.
This is not very good security, however, so my next proposal is...
Proposal #2: Use HTTP authentication to guarantee that the resource is
intended to be exposed to direct linking. Let's say that there is a
file http://example.com/foo.mp3 and it has a username and password
attached; an RSS enclosure element would have to specify the username
and password before an aggregator would pre-fetch the object. We
would require there to be access restrictions on items for
auto-download, and we would require enclosure elements to give a
username and password. The benefit of this is that it allows us to be
sure that a host has taken affirmative steps to enable
pre-fetching.
Proposal #3: Keep looking in this general direction, i.e. within HTTP,
for existing practice related to pre-fetching. One example I found
was the
Mozilla pre-fetching FAQ.
Jon Udell: A frustrated consumer of media
If we want media content to flow naturally on the web, the first and most obvious thing to do is publish the stream URLs. The second thing is to put some simple authoring capability into the player. It needs two new buttons: Start Clip and End Clip. When you click Start Clip, it notes the start time of a clip. When you click End Clip, it notes the end time and gives you the URL of the clip.
It's no wonder that David is a "frustrated consumer of media." We deploy AV content on the web in a style that emulates television but is antithetical to the web. I'd like to change that.
permalink
