Media (Intel® Video Processing Library, Intel Media SDK)
Access community support with transcoding, decoding, and encoding in applications using media tools like Intel® oneAPI Video Processing Library and Intel® Media SDK
Announcements
The Intel Media SDK project is no longer active. For continued support and access to new features, Intel Media SDK users are encouraged to read the transition guide on upgrading from Intel® Media SDK to Intel® Video Processing Library (VPL), and to move to VPL as soon as possible.
For more information, see the VPL website.
3058 Discussions

Access violation writing P010 ten bit format chroma.

RobinsonUK
New Contributor I
367 Views

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.

0 Kudos
0 Replies
Reply