GNOME Bugzilla – Bug 781748
One frame delayed in vaapidecode when playing h264.
Last modified: 2017-04-27 06:15:19 UTC
Created attachment 350431 [details] h264 file In the log, DPB size is 1. So I expect to be decoded as soon as IDR slice or non-IDR slice push to vaapidecode. But in the log, vaapidecode doesn't decode a frame when received IDR slice. And then vaapidecode is received 1st non-IDR slice, vaapidecode decode one frame.(I guess this frame is IDR's picture) And then vaapidecode is received 2nd non-IDR slice, vaapidecode decode one frame.(I guess this frame is 1st non-IDR's picture) .... This is repeated. That's why I think that vaapidecode is delayed one frame. This can become the problem in real-time streaming such as Android Auto or Carplay. Because the last frame does not display always when playing. vaapi gstvaapidecoder_h264.c:1037:dpb_reset:^[[00m DPB size 1 vaapi gstvaapidecoder_h264.c:2878:init_picture:^[[00m <IDR> vaapi gstvaapidecoder_h264.c:3697:decode_slice:^[[00m slice (1511 bytes) vaapi gstvaapidecoder_objects.c:241:gst_vaapi_picture_decode:^[[00m decode picture 0x04000000 vaapi gstvaapidecoder_h264.c:3697:decode_slice:^[[00m slice (6 bytes) vaapi gstvaapidecoder_objects.c:241:gst_vaapi_picture_decode:^[[00m decode picture 0x04000001 vaapi gstvaapidecoder.c:378:push_frame:^[[00m push frame 0 (surface 0x04000000) vaapi gstvaapidecoder.c:399:pop_frame:^[[00m pop frame 0 (surface 0x04000000) vaapi gstvaapidecoder_h264.c:3697:decode_slice:^[[00m slice (751 bytes) vaapi gstvaapidecoder_objects.c:241:gst_vaapi_picture_decode:^[[00m decode picture 0x04000002 vaapi gstvaapidecoder.c:378:push_frame:^[[00m push frame 1 (surface 0x04000001) vaapi gstvaapidecoder.c:399:pop_frame:^[[00m pop frame 1 (surface 0x04000001) ....
Created attachment 350432 [details] vaapi*:6 log
Thanks for reporting this. I haven't checked it deeply, but I suspect this is a specific case of bug #762509. I you feel that the problem is the same, can you try the patch posted there and comment you results? If it helps, then we could mark this bug as duplicated.
By the way, attached h264's profile is baseline, which is not supported for current version of gst-vaapi. And the attached log shows the version of gst-vaapi is 0.5.8 I think, we need to make sure that this issue is still available on the master.
I tested after applying a patch (push frames downstream asap instead of waiting until they're ejected from the DPB) of bug #762509. The result as the vaapidecode had no delay. Thanks.
*** This bug has been marked as a duplicate of bug 762509 ***
(In reply to Hyunjun Ko from comment #3) > By the way, attached h264's profile is baseline, which is not supported for > current version of gst-vaapi. > And the attached log shows the version of gst-vaapi is 0.5.8 > > I think, we need to make sure that this issue is still available on the > master. Yes, please consider that branch 0.5 is not maintained anymore.