Enregistrements : corriger le démarrage de la lecture

La lecture d'un enregistrement démarrait au milieu du programme et se
coupait aussitôt ; il fallait relancer une deuxième fois pour qu'elle
tienne.

Cause principale, introduite avec le passage de la playlist en `EVENT` :
tant que le transcodage n'est pas terminé, la playlist n'a pas
d'`EXT-X-ENDLIST`, et hls.js traite alors tout contenu comme du direct.
Sans `startPosition` explicite il démarre au « bord du direct » — donc
collé au front d'encodage, sans la moindre avance de segments. D'où un
départ en plein milieu, puis une coupure immédiate. Au second essai, le
transcodage était terminé (ENDLIST présent, contenu traité en VOD) et
tout se passait bien.

Hors direct : `startPosition: 0` (ou la position de reprise), rattrapage
de latence neutralisé (il accélérait la lecture puis forçait un saut en
avant vers un direct inexistant), et délai d'attente de playlist porté de
10 s à 45 s — une session FFmpeg qui démarre n'est plus prise pour un
manifeste mort.

Cause de fond : la lecture ré-encodait la vidéo. Or la capture se fait en
`-c copy`, donc le fichier contient le codec de la chaîne, presque
toujours du H.264, directement lisible en HLS. Le ré-encodage tenait à
peine le temps réel en 1080p, ce qui laissait le lecteur courir après
l'encodeur en permanence. La vidéo est désormais copiée telle quelle
quand elle est en H.264 (seul l'audio est converti en AAC) : la
segmentation va à la vitesse du disque, l'enregistrement devient
navigable en quelques secondes et les sauts ne redémarrent presque plus
jamais FFmpeg. Les codecs que le navigateur ne sait pas lire (HEVC,
MPEG-2…) restent ré-encodés.

En complément :
- le serveur attend trois segments d'avance avant de servir la playlist,
  et sert ce qu'il a plutôt qu'une erreur si le délai expire ;
- le lecteur de bureau réessaie seul jusqu'à 3 fois, comme le lecteur
  mobile le faisait déjà ;
- `XFPlayer.destroy()` retire ses écouteurs : sans ça, une relance
  laissait l'instance précédente réagir aux commandes du parent et
  republier des positions périmées ;
- les appels ffprobe passent par `MediaProbe`, qui mémorise durée et
  codec tant que le fichier ne change pas.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T1A6WRnoktWcT7ZG4b2rbC

bin/api/streaming_handler.dart

@@ -7,6 +7,7 @@ import '../database/database.dart';
 import '../models/playlist_config.dart';
 import '../services/ffmpeg_session_manager.dart';
 import '../utils/log_redactor.dart';
+import '../utils/media_probe.dart';
 import 'recording_playlist.dart';
 
 /// Directory for temporary HLS segments
@@ -665,12 +666,31 @@ Handler createRecordingStreamHandler(
           body: 'Physical recording file not found');
     }
 
-    final useNvidiaGpu = isGpuEnabled?.call() ?? _isNvidiaGpuEnabled();
     final start = parseRecordingStart(request.url.queryParameters['start']);
     final offsetKey = recordingOffsetKey(start);
     final sessionPrefix = 'rec_${streamId}_t';
     final sessionId = 'rec_${streamId}_$offsetKey';
 
+    // La capture est faite en `-c copy` : le fichier contient le codec
+    // d'origine de la chaîne, presque toujours du H.264 — directement
+    // lisible en HLS. Le ré-encoder tenait à peine le temps réel en 1080p,
+    // si bien que la lecture démarrait collée au front d'encodage et se
+    // coupait à la moindre hésitation. En copie, la segmentation va à la
+    // vitesse du disque : l'enregistrement devient navigable en quelques
+    // secondes. Seuls les codecs que le navigateur ne sait pas lire
+    // (HEVC, MPEG-2…) justifient encore un ré-encodage.
+    final videoCodec = await MediaProbe.videoCodec(targetUrl);
+    final canCopyVideo = videoCodec == 'h264';
+    final useNvidiaGpu =
+        !canCopyVideo && (isGpuEnabled?.call() ?? _isNvidiaGpuEnabled());
+
+    if (!sessionManager.contains(sessionId)) {
+      print(
+        '[Recording] $sessionId : ${canCopyVideo ? 'copie vidéo' : 'ré-encodage'}'
+        ' (codec source : ${videoCodec ?? 'inconnu'})',
+      );
+    }
+
     final session = await sessionManager.getOrStart(
       id: sessionId,
       isLive: false,
@@ -680,9 +700,12 @@ Handler createRecordingStreamHandler(
         if (useNvidiaGpu) ...['-hwaccel', 'cuda'],
         // -ss AVANT -i : recherche rapide par index, sans décoder ce qui
         // précède. La sortie repart de 0, le lecteur ré-ajoute l'offset.
+        // En copie, la position atteinte est l'image-clé qui précède.
         if (start > 0) ...['-ss', '$start'],
         '-i', targetUrl,
-        if (useNvidiaGpu) ...[
+        if (canCopyVideo) ...[
+          '-c:v', 'copy',
+        ] else if (useNvidiaGpu) ...[
           '-c:v', 'h264_nvenc', '-preset', 'p4', '-tune', 'hq',
           '-rc', 'cbr', '-b:v', '3000k', '-maxrate', '3500k',
           '-bufsize', '6000k',
@@ -710,7 +733,10 @@ Handler createRecordingStreamHandler(
       ],
     );
 
-    final result = await sessionManager.waitForPlaylist(session);
+    // Trois segments d'avance (~12 s) avant de rendre la main : c'est la
+    // marge qui manquait au démarrage. En copie vidéo elle est produite en
+    // une fraction de seconde, elle ne coûte donc que sur un ré-encodage.
+    final result = await sessionManager.waitForPlaylist(session, minSegments: 3);
     if (!result.ready) {
       sessionManager.killSession(sessionId);
       return Response(502,