Récupérer les dimensions d'un flux H264Video

Non!!!

vous devez exécuter une fonction complexe pour extraire les dimensions vidéo des ensembles de paramètres de séquence. Comment faire cela? Vous devez d'abord écrire votre propre décodeur Exp-Golomb, ou en trouver un en ligne... dans le code source live555 quelque part il y en a un par exemple...

alors vous devez obtenir un cadre SPS. Il a NAL=0x67 (NAL est le premier octet dans un cadre H. 264) et vous pouvez le trouver sousZ0KAKYiLQDIBL0IAAB1MAAK/IAg= vous devez décoder quelque chose comme ça de Base64 dans un tableau d'octets.

alors vous devez extraire la charge brute de la séquence D'octets qui est suivi par L'en-tête de L'unité NAL dans ce tableau d'octets!!! Il est généralement d'un octet long, mais lisez sur juste pour être sûr... RBSP contient les octets nécessaires pour exécuter le seq_parameter_set_data( ) fonction. Donc vous devez enlever l'en-tête de L'unité NAL la première (un ou plusieurs octets).

Voici la fonction qui extrait les octets RBSP de L'unité SPS NAL:

alors quand vous avez SPS (RBSP bytes) vous devez effectuer une fonction qui parse les bits dans ce tableau d'octets. Voici la fonction avec tous les paramètres analysés (le document entier peut être trouvé ici: http://www.itu.int/rec/T-REC-H.264-201003-I/en et son En fr.):

Là, vous pouvez voir certains trucs étranges... tout d'abord, vos dimensions vidéo sont calculées comme suit:

Width = ((pic_width_in_mbs_minus1 +1)*16) - frame_crop_right_offset*2 - frame_crop_left_offset*2;
Height = ((2 - frame_mbs_only_flag)* (pic_height_in_map_units_minus1 +1) * 16) - (frame_crop_top_offset * 2) - (frame_crop_bottom_offset * 2);

Deuxièmement, et le plus important, dans la colonne descripteur de ce tableau de code, est indiqué ce que vous devez faire pour lire le paramètre texte en caractères gras dans la première colonne. C'est ce que les valeurs de y dire:

• u (N) - Lire un nombre non signé qui est N bits
• s (N) - lire un numéro signé qui est N bits long
• ue (v) -lisez un numéro Exp-Golomb non signé (v est pour la longueur variable, donc c'est la même chose que ue())
• se (v) - lire un numéro Exp-Golomb signé

C'est là que votre décodeur Exp-Golomb est utile...

donc, implémentez cette fonction, passez SPS, et vous obtiendrez votre largeur et votre hauteur. Profiter... :)

les calculs de taille sont malheureusement erronés et devraient être:

width = ((pic_width_in_mbs_minus1 +1)*16) - frame_crop_left_offset*2 - frame_crop_right_offset*2;
height= ((2 - frame_mbs_only_flag)* (pic_height_in_map_units_minus1 +1) * 16) - (frame_crop_top_offset * 2) - (frame_crop_bottom_offset * 2);

en fait, les paramètres de recadrage ne doivent être utilisés que lorsque [frame_cropping_flag] est activé dans SPS. Profitez De H. 264!

en ce qui concerne le calcul de la taille de trame, la formule ci-dessus n'est pas correcte.

Quand chroma_format_idc est présent, alors il faut l'extraire du SPS. Lorsque chroma_format_idc n'est pas présent, il est supposé être égal à 1 (format chroma 4:2:0). Dans ce cas, le separate_color_plane_flag n'est pas définie. Cela signifie que chromaArrayType = chroma_format_idc et subWidthC et subHeightC sont uqual à 2.

les variables cropUnitX et cropUnitY sont dérivées comme suit:

• Si chromaArrayType est égal à 0,cropUnitX et cropUnitY sont dérivés comme:

  cropUnitX = 1
  cropUnitY = 2 - frame_mbs_only_flag
  

• Sinon (chromaArrayType est égal à 1,2, ou 3),cropUnitX et cropUnitY sont dérivés comme:

  cropUnitX = subWidthC
  cropUnitY = subHeightC * ( 2 - frame_mbs_only_flag )
  

Maintenant, vous pouvez utiliser cropUnitX et cropUnitY dans la formule ci-dessus pour obtenir les valeurs correctes pour la taille du cadre.