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

[Rich Felker]

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. Maybe Måns would
like to back me up though? 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...

> > > just try:
> > > 
> > > Sub: K                                   K
> > > Vid: KFFFFKFF..1hour..KFFFFKFF..1hour..KFFF
> > > 
> > > you can either
> > > A. ignore the subs and seek purely based on the video stream (will not
> > >    display subs after seeking)
> > > B. seek to previous keyframe of all streams (will not allow you to seek
> > >    into the 2 hour segment without sub keyframes
> > 
> > Having the same subtitle displayed for 2 hours duration (or even more
> > than 5-10 seconds duration) is nonsense. If you meant for the subtitle
> > at the beginning in your example to only be briefly displayed, then no
> > subs for the next 2 hours, EOR is what allows NUT to accomplish that!
> 
> my example is about a non nut container, and what is displayed or not
> between the keyframes of the subtitle stream is NOT known to the
> demuxer (and neither to the nut muxer which should mux that, unless
> it parses the subtitle stream ...)

I don't think it's unreasonable at all for the muxer to need to be
passed durations for subtitles as well as starting timestamps. Without
duration there's no way the demuxer could possibly support knowing
whether the subtitle is still relevant when seeking. EOR is just a
clean stream-oriented way to encode duration and prevent messing up
the back_ptr system.

> > The only other possibilities are to give up on your correct seeking
> > with subtitles (which you seemed to want the most of any of us) or
> > throw in thousands of fake empty keyframes.
> 
> yes, ~1000 small (<10byte) keyframes whos position in time matches the video
> keyframes would be the correct solution, needing 10kb for 2 hours is
> negligible its a mere ~ 0.01 kbit/sec

It's not correct! To do this the muxer has to manufacture data as
well! It also means seeking will be _incorrect_, in the sense that if
you disable video and just enable audio and subs, seeks will go
farther back than they need to in order to find the _useless_ blank
subtitle.

PLEASE for the love of [insert deity here] stop bringing up old issues
now; it's too late. It's easy to complain about these things now 1.5-2
years later when everyone's forgotten why the decisions were made the
way they were and why they're essential to correct operation, but that
doesn't mean we should go through the same process again now only to
rediscover the same thing. :(

Rich