Thanks Andrew for bringing this up and looking at the code modifications and pointing out test procedures for each. I plan to test these specifically and hope Andrea does too. On Sat, Oct 17, 2026 at 7:55 AM Andrew Randrianasulu via Cin < cin@lists.cinelerra-gg.org> wrote:
On Sat, Oct 17, 2026 at 4:06 PM Sam via Cin <cin@lists.cinelerra-gg.org> wrote:
Hi Andrew,
one more thing I wanted to add to my last mail.
This week Linus Torvalds published a kernel patch series that he wrote
with Claude Code, the same tool I use. In the commit message he says so openly:
"The code, the test programs, the review behind the list above and
the first draft of this text were done with an LLM coding assistant (Claude Code) under my direction. The measurements were run on my machine."
What I find most telling is what happened next: other kernel developers
reviewed the series and found a race condition before anything was merged, and Torvalds handed the work on to another developer. Phoronix and The New Stack have the details:
- https://www.phoronix.com/news/Linus-Torvalds-Claude-Code
- https://thenewstack.io/torvalds-claude-code-kernel/
That is pretty much how I see it too. The AI writes fast and
surprisingly well, a human directs it and measures the results, and review by others catches what slips through. So thank you again for looking at the patches. That kind of help is exactly the part no tool can replace.
Sam
Am 17.10.26 um 14:50 schrieb Sam via Cin:
Hi Andrew,
thank you for picking these out, and for your trust. It is a fair
question to ask about code written with an AI, so let me explain how I work.
I work with Claude, and every commit it helped with says so in its last
line. Since the Claude 5 models, the quality of the code has honestly surprised me. That is no guarantee that it is free of errors, of course. And at the speed the AI writes code, I can't go through every single line of the whole port myself. That would take me weeks, I would need a whole team for it.
So the workflow is built around a human checking the results. Every
problem is reproduced first, then fixed, then measured, with test series and code reviews on top. Testing again and again is what finds errors like these, and so does help like yours.
The patches for the stable version are a different matter, though: they
are small. Together they add 168 lines and remove 26, so they can be read line by line, and I would be glad if you looked at them that way too. Here is what each one does and how it was checked:
MPEG 4:2:2 (f6f2f02e): The encoder splits each picture into row bands,
one per processor, and each band was the rounded share of the rows. When the bands add up to fewer rows than the picture has, the bottom rows are never encoded. On 16 processors, 720x576 lost rows 32 to 35 in every picture, and ffmpeg reported “overread” and “MVs not available”. After the fix, 20 sizes from 176x144 to 1920x1088 decode without a message on 16 processors, and 720x576 against the source went from 16.9 dB to 40.7 dB PSNR. The stable AppImage of 2026-02-02 shows the same problem, so it is not something the port introduced.
GIF (7eb53a10): Animated GIFs had no delay per image, so viewers raced
through them or showed only the first image, and ffprobe saw one image in a 50 image file. Now an animation is GIF89a with a loop block and a delay per image. 25 fps renders 50 images of 4/100 s, and ffprobe reads 50 frames at 25 fps and 2.0 s. Frames of a GIF list are unchanged.
DPX (b4541d22 and 667b65fd): FileDPX could only read, a render to DPX
gave empty files. Now it writes 16 bit RGB through libdpx, the way FileEXR writes. A rendered frame compared to a PNG of the same frame gives 51.2 dB, which is the rounding from 16 to 8 bit, and Cinelerra loads the file again. The second commit leaves the file name in the DPX header empty, the first version wrote “frame.dpx” into every file. Two old bugs in the same file are fixed on the way: DPXInStream::ReadDirect() had no return, and FileDPX::color_model was not set before the first frame was read.
About the big host: you should not need one. Whether rows get lost
depends only on the picture height and on the number of processors mpeg2enc sees. It counts them in /proc/cpuinfo (calculate_smp() in mpeg2enc.c). With the old rounding, these should break as well:
1280x720 with 4 processors 352x288 or 176x144 with 8 processors 720x576 with 5 or 7 processors
720x576 with 8 processors comes out clean (36 rows in bands of 5), so if
that is what you tried with -smp 8, it fits. I measured only 16 processors, the other cases are calculated from the old code.
The four patches are attached, made with git format-patch. They apply in
this order to upstream master f833b47e, which is the newest commit in my clone and may be behind. I have not built the stable tree with them, so a build and a test on your side would be very welcome.
I applied them to latest master on Debian 11 amd64 VM.
DPX now can be written and read back
Gif writes 1.gif and both ffplay and mplayer can play it back animated
mpeg2 (1280x720, 4 cpu) in Mpeg Video - > mpeg 2 generic / YU 4:2:2 shows some errors in cingg itself (index-related) but plays back clearly by ffplay
So I think those fixes are win!
Hopefully Andrea/Phyllis can confirm their effect?
Thanks for making them clear enough for me to spot in all other commits!
That is also why I value your help so much. I can test until I drop, but
in a code base this big, finding such things only works as a joint effort. One person alone can't do it at this speed. And speed is the point: I want to bring Cinelerra back to where working with it is fun again. I'd like to see new features that we've been waiting for for years.
Sam
_______________________________________________ Cin mailing list -- cin@lists.cinelerra-gg.org To unsubscribe send an email to cin-leave@lists.cinelerra-gg.org
_______________________________________________ Cin mailing list -- cin@lists.cinelerra-gg.org To unsubscribe send an email to cin-leave@lists.cinelerra-gg.org