[MPlayer-dev-eng] finalizing nut!

[Attila Kinali]

On Wed, May 26, 2004 at 11:12:44PM +0200, gabor wrote:
> On Wed, 2004-05-26 at 16:12 -0400, D Richard Felker III wrote:
> > nt forget about
> > > "character set encoding"...
> > 
> > I suppose that's part of the stream header for text streams.
> > Personally I would be tempted to forbid anything but UTF8; however
> > there are too many stupid people who would just break the rule anyway
> > to put their bad encodings...
> 
> no...please be strict on this...
> 
> imho:
> 
> i don't know what subtitle formats are allowed in nut, but if there is
> no list specified:
> 
> 1. if the subtitle format defines an encoding type (for example it
> forces it to be latin1), then let them be in that encoding
> 2. if the subtitle format defines a way to specify the encoding inside
> the sub file (i don't know about them, but think like in xml), then let
> them define it inside the subtitle file
> 
> 3. if the sub format does not define an encoding (like most of the
> subtitles i've met,like *sub *srt and so on), THEN PLEASE PLEASE PLEASE
> PRETTY PLEASE FORCE IT TO UTF8 IN THE SPECIFICATION..many thanks :)

I aboslutely agree with this.

Further i have to not that nut lacks specs in two important fields:
subtitels and chapters.

As i understand the current specs (which is btw quite hard if
you didnt follow the whole discussion) there is only a stream class
definted for subtitles but nothing is said on how it should be embeded
into the file and even at some places it cannot (!) be added w/o
contradicting the current specs.

First a little overview on what types of subtitles we have:

1) timestamp:text

This is the most simple form. There is nothing but what is necessary
to display the text (actualy there is a lot missing)


2) header
   timestamp text

Extension of the former. Sometimes even specifying different
charactersets in the header. 1) and 2) can be handled similar
to audio streams as they share the basic properties.

3) header
   timestamp text_with_embeded_drawing_code

This is the most complicated form, as the text may include anything
starting from simple text going up to complete videos (yes, there are
formats that specify how to show short clips in a subfile!)


IMHO, there need to be at least a way how to store the header (is the
codec_specific_data meant for this?). I dont know how to handle the 
timestamps correctly, as they are actualy timestamps+duration.
Also the complex text_with_embeded_drawing_code is a problem for
seeking. Ie to properly draw the subtitels after seeking you might
need the last few text chunks as they might overlap or even a former
chunk is shown after a later is already gone. 

Currently i'm thinking about a rewrite of the subreader code and
the best solution for handling the more complex subtitles i could came
up with was to read the whole file and store it in an intermediate,
render friendly format in mplayer. I think that nut will face similar
problems if such formats should be supported.

Side question: Mosu how does mkv handle those advanced features of
ASS ?

All in all, the exact storage of subtitels should be clearly
spelled out in the specs, otherwise we will end up with incompatible
and restricting implementations.

Also the chapter information storage should be spelled out,
though i have really no idea on what information is needed there and how
it should be stored.

IMHO also a clearly defined way on how to add other stream types
to nut is missing. Especialy on what to do with stream types that are
not recognized.

Note also that there should be a authoritative body specified for
further extensions of nut.


			Attila Kinali


			Attila Kinali