[MPlayer-dev-eng] Pixelformat negotiation
D Richard Felker III
dalias at aerifal.cx
Fri Apr 30 00:25:31 CEST 2004
On Thu, Apr 29, 2004 at 11:51:13PM +0200, Jiri Svoboda wrote:
> Hi,
> on directfb list was question why YV12 format is supported mga g200 by
> mga_vid and not by vo_directfb. While digging in the logs and source I've
> found following.
> Support of YV12 on g200 in mga_vid is done in software by converting it to
> YUV2 by the driver.
It's not converted to YUY2. It's converted to a format commonly known
at NV12 (thanks to nvidia) or packed chroma planes. Unlike YUY2, it's
no bigger than YV12. The luma plane is still independent while the
chroma planes are packed together as one.
BTW, it's possible to optimize this heavily for direct rendering, but
MPlayer doesn't...
> I was wondering why also mplayer does not this
> connvertion in conjuction with diretfb and falls to RGB. So I've loooked and
> log and found that during negotiation of csp mplayer does not bother with
> anything else than YV12 nad than by RGB with swscaler.
>
> So my question is why in case that codec supports only YV12 and vo_drier not
> we imediately fall back to RGB using swscaler? Wouldn't it be better to try
> at first other YUV formats? This could save some proccessor time - YUV ->
> YUV conversion is faster than conversion to RGB.
>
> This could be done by two ways:
> - by automatic inserting of vf_yuy2 or similar filter in the same manner
> vf_scale is inserted
vf_yuy2 does fast but incorrect conversion. vf_ilpack is the correct
yv12->yuy2 converter, and vf_scale is better if you're sure the video
isn't interlaced. But you'd be better off to add NV12 support.
> - by favorising YUV formats in vf_scale in case of YUV format on input
> instead of RGB ones
Wasn't this change already made?
Rich
More information about the MPlayer-dev-eng
mailing list