Il faut considérer la manière dont "le facteur d'avance rapide" est calculé...faudrais que je regarde en détail comment ça marche sur E2, mais sur E1 le phénomène était en fait géré par saut dans le fichier de blocks de "N" Kb, plus ou moins gros en fonction du facteur demandé.
Ce type d'avance n'a en fait rien à voir à avec un réel facteur de vitesse qui doit être considéré en terme de nombre d'images.
Mais même si l'on gère en nombre d'image, le phénomène suivant peut expliquer le problème rencontré :
Le décodeur mpeg, lorsqu'on est avance rapide, ne reçoit pas toutes les informations, le flux linéaire...on lui soumet des segments du fichier dans lequel il doit retrouver ses petits et tenter d'afficher des images.
Il ne faut pas oublier que, en mpeg, les images sont de trois types : I, P et B. Intra(Initiale), Predite et Bidirectionelle-prédite.
Seules les images I peuvent être affichées sans disposer des images précentes et/ou suivantes, qui sont quant à elles requises pour les images P et/ou B.
De ce fait, plus on fait défiler "vite" l'avance rapide, moins on injecte de données au décodeur et plus on a de probabilité de ne PAS avoir assez de data pour générer une image. Si on tombe sur des images P ou B, leur décodage est impossible. Les images I sont plus lourdes et moins nombreuses...on peut ne jamais tomber dessus ou ne pas charger assez de données dans le décodeur... On peut donc avoir un black screen.
En retour rapide, le code est différent : comme on ne peut pas, théoriquement, revenir en arrière, le code prévois de faire un "saut" arrière important puis de ré-avancer qq temps pour charger une image affichable, afin de simuler un retour arrière "bande". C'est donc plus lourd à faire, mais ça peut générer un affichage là ou le code d'avance rapide, qui (au moins pour E1) compte sur la "probabilité de bien tomber" peut ne pas avoir...de chance !
Faudra que je me penche sur le code détaillé pour valider cette théorie
