2008-10-02 15 views
10

Me gustaría cambiar dinámicamente la fuente de video en una aplicación de transmisión de video. Sin embargo, las diferentes fuentes de video tienen dimensiones de imagen únicas. Puedo generar archivos SDP individuales para cada fuente de video, pero me gustaría combinarlos en un único archivo SDP para que el cliente de visualización pueda redimensionar automáticamente la ventana de visualización a medida que cambia la fuente de video. He aquí dos ejemplos de archivos SDP:Múltiples transmisiones de video H.264 en una sesión RTP

640x480.sdp:

 
v=0 
o=VideoServerIN IP4 192.168.0.2 
s=VideoStream640x480 
t=0 0 
c=IN IP4 192.168.0.2 
m=video 8000/2 RTP/AVP 96 
a=rtpmap:96 H264/90000 
a=fmtp:96 packetization-mode=0; profile-level-id=4D4033; sprop-parameter-sets=Z01AM5ZkBQHtCAAAAwAIAAADAYR4wZU=,aO48gJ== 
a=control:trackID=1 

960x480.sdp:

 
v=0 
o=VideoServerIN IP4 192.168.0.2 
s=VideoStream960x480 
t=0 0 
c=IN IP4 192.168.0.2 
m=video 8000/2 RTP/AVP 96 
a=rtpmap:96 H264/90000 
a=fmtp:96 packetization-mode=0; profile-level-id=4D4033; sprop-parameter-sets=J01AM5WwPA9sBAIA,KO4G8gA= 
a=control:trackID=1 

¿Cómo pueden estos archivos individuales pueden combinar en un solo archivo SDP?

Respuesta

8

Los parámetros en sus dos ejemplos de sdp son muy similares: el nombre de la secuencia y los conjuntos de parámetros sprop difieren. Supongo que no te importa el nombre de la transmisión. Si necesita sprop parámetros conjuntos separados y los clientes son compatibles con el estándar también se puede utilizar tipos de carga útil dinámica separadas para cada resolución y tienen una sola SDP de la siguiente manera:

 v=0 
    o=VideoServerIN IP4 192.168.0.2 
    s=VideoStream640x480 
    t=0 0 
    c=IN IP4 192.168.0.2 
    m=video 8000/2 RTP/AVP 96 97 
    a=rtpmap:96 H264/90000 
    a=fmtp:96 packetization-mode=0; profile-level-id=4D4033; sprop-parameter-sets=Z01AM5ZkBQHtCAAAAwAIAAADAYR4wZU=,aO48gJ== 
    a=rtpmap:97 H264/90000 
    a=fmtp:97 packetization-mode=0; profile-level-id=4D4033; sprop-parameter-sets=J01AM5WwPA9sBAIA,KO4G8gA= 
    a=control:trackID=1 

Al igual que en otras respuestas si no lo hace en realidad necesita los diferentes nombres de flujo o los diferentes conjuntos de parámetros sprop. Debería poder usar su primer SDP y cambiar el formato a medio flujo. No conozco la carga útil real de H.264 o su decodificador en particular lo suficientemente bien como para garantizar que esto funcione en sus aplicaciones, pero es muy común en las aplicaciones de videoconferencia para permitir el cambio dinámico entre resoluciones sin indicar un cambio o requerir una dinámica separada tipo de carga útil

Aunque puede concatenar dos documentos SDP como se menciona en otra respuesta, no creo que ayude en este caso. H.Los decodificadores 264 solo pueden funcionar con un solo parámetro sprop-parameter-sets en un momento en el que creo. Como ambos SDP tendrían el mismo tipo de carga útil, puerto de origen, etc., el receptor no sabría cuándo usar el parámetro sprop-parameter-sets. ACTUALIZACIÓN: tenga en cuenta que algunas implementaciones obtienen sus sprops en banda y no desde el SDP (o solo inicialmente desde el SDP). Si eso se aplica en el entorno de la SDP sprop parámetros conjuntos pueden ser actualizados en banda

Referencias:

  1. RFC 3984 RTP Payload Format for H.264 Video
  2. New proposed H.264 RTP Payload Format RFC 6184
  3. RFC 4566 SDP: Session Description Protocol

[Lo siento por no dar la cita completa - no dude en corregir]

+0

También me deje caer los parámetros sprop-conjuntos y tenerlos en banda y sólo tienen una línea de medios de comunicación de vídeo. Todos los codificadores h264 los tendrán en banda de todos modos. Entonces tendría algún tipo de canal secundario si desea que el cliente controle el tamaño del video enviado y simplemente cambie de fuente al vuelo. El cliente puede simplemente "detectar" cuando la resolución ha cambiado y cambiar su tamaño de visualización. Esto funcionó bien para mí. El único problema es que debe actualizar los parámetros del SDP si su tamaño (tasa de bits) es mayor que el nivel de perfil especificado (poco probable en 5.1 que están usando). –

2

He revisado el RFC (RFC2327 - SDP: Session Description Protocol) y parece que puede concatenar los dos documentos SDP. El documento establece explícitamente:

Cuando SAP transporta SDP, solo se permite una descripción de sesión por paquete. Cuando SDP se transporta por otros medios, muchas descripciones de sesión SDP pueden concatenarse juntas (la línea `v = 'que indica el inicio de una descripción de sesión termina la descripción anterior).

0

Creo que depende de su decodificador. Si admite el cambio de parámetros dentro de la transmisión, si puede decirle al codificador que coloque el encabezado correspondiente al cambiar la resolución, su decodificador debería cambiar automáticamente.

¿Cuál es su pregunta exactamente? ¿Es esto: cómo puedo cambiar la resolución sin detener/reiniciar la transmisión?

No creo que pueda decir de antemano un decodificador, esta es la posible resolución que verá con algo de magia sdp. O bien su descodificador puede entender el cambio de parámetro H264, y entonces está bien, o tiene que dejar de reiniciar todo, y entonces el sdp dinámico es suficiente.

Sé que, por ejemplo, VLC puede detectar el cambio de codificación MP4 (por ejemplo, pasar de la velocidad de bits variable a la velocidad constante), pero se bloqueará si cambia la resolución Lo único que puede hacer con sdp es combine diferentes descripciones de medios, por ejemplo, con diferentes tipos de carga dinámica y diferentes atributos de control-id.

0

Puede realizar el cambio dinámico de la carga útil o el cambio de conjunto de parámetros in-stream, o SIP re-INVITE.

Los cambios en la carga útil tienen el problema de que si no controlas el codificador y el decodificador necesitas asegurarte de que el otro extremo acepte ambas cargas y que cambien las cargas útiles correctamente (y lo suficientemente rápido para ti; no hay ningún requisito en ese).

los cambios in-stream tienen un problema si los paquetes del conjunto de parámetros se pierden. Puede usar un conjunto diferente de conjuntos de parámetros (cambie del conjunto de parámetros 1 a 2 cuando cambie) para evitar la descodificación incorrecta: si los conjuntos se pierden, debe obtener una imagen congelada o en blanco. Aconsejo retransmitirlos algunas veces (no en una sucesión demasiado rápida).

SIP re-INVITE está fuera de banda y en apretón de manos, y por lo tanto seguro, pero agrega demora a cualquier interruptor y puede fallar dependiendo del receptor, y podría ser rechazado.

(Nota: No soy un autor de RFC 3984bis, la actualización al RFC 3984)

Cuestiones relacionadas