[Matroska-devel] Re: Re: Re: EBML

[Paul Bryson]

"Martin Nilsson" wrote...
> Paul Bryson wrote:
> > Limiting the number of subtitle formats definately wouldn't decrease the
size of
> > the lib.  Subtitles are just another generic form of data in Matroska. The
> > same as Video and Audio.  Its all generic.  Matroska doesn't care what
> > it is, it depends on whatever system is being used to decode the data
> > in the proper way.
>
> The reason why I mentioned subtitles in the first place is beacuse there
> is some sort of interpretation of the formats when separating them into
> Track->CodecPrivate and Cluster->Block. Since there is interpretation,
> why not also have normalization, or at least "compression" to a binary
> format?

I am not sure what you are talking about here.  Could you rephrase this?

> But I guess that I am talking for no reason. The "correct" solution from
> Matroska point of view is for me to present a new format and hope for
> its adoption.

That is correct.  Matroska is not about defining what compression formats to
use, it is about offering a common platform for all formats to be used on.

> > On a different note, PNG would be very desireable with its 255 levels of
alpha.
> > Current systems are not strong enough to be depended on to decode PNG
subtitles
> > without causing a pause in the video.
>
> You can't be referring to systems made this century...

Well, tests were made using libpng, so results may vary if using another lib
such as the Opera PNG lib.  Using a 24fps PNG clip at 512x384, and no audio,
resulted in a file that was playable with a slight stutter on my Athlon 2100+.
Decoding PNG subtitles at full DVD res or HDTV, AND decoding the video, AND
overlaying the PNG image on top of the video with full alpha transparency would
indeed result in stuttering.  Current video players simply don't buffer well
enough.

Some people want to prerender complicated SSA scripts into PNG subtitles.  That
definately isn't doable yet.  But when computers are fast enough, it will be
done.

> > Also, it is not likely that any will ever provide full UTF-8 support as the
full
> > Arial font is around 20MB.
>
> As always it's a matter of competence. You can get a Unicode font
> supporting all languages, optimized for TV-resolution, from Bitstream
> that is around 3MB. You can cluster that one into codepages and compress
> them separately.

That sounds like an excellent option.  Do it and define a new standard.  If the
decoder filters work well, and creation tools are easy to use, it will be
adopted.


Pamel