Grigori Goronzy wrote:
On 29.08.2014 12:31, Andy Furniss wrote:
As for that 4:2:2 "doesn't work", AFAICT it absolutely does, but
there is no linear interpolation for chroma, so quality isn't ideal.
This seems to be a hardware restriction, unfortunately.
Hmm, we may have to disagree on the definition of working here :-)
Of course I don't understand the hardware - but are you saying that
because the chrome needs horizontal interpolation you have to have
vertical interpolation too?
No, I just observed that there is no linear interpolation horizontally.
I.e. the exact same chroma value is used for two pixels of the same block.
Ahh, I have seen and mentioned that one long ago, but compared to the
vertical issue it's less noticable to me - still be nice to have
working, though.
Tests were 1:1 vertical scale.
With weave shader a test pattern rgbymc 422 chroma looked much like it
would if I had used ffmpeg to convert to it 420 (ie none of those at all
rendered). On real video it bled between fields, so my use case of
feeding it to a TV to deinterlace would fail - luma was OK.
Hmm - where can I find this test pattern?
lines-576.png is a version with black and white as well.
lines-all.png is the result of me using your mpv command with --loop=inf
and taking an xwd for analysis.
I notice that on this one luma does get slightly borked also.
https://drive.google.com/folderview?id=0BxP5-S1t9VEEOGNKUHdDcUEtQ1U&usp=drive_web
Also there is a "real" test, snook-ilpack.png is master and again
snook-all is the result.
This one is of interest because as you can see the chroma on the weave
has bled between fields.
This will be noticeable when deinterlaced.
I didn't zoom it on the all, but the luma on the white ball is still
correct WRT fields, hence me thinking luma was OK previously.
Looking closely it is tinted green a bit.
I just made a simple test pattern myself: http://i.imgur.com/hsLFBxy.png
I displayed it in mpv with the following command line:
mpv --vo=vdpau --vf=format=uyvy422 422-chroma.png
I clearly see separate chroma for each line, but chroma cositing seems
to be a bit off, i.e. chroma is shifted downwards by about half a pixel.
That doesn't happen with forced progressive mode. So this is most
probably it.
Yea, your test doesn't show it quite as well, but there are new colours
there.
I guess the 1/2 pix error is to blame - can it be fixed?
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
