docs(x265): head-to-head §Results + PROBE-SPLAT-μ-HYDRATION-RHO queued#250
Conversation
Plan §Results (head-to-head): our helix Signed360 object-motion codes (432 B, ∞ PSNR bit-exact) vs x265 block-MV (43,115 B, 60.94 dB) on the SAME φ-scene. Verdict: tautological-win / model-matched lower bound (KILL did not fire, NOT a general-codec win) — establishes the amortization's concrete bit-cost (1× 6-byte Signed360/sprite/P-frame); arbitrary non-φ motion needs residuals (the [H] gate). Follow-up probe queued — PROBE-SPLAT-μ-HYDRATION-RHO (the spatial cousin): the 3DGS↔blasgraph↔gridlake presumption adjudicated (splat3d GaussianBatch already SoA → only net-new claim is address-derived μ, φ-manifold-gated; EWA-semiring DROPPED as non-commutative). Runs on a real Inria .ply. Board: lance-graph E-X265-HEADTOHEAD-1 + E-3DGS-MU-HYDRATION-1. Guard test 117/117. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3RyLEbuNSHxxB3NTTrGki
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_36976a19-5328-4fa6-a5dc-68fca9d1df13) |
|
Warning Review limit reached
Next review available in: 18 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 234b936262
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| | Lane | Bytes | bits/frame | PSNR | Codec | | ||
| |---|---|---|---|---| | ||
| | A — x265 3.5 medium | 43,115 | 1437.2 | 60.94 dB | general block-MV, blind to scene structure | |
There was a problem hiding this comment.
This row reuses the 43,115 B / 1437.2 bpf value that the preceding section documents as the entire HEVC output (raw Y4M ... → HEVC 43,115 B), but the new result is framed as a comparison against x265's MV field. In this context, readers will treat the 432 B object-motion lane as replacing x265's motion-vector payload, while the HEVC stream also includes residuals, modes, headers, and other syntax, so the experiment overstates what was actually measured. Please either measure/report x265's MV-side bits separately or rename Lane A/the heading as a total x265 bitstream comparison.
Useful? React with 👍 / 👎.
…ream framing Codex-P1 #740: reproducer now renders through helix's REAL signed_lift (golden- ratio azimuth, r=√u), not a golden-angle approximation → genuine helix result; lane-A re-measured on the real-helix scene (40,750 B, 1358.3 bits/frame, 61.27 dB). Codex-P2 #250: relabelled as TOTAL-stream vs TOTAL-stream (x265's bytes are the whole HEVC output, not its MV payload). Guard test 117/117. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3RyLEbuNSHxxB3NTTrGki
2 participants
Follow-up to the merged PROBE-GPU-LUT + HEVC-anchor docs (#249), on a branch restarted from
master.Adds to
x265-sprite-replay-probe-v1.md:Signed360object-motion codes (432 B, ∞ PSNR bit-exact) vs x265 block-MV (43,115 B, 60.94 dB) on the same φ-scene. Verdict: tautological-win / model-matched lower bound (KILL did not fire; not a general win) — establishes the amortization's concrete bit-cost; arbitrary non-φ motion needs residuals (the [H] gate).splat3d::GaussianBatchalready SoA → only net-new claim is address-derived μ (φ-manifold-gated); EWA-semiring DROPPED (non-commutative). Runs on a real Inria.ply.Code + board live in lance-graph (
hevc_headtohead.rs,E-X265-HEADTOHEAD-1,E-3DGS-MU-HYDRATION-1). Knowledge-doc guard test 117/117 green.🤖 Generated with Claude Code
Generated by Claude Code