[whatwg] media elements: Relative seeking

[Calogero Alex Baldacchino]

Eric Carlson ha scritto:
>
> On Nov 24, 2008, at 2:21 PM, Calogero Alex Baldacchino wrote:
>
>> Well, the length attribute could be an indication about such limit 
>> and could accept a generic value, such as 'unknown' (or '0', with the 
>> same meaning - just to have only numerical values) to indicate an 
>> endless stream (i.e. a realtime iptv): in such a case, any seeking 
>> operation could be either prohibited or just related to the amount of 
>> yet played content which is eventually present in a local cache.
>>
>   It is a mistake to assume that media data is present in the local 
> cache after it has been played. Some devices have very limited storage 
> (eg. small handhelds) and choose to use a very limited non-persistent 
> cache, live streams have essentially unbounded size and can't be 
> cached, even downloaded content can be so large that clients on a 
> desktop class machine may choose to no buffer the entire file.
>
> eric
>
Ok, I understand that point was too unclear, and I have to write 
something meaningful, lol!
What I meant was: let's assume the user agent has a somewhat buffer big 
enough to maintain a part of the yet played contet; such a buffer could 
be a portion of the download buffer, or a somewhat buffer acting like a 
proper, little cache (or variable in size from u.a. to u.a. - that's it: 
I called such a client-side non-better-defined buffer a 'local cache', 
not meaning that should be persistent); if this happens (and the user 
agents - or any codec avaied of - should know what part of the stream 
has yet been played and is still in the buffer, if any exists), the user 
agent could allow a backward seek limitedly to the amount of buffered, 
yet-played stream, and also buffer a little portion of the following 
stream, not much, just what would be enough to let a "retarded" playback 
of the stream (in such a scenario, after a while the buffered content 
would/could be discarded, so the 'local' cache would be a little and non 
persistent one). Of course all of this could (and perhaps should) be 
implementation dependent, I just aimed (in my crazy mind) to briefly 
trace such eventuality.

However, the above suggests me something else: a somewhat user agent 
could give the opportunity to record a (portion of a) stream (despite 
this being a 'fixed-size' audio/video or a livestream - for the sake of 
this mail I'm disregarding any DRM related concern), so there could be a 
real persistent cache, which could also work as a 'set-top-box' cache 
allowing retarded playback of a live stream (such a cache could even be 
non-local, but provided by a remote server as a web-based service, 
eventually related with the streamed content provider; in such a case, 
the user agent would coordinate with the remote cache, i.e. getting 
informations about the cache start point, the current position and the 
overall duration). Perhaps the specificacions could sketch out such a 
possibility too, yet leaving it to the implementation. Or perhaps that's 
out of the specifications scope, and I'm just wasting my and your 
time... if so, I apologize.
Regards.
 
 
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f
 
 Sponsor:
 Scegli Carta Eureka per tutti i tuoi acquisti! Con zero costi di attivazione avrai un credito fino a 3000 euro. Attivala ora!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8428&d=25-11