Hello,
Apologies if this is a flood of questions:
STREAMING TRANSPORT CONTROL:
It looks to me like progressive download over HTTP is the only 'streaming' supported meaning the "download stream" will buffer and start playback before whole clip is fully downloaded, but there is no means for true streaming transport control i.e jumping to near the end of a video clip without having to download/watched up to that point. Can you confirm?
After studying ISO 14496-12 and ISO 13818-1,2,3 this limitation is mostly one of first-generation player architectures.
We recently wrote a JMF DataSource for the Blackberry that shattered all those assumption. Not only did we overcome Blackberry's inability to download any file larger than 256K, we got it to play a 1-hour 100M 3GP file via HTTP. It is entirely possible for a player using HTTP to seek to particular times inside a piece of media, ESPECIALLY with an ISO 14496-12 -derived video.
When we tricked the Blackberry JMF into thinking that the 100 Mbyte video was available locally we observed it read the first few bytes of the resource, then jump to the end (which we accomplished using the bog-standard Range: header) to slurp up the metadata which includes per-frame pointers. Once it had the metadata it was easy to fetch whatever subset of the URL contained the audio and video needed for rendering.
The requirement that the metadata occur before the 'mdat' box is something that can be relaxed by investing less than a week of coding. Random access to files via HTTP is a blind spot for many coders. This obsolete limitation can be observed in mplayer, J2ME, and android. This limitation can and should be removed. The only question is how long it will take the various coders to read section 13.35 of RFC 2616.
