GNOME Bugzilla – Bug 781142
Seeking can be slow due to surface recreation
Last modified: 2017-06-15 12:00:17 UTC
gstreamer-vaapi seeking in 1.x can be significantly slower than in 0.10 on some hardware (Z530) because the driver takes 40ms to create a surface. We didn't used to recreate the entire decoder and surface pool on a seek, but now do. Attached patches make that faster by adding a reset() method the backend vaapi decoder that keeps the old surface pool around.
Created attachment 349617 [details] [review] Implement decoder reset on flush, rather than recreating Clear decoders out on a flush but keep the same instance, rather than completely recreating them. That avoids unecessarily freeing and recreating surface pools and contexts, which can be quite expensive
Created attachment 349618 [details] [review] h264 decoder: Implement reset() for faster flush Implement a custom reset() function for faster flushes that just clear the reference pictures but don't reallocate the DPB or clear out SPS/PPS
Created attachment 349619 [details] [review] vaapidecode: Don't renegotiate on every flush If caps don't actually change, don't update the decoder and don't set the do_renego flag forcing downstream renegotiation
Thanks Jan! As far as I can see, everything is alright.
Comment on attachment 349617 [details] [review] Implement decoder reset on flush, rather than recreating lgtm
Comment on attachment 349618 [details] [review] h264 decoder: Implement reset() for faster flush lgtm
Comment on attachment 349619 [details] [review] vaapidecode: Don't renegotiate on every flush lgtm
kk