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. 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
> 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
> Please help us understand what needs to be done from our side for
> resolving this issue. Please do let us know if any our understandings
> are wrong.
It's the same issue. The GL interop API returns video data as fields, so
the field splitting for hevc is done incorrectly, just as it was
incorrect for the read-back API. Presumably, depending on how the driver
code is written, you may have needed to fix only a single spot, but I'm
guessing you probably need to fix the GL case separately, given that
fixing the vdpau mixer didn't fix either of the other two paths.
There is no repro with ffmpeg as it does not use the GL interop.
The mpv code does field merging, but that is what any client using
vdpau gl interop would do. You could reproduce this in any client.
And just because we're discussing this, we'd all love it if there was a
new mode where the interop surfaces were frame, rather than field based.
ffmpeg-devel mailing list