Info packets in NUT stream (spec bugs?)
hmm, several bugs found in spec? from spec:
If a info packet is stored anywhere then a muxer MUST also store an identical info packet after every main-stream-header set
This is nonsense in real time streaming, isn't it?.. In real time streaming, the only rule i suggest there should be is that after a main-header set, there should be all global info packets (chapter_id==0), and info packets applying to the current chapter. (e.g., if you joined in the middle of a song, you should get the info packet telling about the song)
info_packet: stream_id_plus1 v chapter_id v chapter_start t chapter_len v [...] chapter_id Id of chapter this packet applies to. If zero, packet applies to whole file. Positive chapter_id's are real chapters and MUST NOT overlap. Negative chapter_id indicate a sub region of file and not a real chapter. chapter_id MUST be unique to the region it represents.
Ahem, negative?.. 'v' unsigned vlc ...
the structure of a undamaged file should look like the following, [...] file: file_id_string while(!eof){ packet_header, main_header, packet_footer reserved_headers for(i=0; i<stream_count; i++){ packet_header, stream_header, packet_footer reserved_headers } while(next_code == info_startcode){ packet_header, info_packet, packet_footer reserved_headers } if(next_code == index_startcode){ packet_header, index_packet, packet_footer } if (!eof) while(next_code != main_startcode){ if(next_code == syncpoint_startcode){ packet_header, syncpoint, packet_footer } frame reserved_headers } }
Is it supposed to be impossible to write an info packet without writing an entire main header set? And I have an API question for libnut demuxer: for the case of info headers after main headers, I plan on looking for them only once and give them to the caller together with the main header information, but what should I do for the case of info packets found in the wild? optional callback function? - ods15
Hi On Sat, Nov 04, 2006 at 03:53:13PM +0200, Oded Shimon wrote:
hmm, several bugs found in spec?
and sending them all in one mail, please dont do this, ill reply with individual mails to this ... [...]
info_packet: stream_id_plus1 v chapter_id v chapter_start t chapter_len v [...] chapter_id Id of chapter this packet applies to. If zero, packet applies to whole file. Positive chapter_id's are real chapters and MUST NOT overlap. Negative chapter_id indicate a sub region of file and not a real chapter. chapter_id MUST be unique to the region it represents.
Ahem, negative?.. 'v' unsigned vlc ...
this is a problem, how should we solve it? every solution will break compatibility strictly speaking we can drop the no overlap requirement or change v->s iam fine with either, whats your and richs preferance? only thing iam against is forbidding overlaping "chapter_ids" entirely [...] -- 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
On Sat, Nov 04, 2006 at 10:19:40PM +0100, Michael Niedermayer wrote:
Hi
On Sat, Nov 04, 2006 at 03:53:13PM +0200, Oded Shimon wrote:
hmm, several bugs found in spec?
and sending them all in one mail, please dont do this, ill reply with individual mails to this ...
[...]
info_packet: stream_id_plus1 v chapter_id v chapter_start t chapter_len v [...] chapter_id Id of chapter this packet applies to. If zero, packet applies to whole file. Positive chapter_id's are real chapters and MUST NOT overlap. Negative chapter_id indicate a sub region of file and not a real chapter. chapter_id MUST be unique to the region it represents.
Ahem, negative?.. 'v' unsigned vlc ...
this is a problem, how should we solve it? every solution will break compatibility strictly speaking
we can drop the no overlap requirement or change v->s iam fine with either, whats your and richs preferance? only thing iam against is forbidding overlaping "chapter_ids" entirely
I preffer v->s . - ods15
On Sat, Nov 04, 2006 at 11:36:24PM +0200, Oded Shimon wrote:
chapter_id Id of chapter this packet applies to. If zero, packet applies to whole file. Positive chapter_id's are real chapters and MUST NOT overlap. Negative chapter_id indicate a sub region of file and not a real chapter. chapter_id MUST be unique to the region it represents.
Ahem, negative?.. 'v' unsigned vlc ...
this is a problem, how should we solve it? every solution will break compatibility strictly speaking
we can drop the no overlap requirement or change v->s iam fine with either, whats your and richs preferance? only thing iam against is forbidding overlaping "chapter_ids" entirely
I preffer v->s .
Me too. There is not a single NUT file with chapter info packets in it, so compatibility is irrelevant. Rich
Hi On Sat, Nov 04, 2006 at 03:53:13PM +0200, Oded Shimon wrote: [...]
And I have an API question for libnut demuxer: for the case of info headers after main headers, I plan on looking for them only once and give them to the caller together with the main header information, but what should I do for the case of info packets found in the wild? optional callback function?
do you also have a callback for normal frames? if yes then it seems the right spot for info packets too, if you have no callbacks then one for info packets looks odd too IMHO you could also simply set a flag if info packets changed, and the user could check that after each packet if needed, or ... really i dont know what is best ... [...] -- 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
Hi On Sat, Nov 04, 2006 at 03:53:13PM +0200, Oded Shimon wrote:
hmm, several bugs found in spec? [...]
the structure of a undamaged file should look like the following, [...] file: file_id_string while(!eof){ packet_header, main_header, packet_footer reserved_headers for(i=0; i<stream_count; i++){ packet_header, stream_header, packet_footer reserved_headers } while(next_code == info_startcode){ packet_header, info_packet, packet_footer reserved_headers } if(next_code == index_startcode){ packet_header, index_packet, packet_footer } if (!eof) while(next_code != main_startcode){ if(next_code == syncpoint_startcode){ packet_header, syncpoint, packet_footer } frame reserved_headers } }
Is it supposed to be impossible to write an info packet without writing an entire main header set?
the text above would suggest so ... is there a problem with this? does it not match something which was agreed upon? (no i dunno) the possibility to write info packets anywere was removed in r16507 at that time we still had info streams, which where later droped also for the case of realtime streams where song info is updated at the song start, well there must be a main header there anyway or you cant start listening ... the exception would be if the main header is transmitted out of band with SDP or similar but then the info packets could as well be transmitted out of band instead of blindly sending them duplicated a few times ... [...] -- 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
On Sat, Nov 04, 2006 at 10:47:45PM +0100, Michael Niedermayer wrote:
Hi
On Sat, Nov 04, 2006 at 03:53:13PM +0200, Oded Shimon wrote:
hmm, several bugs found in spec? [...]
the structure of a undamaged file should look like the following, [...] file: file_id_string while(!eof){ packet_header, main_header, packet_footer reserved_headers for(i=0; i<stream_count; i++){ packet_header, stream_header, packet_footer reserved_headers } while(next_code == info_startcode){ packet_header, info_packet, packet_footer reserved_headers } if(next_code == index_startcode){ packet_header, index_packet, packet_footer } if (!eof) while(next_code != main_startcode){ if(next_code == syncpoint_startcode){ packet_header, syncpoint, packet_footer } frame reserved_headers } }
Is it supposed to be impossible to write an info packet without writing an entire main header set?
the text above would suggest so ... is there a problem with this? does it not match something which was agreed upon? (no i dunno)
the possibility to write info packets anywere was removed in r16507 at that time we still had info streams, which where later droped
There were too many info flamewars for me to remember :)
also for the case of realtime streams where song info is updated at the song start, well there must be a main header there anyway or you cant start listening ... the exception would be if the main header is transmitted out of band with SDP or similar but then the info packets could as well be transmitted out of band instead of blindly sending them duplicated a few times ...
Why would i need to repeat the main headers just for a song change? it involves no codec change or anything else (which is illegal in NUT anyway), just a change of songs, which means nothing but a change of metadata... This is a radio, the main headers are only given for you once at connect (which btw should carry the metadata of the _current_ song), but the metadata can change frequently, so you need to send new info packets, no need to send with it the entire bloated vorbis header... - ods15
Hi On Sun, Nov 05, 2006 at 12:02:04AM +0200, Oded Shimon wrote:
On Sat, Nov 04, 2006 at 10:47:45PM +0100, Michael Niedermayer wrote:
Hi
On Sat, Nov 04, 2006 at 03:53:13PM +0200, Oded Shimon wrote:
hmm, several bugs found in spec? [...]
the structure of a undamaged file should look like the following, [...] file: file_id_string while(!eof){ packet_header, main_header, packet_footer reserved_headers for(i=0; i<stream_count; i++){ packet_header, stream_header, packet_footer reserved_headers } while(next_code == info_startcode){ packet_header, info_packet, packet_footer reserved_headers } if(next_code == index_startcode){ packet_header, index_packet, packet_footer } if (!eof) while(next_code != main_startcode){ if(next_code == syncpoint_startcode){ packet_header, syncpoint, packet_footer } frame reserved_headers } }
Is it supposed to be impossible to write an info packet without writing an entire main header set?
the text above would suggest so ... is there a problem with this? does it not match something which was agreed upon? (no i dunno)
the possibility to write info packets anywere was removed in r16507 at that time we still had info streams, which where later droped
There were too many info flamewars for me to remember :)
also for the case of realtime streams where song info is updated at the song start, well there must be a main header there anyway or you cant start listening ... the exception would be if the main header is transmitted out of band with SDP or similar but then the info packets could as well be transmitted out of band instead of blindly sending them duplicated a few times ...
Why would i need to repeat the main headers just for a song change? it involves no codec change or anything else (which is illegal in NUT anyway), just a change of songs, which means nothing but a change of metadata... This is a radio, the main headers are only given for you once at connect (which btw should carry the metadata of the _current_ song), but the metadata can change frequently, so you need to send new info packets, no need to send with it the entire bloated vorbis header...
as you send a client specific stream (mainheaders just at a specific start) you can as well send the mainheaders and info out of band IMHO, that way they are not part of the nut file and the restrictions wont apply IMHO mainheaders are critical (should be transmited over a reliable protocol like TCP) the normal remaning stream could as well be transmitted over UDP with retransmits only of non B frames or retransmits depending on other parameters (no use in retransmitting data if its in the clients past and not needed for prediction of future frames) also nut is no network protocol, i have my doubts it will be used raw in such a streaming case ... this is more something for nut-np ... the big problem with simply allowing arbitrarily placed info is that it makes the info useless for the normal nut file case as the info cannot be found its like a dvd with chapters but the information about where the chapters begin is stored at the begin of the chapters, you end up with a O(n) search ... so ive some concerns with just saying its ok for streaming, as that leads to nut files laying around which are encoded for streaming ... [...] -- 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
On Sun, Nov 05, 2006 at 12:19:53AM +0100, Michael Niedermayer wrote:
On Sun, Nov 05, 2006 at 12:02:04AM +0200, Oded Shimon wrote:
On Sat, Nov 04, 2006 at 10:47:45PM +0100, Michael Niedermayer wrote:
also for the case of realtime streams where song info is updated at the song start, well there must be a main header there anyway or you cant start listening ... the exception would be if the main header is transmitted out of band with SDP or similar but then the info packets could as well be transmitted out of band instead of blindly sending them duplicated a few times ...
Why would i need to repeat the main headers just for a song change? it involves no codec change or anything else (which is illegal in NUT anyway), just a change of songs, which means nothing but a change of metadata... This is a radio, the main headers are only given for you once at connect (which btw should carry the metadata of the _current_ song), but the metadata can change frequently, so you need to send new info packets, no need to send with it the entire bloated vorbis header...
as you send a client specific stream (mainheaders just at a specific start) you can as well send the mainheaders and info out of band IMHO, that way they are not part of the nut file and the restrictions wont apply IMHO
mainheaders are critical (should be transmited over a reliable protocol like TCP) the normal remaning stream could as well be transmitted over UDP with retransmits only of non B frames or retransmits depending on other parameters (no use in retransmitting data if its in the clients past and not needed for prediction of future frames)
also nut is no network protocol, i have my doubts it will be used raw in such a streaming case ...
It could, there's no real reason you can't just TCP NUT over some simple protocol. Oh no, I'm turning into Ivan :)
this is more something for nut-np ...
I think it would be a bit weak if it would be impossible to send new info data in NUT.. Though I do see the logic that it is a network thing instead of a file thing and should be out of band... I'm a bit torn on this issue...
the big problem with simply allowing arbitrarily placed info is that it makes the info useless for the normal nut file case as the info cannot be found its like a dvd with chapters but the information about where the chapters begin is stored at the begin of the chapters, you end up with a O(n) search ... so ive some concerns with just saying its ok for streaming, as that leads to nut files laying around which are encoded for streaming ...
The proposal I had for this is - info packets not written after main headers are only allowed in real time streaming, and must have chapter_id!=0, and any info packets written after main headers, both in file and in streaming scenario, MUST be repeated together with all main headers. No demuxer would have to search anything past main headers, any info packets given during demuxing is "information update". In the file scenario, all info must be written after the main headers, so no searching necessary. - ods15
On Sun, Nov 05, 2006 at 09:48:46AM +0200, Oded Shimon wrote:
On Sun, Nov 05, 2006 at 12:19:53AM +0100, Michael Niedermayer wrote:
the big problem with simply allowing arbitrarily placed info is that it makes the info useless for the normal nut file case as the info cannot be found its like a dvd with chapters but the information about where the chapters begin is stored at the begin of the chapters, you end up with a O(n) search ... so ive some concerns with just saying its ok for streaming, as that leads to nut files laying around which are encoded for streaming ...
The proposal I had for this is - info packets not written after main headers are only allowed in real time streaming, and must have chapter_id!=0
Just to point something out - we already make a distinction in the spec between real time streaming and file storage - in regards to index and headers must be repeated 3 times... - ods15
On Sun, Nov 05, 2006 at 09:48:46AM +0200, Oded Shimon wrote:
also nut is no network protocol, i have my doubts it will be used raw in such a streaming case ...
It could, there's no real reason you can't just TCP NUT over some simple protocol. Oh no, I'm turning into Ivan :)
Indeed, TCP is the _sane_ method for streaming. All these fancy protocols are for the stupid case where you're saturating the network. If there's any chance that the recipient wants to record the stream, it needs reliable delivery anyway and should just be using TCP. Rich
Hi On Sun, Nov 05, 2006 at 11:56:45AM -0500, Rich Felker wrote:
On Sun, Nov 05, 2006 at 09:48:46AM +0200, Oded Shimon wrote:
also nut is no network protocol, i have my doubts it will be used raw in such a streaming case ...
It could, there's no real reason you can't just TCP NUT over some simple protocol. Oh no, I'm turning into Ivan :)
Indeed, TCP is the _sane_ method for streaming. All these fancy protocols are for the stupid case where you're saturating the network. If there's any chance that the recipient wants to record the stream, it needs reliable delivery anyway and should just be using TCP.
yes, but there are a few issues ... routers might give priority to fancy protocols relative to TCP when it comes to what to send out first, (no i dunno if thats the case iam just guessing) packets can be lost even if the network isnt saturated, and the retransmit will cause the following few packets to arrive later unless you have >= 2x the bandwidth available then what you use and the OS might not give the user app the next data until it has successfully received the retransmitted packet and normal people will complain if they notice problems even just once per hour in a conversation on the phone they will also complain if you add some extra delay to hide the effects of one retransitted packet iam not saying NUT over TCP is silly, iam just saying that with current TCP implementations its not optimal maybe the solution would rather be to change the client TCP implementation so that it gives all packets immedeatly to the user and gives the user the option to send dummy acknowledge packets foe specific missing packets so that no unneccessary retransmits happen ... [...] -- 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
On Sun, Nov 05, 2006 at 06:30:45PM +0100, Michael Niedermayer wrote:
Hi
On Sun, Nov 05, 2006 at 11:56:45AM -0500, Rich Felker wrote:
On Sun, Nov 05, 2006 at 09:48:46AM +0200, Oded Shimon wrote:
also nut is no network protocol, i have my doubts it will be used raw in such a streaming case ...
It could, there's no real reason you can't just TCP NUT over some simple protocol. Oh no, I'm turning into Ivan :)
Indeed, TCP is the _sane_ method for streaming. All these fancy protocols are for the stupid case where you're saturating the network. If there's any chance that the recipient wants to record the stream, it needs reliable delivery anyway and should just be using TCP.
yes, but there are a few issues ... routers might give priority to fancy protocols relative to TCP when it comes to what to send out first, (no i dunno if thats the case iam just guessing) packets can be lost even if the network isnt saturated, and the retransmit will cause the following few packets to arrive later unless you have >= 2x the bandwidth available then what you use and the OS might not give the user app the next data until it has successfully received the retransmitted packet and normal people will complain if they notice problems even just once per hour in a conversation on the phone they will also complain if you add some extra delay to hide the effects of one retransitted packet
This is not the issue here :) Rich exaggurated much, TCP is not the ONLY method for streaming, but for a specific case of a streaming, it is actually a very good method - the case I have in mind is mass radio. This scenario requires no seeking or any fancy stuff, and simple TCP really does the trick. (to get back on topic) And THIS is exactly the situation where I want info packets inside a NUT file, for the radio to tell about the current song. I don't think this is too far-fetched... - ods15
Hi On Sun, Nov 05, 2006 at 09:48:46AM +0200, Oded Shimon wrote:
On Sun, Nov 05, 2006 at 12:19:53AM +0100, Michael Niedermayer wrote:
On Sun, Nov 05, 2006 at 12:02:04AM +0200, Oded Shimon wrote:
On Sat, Nov 04, 2006 at 10:47:45PM +0100, Michael Niedermayer wrote:
also for the case of realtime streams where song info is updated at the song start, well there must be a main header there anyway or you cant start listening ... the exception would be if the main header is transmitted out of band with SDP or similar but then the info packets could as well be transmitted out of band instead of blindly sending them duplicated a few times ...
Why would i need to repeat the main headers just for a song change? it involves no codec change or anything else (which is illegal in NUT anyway), just a change of songs, which means nothing but a change of metadata... This is a radio, the main headers are only given for you once at connect (which btw should carry the metadata of the _current_ song), but the metadata can change frequently, so you need to send new info packets, no need to send with it the entire bloated vorbis header...
as you send a client specific stream (mainheaders just at a specific start) you can as well send the mainheaders and info out of band IMHO, that way they are not part of the nut file and the restrictions wont apply IMHO
mainheaders are critical (should be transmited over a reliable protocol like TCP) the normal remaning stream could as well be transmitted over UDP with retransmits only of non B frames or retransmits depending on other parameters (no use in retransmitting data if its in the clients past and not needed for prediction of future frames)
also nut is no network protocol, i have my doubts it will be used raw in such a streaming case ...
It could, there's no real reason you can't just TCP NUT over some simple protocol. Oh no, I'm turning into Ivan :)
this is more something for nut-np ...
I think it would be a bit weak if it would be impossible to send new info data in NUT.. Though I do see the logic that it is a network thing instead of a file thing and should be out of band... I'm a bit torn on this issue...
the big problem with simply allowing arbitrarily placed info is that it makes the info useless for the normal nut file case as the info cannot be found its like a dvd with chapters but the information about where the chapters begin is stored at the begin of the chapters, you end up with a O(n) search ... so ive some concerns with just saying its ok for streaming, as that leads to nut files laying around which are encoded for streaming ...
The proposal I had for this is - info packets not written after main headers are only allowed in real time streaming, and must have chapter_id!=0, and any info packets written after main headers, both in file and in streaming scenario, MUST be repeated together with all main headers. No demuxer would have to search anything past main headers, any info packets given during demuxing is "information update". In the file scenario, all info must be written after the main headers, so no searching necessary.
hmm, rich what is your oppinion about that? iam unsure if iam against it or not ... [...] -- 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
On Sun, Nov 05, 2006 at 07:07:22PM +0100, Michael Niedermayer wrote:
On Sun, Nov 05, 2006 at 09:48:46AM +0200, Oded Shimon wrote:
On Sun, Nov 05, 2006 at 12:19:53AM +0100, Michael Niedermayer wrote:
the big problem with simply allowing arbitrarily placed info is that it makes the info useless for the normal nut file case as the info cannot be found its like a dvd with chapters but the information about where the chapters begin is stored at the begin of the chapters, you end up with a O(n) search ... so ive some concerns with just saying its ok for streaming, as that leads to nut files laying around which are encoded for streaming ...
The proposal I had for this is - info packets not written after main headers are only allowed in real time streaming, and must have chapter_id!=0, and any info packets written after main headers, both in file and in streaming scenario, MUST be repeated together with all main headers. No demuxer would have to search anything past main headers, any info packets given during demuxing is "information update". In the file scenario, all info must be written after the main headers, so no searching necessary.
hmm, rich what is your oppinion about that? iam unsure if iam against it or not ...
- ods15
On Sun, Nov 05, 2006 at 09:32:44PM +0200, Oded Shimon wrote:
On Sun, Nov 05, 2006 at 07:07:22PM +0100, Michael Niedermayer wrote:
On Sun, Nov 05, 2006 at 09:48:46AM +0200, Oded Shimon wrote:
On Sun, Nov 05, 2006 at 12:19:53AM +0100, Michael Niedermayer wrote:
the big problem with simply allowing arbitrarily placed info is that it makes the info useless for the normal nut file case as the info cannot be found its like a dvd with chapters but the information about where the chapters begin is stored at the begin of the chapters, you end up with a O(n) search ... so ive some concerns with just saying its ok for streaming, as that leads to nut files laying around which are encoded for streaming ...
The proposal I had for this is - info packets not written after main headers are only allowed in real time streaming, and must have chapter_id!=0, and any info packets written after main headers, both in file and in streaming scenario, MUST be repeated together with all main headers. No demuxer would have to search anything past main headers, any info packets given during demuxing is "information update". In the file scenario, all info must be written after the main headers, so no searching necessary.
hmm, rich what is your oppinion about that? iam unsure if iam against it or not ...
- ods15
Objections? Commit? 48 hour notice from now. - ods15
Index: DOCS/tech/nut.txt =================================================================== --- DOCS/tech/nut.txt (revision 20666) +++ DOCS/tech/nut.txt (working copy) @@ -180,11 +180,15 @@ packet_header, index_packet, packet_footer } if (!eof) while(next_code != main_startcode){ - if(next_code == syncpoint_startcode){ - packet_header, syncpoint, packet_footer + packet_header, syncpoint, packet_footer + do{ + frame + }while(next_code == framecode); + reserved_headers + if (realtime_stream) while(next_code == info_startcode){ + packet_header, info_packet, packet_footer + reserved_headers } - frame - reserved_headers } }
@@ -836,9 +840,15 @@ Info: -----
-If a info packet is stored anywhere then a muxer MUST also store an identical +All info packets stored after a main header set MUST also have an identical info packet after every main-stream-header set
+All info packets not stored after a main header set MUST have +chapter_id!=0 . + +Info packets MUST be written after main header sets in non realtime +streams. + If a demuxer has seen several info packets with the same chapter_id and stream_id then it MUST ignore all but the one with the highest position in the file
Hi On Mon, Nov 06, 2006 at 10:56:57AM +0200, Oded Shimon wrote:
On Sun, Nov 05, 2006 at 09:32:44PM +0200, Oded Shimon wrote:
On Sun, Nov 05, 2006 at 07:07:22PM +0100, Michael Niedermayer wrote:
On Sun, Nov 05, 2006 at 09:48:46AM +0200, Oded Shimon wrote:
On Sun, Nov 05, 2006 at 12:19:53AM +0100, Michael Niedermayer wrote:
the big problem with simply allowing arbitrarily placed info is that it makes the info useless for the normal nut file case as the info cannot be found its like a dvd with chapters but the information about where the chapters begin is stored at the begin of the chapters, you end up with a O(n) search ... so ive some concerns with just saying its ok for streaming, as that leads to nut files laying around which are encoded for streaming ...
The proposal I had for this is - info packets not written after main headers are only allowed in real time streaming, and must have chapter_id!=0, and any info packets written after main headers, both in file and in streaming scenario, MUST be repeated together with all main headers. No demuxer would have to search anything past main headers, any info packets given during demuxing is "information update". In the file scenario, all info must be written after the main headers, so no searching necessary.
hmm, rich what is your oppinion about that? iam unsure if iam against it or not ...
- ods15
Objections? Commit? 48 hour notice from now.
i object until i heard a comment from at least rich, comments from everyone else are of course welcome too [...] -- 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
On Mon, Nov 06, 2006 at 01:44:19PM +0100, Michael Niedermayer wrote:
On Mon, Nov 06, 2006 at 10:56:57AM +0200, Oded Shimon wrote:
On Sun, Nov 05, 2006 at 09:32:44PM +0200, Oded Shimon wrote:
On Sun, Nov 05, 2006 at 07:07:22PM +0100, Michael Niedermayer wrote:
On Sun, Nov 05, 2006 at 09:48:46AM +0200, Oded Shimon wrote:
On Sun, Nov 05, 2006 at 12:19:53AM +0100, Michael Niedermayer wrote:
the big problem with simply allowing arbitrarily placed info is that it makes the info useless for the normal nut file case as the info cannot be found its like a dvd with chapters but the information about where the chapters begin is stored at the begin of the chapters, you end up with a O(n) search ... so ive some concerns with just saying its ok for streaming, as that leads to nut files laying around which are encoded for streaming ...
The proposal I had for this is - info packets not written after main headers are only allowed in real time streaming, and must have chapter_id!=0, and any info packets written after main headers, both in file and in streaming scenario, MUST be repeated together with all main headers. No demuxer would have to search anything past main headers, any info packets given during demuxing is "information update". In the file scenario, all info must be written after the main headers, so no searching necessary.
hmm, rich what is your oppinion about that? iam unsure if iam against it or not ...
- ods15
Objections? Commit? 48 hour notice from now.
i object until i heard a comment from at least rich, comments from everyone else are of course welcome too
This is a new proposal: Basically identical to the previous one, only info packets SHOULD NOT appear "in the wild" in non-realtime-streams instead of MUST NOT. Making the distinction between file and realtime streams less strict. Demuxers still SHOULD NOT search for info packets anywhere except after the main headers. I think this is most clean... Comments? - ods15
On Fri, Nov 10, 2006 at 08:57:23AM +0200, Oded Shimon wrote:
On Mon, Nov 06, 2006 at 01:44:19PM +0100, Michael Niedermayer wrote:
On Mon, Nov 06, 2006 at 10:56:57AM +0200, Oded Shimon wrote:
On Sun, Nov 05, 2006 at 09:32:44PM +0200, Oded Shimon wrote:
On Sun, Nov 05, 2006 at 07:07:22PM +0100, Michael Niedermayer wrote:
On Sun, Nov 05, 2006 at 09:48:46AM +0200, Oded Shimon wrote:
On Sun, Nov 05, 2006 at 12:19:53AM +0100, Michael Niedermayer wrote: > the big problem with simply allowing arbitrarily placed info is that it > makes the info useless for the normal nut file case as the info cannot be > found its like a dvd with chapters but the information about where the > chapters begin is stored at the begin of the chapters, you end up with > a O(n) search ... > so ive some concerns with just saying its ok for streaming, as that > leads to nut files laying around which are encoded for streaming ...
The proposal I had for this is - info packets not written after main headers are only allowed in real time streaming, and must have chapter_id!=0, and any info packets written after main headers, both in file and in streaming scenario, MUST be repeated together with all main headers. No demuxer would have to search anything past main headers, any info packets given during demuxing is "information update". In the file scenario, all info must be written after the main headers, so no searching necessary.
hmm, rich what is your oppinion about that? iam unsure if iam against it or not ...
- ods15
Objections? Commit? 48 hour notice from now.
i object until i heard a comment from at least rich, comments from everyone else are of course welcome too
This is a new proposal: Basically identical to the previous one, only info packets SHOULD NOT appear "in the wild" in non-realtime-streams instead of MUST NOT. Making the distinction between file and realtime streams less strict. Demuxers still SHOULD NOT search for info packets anywhere except after the main headers. I think this is most clean...
Comments?
Repost. ... 48 hour notice ...
Index: nut.txt =================================================================== --- nut.txt (revision 20666) +++ nut.txt (working copy) @@ -180,11 +180,15 @@ packet_header, index_packet, packet_footer } if (!eof) while(next_code != main_startcode){ - if(next_code == syncpoint_startcode){ - packet_header, syncpoint, packet_footer + packet_header, syncpoint, packet_footer + do{ + frame + }while(next_code == framecode); + reserved_headers + while(next_code == info_startcode){ + packet_header, info_packet, packet_footer + reserved_headers } - frame - reserved_headers } }
@@ -836,9 +840,15 @@ Info: -----
-If a info packet is stored anywhere then a muxer MUST also store an identical +All info packets stored after a main header set MUST also have an identical info packet after every main-stream-header set
+All info packets not stored after a main header set MUST have +chapter_id!=0 . + +Info packets SHOULD be written after main header sets in non realtime +streams. + If a demuxer has seen several info packets with the same chapter_id and stream_id then it MUST ignore all but the one with the highest position in the file
- ods15
On Sun, Nov 12, 2006 at 05:27:06PM +0200, Oded Shimon wrote:
On Fri, Nov 10, 2006 at 08:57:23AM +0200, Oded Shimon wrote:
On Mon, Nov 06, 2006 at 01:44:19PM +0100, Michael Niedermayer wrote:
On Mon, Nov 06, 2006 at 10:56:57AM +0200, Oded Shimon wrote:
On Sun, Nov 05, 2006 at 09:32:44PM +0200, Oded Shimon wrote:
On Sun, Nov 05, 2006 at 07:07:22PM +0100, Michael Niedermayer wrote:
On Sun, Nov 05, 2006 at 09:48:46AM +0200, Oded Shimon wrote: > On Sun, Nov 05, 2006 at 12:19:53AM +0100, Michael Niedermayer wrote: > > the big problem with simply allowing arbitrarily placed info is that it > > makes the info useless for the normal nut file case as the info cannot be > > found its like a dvd with chapters but the information about where the > > chapters begin is stored at the begin of the chapters, you end up with > > a O(n) search ... > > so ive some concerns with just saying its ok for streaming, as that > > leads to nut files laying around which are encoded for streaming ... > > The proposal I had for this is - info packets not written after main > headers are only allowed in real time streaming, and must have > chapter_id!=0, and any info packets written after main headers, both in > file and in streaming scenario, MUST be repeated together with all main > headers. No demuxer would have to search anything past main headers, any > info packets given during demuxing is "information update". In the file > scenario, all info must be written after the main headers, so no searching > necessary.
hmm, rich what is your oppinion about that? iam unsure if iam against it or not ...
- ods15
Objections? Commit? 48 hour notice from now.
i object until i heard a comment from at least rich, comments from everyone else are of course welcome too
This is a new proposal: Basically identical to the previous one, only info packets SHOULD NOT appear "in the wild" in non-realtime-streams instead of MUST NOT. Making the distinction between file and realtime streams less strict. Demuxers still SHOULD NOT search for info packets anywhere except after the main headers. I think this is most clean...
Comments?
Repost. ... 48 hour notice ...
Committed... Should some note be added about this being added after spec freeze?.. Change is too semantic to have effect on demuxers.. - ods15
On Tue, Nov 14, 2006 at 07:04:43PM +0200, Oded Shimon wrote:
On Sun, Nov 12, 2006 at 05:27:06PM +0200, Oded Shimon wrote:
On Fri, Nov 10, 2006 at 08:57:23AM +0200, Oded Shimon wrote:
On Mon, Nov 06, 2006 at 01:44:19PM +0100, Michael Niedermayer wrote:
On Mon, Nov 06, 2006 at 10:56:57AM +0200, Oded Shimon wrote:
On Sun, Nov 05, 2006 at 09:32:44PM +0200, Oded Shimon wrote:
On Sun, Nov 05, 2006 at 07:07:22PM +0100, Michael Niedermayer wrote: > On Sun, Nov 05, 2006 at 09:48:46AM +0200, Oded Shimon wrote: > > On Sun, Nov 05, 2006 at 12:19:53AM +0100, Michael Niedermayer wrote: > > > the big problem with simply allowing arbitrarily placed info is that it > > > makes the info useless for the normal nut file case as the info cannot be > > > found its like a dvd with chapters but the information about where the > > > chapters begin is stored at the begin of the chapters, you end up with > > > a O(n) search ... > > > so ive some concerns with just saying its ok for streaming, as that > > > leads to nut files laying around which are encoded for streaming ... > > > > The proposal I had for this is - info packets not written after main > > headers are only allowed in real time streaming, and must have > > chapter_id!=0, and any info packets written after main headers, both in > > file and in streaming scenario, MUST be repeated together with all main > > headers. No demuxer would have to search anything past main headers, any > > info packets given during demuxing is "information update". In the file > > scenario, all info must be written after the main headers, so no searching > > necessary. > > hmm, rich what is your oppinion about that? iam unsure if iam against it > or not ...
- ods15
Objections? Commit? 48 hour notice from now.
i object until i heard a comment from at least rich, comments from everyone else are of course welcome too
This is a new proposal: Basically identical to the previous one, only info packets SHOULD NOT appear "in the wild" in non-realtime-streams instead of MUST NOT. Making the distinction between file and realtime streams less strict. Demuxers still SHOULD NOT search for info packets anywhere except after the main headers. I think this is most clean...
Comments?
Repost. ... 48 hour notice ...
Committed
OK, I'm sorry I committed this so hastily. You said you object until you have heard from Rich. I talked to Rich on IRC and he seemed apathetic on the issue and unwilling to reply on it. I changed my proposal to be somewhat saner with a less strict distinction between realtime and non-realtime streams, and you have not made any objection reply since. Can we discuss this now? - ods15
Hi On Wed, Nov 15, 2006 at 02:17:03AM +0200, Oded Shimon wrote:
On Tue, Nov 14, 2006 at 07:04:43PM +0200, Oded Shimon wrote:
On Sun, Nov 12, 2006 at 05:27:06PM +0200, Oded Shimon wrote:
On Fri, Nov 10, 2006 at 08:57:23AM +0200, Oded Shimon wrote:
On Mon, Nov 06, 2006 at 01:44:19PM +0100, Michael Niedermayer wrote:
On Mon, Nov 06, 2006 at 10:56:57AM +0200, Oded Shimon wrote:
On Sun, Nov 05, 2006 at 09:32:44PM +0200, Oded Shimon wrote: > On Sun, Nov 05, 2006 at 07:07:22PM +0100, Michael Niedermayer wrote: > > On Sun, Nov 05, 2006 at 09:48:46AM +0200, Oded Shimon wrote: > > > On Sun, Nov 05, 2006 at 12:19:53AM +0100, Michael Niedermayer wrote: > > > > the big problem with simply allowing arbitrarily placed info is that it > > > > makes the info useless for the normal nut file case as the info cannot be > > > > found its like a dvd with chapters but the information about where the > > > > chapters begin is stored at the begin of the chapters, you end up with > > > > a O(n) search ... > > > > so ive some concerns with just saying its ok for streaming, as that > > > > leads to nut files laying around which are encoded for streaming ... > > > > > > The proposal I had for this is - info packets not written after main > > > headers are only allowed in real time streaming, and must have > > > chapter_id!=0, and any info packets written after main headers, both in > > > file and in streaming scenario, MUST be repeated together with all main > > > headers. No demuxer would have to search anything past main headers, any > > > info packets given during demuxing is "information update". In the file > > > scenario, all info must be written after the main headers, so no searching > > > necessary. > > > > hmm, rich what is your oppinion about that? iam unsure if iam against it > > or not ... > > - ods15
Objections? Commit? 48 hour notice from now.
i object until i heard a comment from at least rich, comments from everyone else are of course welcome too
This is a new proposal: Basically identical to the previous one, only info packets SHOULD NOT appear "in the wild" in non-realtime-streams instead of MUST NOT. Making the distinction between file and realtime streams less strict. Demuxers still SHOULD NOT search for info packets anywhere except after the main headers. I think this is most clean...
Comments?
Repost. ... 48 hour notice ...
Committed
OK, I'm sorry I committed this so hastily. You said you object until you have heard from Rich. I talked to Rich on IRC and he seemed apathetic on the issue and unwilling to reply on it. I changed my proposal to be somewhat saner with a less strict distinction between realtime and non-realtime streams, and you have not made any objection reply since.
Can we discuss this now?
yes we can, what about keeping the current info after header + info must be identical rule with an exception like if a nut "file" is transmitted over the network and no out of band method to update metadata is available then info packets may be placed between ?syncpoints? the contents of these info packets may change and they do override the info packets after the mainheader. for the normal info packets after the mainheaders the normal rules apply (=no changes) dumping such a network stream to disk does not constitute a valid nut file, to convert such a stream to a valid nut file it is needed to read the whole to find the most up to date info and then place this after every main/stream header group to simplify this conversation every of the "new" info packets must contain a pointer to the previous "new" info packet? and some approproate stuffing/empty info packet should be added after all main/stream headers? [...] -- 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
On Wed, Nov 15, 2006 at 03:07:49AM +0100, Michael Niedermayer wrote:
On Wed, Nov 15, 2006 at 02:17:03AM +0200, Oded Shimon wrote:
On Tue, Nov 14, 2006 at 07:04:43PM +0200, Oded Shimon wrote:
On Sun, Nov 12, 2006 at 05:27:06PM +0200, Oded Shimon wrote:
On Fri, Nov 10, 2006 at 08:57:23AM +0200, Oded Shimon wrote:
This is a new proposal: Basically identical to the previous one, only info packets SHOULD NOT appear "in the wild" in non-realtime-streams instead of MUST NOT. Making the distinction between file and realtime streams less strict. Demuxers still SHOULD NOT search for info packets anywhere except after the main headers. I think this is most clean...
Comments?
Repost. ... 48 hour notice ...
Committed
OK, I'm sorry I committed this so hastily. You said you object until you have heard from Rich. I talked to Rich on IRC and he seemed apathetic on the issue and unwilling to reply on it. I changed my proposal to be somewhat saner with a less strict distinction between realtime and non-realtime streams, and you have not made any objection reply since.
Can we discuss this now?
yes we can, what about keeping the current info after header + info must be identical rule with an exception like if a nut "file" is transmitted over the network and no out of band method to update metadata is available then info packets may be placed between ?syncpoints? the contents of these info packets may change and they do override the info packets after the mainheader. for the normal info packets after the mainheaders the normal rules apply (=no changes) dumping such a network stream to disk does not constitute a valid nut file, to convert such a stream to a valid nut file it is needed to read the whole to find the most up to date info and then place this after every main/stream header group
to simplify this conversation every of the "new" info packets must contain a pointer to the previous "new" info packet?
Do you suggest adding some sort of flag to info packets saying if they are "new" ones or "header" ones?
and some approproate stuffing/empty info packet should be added after all main/stream headers?
Well, for one, this stuffing packet would violate the "identical info packets after main header" rule. Also, the main headers are in the begginning, and a smart network stream would have no reason to repeat them, so they will not point backwards to anything... I don't think the pointer stuff helps at all - either the stream dumper is NUT aware, in which case it can rip out all the info packets found during dumping (and optionally add them to main headers somehow), or it is not NUT aware and it doesn't care anyway. You seem to be scared of people putting info packets in the middle of files or in dumped realtime streams - I don't see this as an issue. Demuxers SHOULD NOT search for info packets anywhere except after the main header. If you were silly enough to stick an info packet somewhere in the middle, a demuxer will not see it until playbacking that point (you SHOULD NOT do this). And in the case of dumped realtime streams, you can fix them fairly easily by remuxing... - ods15
Hi On Wed, Nov 15, 2006 at 07:44:15AM +0200, Oded Shimon wrote:
On Wed, Nov 15, 2006 at 03:07:49AM +0100, Michael Niedermayer wrote:
On Wed, Nov 15, 2006 at 02:17:03AM +0200, Oded Shimon wrote:
On Tue, Nov 14, 2006 at 07:04:43PM +0200, Oded Shimon wrote:
On Sun, Nov 12, 2006 at 05:27:06PM +0200, Oded Shimon wrote:
On Fri, Nov 10, 2006 at 08:57:23AM +0200, Oded Shimon wrote:
This is a new proposal: Basically identical to the previous one, only info packets SHOULD NOT appear "in the wild" in non-realtime-streams instead of MUST NOT. Making the distinction between file and realtime streams less strict. Demuxers still SHOULD NOT search for info packets anywhere except after the main headers. I think this is most clean...
Comments?
Repost. ... 48 hour notice ...
Committed
OK, I'm sorry I committed this so hastily. You said you object until you have heard from Rich. I talked to Rich on IRC and he seemed apathetic on the issue and unwilling to reply on it. I changed my proposal to be somewhat saner with a less strict distinction between realtime and non-realtime streams, and you have not made any objection reply since.
Can we discuss this now?
yes we can, what about keeping the current info after header + info must be identical rule with an exception like if a nut "file" is transmitted over the network and no out of band method to update metadata is available then info packets may be placed between ?syncpoints? the contents of these info packets may change and they do override the info packets after the mainheader. for the normal info packets after the mainheaders the normal rules apply (=no changes) dumping such a network stream to disk does not constitute a valid nut file, to convert such a stream to a valid nut file it is needed to read the whole to find the most up to date info and then place this after every main/stream header group
to simplify this conversation every of the "new" info packets must contain a pointer to the previous "new" info packet?
Do you suggest adding some sort of flag to info packets saying if they are "new" ones or "header" ones?
no their position already defines that clearly
and some approproate stuffing/empty info packet should be added after all main/stream headers?
Well, for one, this stuffing packet would violate the "identical info packets after main header" rule.
no it would not, my proposal would have putted the pointers only in the new changing packets
Also, the main headers are in the begginning, and a smart network stream would have no reason to repeat them, so they will not point backwards to anything...
if they are not repeated then its not a valid nut file
I don't think the pointer stuff helps at all - either the stream dumper is NUT aware, in which case it can rip out all the info packets found during dumping (and optionally add them to main headers somehow), or it is not NUT aware and it doesn't care anyway.
You seem to be scared of people putting info packets in the middle of files or in dumped realtime streams - I don't see this as an issue. Demuxers SHOULD NOT search for info packets anywhere except after the main header. If you were silly enough to stick an info packet somewhere in the middle, a demuxer will not see it until playbacking that point (you SHOULD NOT do this). And in the case of dumped realtime streams, you can fix them fairly easily by remuxing...
you can fix nut files on writeable media, but if its allowed to have such packets in nut files (compared to just streams sent over the network) then theres a good chance that dvds with nut files (assuming they would ever be used on dvds) would missuse that ... really IMO streaming and filestoreage are different and applying the same rules to both will cause disadvantages in both, slightly seperate rules make more sense repeating headers in a stream is unneeded if you can gurantee error free transmission (either by retransmits like TCP or just a silly dissconnect- reconnect) for a file which can be stored and transmitted over unpredictable channels the repeats make sense, they also make sense in non specific streaming ... changing info makes sense for streaming but in files stored on your dvd its a PITA you could now try to invent some messy system (info streams ...) to make changed info findable in files on your dvd but thats a ugly hack to force one solution to cover 2 cases (for the network case theres no need to find these packets ...) really i think that nut-np is what should be used, if you want to use nut over tcp, thats fine but then live with its limitations and dont just hack it because you cant live with 1 or 2 pages of code to handle a minimal additional header from nut-np over TCP also you dont need syncpoints over TCP, its a waste of bandwidth ... [...] -- 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
Hi On Wed, Nov 15, 2006 at 11:29:12PM +0100, Michael Niedermayer wrote:
Hi
On Wed, Nov 15, 2006 at 07:44:15AM +0200, Oded Shimon wrote:
On Wed, Nov 15, 2006 at 03:07:49AM +0100, Michael Niedermayer wrote:
On Wed, Nov 15, 2006 at 02:17:03AM +0200, Oded Shimon wrote:
On Tue, Nov 14, 2006 at 07:04:43PM +0200, Oded Shimon wrote:
On Sun, Nov 12, 2006 at 05:27:06PM +0200, Oded Shimon wrote:
On Fri, Nov 10, 2006 at 08:57:23AM +0200, Oded Shimon wrote: > This is a new proposal: Basically identical to the previous one, only info > packets SHOULD NOT appear "in the wild" in non-realtime-streams instead of > MUST NOT. Making the distinction between file and realtime streams less > strict. Demuxers still SHOULD NOT search for info packets anywhere except > after the main headers. I think this is most clean... > > Comments?
Repost. ... 48 hour notice ...
Committed
OK, I'm sorry I committed this so hastily. You said you object until you have heard from Rich. I talked to Rich on IRC and he seemed apathetic on the issue and unwilling to reply on it. I changed my proposal to be somewhat saner with a less strict distinction between realtime and non-realtime streams, and you have not made any objection reply since.
Can we discuss this now?
yes we can, what about keeping the current info after header + info must be identical rule with an exception like if a nut "file" is transmitted over the network and no out of band method to update metadata is available then info packets may be placed between ?syncpoints? the contents of these info packets may change and they do override the info packets after the mainheader. for the normal info packets after the mainheaders the normal rules apply (=no changes) dumping such a network stream to disk does not constitute a valid nut file, to convert such a stream to a valid nut file it is needed to read the whole to find the most up to date info and then place this after every main/stream header group
to simplify this conversation every of the "new" info packets must contain a pointer to the previous "new" info packet?
Do you suggest adding some sort of flag to info packets saying if they are "new" ones or "header" ones?
no their position already defines that clearly
and some approproate stuffing/empty info packet should be added after all main/stream headers?
Well, for one, this stuffing packet would violate the "identical info packets after main header" rule.
no it would not, my proposal would have putted the pointers only in the new changing packets
Also, the main headers are in the begginning, and a smart network stream would have no reason to repeat them, so they will not point backwards to anything...
if they are not repeated then its not a valid nut file
I don't think the pointer stuff helps at all - either the stream dumper is NUT aware, in which case it can rip out all the info packets found during dumping (and optionally add them to main headers somehow), or it is not NUT aware and it doesn't care anyway.
You seem to be scared of people putting info packets in the middle of files or in dumped realtime streams - I don't see this as an issue. Demuxers SHOULD NOT search for info packets anywhere except after the main header. If you were silly enough to stick an info packet somewhere in the middle, a demuxer will not see it until playbacking that point (you SHOULD NOT do this). And in the case of dumped realtime streams, you can fix them fairly easily by remuxing...
you can fix nut files on writeable media, but if its allowed to have such packets in nut files (compared to just streams sent over the network) then theres a good chance that dvds with nut files (assuming they would ever be used on dvds) would missuse that ...
really IMO streaming and filestoreage are different and applying the same rules to both will cause disadvantages in both, slightly seperate rules make more sense
repeating headers in a stream is unneeded if you can gurantee error free transmission (either by retransmits like TCP or just a silly dissconnect- reconnect) for a file which can be stored and transmitted over unpredictable channels the repeats make sense, they also make sense in non specific streaming ... changing info makes sense for streaming but in files stored on your dvd its a PITA you could now try to invent some messy system (info streams ...) to make changed info findable in files on your dvd but thats a ugly hack to force one solution to cover 2 cases (for the network case theres no need to find these packets ...)
really i think that nut-np is what should be used, if you want to use nut over tcp, thats fine but then live with its limitations and dont just hack it because you cant live with 1 or 2 pages of code to handle a minimal additional header from nut-np over TCP
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) [...] -- 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
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
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
On Fri, Nov 17, 2006 at 01:02:22PM +0100, Michael Niedermayer wrote:
On Fri, Nov 17, 2006 at 09:31:40AM +0200, Oded Shimon wrote:
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?
I don't consider it a butchering of the spec to omit repeated headers in the case of realtime streaming as it is an impossible rule to inforce and illogical in the case of realtime streaming. The only way to truely enforce this rule in realtime streams is by making all 3 header copies right at the begginning, with no frame inbetween - otherwise the user can stop the dumping immediately after it begun and it would be impossible to get all 3 copies even if the streamer repeated headers. Even if they were repeated - they would not be useful for finding in dumped files as they would not be in 2^n locations (unless you expect the streaming server to start doing calculations for EACH client..) It's a butchering of the spec only because you can semantically consider the file truncated and incomplete - in your suggest of max_distance butchering, you're explicitly butchering the spec to the point that compliant demuxers will not be able to play it without different modes for streaming and files.
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
Well, I somewhat doubt that will actually happen, but I accept the argument...
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
I have no idea for a solution. Your proposed solution doesn't work as there is no way to find the last info packet. even with your stuffing info packet in headers idea: 1. how would you find the headers? 2. who said the headers are necessarily after the last info packet in the file? Our main assumption is that in realtime stream dumping, they can be cut/truncated at absoloutely any arbitrary point in the file. BTW, if we ultimately decide on disallowing mid-stream info packets, we need to remove these 2 parts from the spec: --- If a demuxer has seen several info packets with the same chapter_id and stream_id then it MUST ignore all but the one with the highest position in the file demxuxers SHOULD NOT search the whole file for info packets --- As they make no sense without them (all headers must be repeated identically after all main headers) BTW2, If we decide we do allow mis-stream info packets, then this rule somewhat fails: --- chapter_id n MUST not be used unless there are at least n chapters in the file --- As a streamer would start at chapter_id=1, and linearly grow - you can join at any arbitrary point, even when chapter_id=5926. - ods15
On Sun, Nov 19, 2006 at 06:58:59PM +0200, Oded Shimon wrote:
On Fri, Nov 17, 2006 at 01:02:22PM +0100, Michael Niedermayer wrote:
On Fri, Nov 17, 2006 at 09:31:40AM +0200, Oded Shimon wrote:
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?
I don't consider it a butchering of the spec to omit repeated headers in the case of realtime streaming as it is an impossible rule to inforce and illogical in the case of realtime streaming. The only way to truely enforce this rule in realtime streams is by making all 3 header copies right at the begginning, with no frame inbetween - otherwise the user can stop the dumping immediately after it begun and it would be impossible to get all 3 copies even if the streamer repeated headers. Even if they were repeated - they would not be useful for finding in dumped files as they would not be in 2^n locations (unless you expect the streaming server to start doing calculations for EACH client..)
It's a butchering of the spec only because you can semantically consider the file truncated and incomplete - in your suggest of max_distance butchering, you're explicitly butchering the spec to the point that compliant demuxers will not be able to play it without different modes for streaming and files.
You realize, right, that the issue here is that a truncated nut file is not a valid nut file, according to the spec? If we acknowledge the existence of truncated files but note that they do not constitute "complete" files (by virtue of missing header copies and missing index) the problem goes away, I think.
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
Well, I somewhat doubt that will actually happen, but I accept the argument...
It's quite easy to say that incomplete streams are valid but incomplete, and further to require that IF the stream contains and index, it MUST be complete (i.e. include header copies).
BTW, if we ultimately decide on disallowing mid-stream info packets, we need to remove these 2 parts from the spec: --- If a demuxer has seen several info packets with the same chapter_id and stream_id then it MUST ignore all but the one with the highest position in the file
demxuxers SHOULD NOT search the whole file for info packets ---
I'm find with keeping this possibility as long as the last condition (don't search) is made abundantly clear. But really I don't care. It's a stupid bikeshed issue.
BTW2, If we decide we do allow mis-stream info packets, then this rule somewhat fails: --- chapter_id n MUST not be used unless there are at least n chapters in the file ---
As a streamer would start at chapter_id=1, and linearly grow - you can join at any arbitrary point, even when chapter_id=5926.
IMO this should remain illegal. You can use negative chapter_id or something.. In any case the info system is probably not ideal for the sort of streaming uses you're describing. There are much better out of band ways to accomplish this info delivery.. Rich
Hi On Sun, Nov 19, 2006 at 06:58:59PM +0200, Oded Shimon wrote:
On Fri, Nov 17, 2006 at 01:02:22PM +0100, Michael Niedermayer wrote:
On Fri, Nov 17, 2006 at 09:31:40AM +0200, Oded Shimon wrote:
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?
I don't consider it a butchering of the spec to omit repeated headers in the case of realtime streaming as it is an impossible rule to inforce and illogical in the case of realtime streaming. The only way to truely enforce this rule in realtime streams is by making all 3 header copies right at the begginning, with no frame inbetween - otherwise the user can stop the dumping immediately after it begun and it would be impossible to get all 3 copies even if the streamer repeated headers. Even if they were repeated - they would not be useful for finding in dumped files as they would not be in 2^n locations (unless you expect the streaming server to start doing calculations for EACH client..)
well, if you want to be able to start playing in the middle (your comment strongly suggests that) you either need to repeat headers often or transmit them out of band, or allow clients to seeks to past data somehow ... also i think we once said that timestamps must start at 0, you seem to break that too, iam not sure if theres anything in the spec which forbids it or if theres anything which would break, iam just mentioning it ... and anyway the not duplicated headers are a minor issue about which i dont really care as long as its clear that this is not ok in normal nut files it of course can happen in truncated or otherwise damaged files and a demuxer still should handle that sanely ... [...]
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
Well, I somewhat doubt that will actually happen, but I accept the argument...
you want to omit them in your streams IIRC because of the space saving so why shouldnt others too?
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
I have no idea for a solution. Your proposed solution doesn't work as there is no way to find the last info packet. even with your stuffing info packet in headers idea: 1. how would you find the headers? 2. who said the headers are necessarily after the last info packet in the file? Our main assumption is that in realtime stream dumping, they can be cut/truncated at absoloutely any arbitrary point in the file.
1. every midstream info packet (and only them) MUST have a pointer to the previous non redundant/repeated midstream info packet 2. the distance between midstream info packets MUST be <= C*max_distance unless that is impossible (too large stream header / frame) in which case the distance MUST be as small as possible for the specific case 3. a info packet MUST either be part of the normal info packets or it MUST be repeated like described in 2. within the area to which it applies and it MUST be in that area at least once
BTW, if we ultimately decide on disallowing mid-stream info packets, we need to remove these 2 parts from the spec: --- If a demuxer has seen several info packets with the same chapter_id and stream_id then it MUST ignore all but the one with the highest position in the file
demxuxers SHOULD NOT search the whole file for info packets ---
As they make no sense without them (all headers must be repeated identically after all main headers)
leaving them does no harm droping them changes the frozen spec again ... it also makes adding mid stream info packets at a later time much harder if the rules are droped now
BTW2, If we decide we do allow mis-stream info packets, then this rule somewhat fails: --- chapter_id n MUST not be used unless there are at least n chapters in the file ---
As a streamer would start at chapter_id=1, and linearly grow - you can join at any arbitrary point, even when chapter_id=5926.
is a arbitrary cut part (both begin and end cut) always a valid nut file? if yes then every file is a valid nut file as it could be the data of a single frame i would rather say that the whole stream from its true begin forms a valid nut file and when you start cutting it becomes a damaged stream which must be dealt with correctly by demuxers if all headers and one syncpoint is available [...] -- 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
On Mon, Nov 20, 2006 at 03:29:29PM +0100, Michael Niedermayer wrote:
well, if you want to be able to start playing in the middle (your comment strongly suggests that) you either need to repeat headers often or transmit them out of band, or allow clients to seeks to past data somehow ...
His idea is that the server would semi-dynamically generate a stream by first writing the headers when a client connects, then copying everything else from disk. This is what I had in mind too.
also i think we once said that timestamps must start at 0, you seem to break
Absolutely not! If this were required then you could not split long movies into multiple files to split across media without losing information (and mildly breaking a/v sync since it's impossible for all streams to start exactly at 0 after splitting a file unless you choose a cut point divisible by all frame durations...).
that too, iam not sure if theres anything in the spec which forbids it or if theres anything which would break, iam just mentioning it ...
Starting at arbitrary timestamp is totally legal and it was always my intent for it to be legal. Obviously streaming is not possible either if you don't allow for this..
and anyway the not duplicated headers are a minor issue about which i dont really care as long as its clear that this is not ok in normal nut files it of course can happen in truncated or otherwise damaged files and a demuxer still should handle that sanely ...
Agree.
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
Well, I somewhat doubt that will actually happen, but I accept the argument...
you want to omit them in your streams IIRC because of the space saving so why shouldnt others too?
Well in Oded's case it happens that they're utterly useless, but as long as we follow what you and I said above I don't think there's a problem.
I have no idea for a solution. Your proposed solution doesn't work as there is no way to find the last info packet. even with your stuffing info packet in headers idea: 1. how would you find the headers? 2. who said the headers are necessarily after the last info packet in the file? Our main assumption is that in realtime stream dumping, they can be cut/truncated at absoloutely any arbitrary point in the file.
1. every midstream info packet (and only them) MUST have a pointer to the previous non redundant/repeated midstream info packet 2. the distance between midstream info packets MUST be <= C*max_distance unless that is impossible (too large stream header / frame) in which case the distance MUST be as small as possible for the specific case 3. a info packet MUST either be part of the normal info packets or it MUST be repeated like described in 2. within the area to which it applies and it MUST be in that area at least once
Seems like the sanest proposal for this so far, but.... introduces huge ugly complexity to implementation.
BTW, if we ultimately decide on disallowing mid-stream info packets, we need to remove these 2 parts from the spec: --- If a demuxer has seen several info packets with the same chapter_id and stream_id then it MUST ignore all but the one with the highest position in the file
demxuxers SHOULD NOT search the whole file for info packets ---
As they make no sense without them (all headers must be repeated identically after all main headers)
leaving them does no harm droping them changes the frozen spec again ... it also makes adding mid stream info packets at a later time much harder if the rules are droped now
Yes, let's not harm syntactic extensibility. I doubt the sanity of this mid-stream info at all, but...
BTW2, If we decide we do allow mis-stream info packets, then this rule somewhat fails: --- chapter_id n MUST not be used unless there are at least n chapters in the file ---
As a streamer would start at chapter_id=1, and linearly grow - you can join at any arbitrary point, even when chapter_id=5926.
is a arbitrary cut part (both begin and end cut) always a valid nut file? if yes then every file is a valid nut file as it could be the data of a single frame
i would rather say that the whole stream from its true begin forms a valid nut file and when you start cutting it becomes a damaged stream which must be dealt with correctly by demuxers if all headers and one syncpoint is available
An arbitrary dd-cut nut file is not a valid complete not file, and not valid at all if the beginning has been cut. On the other hand, a file cut with a proper cutting tool SHOULD be valid, e.g. if you're cutting a movie to split it across undersized media (cdr). Requiring the chapters to be renumbered after cutting is particularly ugly and destructive of semantic information. I'd like to request a minor revision: instead of requiring positive chater id's to start from 1, just require them to be contiguous. This keeps implementation simple (array storage can be used), but the first element need not reflect "chapter 1" in a user sense. Alternatively you can just keep all chapters stored in both/all files after split, pointing to timestamp ranges outside of the current file. I have no idea if this is valid or not... :) Rich
On Mon, Nov 20, 2006 at 12:37:22PM -0500, Rich Felker wrote:
On Mon, Nov 20, 2006 at 03:29:29PM +0100, Michael Niedermayer wrote:
well, if you want to be able to start playing in the middle (your comment strongly suggests that) you either need to repeat headers often or transmit them out of band, or allow clients to seeks to past data somehow ...
His idea is that the server would semi-dynamically generate a stream by first writing the headers when a client connects, then copying everything else from disk. This is what I had in mind too.
Not necessarily from disk. All it has to buffer is the main headers once, then it just has to wait for it's lead muxer to give a syncpoint, and then give everything to the client like any other client...
that too, iam not sure if theres anything in the spec which forbids it or if theres anything which would break, iam just mentioning it ...
Starting at arbitrary timestamp is totally legal and it was always my intent for it to be legal. Obviously streaming is not possible either if you don't allow for this..
I've never actually tested it, but AFAIK libnut is completely safe and non-breaking on this issue.
you want to omit them in your streams IIRC because of the space saving so why shouldnt others too?
Well in Oded's case it happens that they're utterly useless, but as long as we follow what you and I said above I don't think there's a problem.
I assume you mean what you said regarding "complete file" semantics and index. In which case, yes, I agree too.
I have no idea for a solution. Your proposed solution doesn't work as there is no way to find the last info packet. even with your stuffing info packet in headers idea: 1. how would you find the headers? 2. who said the headers are necessarily after the last info packet in the file? Our main assumption is that in realtime stream dumping, they can be cut/truncated at absoloutely any arbitrary point in the file.
1. every midstream info packet (and only them) MUST have a pointer to the previous non redundant/repeated midstream info packet 2. the distance between midstream info packets MUST be <= C*max_distance unless that is impossible (too large stream header / frame) in which case the distance MUST be as small as possible for the specific case 3. a info packet MUST either be part of the normal info packets or it MUST be repeated like described in 2. within the area to which it applies and it MUST be in that area at least once
Seems like the sanest proposal for this so far, but.... introduces huge ugly complexity to implementation.
It's actually not that bad in implementation - just keep last_info and last_info_redundant (to know if to place another one now), a few more if's together with syncpoint writing, and you're done. Or do you mean complexity in demuxer? In which case, yes, it is somewhat ugly... But I don't really agree in demuxer searching for info packets anywhere after main headers anyway. I have two questions though: How do you know if to search for these redundant packets or not? I assume you do NOT write them at all if there are no mid-stream info packets at all, in which case, when looking for them, how do you know if you simply haven't scanned enough of C*max_distance from EOF, or if there aren't mid-stream info packets at all? Also, for the begginning of file, do you write these info_redundant until you have one info packet or not? Sounds like this would need another flag in the main header.
leaving them does no harm droping them changes the frozen spec again ... it also makes adding mid stream info packets at a later time much harder if the rules are droped now
Yes, let's not harm syntactic extensibility. I doubt the sanity of this mid-stream info at all, but...
It does feel like a bikeshed issue, but it is very important to some people (not me BTW). [...]
I'd like to request a minor revision: instead of requiring positive chater id's to start from 1, just require them to be contiguous. This keeps implementation simple (array storage can be used), but the first element need not reflect "chapter 1" in a user sense.
I preffer this. - ods15
Hi On Mon, Nov 20, 2006 at 07:41:48PM +0200, Oded Shimon wrote:
On Mon, Nov 20, 2006 at 12:37:22PM -0500, Rich Felker wrote: [...]
that too, iam not sure if theres anything in the spec which forbids it or if theres anything which would break, iam just mentioning it ...
Starting at arbitrary timestamp is totally legal and it was always my intent for it to be legal. Obviously streaming is not possible either if you don't allow for this..
IIRC someone originally wanted timestamps to start from 0, we then realized thats not possible and then we agreed that it should be close to 0 or something (and no iam not at all trying to say that i am against arbitrary start timestamps ...)
I've never actually tested it, but AFAIK libnut is completely safe and non-breaking on this issue.
theres at least one issue with random start timestamps try 1e9999 as start timestamp and tell me if that worked :) while the fileformat of course has no problem with arbitrary integers, implementations will ... making it clear that 0 should be used as start where possible reduces the issue but doesnt solve it something like: timestamps SHOULD start at or close to 0, and MUST fit into 63bit, note this limit may be raised in the (distant) future should solve the issue ... this should be enough for a few hundread years at nanosecond resolution [...]
I have no idea for a solution. Your proposed solution doesn't work as there is no way to find the last info packet. even with your stuffing info packet in headers idea: 1. how would you find the headers? 2. who said the headers are necessarily after the last info packet in the file? Our main assumption is that in realtime stream dumping, they can be cut/truncated at absoloutely any arbitrary point in the file.
1. every midstream info packet (and only them) MUST have a pointer to the previous non redundant/repeated midstream info packet 2. the distance between midstream info packets MUST be <= C*max_distance unless that is impossible (too large stream header / frame) in which case the distance MUST be as small as possible for the specific case 3. a info packet MUST either be part of the normal info packets or it MUST be repeated like described in 2. within the area to which it applies and it MUST be in that area at least once
Seems like the sanest proposal for this so far, but.... introduces huge ugly complexity to implementation.
It's actually not that bad in implementation - just keep last_info and last_info_redundant (to know if to place another one now), a few more if's together with syncpoint writing, and you're done.
Or do you mean complexity in demuxer? In which case, yes, it is somewhat ugly... But I don't really agree in demuxer searching for info packets anywhere after main headers anyway.
thats perfectly fine, i never proposed that demuxers should search for them its just that if a demuxer wants to or needs to then it should be technically possible to find them also remuxing such streamdumps into midstream info less nut files benefits from the ability to qickly enumerate all midstream info packets ...
I have two questions though: How do you know if to search for these redundant packets or not? I assume you do NOT write them at all if there are no mid-stream info packets at all, in which case, when looking for them, how do you know if you simply haven't scanned enough of C*max_distance from EOF, or if there aren't mid-stream info packets at all? Also, for the begginning of file, do you write these info_redundant until you have one info packet or not?
dunno, probably yes
Sounds like this would need another flag in the main header.
yes
[...]
[...]
I'd like to request a minor revision: instead of requiring positive chater id's to start from 1, just require them to be contiguous. This keeps implementation simple (array storage can be used), but the first element need not reflect "chapter 1" in a user sense.
I preffer this.
same issue as with timestamps, may i limit that to 31 bit or more precissely int32_t? and is it really that simple? i mean with the start from 0 its a count=MAX(count, id); realloc(count); store with the contiguous ones lets say you receive 100,101,102,103,104,105,99,100,101,... here the first info packet with 99 was damaged ... then what about mixing that with normal info packets? i mean info packets with chapter id 1,2,3 and then midstream info packets 4,5,6,7, ... and if you now cut the file, you loose contiguousity ... i think these things need to be resolved before we can think about allowing chapter ids to start at >0 [...] -- 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
On Mon, Nov 20, 2006 at 11:32:37PM +0100, Michael Niedermayer wrote:
Hi
On Mon, Nov 20, 2006 at 07:41:48PM +0200, Oded Shimon wrote:
On Mon, Nov 20, 2006 at 12:37:22PM -0500, Rich Felker wrote: [...]
that too, iam not sure if theres anything in the spec which forbids it or if theres anything which would break, iam just mentioning it ...
Starting at arbitrary timestamp is totally legal and it was always my intent for it to be legal. Obviously streaming is not possible either if you don't allow for this..
IIRC someone originally wanted timestamps to start from 0, we then realized thats not possible and then we agreed that it should be close to 0 or something (and no iam not at all trying to say that i am against arbitrary start timestamps ...)
I never agreed to such a thing because it was always my intent that you could split and recombine files across media without loss of information. Also there's no reasonable way to specify "close to 0".
I've never actually tested it, but AFAIK libnut is completely safe and non-breaking on this issue.
theres at least one issue with random start timestamps try 1e9999 as start timestamp and tell me if that worked :) while the fileformat of course has no problem with arbitrary integers, implementations will ... making it clear that 0 should be used as start where possible reduces the issue but doesnt solve it
I think it's clear that if you use idiotic time values you'll have problems with implementation support. IMO it's fine to say just that implementations SHOULD NOT go out of their way to support excessively large values for any field in a NUT file.
It's actually not that bad in implementation - just keep last_info and last_info_redundant (to know if to place another one now), a few more if's together with syncpoint writing, and you're done.
Or do you mean complexity in demuxer? In which case, yes, it is somewhat ugly... But I don't really agree in demuxer searching for info packets anywhere after main headers anyway.
Demuxer of course..
thats perfectly fine, i never proposed that demuxers should search for them its just that if a demuxer wants to or needs to then it should be technically possible to find them
It is always possible via linear search. If the demuxer SHOULD NOT search for them then we should not go out of our way to make it easy to search... Just my 2¢...
I'd like to request a minor revision: instead of requiring positive chater id's to start from 1, just require them to be contiguous. This keeps implementation simple (array storage can be used), but the first element need not reflect "chapter 1" in a user sense.
I preffer this.
same issue as with timestamps, may i limit that to 31 bit or more precissely int32_t?
I don't even care if you limit it to int16_t...
and is it really that simple? i mean with the start from 0 its a count=MAX(count, id); realloc(count); store with the contiguous ones lets say you receive 100,101,102,103,104,105,99,100,101,...
here the first info packet with 99 was damaged ...
Yes, I see. You can remap them, I suppose it's a little painful tho..
then what about mixing that with normal info packets? i mean info packets with chapter id 1,2,3 and then midstream info packets 4,5,6,7, ... and if you now cut the file, you loose contiguousity ...
i think these things need to be resolved before we can think about allowing chapter ids to start at >0
Bleh.. Rich
Hi On Mon, Nov 20, 2006 at 08:57:36PM -0500, Rich Felker wrote: [...]
I've never actually tested it, but AFAIK libnut is completely safe and non-breaking on this issue.
theres at least one issue with random start timestamps try 1e9999 as start timestamp and tell me if that worked :) while the fileformat of course has no problem with arbitrary integers, implementations will ... making it clear that 0 should be used as start where possible reduces the issue but doesnt solve it
I think it's clear that if you use idiotic time values you'll have problems with implementation support. IMO it's fine to say just that implementations SHOULD NOT go out of their way to support excessively large values for any field in a NUT file.
what is excessively large? whats idiotic? thats not a good way to specify the valid range of a value
32bit is idiotic for many people iam pretty sure, still its not enough if your input data is in nanosecond precission ...
and its neither reasonable to assume that everyone has to spend an hour per field to guess what range of values would have to be supported to handle all non idiotic cases
It's actually not that bad in implementation - just keep last_info and last_info_redundant (to know if to place another one now), a few more if's together with syncpoint writing, and you're done.
Or do you mean complexity in demuxer? In which case, yes, it is somewhat ugly... But I don't really agree in demuxer searching for info packets anywhere after main headers anyway.
Demuxer of course..
thats perfectly fine, i never proposed that demuxers should search for them its just that if a demuxer wants to or needs to then it should be technically possible to find them
It is always possible via linear search. If the demuxer SHOULD NOT search for them then we should not go out of our way to make it easy to search... Just my 2¢...
well there really are 2 cases IMHO A. midstream info packets are not allowed in normal nut files B. midstream info packets are allowed in normal nut files for A i agree that the pointers and repeating shouldnt be required, there may be other reasons though why repeating the info makes sense ... for B i dont agree, simply because if info is there, then there are cases where the user will want to have that info, think of some capture of odeds radio stream, its not unlikely to think that the user would want to seek to a specific song (she knows the song title but not the time to seek to) [...] -- 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
On Tue, Nov 21, 2006 at 06:32:03PM +0100, Michael Niedermayer wrote:
Hi
On Mon, Nov 20, 2006 at 08:57:36PM -0500, Rich Felker wrote: [...]
I've never actually tested it, but AFAIK libnut is completely safe and non-breaking on this issue.
theres at least one issue with random start timestamps try 1e9999 as start timestamp and tell me if that worked :) while the fileformat of course has no problem with arbitrary integers, implementations will ... making it clear that 0 should be used as start where possible reduces the issue but doesnt solve it
I think it's clear that if you use idiotic time values you'll have problems with implementation support. IMO it's fine to say just that implementations SHOULD NOT go out of their way to support excessively large values for any field in a NUT file.
what is excessively large? whats idiotic? thats not a good way to specify the valid range of a value
32bit is idiotic for many people iam pretty sure, still its not enough if your input data is in nanosecond precission ...
and its neither reasonable to assume that everyone has to spend an hour per field to guess what range of values would have to be supported to handle all non idiotic cases
My idea is that what's idiotic changes with time. That's why we use vlc rather than fixed-size fields. Unlike other potential areas of abuse in the spec, I don't see any realistic issue with people intentionally choosing initial timestamps that will cause trouble with some implementations. Generally the only things people would choose for starting timestamps would be 0, the end timestamp of another file, or the current unix time (seconds since the epoch). All of these will fit ok in 64bit as long as a sane timebase is used.
It is always possible via linear search. If the demuxer SHOULD NOT search for them then we should not go out of our way to make it easy to search... Just my 2¢...
well there really are 2 cases IMHO A. midstream info packets are not allowed in normal nut files B. midstream info packets are allowed in normal nut files
for A i agree that the pointers and repeating shouldnt be required, there may be other reasons though why repeating the info makes sense ...
for B i dont agree, simply because if info is there, then there are cases where the user will want to have that info, think of some capture of odeds radio stream, its not unlikely to think that the user would want to seek to a specific song (she knows the song title but not the time to seek to)
Arrg, this is what I was saying way back about info streams and I got flamed to death. Anyway such file has no index already, so it's not meant to be searchable by index, and searching by chapter _name_ does not work with binary search so linear search is the natural requirement anyway. If a user wants to be able to search this file they'll probably remux it to make a complete nut file (one with index and repeated headers). While there are some questions to answer I'd be generally ok with mandating that a "complete" nut file must not have info except after the headers and that it must be repeated and identical. On the other hand I think it still might be best to just always mandate this, so that a complete nut file can be generated just by appending to an incomplete one. I fear if we don't allow this people will make "append-based" completion utilities anyway because it's so much more convenient. Rich
Hi On Tue, Nov 21, 2006 at 02:32:14PM -0500, Rich Felker wrote:
On Tue, Nov 21, 2006 at 06:32:03PM +0100, Michael Niedermayer wrote:
Hi
On Mon, Nov 20, 2006 at 08:57:36PM -0500, Rich Felker wrote: [...]
I've never actually tested it, but AFAIK libnut is completely safe and non-breaking on this issue.
theres at least one issue with random start timestamps try 1e9999 as start timestamp and tell me if that worked :) while the fileformat of course has no problem with arbitrary integers, implementations will ... making it clear that 0 should be used as start where possible reduces the issue but doesnt solve it
I think it's clear that if you use idiotic time values you'll have problems with implementation support. IMO it's fine to say just that implementations SHOULD NOT go out of their way to support excessively large values for any field in a NUT file.
what is excessively large? whats idiotic? thats not a good way to specify the valid range of a value
32bit is idiotic for many people iam pretty sure, still its not enough if your input data is in nanosecond precission ...
and its neither reasonable to assume that everyone has to spend an hour per field to guess what range of values would have to be supported to handle all non idiotic cases
My idea is that what's idiotic changes with time. That's why we use vlc rather than fixed-size fields. Unlike other potential areas of abuse in the spec, I don't see any realistic issue with people intentionally choosing initial timestamps that will cause trouble with some implementations. Generally the only things people would choose for starting timestamps would be 0, the end timestamp of another file, or the current unix time (seconds since the epoch). All of these will fit ok in 64bit as long as a sane timebase is used.
for rtp the start timestamp is recommanded to be random() IIRC and for transcoding people might choose to keep the start timestamp also when taking some seconds since x and converting that to a "insane" timebase problems will happen ...
It is always possible via linear search. If the demuxer SHOULD NOT search for them then we should not go out of our way to make it easy to search... Just my 2¢...
well there really are 2 cases IMHO A. midstream info packets are not allowed in normal nut files B. midstream info packets are allowed in normal nut files
for A i agree that the pointers and repeating shouldnt be required, there may be other reasons though why repeating the info makes sense ...
for B i dont agree, simply because if info is there, then there are cases where the user will want to have that info, think of some capture of odeds radio stream, its not unlikely to think that the user would want to seek to a specific song (she knows the song title but not the time to seek to)
Arrg, this is what I was saying way back about info streams and I got flamed to death. Anyway such file has no index already, so it's not meant to be searchable by index, and searching by chapter _name_ does not work with binary search so linear search is the natural requirement anyway.
it is possible to extend info packets so that O(log n) search for names can be done ill explain how (and no iam not saying i actually propose doing that, its just a random thought) 1. add a hash table to every info packet which contains pointers to info packets for all names in the X previous info packets 2. X is the largst power of 2 which divides n which is the number of the current info packet, (n=5 -> X=1, n=6 -> X=2, n=8 -> X=8) 3. add a pointer to the Xth previous info packet the space requirement for this is O(n log n) for n info packets now to search for your favorite name, start with the last info packet search its hash table, if theres a match you have your name, if not follow the pointer from 3. and retry (X must be at least twice as large after each retry so this is guranteed to terminate after log n steps) another random thought 100 music videos with midstream info back pointers need 100 seeks to read all with 10ms per seek thats 1 second, if we assume 3min playtime per music video the whole would be 300min and at a realistic bitrate that will take much longer to search without the pointers and yet another random tought if we now repeat the last X different info packets with each info packet similarely to the hash table mess then we could read all with log n seeks (and n log n space instead of n for n info packets) while the complexity would be very low on the demuxer side, just linear search + follow the pointer [...] -- 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
On Tue, Nov 21, 2006 at 10:35:57PM +0100, Michael Niedermayer wrote:
On Tue, Nov 21, 2006 at 02:32:14PM -0500, Rich Felker wrote:
On Tue, Nov 21, 2006 at 06:32:03PM +0100, Michael Niedermayer wrote:
what is excessively large? whats idiotic? thats not a good way to specify the valid range of a value
32bit is idiotic for many people iam pretty sure, still its not enough if your input data is in nanosecond precission ...
and its neither reasonable to assume that everyone has to spend an hour per field to guess what range of values would have to be supported to handle all non idiotic cases
My idea is that what's idiotic changes with time. That's why we use vlc rather than fixed-size fields. Unlike other potential areas of abuse in the spec, I don't see any realistic issue with people intentionally choosing initial timestamps that will cause trouble with some implementations. Generally the only things people would choose for starting timestamps would be 0, the end timestamp of another file, or the current unix time (seconds since the epoch). All of these will fit ok in 64bit as long as a sane timebase is used.
for rtp the start timestamp is recommanded to be random() IIRC and for transcoding people might choose to keep the start timestamp also when taking some seconds since x and converting that to a "insane" timebase problems will happen ...
Just wanted to know one more possible scenario for this - stupid people transcoding directly with pts from mpeg (i've seen mpegs start at timestamps of 24352...) - ods15
Hi On Wed, Nov 22, 2006 at 03:13:27AM +0200, Oded Shimon wrote:
On Tue, Nov 21, 2006 at 10:35:57PM +0100, Michael Niedermayer wrote:
On Tue, Nov 21, 2006 at 02:32:14PM -0500, Rich Felker wrote:
On Tue, Nov 21, 2006 at 06:32:03PM +0100, Michael Niedermayer wrote:
what is excessively large? whats idiotic? thats not a good way to specify the valid range of a value
32bit is idiotic for many people iam pretty sure, still its not enough if your input data is in nanosecond precission ...
and its neither reasonable to assume that everyone has to spend an hour per field to guess what range of values would have to be supported to handle all non idiotic cases
My idea is that what's idiotic changes with time. That's why we use vlc rather than fixed-size fields. Unlike other potential areas of abuse in the spec, I don't see any realistic issue with people intentionally choosing initial timestamps that will cause trouble with some implementations. Generally the only things people would choose for starting timestamps would be 0, the end timestamp of another file, or the current unix time (seconds since the epoch). All of these will fit ok in 64bit as long as a sane timebase is used.
for rtp the start timestamp is recommanded to be random() IIRC and for transcoding people might choose to keep the start timestamp also when taking some seconds since x and converting that to a "insane" timebase problems will happen ...
additional note, i dont know if there really is a problem in the rtp case as i dont know rtp well enough, maybe the timestamps have few enough bits so this wouldnt be a problem but still a "choose a sane value" is not a good way to specify the valid range of something ...
Just wanted to know one more possible scenario for this - stupid people transcoding directly with pts from mpeg (i've seen mpegs start at timestamps of 24352...)
please add a note to the spec sying that people MUST NOT use timestamps from mpeg* blindly while transcoding as mpeg can have timestamp discontinuities ... [...] -- 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
Hi On Tue, Nov 21, 2006 at 10:35:57PM +0100, Michael Niedermayer wrote: [...]
It is always possible via linear search. If the demuxer SHOULD NOT search for them then we should not go out of our way to make it easy to search... Just my 2¢...
well there really are 2 cases IMHO A. midstream info packets are not allowed in normal nut files B. midstream info packets are allowed in normal nut files
for A i agree that the pointers and repeating shouldnt be required, there may be other reasons though why repeating the info makes sense ...
for B i dont agree, simply because if info is there, then there are cases where the user will want to have that info, think of some capture of odeds radio stream, its not unlikely to think that the user would want to seek to a specific song (she knows the song title but not the time to seek to)
Arrg, this is what I was saying way back about info streams and I got flamed to death. Anyway such file has no index already, so it's not meant to be searchable by index, and searching by chapter _name_ does not work with binary search so linear search is the natural requirement anyway.
it is possible to extend info packets so that O(log n) search for names can be done ill explain how (and no iam not saying i actually propose doing that, its just a random thought) 1. add a hash table to every info packet which contains pointers to info packets for all names in the X previous info packets 2. X is the largst power of 2 which divides n which is the number of the current info packet, (n=5 -> X=1, n=6 -> X=2, n=8 -> X=8) 3. add a pointer to the Xth previous info packet
another idea, if we choose Y=sqrt( number of info packets ) and then duplicate the last Y info packets in every Yth info packet and give the small info packets a pointer to the last and the large ones a pointer to the last large one, then it should look like: 1 2 3 1234 5 6 7 5678 9 A B 9ABC D E and needs O(n) space (actually exactly 2*n) and O(sqrt(n)) seeks for finding a info packet the same can be done with the xth root, O(n^(1/x)) time and x*n overhead [...] -- 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
Hi On Sat, Nov 04, 2006 at 03:53:13PM +0200, Oded Shimon wrote:
hmm, several bugs found in spec?
from spec:
If a info packet is stored anywhere then a muxer MUST also store an identical info packet after every main-stream-header set
This is nonsense in real time streaming, isn't it?.. In real time streaming, the only rule i suggest there should be is that after a main-header set, there should be all global info packets (chapter_id==0), and info packets applying to the current chapter. (e.g., if you joined in the middle of a song, you should get the info packet telling about the song)
the problem is not specific to realtime streaming but streaming in general think of a 1 week long file made of 1min long songs, streaming that in a non seekable way makes it impossible to place all info packets after every main-stream header set, the problem is that non seekability and streaming will need headers and info to be repeated often ... i have several suggestions to reduce this problem 1. require info packets (after the mainheader) to be ordered by their start time 2. drop the requirement you quoted above for streams for which no bidirectional out of band channel exists and which are neither seekable 3. dissallow main/streamheaders and info packets in the normal stream if an out of band system to transmit them is available 1 has the advantage of O(log n) vs. O(n) time for files with really many info packets (no effect on demuxer complexity unless it wants to use this additional ordering for quickly finding stuff, and IMHO small effect on muxer complexity, new files would always be valid in the old spec) maybe this could be added as a SHOULD requirement? maybe with a info packet saying sorted=1 or so? 2 should fix your complaint? the muxer would then have to place info based on the following 2 rules in the current spec: ---- If a demuxer has seen several info packets with the same chapter_id and stream_id then it MUST ignore all but the one with the highest position in the file demxuxers SHOULD NOT search the whole file for info packets ---- 3 ensures that no half valid nut files are laying around in case info packets are updated out of band (a client would either dump the stream blindly which would result in an unplayable stream, or dump it and then add the latest info and mainheaders) comments welcome ... [...] -- 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
participants (3)
-
Michael Niedermayer -
Oded Shimon -
Rich Felker