H264 RTP timestamp

Question

Ho una confusione circa il timestamp H264 pacchetto RTP. So che la frequenza di clock parete del video è 90KHz, che ho definito nel SIP SDP. Il frame rate della mia encoder non è esattamente 30 FPS, è variabile. Esso varia da 15 fps a 30 fps al volo. Quindi, non posso utilizzare alcun timestamp fisso.

Potrebbe uno mi dica il timestamp del seguente pacchetto codificato.
Dopo 0 milisecond codificato RTP timestamp = 0 (Let il timestamp di partenza 0)
Dopo 50 milisecond codificato RTP timestamp =?
Dopo 40 milisecond codificato RTP timestamp =?
Dopo 33 milisecond codificato RTP timestamp =?

Qual è la formula quando il frame rate codificato è variabile?

Grazie in anticipo.

Answer 1

Non importa se il codificatore codifica video a 10FPS o 30FPS, con la RTP timestamp dici il ricevitore per quanto tempo è la pausa tra i due telai. Così si stabilisce che al volo per ogni fotogramma. In questo modo è possibile inviare 10 fotogrammi in un secondo (10 fps), e in due secondi è possibile inviare 30 fotogrammi (30 fps). Hai solo bisogno di impostare correttamente il timestamp RTP. E se ho la tua domanda, siete in dubbio come fare questo ...

Che la partenza timestamp essere 0, si aggiunge il tempo di orologio da parete in millisecondi, moltiplicato per 100 per l'ultimo timestamp RTP, oppure è possibile utilizzare qualsiasi scala volta che si desidera. 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 fotogramma 1, quindi caricare e decodificare Frame 2, ma sarà dormire per 50 ms (differenza di tempo tra il fotogramma 1 e Frame 2) prima che disegna il fotogramma 2, e così via ...

E come si può vedere, il decodificatore utilizza RTP timestamp per sapere quando per visualizzare ogni uno, e si pretende molto importa se il video è stato codificato a 30 o 10 fps.

Inoltre, se il video è 30 fps, questo non significa che per ogni secondo ci saranno 30 pacchetti RTP. A volte ci possono essere più di 100, quindi non si può avere una formula che garantisce il corretto calcolo RTP timestamp.

Credo che questo è ciò che vi serve ... spero aiutato, Non -1 me se non ha ancora ... =)

Answer 2

Non esiste una formula semplice per questo.

L'istante utilizzato per campionare il telaio prima della codifica è chiamato PTS (presentazione timestamp). E 'fuori del campo di applicazione del codificatore, si deve ricordare che nel vostro flusso di dati quando si cattura 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 il codificatore genera fotogrammi B (o B-fette), allora l'ordine di decodifica deve essere modificato, in quanto B-frame richiede il fotogramma successivo da decodificare, quindi deve essere inviato prima.

In quest'ultimo caso, la RFC6184 afferma che avete modo multiplo per lo streaming delle unità NAL codificati.

La maggior parte del software di streaming utilizzerà la modalità chiamata "non Interleaved", in cui, è necessario impostare il timestamp RTP al PTS + offset, ma li invia in ordine di decodifica in modo che il timestamp non aumenterà in modo monotono. Questo significa anche il cliente dovrà decodificare in 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 interlacciato dove è possibile riordinare le unità NAL. In tal caso, è necessario implementare una logica applicazione per riordinare le unità, fare riferimento al RFC6184 per i dettagli.