On Tue, Mar 07, 2006 at 03:18:54AM +0100, Michael Niedermayer wrote:
Hi
On Mon, Mar 06, 2006 at 07:44:49PM -0500, Rich Felker wrote:
On Mon, Mar 06, 2006 at 05:52:12PM +0100, Michael Niedermayer wrote:
Hi
On Mon, Mar 06, 2006 at 05:33:43PM +0100, Luca Barbato wrote:
Michael Niedermayer wrote:
Hi
[...]
Sorry to be me, but... nut is JUST for stored content, and before someone start telling about http, well it is just serving a file over tcp, it isn't streaming at all.
Could that make the issue die as it should long before? or is somebody is really thinking about streaming NUT over udp making sure each packet is contained in an udp packet?
Nut is good as backing store since it gives you all the informations you need for streaming (using rtp, for example).
well, i am certainly not against droping all the "realtime streaming" stuff objections, comments anyone, rich?
Hmm, are you saying to completely remove nut-internal support for variable info data embedded in the file, and instead have this at a higher level transport layer, if at all? I would be strongly in favor of that.
yes, though i would like to keep the option to add variable info in a later version of nut (so maybe say muxers MUST not change info but demuxers MUST accept it and use the last info packet they stumble across)
This is what I'm strongly against, since it requires a demuxer to read unboundedly into the future in order to conform to the spec. It must be possible to know when you've found all possible info that might be relevant to a certain timespan so you can end the search. Otherwise we're making a spec which is impossible to implement. Rich