Aucune de ces.
Habituellement, la sortie sera un flux d'octets contenant uniquement les données de couleur. L'emplacement X, Y est impliqué par les dimensions de la vidéo. En d'autres termes, les trois premiers octets pourraient coder la valeur de couleur à (0, 0), le troisième à trois octets la valeur à (0, 1), et ainsi de suite. Certains formats peuvent utiliser des groupes de quatre octets, ou même un nombre de bits ne correspondant pas à un octet. Par exemple, si vous utilisez 5 bits pour chaque composant de couleur et que vous avez trois composants de couleur, cela représente 15 bits par pixel. Cela pourrait être complété à 16 bits (exactement deux octets) pour l'efficacité, car cela permettra d'aligner les données de manière à ce que les processeurs puissent mieux les traiter.
Lorsque vous avez traité exactement autant de valeurs que la largeur de la vidéo, vous avez atteint la fin de cette ligne. Lorsque vous avez traité exactement autant de lignes que la vidéo est haute, vous avez atteint la fin de cette image. En ce qui concerne l'interprétation de ces octets, cela dépend de l'espace colorimétrique utilisé par le codec. Les espaces colorimétriques communs sont YUV, RGB et HSL/HSV.
Cela dépend fortement du codec utilisé et du format d'entrée qu'il supporte; le format de sortie est généralement limité à l'ensemble des formats qui sont des entrées acceptables. Les données d'horodatage sont un peu plus complexes, car elles peuvent être codées dans le flux vidéo lui-même ou dans le conteneur. Au minimum, le flux aurait besoin d'un framerate; à partir de cela, le temps de chaque trame peut être déterminé en comptant combien de trames ont déjà été décodées. D'autres approches, comme celle adoptée par AVI, consistent à inclure un décalage d'octet pour chaque Nième image (ou seulement les images clés) à la fin du fichier pour permettre une recherche rapide. (Sinon, vous devrez décoder chaque image jusqu'à l'horodatage que vous recherchez afin de déterminer où se trouve le fichier dans cette image.Notez que pour la plupart des codecs et des conteneurs, les flux audio et vidéo sont indépendants et ne savent rien l'un de l'autre. Pendant l'encodage, le logiciel qui écrit les deux flux dans le format du conteneur exécute un processus appelé muxing. Il va écrire les données en morceaux de N secondes chacun, en alternance entre les flux. Cela permet à celui qui lit le flux d'obtenir N secondes de vidéo, puis N secondes d'audio, puis N secondes de vidéo, et ainsi de suite. (Plus d'un flux audio peut également être inclus - cette technique est fréquemment utilisée pour regrouper la vidéo et les pistes audio anglaises et espagnoles en un seul fichier contenant trois flux.) En fait, même les sous-titres peuvent être mélangés avec les autres. ruisseaux.
cdhowie. Merci beaucoup pour votre explication. J'ai une question subséquente. De ce que vous avez décrit, le client vidéo doit dessiner chaque image indépendamment. Est-ce que ce n'est pas trop consommer CPU/GPU étant donné que les changements entre les images consécutives sont très petites? Est-il laissé au client vidéo de comparer l'image précédente avec l'image suivante, d'identifier les pixels qui doivent être redessinés et de simplement dessiner cette portion sur l'écran? – Peter
@Peter Il semble que beaucoup de CPU, mais ce n'est pas le cas. Les images sont généralement dessinées en une seule opération en poussant le tampon de trame sur la carte vidéo à l'aide du pilote de la carte vidéo. Il existe également des cartes vidéo qui prennent en charge le décodage vidéo matériel, de sorte que l'application envoie le flux vidéo * comprimé * au GPU et le décode sur la puce et le restitue directement à l'écran avec peu ou pas d'implication du processeur. Même sans ces optimisations, les processeurs modernes sont très rapides et peuvent gérer de telles tâches facilement. – cdhowie