Calculateur de visionnage en série
Dix épisodes de 45 minutes en vitesse 1,5 représentent 5 heures, un peu plus d'un cinquième de journée. Indiquez les épisodes restants, leur durée et votre vitesse de lecture pour voir le total en heures et en journées de 24 heures. Gratuit dans votre navigateur.
- Gratuit
- Fonctionne dans votre navigateur
- Sans inscription
- Vos données restent sur votre appareil
Lancer gratuitement
Exemple résolu
- Épisodes
- 10
- Minutes par épisode
- 45
- Vitesse
- 1,5
- Total de minutes
- 300
- Heures
- 5
- Jours
- 0,2083333333
Enchaîner une série d'une traite est un problème de budget de temps : multipliez le nombre d'épisodes par la durée de chacun, puis divisez par la vitesse de lecture que vous allez vraiment utiliser. Avant de commencer une nouvelle saison un vendredi soir, il faut savoir si vous affrontez une seule soirée, un week-end entier ou le gros d'une semaine. Ce calculateur de visionnage en série accepte trois nombres finis et positifs — combien d'épisodes restent, combien de minutes dure chacun, et la vitesse de lecture — et renvoie le temps total de visionnage en heures et en jours de 24 heures. Une saison de dix épisodes de quarante-cinq minutes à une vitesse d'une fois et demie fait cinq heures, un peu plus de deux dixièmes de jour.
Comment les heures et les jours du visionnage se calculent à partir de trois nombres
L'identité est la même que celle qu'utilise en interne tout lecteur de streaming. La durée brute en minutes est le nombre d'épisodes multiplié par la longueur d'un épisode en minutes. Le temps de visionnage en minutes est ce produit divisé par la vitesse de lecture.
Les heures sont les minutes de visionnage divisées par soixante. Les jours sont les heures divisées par vingt-quatre, selon un jour continu de vingt-quatre heures plutôt qu'un calendrier civil ou une coupure d'heure de coucher. La vitesse de lecture est un multiplicateur positif : 1.0 est la bande-son d'origine, 1.25 et 1.5 sont les réglages courants pour finir une saison plus vite, et 2.0 réduit l'horloge de moitié.
Une valeur sous 1.0 — ralenti, étude d'une langue ou cadence restaurée — allonge le visionnage, c'est pourquoi le champ n'est pas borné à un minimum de un. Les comptes fractionnaires sont acceptés parce que les demi-épisodes, les spéciaux de recap et les finales en deux parties existent vraiment ; l'arithmétique n'impose pas un entier. Ce point d'accès ne va pas chercher des listes d'épisodes dans un catalogue, ne retranche pas les génériques sautés et n'applique pas de fuseaux.
Il répond à une seule question : si vous vous asseyez et lisez chaque épisode listé à une vitesse constante, combien d'heures et combien de jours de vingt-quatre heures dure ce visionnage.
Où un calculateur de visionnage en série justifie sa place
Les foyers qui prévoient un marathon de week-end ont besoin d'heures pour laisser de la place aux repas et au sommeil, et de jours pour qu'une mini-série de prestige de douze heures ne soit pas prise pour une seule nuit. Les rédacteurs de recaps et les éditeurs qui construisent un calendrier de diffusion ont besoin d'une conversion déterministe du nombre d'épisodes et de la durée vers un budget d'horloge murale qu'ils peuvent figer dans une feuille.
Les étudiants d'une langue à 0.75x ont besoin de la même formule avec une vitesse inférieure à un, non d'un outil qui refuse en silence tout ce qui n'est pas 1x ou 2x. Les programmateurs de clubs et les équipes d'hospitalité qui organisent une soirée à thème peuvent transformer une pile d'épisodes en une horloge de bout en bout sans ouvrir une application de calcul pour chaque titre.
Gardez les trois entrées positives et finies, figez hours et days dans vos tests, et vous obtenez un budget de visionnage reproductible pour un plan de vendredi, un calendrier éditorial, une fiche de laboratoire de langues ou un worker en bordure, sans dresser un catalogue de streaming à vous.
Cas d’usage
Planifiez un marathon de série pour le week-end
Transformez une saison de dix épisodes de quarante-cinq minutes à 1.5x en cinq heures afin de savoir si le vendredi soir suffit ou s'il vous faut aussi le samedi.
Comparez la lecture à 1x, 1.5x et 2x
Gardez le même nombre d'épisodes et la même durée, changez seulement speed, et voyez combien d'horloge murale une bande-son plus rapide économise vraiment.
Calendriers éditoriaux et bureaux de recaps
Convertissez une bible de saison de comptes d'épisodes et de durées en heures et jours qu'un rédacteur peut bloquer sur un planning de recap ou de live-tweet.
Questions fréquentes
Qu'est-ce que la vitesse de lecture et comment change-t-elle le total ?
Speed est un multiplicateur positif sur la bande-son d'origine. 1.0 est le temps réel, 1.5 raccourcit le visionnage d'un tiers, 2.0 le réduit de moitié, et une valeur sous 1.0 (par exemple 0.75 pour l'étude d'une langue) l'allonge.
Que se passe-t-il si une entrée est nulle, négative ou absente ?
Un enchaînement sans épisodes, un épisode de durée nulle ou une vitesse de lecture nulle n'est pas un visionnage, et ces échecs ne sont pas facturés.
Les durées d'épisode sont-elles en minutes ou en heures ?
Hours et days n'apparaissent que dans le résultat, après conversion de l'horloge de visionnage.
Puis-je compter un demi-épisode ou un final en deux parties ?
Oui. Le nombre d'épisodes accepte les décimales, car les demi-épisodes restants, les épisodes récapitulatifs et les finales en deux parties existent bel et bien. Le calcul ne vous oblige pas à arrondir à un nombre entier.
Le calcul retire-t-il les génériques que je passe ?
Non. Il suppose que vous regardez chaque épisode en entier, à une vitesse constante. Si vous sautez souvent le générique, votre temps réel devant l'écran sera un peu plus court que le résultat.
Outils associés
Pour les développeurs — accès API
Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.
Endpoint
Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.
Appeler depuis votre stack
curl -X POST https://api.kit.forhosting.com/life/binge-watching \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"episodes":10,"episode_minutes":45,"speed":1.5}'const res = await fetch("https://api.kit.forhosting.com/life/binge-watching", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"episodes": 10,
"episode_minutes": 45,
"speed": 1.5
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/life/binge-watching",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"episodes": 10,
"episode_minutes": 45,
"speed": 1.5
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/life/binge-watching", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"episodes":10,"episode_minutes":45,"speed":1.5}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"episodes":10,"episode_minutes":45,"speed":1.5}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/life/binge-watching", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Exemple de requête
{
"episodes": 10,
"episode_minutes": 45,
"speed": 1.5
}Exemple de réponse
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "life.binge_watching",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.
Tarifs
Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.
Limites
max_episodes | 1000000 |
max_episode_minutes | 1000000 |
max_speed | 100 |
Erreurs
| HTTP | Code | Signification |
|---|---|---|
401 | unauthorized | Clé API absente ou invalide : vérifiez l’en-tête Authorization. |
402 | insufficient_balance | Solde insuffisant : rechargez votre compte pour lancer cette tâche. |
404 | unknown_type | Type de tâche inconnu : vérifiez le champ type de votre requête. |
429 | rate_limited | Trop de requêtes : ralentissez la cadence, puis réessayez. |
Notes techniques
Les zéros, les négatifs, les champs manquants ou les valeurs non finies échouent avec invalid_input et ne sont pas facturés. Utilisez la page dans votre navigateur sans frais, ou appelez l'API à $0.002 par requête réussie lorsqu'une feuille de calcul, un calendrier éditorial ou une fiche de tutorat a besoin du même chiffre.
Comment les heures et les jours du visionnage se calculent à partir de trois nombres
La réponse répète les valeurs nettoyées de episodes, episode_minutes et speed, puis renvoie total_minutes, hours et days, plus une chaîne formula qui reformule l'identité afin qu'une interface puisse afficher la règle à côté du nombre.
Contrat d'entrée, vitesse de lecture, champs de réponse et erreurs de validation
Les erreurs nomment toujours le champ canonique afin que le formulaire web marque le bon contrôle. Les zéros et les négatifs échouent parce qu'un enchaînement sans épisodes, un épisode de durée nulle ou une vitesse nulle n'est pas un visionnage — et une vitesse nulle serait une division par zéro. Les magnitudes au-dessus des plafonds documentés échouent pour qu'une faute de frappe ne fasse pas exploser l'isolate. Une sitcom d'une demi-heure à vingt-quatre épisodes à 1x fait cinq cent vingt-huit minutes, 8.8 heures et 0.366666666667 jour. Envoyez un corps JSON avec trois nombres finis et positifs obligatoires : episodes, le nombre d'épisodes que vous allez regarder ; episode_minutes, la durée d'un épisode en minutes ; et speed, le multiplicateur de lecture. Les alias episode_count, n et count sont acceptés pour episodes ; minutes, episode_length, length et duration pour episode_minutes ; et playback_speed, playback et rate pour speed. Chaque champ peut arriver comme nombre JSON ou comme chaîne numérique ; booléens, objets, chaînes vides, NaN et Infinity échouent avec invalid_input. En cas de succès, le corps inclut les entrées répétées, total_minutes comme horloge de visionnage, hours comme total_minutes divisé par soixante, days comme hours divisé par vingt-quatre, et une chaîne formula. Un contrôle familier est dix épisodes de quarante-cinq minutes à speed 1.5, qui donnent trois cents minutes de visionnage, cinq heures et 0.208333333333 jour. Les champs manquants et les valeurs non positives sont invalid_input et ne sont pas facturés. Les appels API réussis utilisent le tarif de base publié $0.002 ; le chemin gratuit du navigateur exécute la même fonction solve sans consommer de solde prépayé.
Où un calculateur de visionnage en série justifie sa place
Comme l'implémentation est du parse pur de palier A, chaque appel réussi coûte le tarif de base publié $0.002, sans jetons de modèle ni réseau sortant, et une validation échouée ne consomme pas de solde.
Questions techniques
Comment calcule-t-on le temps pour regarder une série d'une traite ?
Envoyez trois nombres positifs : episodes, episode_minutes et speed. L'API renvoie total_minutes = episodes × episode_minutes / speed, puis hours = total_minutes / 60 et days = hours / 24.
Combien coûte le calculateur de visionnage en série ?
L'outil du navigateur est gratuit. Les requêtes API utilisent un solde prépayé KIT à $0.002 par appel réussi ; une entrée invalide n'est pas facturée.