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