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 774244 - [VP9][decode] get checksum fail.
[VP9][decode] get checksum fail.
Status: RESOLVED NOTABUG
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: 2016-11-11 05:33 UTC by Fei
Modified: 2016-12-02 17:49 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Fei 2016-11-11 05:33:26 UTC
1. Testing Steps:
========================================================================
gst-launch-1.0 filesrc location=/media/VP9Conf700/g2_decoder_case_14201.vp9.webm ! ivfparse ! vaapivp9dec ! vaapipostproc format=i420 ! checksumsink2 file-checksum=TRUE frame-checksum=FALSE

2.Log:
========================================================================
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /opt/X11R7/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
Setting pipeline to PAUSED ...
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /opt/X11R7/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
Pipeline is PREROLLING ...
Got context from element 'vaapipostproc0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayX11\)\ vaapidisplayx11-1";
Redistribute latency...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Redistribute latency...
Redistribute latency...

** (gst-launch-1.0:3832): CRITICAL **: gst_video_frame_map_id: assertion 'info->width <= meta->width' failed
0:00:00.071497532  3832      0x2020ca0 ERROR                default gstchecksumsink.c:385:gst_checksum_sink_render:<checksumsink0> Failed to map frame
**
ERROR:gstchecksumsink.c:386:gst_checksum_sink_render: code should not be reached
Aborted (core dumped)


3. Testing Env:
========================================================================
gst_plugins_vaapi10: (master)d7231f66ccd7b460c3465c4fdff6694813397114
libva:               (master)c4f37b5dc9f092f68a793c52ea169092f0ad6e44
Libva_intel_driver:  (master)db93c4020d9b0aca8472f772e91570a641983c66

4. Frequency of Occurence:
========================================================================
100%
Comment 1 Víctor Manuel Jáquez Leal 2016-11-11 09:21:34 UTC
@Fei, where do you get checksumsink2 element?
Comment 2 Fei 2016-11-14 01:35:48 UTC
(In reply to Víctor Manuel Jáquez Leal from comment #1)
> @Fei, where do you get checksumsink2 element?

@Victor, you can get it from https://github.com/sreerenjb/gst-checksumsink.
Comment 3 Víctor Manuel Jáquez Leal 2016-11-14 13:15:16 UTC
Okey. Thanks!

Can you check if applying the patch in bug 773948 it is solved?
Comment 4 Fei 2016-11-15 01:30:29 UTC
(In reply to Víctor Manuel Jáquez Leal from comment #3)
> Okey. Thanks!
> 
> Can you check if applying the patch in bug 773948 it is solved?

I tried it, but it could't fix this issue.
Comment 5 Víctor Manuel Jáquez Leal 2016-11-15 12:57:56 UTC
This is strange.

The media is rendered with no complains by xvimagesink and xiamgesink, which uses the same mechanism of checksumsink2.

The problem is that the caps reported by getcaps() has different size resolutions from the buffer's meta.

We need to review checksumsink2's code.
Comment 6 Víctor Manuel Jáquez Leal 2016-12-02 17:41:44 UTC
Hi @Fei,

It looks that the problem is not in gstreamer-vaapi, as I said, but in gst-checksumsink2

I revamped gst-checksumsink2:

https://github.com/ceyusa/gst-checksumsink

and it works with this media.

WARNING: I changed a lot the code:

+ it uses GLib checksum facilities instead of calling md5sum command
+ it only stores the raw output once, not twice. If you want to save the raw output, you can control the directory with the envvar TMPDIR
+ now it doesn't collide with the gstreamer's official checksumsink (you can have installed both)
+ potentially more color formats can be negotiated since the planes and frames are extracted using the gstreamer functionality, rather than custom code.
+ it *should* be faster

BUT: i didn't compare the output with more that two files, so be careful.
Comment 7 Víctor Manuel Jáquez Leal 2016-12-02 17:49:24 UTC
I'll close this as a not a bug, since it wasn't a bug in gstreamer-vaapi

Let me know privately if you have problems with this new version of gst-checksumsink.