[Cin] "Competitors" or do we want to stay alive?

[Andrew Randrianasulu]

пт, 4 апр. 2025 г., 18:32 Phyllis Smith <phylsmith2017 at gmail.com>:

> Yes, thanks for a good summary.  I think Cinelerra has its place and still
> serves as a learning tool also..
> If the Olive NLE Matt had corroborated with CinGG, he would have been
> welcome and could have made major changes to update it instead of trying to
> write from scratch.
>

https://github.com/olive-editor/olive/issues/2383

lets see ......




>
> On Fri, Apr 4, 2025 at 4:06 AM Andrew Randrianasulu via Cin <
> cin at lists.cinelerra-gg.org> wrote:
>
>> Sorry for being frustrated lately.
>>
>> Realities of all this "modern development" vs me tend to be not in favor
>> of our project.
>>
>> I looked up two "other" projects in video editing.
>>
>> MLT is well-known and going on for nearly two decades.
>>
>> In this year release notes we see:
>>
>> https://github.com/mltframework/mlt/releases
>>
>>
>> =====
>>
>> https://github.com/mltframework/mlt/releases/tag/v7.30.0
>>
>>
>> Added support for mlt_image_yuv420p10, mlt_image_yuv444p10, and
>> mlt_image_yuv422p16 in avfilter, swscale, and rescale filters.
>> This facilitates using these pixel formats end-to-end when using only
>> FFmpeg producers, certain avfilters, and avformat 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 color_trc and pix_fmt
>> properties on the avformat consumer (see ffmpeg -h full for these
>> values). The avformat consumer automatically converts MLT colorspace
>> (integer value) to FFmpeg's colorspace and color_primaries (unless
>> explicit) options.
>>
>> ====
>>
>> I take this as "floating point pipeline still not here".
>>
>> Olive branch is even more depressing:
>>
>> https://github.com/olive-editor/olive/issues
>>
>> Last non-CI commit was in ... september 2023?
>>
>> 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.
>>
>> Natron does not do audio, as far as I know, and also hanging on a thread
>> (single developer).
>>
>> 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!
>>
>> 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.
>>
>> https://www.phoronix.com/news/X11-DeepColor-Visual-RFC
>>
>> from 2017 ....
>>
>>
>> https://lists.freedesktop.org/archives/wayland-devel/2017-December/036403.html
>>
>> It took whole 8 years to get into "usable in mpv" state, and producing
>> video usually have higher demands than playing back.
>>
>> 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).
>>
>> 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
>> ....).
>>
>> I see no escape from this, at larger scale. And this makes me even more
>> frustrated.
>>
>> cc ffmpeg-user/libav user because otherwise no one from "outside" will
>> ever read this.
>> --
>> Cin mailing list
>> Cin at lists.cinelerra-gg.org
>> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20250404/999cebff/attachment.htm>