¿Por qué el crecimiento provoca un aumento en la nekachestva calidad, o si se debe trabajar la función principal

absurdo discutir con el hecho de que lo analógico CCTV del pasado: las cámaras IP baratas proporcionan una calidad de imagen comparable con cara analógica. Además, las cámaras IP son ilimitados por nada excepto registrador rendimiento, mientras que las cámaras analógicas requieren un estricto cumplimiento de las tarjetas de la recepción, igualando los niveles de la señal del transmisor / receptor / amplificador y otra chamanismo.
El diseño de un sistema basado en cámaras IP en cualquier momento la cámara puede ser removido y reemplazado por una mejor - si aún así mantener la dirección IP y la contraseña de acceso, es probable que ni siquiera tiene que cambiar la configuración del receptor -. Sólo tiene que ir al archivo de imagen mejor < br /> Por otro lado, impone restricciones a la recepcionista - él debe estar dispuesto a trabajar en cualquier resolución, cualquier tasa de bits, cualquier codec y cualquier protocolo ... Bueno, o al menos para que funcione correctamente con el declarado
.


En el mundo del software, hay dos maneras - hay linux vías: una colección de pequeños programas, cada uno de lo que hace una función, pero es muy buena; y hay ventanas vías: Este es un enorme procesadores de alimentos que pueden hacer todo, y un poco más. El problema linux-forma principal - es la falta de interfaz. Para obtener todos los beneficios de fumar tienen mana (o al menos leer --help), y el experimento. Y sólo para averiguar lo que es y lo que se puede combinar y cómo. El principal problema de las ventanas vías - es la pérdida de la función principal. Muy pronto en la dop.funktsionalom ensuciamiento perdido pruebas funcionales clave, y, finalmente, los problemas comienzan incluso con él. Y así comienza la inercia del pensamiento, "esta es la función principal, que está ampliamente probado, sobre todo, no puede haber un error, el usuario está haciendo algo mal».

Ahora ve a nuestras ovejas: ahora hay un aumento constante de la calidad de las cámaras IP. Cualquiera que haya visto la cámara diferencia FullHD instalado en el mismo lugar donde antes había incluso ultrakrutaya 700TVL, no quiero volver (tanto más por el precio que está ahora sobre la misma). Un mayor desarrollo conduce al hecho de que la cámara de 3 megapíxeles (2048x1536) y una de 5 megapíxeles (2592x1944) no son infrecuentes. El único precio para una mejor calidad - aumento de los costos de almacenamiento y transmisión. Sin embargo, la unidad de disco duro gigabyte de precios tiene caídas largas (y bastante recuperado de la inundación en la planta), y por lo tanto no es un problema.

Hoy mismo había una pequeña disputa con maxlapshin sobre el tema de si la nada fabricante de software para el usuario, después de la venta o no. Sí, cualquier software se vende "tal cual" sin ninguna promesa. Por lo tanto, incluso pagando mucho más, usted no consigue el hecho de que incluso el software de trabajo. Eso es sólo si el software no funciona, y es conocido - el flujo de clientes se acabará algún día. A pesar de que se compra, la evidencia de correcciones de errores (y más aún, la implementación de características) bajo la gran pregunta.

Termine la entrada y ver un pequeño pero muy significativo de vídeo (que ni siquiera puede ver - en stop.kadre ver todo):


Este fallo libro de texto que veo casi todo el software diseñado para la grabación de vídeo. Vi esto en VideoNet, consulte regularmente en Axxon A continuación, como se puede ver en el vídeo - que me saludó Trassir. La misma canoa, incluso en su propio visor de la cámara. Sería posible escribir de todos los problemas y la cámara. Se puede atribuir a la red. Puede ser una gran carga en la CPU. Posible a las interferencias electromagnéticas. Puede ser recomendable comprobar la memoria. Puede volver a instalar el sistema. En general, los métodos en lugar de proceder a hacer que una persona принести aseo ...
Éstos son sólo conectado a la misma flujo a través de RTSP vlc no hay artefactos y problemas técnicos - no. En el mismo equipo funciono nakolenny script de prueba que lee de la corriente y la cámara graba en disco - y sin pérdida y sin problemas, y por lo tanto es sólo un método -. Para reducir la resolución de la cámara y la reducción de la tasa de bits

Es decir, a pesar de la flexibilidad, alegando que es un montón de cámaras de trabajo sobre ONVIF y RTSP ... De todos modos, no se puede obtener ninguna ventaja desde el software de vigilancia IP desde la recepción no estaba preparado para ello.

La principal razón de este comportamiento, por extraño que parezca, es una red IP, los codecs y ... aguas residuales.

Así que, para empezar, una breve teoría básica sobre una red IP. En todas las ejecuciones de la red en forma de bolsas. Cada paquete tiene un tamaño máximo (MTU, 1500 LINC convencional), el emisor y el receptor. Bolsa una vez que se envía en el camino y al final llegar al destinatario. No puede ser alcanzado. Puede causar lesiones. Pedazo puede venir ... En general, las posibles opciones. De estas bolsas se enrolla en la parte superior de los protocolos de transporte: UDP y TCP (de interés para nosotros). UDP-nada cambia, pero hay un puerto del remitente y el puerto de destino para permitir que los paquetes comparten entre sí; y un TCP atornilla un montón de lógica que "garantiza la entrega." Más precisamente - garantiza la entrega o generar errores si algo no se puede entregar. Bueno ... promete garantizar (promesa - no casarse;) Cualquier administrador repetidamente vio "colgado" conexiones en el mismo Internet móvil, por ejemplo)
.
Como TCP garantiza la entrega? Un simple - cada paquete debe ser confirmada. No hay evidencia de algún tiempo - el paquete se pierde - reenviemos. Pero si cada paquete esperar la confirmación - la velocidad cae horriblemente, y cuanto más, mayor es la demora entre los puntos que se comunican. Por lo tanto, introduce el concepto de "ventanas" - podemos enviar un máximo de N paquetes sin confirmación, y luego esperar la confirmación. Pero espera, demasiada evidencia N - receptor también enviar y recibir confirmación de cada uno, sino simplemente "máxima visión". Entonces la evidencia es menos. Y la confirmación puede ser enviada junto con los paquetes de envío, por lo que no se levantó dos veces. En general - la lógica del mar, todo ello encaminado a la realización de la promesa de la entrega, pero el máximo aprovechamiento del canal. Tamaño de la ventana - vacila, y seleccionado por el sistema basado en el vudú, la configuración, el tiempo en Marte. Además, los cambios en la corriente del proceso. Toque sobre este punto más adelante.

Así que ahora vamos a pasar a nuestras ovejas - H264 sobre RTSP. (De hecho, casi no importa - lo que es un codec es y qué protocolo de transporte No piense que si usted está utilizando cualquier protocolo de su genio, que a veces más fácil RTSP, no es asunto de su negocio.). RSS compone de repetir periódicamente fotograma clave y un cambio de flujo desde el estado actual. Al conectarse con el video que esperar a un fotograma clave, y luego lo llevamos a la situación actual, y luego tomamos diffs, que se superponen y se muestran. ¿Qué quiere decir esto? Esto significa que cada X segundos moscas muchos datos - fotograma completo. Y cuanto más, mayor será la resolución de la cámara y la más alta es la tasa de bits (aunque seamos honestos, velocidad de bits tiene poco efecto sobre el tamaño de los fotogramas clave). Así pues, aquí tenemos tiempo 0 - comenzando fotograma clave a la que llega una vez al a pantalla completa (por ejemplo, tenemos la cámara todo 3 megapiselya - está 2048x1536 = 3.145.728 píxeles Después de la compresión es patético ~ 360 KB.). Flujo total tenemos 8 megabits = 1 megabyte, fotograma clave cada 5 segundos, y FPS = 18. Entonces vamos a tener algo como 360k, entonces 52K cada 1/18 de segundo, 5 segundos más tarde de nuevo 360k, luego de nuevo a 52K.

Ahora, de nuevo volver a la UDP y TCP. Quien llegó a la bolsa de la tarjeta de red doblado en la tarjeta de red de amortiguación y el procesador puso la bandera (o una interrupción) que tiene datos. Procesador suspende la ejecución de todos los útiles, se saca de un pack de mapas, y comienza a subir y desnudarlo en la pila TCP / IP. Este proceso se realiza en la prioridad más alta (para trabajar con hierro). Pero todavía Windows o Linux, o cualquier que no es RTOS, así que no hay garantías cuando se puede llegar a la aplicación de este paquete. Y por lo tanto, tan pronto como el sistema descubierto qué tipo de paquete para que la conexión es, el paquete está tratando de cumplir con el búfer.
En UDP: Si no hay espacio en la memoria intermedia, el paquete se descarta
. En TCP: si no hay espacio en el búfer, el flujo algoritmo de control se incluye - el remitente envía un desbordamiento de la señal, dicen encerrados mientras yo no estoy sacudo un poco. Una vez que la aplicación toma algunos de los datos de la memoria intermedia, el sistema envía "OK, condujo más» reanude la comunicación remitente.

Ahora vamos a poner todo y escribir cómo la recepción de datos de la cámara. Para empezar - un simple caso de UDP. La cámara lee el siguiente fotograma, lo pone en el esfínter del detrusor se comprime paquetes de datos sobre los recortes, añade cabeceras y envía al destinatario. El destinatario recibe los primeros 260 paquetes UDP, luego una pausa, otros 40 paquetes, pausa, otros 40 paquetes, etc. Los primeros 260 paquetes UDP llegan al instante - en algún lugar durante 30 milisegundos; y ya en el 55y llegará el próximo 40 milisegundos (por otros 4 milisegundos). Supongamos que el buffer que tenemos es de 128 kilobytes. Entonces, van a anotar 10 milisegundos. Y si en ese momento la aplicación no vaciar el búfer en una sola ráfaga de controles realizados todos (en realidad leer a la vez en un solo paquete ...) - vamos a perder el resto de la trama clave. Dado que no RTOS, y la aplicación puede forzar el "sueño" por cualquier razón (como OS restablece el búfer en el disco) en el mismo momento, la única manera de no perder nada - es necesario tener un tamaño de búfer de red es mayor de lo que podemos sueño. Esto es, idealmente, deberían instalarse búfer OS igual a aproximadamente 2 segundos de flujo, en este caso - 2 megabytes. De lo contrario la pérdida garantizada.



Está bien, pero también tenemos TCP! Que garantiza la entrega, y pida al remitente que esperar si eso! Vamos a cambiar a TCP, y un vistazo a la misma imagen. Sobrecarga adicional se puede descuidar, vamos a ver qué pasa. Así pues, tenemos moscas 360 kilobytes de datos. Son enviados a 100Mbps enlace en algún lugar de 30 milisegundos. En algún lugar de la memoria intermedia del receptor milisegundo 10a está llena, la cámara y le pidió que se callara. Supongamos que, después de una aplicación de 20 ms más leer todo el buffer disponible (en realidad - leer 4 bytes, luego 1400, luego otra 4, 1400 todavía ...) y pidió a la cámara para seguir operando. cámara ha enviado otro tercer fotograma clave, y de nuevo se callara. Después de otros 20 ms condujeron en - pero aun así la cámara producen datos que sirvieron de amortiguamiento de la propia cámara. Y aquí llegamos al momento resbaladizo - y qué tamaño de búfer de TCP en la cámara? Además, debido a la constante "cállate" - "mantener" el ancho de banda efectivo disminuye dramáticamente - en lugar de 100Mbps que 128kbayt en 30 ms = 32 megabits máximos. In Windows Server, el quantum defecto es un 120ms fijos. Cuando 120ms límite de velocidad a 8.5mbit. Es decir, el sistema operativo del servidor utilizando un tampón en 128kbayt tome flujo 8mbitny será no sólo difícil, pero de enormes proporciones. En el sistema operativo de escritorio más fácil, pero aún así el problema será en cualquier chihe. Si el buffer es más - es cada vez mejor, pero aún así - en cualquier inestabilidad problemas de resta comienzan ese resultado en el caso más simple para mover bruscamente, en algunos casos, a la daños a la arroyo o insecto similar, si el desbordamiento del búfer TCP dentro de la cámara.

¿Dónde se puede dibujar una sola conclusión - el buffer así, idealmente, debería haber un margen de unos 2 segundos de flujo, en este caso - 2 megabytes. De lo contrario, el problema es probable.

Tal vez me equivoque, pero si la tarea de la aplicación es la de aceptar y mantener el flujo de las cámaras no pueden hacer esto - es un error. Y esto se debe corregir el error, y no a proponer una reducción del problema ya resuelto la reducción de la calidad de una cámara analógica. Dixi.

Fuente: habrahabr.ru/post/227483/