ChitraMaya v1.61.00 — Release Notes
This release fixes a silent audio-desync bug affecting stream captures
(MPEG-TS files), adds new self-defense machinery around encoding and
finalize, and fixes a crash on 8K VR content. Updating is recommended
for everyone; it is important if you process stream captures.
Important
If any of your restored videos ever drifted out of sync — re-run them on 1.61.00.
Files ripped from streaming sites are usually MPEG-TS streams in
disguise (often with a .mkv name). On every prior release, the
hardware decode path silently dropped about 5 seconds of video at
the start of such files and re-stamped the remaining frames from
zero, producing a constant ~5s audio desync — plus a smaller constant
offset (~67 ms) on all TS sources. The output looked complete and
reported success. 1.61.00 fixes the whole chain and recovers the
dropped 5 seconds. Outputs made from TS captures on older versions
cannot be repaired after the fact — re-run the source files.
Fixed: audio desync on MPEG-TS stream captures (CM-120, CM-121)
Three stacked defects, all fixed:
- The decoder dropped the head of TS streams (CM-120). The
GPU-decode path's demuxer skips a constant ~5.005s of frames at the
start of MPEG-TS stream captures (the count scales with frame rate:
~150 frames at 29.97 fps, ~300 at 59.94). ChitraMaya now detects TS
sources and losslessly remuxes them to a temporary MP4 before
decoding — a stream copy, no quality change — which restores full
frame delivery with true timestamps. Console line to look for:
[Decoder] MPEG-TS source detected ... remuxing to a temporary MP4. - The timestamp safety net had gone silently blind (CM-120a). A
decoder-library API rename in the bundled wheel meant per-frame
timestamps were quietly unavailable since v1.60.00. Restored, made
robust across library versions, and backed by new end-of-run honesty
checks: if the decoder ever delivers fewer frames than the stream
reports, the console now says so loudly instead of letting the remux
hide it. - A/V start-offset restoration never worked on TS sources (CM-121).
The probe that reads the source's audio/video start offsets failed
silently on TS files (ffprobe reports TS streams twice; the doubled
value broke parsing), so the finalize skipped offset restoration on
every TS source — a constant ~67 ms error. Fixed and field-verified.
What you'll see: while a TS file processes, a temporary
<name>.cm120-tsremux.mp4 appears next to the source (or in the system
temp folder if the source folder is read-only). It is roughly
source-sized, is deleted when the run finishes, and is reused if you
re-run the same file. Budget disk space accordingly.
Field validation: a 64-minute 59.94 fps stream capture that
previously lost 300 frames and played audibly out of sync now delivers
all 229,812 frames with sync verified at the start, middle, and end of
the file.
Fixed: crash on 8K VR content on most GPUs (CM-123)
8K-wide H.264 VR sources exceed NVDEC's decode limit on everything
before RTX 50-series, so the app correctly falls back to CPU decode —
and then the VR projection compositor crashed on its first restored
frame (Expected all tensors to be on the same device). Fixed; the
full 8K VR path now runs end to end on pre-Blackwell cards. Expect CPU
decode to be slow — that part is physics, not a bug.
New self-defense: the encoder can no longer fail silently
Two real overnight-run failures this week produced two permanent
defenses:
- NVENC liveness canary (CM-122). In one 11-hour run, the NVENC
session died silently 16 minutes in; the decoder library swallowed
the error and the app "encoded" nothing for 10.7 hours while
reporting success. The encoder now aborts loudly within seconds of a
dead session, your already-encoded frames are preserved in the raw
bitstream next to a ready-made recovery script, and the flush line
now reports the bitstream size
(Flushed (229812 frames, 5791.2 MB bitstream)) so a byteless
"success" is impossible. - Finalize now survives slow disks (CM-124). The final remux used
to run under a wall-clock timeout — which killed an ffmpeg that was
writing steadily at hard-disk speeds, discarding a completed encode
at 59% packaged. The remux is now supervised by disk progress: a
slow disk gets as long as it needs, a truly wedged process is still
killed within minutes, and a failed finalize deletes its half-written
output instead of leaving a corpse that looks like your result (the
raw bitstream + recovery script remain the salvage).
Also in this release
- Model matching by basename (CM-118): Manage Models now matches
engines to checkpoints by basename, so renamed model files pair up
correctly. - Support Save the Children: the app now carries a donation link.
If ChitraMaya is useful to you, consider giving to them instead of
us — we don't take money.
Known issues
- Interrupted-remux cache (CM-125): if a run is interrupted (power
loss, forced kill) while the console shows the "remuxing to a
temporary MP4" message, delete the leftover<name>.cm120-tsremux.mp4
next to the source before re-running that file — an incomplete cache
from a prior interrupted run could otherwise be reused. A run that
got past the remux message is not affected. Fix lands in the next
patch. - Very long filenames (CM-127): Windows' 260-character path limit
can make files with very long names fail to process ("No such file
or directory" on the.hevcsidecar) and can silently skip the
stream-capture remux ("remux skipped: no writable location").
Shorten the filename — keep the full output path under ~230
characters. Fix lands in the next patch. - Everything in the README's Known Issues carries over.
Intel Arc (XPU) and AMD (ROCm) editions
Both editions are rebuilt on the 1.61.00 codebase. The TS head-drop
bug (CM-120) never affected them — they decode through a different
path — but they pick up the TS start-offset fix (CM-121), the finalize
progress supervision (CM-124), and the partial-output cleanup.
The Arc edition gains a second validated configuration. As part of
this release's testing, the full restore path was validated on a
Core Ultra 7 256V laptop (Lunar Lake, Arc 140V iGPU, 16GB) —
integrated Arc works, and works well. On the same 4K test clip:
RTX 3060 58s, Arc 140V iGPU 2m41s, desktop A580 (with
Resizable BAR) 2m37s — a 30W integrated GPU matching a desktop
Arc card, at roughly 3× an equivalent NVIDIA card. Reminder for
discrete Arc owners: that ~3× figure requires Resizable BAR on;
without it the same A580 ran ~20× slower. iGPUs are exempt (unified
memory). On 16GB laptops, expect the RAM guard to engage on 4K
content — the run completes at reduced pace; 1080p fits comfortably.
Tip
Arc/XPU users: update your Intel graphics driver first.
Field finding from this release's testing: on an out-of-box Lunar
Lake laptop with a 2024-vintage driver, the GPU enumerates but
compute kernels fail (could not make an engine with allocator;
self-check reports "device enumerates but kernels do not launch").
A current Intel graphics driver fixes it. If -self-check shows that
FAIL line, the driver is your problem — not your card, not the app.
(One more Intel quirk: the driver installer can stall when run
unattended or over a remote session — run it at the machine and
watch it finish.)
SHA-256 checksums
Downloaded ChitraMaya from a mirror, a forum re-upload, or a friend?
Verify you have the authentic build: in PowerShell run
Get-FileHash <file> -Algorithm SHA256 and compare against this table.
If a hash does not match, do not run the file -- get it from this page.
| File | Size (bytes) | SHA-256 |
|---|---|---|
| ChitraMaya-xpu-install.exe | 1281077101 | 0d0240a5d4de265b5e9120bebf173c072fc229a712f223a2cdd63126d5a85402 |
checksums.txt (sha256sum format)
0d0240a5d4de265b5e9120bebf173c072fc229a712f223a2cdd63126d5a85402 ChitraMaya-xpu-install.exe