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

[Rich Felker]

On Sun, Nov 26, 2006 at 06:30:28PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Sat, Nov 25, 2006 at 01:38:39PM -0500, Rich Felker wrote:
> [...]
> > 
> > > > 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
> 
> my sugestion was not to make the muxer inject new frames but rather that
> you cannot seek to points where there are no keyframes (this is pretty much
> how things normally behave, ignoring subtitles ...)

Well the result of this is that _someone_ must inject new frames or
else all movies with subtitles become completely unseekable...

> with gaps/EOR OTOH its possible to seek to keyframes and gaps but if so why
> disallow it for non subtitle streams?
> what extra computations would be needed on the demuxer side for non subtitle
> EOR? (a muxer could always choose not to support EOR)

Nothing whatsoever on the demuxer side. The problem is on the player
side. The player would either have to be able to either generate
silence (for audio) or switch to a different sychronization system...

Anyway the practical difference here is that EOR for subtitles is
needed to implement in NUT something that is already existing
practice: movies that do not constantly have a subtitle displayed. EOR
for audio/video, while it could be nice, is not needed for any
existing practice, only to add a new capability that did not exist
before.

> > 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.
> 
> which will cause a few milliseconds of useless computations after a seek

Depends on the behavior of the player, but hopefully yes.

More fundamentally, the principle of "correct seeking" is violated,
and if we're going to violate that we might as well not have put so
much effort into ensuring that it works to begin with. You never cared
much about it but I did...

> > 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. :(
> 
> its a bad sign if you need to think about something for days to rediscover
> why it was needed,

If this is the case then all of NUT is a horrible horrible design. The
point is that it's easy to satisfy all the conditions required on
muxing and that it's easy to implement a demuxer. Understanding _why_
all the conditions are necessary was never intended to be easy, and
IMO it's impossible to make a good set of conditions which are both
easy to satisfy/interpret AND easy to understand the motivation
behind. If not impossible, it would take us at least 6 more years...!

> it means IMHO the thing is too complex already or the
> case which needs it is pretty obscure or the reasoning hasnt been 
> documented, in which case disscussing the issue and documenting the reasoning
> seems like a good idea ...

OK if someone can come up with a list of requirements/features/etc. in
NUT that seem unjustified, I will write up detailed documentation on
what they're needed for. Maybe I'll be wrong and it will be easy to
understand once I've written this...

Rich