This patch series introduces the new API that was discussed in my previous series, and starts working towards a new, graph-based scaler dispatch mechanism. This currently piggybacks off of existing swscale logic, but I plan on incrementally rewriting the high-level innards going forwards.
In order te preserve backwards compatibility, and to provide a clear migration path, the old type names and API functions are still accessible, and the new implementation is hidden inside the same SwsInternal struct. This allows us to reclaim the same symbol name while only wasting around 40 kB of memory per allocated SwsContext. In the future, this will become less as the old context gets deprecated and eventually removed, in favor of less monolithic, individual filter passes. The downside of this approach is that users must explicitly choose to either use the "new" API usage style or the "old" API usage style, conditionally on whether or not sws_init_context() was called, and cannot mix and match the two. However, this should not be a major issue in practice, as the only way to use the new API is by deliberatily *omitting* all of the legacy init calls, something that legacy API users cannot possibly do. In exchange for this, we gain the massive upside of not needing to use sws_alloc_context2(), sws_scale_frame2() and so on. I consider this a decent compromise. Lastly, I also rewrote the test framework to facilitate further development of the new API, and to benchmark it to fend off any unintended performance regressions. The peformance should be pretty similar accross the board, since the implementation didn't really change so far. However, some cases have gotten dramatically faster, for example xyz12le -> yuv420p, since cascaded contexts and XYZ pre-passes can now be properly threaded. This results in an almost 400% speed improvement on my machine at 1080p. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
