[Bug 110394] Skylake GPU HANG while gstreamer H264 vaapi encoding from MJPEG vaapi decode on drm-tip

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=110394

--- Comment #59 from Andy Nicholas <andy.nicholas at shield.ai> ---
Ideally, I would be able to setup a video pipeline so that the jpeg frames
could be decoded using VAAPI into main memory, modified, then encoded using
VAAPI to H264. That is what the previous gstreamer script accomplishes.

At this point I am looking for some kind of fallback position where I could
take the jpeg frames and invoke the GPU less to reduce the chance of crashing.
So I'm willing to take the CPU reduction to have the CPU decode the JPEG
frames, but the GPU would need to encode the H264 stream.

I did this with the script below and, unfortunately, the crashes still occur.
Software jpeg decode is being paired with hardware H264 encode. I've only been
running for less than 1 hour and 2 compute sticks have already crashed.

Not sure how I'm going to proceed because it looks like the only way to
work-around this issue is to disable RC6. Maybe I can try to reduce the size of
the movie and see if a more minimal size can reproduce the problem.


#!/usr/bin/env bash

set -ex

tcount=0
while true; do
        echo "Transcode: iteration $tcount" | tee tcount.txt

        # remove old output
        rm -f /tmp/transcode-output.mp4

        # transcode using gstreamer
        time gst-launch-1.0 filesrc location=mjpeg-outside-640x480.mkv ! \
                matroskademux ! \
                queue ! \
                jpegdec ! \
                videoconvert ! \
                videoscale ! \
                "video/x-raw,width=640,height=480,framerate=(fraction)30/1" ! \
                queue ! \
                vaapih264enc ! \
                mp4mux ! \
                filesink location=/tmp/gst-output.mp4

        tcount=$((tcount+1))    
done

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20190419/88cd0426/attachment.html>