Mi manca una cosa fondamentale nella traduzione di un flusso UDP di una sessione SDP in un flusso H.264 decodificabile. Sto testando con una videocamera H.264 e posso riprodurre direttamente il flusso con un player. Quando provo a riprodurre il flusso tradotto, questo non verrà riconosciuto dal giocatore (errore di intestazione mancante). Tuttavia devo decodificare il flusso UDP per poterlo integrare in un'applicazione Java per la quale ci sono alcuni decodificatori in giro.Come convertire i pacchetti UDP H.264 in file multimediale o file riproducibili (deframmentazione)
ho visto molto bene le risposte alle seguenti domande già:
- How to process raw UDP packets so that they can be decoded by a decoder filter in a directshow source filter
- Problem to Decode H264 video over RTP with ffmpeg (libavcodec)
Entrambi hanno alcune piccole differenze che sono fonte di confusione (vedi sotto).
Ma prima diamo un'occhiata alla parte facile. Come vedo dalla fotocamera ci sono pacchetti SPS e PPS inviati. Tutti i pacchetti rimanenti sono frame frammentati indicizzati o meno.
Per tutti i pacchetti senza frame (solo NALUnitType 7 e 8 nel mio caso) I strip dell'intestazione RTP (12 byte) e aggiungi byte iniziali 3 x 0 byte e 1 x 1 davanti (00 00 00 01) .
Per tutti i pacchetti di frame frammentati li ricostruisco secondo la descrizione della risposta 1. Quindi in dettaglio questo significa: Striscia dell'intestazione RTP (basta usarlo per la verifica dei dati). Quindi decodificare dal payload le informazioni sul frammento:
Primo byte: [3 UNITÀ NALI | 5 FRAGMENT TYPE BITS]
Secondo byte: [START BIT | END BIT | BIT RISERVA | 5 NAN UNIT BITS]
Se il bit di avvio è impostato, viene creata una nuova intestazione del payload: [3 NAL UNIT BITS (dal primo byte) | 5 Bit unità NAL (dal secondo byte)]
Questo ci dà un NALUnitType 1 per una fetta non idr o un 5 per una fetta idr. Quale è secondo la specifica.
Prendo questa nuova intestazione del payload (1 byte) e allego il payload senza l'intestazione di 2 byte in un nuovo pacchetto. Tutti i frammenti consecutivi vengono aggiunti allo stesso modo (striscia di 12 byte di intestazione RTP, striscia di 2 byte di informazioni sul tipo di unità) finché non viene visualizzata una informazione sul bit di fine. Quando viene visualizzata la fine, inserisco i byte iniziali (00 00 00 01) davanti a questo pacchetto e lo scrivo nello stream.
Il problema è che non può essere decodificato per motivi sconosciuti. La differenza nella risposta 2 delle risposte che ho letto è che il secondo byte dell'intestazione del payload potrebbe essere inserito anche nel pacchetto tradotto. Ma ho provato entrambi e ancora senza fortuna.
Probabilmente c'è qualcosa di diverso nel nuovo flusso? O faccio un errore nella deframmentazione?
Si scopre che la nuova intestazione del carico utile del frame combinato è sbagliata in qualche modo. Controllerò cosa potrebbe esserci di sbagliato lì. – Thomas
[3 BIT DI UNITÀ NALE (dal primo byte) | 5 BIT DI UNITÀ NALE (dal secondo byte) | 0x40] fa il trucco. Non so perché ancora. – Thomas