[MPlayer-dev-eng] gl & distorted fisheye for dome projection

[Johannes Gajdosik]

On 06/29/2006 10:44:59 AM, Reimar Doeffinger wrote:
> Hello,
> On Thu, Jun 29, 2006 at 12:27:58AM +0200, Johannes Gajdosik wrote:
> > I assume a "vertex program" is a GPU program, correct?
> 
> Yes.
> 
> > Can you also please explain how "store in a texture and use a lookup"
> > works? Perhaps customtex already accomplishes my task,
> > in this case my humble apology for disturbing.
> 
> Actually you could accomplish this with customprog and customtex,
> probably with much higher quality than the current approach. Though I
> have to admit that IIRC it will mean that you have to use either ATI or
> nVidia binary drivers and a not too old graphics card (basically the
> same as for -vo gl:yuv=2).
> 
> > You seem to mean some kind of lookup-table-texture: the value of a pixel
> > in the texture would not just be RGB, but instead it would be a pointer
> > to a position inside the source image. Is such a thing possible?
> 
> (This is for the GPU-Programming approach) Yes, though you'd probably also
> want the brightness in there.
> But whatever the implementation I guess getting the cases where a black
> boder is added or the OSD is used would be problematic. Though this
> might be not really relevant *g*

Lets not consider the OSD in the first step.
I am glad that everything I want to accomplish is already implemented
in the current MPlayer version. The fact that it will only work for NVidia
and ATI is a little drawback, but on the other hand there may be performance
improvements or other benefits.

So if I understand correctly, the only thing I need to make is a
"custom fragment program" and a "custom texture". Or perhaps
rather a program that generates the "custom fragment program" and
the "custom texture" from the image sizes and the geometry parameters.

I have had a look at the manpage and at edgedetect.fp and emboss.fp.
And I must admit that I did not understand the fragment programs
well enough in order to be able to write my own. Some lines I could
not understand at all.

Can you give me a hint where to acquire the knowledge needed to
write a fragment program that accomplishes this task?


> > GPU programming would be interesting, of course, but I would also like
> > to keep compatibility with many graphic cards.
> 
> I understand that, but I don't think such special-purpose code (and I
> expect it to be quite a lot of code) to be suitable for inclusion in a
> standard MPlayer version.

In my opinion 200 LOCs would be enough. But I understand that you do not
want to include this in the gl vo driver. Especially when the same thing
is already possible for NVidia and ATI without code modification.
I will try the fragment program first.

For an easy alternative: Are plugins possible in mplayer? In this case I
think of a special vo plugin of course. The pluging would not have to be
distributed along with mplayer, and it would not have to be maintained
by mplayer developers.

Yours,
Johannes Gajdosik