Fix floating-point precision validation in timestamp checks

[jeremyteboul]

Resolves floating-point precision errors in video processing workflows that compute timestamps subject to small arithmetic precision loss.

• Fixes validation failures 'frame pts is 0.033000; must be greater than or equal to 0.033000' Example:
  ChainedTransform: 5.00 % of reads+writes failed (5/100+0). Error reason counts (max 100): 'frame pts is 0.033000; must be greater than or equal to 0.033000.':2, 'frame pts is 0.033033; must be greater than or equal to 0.033033.':2, 'frame pts is 0.040000; must be greater than or equal to 0.040000.':1. Sample errors: (SampleNFramesWithFps(tensor([ 0, 0, 0, ..., 49, 48, 48], dtype=torch.uint8)): 'frame pts is 0.033000; must be greater than or equal to 0.033000.',SampleNFramesWithFps(tensor([ 0, 0, 0, ..., 49, 48, 48], dtype=torch.uint8)): 'frame pts is 0.033033; must be greater than or equal to 0.033033.',SampleNFramesWithFps(tensor([ 0, 0, 0, ..., 49, 48, 48], dtype=torch.uint8)): 'frame pts is 0.033000; must be greater than or equal to 0.033000.',SampleNFramesWithFps(tensor([ 0, 0, 0, ..., 49, 48, 48], dtype=torch.uint8)): 'frame pts is 0.033033; must be greater than or equal to 0.033033.',SampleNFramesWithFps(tensor([ 0, 0, 0, ..., 49, 48, 48], dtype=torch.uint8)): 'frame pts is 0.040000; must be greater than or equal to 0.040000.').
• Applied to both getFramesPlayedAt() and getFramesPlayedInRange() methods
• Add C++ test cases for precision error scenarios

[meta-codesync]

@jeremyteboul has imported this pull request. If you are a Meta employee, you can view this in D84474137.

[NicolasHug]

Thanks for the PR @jeremyteboul

Would you be able to share a specific video where these errors can occur? I'd like to see if there are more robust or alternative ways to solve the underlying issue. We've tried to avoid using EPS-logic in TC so far, as they're hard to reason about and can typically cascade into other kind of downstream floating-point issues. This is only a gut feeling, but perhaps the best course of action here would be to switch from double pts values to int-based pts values for comparison.

A reproducing video would help figuring out what the best course of action is.

[jeremyteboul]

Thanks for the PR @jeremyteboul

Would you be able to share a specific video where these errors can occur? I'd like to see if there are more robust or alternative ways to solve the underlying issue. We've tried to avoid using EPS-logic in TC so far, as they're hard to reason about and can typically cascade into other kind of downstream floating-point issues. This is only a gut feeling, but perhaps the best course of action here would be to switch from double pts values to int-based pts values for comparison.

A reproducing video would help figuring out what the best course of action is.

The issue was happening on a large dataset of videos 100K where unfortunately 5 of them where failing with this error; If we want these videos it will take more times to identify them;

Agree EPS can introduce issue if you it to update a variable; In the log we can see that the value are in theory identical and the comparison should pass, it only fails due to the approximation done with double; so it is all about the precision you want to achieve for your decimal value and ensuring the verification does not include past/next frame; moving to int will also round and approximate the result;