[NUT-devel] NUT spec review - chapters

[Rich Felker]

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