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

[Reimar Döffinger]

On Mon, Aug 02, 2010 at 12:04:26PM +0200, Nicolas George wrote:
> Le quartidi 14 thermidor, an CCXVIII, Reimar Döffinger a écrit :
> > 1) I first and mainly only suggested making it work with the current
> >    luminance-alpha which should be a good idea anyway and not much effort.
> 
> I do not think this is a very attractive idea: although it is possible,
> fitting the square-shaped peg of a colored image into the circle-shaped hole
> of a luminance+alpha API is tedious code that would become utterly useless
> if RGBA support is added, as expected.

But we do not have any RGBA images in MPlayer anywhere currently!
We do have paletted images and we do have luminance+alpha.

> In building construction, I believe it is considered a bad idea, when the
> foundations are seen to be too shaky for a first-story extension, to build
> the extension with strings and sticks and later rebuild stronger
> foundations.

I am suggesting to build the foundation (passing the image data through
the filter chain via EOSD etc.) and then build the extensions to it
(RGBA support) instead of first building the extensions and then see
if we can shove the foundations below it.
My reason for considering it this way is that there's not really that
much you can do wrong when adding the support for an additional format,
it just bloats the code a bit.
And I am trying to suggest to first get the thing working in principle
and then add the bloat.

> > 2) For DVDs I think it's likely to be at least not significantly less
> >    efficient, possibly even more efficient to do one render pass per
> >    palette - but anyway that was just an additional idea.
> 
> DVD subs have only four palette entries, with one supposed to be completely
> transparent. DVB subtitles can have much more, up to 256 I believe, and I
> have seen with 15 used colors for smooth shaded letters.

Which is why I was only talking about DVD. And this was only a
suggestion of what could be done - if not much effort.

> > I thought I said clearly the low-level support is _not_ my concern,
> > my concern is that we might end up with working but _useless_ low-level
> > support because the high-level stuff (time stamp handling etc.) might
> > mean it does not work for any of the cases we want to have it working.
> > Or to put it differently: I suggest to implement a as simple as possible
> > proof-of-concept that does something useful before starting with API-level
> > work.
> > Of course I only suggest this because I expect it to be minimal to
> > no additional work overall.
> 
> Converting anything to the "constant color+alpha mask" format is additional
> work, and very unrewarding as it is, since it would become useless once the
> API work is done.

_All_ subtitle formats coming from existing code is already in that
format, would you please tell me where that "additional work" is
supposed to come from?
Supporting the _other_ formats is what needs additional work, and I
suggest to do that last because it makes the other changes that may be
necessary more work.
Also I disagree about it becoming it useless, the luminance+alpha format
is the only one where the -vo gl:osdcolor will still work, however don't
misunderstand me, I don't want to push this as extra work on you, I just
don't think it should be extra work (or at least not much).

> Requiring it is a sure way to discourage people, as Uoti did to me when I
> tried to push DVB subtitle support eighteen months ago.
> 
> What about API work along with a simple-yet-useful feature to show its
> usefulness? I can think of two right now:
> 
> - A pair of slave command to overlay a bitmap file on top of the running
>   video:
>   bitmap_add tag filename x y w h
>   bitmap_remove tag
> 
> - A .srtx overlay video filter: .srtx is the same as .srt, but with the name
>   of a bitmap file instead of the text of the subtitle.

Well, maybe, but I think neither of them will answer whether the code
will work with the current DVD, DVB, PGS subtitle support without
_completely_ rewriting it.
And you'll have a huge amount of convincing in front of you if your
solution will need much more than an additional paletted->RGBA conversion
instead of the existing paletted -> luminance+alpha one.

> Both would be very easy to implement if EOSD had a clean public entry point,
> but are much harder to implement now.

I just think that we now have two OSD things. And I simply can't shake
the suspicion that if everyone starts at the most unrelated part and at
the end figures out that it all just doesn't fit together we will end up
with 4 or more when we finally have full coloured subs and none of the will
work properly.
There's one thing I truly hate, and that is a half-assed rewrite every
few years with no-one ever really finishing it.
If it's reviewable patches and you can convince me you have a good idea
of how to get it to an actually working solution that does not require
us to keep one OSD backend per subtitle format or performance
requirement around I don't think I'll object, I am just saying I am not
convinced you have an idea of how to fit it all together in the end and
I am suggesting a way that I think should give you that idea with
minimal effort.