<div dir="auto">Sorry for being frustrated lately.<div dir="auto"><br></div><div dir="auto">Realities of all this "modern development" vs me tend to be not in favor of our project. </div><div dir="auto"><br></div><div dir="auto">I looked up two "other" projects in video editing.</div><div dir="auto"><br></div><div dir="auto">MLT is well-known and going on for nearly two decades.</div><div dir="auto"><br></div><div dir="auto">In this year release notes we see:</div><div dir="auto"><br></div><div dir="auto"><a href="https://github.com/mltframework/mlt/releases" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://github.com/mltframework/mlt/releases</a></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">=====</div><div dir="auto"><br></div><div dir="auto"><a href="https://github.com/mltframework/mlt/releases/tag/v7.30.0" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/mltframework/mlt/releases/tag/v7.30.0</a></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Added support for <code>mlt_image_yuv420p10</code>, <code>mlt_image_yuv444p10</code>, and <code>mlt_image_yuv422p16</code> in <code>avfilter</code>, <code>swscale</code>, and <code>rescale</code> filters.<br>
This facilitates using these pixel formats end-to-end when using only FFmpeg producers, certain avfilters, and <code>avformat</code>
 consumer. This means it is possible to do 10-bit end-to-end on the CPU 
when being careful to select compatible components and options to avoid 
conversions. One can pass-through HDR; however, you must set the <code>color_trc</code> and <code>pix_fmt</code> properties on the <code>avformat</code> consumer (see <code>ffmpeg -h full</code> for these values). The <code>avformat</code> consumer automatically converts MLT <code>colorspace</code> (integer value) to FFmpeg's <code>colorspace</code> and <code>color_primaries</code> (unless explicit) options.</div><div dir="auto"><br></div><div dir="auto">====</div><div dir="auto"><br></div><div dir="auto">I take this as "floating point pipeline still not here".</div><div dir="auto"><br></div><div dir="auto">Olive branch is even more depressing:</div><div dir="auto"><br></div><div dir="auto"><a href="https://github.com/olive-editor/olive/issues" rel="noreferrer noreferrer" target="_blank">https://github.com/olive-editor/olive/issues</a></div><div dir="auto"><br></div><div dir="auto">Last non-CI commit was in ... september 2023?</div><div dir="auto"><br></div><div dir="auto">May be developing moved somewhere, but this mean all exiting new bugs and state of being incomplete for  few more years, given that even with most of hard work done by OpenGL, OCIO, ffmpeg etc remaining NLE core is not that simple, as it turned out to be.</div><div dir="auto"><br></div><div dir="auto">Natron does not do audio, as far as I know, and also hanging on a thread (single developer).</div><div dir="auto"><br></div><div dir="auto">Blender is a Big Shot now, with predictably big requirements both in software (try to build it on Slackware) and in hardware. Driven by higher end!</div><div dir="auto"><br></div><div dir="auto">And whole "Oh lol X is deprecated, everyone rewrite themselves to Wayland"  push. I bet there might be way to resistance say Intel's or Nvidia "HDR on X" proposals in Xwayland but who will do all this work for single application? It took Valve's money effectively to get anything at all done in this area.</div><div dir="auto"><br></div><div dir="auto"><a href="https://www.phoronix.com/news/X11-DeepColor-Visual-RFC" target="_blank" rel="noreferrer">https://www.phoronix.com/news/X11-DeepColor-Visual-RFC</a></div><div dir="auto"><br></div><div dir="auto">from 2017 ....</div><div dir="auto"><br></div><div dir="auto"><a href="https://lists.freedesktop.org/archives/wayland-devel/2017-December/036403.html">https://lists.freedesktop.org/archives/wayland-devel/2017-December/036403.html</a></div><div dir="auto"><br></div><div dir="auto">It took whole 8 years to get into "usable in mpv" state, and producing video usually have higher demands than playing back.</div><div dir="auto"><br></div><div dir="auto">I am fairly sure someone will write something in Rust (so it will break in 6 months time because Rust is for Big D Developers who have no problems with such churn) or c++ 25 because c+11 is too archaic and all new courses are about $latest (double meaning of $ here).</div><div dir="auto"><br></div><div dir="auto">Again, I do not think this is only individual developers fault, just more complex issue with constant stream of *new*  hardware we supposed to fix in field by writing software, somehow (HDR displays are all or nothing, so HD(R), SD and GUI all must be mixed on host side). And general "culture" of individualism (because Silicon Valley, bebe!)  and effectively social darwinism (where are XDTV and libquicktime? killed by constant API churn ....).</div><div dir="auto"><br></div><div dir="auto">I see no escape from this, at larger scale. And this makes me even more frustrated.</div><div dir="auto"><br></div><div dir="auto">cc ffmpeg-user/libav user because otherwise no one from "outside" will ever read this.</div></div>