-
The vaCreateContext do not need to specify the surfaces for the context creation now. So we do not need to bind any surface to the context anymore. Surfaces should be the resource belong to display and just be used in encoder/decoder context. The previous manner has big limitation for decoder. The context's surface number is decided by dpb size. All the surfaces in dpb will be attached to a gstbuffer and be pushed to down stream, and the decoder need to wait down stream free the surface and go on if not enough surface available. For more and more use cases, this causes deadlock. For example, gst-launch-1.0 filesrc location=a.h264 ! h264parse ! vaapih264dec ! x264enc ! filesink location=./output.h264 will cause deadlock and make the whole pipeline hang. the x264enc encoder need to cache more than dpb size surfaces. The best solution is seperating the surfaces number and the dpb size. dpb and dpb size shoule be virtual concepts maintained by the decoder. And let the surfaces_pool in context maintain the re-use of all surfaces. For encoder, the situation is better, all the surfaces are just used as reference frame and no need to be pushed to down stream. We can just reserve and set the capacity of the surfaces_pool to meet the request. Fix: #147 Fix: #88 Co-Author: Víctor Manuel Jáquez Leal <vjaquez@igalia.com> Part-of: <!353>
ac3e8c7c
