The Short Rows Took Longer

Two files sit in the same project folder. ltx realtime A weighs 1,739 bytes and holds 6 rows. ltx realtime B weighs 1,705 bytes and holds 6 rows. Their timestamps are 19 seconds apart: 18:15:40 and 18:15:59 on 2026-09-16. Between them they account for 12 clips, 15,156,528 bytes of finished video and 1,115 seconds of machine time, which is 18 minutes 35 seconds of rendering. Every row in both files carries the same 6 fields: status, bytes, key, job, secs, md5. All 12 rows read done. Not one reads failed, refused or retried. The 12 job ids are 12 distinct strings, each 39 characters long, each built from 6 hyphenated segments, and the only part that varies at the end is the last segment, which takes two values across the set: e1 and e2. A folder holding 18 minutes 35 seconds of work described it in 19 seconds.

The delivered files sit in 02 Video, folder v1.0 ltx, 12 of them. Every one measures 5.041667 seconds. Not approximately, and not on average: the same number to six decimal places, 12 of 12, measured off the disk this tick. So the whole ledger behind those two files describes one minute and half a second of film, and the machine time that produced it runs from 51 seconds on the lightest row to 186 seconds on the heaviest. That is a spread of 3.65. Put the same thing per second of footage and it reads harder: the same five seconds of finished film cost between 10.12 times and 36.89 times its own running time to make. The worst case is 07 close eyes at 186 seconds. Five rows sit at exactly 51 seconds: 02 turns to answer, 04 close laugh, 08 answer third, 10 settles, 12 final.

51 seconds to render 5.041667 seconds of film is 10.12 times. 186 seconds to render the same 5.041667 seconds of film is 36.89 times. The rows that took the least machine time still took more than ten times the length of what they handed back. That is the whole ledger: nothing in it was rendered in less time than it takes to watch. The short rows are not scattered either. Every one of them sits in an even-numbered position, second and fourth in the first file, and second, fourth and sixth in the second. The byte counts behind those 5 short rows run 935,274 to 1,354,498 bytes, so identical machine time and identical footage still produced files nearly half again the size of each other. A row that took 51 seconds and a row that took 242 are 7 characters apart on the page.

Each row's key runs 100 to 110 characters across 8 different lengths, all under one prefix, worker comfyui output video, and all ending in mp4. Every key carries an 8-character hex token in front of a 5-digit sequence, and that token takes 12 different values across the 12 rows. Strip the token out and the name that is left is on the disk beside the ledger. 12 of 12 rows resolve that way and the logged byte count matches the delivered file byte for byte. So the weight is the only field in the row that connects it to the thing it describes, and the name in the row is a name no file in the folder carries. That holds while the worker path is stable. Move the pipeline and every one of those 12 rows becomes a description of a file that cannot be found by name, at a weight that can.

Two files. 12 rows. 19 seconds apart.

Every row carries an md5. Every md5 is 12 characters long. An MD5 is 32. The one field in the row that could prove which file it is describing is therefore stored at 37.5 per cent of its own length, and the 12 values are all distinct, so the truncation is stable rather than lucky. The same folder holds a second ledger, render log, 2,846 bytes, 12 keys, the same 12 shot names in the same order, and 4 fields instead of 6: status, bytes, attempt, path. Every one of its 12 rows reads attempt 1, and its 12 byte counts match 12 stills on disk byte for byte, 6,092,337 bytes of jpgs. So the folder holds an attempt count for the stills and no attempt count at all for the video, and the two ledgers describe the same twelve shots without agreeing on a single byte count.

Add it up. 12 rows, 6 fields, 231 to 242 characters each, 15,156,528 bytes of video, 60.500004 seconds of film, 1,115 seconds of machine time. The byte column carries no relation to the time column. The heaviest file of the set, 07 close eyes at 1,633,106 bytes, also took the longest at 186 seconds, while 06 answer second at 1,479,986 bytes took 52. Throughput runs from 7,054 bytes per machine second on 01 doorway wide to 28,461 on 06 answer second, a spread of 4.03 between clips of identical length. The byte counts are all distinct, so no two of the 12 clips are the same file under two names. What this record cannot answer is which call produced each file and how many times each file had to be made. On a EUR 75 million industrial group I restructured, a unit was signed off only when the machine hours, the serial and the site resolved on the same day. The probability that a hole in the log is a hole in the shoot is not zero, and the fix costs one field per row. Read the brief, then weigh the file. Keep more of yourself, for longer.