[NUT-devel] NUT spec review - chapters

[Michael Niedermayer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/nut-devel/attachments/20080209/ad880168/attachment.pgp>