improve video export progress and quality controls

[shantz1]

No description provided.

[GargantuaX]

Thanks for the contribution. I tested this commit after merging the current main (v1.0.31) into an isolated checkout.

Validation completed:

• merge with current main: clean
• focused CLI/SDK tests: 13 passed
• full suite rerun: 1,356 passed, 29 skipped, 0 failed
• production build and SDK smoke: passed
• real 10-second 1280x720/24fps video export with --video-bitrate-mbps 12: succeeded

I found two actionable issues in the new progress/timeout behavior:

1. The CLI reports an incorrect total frame count. The real sample contains 240 frames (ffprobe), but the output progressed through 101/90 frames and ended at 240/90 frames. resolveVideoMetadata() assigns computePacketStats(90).packetCount to frameCountEstimate; that packet count is capped by the 90-packet sampling limit, so it is not the total frame count. Please derive the estimate from duration × average packet rate, or omit the denominator when it is not reliable, and add a regression test.

2. --video-timeout-ms is documented as an export inactivity timeout, but it is also passed into page.setDefaultTimeout(Math.min(timeoutMs, 30_000)). A 100 ms probe failed at page.goto: Timeout 100ms exceeded before video processing began. Please decouple Playwright navigation/action timeout from the export inactivity timer so the option matches its documented semantics.

The PR currently adds no tests. Please add focused coverage for waitForVideoProcessing(), CLI argument validation/forwarding, the unreliable frame-estimate case, and the separation between page setup timeout and inactivity timeout.

[shantz1]

Thanks for the detailed review and feedback! I've pushed a follow-up commit that addresses both issues.

• Frame totals are now estimated using the video duration and the sampled average packet rate. The 90-packet sample limit is no longer treated as the total frame count, and if the estimate isn't reliable, the denominator is simply left out.
• Playwright page setup and navigation now have their own 30-second timeout. The --video-timeout-ms flag only controls export inactivity, which matches the documented behavior.

I also added targeted tests covering:

• waitForVideoProcessing()
• CLI validation and option forwarding
• the capped packet-sample regression
• separation of setup and inactivity timeouts

I reran the focused tests, the full test suite, the production build, and the SDK smoke tests, and everything is passing now. Thanks again for the thorough feedback!