[Live-devel] Query for Live555 forum

[Ross Finlayson]

>I guess
>you have access to the same NDA documents from Amino that I do

No, I don't have *any* documentation about the Amino STBs.  (We just 
happen to have an AmiNet 110 sitting around as a result of a project 
done for an earlier customer; that's what I've been using for 
testing.)

Once again, Live Networks, Inc. has no affiliation with Amino 
Technologies, and we don't know enough about their hardware to debug 
it (even if we had the time/inclination to do so; remember that 
they're not the only STB hardware company in existence).  If people 
are having problems with our server(s) streaming to Amino's hardware, 
then the ball is in Amino's court to help figure out exactly why.  We 
have done our part by making our source code available, and by 
providing this public forum.  We also have plans (discussed 
extensively on this list in early February; see the mail archives for 
details) to provide additional Transport Stream 'framer' classes that 
should produce smoother inter-packet delays when streaming.  (No, 
there is no ETA for this; please don't ask :-)


>Most local area lans and ADSL network connections have maximum 5ms
>delay from server, and usually the network jitter is much less than
>that.

Agreed.  However, the point stands that if any such client wishes to 
work well over the general Internet - as opposed to a single LAN only 
- then it *must* provide sufficient jitter buffering.  There is 
*nothing* that a server can ever do that can overcome a lack of 
sufficient buffering at the client.

One of the basic principles of the Internet is that the network is 
assumed to be dumb, and therefore intelligence is migrated to the 
endpoints.  In particular, this means that endpoints should provide 
sufficient buffer memory to compensate for network jitter.  With 
memory being dirt cheap, there is really no excuse anymore not to do 
this.  (If your hardware budget is so limited that you can't provide 
more than 64 kBytes of buffer memory, then perhaps you just can't 
expect your the general Internet to be part of your client's target 
application space.)


>  The reason for making the buffer like this is as noted earlier,
>the low delay trick play functionality. Having a two second buffer is
>not ideal when going ffwd at 32x and pressing play when you see where
>you want to watch from. It will take you a minute forward before you
>are back at 1x.

I don't buy this.  When the user presses 1x play again, the client 
(STB) can just flush any remaining data in the buffer, and request 
that the server resume 1x play from the point in time (NPT) that the 
user wishes to resume, not just the last place where it streamed data 
at 32x.  The RTSP protocol supports this (using the "Range: npt=" 
header in the "PLAY" request).  (Again: Make the endpoints 
sufficiently intelligent...)
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/