- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I decided to test my VPL encoder with portrait rather than landscape resolution data. It failed with 720x1280 resolution due to an access violation writing the surface before submitting to the encoder. I'm using an AV1 encoder with 10 bit input (MFX_FOURCC_P010).
I'm using an Intel Arc 380 (31.0.101.5085) and my CPU is an AMD 3900X. My VPL SDK version is 2023.1.0. I'm using Windows 11 (23H2).
The surface should be 16 bit words, semi-planar (10 bits only used in each word). Therefore the following to fill the luma (for example):
{
auto * luma = reinterpret_cast<uint16_t *>(encode_surface->Data.Y);
auto luma_height = encode_surface->Info.Height;
for (auto y = 0; y < luma_height; y++, luma += encode_surface->Data.Pitch / sizeof(uint16_t) /* our pointer is to uint16_t, pitch is in bytes */)
{
for (auto x = 0; x < encode_surface->Info.Width; x++)
{
luma[x] = 0x1234;
}
}
}
and the following to fill the chroma, which should be half the height of the luma (half the size width and height, however P010 is interleaved U and V, so 360 U and 360 V, stored as UVUVUVUV... so 720 words):
{
auto * chroma = reinterpret_cast<uint16_t *>(encode_surface->Data.UV);
auto chroma_height = encode_surface->Info.Height / 2;
for (auto y = 0; y < chroma_height; y++, chroma += encode_surface->Data.Pitch / sizeof(uint16_t) /* our pointer is to uint16_t, pitch is in bytes */)
{
for (auto x = 0; x < encode_surface->Info.Width; x++)
{
chroma[x] = 0xABCD;
}
}
}
Writing the chroma gives an access violation at a strange location, with Y = 601 and X = 32. Given the image is 720 x 1280, I expect the chroma plane to be 720 x 640. The pitch is 1,472 bytes, which is 1,440 rounded up to some appropriate boundary (64 bytes). I am only writing the first 1,440 bytes (720 words) of each row.
Is this a driver/impl bug or have I made a very basic error? The problems I have are often between chair and keyboard!
I have attached a very simple Visual Studio 2022 solution to repro this issue (just requires the SDK installed for the include and library paths and libvpld.dll in the program directory to run). The repo just creates a session and asks it for a surface to encode with, then tries to fill that surface with values. It doesn't load or read or write any image or movie files. It's just lock the surface, writes some values, unlock. It fails writing the chroma.
If you need any further info, please ask.
Additional note 1: I am able to decode 10 bit P010 format previously encoded by an NVIDIA 4080 using VPL so this appears to be a specific issue with encoding.
Additional note 2: I have downsampled my 10 bit to 8 bit before submitting to the encoder and it works fine, i.e. the problem doesn't occur with my 8 bit NV12 frames on the same movie.
Link Copied
![](/skins/images/D3C0B914909A6564BBB97F4AD1ED1973/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page