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