horodatage RTP H264

Question

J'ai une confusion à propos de l'horodatage de H264 paquet RTP. Je sais que la fréquence d'horloge murale de la vidéo est 90kHz que je défini dans le SIP SDP. Le taux de trame de mon encodeur est pas exactement 30 FPS, il est variable. Il varie de 15 FPS à 30 FPS à la volée. Donc, je ne peux pas utiliser un horodatage fixe.

Quelqu'un pourrait-il me dire l'horodatage du paquet codé suivant.
Après 0 milisecond horodatage RTP codé = 0 (Soit l'horodatage 0 démarrage)
Après 50 milisecond codé horodatage RTP =?
Après 40 milisecond codé horodatage RTP =?
Après 33 milisecond codé horodatage RTP =?

Quelle est la formule lorsque le taux de trame codée est variable?

Je vous remercie à l'avance.

Answer 1

Peu importe si votre codeur code vidéo à 10fps ou 30fps, avec horodatage RTP vous dire le récepteur combien de temps est la pause entre les deux cadres. Donc, vous déterminez que à la volée pour chaque trame. De cette façon, vous pouvez envoyer 10 images en une seconde (10fps), et dans d'autres secondes, vous pouvez envoyer 30 images (30 images par seconde). Il vous suffit de définir correctement l'horodatage RTP. Et si je reçois votre question, vous êtes dans le doute comment faire ...

Laissez l'horodatage de départ soit 0, vous ajoutez le temps d'horloge murale en millisecondes multiplié par 100 au dernier horodatage RTP, ou vous pouvez utiliser une échelle de temps que vous voulez. Pour le décodeur de décoder une vidéo de 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 du décodeur et décoder l'image 1, puis chargez et decode Frame 2, mais il dormira pendant 50 ms (différence de temps entre l'image 1 et image 2) avant tire le cadre 2, et ainsi de suite ...

Et comme vous pouvez le voir, le décodeur utilise RTP estampilles pour savoir quand afficher chacun, et il ne marche pas l'esprit si la vidéo a été encodée à 30 ou 10 images par seconde.

En outre, si la vidéo est de 30 images par seconde, cela ne signifie pas que pour chaque seconde, il y aura 30 paquets RTP. Parfois, il peut y avoir plus de 100, de sorte que vous ne pouvez pas avoir une formule qui assure le calcul d'horodatage RTP correct.

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 échantillonner le cadre avant le codage est appelé PTS (horodatage de présentation). Il est hors de la portée du codeur, vous devez vous rappeler dans votre flux de données lors de la capture des images.

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

1. L'encodeur H264 ne génère pas d'image 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 B tranches), l'ordre de décodage doit être modifié, puisque image B nécessite la trame suivante à décoder, donc il doit être envoyé avant.

Dans ce dernier cas, le RFC6184 indique que vous avez de façon multiple pour diffuser les unités NAL codées.

La plupart des logiciels de streaming utilisera le mode appelé « non entrelacée », dans lequel, vous devez définir l'horodatage RTP au PTS + offset, mais les envoyer dans l'ordre de décodage de sorte que le timestamp ne sera pas augmenter de façon monotone. Cela signifie également que le client devra décoder dans l'ordre reçu et non réordonner les images dans l'ordre PTS.

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

Le dernier mode décrit dans RFC6184 est l'ordre entrelacée soi-disant où vous pouvez réorganiser les unités NAL. Dans ce cas, vous devez mettre en œuvre une logique d'application pour réorganiser les unités, reportez-vous RFC6184 pour plus de détails.