[NUT-devel] a few things about nut.txt

[Måns Rullgård]

Rich Felker said:
> On Sat, Nov 25, 2006 at 11:53:16AM +0100, Michael Niedermayer wrote:
>> Hi
>>
>> On Fri, Nov 24, 2006 at 10:58:20PM -0500, Rich Felker wrote:
>> > On Sat, Nov 25, 2006 at 12:03:55AM +0100, Michael Niedermayer wrote:
>> > > [...]
>> > > >
>> > > > > * nut files with EOR cannot be converted to other containers or more
>> > > > >   correctly you cannot seek correctly in the resulting file
>> > > >
>> > > > Not true.
>> > >
>> > > wait, EOR is "absolutely needed" and it works in containers which dont have
>> > > EOR, how can both be true?
>> >
>> > Other containers don't support correct seeking with subtitles unless
>> > they have an index of all subtitles.
>>
>> i dont think this is true, maybe someone who knows the details about subs
>> in mpeg-ps/ts could clarify but my suspicion is that there are rules in the
>> relevant specs which ensure that the correct subs are displayed after
>> seeking, and most other containers which support subs have an index ...
>
> I'm quite sure mpeg-ps/ts make no provision for this.

The ISO MPEG PS/TS specs do not mention any subtitles.  The DVD and DVB specs
add their own subtitle formats to PS and TS, respectively.

> DVD players and other devices that seek on
> mpeg streams generally have _horribly_ crappy behavior under seeking
> and don't seek at all except to chapter boundaries or via 'fast read
> and skip decoding of nonkey frames'. I've never seen one with
> seek-to-time, probably because mpeg does not even make seek-to-time
> possible due to meaningless resetting timestamps...

You haven't been looking hard enough then.  The DVD metadata (IFO files)
contains a time to byte offset index, usually with a granularity of around
2 seconds.  This allows for reasonably accurate seeking without the index
growing very large.

DVB streams are normally broadcast and seeking is meaningless.  DVR devices
usually parse the elementary streams and create an external index while
recording.  The particulars ones I work with even have frame-accurate
seeking, and continuously variable playback speed, both forwards and
backwards.

As for timestamp resets, you can't avoid them when broadcasting 24/7, unless
you have infintely large timestamp fields.

-- 
Måns Rullgård
mru at inprovide.com