h264 Horodatage RTP

Question

J'ai une confusion à propos de l'horodatage du paquet RTP h264. Je sais que le taux d'horloge de la vidéo est de 90KHz que j'ai défini dans le SDP SIP. Le taux de trame de mon encodeur n'est pas exactement de 30 FPS, c'est variable. Il varie de 15 FPS à 30 FPS à la volée. Donc, je ne peux pas utiliser d'horodatage fixe.

Quelqu'un peut-il me dire l'horodatage du paquet codé suivant.
Après l'horodatage RTP codé sur 0 milliseconde = 0 (Laisser l'horodatage de départ 0)
Après 50 millisecondes d'encodage codé RTP =?
Après l'horodatage RTP codé sur 40 millisecondes =?
Après l'horodatage RTP codé sur 33 millisecondes =?

Quelle est la formule lorsque la fréquence d'images codée est variable?

Merci d'avance.

Answer 1

Peu importe si votre encodeur code une vidéo à 10FPS ou 30FPS, avec l'horodatage RTP, vous indiquez au récepteur la durée de la pause entre les deux images. Donc, vous déterminez à la volée pour chaque image. De cette façon, vous pouvez envoyer 10 images en une seconde (10fps), et en une seconde vous pouvez envoyer 30 images (30 fps). Vous devez seulement définir l'horodatage RTP correctement. Et si j'ai votre question, vous êtes dans le doute comment faire ceci ...

Laissez l'horodatage de départ être 0, vous ajoutez l'horloge murale en millisecondes multiplié par 100 à la dernière horodatage RTP, ou vous pouvez utilisez n'importe quelle échelle de temps que vous voulez. Pour le décodeur décodage vidéo 10fps à 30fps, ajouter 333000 à horodatage RTP pour chaque paquet ... mais permet de regarder votre exemple:

Frame #  RTP Time Time between frames [ms] 
[ 1]    0 0 
[ 2]   50000 50 
[ 3]   90000 40 
[ 4]   420000 33 

Donc, si vous définissez l'horodatage RTP comme celui-ci (Time in ms * 100000) vous ferez la charge de décodeur et décoder le cadre 1, puis charger et décoder le cadre 2, mais il va dormir pendant 50 ms (différence de temps entre les images 1 et 2) avant de dessiner le cadre 2, et ainsi de suite ...

Et comme vous peut voir, le décodeur utilise des horodatages RTP pour savoir quand afficher chacun, et cela ne dérange pas si la vidéo a été encodée à 30 ou 10 fps. De plus, si la vidéo est à 30 ips, cela ne veut pas dire que pour chaque seconde il y aura 30 paquets RTP. Parfois, il peut y en avoir plus de 100, donc vous ne pouvez pas avoir une formule qui assure le bon calcul d'horodatage RTP.

Je suppose que c'est ce que vous avez besoin ... J'espère aidé, me DonT -1 si je na pas ... =)

Answer 2

Il n'y a pas de formule simple pour cela.

L'instant utilisé pour l'échantillonnage de la trame avant le codage est appelé PTS (horodatage de présentation). Il est hors de la portée de l'encodeur, vous devez vous en souvenir dans votre flux de données lorsque vous capturez les images.

À partir de là, vous avez 2 possibilités:

1. L'encodeur H264 ne génère pas de cadre B, puis l'horodatage RTP doit être le PTS + décalage aléatoire (la même pour toutes les sessions de streaming)
2. Si le codeur génère des trames B (ou des tranches B), alors l'ordre de décodage doit être modifié, puisque l'image B nécessite que l'image suivante soit décodée, elle doit donc être envoyée avant.

Dans ce dernier cas, la RFC6184 indique que vous avez plusieurs façons de diffuser les unités NAL codées. La plupart des logiciels de streaming utilisent le mode "Non entrelacé", dans lequel vous devez définir l'horodatage RTP sur le décalage PTS +, mais les envoyer dans l'ordre de décodage pour que l'horodatage n'augmente pas de façon monotone. Cela signifie également que le client devra décoder dans l'ordre reçu et ne pas réorganiser les trames dans l'ordre PTS.

Je ne suis pas en utilisant le terme DTS ici pour une raison, parce que vous n'avez pas besoin du décodage horodatage pour que cela fonctionne, seul l'ordre.

Le dernier mode décrit dans la RFC 6184 est l'ordre dit entrelacé dans lequel vous pouvez réorganiser les unités NAL. Dans ce cas, vous devez implémenter une logique d'application pour réorganiser les unités, reportez-vous à RFC6184 pour plus de détails.