[MPlayer-users] Mplayer with Stereoscopic using Vdpau

[Reimar Döffinger]

On Sat, Nov 27, 2010 at 07:35:53AM -0300, Cristian Sebastian Rocha wrote:
> You're right. Our approach benefits only a few users, but you can not
> get the same functionality with less effort. The problem is not the
> output surface, the problem is VDPAU decoder, which can not decode
> more than 128 macroblocks (2k pixels), so we use interleaved frames.

Yes, I understood that. The lack of better alternatives unfortunately
does not remove the issue of the approach :-)
It is also relevant that in the long-term this problem is likely to solve
itself (through VDPAU supporting either MVC or higher resolutions),
whereas the issues with the interleaved format are likely to stay
(though a solution more integrated with the decoder could use e.g.
userdata to signal which "view" a frame codes).

> You are right, we could use vdp_video_mixer_render to show both sides
> in one window. But we divided the frame into two windows because it
> was easier to test.  All this effort is not really need, perhaps the
> next version does not have this functionality.

I am not saying that the approach might not have been the best choice for
you, it's just that for us the approach of using two screens creates a lot
of code which from a maintainance standpoint isn't good enough to be included
in the main tree.

> Our goal was to achieve a low-cost stereoscopic player, with high
> definition and capable of decryption on-the-fly. That is why we
> studied several options, where mplayer with vdpau was the best,
> although we had to deinterlace.

Well, if it does what you want that makes it already a success!
I just want to make clear what from my point are the reasons that
speak against including it. This doesn't hinder anyone from using
the patch of course, and since you sent it to -users and not -dev-eng
you might even be more interested in the latter rather than the former.
Getting a largish functionality included "upstream" that was developed
over a long time completely independently is never easy, mainly for two
reasons:
1) The people implementing it usually are neither that familiar with the
   code base nor are they so well aware of plans for future functionality
   nor of some of the design considerations that were never properly documented,
   so the result tends to deviate from the "ideal" solution.
   Also since they only have to maintain their changes it is more important that
   merging new upstream versions works well than whether the change is 10 or 500 lines
   (whereas for us accepting a 500 line version in the _long term_ would result in
   code that is a unuseable mess even if in each individual case it seems like an
   acceptable compromise).
2) "Upstream" is not aware of the history, does not know all the details of why
   certain design decisions were made and which alternative approaches do not work.