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). - ods15