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

[Xidorn Quan]

On Fri, Aug 17, 2012 at 2:22 PM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de>wrote:

> 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?
>

FFmpeg just passes the data from VDA directly to the player.
All hardware accelerations which implemented as HWAccel in FFmpeg
are working this way. To make these code in FFmpeg, we need to
implement another decoder in FFmpeg, and that might cause another
addition data copying.

In fact I did implement the VDA decoder directly in FFmpeg several
weeks ago, but developers for FFmpeg thought that FFmpeg had
provided proper interface for player to use, and implementing decoder
independently made code bloat. I think they might be right because
there are many other things to do in decoding H.264 video other than
decoding frames which the VDA only provides.


> 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).
>

Sorry but I'm not familiar with vo_gl. I found that vo_corevideo
always copys data from the provided mp_image to the buffer created by
itself. Except sharing buffer with other program, I have no idea
about it either.


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

I know why it loops. The initialization of VDA is now in init_vo
so when it is called, it have been too late to find the error since
the codec have been initialized successfully. I think I should move
the initialization code from init_vo to init in vd_ffmpeg and let it
break the initialization process if it fails.

Regards,
Xidorn Quan