transport stream (for live streaming) = container + protocol IN ONE

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.
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel