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

[Rich Felker]

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. NUT's back_ptr is the mechanism
by which NUT makes this possible, but without EOR it will ruin seeking
in files without extremely frequent subtitles.

> 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!

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.

BTW, for subtitles, EOR is nothing more than a fake empty keyframe
after every syncpoint. It's just a shorthand notation where they don't
actually have to be stored, and it makes it easier (with index, at
least) to find all the actual _real_ subtitle frames if you want to
extract them.

> > > * lav* does not support it (and i dont plan to change that), for lav*
> > >   gaps are not allowed, you will have to encode black/silence/no subs
> > >   keyframes (which require only negligible storeage anyway)
> > 
> > The nut muxer should automatically generate EOR for subtitles and not
> > use it anywhere else (except perhaps eof). Just repeating an 'empty'
> > subtitle every few seconds is an ugly hack.
> 
> IMHO EOR is a ugly hack, puting keyframes where you want to seek to is
> the correct thing to do

No, flooding the stream with a bunch of fake subtitle keyframes is the
ugly hack. It's a huge waste of bandwidth and requires _more_ special
casing by the muxer, not less. EOR is very simple to handle and fits
in with all the existing semantics. That's why we were able to add it
when the issue came up.

> also if you have a special case for "whole screen transparent" then why
> not for black frames or no audio? or gray frames or white frames ...
> this does make at least as much sense as for subtitles, think of a audio
> stream with music, one with actors voices, one with commentary, one with
> special effects, ...
> having this split would be VERY nice, and these streams would have alot
> of large gaps which would benefit from EOR

They would, that's why I don't want to rule out supporting it in the
future. But at this time it seems utterly incompatible with most
player designs, and mandating support for it seems like a bad idea. I
wouldn't mind offering support in an "advanced profile" or something,
but I don't know if we want to go there yet... It seems like we could
at least wait until the NUT 1.0 spec is out the door to start worrying
about more advanced profiles that could be difficult for existing
players to support...

Rich