We are hitting a BadRequestError (400) when evaluating Cosmos-Reason2-2B/Cosmos-Reason2-8B for PPE detection. It looks like a mapping logic error in the vision processor regarding pixel budgeting.
The Bug:
The --total-pixels value is being incorrectly assigned to the linear length of the longest_edge rather than the total area.
• Partner Input: --total-pixels 1003520
• Resulting Metadata: {'shortest_edge': 131072, 'longest_edge': 1003520}
• The Overflow: The shortest_edge is snapping exactly to $2^{17}$ (131,072), suggesting an integer overflow or alignment error during the aspect ratio calculation on ARM64.
The resulting ~131B pixel payload is causing the server to reject the request.
Reproduction:
• HW: DGX Spark (ARM64)
• Inference: cosmos-reason2-inference online --videos "4k_video.mp4" --total-pixels 1003520 --fps 1
Question: Is this a known regression in how the CLI maps area budget, or an ARM-specific scaling bug? We are currently using FFmpeg as a workaround but want to use the built-in scaling.
We are hitting a BadRequestError (400) when evaluating Cosmos-Reason2-2B/Cosmos-Reason2-8B for PPE detection. It looks like a mapping logic error in the vision processor regarding pixel budgeting.
The Bug:$2^{17}$ (131,072), suggesting an integer overflow or alignment error during the aspect ratio calculation on ARM64.
The --total-pixels value is being incorrectly assigned to the linear length of the longest_edge rather than the total area.
• Partner Input: --total-pixels 1003520
• Resulting Metadata: {'shortest_edge': 131072, 'longest_edge': 1003520}
• The Overflow: The shortest_edge is snapping exactly to
The resulting ~131B pixel payload is causing the server to reject the request.
Reproduction:
• HW: DGX Spark (ARM64)
• Inference: cosmos-reason2-inference online --videos "4k_video.mp4" --total-pixels 1003520 --fps 1
Question: Is this a known regression in how the CLI maps area budget, or an ARM-specific scaling bug? We are currently using FFmpeg as a workaround but want to use the built-in scaling.