[MPlayer-dev-eng] [RFC] EOSD improvements

[Reimar Döffinger]

On Sun, Aug 01, 2010 at 12:39:35AM +0200, Reimar Döffinger wrote:
> On Sun, Aug 01, 2010 at 12:14:19AM +0200, Grigori Goronzy wrote:
> > On 07/31/2010 06:00 PM, Reimar Döffinger wrote:
> > > I think you should already with the first patch come up with something
> > > that will work ones the types are different, otherwise there's no way
> > > to know if your design is going to be even remotely useful or if there's
> > > some mayor issue that means we'll just have to 100% revert it.
> > 
> > Sure - this is merely a proof of concept, not meant to be committed to
> > mainline.
> > More importantly I'm interested in what developers think about extending
> > EOSD to be a generic OSD interface (and modifying spudec to use it).
> 
> Well, just as kind of "background" in principle spudec probably at some point
> should be split into a part doing decoding and a part handling display of
> the subtitles.
> For this purpose it might make sense to (despite increased memory
> requirement) decode the data before enqueueing.
> Similarly, the vf_ass filter currently does timing, image generation and
> blending, which is not suitable to spudec which already does the timing.
> Personally I would suggest going for the absolute minimum that gives
> some "visible" result, seeing how it looks when it is actually
> implemented and possibly just throwing it all away if it does not look
> good.
> One possibility for that is to just make the current luminance-alpha
> vobsubs rendered via EOSD, since that does(should) not require any
> changes to the EOSD rendering and ASS_Image struct.

Note that a second step could be to then push one ASS-compatible bitmap
per palette entry, which should allow fully working, colored DVD
subtitles with "only" 4 rendering passes.
PGS is a bit unrealistic this way, it might require 256 passes...