NUT spec review - chapters
I've been reviewing the NUT spec for clarity and bugs and found one small issue with the way chapters are specified for info: chapter_id (s) The ID of the chapter this packet applies to. If zero, the packet applies to the whole file. Positive chapter_id values represent real chapters and MUST NOT overlap. chapter_start (t) timestamp of start of chapter chapter_len (v) Length of chapter in the same timebase as chapter_start. It's likely impossible to partition a file into chapters that cover the whole file without overlapping due to the requirement that chapter_len use the same timebase as chapter_start. Surely you could just cut the chapter lengths short and in most places it would only make a difference of a few frames, but it one wants to use chapters for cutting a file and later being able to rejoin the parts to get the original file, things would break badly. Using chapter_end in its own timebase or having positive chapter_ids implicitly ended by the start of the next chapter would both work, but would break the frozen syntax. Is this an issue anyone cares about? Is there a nice fix? I'll post any more issues I see as I continue to review. Rich
On Sat, Feb 09, 2008 at 04:44:45AM -0500, Rich Felker wrote:
I've been reviewing the NUT spec for clarity and bugs and found one small issue with the way chapters are specified for info:
chapter_id (s) The ID of the chapter this packet applies to. If zero, the packet applies to the whole file. Positive chapter_id values represent real chapters and MUST NOT overlap.
chapter_start (t) timestamp of start of chapter
chapter_len (v) Length of chapter in the same timebase as chapter_start.
It's likely impossible to partition a file into chapters that cover the whole file without overlapping due to the requirement that chapter_len use the same timebase as chapter_start. Surely you could
just cut the chapter lengths short and in most places it would only make a difference of a few frames, but it one wants to use chapters for cutting a file and later being able to rejoin the parts to get the original file, things would break badly.
This would break badly with overlap as well. Its a matter of missing vs. duplicated packets.
Using chapter_end in its own timebase or having positive chapter_ids implicitly ended by the start of the next chapter would both work, but would break the frozen syntax.
You assume that a chapter partitioning is possible in a stream independant way. This might not always be true, chapter boundaries might differ very slightly between streams. Generic info would solve it. Specifying chapters per stream would work as well, and its debateable if thats allowed by the spec or not. Chapters would not overlap within a stream. But iam not saying thats a solution i would want to have ... Having chapter_end in a seperate info packet would break error robustness. One no longer could use the data of an info packet without knowing that the next one was undamaged. Now think of what happens if a info packet has been damaged, a remuxer would have to discard all info packets. The last because its damaged, the previous because it depended on the last the next previous because it depended on the removed one and so on ... Also you have suggested this already a long time ago and we decided it is a bad idea. Having seperate timebases for begin and end would be better than above. But the most important part you forgot is that chapers might end at slightly different spots in streams. If you want to specify this exactly then this change wont get you any closer to it. If you dont you can as well just always use the chapter start/end of the video or audio stream. Its not much less accurate and theres no overlap/gap problem. Thus in summary i think * As the system is, specifying all chapters in the same timebase should work. Not exact, but your 2 suggestions arent always either. * For exactness generic info or per stream chapters with the current system could be used. Iam very strogly against breaking compatibility to move from one restricted system which you thought sufficient in the past to a slightly differen one you consider sufficient now. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus
On Sat, Feb 09, 2008 at 01:57:51PM +0100, Diego Biurrun wrote:
On Sat, Feb 09, 2008 at 01:49:03PM +0100, Michael Niedermayer wrote:
Iam very strogly against breaking compatibility
Breaking compatibility with what?
With the frozen spec. It is EXTREEMLY unprofessional to call something frozen and then break compatibility for a dubious improvment. One shouldnt complain about mpeg being lame while then acting even more lame. Also as said we just move to another restricted (and more complex!) case. Its like: 1 year ago: We know beyond doubt that X is exactly what is needed and we insist on having everything else disallowed by the syntax. today : We know beyond doubt that X2 is exactly what is needed, X wasnt enough and we insist on having everything else disallowed by the syntax. This is not the kind of change we should do, its just repeating our past mistake. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Thouse who are best at talking, realize last or never when they are wrong.
On Sat, Feb 09, 2008 at 02:38:17PM +0100, Michael Niedermayer wrote:
On Sat, Feb 09, 2008 at 01:57:51PM +0100, Diego Biurrun wrote:
On Sat, Feb 09, 2008 at 01:49:03PM +0100, Michael Niedermayer wrote:
Iam very strogly against breaking compatibility
Breaking compatibility with what?
With the frozen spec. It is EXTREEMLY unprofessional to call something frozen and then break compatibility for a dubious improvment. One shouldnt complain about mpeg being lame while then acting even more lame.
Also if we do decide to break compatibility then this should be marked clearly. Not like yet another commit to nut.txt Iam thinking here of nut2.txt with the number acting like a soname and of course also updating the stored version number And the new variant would be non frozen so until its frozen compatibility breaks could be done much easier ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle
On Sat, Feb 09, 2008 at 02:38:17PM +0100, Michael Niedermayer wrote:
On Sat, Feb 09, 2008 at 01:57:51PM +0100, Diego Biurrun wrote:
On Sat, Feb 09, 2008 at 01:49:03PM +0100, Michael Niedermayer wrote:
Iam very strogly against breaking compatibility
Breaking compatibility with what?
With the frozen spec. It is EXTREEMLY unprofessional to call something frozen and then break compatibility for a dubious improvment. One shouldnt complain about mpeg being lame while then acting even more lame.
The spec was called frozen, yes. However, just calling something frozen is inconsequential. The important part of calling something frozen are the ramifications of the act of calling it frozen. What people care about is not that the word "frozen" appears on some random document on the internet. Instead, once something is called frozen certain things should be guaranteed. One thing that should be guaranteed is stability of interfaces, but much more important is that the project has moved beyond a certain point and all important issues are resolved. Now if you have a look at recent discussions and nutissues.txt, this is not yet the case. Thus, I disagree that compatibility should not be broken. Calling the spec frozen was premature. Make all the changes that are necessary without burdening yourself with bogus backwards compatibility. The moment to take these things into account has not yet come. If you are afraid of appearing unprofessional then having called the spec frozen at some point really is the least of your troubles. Note that I'm not trying to flame here, I will shortly send a message with an outline how to move forward and professionalize NUT. Diego
On Sat, Feb 09, 2008 at 01:49:03PM +0100, Michael Niedermayer wrote:
On Sat, Feb 09, 2008 at 04:44:45AM -0500, Rich Felker wrote:
I've been reviewing the NUT spec for clarity and bugs and found one small issue with the way chapters are specified for info:
chapter_id (s) The ID of the chapter this packet applies to. If zero, the packet applies to the whole file. Positive chapter_id values represent real chapters and MUST NOT overlap.
chapter_start (t) timestamp of start of chapter
chapter_len (v) Length of chapter in the same timebase as chapter_start.
It's likely impossible to partition a file into chapters that cover the whole file without overlapping due to the requirement that chapter_len use the same timebase as chapter_start. Surely you could
just cut the chapter lengths short and in most places it would only make a difference of a few frames, but it one wants to use chapters for cutting a file and later being able to rejoin the parts to get the original file, things would break badly.
This would break badly with overlap as well. Its a matter of missing vs. duplicated packets.
Overlap is already illegal so I did not even consider it. Of course it is just as bad, or even worse..
Using chapter_end in its own timebase or having positive chapter_ids implicitly ended by the start of the next chapter would both work, but would break the frozen syntax.
You assume that a chapter partitioning is possible in a stream independant way. This might not always be true, chapter boundaries might differ very slightly between streams.
If streams are truely part of the same program, then the chapter boundaries "should" be the same for each stream, for an appropriate sense of the word "should". At least I don't think it's a major issue.
Generic info would solve it. Specifying chapters per stream would work as well, and its debateable if thats allowed by the spec or not. Chapters would not overlap within a stream. But iam not saying thats a solution i would want to have ...
I think it's exceedingly ugly and makes practical use of chapters almost impossible. How is a player supposed to present chapter lists in an accessible manner then?
Having chapter_end in a seperate info packet would break error robustness. One no longer could use the data of an info packet without knowing that the next one was undamaged. Now think of what happens if a info packet has been damaged, a remuxer would have to discard all info packets. The last because its damaged, the previous because it depended on the last the next previous because it depended on the removed one and so on ... Also you have suggested this already a long time ago and we decided it is a bad idea.
I agree it's a bad idea.
Having seperate timebases for begin and end would be better than above. But the most important part you forgot is that chapers might end at slightly different spots in streams. If you want to specify this exactly then this change wont get you any closer to it. If you dont you can as well just always use the chapter start/end of the video or audio stream. Its not much less accurate and theres no overlap/gap problem.
Indeed, you can use the same timebase for all the chapter boundaries, but this seems rather limiting and artificial.
Iam very strogly against breaking compatibility to move from one restricted system which you thought sufficient in the past to a slightly differen one you consider sufficient now.
Alright. Even though there is no implementation of chapters at this time.. Rich
On Sat, Feb 09, 2008 at 10:54:13PM -0500, Rich Felker wrote: [..]
Having seperate timebases for begin and end would be better than above. But the most important part you forgot is that chapers might end at slightly different spots in streams. If you want to specify this exactly then this change wont get you any closer to it. If you dont you can as well just always use the chapter start/end of the video or audio stream. Its not much less accurate and theres no overlap/gap problem.
Indeed, you can use the same timebase for all the chapter boundaries, but this seems rather limiting and artificial.
I dunno, Chapter 1 begin video frame 500, end audio sample 99000 Chapter 2 begiin subtitle sample 87, end video sample 876 looks a little strange, having it all in one timebase looks better IMHO, also theres the issue that practically every demuxer will convert it immedeatly after loading to a common timebase. I would at least in lavf, its too much of a mess to work with such timestamps.
Iam very strogly against breaking compatibility to move from one restricted system which you thought sufficient in the past to a slightly differen one you consider sufficient now.
Alright. Even though there is no implementation of chapters at this time..
hmm, well if thats true we might be able to cheat but i still think that maybe this isnt all that much of an improvment. being able to specify chapters in any timebase one wants seems sufficient. Having a timebase per timestamp seems like an overkill ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato
On Sun, Feb 10, 2008 at 05:56:32AM +0100, Michael Niedermayer wrote:
On Sat, Feb 09, 2008 at 10:54:13PM -0500, Rich Felker wrote: [..]
Having seperate timebases for begin and end would be better than above. But the most important part you forgot is that chapers might end at slightly different spots in streams. If you want to specify this exactly then this change wont get you any closer to it. If you dont you can as well just always use the chapter start/end of the video or audio stream. Its not much less accurate and theres no overlap/gap problem.
Indeed, you can use the same timebase for all the chapter boundaries, but this seems rather limiting and artificial.
I dunno, Chapter 1 begin video frame 500, end audio sample 99000 Chapter 2 begiin subtitle sample 87, end video sample 876
looks a little strange, having it all in one timebase looks better IMHO, also theres the issue that practically every demuxer will convert it immedeatly after loading to a common timebase. I would at least in lavf, its too much of a mess to work with such timestamps.
It could be converted to the gcd timebase by the demuxer implementation. Lame implementations also just might use double or something...
Iam very strogly against breaking compatibility to move from one restricted system which you thought sufficient in the past to a slightly differen one you consider sufficient now.
Alright. Even though there is no implementation of chapters at this time..
hmm, well if thats true we might be able to cheat but i still think that maybe this isnt all that much of an improvment. being able to specify chapters in any timebase one wants seems sufficient. Having a timebase per timestamp seems like an overkill ...
That's probably okay too... Rich
On Sun, Feb 10, 2008 at 12:35:05AM -0500, Rich Felker wrote:
Iam very strogly against breaking compatibility to move from one restricted system which you thought sufficient in the past to a slightly differen one you consider sufficient now.
Alright. Even though there is no implementation of chapters at this time..
hmm, well if thats true we might be able to cheat but i still think that maybe this isnt all that much of an improvment. being able to specify chapters in any timebase one wants seems sufficient. Having a timebase per timestamp seems like an overkill ...
That's probably okay too...
To clarify, if the decision is just to leave things as-is, I'd like to add a "SHOULD" recommending that NUT files use the same timebase for all chapters, or at least those with positive chapter_id. Also I suppose it's legal to include the gcd timebase in the global header's timebase list, and then chapters can truely be split at arbitrary points. :) Rich
On Sun, Feb 10, 2008 at 12:40:03AM -0500, Rich Felker wrote:
On Sun, Feb 10, 2008 at 12:35:05AM -0500, Rich Felker wrote:
Iam very strogly against breaking compatibility to move from one restricted system which you thought sufficient in the past to a slightly differen one you consider sufficient now.
Alright. Even though there is no implementation of chapters at this time..
hmm, well if thats true we might be able to cheat but i still think that maybe this isnt all that much of an improvment. being able to specify chapters in any timebase one wants seems sufficient. Having a timebase per timestamp seems like an overkill ...
That's probably okay too...
To clarify, if the decision is just to leave things as-is, I'd like to add a "SHOULD" recommending that NUT files use the same timebase for all chapters, or at least those with positive chapter_id.
Added
Also I suppose it's legal to include the gcd timebase in the global header's timebase list, and then chapters can truely be split at arbitrary points. :)
yes, but the gcd might violate "time_base_denom MUST be < 2^31" and thus wont be storeable. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already.
participants (3)
-
Diego Biurrun -
Michael Niedermayer -
Rich Felker