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