[Bug]: Unnecessary frame_rate-parameter in Byte Track

[NikolasE]

Search before asking

• I have searched the issues and discussions and found no similar bug report.

Bug

Rather surprising behavior instead of a bug, but the init-parameters of ByteTrack could be optimized:

supervision/src/supervision/tracker/byte_tracker/core.py

Line 16 in 48035c1

class ByteTrack:

We pass frame_rate (default 30) and lost_track_buffer (default 30) to compute the max_time_lost:

self.max_time_lost = int(frame_rate / 30.0 * lost_track_buffer)

To adapt the value, we can change both values (which are only used in this line!), but need to know that there is a hardcoded 30 in the computation.

Also the doc for lost_track_buffer is

lost_track_buffer (int): Number of frames to buffer when a track is lost.

Which is inconsistent with the implementation.

Proposal:
just remove the frame_rate-parameter and set
self.max_time_lost = lost_track_buffer

just like

self.minimum_consecutive_frames = minimum_consecutive_frames

Environment

• Supervision: develop
• Python: ALL
• OS: ALL

Minimal Reproducible Example

No response

Are you willing to submit a PR?

• Yes I'd like to help by submitting a PR!

[Borda]

Thanks for reporting this — you're absolutely right that the frame_rate parameter was confusing. As of #2215, we're deprecating the ByteTrack class in supervision in favor of ByteTrackTracker from the new standalone trackers package, where this has been addressed. Closing this issue as part of that migration. We'd love it if you continued the conversation or contributed over in the new repo — thanks for your time on this! 🙏

[NikolasE]

Thanks! Should I recreate the ticket/MR for https://github.com/roboflow/trackers/blob/develop/trackers/core/bytetrack/tracker.py?