Design Proposal for Video Sequencer (VSE) Proxy System
Design Proposal for Video Sequencer Proxy System
Reason:
- Current proxy setup has so much options for just a simple task.
- It is slow.
Here is an addon we have created just to show some ideas how it may work. But C implementation would work more efficiently.
Which Features:
Global Proxy Folder:
- This is easier to maintain. Deleting/Cleanup is also simple.
- Reusable proxy setup. These proxies can be reused in new projects.
- We are using custom proxy directory for detecting the proxy.
- Preference has a delete proxy operator to delete the whole proxy in one click.
Ability to create proxy in library bin (in our case in File Browser).
Ffmpeg Command:
We are using this command for building proxy:
ffmpeg -i input.mp4 -vf scale=640:-2 -vcodec libx264 -g 1 -bf 0 -vb 0 -crf 20 -preset veryfast -acodec aac -ab 128k out.avi
- This will create intraframes in h264 within an AVI container with a fixed width of 640 preserving aspect ratio.
- Fixed ratio of 640:-2 ("-:2" is needed for x264 to use the scale filter which needs to be divisible by 2)
Details: ffmpeg.org/ffmpeg-filters.html
Reasons we are using fixed width of 640 preserving aspect ratio are:
-
It's straight forward. No need to make decision for variable size for a simple proxy operation.
-
Mixed media like HD and 4k can be used together with the same quality.
-
The interface can fit 640 width nicely.
-
Industry is going for 4k and 4k+. Where 25% proxy creates a huge file size of 960x540 for example.
-
Variable scaling also affects the encoding speed and frame blending.
-
We are using CRF for the image quality and file size instead.
7 Comments
Currently there are several proxy refactoring patches waiting to get committed. So something will happen to the proxy code, however it seems the argument of backward compatibility stops serious steps towards simplifying proxy handling and UI. developer.blender.org/search/query/ds4PgwciQHWg/ In 2.90 there is now a proxy menu which contains the holy trinity of VSE proxies: setup(add proxy flags to selected), Build(render selected), View(set proxy view resolution). With these 3 put together it is simpler, but the panel is still a mess. Here are some of my other attempts to redesign the proxy UI: devtalk.blender.org/t/design-proposal-proxy-use-in-the-video-sequence-editor/12065 And a patch: developer.blender.org/D6077 Rewriting and improving the cache seems to be prioritized higher and thought of as a replacement for proxies, but that isn't correct, imo. So doing a good proxy add-on, like you have done, is properly the best short-term approach. Btw. I left you a few improvement ideas on GitHub.
* @ tintwotin * And I've notified the author in the youtube comments to ensure he sees it ;)
In general I agree with most things you propose. I've had similar discussion recently and mostly agreed on having proxy settings in user preferences with sane defaults with automatic building when you add movie strip.
Main issues from developers point of view are that proxy system is shared with movie clip editor, which isn't so big problem, but it would be relatively big change to make it more universal. That is support more resolutions and codecs and what not.
Bigger issue is speed. We use ffmpeg to transcode movies, but I guess this process is limited to single threaded performance. I personally lack good ffmpeg API knowledge, so I can't really tell how much work it would be to change this. I use small command line script to generate proxies in my video projects so I know that it is not ideal. I want to finish 2 bigger changes (timeline library and fast image processing) before I start looking into ffpmeg performance. Reason is that you build proxies once for project, then it is fast, but during editing you need to be able to preview your changes constantly. I have implemented disk cache to do just that, but it is not a proper solution long term.
I don't really have any plan to work on implementing these changes currently but I am willing to review code if somebody decides to contribute (just talk to me first before putting in a lot of work).
* @richardantalik * FFMPEG has a multi-thread argument, and if I'm not mistaken and everything is hooked up correctly, it should just do that by default unless told otherwise. That's my understanding.
Any plan to add support for image sequences?
* @simon.p.heggie * Image sequences and it's proxies are supported currently
Great work! Looks much more straightforward than the current system.