YV12/YVU9/etc and odd width and/or height

[Andrew Voznytsa]

Hi All,

I'm working on DirectShow filter (transform filter, some input format to
YUV output conversion) and need to display YV12(and others) in case of
odd width and height. After some time I got this working on my system
(Win XP, DirectX 9, Radeon 9200 SE), but solution is a bit tricky. I
know, the best way to get it working everywhere is to crop/resize
picture to the nearest even width/height, but in my case it's not good
solution.
So, I'd like to know if there is any spec which describes how DirectX
compatible drivers should handle YV12/YVU9/etc in case of odd width and
height (I'd like to be sure that my software will work with any DirectX
compatible software/hardware).

Best regards,
Andrew Voznytsa

P.S.
If you wish you may contact me by email, remove _no_spam_ from my email
address.

[Gabest]

I don't think these formats are valid with odd width/height, it's like you
wanted to draw a triangle with two sides only.

Post by Andrew Voznytsa
Hi All,
I'm working on DirectShow filter (transform filter, some input format to
YUV output conversion) and need to display YV12(and others) in case of
odd width and height. After some time I got this working on my system
(Win XP, DirectX 9, Radeon 9200 SE), but solution is a bit tricky. I
know, the best way to get it working everywhere is to crop/resize
picture to the nearest even width/height, but in my case it's not good
solution.
So, I'd like to know if there is any spec which describes how DirectX
compatible drivers should handle YV12/YVU9/etc in case of odd width and
height (I'd like to be sure that my software will work with any DirectX
compatible software/hardware).
Best regards,
Andrew Voznytsa
P.S.
If you wish you may contact me by email, remove _no_spam_ from my email
address.

[Andrew Voznytsa]

You are right (from historic point of viev). YUV came from TV where
custom resolutions are unsupported and therefore problem does not exist.
But DirectX/Video renderers support odd width and height in case of
YV12/etc. If they support this then there should be way to draw those
formats correctly. I'd like to know if DirectX spec standardizes such
cases or no. If yes, then how to calculate offsets to U/V planes and how
data (in last odd lines/pixels) is interpreted.

For example:
ATI Radeon 9200 SE, YV12, odd width and height:
a) Y pointer is calculated as usual
b) V just after Y, width of V is calculated as (Y width + 1) / 2, height
= (Y height + 1) / 2, but last line of V plane has width (Y width + 1) /
4 because (as I think) each V sample are shared with 4 Y samples of last
Y line.
c) U plane comes just after V. Data is interpreted in the same way as V.

I don't want to spend my time checking if all cards/drivers/whatever
works in this way. I'd like to know how this _shall_ work from DirectX
point of view. Can anyone help?

Post by Gabest
I don't think these formats are valid with odd width/height, it's like you
wanted to draw a triangle with two sides only.

Post by Andrew Voznytsa
Hi All,
I'm working on DirectShow filter (transform filter, some input format to
YUV output conversion) and need to display YV12(and others) in case of
odd width and height. After some time I got this working on my system
(Win XP, DirectX 9, Radeon 9200 SE), but solution is a bit tricky. I
know, the best way to get it working everywhere is to crop/resize
picture to the nearest even width/height, but in my case it's not good
solution.
So, I'd like to know if there is any spec which describes how DirectX
compatible drivers should handle YV12/YVU9/etc in case of odd width and
height (I'd like to be sure that my software will work with any DirectX
compatible software/hardware).
Best regards,
Andrew Voznytsa
P.S.
If you wish you may contact me by email, remove _no_spam_ from my email
address.

[Tim Roberts]

Post by Andrew Voznytsa
You are right (from historic point of viev). YUV came from TV where
custom resolutions are unsupported and therefore problem does not exist.

That's too much of an oversimplification. All of the original Video For
Windows codecs used YUV internally, because of the ability to subsample the
less important chroma parts. They all supported variable widths and
heights. Most of them required the width to be a multiple of 4. Indeo (up
through 4.x) required width and height to be a multiple of 16.

Post by Andrew Voznytsa
But DirectX/Video renderers support odd width and height in case of
YV12/etc.

I don't think you will ever find one that does. It's in the definition of
the formats. YUY2 and UVYV are DEFINED as requiring an even width. YV12
requires an even width and an even height.

Post by Andrew Voznytsa
If they support this then there should be way to draw those
formats correctly. I'd like to know if DirectX spec standardizes such
cases or no.

Yes, it is standardized: not supported.

Post by Andrew Voznytsa
I don't want to spend my time checking if all cards/drivers/whatever
works in this way. I'd like to know how this _shall_ work from DirectX
point of view. Can anyone help?

If the Radeon driver actually supports it, it is a bug in the Radeon
driver. However it actually works is just an accident. Don't do it. Your
application should not request an odd width for a YUV format.

Even if you did, no one would ever want it. It is silly to waste your time
worrying about it. People want 320x240, 352x288, 640x480, 768x576,
800x600, etc. They simply do not want 393x277.

[Andrew Voznytsa]

Post by Tim Roberts

Post by Andrew Voznytsa
If they support this then there should be way to draw those
formats correctly. I'd like to know if DirectX spec standardizes such
cases or no.

Yes, it is standardized: not supported.

Thanks for the answer, can you give some link to/name of the standard?

Post by Tim Roberts

Post by Andrew Voznytsa
I don't want to spend my time checking if all cards/drivers/whatever
works in this way. I'd like to know how this _shall_ work from DirectX
point of view. Can anyone help?

If the Radeon driver actually supports it, it is a bug in the Radeon
driver. However it actually works is just an accident. Don't do it. Your
application should not request an odd width for a YUV format.
Even if you did, no one would ever want it. It is silly to waste your time
worrying about it. People want 320x240, 352x288, 640x480, 768x576,
800x600, etc. They simply do not want 393x277.

Not sure. If someone used my encoder to recompress (for example)
c:\windows\clock.avi (321x321) "as is" (no cropping, resizing) then my
decoder should decompress it to the same resolution. To do this I can
(and I'll) disable YUV and use RGB as output format. But colorspace
conversion is not very cheap operation and I decided to check if it is
possible to use some YUV (this is codec's native format)... Looks like
no chances..

[Tim Roberts]

Post by Andrew Voznytsa
Not sure. If someone used my encoder to recompress (for example)
c:\windows\clock.avi (321x321) "as is" (no cropping, resizing) then my
decoder should decompress it to the same resolution.

If you recompressed that with Cinepak, the compressed file would be
324x322, and would uncompress to the same size. It's entirely reasonable.