GNOME Bugzilla – Bug 796625
vaapipostproc: Bob deinterlace doesn't work for raw file.
Last modified: 2018-11-03 15:55:10 UTC
$gst-launch-1.0 -vf filesrc location=1920x1080.nv12 num-buffers=1 ! rawvideoparse format=nv12 width=1920 height=1080 ! vaapipostproc format=nv12 width=1920 height=1080 deinterlace-mode=1 deinterlace-method=bob ! checksumsink2 file-checksum=false frame-checksum=false plane-checksum=false dump-output=true dump-location=bob_NV12_1920x1080.yuv The output yuv have 2 frames, and each frame is bit match with input. But by using yamivpp: $yamivpp --di bob 1920x1080.nv12 1920x1080.bob.nv12 the output only 1 frame, and md5 is different with input.
You forgot set set interlaced=1 on rawvideoparse in order to tall vaapipostproc that the input is interlaced. Can you validate this please ?
(In reply to Nicolas Dufresne (ndufresne) from comment #1) > You forgot set set interlaced=1 on rawvideoparse in order to tall > vaapipostproc that the input is interlaced. Can you validate this please ? Same result with cmd: gst-launch-1.0 -vf filesrc location=1920x1080.nv12 num-buffers=1 ! rawvideoparse format=nv12 width=1920 height=1080 interlaced=1 ! vaapipostproc format=nv12 width=1920 height=1080 deinterlace-mode=1 deinterlace-method=bob ! checksumsink2 file-checksum=false frame-checksum=false plane-checksum=false dump-output=true dump-location=bob_NV12_1920x1080.yuv
@Fei, can you attach the input file?
Created attachment 372720 [details] input file.
(In reply to Víctor Manuel Jáquez Leal from comment #3) > @Fei, can you attach the input file? Hi Victor, I have uploaded it, please check attachment.
Ah, so you wan to use vaapipostproc to interleave a progressive frame, I thought it as the opposite. Obviously, deinterlace-* aren't telling vaapipostproc to do that. @Victor, is that really a supported use case in VAAPI ?
@Nicolas, either way, shouldn't we expect to see some sort of difference on output regardless of "real" yuv details of input?
There is no way to instruct vaapipostproc to interlace a progressive frame as of now. So the output is the same. Try with the interlace element if you are curious.
I may be naive, but should "rawvideoparse format=nv12 width=1920 height=1080 interlaced=1" output interlaced frames for vaapipostproc?
(In reply to U. Artie Eoff from comment #9) > I may be naive, but should "rawvideoparse format=nv12 width=1920 height=1080 > interlaced=1" output interlaced frames for vaapipostproc? It will pretend it's interlaced, but it's not, since the image you provided is progressive. Then you selected a BOB deinterlacer, which I believe is the only one that won't deteriorate the frame. Also, we aware that you need at least 3 fields (2 interleaved frames) in order to use any other algo.
(In reply to Nicolas Dufresne (ndufresne) from comment #10) > (In reply to U. Artie Eoff from comment #9) > > I may be naive, but should "rawvideoparse format=nv12 width=1920 height=1080 > > interlaced=1" output interlaced frames for vaapipostproc? > > It will pretend it's interlaced, but it's not, since the image you provided > is progressive. Then you selected a BOB deinterlacer, which I believe is the > only one that won't deteriorate the frame. Also, we aware that you need at > least 3 fields (2 interleaved frames) in order to use any other algo. So it determines the raw image data is progressive, how? As far as rawvideoparse is concerned, it's just random raw data, right? And it should read the data in terms of how the user specifies. Perhaps it's because the size of data is not enough for 3 fields? Oddly, ffmpeg and yami (same vaapi driver) produce a different result for bob deinterlacer with same input!
(In reply to U. Artie Eoff from comment #11) > (In reply to Nicolas Dufresne (ndufresne) from comment #10) > > (In reply to U. Artie Eoff from comment #9) > > > I may be naive, but should "rawvideoparse format=nv12 width=1920 height=1080 > > > interlaced=1" output interlaced frames for vaapipostproc? > > > > It will pretend it's interlaced, but it's not, since the image you provided > > is progressive. Then you selected a BOB deinterlacer, which I believe is the > > only one that won't deteriorate the frame. Also, we aware that you need at > > least 3 fields (2 interleaved frames) in order to use any other algo. > > So it determines the raw image data is progressive, how? As far as > rawvideoparse is concerned, it's just random raw data, right? And it should > read the data in terms of how the user specifies. Perhaps it's because the > size of data is not enough for 3 fields? Oddly, ffmpeg and yami (same vaapi > driver) produce a different result for bob deinterlacer with same input! That is, ffmpeg-vaapi and yami-vaapi produce very similar outputs. That is, PSNR is 50-60 range for both. But gstreamer-vaapi produces noop output.
I wanna comment about the 2 frames output instead of 1. We always double the framerate (and produce double the number of frames) in gstreamer-vaapi unlike the default option in gst-msdk which won't output double frames. see this comment: https://bugzilla.gnome.org/show_bug.cgi?id=781069#c18
(In reply to Nicolas Dufresne (ndufresne) from comment #6) > Ah, so you wan to use vaapipostproc to interleave a progressive frame, I > thought it as the opposite. Obviously, deinterlace-* aren't telling > vaapipostproc to do that. > > @Victor, is that really a supported use case in VAAPI ? It is only "interlaced to de-interlace".
(In reply to sreerenj from comment #13) > I wanna comment about the 2 frames output instead of 1. > > We always double the framerate (and produce double the number of frames) in > gstreamer-vaapi unlike the default option in gst-msdk which won't output > double frames. > see this comment: https://bugzilla.gnome.org/show_bug.cgi?id=781069#c18 That seems odd, so what shall we expect when vpp deinterlacer this frame ? Two frames ?
Ok, I've run the test in another form: Software: gst-launch-1.0 filesrc location=1920x1080.nv12 ! rawvideoparse format=nv12 width=1920 height=1080 interlaced=1 ! deinterlace method=6 ! multifilesink location="test-%d.nv12" VPP: gst-launch-1.0 filesrc location=1920x1080.nv12 ! rawvideoparse format=nv12 width=1920 height=1080 interlaced=1 ! vaapipostproc format=nv12 width=1920 height=1080 deinterlace-mode=1 deinterlace-method=bob ! multifilesink location="test-vpp-%d.nv12" The software deinterlacer produces 3 images (not sure what is the logic for the). When I view these image, in the snow, I can see that the lines got scale, as the snow is presenting a slightly vertical direction. And indeed, vaapipostproc leaves the frames untouched, not scaled as BoB method is supposed to be. To view the files: gst-launch-1.0 filesrc location=test-2.nv12 ! rawvideoparse format=nv12 width=1920 height=1080 ! imagefreeze ! videoconvert ! gtksink
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/101.