GNOME Bugzilla – Bug 772259
decoder: h265 : Failing to play a stream occasionally
Last modified: 2017-03-17 08:48:02 UTC
The attached stream (saved from a network source) is causing driver asseertion sometimes. gen9_mfd.c:587: gen9_hcpd_get_reference_picture_frame_id: Assertion `0' failed. Aborted (core dumped) Could be better to do some investigation from gstreamer side first.
Created attachment 336683 [details] sample h265 stream
I'm having consistent assertion on the encode stream from h265 with matroskamux. I'm using the gstreamer-vaapi 1.8.3 version. command: 1. h265 encode command: gst-launch-1.0 filesrc location=/home/root/iceage_720x480_491.yuv ! videoparse width=720 format=i420 framerate=30 height=480 ! vaapih265enc rate-control=cqp ! video/x-h265,profile=main ! h265parse ! matroskamux ! fpsdisplaysink video-sink="filesink location=/home/root/test.mkv" text-overlay=false 2. h265 decode command: gst-launch-1.0 filesrc location=/home/root/test.mkv ! matroskademux ! h265parse ! vaapidecode ! vaapisink The raw stream encoded by using vaapih265enc + matroskamux, the replay back the h265 video stream, it will hitting error assertion causing in gen9_mfd.c:587: gen9_hcpd_get_reference_picture_frame_id: Assertion `0' failed. Aborted (core dumped) Found out the after revert this commit id: dc35dafa1d2d320da0ef8750233e1bf5dec747cc, it is working fine. I'm trying just changed from "encoder->cts_offset = GST_CLOCK_TIME_NONE" back to "encoder->cts_offset = 0", it is working fine. GST_CLOCK_TIME_NONE is -1 value.
Is Lim issue a different one than the reported by Sree a different issue??? Sree, is this assert a consequence of a bad encoding using gstreamer-vaapi? What Lim says make sense and it is my fault. I will change it asap.
Created attachment 337222 [details] [review] encoder: h264,h265: fix regression in offset count In commit dc35dafa a bug was introduced because I assumed that GST_CLOCK_TIME_NONE is zero when is -1. This patch fixes that mistake.
As I don't have a skylake at hand right now, I'm trying to replicate it with H264 in haswell, but I don't see the assert.
(In reply to Víctor Manuel Jáquez Leal from comment #5) > As I don't have a skylake at hand right now, I'm trying to replicate it with > H264 in haswell, but I don't see the assert. Hi Victor, I did run the same test on h264 last week, but I can't reproduce in H264. It only able to consistent reproduce in H265. Once the fixed changed ready, can you please help check in into v1.8 branch? Thank you.
Comment on attachment 337222 [details] [review] encoder: h264,h265: fix regression in offset count Attachment 337222 [details] pushed as ef3ee8b - encoder: h264,h265: fix regression in offset count
(In reply to Víctor Manuel Jáquez Leal from comment #7) > Comment on attachment 337222 [details] [review] [review] > encoder: h264,h265: fix regression in offset count > > Attachment 337222 [details] pushed as ef3ee8b - encoder: h264,h265: fix > regression in offset count Also pushed for branch 1.8
This issue already fixed. Can't reproduce anymore with the code fixes. I think we can close this bugzilla now. Sorry, I forgot to update at here.
Fixed since release 1.10. Closing now.