[MPlayer-dev-eng] NUT (informal) proposal, based on discussions

[Ivan Kalvachev]

2006/1/18, Rich Felker <dalias at aerifal.cx>:
>
> Index:
>
> 1. List of all syncpoints positions

This alone is enough to discard your proposition. The index must
contain one entry per keyframe. As of now the syncpoints are on every
32kb and may be way more often than keyframes.

This is exactly why I raised my voice again nuts syncpoints.

What I propose.
1. Index that contains entry for all keyframes on all streams that are
not keyframe only (Rich doesn't know what intra-frame is so i will use
the word keyframe instead)

2. If you think that audio streams may need to be read a little
earlier that video stream (e.g. we have audio frame starting before
video pts and next after pts, it could be needed for video editor) we
_may_ include entry for the corresponding keyframe-only stream..

That's it.

I had talked with oded before and I see the idea of seekpoints in syncpoints.
But the goal is out of proporsion.

1. There is no reason index to not be created. Only exceptions are
streams that are been captured atm, or linear download stream.

2. Binary search itself means a lot of seeking. We can safely assume
that it is feasible only on fast-seekable media.
As result we can omit a lot of redundant info in the seekpoint.

3. The idea of seekpoints is that we may find the frame with needed
pts, but we have no idea for the keyframe we need to decode that
frame. So we either need it pts or pointer info (called back_ptr). On
fast seeking media we don't need both (#2).
I prefer back_ptr, as it will need less seeking than re-starting binary search.

4. Syncpoints are very frequent. This means we must put as less
information as possible.
So I think that syncpoints must contain back_ptr to their keyframe
(only for their stream). If we need multiple streams we may parse a
little more info in order to get extra keyframe info. Subtitles are
different matter.(below)

5. We can afford to put huge seekpoint at the keyframe syncpoint, as
keyframes are less frequent. All inter-stream dependencies could be
there, not in the regular bytestream
In order to optimize small seeks and generally to have more local
info, we may also resurrect the linked keyframe chain that was removed
before, .

I personally doesn't like including so many redundant data, as it will
only waste space in 99% of the cases and it doesn't really improve
error resistance.. It just minimize the searching time for binary
search. In usual case 1 video stream 1 or more keyframe only audio
stream, we will never need to do refinement for more streams,
excluding subtitles problem.


6. Subtitles are much more complicated. Let's assume we have huge
bitmap subtitles we cannot store at once. Subtitles have start time
and end time (or duration). The question is should we store the start
time of previous subtitle in seek/syncpoint if it is pass it
duration/end_time? If not, how is the demuxer going to know that?
There are 5 cases:
a) we store one subtitle frame with the text/sub info, then one empty
to hide it. This way we use frame pts. The bad side... we must
complicate demuxer to handle subtitles by different way than the other
streams.
b) we store one subtitle frame and code the pts and duration info in
the same frame. The bad side, demuxer won't know about duration or
will need special handling for subtitles. (or even special type of
frame).
c) store all subtitles at once place.Not good idea with bitmap type subtitles.
d) seek/sync pointers always point to the previous subtitle frame no
mater if it is needed or not, wasting valuable space.



As final note, precise seeking is what WMP did for a long time, you
point the seekbar and it seeks precisely to the pointed frame(that it
had figured out somehow), including finding the previous keyframe and
decoding and discarding all frames until it reach it (usually 9 sec in
play time). We had laughed at them as in this case it is not needed.
MPlayer seeking was considered right and fast.

Nut must be able to do both, precise backward seeking (but slower in
rare cases) and (always fast) forward seeking. The application must
decide which one it needs. (or even that it prefers backward for
backward and forward for forward).

P.S.
I'm not intending flaming and will surely ignore anything that Rich
throws at me without thinking or understanding my proposals.
I would highly appreciate any comments from Oded and Michael.