[NUT-devel] Info packets in NUT stream (spec bugs?)

[Michael Niedermayer]

Hi

On Fri, Nov 17, 2006 at 09:31:40AM +0200, Oded Shimon wrote:
> On Thu, Nov 16, 2006 at 12:12:53AM +0100, Michael Niedermayer wrote:
> > On Wed, Nov 15, 2006 at 11:29:12PM +0100, Michael Niedermayer wrote:
> > > also you dont need syncpoints over TCP, its a waste of bandwidth ...
> > 
> > heres a simple nut streaming spec proposal (whats not explicitly overriden
> > is as defined by the current nut spec)
> > 
> > streaming in general:
> > * nut is transmitted raw (no extra headers)
> > * info may change and be transmitted anywhere
> > * the client can (if supported by the server do seeks, ask for header or
> >   info retransmitts, and ask for intra refresh (keyframe), and request
> >   a syncpoint)
> > 
> > streaming over error free channels:
> > * main, stream and info headers MUST NOT be repeateded unless requested by
> >   the client and supported by the server
> > * there is only 1 syncpoint after the headers unless server side seeking
> >   is supported and used
> > -----
> > streaming over channels with packet loss:
> > * packet boundaries are aligned with nut frame starts where possible
> > * packet boundaries are aligned with slice starts where possible
> > * FLAG_CODED_PTS SHOULD be set for all frames which use a frame from
> >   a previous packet to calculate the pts
> > * if the packet starts with a framecode then it MUST have FLAG_CHECKSUM
> >   set (that way packets which continue past packets can be distinguished
> >   from packets starting new frames)
> 
> 
> This doesn't seem like a streaming protocol, more like a butchering of the 
> nut spec (most obvious, allowing syncpoints not be written - this is an 
> obvious violation of max_distance). This doesn't necessarily make it a bad 
> idea (if you are completely error free, and not seeking, syncpoints are 
> redundant and non-trivial to calculate for their back_ptr), but it does 
> not seem like something to be written in a seperate document and being 
> called a "streaming protocol" - it's a modified NUT format spec for 
> streaming... And I think it's probably a bad idea to have several modified 
> specs (it's somewhat like mpeg-ts, mpeg-ps, mpeg-bla).

no mpeg-ts and mpeg-ps are much more different then what i proposed

the problem simply is that different environments/systems have different
requirements, if there is packet loss then some additional things are needed
if not they are a waste, surely some minimum error recovery stuff can always
be added but then again you where the one saying you will ignore the spec
and not repeat headers as its not needed in your case! so what do you
argue against? seems like its what you yourself wanted?
if you buther the spec by omiting repeated header then butcher it enough
so it cannot be played if dumped raw otherwise such broken streams will
spread not neccessarily originating from stream dumps but maybe rather
people who like to safe 0.1% space

and then info packets, i will not accpet info to be unfindable, that is
files stored on disk must have at least

O(number of distinct info packets) to enumerate all distinct info packets
O(file size) is not ok
simply adding a single back pointer to midstream info packets would help
alot here

also very nice would be
O(number of apllicable info packets * log n) to find info for a specific time
though we currently dont gurantee that

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