MPEG4 XMT tutorial

After my own tutorial on using XMT (XMT-O, actually, a SMIL derivative) and BIFS to author interactive MPEG4 videos (along with the accompanying MPEG4 tutorial article), I found this excellent primer on using XMT-A  to create simple MPEG4 scenes.  XMT-A is lower-level than XMT-O - more control and flexibility, but more complex and more code to write, too.

The author, Jean Le Feuvre, has created a good MPEG4 reference site around the GPAC project - a GNU-licensed implementation that will:

Video streaming for the rest of us

Jon Udell writes in Infoworld about this experience with setting up his own personal webcasting station in no time.  It's this kind of thing that makes ad-hoc personal publishing of video possible.   While Jon points to how easy it was to set up, he also notes in his Weblog that it's still too geeky for anyone and everyone to publish and use video. 


Regarding using start and end times to deep-link into a video file, Jon notes the difficulty of finding good information on the Web.  Part of the reason for that might be that, for some reason, Google is still not indexing the articles in streamingmedia.com.  I'll have to ask my search engine expert friend, Jill Whalen, about that. But in the meantime, here are three pieces on streamingmedia metafiles, with info on how to deep-link into the middle of a video with start and end times.

HTTP is more like streaming than it used to be!

I recently recieved this note from a reader of streamingmedia.com. It relates to my artlcle earlier this year, Streaming vs. Downloading Video: Understanding The Differences:


I checked out the site metioned here, and it is serving audio using HTTP from an Apache 1.3 web server. Indeed, I could advance an hour into the 32kbps audio file with almost instantaneous seek time.  I started up my HTTP packet sniffer, loaded up an audio file, and then slid the RealPlayer's position slider ahead to near the end.  A new HTTP request was sent to the Web server by RealPlayer.  A look at the contents of that header revealed the secret:


HTTP 1.1 supports the Range parameter, which allows a specific byte range of the file to be requested.  The Web server responds with the requested data in a "206 - Partial Content" message.  It won't work with any Web server, but will with many.  The W3C's docs on HTTP 1.1 say the following:


This does remove one of the clear advantages of true streaming over http streaming.  It is clearly possible to seek ahead in a audio or video file streamed from a Web server.  You do need to use a .ram metafile for this to work.  If you link directly to the .rm file in your web page, then the browser will download the file and pass it whole to the RealPlayer (which now has no communication with the server).  If you use a .ram file, then the RealPlayer makes its own connection to the server to get the media file, and that enables it to make Range requests as needed. 

For those who are interested, the full http headers from the transaction appear in the extended entry under the "continue reading" link. 

Captured using the EffeTech HTTP Sniffer 3.5

Initial Request:
GET /ugh/patrick_promo.rm HTTP/1.1
Accept: */*
User-Agent: RMA/1.0 (compatible; RealMedia)
Icy-MetaData: 1
Bandwidth: 10485800
ClientID: WinNT_5.0_6.0.11.868_RealPlayer_RN10PRM_en_686
GUID: 00000000-0000-0000-0000-000000000000
Language: en, *
RegionData: 02163
SupportsMaximumASMBandwidth: 1
Connection: Keep-Alive
Host: samples.deepconnections.com
Accept-Language: en, *
Accept-Encoding: gzip

Initial Response:
HTTP/1.1 200 OK
Date: Wed, 03 Dec 2003 18:33:03 GMT
Server: Apache/1.3.28 (Unix) mod_ssl/2.8.15 OpenSSL/0.9.7c PHP/4.3.3
Last-Modified: Thu, 20 Nov 2003 18:21:40 GMT
ETag: "3e18523-e8ecde-3fbd0634"
Accept-Ranges: bytes
Content-Length: 15264990
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: audio/x-pn-realaudio

Seek Request:
GET /ugh/patrick_promo.rm HTTP/1.1
Accept: */*
User-Agent: RMA/1.0 (compatible; RealMedia)
Icy-MetaData: 1
Bandwidth: 10485800
ClientID: WinNT_5.0_6.0.11.868_RealPlayer_RN10PRM_en_686
GUID: 00000000-0000-0000-0000-000000000000
Language: en, *
RegionData: 02163
SupportsMaximumASMBandwidth: 1
Connection: Keep-Alive
Host: samples.deepconnections.com
Accept-Language: en, *
Accept-Encoding: gzip
Range:bytes=9914094-

Seek Response:
HTTP/1.1 206 Partial Content
Date: Wed, 03 Dec 2003 18:33:11 GMT
Server: Apache/1.3.28 (Unix) mod_ssl/2.8.15 OpenSSL/0.9.7c PHP/4.3.3
Last-Modified: Thu, 20 Nov 2003 18:21:40 GMT
ETag: "3e18523-e8ecde-3fbd0634"
Accept-Ranges: bytes
Content-Length: 5350896
Content-Range: bytes 9914094-15264989/15264990
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: audio/x-pn-realaudio

Interactive MPEG4 authoring - more notes

My article on Interactive MPEG4 Authoring using XMT appeared last week on streamingmedia.com and is getting a lot of traffic.  One thing I've learned from readers is that the interactive MPEG4 example and source code that goes with the article requires a lot of CPU horsepower to play.  Users on 450MHz Pentium systems get choppy, halting playback, and I've confirmed this using my old dual-processor Pentium 300MHz machine.  On my 800MHz machines, the example, which is encoded at about 516kbps, plays just fine. 

I'm not sure if it's the IBM M4Play applet I'm using that's got high CPU needs or if any MPEG4 player that supports this profile would be the same.  Since the QT and RealONE players don't play this content, I haven't been able to easily check it out.