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

[wm4]

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.