[MPlayer-dev-eng] [PATCH] vda support for mplayer

Reimar Döffinger Reimar.Doeffinger at gmx.de
Fri Aug 17 08:22:22 CEST 2012


On 17 Aug 2012, at 04:00, Xidorn Quan <quanxunzhen at gmail.com> wrote:
> It seems that other hardware accelerations supported in MPlayer
> cannot cooperate with video filters because (from comments in them
> I guess that) they only provide compressed data directly from decoder
> to video out. VDA is different from them. The data VDA provided is
> just wrapped raw image data, so I hacked vf_scale and forced it to
> recognize VDA data as normal image data. It works fine for me.
> I tested ass, mirror, screenshot and noise, they all works perfectly.

Why can't FFmpeg then just provide the data as a completely normal image?
Or mire specifically, why is the code that is in vd_ffmpeg not in FFmpeg instead?

> The code modified in vo_corevideo in fact is not very useful since
> vf_scale may convert all VDA-format data to raw image data, but when
> no vf is applied and shared_buffer is not enabled, the image can be
> draw directly from vd to vo with no unnecessery copying.

Might be just too early in the morning for me to understand it, but at the moment I don't see why not adding that code should add a memcpy.
Also I'd think that -vo gl should not require a memcpy any more (and is a huge lot faster and thus the preferred vo for me on OSX - though probably won't be when the raw data is in yuyv instead of yv12 I guess).

> At the end, I'd like to point out that there is still a problem that
> it will fall into endless loop instead of falling back to alternative
> codec if the video inputed is not supported by VDA (e.g. 10bit,
> in TS container, etc.) or VDA cannot be initialized successfuly for
> other reason. I cannot figure out how to resolve this problem.
> Does anyone here have an idea?

Have a log file? I'd need an idea where it loops first.


More information about the MPlayer-dev-eng mailing list