The controversies so far... 1. checksum in frame headers/syncpoints I did very much like the elegance with the syncpoints, however I did not like the hacks in code to accomplish this (frame header parser in find_syncpoint, put_frame using put_syncpoint to a temporary buffer, demuxing frame header is dependant of "saw syncpoint" context). So I have no strong feelings either way with this. I do have a small proposal for overhead reduction in new method (if it's stupid say so and I'll drop it) - has_checksum being implicit by the rules it is manditory for - so you can save frame codes or a byte for coded flags... Come to think of it, the frame header for a frame that needs has_checksum is large already anyway... 2. limiting max_distance, max_frame_size I say, keep them VLC, but add a MUST in spec regarding their value... Using 'u(16)' is as silly as using it for the 'tmp_mul' vars in the main header which also have a MUST restriction... 3. prefix/compression for frames Not sure if this is an actual controversy, possibly the flamewar going on has nothing to do with this (let's keep mplayer g5926 flames for another mailing list :). I'm quite against the prefix stuff, for a completely other reason - it's a silly complexity for something that does not belong in the container. If you're gonna do this, you might as well compress the frames with bzip2 while you're at it. underhead is nice, but not that nice, this will be nothing but a legacy feature in the future... 4. Info frames/streams/packets The first problem: limiting positions where info frames/packets should be Michael you said you're strongly against this, but you also said a muxer should place them sanely and the demuxer should not go crazy looking for them. IMO there should be rules that you can't just put the frames/packets all over the place as you please, and I'd like to find the best ones that stay fully featured while still allowing the demuxer to not have to search everywhere for them. Second problem: dump info streams? There is some advantage to this - info frames don't really have stream like behavior, unless you repeat them often. A NUT-aware streaming server could give the info frame relavent to current position just once, and not be wasteful and repeat often or at all... Info streams can work if you put an EOR closely after the frame, but that is not semantically correct... What I hate about dumping info streams though is some complication to my demuxer api (each call can give a frame or a packet, instead of always a frame), and, if we do dump info streams, I very much want a restriction that info packets that are global (chapter_id >=0 ?) can only come after main headers, and not wherever... Thinking again about my streaming example, the file isn't seekable anyway, and if you dump it, and you're still using the info frames instead of remuxing them to info packets, you deserve what you get of an unseekable/bad seekable file... (Which would nicely discourage using info frames in places where it is inappropiatte - not live streams..) - ods15
On Fri, Mar 03, 2006 at 07:31:12PM +0200, Oded Shimon wrote:
The controversies so far...
1. checksum in frame headers/syncpoints I did very much like the elegance with the syncpoints, however I did not like the hacks in code to accomplish this (frame header parser in find_syncpoint, put_frame using put_syncpoint to a temporary buffer, demuxing frame header is dependant of "saw syncpoint" context). So I have no strong feelings either way with this. I do have a small proposal for overhead reduction in new method (if it's stupid say so and I'll drop it) - has_checksum being implicit by the rules it is manditory for - so you can save frame codes or a byte for coded flags... Come to think of it, the frame header for a frame that needs has_checksum is large already anyway...
Hmm, making it implicit is a good idea. I like that because it avoids wasting framecodes, although of course you could always just use a single 'wasted framecode' for "everything coded explicitly" which would probably be the most sane way to do huge frames.
2. limiting max_distance, max_frame_size I say, keep them VLC, but add a MUST in spec regarding their value... Using 'u(16)' is as silly as using it for the 'tmp_mul' vars in the main header which also have a MUST restriction...
Agree.
3. prefix/compression for frames Not sure if this is an actual controversy, possibly the flamewar going on has nothing to do with this (let's keep mplayer g5926 flames for another mailing list :).
Agree. :)
I'm quite against the prefix stuff, for a completely other reason - it's a silly complexity for something that does not belong in the container. If you're gonna do this, you might as well compress the frames with bzip2 while you're at it. underhead is nice, but not that nice, this will be nothing but a legacy feature in the future...
I tend to agree, but I don't want to argue over this issue since it's gotten totally off-topic and turned into flames about unrelated things. It's up to you and Michael what to do with this.
4. Info frames/streams/packets The first problem: limiting positions where info frames/packets should be Michael you said you're strongly against this, but you also said a muxer should place them sanely and the demuxer should not go crazy looking for them. IMO there should be rules that you can't just put the frames/packets all over the place as you please, and I'd like to find the best ones that stay fully featured while still allowing the demuxer to not have to search everywhere for them.
Agree strongly. Michael, if you insist on having some type of info packets that can be positioned at any random place in the file, I also want there to be some way for the demuxer to know when the file author was sane and only placed the packets where they belong. Info streams with full stream semantics were my preferred solution, but I'm open to other equivalent approaches. Things I don't want though: - being required to transmit a duplicate info packet at the end of a chapter just to update the length. - having to search the whole file to find the info that applies to a given time interval.
Second problem: dump info streams? There is some advantage to this - info frames don't really have stream like behavior, unless you repeat them often. A NUT-aware streaming server could give the info frame relavent to current position just once, and not be wasteful and repeat often or at all... Info streams can work if you put an EOR closely after the frame, but that is not semantically correct... What I hate about dumping info streams though is some complication to my demuxer api (each call can give a frame or a packet, instead of always a frame), and, if we do dump info streams, I very much want a restriction that info packets that are global (chapter_id >=0 ?) can only come after main headers, and not wherever...
IMO this makes sense.
Thinking again about my streaming example, the file isn't seekable anyway, and if you dump it, and you're still using the info frames instead of remuxing them to info packets, you deserve what you get of an unseekable/bad seekable file... (Which would nicely discourage using info frames in places where it is inappropiatte - not live streams..)
Agree; however it's not that bad. Rich
Hi On Fri, Mar 03, 2006 at 12:49:37PM -0500, Rich Felker wrote: [...]
4. Info frames/streams/packets The first problem: limiting positions where info frames/packets should be Michael you said you're strongly against this, but you also said a muxer should place them sanely and the demuxer should not go crazy looking for them. IMO there should be rules that you can't just put the frames/packets all over the place as you please, and I'd like to find the best ones that stay fully featured while still allowing the demuxer to not have to search everywhere for them.
Agree strongly. Michael, if you insist on having some type of info packets that can be positioned at any random place in the file, I also want there to be some way for the demuxer to know when the file author was sane and only placed the packets where they belong. Info streams with full stream semantics were my preferred solution, but I'm open to other equivalent approaches. Things I don't want though:
- being required to transmit a duplicate info packet at the end of a chapter just to update the length.
- having to search the whole file to find the info that applies to a given time interval.
maybe nochange and noadd flags per info packet would make you happy, so as soon as some info is final these would be set and following info packets for the specific "chapter" would have to be identical, that still allows updates on realtime streams ... so the rules would be 1. values MUST not change in a chapter for which a past info packet had the nochange flag set, likewise nothing MUST be added if the noadd flag was set 2. info packets MUST be stored and repeated after every mainheader- streamheader set after which they become known unless they are big or unimportant or irrelevent rich, theres also yet another case where your idealistic restrictions cause troubble, and that is the next song/show/lecture/... in case of a realtime stream, yeah if its known i would like to know it so i can decide if i keep sitting infront of my computer or if i can do something else in case i dont want to hear it [...] -- Michael
On Fri, Mar 03, 2006 at 07:44:45PM +0100, Michael Niedermayer wrote:
Hi
On Fri, Mar 03, 2006 at 12:49:37PM -0500, Rich Felker wrote: [...]
4. Info frames/streams/packets The first problem: limiting positions where info frames/packets should be Michael you said you're strongly against this, but you also said a muxer should place them sanely and the demuxer should not go crazy looking for them. IMO there should be rules that you can't just put the frames/packets all over the place as you please, and I'd like to find the best ones that stay fully featured while still allowing the demuxer to not have to search everywhere for them.
Agree strongly. Michael, if you insist on having some type of info packets that can be positioned at any random place in the file, I also want there to be some way for the demuxer to know when the file author was sane and only placed the packets where they belong. Info streams with full stream semantics were my preferred solution, but I'm open to other equivalent approaches. Things I don't want though:
- being required to transmit a duplicate info packet at the end of a chapter just to update the length.
- having to search the whole file to find the info that applies to a given time interval.
maybe nochange and noadd flags per info packet would make you happy, so as soon as some info is final these would be set and following info packets for the specific "chapter" would have to be identical, that still allows updates on realtime streams ...
so the rules would be
1. values MUST not change in a chapter for which a past info packet had the nochange flag set, likewise nothing MUST be added if the noadd flag was set 2. info packets MUST be stored and repeated after every mainheader- streamheader set after which they become known unless they are big or unimportant or irrelevent
This is a lot of added complexity for no gain over what I proposed... Still it's better than nothing.
rich, theres also yet another case where your idealistic restrictions cause troubble, and that is the next song/show/lecture/... in case of a realtime stream, yeah if its known i would like to know it so i can decide if i keep sitting infront of my computer or if i can do something else in case i dont want to hear it
How do my restrictions preclude a next-song field? IMO you have a misperception of what I'm asking for. Rich
Hi On Fri, Mar 03, 2006 at 02:06:07PM -0500, Rich Felker wrote:
On Fri, Mar 03, 2006 at 07:44:45PM +0100, Michael Niedermayer wrote:
Hi
On Fri, Mar 03, 2006 at 12:49:37PM -0500, Rich Felker wrote: [...]
4. Info frames/streams/packets The first problem: limiting positions where info frames/packets should be Michael you said you're strongly against this, but you also said a muxer should place them sanely and the demuxer should not go crazy looking for them. IMO there should be rules that you can't just put the frames/packets all over the place as you please, and I'd like to find the best ones that stay fully featured while still allowing the demuxer to not have to search everywhere for them.
Agree strongly. Michael, if you insist on having some type of info packets that can be positioned at any random place in the file, I also want there to be some way for the demuxer to know when the file author was sane and only placed the packets where they belong. Info streams with full stream semantics were my preferred solution, but I'm open to other equivalent approaches. Things I don't want though:
- being required to transmit a duplicate info packet at the end of a chapter just to update the length.
- having to search the whole file to find the info that applies to a given time interval.
maybe nochange and noadd flags per info packet would make you happy, so as soon as some info is final these would be set and following info packets for the specific "chapter" would have to be identical, that still allows updates on realtime streams ...
so the rules would be
1. values MUST not change in a chapter for which a past info packet had the nochange flag set, likewise nothing MUST be added if the noadd flag was set 2. info packets MUST be stored and repeated after every mainheader- streamheader set after which they become known unless they are big or unimportant or irrelevent
This is a lot of added complexity for no gain over what I proposed... Still it's better than nothing.
no its much simpler then what you proposed, you proposed a complicated and very limited system of info packets, frames and streams where the end times of the frames would have to be calucaled based on future packet timstamps, my system has no info streams or frames, just info packets and they never depend on any timestamps of any packet and the demuxer never has to seek anywhere to search for them the muxer must place them where they will be needed like in every other standard
rich, theres also yet another case where your idealistic restrictions cause troubble, and that is the next song/show/lecture/... in case of a realtime stream, yeah if its known i would like to know it so i can decide if i keep sitting infront of my computer or if i can do something else in case i dont want to hear it
How do my restrictions preclude a next-song field? IMO you have a misperception of what I'm asking for.
your restriction was that info must not be stored outside its relevance area (start .. end to which it applies) the next field you propose above violates this if OTOH this rule only applies to chapter_start/len then iam happy and we will just put dummy values in this and store all the actual info in next-* fields and if if you dont insist on that restriction anymore then no need for a 2x complexity double level next-* system, just store the info packet describing the next song [...] -- Michael
On Fri, Mar 03, 2006 at 11:25:55PM +0100, Michael Niedermayer wrote:
This is a lot of added complexity for no gain over what I proposed... Still it's better than nothing.
no its much simpler then what you proposed, you proposed a complicated and very limited system of info packets, frames and streams where the end times of the frames would have to be calucaled based on future packet timstamps, my system has no info streams or frames, just info packets and they never depend on any timestamps of any packet and the demuxer never has to seek anywhere to search for them the muxer must place them where they will be needed like in every other standard
"Where they will be needed" is completely undefined and often the file author has a very braindamaged idea of "where they will be needed" based on their intentions of what you will be able to do with the file (which often explicitly excludes save-to-disk).
rich, theres also yet another case where your idealistic restrictions cause troubble, and that is the next song/show/lecture/... in case of a realtime stream, yeah if its known i would like to know it so i can decide if i keep sitting infront of my computer or if i can do something else in case i dont want to hear it
How do my restrictions preclude a next-song field? IMO you have a misperception of what I'm asking for.
your restriction was that info must not be stored outside its relevance area (start .. end to which it applies) the next field you propose above violates this
Not at all. A "next song" field is relevant during the current song, and not relevant once the next song actually starts playing. Relevance has a very specific technical definition here, and that definition does not preclude you from doing what you want to do.
if OTOH this rule only applies to chapter_start/len then iam happy and we will just put dummy values in this and store all the actual info in next-* fields
This is perfectly valid according to my spec, albeit rather stupid for most purposes.
and if if you dont insist on that restriction anymore then no need for a 2x complexity double level next-* system, just store the info packet describing the next song
OK I see where you're coming from. Actually I don't object to being able to 'presend' info like this. What I object to is being able to retroactively change info, or having to scan backwards for info. In particular, I find it very bad if the info might not be stored during the chapter itself at all, or if the info might be changed at some unboundedly-distant point in the future. Does this make more sense? I was writing a draft explaining my position better but maybe we're finally making progress on this without it.. Rich
Hi On Fri, Mar 03, 2006 at 07:31:12PM +0200, Oded Shimon wrote:
The controversies so far...
1. checksum in frame headers/syncpoints I did very much like the elegance with the syncpoints, however I did not like the hacks in code to accomplish this (frame header parser in find_syncpoint, put_frame using put_syncpoint to a temporary buffer, demuxing frame header is dependant of "saw syncpoint" context). So I have no strong feelings either way with this. I do have a small proposal for overhead reduction in new method (if it's stupid say so and I'll drop it) - has_checksum being implicit by the rules it is manditory for - so you can save frame codes or a byte for coded flags... Come to think of it, the frame header for a frame that needs has_checksum is large already anyway...
iam weakly against the implicit checksum without a flag, why: * if by whatever reason a past timestamp is messed up the implicit rule would be messed up too * no way to add extra checksums if theres no flag
2. limiting max_distance, max_frame_size I say, keep them VLC, but add a MUST in spec regarding their value... Using 'u(16)' is as silly as using it for the 'tmp_mul' vars in the main header which also have a MUST restriction...
well, iam certainly in favor of MUST restrictions on these values though i would prefer choosing a type which makes it impossible to violate the restriction maybe saying that a (de)muxer MUST treat a value outside the 1...x range as x would be a compromise
3. prefix/compression for frames Not sure if this is an actual controversy, possibly the flamewar going on has nothing to do with this (let's keep mplayer g5926 flames for another mailing list :).
I'm quite against the prefix stuff, for a completely other reason - it's a silly complexity for something that does not belong in the container. If you're gonna do this, you might as well compress the frames with bzip2 while you're at it. underhead is nice, but not that nice, this will be nothing but a legacy feature in the future...
you think all the new stuff the standard comitees will produce wont have redundant startcodes?
4. Info frames/streams/packets The first problem: limiting positions where info frames/packets should be Michael you said you're strongly against this, but you also said a muxer should place them sanely and the demuxer should not go crazy looking for them. IMO there should be rules that you can't just put the frames/packets all over the place as you please, and I'd like to find the best ones that stay fully featured while still allowing the demuxer to not have to search everywhere for them.
ok
Second problem: dump info streams? There is some advantage to this - info frames don't really have stream like behavior, unless you repeat them often. A NUT-aware streaming server could give the info frame relavent to current position just once, and not be wasteful and repeat often or at all... Info streams can work if you put an EOR closely after the frame, but that is not semantically correct...
iam strongly against EOR tricks ...
What I hate about dumping info streams though is some complication to my demuxer api (each call can give a frame or a packet, instead of always a frame), and, if we do dump info streams, I very much want a restriction that info packets that are global (chapter_id >=0 ?) can only come after main headers, and not wherever...
i have no strong oppinion on mainheader-infopacket relative ordering as long as it doesnt depend on info packet contents [...] -- Michael
On Fri, Mar 03, 2006 at 07:21:08PM +0100, Michael Niedermayer wrote:
Hi
On Fri, Mar 03, 2006 at 07:31:12PM +0200, Oded Shimon wrote:
The controversies so far...
1. checksum in frame headers/syncpoints I did very much like the elegance with the syncpoints, however I did not like the hacks in code to accomplish this (frame header parser in find_syncpoint, put_frame using put_syncpoint to a temporary buffer, demuxing frame header is dependant of "saw syncpoint" context). So I have no strong feelings either way with this. I do have a small proposal for overhead reduction in new method (if it's stupid say so and I'll drop it) - has_checksum being implicit by the rules it is manditory for - so you can save frame codes or a byte for coded flags... Come to think of it, the frame header for a frame that needs has_checksum is large already anyway...
iam weakly against the implicit checksum without a flag, why: * if by whatever reason a past timestamp is messed up the implicit rule would be messed up too * no way to add extra checksums if theres no flag
I still intend to have the flag... Just automatically set it on
2. limiting max_distance, max_frame_size I say, keep them VLC, but add a MUST in spec regarding their value... Using 'u(16)' is as silly as using it for the 'tmp_mul' vars in the main header which also have a MUST restriction...
well, iam certainly in favor of MUST restrictions on these values though i would prefer choosing a type which makes it impossible to violate the restriction maybe saying that a (de)muxer MUST treat a value outside the 1...x range as x would be a compromise
No objection
3. prefix/compression for frames Not sure if this is an actual controversy, possibly the flamewar going on has nothing to do with this (let's keep mplayer g5926 flames for another mailing list :).
I'm quite against the prefix stuff, for a completely other reason - it's a silly complexity for something that does not belong in the container. If you're gonna do this, you might as well compress the frames with bzip2 while you're at it. underhead is nice, but not that nice, this will be nothing but a legacy feature in the future...
you think all the new stuff the standard comitees will produce wont have redundant startcodes?
Everybody will use Snow! :P Saddens me that they still haven't been obsoleted...
4. Info frames/streams/packets The first problem: limiting positions where info frames/packets should be Michael you said you're strongly against this, but you also said a muxer should place them sanely and the demuxer should not go crazy looking for them. IMO there should be rules that you can't just put the frames/packets all over the place as you please, and I'd like to find the best ones that stay fully featured while still allowing the demuxer to not have to search everywhere for them.
ok
Second problem: dump info streams? There is some advantage to this - info frames don't really have stream like behavior, unless you repeat them often. A NUT-aware streaming server could give the info frame relavent to current position just once, and not be wasteful and repeat often or at all... Info streams can work if you put an EOR closely after the frame, but that is not semantically correct...
iam strongly against EOR tricks ...
Yeah I said myself, it's just not right.
What I hate about dumping info streams though is some complication to my demuxer api (each call can give a frame or a packet, instead of always a frame), and, if we do dump info streams, I very much want a restriction that info packets that are global (chapter_id >=0 ?) can only come after main headers, and not wherever...
i have no strong oppinion on mainheader-infopacket relative ordering as long as it doesnt depend on info packet contents
I'm somewhat confused by that statement.. You mean, you don't mind a rule "all info packets must come after main headers", but against "all info packets with X must come after main headers". Well, OK, how do you feel about: all info packets must come after main headers all info frames must be hapter_id < 0 And... all info frames must have chapter_start<=pts<=chapter_end . I think these are all the restrictions I'm interested in. - ods15
Hi On Fri, Mar 03, 2006 at 08:43:50PM +0200, Oded Shimon wrote:
On Fri, Mar 03, 2006 at 07:21:08PM +0100, Michael Niedermayer wrote:
Hi
On Fri, Mar 03, 2006 at 07:31:12PM +0200, Oded Shimon wrote:
The controversies so far...
1. checksum in frame headers/syncpoints I did very much like the elegance with the syncpoints, however I did not like the hacks in code to accomplish this (frame header parser in find_syncpoint, put_frame using put_syncpoint to a temporary buffer, demuxing frame header is dependant of "saw syncpoint" context). So I have no strong feelings either way with this. I do have a small proposal for overhead reduction in new method (if it's stupid say so and I'll drop it) - has_checksum being implicit by the rules it is manditory for - so you can save frame codes or a byte for coded flags... Come to think of it, the frame header for a frame that needs has_checksum is large already anyway...
iam weakly against the implicit checksum without a flag, why: * if by whatever reason a past timestamp is messed up the implicit rule would be messed up too * no way to add extra checksums if theres no flag
I still intend to have the flag... Just automatically set it on
so a frame which has checksum=no will be legal and have a checksum? iam strongly against this, either no flag or a flag but not such a hack
2. limiting max_distance, max_frame_size I say, keep them VLC, but add a MUST in spec regarding their value... Using 'u(16)' is as silly as using it for the 'tmp_mul' vars in the main header which also have a MUST restriction...
well, iam certainly in favor of MUST restrictions on these values though i would prefer choosing a type which makes it impossible to violate the restriction maybe saying that a (de)muxer MUST treat a value outside the 1...x range as x would be a compromise
No objection
commited [...]
What I hate about dumping info streams though is some complication to my demuxer api (each call can give a frame or a packet, instead of always a frame), and, if we do dump info streams, I very much want a restriction that info packets that are global (chapter_id >=0 ?) can only come after main headers, and not wherever...
i have no strong oppinion on mainheader-infopacket relative ordering as long as it doesnt depend on info packet contents
I'm somewhat confused by that statement.. You mean, you don't mind a rule "all info packets must come after main headers", but against "all info packets with X must come after main headers".
yes
Well, OK, how do you feel about: all info packets must come after main headers
iam very slightly against this but i dont really care
all info frames must be hapter_id < 0
And... all info frames must have chapter_start<=pts<=chapter_end .
is there anything info frames can what info packets cant? if no then i dont care about how info frames are restricted as i would simply choose not to use them otherwise i very strongly object against both [...] -- Michael
On Fri, Mar 03, 2006 at 11:50:44PM +0100, Michael Niedermayer wrote:
On Fri, Mar 03, 2006 at 08:43:50PM +0200, Oded Shimon wrote:
I'm somewhat confused by that statement.. You mean, you don't mind a rule "all info packets must come after main headers", but against "all info packets with X must come after main headers".
yes
Well, OK, how do you feel about: all info packets must come after main headers
iam very slightly against this but i dont really care
all info frames must be hapter_id < 0
And... all info frames must have chapter_start<=pts<=chapter_end .
is there anything info frames can what info packets cant? if no then i dont care about how info frames are restricted as i would simply choose not to use them otherwise i very strongly object against both
OK, figured you'd be against... I'll outline what I want... (and I think what Rich wants) 1. Info packets, which can only come after main headers, are "global" in that they never provide new information - after reading them once when first reading main headers, you can safely skip all future info packets when you skip headers as well. This is basically the rule in the spec right now: All info packets MUST appear after main headers at begginning of file, and SHOULD be repeated after all main headers unless they are very large. 2. Info frames never store global info, and the only reason to use them would be that not all information is known when beginning to create the file (live streamm...). Finding info frames for a certain region does not need to parse the whole file, and not because the demuxer lives on an assumption that the muxer is sane, but because the spec explicitly says so. Michael, do you have a spec to accomodate these goals together with your own?.. One more idea: All info frames pts<=chapter_end and There must be a frame with pts==chapter_start (convert_ts or whatever) I'm hating that there is so much controversy over such a.. cosmetic issue :/ - ods15
Hi On Sat, Mar 04, 2006 at 06:48:34PM +0200, Oded Shimon wrote:
On Fri, Mar 03, 2006 at 11:50:44PM +0100, Michael Niedermayer wrote:
On Fri, Mar 03, 2006 at 08:43:50PM +0200, Oded Shimon wrote:
I'm somewhat confused by that statement.. You mean, you don't mind a rule "all info packets must come after main headers", but against "all info packets with X must come after main headers".
yes
Well, OK, how do you feel about: all info packets must come after main headers
iam very slightly against this but i dont really care
all info frames must be hapter_id < 0
And... all info frames must have chapter_start<=pts<=chapter_end .
is there anything info frames can what info packets cant? if no then i dont care about how info frames are restricted as i would simply choose not to use them otherwise i very strongly object against both
OK, figured you'd be against...
I'll outline what I want... (and I think what Rich wants)
1. Info packets, which can only come after main headers, are "global" in that they never provide new information - after reading them once when first reading main headers, you can safely skip all future info packets when you skip headers as well. This is basically the rule in the spec right now: All info packets MUST appear after main headers at begginning of file, and SHOULD be repeated after all main headers unless they are very large.
2. Info frames never store global info, and the only reason to use them would be that not all information is known when beginning to create the file (live streamm...). Finding info frames for a certain region does not need to parse the whole file, and not because the demuxer lives on an assumption that the muxer is sane, but because the spec explicitly says so.
Michael, do you have a spec to accomodate these goals together with your own?..
no, there is no such spec
One more idea: All info frames pts<=chapter_end and There must be a frame with pts==chapter_start (convert_ts or whatever)
I'm hating that there is so much controversy over such a.. cosmetic issue :/
this is not a cosmetic issue, you guys want restrictions which make no sense and which restrict actually usefull and needed cases heres what i have in my nut fork on my disk: (note, there are no info streams) Rules for realtime streams: If a info packet X is transmitted anywhere then an info packet with the same chapter and stream_id MUST be placed so that there is never a mainheader and following frame covered by the info packet without the info packet inbetween example: M(mainheader) F(frame covered by infoPacket) f(other frame) I(info) M f f M f I f F F M I F F M I F F f f M f f M as a special exception very large and unimportant info packets can be transmitted less often If 2 info packets have the same chapter_id and stream_id then the earlier MUST be ignored (the last info packet is the most correct, this allows updating or correcting info) Rules for non realtime streams: 2 info packets with the same chapter_id and stream_id MUST be identical Every info packet which is stored anywhere in the file MUST also be stored after every mainheader-streamheader set [...] -- Michael
On Sun, Mar 05, 2006 at 02:59:09PM +0100, Michael Niedermayer wrote:
On Sat, Mar 04, 2006 at 06:48:34PM +0200, Oded Shimon wrote:
I'm hating that there is so much controversy over such a.. cosmetic issue :/
this is not a cosmetic issue, you guys want restrictions which make no sense and which restrict actually usefull and needed cases
heres what i have in my nut fork on my disk: (note, there are no info streams)
Rules for realtime streams:
If a info packet X is transmitted anywhere then an info packet with the same chapter and stream_id MUST be placed so that there is never a mainheader and following frame covered by the info packet without the info packet inbetween example: M(mainheader) F(frame covered by infoPacket) f(other frame) I(info) M f f M f I f F F M I F F M I F F f f M f f M as a special exception very large and unimportant info packets can be transmitted less often
If 2 info packets have the same chapter_id and stream_id then the earlier MUST be ignored (the last info packet is the most correct, this allows updating or correcting info)
Rules for non realtime streams:
2 info packets with the same chapter_id and stream_id MUST be identical
Every info packet which is stored anywhere in the file MUST also be stored after every mainheader-streamheader set
This looks good to me. I'm officially walking out of this convo (I never cared strongly about any of this anyway), if you and Rich agree on some spec, whatever it may be, commit it and I'll be happy... - ods15
Hi On Sun, Mar 05, 2006 at 02:59:09PM +0100, Michael Niedermayer wrote:
Hi
On Sat, Mar 04, 2006 at 06:48:34PM +0200, Oded Shimon wrote:
On Fri, Mar 03, 2006 at 11:50:44PM +0100, Michael Niedermayer wrote:
On Fri, Mar 03, 2006 at 08:43:50PM +0200, Oded Shimon wrote:
I'm somewhat confused by that statement.. You mean, you don't mind a rule "all info packets must come after main headers", but against "all info packets with X must come after main headers".
yes
Well, OK, how do you feel about: all info packets must come after main headers
iam very slightly against this but i dont really care
all info frames must be hapter_id < 0
And... all info frames must have chapter_start<=pts<=chapter_end .
is there anything info frames can what info packets cant? if no then i dont care about how info frames are restricted as i would simply choose not to use them otherwise i very strongly object against both
OK, figured you'd be against...
I'll outline what I want... (and I think what Rich wants)
1. Info packets, which can only come after main headers, are "global" in that they never provide new information - after reading them once when first reading main headers, you can safely skip all future info packets when you skip headers as well. This is basically the rule in the spec right now: All info packets MUST appear after main headers at begginning of file, and SHOULD be repeated after all main headers unless they are very large.
2. Info frames never store global info, and the only reason to use them would be that not all information is known when beginning to create the file (live streamm...). Finding info frames for a certain region does not need to parse the whole file, and not because the demuxer lives on an assumption that the muxer is sane, but because the spec explicitly says so.
Michael, do you have a spec to accomodate these goals together with your own?..
no, there is no such spec
One more idea: All info frames pts<=chapter_end and There must be a frame with pts==chapter_start (convert_ts or whatever)
I'm hating that there is so much controversy over such a.. cosmetic issue :/
this is not a cosmetic issue, you guys want restrictions which make no sense and which restrict actually usefull and needed cases
heres what i have in my nut fork on my disk: (note, there are no info streams)
Rules for realtime streams:
If a info packet X is transmitted anywhere then an info packet with the same chapter and stream_id MUST be placed so that there is never a mainheader and following frame covered by the info packet without the info packet inbetween example: M(mainheader) F(frame covered by infoPacket) f(other frame) I(info) M f f M f I f F F M I F F M I F F f f M f f M as a special exception very large and unimportant info packets can be transmitted less often
If 2 info packets have the same chapter_id and stream_id then the earlier MUST be ignored (the last info packet is the most correct, this allows updating or correcting info)
Rules for non realtime streams:
2 info packets with the same chapter_id and stream_id MUST be identical
Every info packet which is stored anywhere in the file MUST also be stored after every mainheader-streamheader set
rich, do you agree with these and removial of info streams? [...] -- Michael
2006/3/5, Michael Niedermayer <michaelni@gmx.at>:
Hi
On Sat, Mar 04, 2006 at 06:48:34PM +0200, Oded Shimon wrote:
On Fri, Mar 03, 2006 at 11:50:44PM +0100, Michael Niedermayer wrote:
On Fri, Mar 03, 2006 at 08:43:50PM +0200, Oded Shimon wrote:
I'm somewhat confused by that statement.. You mean, you don't mind a rule "all info packets must come after main headers", but against "all info packets with X must come after main headers".
yes
Well, OK, how do you feel about: all info packets must come after main headers
iam very slightly against this but i dont really care
all info frames must be hapter_id < 0
And... all info frames must have chapter_start<=pts<=chapter_end .
is there anything info frames can what info packets cant? if no then i dont care about how info frames are restricted as i would simply choose not to use them otherwise i very strongly object against both
OK, figured you'd be against...
I'll outline what I want... (and I think what Rich wants)
1. Info packets, which can only come after main headers, are "global" in that they never provide new information - after reading them once when first reading main headers, you can safely skip all future info packets when you skip headers as well. This is basically the rule in the spec right now: All info packets MUST appear after main headers at begginning of file, and SHOULD be repeated after all main headers unless they are very large.
2. Info frames never store global info, and the only reason to use them would be that not all information is known when beginning to create the file (live streamm...). Finding info frames for a certain region does not need to parse the whole file, and not because the demuxer lives on an assumption that the muxer is sane, but because the spec explicitly says so.
Michael, do you have a spec to accomodate these goals together with your own?..
no, there is no such spec
One more idea: All info frames pts<=chapter_end and There must be a frame with pts==chapter_start (convert_ts or whatever)
I'm hating that there is so much controversy over such a.. cosmetic issue :/
this is not a cosmetic issue, you guys want restrictions which make no sense and which restrict actually usefull and needed cases
heres what i have in my nut fork on my disk: (note, there are no info streams)
Rules for realtime streams:
If a info packet X is transmitted anywhere then an info packet with the same chapter and stream_id MUST be placed so that there is never a mainheader and following frame covered by the info packet without the info packet inbetween example: M(mainheader) F(frame covered by infoPacket) f(other frame) I(info) M f f M f I f F F M I F F M I F F f f M f f M as a special exception very large and unimportant info packets can be transmitted less often
If 2 info packets have the same chapter_id and stream_id then the earlier MUST be ignored (the last info packet is the most correct, this allows updating or correcting info)
Rules for non realtime streams:
2 info packets with the same chapter_id and stream_id MUST be identical
Every info packet which is stored anywhere in the file MUST also be stored after every mainheader-streamheader set
Somehow I don't like to distinguish between realtime and non-realtime streams. I am concern about how will the later info stream be found on seeking. It is quite possible for it to be missed. (assuming you can seek in realtime stream, e.g. by storing or buffering it).
Hi On Mon, Mar 06, 2006 at 10:39:01AM +0200, Ivan Kalvachev wrote: [...]
this is not a cosmetic issue, you guys want restrictions which make no sense and which restrict actually usefull and needed cases
heres what i have in my nut fork on my disk: (note, there are no info streams)
Rules for realtime streams:
If a info packet X is transmitted anywhere then an info packet with the same chapter and stream_id MUST be placed so that there is never a mainheader and following frame covered by the info packet without the info packet inbetween example: M(mainheader) F(frame covered by infoPacket) f(other frame) I(info) M f f M f I f F F M I F F M I F F f f M f f M as a special exception very large and unimportant info packets can be transmitted less often
If 2 info packets have the same chapter_id and stream_id then the earlier MUST be ignored (the last info packet is the most correct, this allows updating or correcting info)
Rules for non realtime streams:
2 info packets with the same chapter_id and stream_id MUST be identical
Every info packet which is stored anywhere in the file MUST also be stored after every mainheader-streamheader set
Somehow I don't like to distinguish between realtime and non-realtime streams.
I am concern about how will the later info stream be found on seeking. It is quite possible for it to be missed. (assuming you can seek in realtime stream, e.g. by storing or buffering it).
well, lets see, if the seek happens purely in the clients buffer then theres no issue as the client must have seen all the needed info already, that leaves the issue with asking the server to seek to X, here there are a few specific cases 1. the server dynamically inserts the needed info (no problem) 2. back_ptrs are set so that they point to the info pakets (no problem) 3. back ptrs ignore info packets (problem here) so only case 3 matters for us, we could simply add a rule that dissalows it in realtime streams now how does the rich-oded proposal differ, not at all their info streams would either force back_ptrs to point to info frames or would missuse EOR and cause info not to be found, we can achive the same here so again lets see which solutions there would be for case 3 (serverside seek but server is not able to dynamically insert info packets and backptrs ignore info packets) A. dissalow it B. use info streams and dissalow ranodom EORs (practically identical to A.) C. per stream back ptrs and pts in the syncpoints, and require the demuxer to seek first to the info packets and then seek to the actual video/audio (O(N*log(N)) overhead per N streams, mandatory high complexity on the demuxer side) iam in favor of A. and iam strongly against C. [...] -- Michael
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). lu
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? [...] -- Michael
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. BTW I'm presently out of town. Sorry for no notice/replies. Rich
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) [...] -- Michael
Michael Niedermayer wrote:
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)
I'd use MUST accept and either SHOULD or MAY use the freshest info packet. Just to let people who don't care about the issue simply ignore it. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
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
On Tuesday 07 March 2006 18:48, Rich Felker wrote:
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.
I think the keyword is "stumble across". Obviously if the muxer wants the demuxer to be able to find the packet, it should put it at the start. It's acceptable IMO to not find it if it's in the middle, but if it does find a new one accidentally when playing the file normally, it should inform the playing application of it, and not silently discard it.
Hi On Tue, Mar 07, 2006 at 07:23:05PM +0200, Jan Knutar wrote:
On Tuesday 07 March 2006 18:48, Rich Felker wrote:
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.
I think the keyword is "stumble across".
Obviously if the muxer wants the demuxer to be able to find the packet, it should put it at the start. It's acceptable IMO to not find it if it's in the middle, but if it does find a new one accidentally when playing the file normally, it should inform the playing application of it, and not silently discard it.
exactly * demuxer NEVER searches for info, theres no need for that * current muxers put same info after every main-stream header set * demuxer MUST pass latest found info to user app rich whats your oppinion about this? [...] -- Michael
On Tue, Mar 07, 2006 at 10:59:50PM +0100, Michael Niedermayer wrote:
Hi
On Tue, Mar 07, 2006 at 07:23:05PM +0200, Jan Knutar wrote:
On Tuesday 07 March 2006 18:48, Rich Felker wrote:
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.
I think the keyword is "stumble across".
Obviously if the muxer wants the demuxer to be able to find the packet, it should put it at the start. It's acceptable IMO to not find it if it's in the middle, but if it does find a new one accidentally when playing the file normally, it should inform the playing application of it, and not silently discard it.
exactly * demuxer NEVER searches for info, theres no need for that * current muxers put same info after every main-stream header set * demuxer MUST pass latest found info to user app
rich whats your oppinion about this?
Mostly OK. However I don't really like the third requirement since it deals with the demuxer/app interface which so far we have left unspecified. That is, we have specified what a compliant process reading a NUT file must/should do, but we have not specified whether or how this should be broken into a demuxer library and a calling application. IMO this latter distinction does not belong in the NUT spec. The spec should deal with the contents of the file and how it should be interpreted, not application implementation issues. Otherwise, OK. Rich
participants (6)
-
Ivan Kalvachev -
Jan Knutar -
Luca Barbato -
Michael Niedermayer -
Oded Shimon -
Rich Felker