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

[Michael Niedermayer]

Hi

On Sun, Sep 24, 2006 at 02:24:05PM -0400, Rich Felker wrote:
> 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.

its very easy to find out frame priority/dropability, video streams very
very likely fall in one of 2 categories
1. ones which use "arbitrary" frames to predict other frames (only possible
   in h.264)
2. IB...BPB...BP where the IP frames are highest priority and the B frames
   ordering and priority is "related"

now for the whole frame priority thing IMO only 2. matters in practice, and
that a stream is case 2. could be indicated in a nut info packet
in case 2. a simple decode_delay>0 && dts==pts will give you all the lowest
priority frames, the other priority ones can probably also be found by
examining the timestamps

and yes you can construct streams which have dropable frames which cant be
found by the timestamps but such streams simply have no practical relevance
noone generates such streams and it IMHO also makes no sense to generate
them

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is