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

[Jörg Hartmann]

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. 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. And that the overheads of both container and surrounding 
protocol add up. And you probably also know that transport streams for 
"live streaming" or "live broadcasting" (like MPEG-TS) are for good reasons 
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 
- 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)?

Cheers,
J.H.