2011-04-03 8 views
4

Les données d'entrée sont un tableau d'octets qui représente une trame h.264. Le cadre est constitué d'une seule tranche (pas de trame multislice). Donc, comme je l'ai compris, je peux faire face à ce cadre comme à la tranche. La tranche a en-tête, et tranche des données - macroblocs, chaque macrobloc avec son propre en-tête.Analyse h.264 bytestream

donc je dois analyser ce tableau d'octets pour extraire le numéro de trame, type de trame, le coefficient de quantification (comme je l'ai compris chaque macrobloc a son propre coefficient? Ou je me trompe?)

Pouvez-vous me conseiller, où Je peux obtenir des informations plus détaillées sur l'analyse des octets de trame h.264.

(En fait, j'ai lu la norme, mais il n'a pas été très précis, et je suis perdu.)

Merci

+0

Les données d'entrée sont des tableaux d'octets qui représentent la trame h.264.Le cadre est constitué d'une seule tranche (pas de trame multislice). (ce sont les limites de mon problème) – stemm

+0

Essayez de regarder ISO/IEC 14496-15 – VitalyVal

+0

Qu'est-ce que h.264m? Je veux dire - est h.264m une extension à H.264? – anatolyg

Répondre

15

La norme H.264 est un peu difficile à lire, alors voici quelques conseils.

  • Lire l'annexe B; assurez-vous que votre entrée commence par un code de démarrage
  • Lisez la section 9.1: vous en aurez besoin pour toutes les conditions suivantes
  • tête de tranche est décrit dans la section 7.3.3
  • « numéro de trame » est pas explicitement codée dans le en-tête de tranche; frame_num est proche de ce que vous voulez probablement.
  • « Type de trame » correspond probablement à slice_type (la deuxième valeur dans l'en-tête de tranche, donc plus facile à analyser, vous devriez certainement commencer par celui-ci)
  • « coefficient de Quantification » - voulez-vous dire « paramètre de quantification "? Si oui, préparez-vous à écrire un analyseur H.264 complet (ou réutilisez-en un existant). Regardez dans la section 9.3 pour avoir une idée de la complexité d'un analyseur H.264.
6

La norme est très difficile à lire. Vous pouvez essayer d'analyser le code source d'un logiciel de décodage de flux vidéo H.264 existant tel que ffmpeg avec ses bibliothèques C (C99). Par exemple, il existe une fonction avcodec_decode_video2 documentée here. Vous pouvez obtenir le fonctionnement complet de C (ouvrir le fichier, obtenir le flux H.264, parcourir les trames, vider l'information, obtenir l'espace colorimétrique, enregistrer les images sous forme d'images PPM brutes, etc.) here. Alternativement, il ya un grand livre "The H.264 Advanced Video Compression Standard", ce qui explique la norme en "langage humain". Une autre option est d'essayer le logiciel Elecard StreamEye Pro (il existe une version d'essai), ce qui pourrait vous donner une perspective (visuelle) supplémentaire.

4

En fait beaucoup mieux et plus facile (c'est seulement mon avis) de lire la documentation de codage vidéo H.264. ffmpeg est une très bonne bibliothèque mais elle contient beaucoup de code optimisé. Mieux vaut regarder la mise en œuvre de référence du codec H.264 et de la documentation officielle. http://iphome.hhi.de/suehring/tml/download/ - ceci est un lien vers l'implémentation du codec JM. Essayez de séparer les niveaux de processus de décodage, comme la couche de transport qui contient des unités NAL (SPS, PPS, SEI, IDR, SLICE, etc.). Que vous avez besoin de mettre en œuvre le moteur VLC (principalement les codes exp-Golomb de 0). Un codec très difficile et puissant appelé CABAC (Context Adaptive Arithmetic Binary Codec). C'est une tâche assez difficile. Le processus de démultiplexage (après le déballage d'une vidéo) est également compliqué. Vous devez complètement comprendre chacun de ces modules. Bonne chance.

+0

merci pour le pointage! – stemm

+0

Vous êtes les bienvenus! – t0k3n1z3r