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-boun...@ffmpeg.org> On Behalf Of wm4 Sent: Friday, August 18, 2017 4:20 PM To: ffmpeg-devel@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 <mbo...@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@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
