chore: refactor timing offset properties

[United600]

No description provided.

[Copilot]

Pull Request Overview

This PR refactors the timing offset properties for audio and subtitle synchronization by moving them from custom implementation in the ViewModel to proper interface-based properties in the media player architecture.

• Extracted timing offset properties from PlayerControlsViewModel to the IMediaPlayer interface
• Replaced manual property handling with ObservableProperty attributes for automatic change notifications
• Added proper event handling for timing offset changes in VlcMediaPlayer

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
PlayerControlsViewModel.cs	Removed custom timing offset properties and replaced with ObservableProperty fields and change handlers
VlcMediaPlayer.cs	Added proper AudioTimingOffset and SubtitleTimingOffset properties with event notifications
IMediaPlayer.cs	Added timing offset properties and events to the interface definition

[Copilot]

The magic number 0.0001 should be extracted to a named constant to improve maintainability and make the tolerance value explicit.

Suggested change

	public double SubtitleTimingOffset
	{
	get => VlcPlayer.SpuDelay / 1000.0;
	set
	{
	double oldValue = VlcPlayer.SpuDelay / 1000.0;
	if (Math.Abs(oldValue - value) > 0.0001)
	private const double SubtitleTimingOffsetTolerance = 0.0001;
	public double SubtitleTimingOffset
	{
	get => VlcPlayer.SpuDelay / 1000.0;
	set
	{
	double oldValue = VlcPlayer.SpuDelay / 1000.0;
	if (Math.Abs(oldValue - value) > SubtitleTimingOffsetTolerance)

[Copilot]

The magic number 0.0001 should be extracted to a named constant to improve maintainability and make the tolerance value explicit. Consider using the same constant as in the SubtitleTimingOffset property.

[huynhsontung]

There is actually a reason I didn't want to include the timing offset properties in the IMediaPlayer interface. I want IMediaPlayer to track the UWP MediaPlayer class as much as possible. This way, we can be sure that any player backend we implement can follow the UWP standard. This is the assumption that enables FFmpeg integration. (#333)

[United600]

There is actually a reason I didn't want to include the timing offset properties in the IMediaPlayer interface. I want IMediaPlayer to track the UWP MediaPlayer class as much as possible. This way, we can be sure that any player backend we implement can follow the UWP standard. This is the assumption that enables FFmpeg integration. (#333)

Makes sense. MediaPlayerElement also I guess.