h264 RTP timestamp

Question

Ho una confusione sul timestamp del pacchetto RTP h264. So che la frequenza di clock del video è di 90 KHz che ho definito nel SIP SDP. Il frame rate del mio encoder non è esattamente di 30 FPS, è variabile. Al volo varia da 15 FPS a 30 FPS. Quindi, non posso usare alcun timestamp fisso.

Qualcuno potrebbe dirmi il timestamp del seguente pacchetto codificato.
Dopo 0 millisecondi codificato RTP timestamp = 0 (Lasciare il timestamp di partenza 0)
Dopo il timestamp RTP con codifica di 50 millisecondi =?
Dopo 40 millisecondi con timestamp RTP =?
Dopo il timestamp RTP con codifica di 33 millisecondi =?

Qual è la formula quando la frequenza fotogrammi codificata è variabile?

Grazie in anticipo.

Answer 1

Non importa se il codificatore codifica video a 10 FPS o 30 FPS, con il timestamp RTP si indica al ricevitore quanto è lunga la pausa tra i due fotogrammi. Quindi lo decidi al volo per ogni fotogramma. In questo modo puoi inviare 10 fotogrammi in un secondo (10 fps) e in un secondo puoi inviare 30 fotogrammi (30 fps). È sufficiente impostare correttamente il timestamp RTP. E se ricevo la tua domanda, sei nel dubbio su come farlo ...

Lascia che il timestamp iniziale sia 0, aggiungi il tempo dell'orologio a muro in millisecondi moltiplicato per 100 all'ultimo timestamp RTP, oppure puoi usa qualsiasi scala temporale che desideri. Per rendere la decodifica di video 10fps decoder a 30 fps, aggiungere 333000 alla RTP timestamp per ogni pacchetto ... ma consente di guardare il tuo esempio:

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

Quindi, se si imposta la RTP timestamp come questo (Time in ms * 100000) si farà carico decoder e decodificare il Frame 1, quindi caricare e decodificare il Frame 2, ma dormirà per 50 ms (differenza di tempo tra Frame 1 e Frame 2) prima di disegnare il Frame 2, e così via ...

E come voi può vedere, il decoder utilizza i timestamp RTP per sapere quando visualizzarli e non importa se il video è stato codificato a 30 o 10 fps.

Inoltre, se il video è 30 fps, ciò non significa che per ogni secondo ci saranno 30 pacchetti RTP. A volte possono esserci più di 100, quindi non è possibile avere una formula che assicuri il corretto calcolo del timestamp RTP.

immagino che questo è quello che ti serve ... speranza ho aiutato, Non -1 me se non ha ancora ... =)

Answer 2

non esiste una formula semplice per questo.

L'istante utilizzato per il campionamento del fotogramma prima della codifica viene chiamato PTS (timestamp di presentazione). È fuori dall'ambito del codificatore, è necessario ricordarlo nel flusso di dati quando si acquisiscono i frame.

Da lì, ci sono 2 possibilità:

1. L'encoder H264 non genera B-frame, quindi il timestamp RTP dovrebbe essere il PTS + casuale offset (lo stesso per tutte le sessioni in streaming)
2. Se l'encoder genera B-frame (o B-slices), allora l'ordine di decodifica deve essere modificato, poiché B-frame richiede la decodifica del prossimo frame, quindi deve essere inviato prima.

In quest'ultimo caso, l'RFC6184 afferma che si dispone di più modalità per lo streaming delle unità NAL codificate.

La maggior parte del software di streaming utilizza la modalità denominata "Non interlacciata", in cui è necessario impostare il timestamp RTP sull'offset PTS +, ma inviarli nell'ordine di decodifica in modo che il timestamp non aumenti monotonicamente. Ciò significa anche che il client dovrà decodificare nell'ordine ricevuto e non riordinare i frame nell'ordine PTS.

non sto usando il termine DTS qui per un motivo, perché non è necessario la decodifica timestamp per far funzionare tutto questo, solo l'ordine.

L'ultima modalità descritta in RFC6184 è il cosiddetto ordine interfogliato in cui è possibile riordinare le unità NAL. In tal caso, è necessario implementare alcune logiche dell'applicazione per riordinare le unità, fare riferimento a RFC6184 per i dettagli.