[MPlayer-dev-eng] Lots of stuff for NUT

[Vladimir Mosgalin]

Hi Rich Felker!

 On 2006.01.09 at 15:28:28 -0500, Rich Felker wrote next:

> > note, iam sure the end user _does_ care about seeing the subs after seeking
> > while she probably wont care much about a little overhead or seeking to the 
> > "optimal" point
> 
> Again this is optional. Usually I couldn't care less about seeing the
> subs after seeking, but I know many users would like to and sometimes
> I want to as well. In most formats other than NUT, it's not even
> possible to show the subs immediately after seeking without an
> unbounded backwards linear search, so I'm used to not seeing them.

I'd like to insert my two cents.. I know you are in a middle of hot and
interesting discussion, but I hope user's comments are allowed here..

mplayer has a wonderful feature, it can show previous/next subtitle. It
is really useful, when you want to read subtitle that quickly
disappeared a bit longer without seeking backwards. It works only with
external subtitles, however.
Now, in most containers, like mpeg-ps, ogm and mkv it wouldn't be even
possible to display next subtitle, because you have to seek in stream,
which of course is stupid. External subtitles can be preloaded, but
you can't extract subtitle stream from these containers without reading
complete stream.

Now, I'd really like NUT to be a container where you can quickly extract
subtitle stream (at least the text ones), for this and other purposes.
Ability to add subtitle stream without remuxing the whole file (which
can even lead to problems in rare cases), would also be great, though
not that required.

> I'm sorry you're getting irritated, but as the end user, I care about
> correctness. It pisses me off when I use -ss X and end up at timestamp
> X+-not_so_small_delta. Maybe other users don't care about this, but
> then again they probably don't care about overhead either, especially
> when it's way smaller than AVI and somewhat smaller than MKV.

I'd like to second that! And you really shouldn't care about overhead
that much... Big overhead would be really bad for audio-only files, but
with today's video bitrates people use for distribution, backup and even
streaming, it's not a thing to worry about. IMHO features and
correctness should be number one priority.

Well, personally I don't even mind about overhead of avi files.. mpeg
files are worse anyway ;) Also index can be compressed. Since it's in
one chunk, it will compress really well, and using something like lzo
will allow fast decompression with very low memory requirements on all
kinds of systems.  If you care about size (no, not personally you, Rich
;) ), why not use a more advanced, but compressed index?

-- 

Vladimir