Hap Alpha video not working on AMD graphics card about ofxhapplayer

[tobiasebsen]

A bit more investigation reveals that glCompressedTexSubImage2D fails with GL_INVALID_OPERATION.

I have also checked the list of supported compression formats using glGet GL_COMPRESSED_TEXTURE_FORMATS and it does indeed include GL_COMPRESSED_RGBA_S3TC_DXT5_EXT

[bangnoise]

Strange - AMD drivers up to date? Does this also happen with the ofxHapPlayer example app on the affected machine?

[tobiasebsen]

Yes. It's a new computer with most recent drivers installed. And the issues is the same with the example app.

[sunekastbjerg]

I'm having the same strange issue. The issue only happens on AMD cards (i tried an RX 480 and R9 290), and it has not been an issue with the last versions of ofxHapPlayer. I have found that it is fixed by making the video dimensions divisible by 4. I had a 985 x 574 video that works fine on AMD cards if i scale it to 984 x 572. If i just make the dimensions even, it does not work.

[bangnoise]

@sunekastbjerg ah - OK, helpful to know it works for multiples of 4. Could you try the following change to ofxHapPlayer.cpp, lines 546 onwards:

#if OFX_HAP_HAS_CODECPAR
            ofxHapPY::roundUpToMultipleOf4(_videoStream->codecpar->width),
            ofxHapPY::roundUpToMultipleOf4(_videoStream->codecpar->height),
#else
            ofxHapPY::roundUpToMultipleOf4(_videoStream->codec->width),
            ofxHapPY::roundUpToMultipleOf4(_videoStream->codec->height),
#endif

Then try playing an odd-dimensioned movie and report back. Thanks!

[bangnoise]

just for clarity, the full function call there becomes

        glCompressedTexSubImage2D(GL_TEXTURE_2D,
            0,
            0,
            0,
#if OFX_HAP_HAS_CODECPAR
            ofxHapPY::roundUpToMultipleOf4(_videoStream->codecpar->width),
            ofxHapPY::roundUpToMultipleOf4(_videoStream->codecpar->height),
#else
            ofxHapPY::roundUpToMultipleOf4(_videoStream->codec->width),
            ofxHapPY::roundUpToMultipleOf4(_videoStream->codec->height),
#endif
            internalFormat,
            static_cast<GLsizei>(_decodedFrame.buffer.size()),
            _decodedFrame.buffer.data());

[sunekastbjerg]

Thanks for the fast response! I'm getting an GL_INVALID_VALUE from glCompressedTexSubImage2D with those values. Don't we need to resize the buffer as well for that to work?

[bangnoise]

The buffer is correctly sized because DXT data is always in 4x4 blocks even if some of the pixels are beyond the bounds of the image (drivers are expected to be able to handle odd widths in glCompressedTexSubImage2D, so this is a driver bug).

We probably need to allocate the texture with the same rounded dimensions - but we don't want OF to start drawing the full texture either. See if it works if you perform the same rounding at lines 513 onwards where we set the texture's dimensions - it's not a solution because you'll also see the extra pixels when you draw the texture, but we can force that if we discover this works.

[tobiasebsen]

There is also the coded_width and coded_height parameters to reveal the actual dimensions of the data. They should be the same as multiple of four, but coded dimensions are more correct, right?

[bangnoise]

@tobiasebsen from AVCodecContext? We don't have one for the video stream.

[sunekastbjerg]

The buffer is correctly sized because DXT data is always in 4x4 blocks even if some of the pixels are beyond the bounds of the image (drivers are expected to be able to handle odd widths in glCompressedTexSubImage2D, so this is a driver bug).

We probably need to allocate the texture with the same rounded dimensions - but we don't want OF to start drawing the full texture either. See if it works if you perform the same rounding at lines 513 onwards where we set the texture's dimensions - it's not a solution because you'll also see the extra pixels when you draw the texture, but we can force that if we discover this works.

Just tried that out, and it seems to work with the odd sized textures when the allocation is rounded up to multiples of 4 as well. Thanks! :)

[tobiasebsen]

@bangnoise you could just set the _texture.texData.width and _texture.texData.height to the non-rounded values after texture allocation to avoid drawing the extra pixels.

[tobiasebsen]

... and, of cause, scale the tex_t and tex_u accordingly.

[tobiasebsen]

#63 Like this ?

[sunekastbjerg]

Yes that is what i tried and it works on an AMD R9 290 at least. :)

[bangnoise]

Fixed in #63 - thanks @tobiasebsen