IanB
16th January 2007, 23:25
@tsp, As you already know the pitch will be 2 byte aligned in this case, and you will have a lot of unhappy filter users.
Yes you can abuse the privilege of being able to force a pitch but you the filter author are responsible for making sure your filters conform to the expectation of the API.
A filter that subsequently unused 4/16 bytes off the end of it's rows would be quite okay to initially ask for 16 bit alignment as an interim work frame.
Note also! I have said nothing about the alignment of the read/write pointers, this issue is just about the spare space at the end of each row and how it is aligned.
------------------------------------------------------------
:Edit: One point not mentioned above is the effect of the Crop filter and it's internal implementer SubFrame(). This can result in a pitch many times greater than the rowsize.BlankClip(Width=10240, Pixel_Type="YV12")
Crop(0, 0, 16, 0)
# Pitch >= 10240 bytes, rowsize 16 bytes
Yes you can abuse the privilege of being able to force a pitch but you the filter author are responsible for making sure your filters conform to the expectation of the API.
A filter that subsequently unused 4/16 bytes off the end of it's rows would be quite okay to initially ask for 16 bit alignment as an interim work frame.
Note also! I have said nothing about the alignment of the read/write pointers, this issue is just about the spare space at the end of each row and how it is aligned.
------------------------------------------------------------
:Edit: One point not mentioned above is the effect of the Crop filter and it's internal implementer SubFrame(). This can result in a pitch many times greater than the rowsize.BlankClip(Width=10240, Pixel_Type="YV12")
Crop(0, 0, 16, 0)
# Pitch >= 10240 bytes, rowsize 16 bytes