experiments of a tiny cytube-like player with yt-dlp

merge video into control WS, use group_id for sync master

Frontend now receives video data as MoQ objects on the single control WS connection instead of a separate raw-fMP4 WebSocket. This gives the client access to the MoQ group_id, which is used as the sole synchronisation primitive between video data and state updates. Server changes: - ActiveTrackInfo and TrackState carry group_id - Player::start() returns the assigned group_id - execute_effects stores group_id on the active track - Subscribe handler for video track sends cached init + forwards live MoQ objects via the control WS object channel - Removed handle_video_session and video WS route Frontend changes: - Subscribe to video track alongside chat and state - handleVideoObject() uses group_id to discard stale old-track data and gate on init reception - updateNowPlaying() sets awaitingInit only if processedGroupId < newGroupId (no re-buffer if init already arrived) - No more separate video WS connection, no pendingTrackChange flag - onopen resets sync state (currentGroupId, processedGroupId, awaitingInit) 149 tests pass, 0 warnings.


Author karitham Date Commit fb5404c4 Parent 1741e7be Change ID qmslklyw