Necesito detectar MPEG4 I-Frame en el paquete RTP. Sé cómo eliminar el encabezado RTP y obtener el marco MPEG4, pero no puedo entender cómo identificar el I-Frame.Detectar MPEG4/H264 I-Frame (IDR) en la secuencia RTP
¿Tiene una firma/cabecera específica?
Ok, así que me di cuenta de la corriente h264.
cómo detectar I-Frame:
No puedo encontrar la corriente MPEG4-ES ... ¿alguna sugerencia?
EDIT: H264 IDR
Este funciona para mi flujo h264 (fmtp:96 packetization-mode=1; profile-level-id=420029;). Acaba de pasar la matriz de bytes que representa el fragmento h264 recibido a través de RTP. Si desea pasar un RTP completo, simplemente corrija el valor RTPHeaderBytes para omitir el encabezado RTP. Siempre obtengo el I-Frame, porque es el único marco que se puede fragmentar, ver here. ¡Utilizo este código (simplificado) en mi servidor, y funciona como un encanto! Si I-Frame (IDR) no está fragmentado, el fragment_type sería 5, por lo que este código devolvería true para los IDR fragmentados y no fragmentados.
public static bool isH264iFrame(byte[] paket)
{
int RTPHeaderBytes = 0;
int fragment_type = paket[RTPHeaderBytes + 0] & 0x1F;
int nal_type = paket[RTPHeaderBytes + 1] & 0x1F;
int start_bit = paket[RTPHeaderBytes + 1] & 0x80;
if (((fragment_type == 28 || fragment_type == 29) && nal_type == 5 && start_bit == 128) || fragment_type == 5)
{
return true;
}
return false;
}
Aquí está la tabla de tipos de unidad NAL:
Type Name
0 [unspecified]
1 Coded slice
2 Data Partition A
3 Data Partition B
4 Data Partition C
5 IDR (Instantaneous Decoding Refresh) Picture
6 SEI (Supplemental Enhancement Information)
7 SPS (Sequence Parameter Set)
8 PPS (Picture Parameter Set)
9 Access Unit Delimiter
10 EoS (End of Sequence)
11 EoS (End of Stream)
12 Filter Data
13-23 [extended]
24-31 [unspecified]
EDIT 2: MPEG4 I-VOP
me olvidó actualizar esta ... Gracias a Che y ISO IEC 14496-2 documento, ¡Pude resolver esto! Che era rito, pero no es tan preciso en su respuesta ... así que aquí es cómo encontrar cuadros I, P y B (I-VOP, P-VOP, B-VOP) en resumen:
000001B6 (hex). Es lo mismo para todos los cuadros MPEG4 (I, P, B)A continuación sigue mucha más información, que no voy a describir aquí (ver el documento IEC), pero solo (como dijo) necesitamos la 2 bits más altos desde el siguiente byte (los siguientes dos bits después del byte con el valor B6). Esos 2 bits que indican al VOP_CODING_TYPE, consulte la tabla:
VOP_CODING_TYPE (binary) Coding method
00 intra-coded (I)
01 predictive-coded (P)
10 bidirectionally-predictive-coded (B)
11 sprite (S)
Por lo tanto, para encontrar siempre el cuadro I encontrar el paquete a partir de cuatro bytes 000001B6 y que tienen los más altos dos bits del byte siguiente 00. Esto encontrará I frame en MPEG4 stream con un tipo de objeto de video simple (no estoy seguro de simple avanzado).
Para cualquier otro problema, puede consultar el documento provisto (ISO IEC 14496-2), aquí encontrará todo lo que necesita saber sobre MPEG4.:)
Por lo que yo sé, fragmentos corriente MPEG4-ES en la carga útil de RTP por lo general comienzan con startcode MPEG4, que puede ser uno de estos:
0x000001b0: visual_object_sequence_start_code (probablemente fotograma clave)0x000001b6 : vop_start_code (fotograma clave, si los dos bits siguientes son cero)0x000001b3: group_of_vop_start_code, que contiene tres bytes y después de esperar un vop_start_code que pueden o no pueden pertenecer a un fotograma clave (ver arriba)0x00000120: video_object_layer_start_code (probablemente fotograma clave)0x00000100-0x0000011f: video_object_start_code (los que parecen fotogramas clave también)Me temo que se le necesita analizar la secuencia para estar seguro: -/
En realidad, era correcto para la secuencia h264, si el valor NAL (primer byte) es 0x7C significa que I-Frame está fragmentado. Ningún otro fotograma (P y B) puede estar fragmentado, por lo que si hay packetization-mode=1 en SDP, significa que los I-Frames están fragmentados y, por lo tanto, si lee 0x7C como primer byte, entonces es I-Frame. Lea más aquí: http://www.rfc-editor.org/rfc/rfc3984.txt.
0x000001b6: vop_start_code (fotograma clave, si los dos bits siguientes son cero) esta es la forma correcta para MPEG-4
Esto funcionó para mí:
- Averiguar el "tipo de carga útil", por ejemplo: Tipo de carga útil: DynamicRTP-Type-96 (96)
- Indica a wireshark qué transmisión es H264: Archivo-> preferences-> protocols-> H264. Ingrese 96 como tipo de carga útil.
- filtro en slice_type: "h264.slice_type eq 7"
Para H264:
Ejemplos:
nal_ref_idc: 3, nal type: 7 (0x07) descripcion: 7 (SPS)<br>
00000000 24 00 00 2B 80 60 22 ED 96 57 3E 68 57 F3 22 B5 $..+.`"í.W>hWó"µ<br>
00000010 67 64 00 1E AD 84 01 0C 20 08 61 00 43 08 02 18 gd..... .a.C...
00000020 40 10 C2 00 84 2B 50 5A 09 34 DC 04 04 04 08 @.Â..+PZ.4Ü....<br>
nal_ref_idc: 3, nal type: 8 (0x08) descripcion: 8 (PPS)<br>
00000000 24 00 00 10 80 60 22 EE 96 57 3E 68 57 F3 22 B5 $....`"î.W>hWó"µ
00000010 68 EE 3C B0 hî<°
FU_A (fragmentation unit A)
nal_ref_idc: 3, nal type: 5 (0x05) descripcion: 5 (IDR (Instantaneous Decoding Refresh) Picture)
00000000 24 00 05 96 80 60 22 F1 96 57 3E 68 57 F3 22 B5 $....`"ñ.W>hWó"µ
00000010 7C 05 A0 AA 2F 81 92 AB CA FE 9E 34 D8 06 AD 74 |. ª/..«Êþ.4Ø.t
...
eso no es correcto (ni de lejos). Puede suceder que funcione para las transmisiones que está viendo. Echa un vistazo a RFC 3984 (que pronto será reemplazado por 3984bis) en el IETF. Tenga en cuenta que puede tener NAL fragmentados (con encabezados de fragmentos, paquetes STAP con múltiples NAL (y el iframe puede comenzar en el segundo NAL de un paquete), etc., etc. Realmente desea escanear todos los NAL en la secuencia de paquetes para NALs que introducen un IDR.Tenga en cuenta que el i-frame/si-frame real puede estar precedido por un conjunto de conjuntos de parámetros de secuencia e imagen, que son * importantes * y deben considerarse parte del IDR (pero no son un marcador) – jesup
Bueno, solo funciona para mí, entonces ... = | – Cipi
@jesup ¿Los conjuntos de parámetros normalmente no se envían fuera de banda? También, ¡hola! Me apetece encontrarlo aquí ... –