baseparse: tearing/jitter artifacts with h265 decoding use-case (regression)
With the attached input yuv bluesky.tbz2, the following decode use-case introduces tearing around frame 133, then skips backwards a few frames. During the decode command, I observed that the pipeline also stalls momentarily (dmesg reports gpu hang, too). If I revert all recent baseparse changes up to and including e906197c, then the decode issue disappears. (related #530 (closed)).
export LIBVA_DRIVER_NAME=i965 gst-launch-1.0 -vf filesrc location=./1080p_blue_sky_1920x1080_I420.yuv \ ! rawvideoparse format=i420 width=1920 height=1080 framerate=30 \ ! vaapih265enc rate-control=cbr keyframe-period=30 num-slices=4 \ max-bframes=2 bitrate=8000 tune=none \ ! video/x-h265,profile=main ! h265parse \ ! filesink location=bluesky.h265 gst-launch-1.0 -vf filesrc location=./bluesky.h265 \ ! h265parse ! vaapih265dec \ ! videoconvert dither=0 ! video/x-raw,format=I420 \ ! checksumsink2 dump-output=true qos=false dump-location=bluesky-decoded.yuv
Regression started at:
commit e906197c622725e48b6250a71a922d45b006fb14 Author: Jan Schmidt <email@example.com> Date: Wed Apr 1 02:36:40 2020 +1100 baseparse: Fix upstream read caching When running in pull mode (for e.g. mp3 reading), baseparse currently reads 64KB from upstream, then mp3parse consumes typically around 417/418 bytes of it. Then on the next loop, it will read a full fresh 64KB again, which is a big waste. Fix the read loop to use the available cache buffer first before going for more data, until the cache drops to < 1KB. Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/518