refactor(video_player): replace audio track string ID with typed indices

[nateshmbhat]

Summary

Refactors the audio track identification and selection API to use separate groupIndex and trackIndex integers instead of encoded string IDs, and updates selectAudioTrack to accept a VideoAudioTrack object for improved type safety and developer experience.

Breaking Changes

Version: 7.0.0 (major version bump)

1. VideoAudioTrack Structure Change

Before:

class VideoAudioTrack {
  final String id;  // Encoded as "groupIndex_trackIndex"
  final String label;
  final String language;
  // ...
}

After:

class VideoAudioTrack {
  final int groupIndex;  // Separate integer for track group
  final int trackIndex;  // Separate integer for track index
  final String label;
  final String language;
  // ...
}

Motivation :
The previous string-based track ID system had several issues:

Lack of Type Safety: String encoding/decoding of track indices was error-prone
Poor Developer Experience: Required developers to manually construct or parse track IDs
Platform Inconsistency: Different platforms (ExoPlayer vs AVFoundation) handle track groups differently, but this was hidden in string encoding
Unintuitive API: Users had to remember the format and construction of track IDs

Interface Breakout PR From : #9925

Pre-Review Checklist

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• I read the [Tree Hygiene] page, which explains my responsibilities.
• I read and followed the [relevant style guides] and ran [the auto-formatter].
• I signed the [CLA].
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I [linked to at least one issue that this PR fixes] in the description above.
• I updated pubspec.yaml with an appropriate new version according to the [pub versioning philosophy], or I have commented below to indicate which [version change exemption] this PR falls under[^1].
• I updated CHANGELOG.md to add a description of the change, [following repository CHANGELOG style], or I have commented below to indicate which [CHANGELOG exemption] this PR falls under[^1].
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which [test exemption] this PR falls under[^1].
• All existing and new tests are passing.

[gemini-code-assist]

Code Review

This pull request is a well-executed refactoring of the audio track selection API. It replaces the string-based track ID with typed indices (groupIndex and trackIndex) on the VideoAudioTrack object, improving type safety and the developer experience. The changes are consistently applied across the platform interface, including the selectAudioTrack method, the VideoAudioTrack class, and the corresponding tests. The version bump to 7.0.0 for this breaking change is appropriate, and the changelog is updated accordingly. I have one minor suggestion to improve the clarity of the changelog entry.

[gemini-code-assist]

For improved clarity in the release notes, consider rephrasing this point. The playerId is still a separate parameter, so stating it accepts the full track object 'instead of separate parameters' is slightly inaccurate. The main change is replacing the trackId string with the VideoAudioTrack object.

Suggested change

	* `selectAudioTrack(int playerId, String trackId)` changed to `selectAudioTrack(int playerId, VideoAudioTrack track)` - now accepts the full track object instead of separate parameters.
	* `selectAudioTrack(int playerId, String trackId)` changed to `selectAudioTrack(int playerId, VideoAudioTrack track)` - now accepts the full track object instead of a separate track ID.

[Andro999b]

What group_id should be for other platforms? I am working on custom VideoPlayerPlatform layer for media_kit for my project. And it does not have any groups of tracks audio tracks. It just separates tracks into video and audio tracks. Instead of this ExoPlayer specific group_id this it should be just video/audio tracks separation.

[stuartmorgan-g]

Motivation : The previous string-based track ID system had several issues:

That would have needed to be considered before you posted #10171, had it go through review, and got it landed. We don't do rapid iteration in production with breaking changes of platform interfaces; please read this comment.

I don't see a sufficiently compelling reason here to make a breaking change. You are welcome to file an issue tracking the desire to change this the next time we are making a breaking change for other reasons.

Lack of Type Safety: String encoding/decoding of track indices was error-prone

At this point, the best option to mitigate it is probably to have an internal structure on each platform, and a single method to convert between that structure and the string form, used at the interface boundary of each platform.

Poor Developer Experience: Required developers to manually construct or parse track IDs

Most developers never need to interact with the platform interface, so this is not sufficient reason for a platform interface breaking change. We're likely talking about a single-digit number of developers who will need to interact with this.

Platform Inconsistency: Different platforms (ExoPlayer vs AVFoundation) handle track groups differently, but this was hidden in string encoding

If different platform handle things differently, that's an argument for a flexible system—either strings, or some subclassable structure. So even if we did want to make a breaking change for this, hard-coding a specific set of fields seems like the wrong solution given this, and likely to cause yet another round of breaking changes in the future.

Unintuitive API: Users had to remember the format and construction of track IDs

Clients of video_player should never be calling APIs at the platform interface layer, so there is no need for them to know anything about this structure.

[nateshmbhat]

got it @stuartmorgan-g have moved the encoding/decoding logic to dart side of the platform interface and updated the main #9925 PR.

The reason i raised this updated interface PR was based on comment by @ash2moon in #10312 PR

[stuartmorgan-g]

The reason i raised this updated interface PR was based on comment by @ash2moon in #10312 PR

This is why we generally wait until the full combined PR has passed all reviews before landing any sub-PRs. It looks like this comment was premature, since the Android review wasn't complete. (@tarrinneal FYI for future federated PRs.)

It's not ideal that it turned out this way, but given that it did we'll need to work with the string form.