[Live-devel] Query for Live555 forum

[Morgan Tørvolt]

> 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 :-)

I know, It was part of discussion. Did not know the fact about you not
having a deal with Amino though. I will advice them to get in touch
with you.

> 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.

I believe that very few STBs are produced for use over general
internet. It would be way to unreliable for high quality TV anyway as
bit error rates at 10^-9 or better is neede to not degrade user
experience notably, and packetloss is a common problem on internet.
Boxes are supposed to be on a strictly controlled network with lots of
datarate headroom, at least in the backbone.

> 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.)

Exactly. Nobody even wants other providers to provide triple play
services trough their first mile equipment, so it will probably not
happen in near future eighter. If you don't need it, why pay for it?
Very small buffer also gives simpler software, possibly simpler
circuits and board layout, less errors (as larger memory chips have a
higher error rate), easier to design and so on.

> 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...)

Agreed. That would be the smart thing to do. The problem could be
syncing the decoder again. If the server and STB is sufficiently
smart, it should work. I do not know of any standard on how to do
this, so I suspect it would be implemented differently on different
servers, giving much of the same problem RTSP has today, but probably
even worse.

-Morgan-