A Pythonic library for Nvidia Codec.
The project is still in active development; expect breaking changes.
Why another Python library for Nvidia Codec?
Comparison to Video-Processing-Framework
- VPF is written fully in C++ and uses
pybindto expose Python interfaces. PNC is written fully in Python and uses
ctypesto access Nvidia C interfaces. Our codes tends to be more concise, less duplicative and easier to read and write.
- Preliminary tests shows little to no difference in terms of performance, because the heavy lifting is done on the GPU anyway. Both library can saturate GPU decoder. PNC uses more CPU than VPF as expected from Python vs. C++, but still negligible (less than 10% of Ryzen 3100 single core for 8K*4K HEVC)
- Resource Management
- In VPF
Surfacegiven to user are not owned by the user. It will be overwritten by new frames which is counter-intuitive;
Pictureare not exposed to user at all – they are always mapped (post-processed and copied) to
Surfaceso the picture can be ready for new frames. The latter is inefficient when only a subset of
Picturesare needed (e.g. screenshots).
- The above is because VPF allocates the bare minimum of resources needed for most decoding tasks. PNC allows the user to specify the amount of resources to be allocated for advanced applications. Users own the resources and decide when and whether to deal with them.
- Managing resources is not painful: similar to
pycuda, we shift the burden of managing host/device resources to the Python garbage collector. Resources (such as
Surface) are automatically freed when the user drops the reference.
- In VPF
Things to come
- TODO Cropping and scaling support in postprocessing
- TODO Color space conversion from YUV (bt. 601/709, full-range/limit-range) to RGB using
Many thanks to @rarzumanyan for all the helps and explanations!