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:

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.

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