After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 796625 - vaapipostproc: Bob deinterlace doesn't work for raw file.
vaapipostproc: Bob deinterlace doesn't work for raw file.
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer-vaapi
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-06-19 04:45 UTC by Fei
Modified: 2018-11-03 15:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
input file. (2.97 MB, application/octet-stream)
2018-06-19 05:51 UTC, Fei
Details

Description Fei 2018-06-19 04:45:53 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.
Comment 1 Nicolas Dufresne (ndufresne) 2018-06-19 04:50:06 UTC
You forgot set set interlaced=1 on rawvideoparse in order to tall vaapipostproc that the input is interlaced. Can you validate this please ?
Comment 2 Fei 2018-06-19 05:02:52 UTC
(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
Comment 3 Víctor Manuel Jáquez Leal 2018-06-19 05:45:27 UTC
@Fei, can you attach the input file?
Comment 4 Fei 2018-06-19 05:51:29 UTC
Created attachment 372720 [details]
input file.
Comment 5 Fei 2018-06-19 05:52:33 UTC
(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.
Comment 6 Nicolas Dufresne (ndufresne) 2018-06-19 06:06:51 UTC
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 ?
Comment 7 U. Artie Eoff 2018-06-19 18:26:59 UTC
@Nicolas, either way, shouldn't we expect to see some sort of difference on output regardless of "real" yuv details of input?
Comment 8 Nicolas Dufresne (ndufresne) 2018-06-19 18:58:25 UTC
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.
Comment 9 U. Artie Eoff 2018-06-19 20:44:40 UTC
I may be naive, but should "rawvideoparse format=nv12 width=1920 height=1080 interlaced=1" output interlaced frames for vaapipostproc?
Comment 10 Nicolas Dufresne (ndufresne) 2018-06-19 23:11:26 UTC
(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.
Comment 11 U. Artie Eoff 2018-06-20 00:56:14 UTC
(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!
Comment 12 U. Artie Eoff 2018-06-20 01:08:15 UTC
(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.
Comment 13 sreerenj 2018-06-20 02:56:29 UTC
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
Comment 14 sreerenj 2018-06-20 02:58:15 UTC
(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".
Comment 15 Nicolas Dufresne (ndufresne) 2018-06-20 14:52:44 UTC
(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 ?
Comment 16 Nicolas Dufresne (ndufresne) 2018-06-21 01:04:58 UTC
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
Comment 17 GStreamer system administrator 2018-11-03 15:55:10 UTC
-- 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.