If one looks into the topic of streaming media standards, one quickly runs into confusion and hype. Lots of people will tout the virtues of one acronym or another. I personally make a living pelting people with acronyms and coming up with new ones. At the end of the day, though, the only standards that matter right now are HTTP and MP3.
This may not be terribly surprising to those that frequent Advogato, but it's something that it pains me to say. I'm one of the co-editors of the RTSP specification, and have been a very active member of the W3C's SYMM Working Group working on SMIL.
The headline and teaser above is to a much longer article that I wrote for a new streaming media community site called Übergid. I encourage you to post your comments over there, as well as here, since as that community builds, there will be people who are not necessarily part of the open source community. Hence, you won't necessarily be preaching to the choir if you talk open source there.
Speaking of open source, a couple of comments did come in about Vorbis. Personally, I've been a big fan of Vorbis, egging on Jack Moffitt (jack) to do the RealPlayer plugin (for which an alpha quality plugin is checked into their CVS repository). I wish the project well, but that's a great example of "nerds flogging an agenda" which I refer to in the Übergid article. The fact of the matter is that the Thomson folks have managed to walk the tightrope pretty well, and though the more savvy open source people may despise the success of MP3, there's enough MP3 content that it'll always be a standard (and hey, patents do expire).
At any rate, I do have some specific issues that I'd like to cover with the open source community. Right now, the heir apparent as a streaming media standard is MPEG-4. However, as has been covered here on Advogato before, the MPEG-4 specification is laden with patents, so much so that the M4IF can't even agree on a licensing policy for those who are willing to pay.
I think there is an opportunity to ensure that a less hideously encumbered video standard becomes the content winner. As near as I know, H.263 is clean (no one has asserted any royalties on this specification). Given that MPEG-4 video is based on H.263, and that H.263v2 (the 1998 version) is just as good, it seems silly to rely on the encumbered version. Both Apple Quicktime and the RealOne Player support this today.
However, there's a dearth of open source software that implements this, and even when it does, it doesn't support enough other standards (RTSP, RTP, MP3) to make it compelling. One project I hold out a lot of hope for is the Live.com Streaming Kit, which includes support for all of the above. However, it's an engine that needs to be incorporated into some other project.
Note that on Windows, it's pretty easy to create a file that has MP3 audio and H.263 video. Download VirtualDub and the Intel H.263 codec, and then convert an AVI file to use the "I263" codec. Alternately, you can download Quicktime, and use it to create your file. However, just by putting it in a Quicktime file, you may have created another encumberance.
I'd like to get some thoughts, and I hope that I inspire some activity on this front.
QoS transport are doomed. Until people are ready to pay for a distinctive different QoS (and this usually doesn't come cheap at all) all efforts toward builting such transport are doomed. So far the attitude "if there is enough people interested, the pipe will grow, and latencies will stabilize" has worked, it might get harder due to the negative economic environement, but so far the improvement is impressive.
But it is important to have formats not encumbered with Patents. I applaud the work of the Vorbis group, maybe there is a scope problem in their effort (hard to not fall in that pit !), but it's very important to have at least a fallback strategy if the patent holders starts to get annoying.
Aside, so when are we gonna get OpenSource SMIL2 players, Nabil has some code too, what's the current state ;-) ?
Daniel
Standards bodies exist to provide sage wisdom which implementers actually benefit from following. 'Standards' must have the following characteristics -
I'm glad to see someone else beating the H.263 drum. Hearing people complain that there's no standard, open source, low-bandwidth video codec gets old when it's not true.
What do you think about VP3? Does it have a chance? (Besides the fact that they need to get some clue and remove the registration requirement from their site...)
What is the sad story of multicast? It seems that no significant streaming ever takes place over the multicast net, yet multicast is a clever and elegant solution to the streaming bandwidth problem. The head-end needs only as much bandwidth as each client.
I understand that in the past, Cisco equipment was mostly incapable of understanding multicast traffic, but that isn't the case anymore and I wonder why multicast still lacks momentum.
Multicast creates at least one route entry per group in every router that the group's traffic passes though. I get the impression that Internet core routers don't have enough spare memory for that.
I do not think it is MP3 nor HTTP per se which are the issue.
people are now accustomed to an interaction mode ("content" hosted on or streamed from "sites") which is unlikely to change. but it will be relatively easy to slip from MP3 to OGG (or, unfortunately, WMF), just as it's been relatively easy to slip new HTML (CSS, javascript, DHTML) or HTTP features (ubiquitous proxying, etags, pipelining) into the browser, or new mail features (CRAM-MD5, ESMTP, APOP, IMAP) into the mail client.
the reason is simple: there are only a handful of well-used, credible access devices (browsers, streaming media players) and they all work exactly the same way. when a point release comes out that supports a new "format" that works exactly the same way the old one did, no user expectations differ, and the user base gradually, unknowingly transitions to the new technology. I do not see any reason to consider waiting the years for MP3 to expire, when there are compelling reasons to enable OGG now, both for the developer and the end-user, and the average shoutcast.com listener or mp3.com downloader will not likely even be aware of when they are using a vorbis (or WMF, sigh) stream, since they did the same thing they always do (activate player, select stream / artist of choice)
I thought people here may be interested in the discussion going on over at the MPEG4IP forum on SourceForge. We're starting to get an interesting discussion going about H.263/MP3/RTSP/RTP interop. Still early, but I think there's some definite possibilities there. While I don't agree with the tactic (promoting MPEG-4), the spirit of the project is a good one. They seem very interested in talking about interoperability using whatever means possible. The thread concerns asking them to widen the scope of things.
For a patent free environment MP3 is irrelevant and MP4 is even less appealing. OGG streaming works. Vp3 needs a lot of work to clean up the released code but could be good - its certainly an equal of DivX without the patent disaster that will turn into
Don't overlook the CU30/QVix codec for real time video either
...it needs to be taken to an established standards group. You go to Xiph.org, and there's an anti-corporate rant in the "about" section, and no feeling of legitimacy. I might be able to get folks here at RealNetworks to take Ogg seriously if it were submitted to the W3C, IETF, OASIS, ITU, or ISO (probably in that order). What would be especially good about W3C is that it would give them an opportunity to show that they are still very much about royalty-free standards (and, make no mistake, at the core, they are...it's just hard to get membership consensus around that, and not 100% necessary in all cases)
Now, whether or not Ogg needs any corporate help for it to succeed is entirely another question (one I won't try to tackle here). However, being someone who works at a corporation who is genuinely interested in fostering tangible interoperability, it's not a practical option at this time, and MP3, though encumbered, is a usable solution.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!
del.icio.us
Digg
Google bookmark
reddit
Simpy
StumbleUpon
Furl
Newsvine
Technorati
Tailrank