¿Cómo puedo mejorar la calidad de video de la aplicación de Android de muestra pjsip pjsua2?
La aplicación de muestra pjsip pjsua2 de Android de muestra predeterminada actual envía una calidad de video muy mala y desea mejorarlos a una calidad de alta definición como mínimo. He intentado usar los métodos siguientes, pero sigue mostrando una calidad de video muy baja. ¿Cómo puedo mejorar la calidad del video saliente? Esta aplicación de muestra puede recibir una calidad de video de hasta 355 * 288 de otra videollamada sip, pero envía una calidad de video muy pobre. Actualmente, he intentado lograr video HD actualizando el valor a continuación del archivo MediaFormatvideo, justo antes de realizar la llamada saliente. Y no ayuda en absoluto a mejorar el video saliente. ¿Estoy actualizando esos atributos en lugares incorrectos?
Actualmente envía una calidad de video por debajo de 192 * 144 y no acepta una calidad de video por encima de 352 * 288. ¿Cómo puedo actualizarlo para que admita al menos una calidad de video de 1280 * 720?
MediaFormatVideo mf=new MediaFormatVideo();
mf.setFpsNum(30);
mf.setFpsDenum(1);
mf.setAvgBps(512000);
mf.setMaxBps(1024000);
mf.setHeight(720);
mf.setWidth(1280);
Estoy actualizando la configuración de la siguiente manera.
MyCall call = new MyCall(account, -1);
CallOpParam prm = new CallOpParam(true);
AccountVideoConfig avc=new AccountVideoConfig();
MediaFormatVideo mf=new MediaFormatVideo();
Log.e("javan-video",String.valueOf(avc.getAutoShowIncoming()));
Log.e("javan-videofps",String.valueOf(mf.getFpsNum()));
mf.setFpsNum(30);
mf.setFpsDenum(1);
mf.setAvgBps(512000);
mf.setMaxBps(1024000);
mf.setHeight(720);
mf.setWidth(1280);
Log.e("javan-videofps",String.valueOf(mf.getFpsNum()));
try {
call.makeCall("sip:"+dialno+"@peoplefone.ch", prm);
AudioManager am = (AudioManager) getSystemService(Context.AUDIO_SERVICE);
am.setSpeakerphoneOn(true);
// startRinging();
} catch (Exception e) {
call.delete();
return;
}
currentCall = call;
showCallActivity();
}
Encontré una documentación, intenté implementarla ... pero no pude mejorar la calidad del video
Framerate
Specify number of frames processed per second.
For encoding direction, configured via pjmedia_vid_codec_param.enc_fmt.det.vid.fps, e.g:
/* Sending @30fps */
param.enc_fmt.det.vid.fps.num = 30;
param.enc_fmt.det.vid.fps.denum = 1;
Note:
that there is a possibility that the value will be adjusted to follow remote capability. For example, if remote signals that maximum framerate supported is 10fps and locally the encoding direction framerate is set to 30fps, then 10fps will be used.
limitation: if preview is enabled before call is established, capture device will opened using default framerate of the device, and subsequent calls that use that device will use this framerate regardless of the configured encoding framerate that is set above. Currently the only solution is to disable preview before establishing media and re-enable it once the video media is established.
For decoding direction, two steps are needed:
pjmedia_vid_codec_param.dec_fmt.det.vid.fps should be set to the highest value expected for incoming video framerate.
signalling to remote, configured via codec specific SDP format parameter (fmtp): pjmedia_vid_codec_param.dec_fmtp.
H263-1998, maximum framerate is specified per size/resolution basis, check here for more info.
/* 3000/(1.001*2) fps for CIF */
param.dec_fmtp.param[m].name = pj_str("CIF");
param.dec_fmtp.param[m].val = pj_str("2");
/* 3000/(1.001*1) fps for QCIF */
param.dec_fmtp.param[n].name = pj_str("QCIF");
param.dec_fmtp.param[n].val = pj_str("1");
H264, similar to size/resolution, the framerate is implicitly specified in H264 level (check the standard specification or this) and the H264 level is signalled via H264 SDP fmtp profile-level-id, e.g:
/* Can receive up to 1280×720 @30fps */
param.dec_fmtp.param[n].name = pj_str("profile-level-id");
param.dec_fmtp.param[n].val = pj_str("xxxx1f");
Bitrate
Specify bandwidth requirement for video payloads stream delivery.
This is configurable via pjmedia_vid_codec_param.enc_fmt.det.vid.avg_bps and pjmedia_vid_codec_param.enc_fmt.det.vid.max_bps, e.g:
/* Bitrate range preferred: 512-1024kbps */
param.enc_fmt.det.vid.avg_bps = 512000;
param.enc_fmt.det.vid.max_bps = 1024000;
Notes:
This setting is applicable for encoding and decoding direction, currently there is no way to set asymmetric bitrate. By decoding direction, actually it just means that this setting will be queried when generating bandwidth info for local SDP (see next point).
The bitrate setting of all codecs will be enumerated and the highest value will be signalled in bandwidth info in local SDP (see ticket #1244).
There is a possibility that the encoding bitrate will be adjusted to follow remote bitrate setting, i.e: read from SDP bandwidth info (b=TIAS line) in remote SDP. For example, if remote signals that maximum bitrate is 128kbps and locally the bitrate is set to 512kbps, then 128kbps will be used.
If codec specific bitrate setting signalling (via SDP fmtp) is desired, e.g: MaxBR for H263, application should put the SDP fmtp manually, for example:
/* H263 specific maximum bitrate 512kbps */
param.dec_fmtp.param[n].name = pj_str("MaxBR");
param.dec_fmtp.param[n].val = pj_str("5120"); /* = max_bps / 100 */
enlace de documentación: introduzca aquí la descripción del enlace
From: "0525512904" <sip:[email protected]>;tag=1609930889511
I: To: <sip:[email protected]>;tag=c6ce5331-3a35-44c8-bb80-23b6ec664085
I: CSeq: 1 INVITE
I: Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
I: Contact: <sip:[email protected]:45483;transport=TLS;ob>
I: Supported: replaces, 100rel, timer, norefersub
I: Content-Type: application/sdp
I: Content-Length: 580
I: v=0
I: o=- 3818919690 3818919691 IN IP4 192.168.3.135
I: s=pjmedia
I: b=AS:352
I: t=0 0
I: a=X-nat:0
I: m=audio 4012 RTP/AVP 96 120
I: c=IN IP4 192.168.3.135
I: b=TIAS:64000
I: a=rtcp:4031 IN IP4 192.168.3.135
I: a=sendrecv
I: a=rtpmap:96 speex/16000
I: a=rtpmap:120 telephone-event/16000
I: a=fmtp:120 0-16
I: a=ssrc:1510027056 cname:365aaa4f448493db
I: m=video 4013 RTP/AVP 97
I: c=IN IP4 192.168.3.135
I: b=TIAS:256000
I: a=rtcp:4033 IN IP4 192.168.3.135
I: a=sendrecv
I: a=rtpmap:97 H264/90000
I: a=fmtp:97 profile-level-id=42e01e; packetization-mode=1
I: a=ssrc:1146236185 cname:365aaa4f448493db
I: a=rtcp-fb:* nack pli
I: --end msg--
E: ringing call
registro completo enlace sip llamada registro completo
Respuestas
Todavía no puedo responder tu pregunta con la información proporcionada.
SDP se utiliza como el tipo de carga útil del protocolo SIP .
Puede ver eso en su registro SIP (parcial) aquí:
Content-Type: application/sdp
SDP es un protocolo de oferta / respuesta.
Dado el recorte de registro incompleto que ha proporcionado el SIP INVITE (supongo que no ha dado el mensaje SIP ENTERO), por lo que ha dado la OFERTA solo del procotol SDP. Entonces, obtenga una imagen completa que necesita para proporcionar tanto la OFERTA como la RESPUESTA.
También sería bueno incluir también el otro registro de PJSIP alrededor de la configuración del codificador / decodificador de video.
En tu oferta dice:
m=video 4013 RTP/AVP 97
Esto significa que puede enviar / recibir video con los parámetros:
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e; packetization-mode=1
Esto significa que puede enviar / recibir H264 con una frecuencia de muestreo de 90000 (es decir, 90 kHz).
La configuración de los parámetros de H264 es: a = fmtp: 97 profile-level-id = 42e01e; modo de paquetización = 1
Entonces...
profile-level-id=42e01e
https://tools.ietf.org/html/rfc6184
profile-level-id: A base16 [7] (hexadecimal) representation of the following three bytes in the sequence parameter set NAL unit is specified in [1]: 1) profile_idc, 2) a byte herein referred to as profile-iop, composed of the values of constraint_set0_flag, constraint_set1_flag, constraint_set2_flag, constraint_set3_flag, constraint_set4_flag, constraint_set5_flag, and reserved_zero_2bits in bit- significance order, starting from the most-significant bit, and 3) level_idc. Note that reserved_zero_2bits is required to be equal to 0 in [1], but other values for it may be specified in the future by ITU-T or ISO/IEC.
profile_idc: 0x42 (66) perfil-iop: 0xE0 (binario 11100000) level_idc: 0x1E (30)
https://en.wikipedia.org/wiki/Advanced_Video_Coding
profile_idc: 66
Perfil de línea de base (BP, 66) Principalmente para aplicaciones de bajo costo que requieren robustez de pérdida de datos adicional, este perfil se utiliza en algunas aplicaciones móviles y de videoconferencia. Este perfil incluye todas las funciones que se admiten en el perfil de línea de base restringido, además de tres funciones adicionales que se pueden utilizar para la solidez de la pérdida (o para otros fines, como la composición de secuencias de vídeo multipunto de bajo retraso). La importancia de este perfil se ha desvanecido un poco desde la definición del perfil de línea de base restringido en 2009. Todos los trenes de bits de perfil de línea de base restringido también se consideran trenes de bits de perfil de línea de base, ya que estos dos perfiles comparten el mismo valor de código de identificación de perfil.
perfil-iop: binario 11100000
Esto significa:
constraint_set0_flag=1 (Constrained Baseline profile)
constraint_set1_flag=1
constraint_set2_flag=1
Estos dos valores IDC y los indicadores de restricción se utilizan para configurar los codificadores de vídeo en función de lo que pueden admitir los decodificadores.
Niveles: 30 ie 3.0
Level: 3.0 Maximum decoding speed (macroblocks/s): 40,500 Maximum
frame size (macroblocks): 1,620 Maximum video bit rate for video
coding layer (VCL): 10,000 Examples for high resolution @ highest
frame rate (maximum stored frames):
352×[email protected] (12)
352×[email protected] (10)
720×[email protected] (6)
720×[email protected] (5)
El nivel de perfil no especifica una resolución de video, se especifica manualmente un tamaño máximo de fotograma / tasa de bits. CUALQUIER combinación de resolución / velocidad de fotogramas que pueda "encajar" dentro de estas limitaciones es válida. Aquí es donde esta es una lista de resolución / framerates que se enumeran como válidos.
Entonces, 720 × 480 @ 30fps O 720 × 576 @ 25fps son válidos para enviar para el perfil de nivel 3.0.
Lo que la oferta le está diciendo al otro lado es que:
- Este lado solo puede DECODIFICAR el flujo codificado del perfil de línea de base restringido H264.
- Este lado solo puede DECODIFICAR velocidades de bits de hasta el nivel 3.0 (es decir, la lista de combinaciones de resoluciones / fps anterior)
La oferta no dice QUÉ enviará el dispositivo al otro lado, sino que esto dependerá de su configuración local combinada con lo que el otro lado dice que puede DESCODIFICAR.
PJSIP "elegirá" la mejor resolución / fps que puede enviar en función de su configuración y la decodificación de oferta admitida (por eso puede ver los registros de PJSIP sobre la configuración del codificador) para saber qué está enviando según la RESPUESTA SDP (no suministrado).
El video no tiene que ser simétrico. es decir, dependiendo de la cámara / pantalla H / W, puede mostrar diferentes resoluciones que lo que puede enviar.
Esto tampoco tiene en cuenta cosas como las resoluciones que cambian dinámicamente durante la transmisión (por ejemplo, cambio vertical / horizontal o aumento / disminución de la resolución según los cambios de ancho de banda de la red de los informes RTCP). La única forma de analizar esto puede ser capturar y decodificar la transmisión H264 para comprender lo que está haciendo. El registro de PJSIP también puede informarle.
ACTUALIZAR
Si observa la salida de registro de pjsip, puede ver tanto la oferta de SDP en INVITE como la respuesta en 200 OK.
I: 11:13:36.176 pjsua_core.c .RX 1119 bytes Response msg 200/INVITE/cseq=22580 (rdata0x6f73203b18) from TLS 95.128.80.3:5061:
I: SIP/2.0 200 OK
I: To: <sip:[email protected]>;tag=61c5c92f
I: Via: SIP/2.0/TLS 146.4.49.20:49305;received=146.4.49.20;rport=49305;branch=z9hG4bKPjdad60ffa-6072-4c6d-8eb1-4a32ab26443a;alias
I: Record-Route: <sip:95.128.80.5;r2=on;lr=on;did=e8.cc62>,<sip:95.128.80.3:5061;transport=tls;r2=on;lr=on;did=e8.cc62>
I: CSeq: 22580 INVITE
I: Call-ID: 0e7676b2-1ca2-48b2-9696-f7e6dc7e1ec9
I: From: <sip:[email protected]>;tag=0b4094bb-b47e-4132-960c-ac564015efa0
I: Content-Type: application/sdp
I: Contact: <sip:[email protected]:5060;alias=95.128.80.93~5060~1>
I: Content-Length: 535
I: v=0
I: o=- 3819003211 3819003212 IN IP4 95.128.80.5
I: s=pjmedia
I: b=AS:352
I: t=0 0
I: a=X-nat:0
I: m=audio 20918 RTP/AVP 96 120
I: c=IN IP4 95.128.80.5
I: b=TIAS:64000
I: a=rtpmap:96 speex/16000
I: a=rtpmap:120 telephone-event/16000
I: a=fmtp:120 0-16
I: a=ssrc:1254727526 cname:496ca0741b8de59f
I: a=sendrecv
I: a=rtcp:20919
I: m=video 20956 RTP/AVP 97
I: c=IN IP4 95.128.80.5
I: b=TIAS:256000
I: a=rtpmap:97 H264/90000
I: a=fmtp:97 profile-level-id=42e01e; packetization-mode=1
I: a=ssrc:977888024 cname:496ca0741b8de59f
I: a=rtcp-fb:* nack pli
I: a=sendrecv
I: a=rtcp:20957
I: --end msg--
En la respuesta, puede ver que respondió con los mismos parámetros H264 que la oferta:
I: m=video 20956 RTP/AVP 97
...
I: a=rtpmap:97 H264/90000
I: a=fmtp:97 profile-level-id=42e01e; packetization-mode=1
Por lo tanto, aceptará velocidades de bits de hasta H264 nivel 3.0.
Si nos fijamos en la inicialización del dispositivo de captura (cámara) vemos estos registros:
I: 11:13:36.270 vid_port.c .........Opening device OpenGL renderer [OpenGL] for render: format=I420, size=352x288 @15:1 fps
Esto significa que la cámara frontal de Android se ha abierto a una resolución de 352x288 @ 15fps.
Supongo que esta es la causa de la calidad del video de la que estás hablando.
Mirando el código fuente de pjsip, enumera las cámaras con los parámetros admitidos.
El tamaño de resolución de captura admitido se determina luego por el tamaño de resolución de captura predeterminado reducido en función de los tamaños de resolución "permitidos" que se pueden enviar.
Dado que los tamaños permitidos son superiores a 352x288 @ 15, solo puedo asumir que la resolución de captura predeterminada de Andriod de su cámara frontal es 352x288 @ 15.
Puede intentar usar la cámara trasera en lugar de la cámara frontal para ver si obtiene una solución getter u otro dispositivo Andriod que tenga una cámara frontal mejor.
PjSip utiliza la API android.hardware.Camera para acceder y utilizar los dispositivos de la cámara. Consulte PjCameraInfo y PjCamera para obtener detalles sobre cómo pjsip usa los dispositivos de la cámara.