Animated and multi-frame RGB archives need timing metadata, per-frame dimensions, and shared codebooks without breaking lossless guarantees on each frame. The proposed .rgbv3dvi container (documented on /rgbv3d/roadmap/) is experimental—not something you should bulk-deploy today.
Current status: research notes define frame headers, dependency on profile 0/1 bitstreams, and placeholder constraints for mixed resolutions. There is no browser muxer on PracticalKit yet. CLI support is staged behind feature flags in the ecosystem repo. We will not ship silent beta endpoints that rewrite uploads on server.
Limits we already know: variable frame size sequences complicate block predictors across time; noise in video frames makes inter-frame vector predictors risky; container overhead must stay bounded so short loops are not larger than ZIP+PNG sequences.
Honest use cases if/when stable: lossless archival of rendered UI animation captures, scientific RGB frame stacks with identical geometry, and regression fixtures for graphics engines—not consumer video replacement. For AV1 or H.264 delivery, use video tools; RGBV3Dvi targets niches where pixel-exact frames matter.
How to follow progress: watch the roadmap page, benchmark additions for multi-frame samples, and blog posts tagged RGBV3D. We prefer dated, testable milestones over vague “coming soon” banners— the same editorial standard as the rest of this rebuild.
Until the multi-frame container is stable, use a manifest-plus-single-frame workflow: one .rgbv3d per frame plus JSON for order, timestamps, dimensions, and checksums. Migration later becomes packaging, not reinterpretation. Roadmap honesty means stating there is no browser muxer yet and no bulk-deploy recommendation—dated milestones beat vague “coming soon” banners that mislead reviewers and engineers alike.
2026-06-05