fix: handle internvl_hf video-only inputs and enable frame sampling

[akawincent]

Summary

This PR fixes two internvl_hf video handling bugs in lmms_eval/models/chat/internvl_hf.py:

• explicitly enables frame sampling when num_frames or fps is configured
• normalizes empty image inputs to None for video-only examples
• avoids building image_sizes from an empty image list

Why

This PR is motivated by two related internvl_hf bugs reported upstream:

• [Bug] internvl_hf: IndexError when visuals is empty list (video-only inputs) #1241 reports that video-only inputs can crash because generate_until() passes images=[] into the processor, and later also assumes visuals is non-empty when building image_sizes
• [Bug] Internvl_hf: num_frames not applied to videos #1242 reports that num_frames is not actually applied, because InternVL video processing keeps do_sample_frames=False by default unless it is explicitly enabled

Together, these two issues make internvl_hf unreliable on video tasks:
video-only samples can raise an IndexError, and sampled-video runs can still process all frames and overflow the model context length.

Closes #1241
Closes #1242

Validation

• pre-commit run --files lmms_eval/models/chat/internvl_hf.py
• python -m py_compile lmms_eval/models/chat/internvl_hf.py

[akawincent]

Hi @Luodian!

Need for review and tests.
InternVL is a widely used model, so I think this issue should be resolved as soon as possible.

[mwxely]

Clean and well-scoped fix. Two minor points to consider:

1. Implicit behavioral change: Since num_frames defaults to 32 in __init__, setting do_sample_frames=True means frame sampling will now actually take effect by default. Previously num_frames=32 was silently ignored (since do_sample_frames was never set). This is arguably the correct behavior, but worth noting in the PR description as it changes the default video processing pipeline for all internvl_hf users on video tasks.

2. Validation question: Did you run an end-to-end video eval (e.g., a small subset of VideoMME or similar) to confirm the fix works beyond py_compile and pre-commit? A quick --limit 4 smoke test would be reassuring.

Otherwise LGTM — the visuals = None guard and image_sizes fix are correct and consistent with existing patterns in the file. cc @kcz358

[akawincent]

2. Validation question: Did you run an end-to-end video eval (e.g., a small subset of VideoMME or similar) to confirm the fix works beyond py_compile and pre-commit? A quick --limit 4 smoke test would be reassuring.

@mwxely Hello,

Yes, I did. Actually, I ran it with --limit to test whether the code works, but I didn't run a full benchmark. To be rigorous, a better testing would be to change the num_frames and observe changes in the final metrics.