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 748417 - vp8enc: valgrind errors when encoding
vp8enc: valgrind errors when encoding
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-04-24 15:03 UTC by Guillaume Desmottes
Modified: 2018-05-07 08:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Guillaume Desmottes 2015-04-24 15:03:11 UTC 
I'm getting a lot of those errors when running the validate.http.transcode.to_vorbis_and_vp8_in_webm.raw_h264_1_mp4 with valgrind.

==11145== Conditional jump or move depends on uninitialised value(s)
==11145==    at 0x11CCCAE7: vp8_regular_quantize_b_sse4_1 (in /tmp/bah/lib/libvpx.so.2.0.0)
==11145==    by 0x11CC3155: macro_block_yrd (in /tmp/bah/lib/libvpx.so.2.0.0)
==11145==    by 0x11CC628C: evaluate_inter_mode_rd.isra.8 (in /tmp/bah/lib/libvpx.so.2.0.0)
==11145==    by 0x11CC8603: vp8_rd_pick_inter_mode (in /tmp/bah/lib/libvpx.so.2.0.0)
==11145==    by 0x11C9C646: vp8cx_encode_inter_macroblock (in /tmp/bah/lib/libvpx.so.2.0.0)
==11145==    by 0x11C9D223: encode_mb_row (in /tmp/bah/lib/libvpx.so.2.0.0)
==11145==    by 0x11C9D5BE: vp8_encode_frame (in /tmp/bah/lib/libvpx.so.2.0.0)
==11145==    by 0x11CB6D5F: encode_frame_to_data_rate (in /tmp/bah/lib/libvpx.so.2.0.0)
==11145==    by 0x11CBA8DB: vp8_get_compressed_data (in /tmp/bah/lib/libvpx.so.2.0.0)
==11145==    by 0x11C964CB: vp8e_encode.part.8 (in /tmp/bah/lib/libvpx.so.2.0.0)
==11145==    by 0x11C7327F: vpx_codec_encode (in /tmp/bah/lib/libvpx.so.2.0.0)
==11145==    by 0x11A608BA: gst_vp8_enc_handle_frame (gstvp8enc.c:2038)
==11145==    by 0x556FAF6: gst_video_encoder_chain (gstvideoencoder.c:1380)
==11145==    by 0x4C2C098: gst_validate_pad_monitor_chain_func (gst-validate-pad-monitor.c:2008)
==11145==    by 0x5A67503: gst_pad_chain_data_unchecked (gstpad.c:4038)
==11145==    by 0x5A67503: gst_pad_push_data (gstpad.c:4271)
==11145==    by 0x57D4CC4: gst_base_transform_chain (gstbasetransform.c:2281)
==11145==    by 0x4C2C098: gst_validate_pad_monitor_chain_func (gst-validate-pad-monitor.c:2008)
==11145==    by 0x5A67503: gst_pad_chain_data_unchecked (gstpad.c:4038)
==11145==    by 0x5A67503: gst_pad_push_data (gstpad.c:4271)
==11145==    by 0x1247BF0A: gst_video_rate_transform_ip (gstvideorate.c:1211)
==11145==    by 0x57D431A: gst_base_transform_handle_buffer (gstbasetransform.c:2133)

I can reproduce using libvpx-1.3.0-6.fc21.x86_64 and libvpx master but not using vpxenc.
Maybe libvpx expect a specific size of buffer or something?
Comment 1 Tim-Philipp Müller 2015-04-24 15:15:37 UTC 
With the exact same input? It might just 0 out input buffers beforehand.

Do you have a simplified test gst-launch pipeline to reproduce this?

It might just be an optimisation in libvpx.
Comment 2 Guillaume Desmottes 2015-04-27 09:36:02 UTC 
Interesting, I can reproduce with "filesrc location=raw_h264.1.mp4 ! qtdemux ! h264parse ! avdec_h264 ! vp8enc ! webmmux ! filesink location=out" but not with "videotestsrc num-buffers=128 ! vp8enc ! webmmux ! filesink location=out"
Comment 3 Vivia Nikolaidou 2018-05-06 10:57:09 UTC 
Does this still happen?
Comment 4 Guillaume Desmottes 2018-05-07 08:00:04 UTC 
Yes. Plenty of "uninitialised" errors when running the pipeline above but none with videotestsrc.
Comment 5 Tim-Philipp Müller 2018-05-07 08:08:48 UTC 
Do you plan to look into this? I don't think it makes sense to keep this open if not. It's unclear there is really a problem here, or if it's GStreamer-side.
Comment 6 Guillaume Desmottes 2018-05-07 08:44:20 UTC 
Not in the short term so let's close it then.