a few things about nut.txt

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

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

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 ...)

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

if you have several streams with normal keyframe distances
(10sec / 300frame)
and the keyframes are not aligned relative to each other
then you 
_CANNOT_ seek correctly, EOR does not help

heres a example:
vid1 KFF...10sec...FFKFF
vid2 FF..5sec..FKF...10sec...

to seek and display both streams you will have to _DECODE_ 5
seconds of video
which with high resolution will need about 5seconds ...

if one stream is a subtitle stream and one a video stream
then the VERY same
happens
example:

syncp   S S     S       S       S
backptr v------/       /       /
          v--------------------
vid     KFKFFFFFFFFFFFFFFFFFFFFFFFFFFK
sub     K  F   F   F  K   F   F     F
seek target                    ^

for the seek target the last syncpoint is choosen, its back
ptr points to
the second sync point, decoding from there will give you a
video keyframe
after that there are maybe 10 seconds or longer until a
subtitle keyframe
you MUST decode these video frames without displaying them
if you want
correct seeking

-> you CANNOT seek correctly if keyframes in a subtitle
stream are not very
frequent or aligned to the other keyframes, EOR has no
effect on this
if OTOH keyframes are frequent or aligned then EOR isnt
needed, so what
EOR seems to do is it affects only a case which doesnt work
with and 
without EOR

[...]

-- 
Michael     GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or
copy any book
Today you'd get arrested for mere telling someone where the
library is
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

a few things about nut.txt

Thread: a few things about nut.txt