[NUT-devel] transport stream (for live streaming) = container + protocol IN ONE

[Rich Felker]

On Mon, Sep 18, 2006 at 04:22:54PM +0200, Jörg Hartmann wrote:
> You call it "proper unix philosophy" to let the protocol handle priority 
> and retransmission for live streaming and not to care the least for this 
> when designing the container.

I think you're coming from a misinterpretation of what "live
streaming" means. To us (or me at least) live streamability just means
the ability to write and read the file over a (reliable) serial
transmission line, e.g. a pipe or tcp socket, without having to seek
or provide out-of-band information.

> But you probably know that a protocol needs 
> to know about the content of the container (droppable frames, most 
> important stream/channel/pictures/info parts etc.) to handle that 
> efficiently.

This is "standard knowledge" but I strongly question whether knowing
any of that is useful. If it is useful, it's useful only to the server
implementation, and thus it can be stored in whatever out-of-band data
format you like, or parsed directly from the codec frames at runtime.

The NUT container is not a script for a streaming media server to tell
it what to do. It's a packaging of the frames to be played by the
player that receives them. Again this is where unix philosophy comes
in to play.

> And that the overheads of both container and surrounding 
> protocol add up.

Yes this happens no matter what you do, due to IP headers and ethernet
headers being oversized. A few extra bytes of your own transport
protocol is invisible on top of that.

> And you probably also know that transport streams for 
> "live streaming" or "live broadcasting" (like MPEG-TS) are for good reasons 

These "good reasons" are not accepted by me and probably not by some
of the other developers as well. Anyway now you're talking about a
completely separate topic, broadcasting, as opposed to streaming
between peers with bidirectional communication.

> designed as both in one: protocol and container. Or INSTEAD of both. So my 
> question is: If you only create a container, and while doing that don't 
> even think of how a live-streaming protocol for its use might look like, 
> why do you think that any non-idiot would use it for live streaming at all 

Live streaming works perfectly well with any "streamable" (see my
first paragraph for the definition) container over reliable
transmission channels (tcp socket, etc.). The only case where this
sort of transmission is not acceptable is when you're planning to
saturate the transmission line, and most sane cases of line saturation
are broadcast systems like TV where there's no line of communication
back from the receiver to the sender.

Of course there are also things like multicast IP, but again unless
you're saturating the lines (which is a very bad idea on the
internet!) retransmission of all dropped packets over a reliable
protocol is a perfectly acceptable system. Clients wanting to record a
copy of the live stream will very much appreciate having all dropped
packets retransmitted, even if they come too late for presentation.

> - instead of a transport stream that is designed from the start to handle 
> the whole of live streaming? Or if you plan to use it for live streaming: 
> why don't you at least take the protocol part (and how both parts add up to 
> an efficient transport system)into consideration (now and not after 1.0)?

Disregarding everything I said above, there is a draft for a spec of
the sort you want. If you want to work on it, read the nut-devel
archives and talk to Michael who wrote it. It provides a combined
container/transport protocol using NUT-like syntax and losslessly
preserving all the information in NUT, but it is and will be
independent from the NUT container. Of course unless there's interest
(from people like yourself) it probably will never see the light of
day...

Rich