[FFmpeg-devel] [PATCH] vdpau: do not use buggy HEVC support by default

[Manoj Bonda]

Hi ,

The bug reported earlier that caused VDPAU-decoded H.265/HEVC content to have interlaced artifacts, when
shared with OpenGL through the GL_NV_vdpau_interop extension is fixed in 410.66 driver release.

As requested in this thread, NVIDIA is now proposing a new interop
extension, where the interop surfaces are frame or field based.
The corresponding VDPAU API change is sent out to VDPAU mailing list for review.

Detailed VDPAU API proposal is available at -
https://lists.freedesktop.org/archives/vdpau/2018-October/000415.html

The proposed new VDPAU OpenGL interop spec (NV_vdpau_inteop2.txt) is available at 
https://github.com/KhronosGroup/OpenGL-Registry/pull/223/files 
for reference.

Please review both the proposals and provide your feedback.

Thanks,
ManojGupta.


-----Original Message-----
From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of wm4
Sent: Friday, August 18, 2017 4:20 PM
To: ffmpeg-devel at ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] vdpau: do not use buggy HEVC support by default

On Tue, 8 Aug 2017 05:15:52 +0000
Manoj Bonda <mbonda at nvidia.com> wrote:

> Hi ,
> 
> HEVC issue for read-back API has been fixed and will be part of the upcoming drivers. 
> Please help us understand the issue with the open gl interop. 

That's great to hear. (Sorry, saw this only now...)

> As per our understanding we are mapping the video surface to gl using 
> the gl-interop and the app(mpv) will be doing the merging/de-interlacing part.
> 
> As per our understanding, in mpv we see merging/de-interlacing is 
> being done using shader at
> 
> Call stack:
>                gl_sc_generate() at utils.c:1,162 0x565daa            
>                finish_pass_direct() at video.c:1,115 0x569cb2    
>                reinterleave_vdpau() at video.c:3,031 0x57277a 
>                pass_upload_image() at video.c:3,079 0x572b6b                
>                pass_render_frame() at video.c:2,506 0x570162 
>                gl_video_render_frame() at video.c:2,877 0x571ce9         
>                draw_frame() at vo_opengl.c:133 0x57d920         
>                render_frame() at vo.c:817 0x579113      
>                vo_thread() at vo.c:916 0x579610

Yes, the API requires this. But with HEVC the driver returned pretty broken textures.

Here's the extension definition:

https://www.khronos.org/registry/OpenGL/extensions/NV/NV_vdpau_interop.txt

It contains this as part of a table:

      VDP_CHROMA_TYPE_420  4                0      w   x h/2  R8        Top-field luma
                                            1      w   x h/2  R8        Bottom-field luma
As you can see, the API _always_ returns video as separate fields. The top field consists of all even lines, while the bottom field of all odd lines (or maybe it was the other way around).

But with HEVC, the top field literally returned the top half of the video frame, and bottom field the second half.

But ideally, nvidia would provide a new GL interop extension, which does not require this interlacing nonsense. (It could support high bit depth surfaces too.)

> we are not able to get how ffmpeg is using the vdpau-opengl interop. 
> Please suggest us how to repro vdpau-opengl  interop issue with ffmpeg. 

FFmpeg doesn't use vdpau-opengl interop, so strictly speaking this discussion is offtopic here. What we saw for readback was pretty similar to what we saw on the textures, though.

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel at ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel