h265parse: 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 gstreamer@e906197c, then the decode issue disappears. (related gstreamer#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 <jan@centricular.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