A continuaci贸n se muestra una historia detallada sobre c贸mo cargamos la tarjeta de NVidia con las tareas de transcodificar video para su transmisi贸n. Demostremos que probamos lo que sucedi贸 y la mejor manera de usar tarjetas de video para transmitir en l铆nea.Durante varios a帽os, nuestro equipo ha estado desarrollando productos para procesar y distribuir contenido multimedia en l铆nea.
Este art铆culo describi贸 recientemente por qu茅 los propietarios de contenido podr铆an necesitar tales soluciones en nuestra era de YouTube.
Uno de nuestros productos es el servidor de medios
Nimble Streamer , que es un software de servidor que lleva las transmisiones en vivo y los archivos a la entrada y los hace accesibles a una gran cantidad de espectadores, mientras que simult谩neamente le permite monetizar el contenido. Esta es una aplicaci贸n nativa escrita en C ++ y portada a todos los sistemas operativos y plataformas populares (Linux, Windows, MacOS) (x64, ARM). Desde el principio, el bajo consumo de recursos y la alta productividad fueron los requisitos principales, y logramos lograr
buenos resultados en esto.
El a帽o pasado, lanzamos el complemento Nimble Streamer:
transcodificador de transmisi贸n en vivo . Esta aplicaci贸n le permite tomar el flujo de entrada de video y / o audio en diferentes formatos y hacer varias conversiones con ellos en tiempo real. La funcionalidad incluye decodificaci贸n (software y hardware), conversi贸n de video y audio mediante filtros (cambio de tama帽o, superposici贸n, etc.) y codificaci贸n (codificaci贸n), tanto de software como de hardware.
El transcodificador se controla a trav茅s del servicio web WMSPanel, los scripts de transcodificaci贸n se crean a trav茅s de la interfaz de arrastrar y soltar, que le permite ver visualmente el proceso. Se pueden ejecutar varios escenarios juntos: con este enfoque es conveniente ejecutar combinaciones de prueba, cargando el servidor en cualquier variaci贸n.
En estos videos puede ver ejemplos de c贸mo funciona la interfaz.
La decodificaci贸n de cada flujo se realiza solo una vez antes de todas las conversiones adicionales ... Esto le permite ahorrar recursos en una operaci贸n de decodificaci贸n costosa, esto se ver谩 claramente a lo largo de las pruebas.
Uno de los mecanismos de conversi贸n que se pueden usar en nuestro transcodificador es la decodificaci贸n de hardware y la codificaci贸n de video utilizando la GPU de NVidia. Las tarjetas gr谩ficas de las 煤ltimas generaciones le permiten asumir algunas de las tareas t铆picas, lo que elimina la carga de la CPU. Nuestro transcodificador puede trabajar con este hardware, que nuestros clientes utilizan activamente.
En el curso de la comunicaci贸n con representantes de la oficina rusa de NVidia, se nos pidi贸 que intentemos organizar pruebas de estr茅s conjuntas de nuestro transcodificador y GPU NVidia para comprender cu谩l ser谩 el efecto econ贸mico de tal t谩ndem en comparaci贸n con la transcodificaci贸n exclusiva de software, sin aceleraci贸n de hardware. Adem谩s, quer铆a entender c贸mo usar de manera 贸ptima la GPU y, si es posible, dar buenas recetas.
Necesit谩bamos obtener r谩pidamente el hierro apropiado y acceder a 茅l, para el ciclo de nuestros experimentos. Planeamos encontrarnos un par de semanas. Queda por encontrar d贸nde conseguir el equipo. La mejor opci贸n ser铆a encontrarlos en la nube y obtener acceso remoto. Despu茅s de buscar las opciones, result贸 que AWS a煤n no tiene una VM con una GPU de generaci贸n Maxwell, y en la nube de Azure, solo est谩 previsto comenzar a proporcionarlas pronto.
1. Hierro de NVidia en la nube de Softlayer, configurando Nimble Streamer
Con la asistencia de NVidia, IBM nos proporcion贸 acceso a su nube, la plataforma IBM Bluemix Cloud Platform (anteriormente
Softlayer ). Esta es una gran red de centros de datos modernos (alrededor de 50 en el momento de la publicaci贸n) en todo el mundo, conectados por una red privada com煤n y que proporcionan una gran selecci贸n de servicios de infraestructura en la nube. Todos los centros de datos est谩n unificados y le permiten alquilar de uno a cientos de servidores virtuales o f铆sicos de la configuraci贸n requerida durante varias horas, as铆 como equilibradores, sistemas de almacenamiento, firewalls; en general, todo lo que se requiere para construir una infraestructura de TI confiable para el servicio de TI implementado.
La oficina de representaci贸n rusa de IBM nos dio acceso completo al
portal de autoservicio para administrar los servicios en la nube y a la configuraci贸n del servidor necesaria, donde pudimos trabajar con diferentes flujos de entrada y configuraciones de nuestro transcodificador.
Hierro
Primero, nos dieron un servidor f铆sico (metal) con 128 GB de RAM y 2xGPU NVidia Tesla M60 y sistema operativo Ubuntu 14.04 preinstalado. Todos los par谩metros del servidor, contrase帽as, versiones de firmware, su conmutaci贸n, IP dedicada, el estado de los componentes de hardware, eran visibles directamente en su cuenta personal, lo que le permite hacer las manipulaciones necesarias con el hardware alquilado, lo que minimiza la necesidad de interacci贸n con el soporte de IBM. Durante la ejecuci贸n de la prueba, result贸 que no pudimos cargar de manera 贸ptima esta configuraci贸n, debido a una serie de limitaciones en la generaci贸n de contextos.
Quer铆amos reducir la configuraci贸n. Como utilizamos la plataforma en la nube, fue necesario a trav茅s del portal de autoservicio para solicitar cambios de configuraci贸n. Despu茅s de la aprobaci贸n, esta operaci贸n tard贸 aproximadamente 2 horas en la ventana de servicio aprobada. Durante este tiempo, el personal t茅cnico del centro de datos de Amsterdam elimin贸 componentes adicionales (ranuras RAM y 1xGPU) del servidor que nos proporcionaron antes y lo devolvi贸 a la operaci贸n. Debe tenerse en cuenta que para los desarrolladores esta opci贸n es muy conveniente, ya que no es necesario ocuparse de la configuraci贸n del hardware, repararla o incluso pasar tiempo instalando el sistema operativo. Perm铆tame recordarle que en este caso el hipervisor no se utiliza porque necesitamos exprimir al m谩ximo los recursos de hardware.
En base a los resultados de nuestra investigaci贸n, nos decidimos por la siguiente configuraci贸n del servidor:
Doble Intel Xeon E5-2690 v3 (2.60GHz)
24 n煤cleos
64 GB de RAM
1 TB SATA
Tenemos 2 procesadores con 12 n煤cleos cada uno, y gracias a Hyper Threading obtenemos el doble, es decir virtualmente 48 n煤cleos.
En escenarios con un acelerador de gr谩ficos, se utiliz贸 una tarjeta basada en el chip GM204 - Tesla M60:
NVIDIA Tesla M60
1xGPU: 2 x Maxwell GM204
Memoria: 16 GB GDDR5
Velocidad de reloj: 2.5 GHz
N煤cleos NVIDIA CUDA: 2 x 2048
Ancho de banda de memoria: 2 x 160 GB / seg.
Le llamo la atenci贸n sobre el hecho de que no se realiz贸 ninguna afinidad, ajuste de chip, overclocking u otra magia en el hardware reducido, solo CPU y GPU no overclockeadas, y para la GPU solo se utiliz贸 el controlador oficial tomado del sitio web de NVidia. Si alguien tiene una experiencia similar, comparta en los comentarios.
Entonces, tenemos acceso. Un r谩pido conocimiento de la interfaz web del panel de control (todo es simple y claro all铆), luego acceder al servidor a trav茅s de SSH, y aqu铆 estamos en la l铆nea de comandos habitual de Ubuntu, poner Nimble Streamer, registrar una licencia de transcodificador nueva y hacer una peque帽a configuraci贸n de configuraci贸n.
Transcodificador 谩gil streamer
Nimble Streamer se configur贸 para crear previamente el cach茅 de contexto de GPU. Esto se debe al hecho de que la GPU tiene un l铆mite en el n煤mero m谩ximo de contextos de decodificaci贸n y codificaci贸n creados, y adem谩s, crear contextos sobre la marcha puede tomar demasiado tiempo.
Se pueden encontrar m谩s detalles sobre el problema de crear contextos en la secci贸n correspondiente a continuaci贸n.
Configuraci贸n de Nimbl en el ejemplo de la primera serie de pruebas:
nvenc_context_cache_enable = true
nvenc_context_create_lock = true
nvenc_context_cache_init = 0: 30: 15.1: 30: 15
nvenc_context_reuse_enable = true
M谩s detalles sobre estas configuraciones est谩n escritos
en nuestro art铆culo .
Antes de comenzar cada serie de pruebas, el cach茅 se configur贸 por separado, teniendo en cuenta los detalles de cada tarea.
Crear scripts de transcodificaci贸n
Se sigui贸 trabajando en nuestro servicio WMSPanel, donde se configuran los scripts del transcodificador.
Como ya se mencion贸, el trabajo pasa por la interfaz web, todo es extremadamente claro y conveniente. Creamos una serie de escenarios que combinan diferentes opciones de transcodificaci贸n (CPU / GPU), diferentes opciones de resoluci贸n y diferentes par谩metros de codificaci贸n (CPU / GPU, perfil, velocidad de bits, etc.)
Se pueden ejecutar conjuntos de escenarios simult谩neamente, lo que permite introducir varias combinaciones de pruebas, aumentar la carga en un orden diferente y cambiarla seg煤n la situaci贸n. Simplemente seleccione los escenarios necesarios y det茅ngalos o rean煤delos.
Aqu铆 hay un conjunto de escenarios:
Aqu铆 hay un ejemplo de uno de los escenarios:
El decodificador de GPU se ve as铆:
Aplicamos el filtro de tama帽o de imagen:
Y aqu铆 est谩 el codificador para la variante GPU:
En general, el funcionamiento de la interfaz del transcodificador se puede
ver en estos videos .
2. Transcodificaci贸n de transmisiones FullHD 1080p
Para empezar, probamos el escenario con las cargas m谩s altas para descubrir los l铆mites de las capacidades de hierro. Por el momento, la "m谩s pesada" de las resoluciones utilizadas en la pr谩ctica es FullHD 1080p.
Para generar las transmisiones en vivo originales, se tom贸 un archivo en
FullHD (1920 * 1080) en
H.264 de alto perfil . El contenido en s铆 es un video tour de la ciudad, es decir Este es un video con una tasa de cambio de imagen promedio. No hay marcos est谩ticos de un solo color que puedan facilitar el trabajo del transcodificador, pero no hay un cambio demasiado r谩pido de tipos y colores. En una palabra: una carga bastante t铆pica.
Se alimentaron
36 transmisiones id茅nticas a la entrada de Nimble Streamer, que luego se utilizaron en el transcodificador en diferentes escenarios.
El escenario de transcodificaci贸n se usa t铆picamente: la transmisi贸n entrante es de perfil alto de
1080p , perfil principal de
720p, 480p, 360p y luego las secuencias de
perfil de l铆nea de base se hacen a partir de ella
: 240p, 160p . En total, hay 1 flujo en la entrada y 5 en la salida. Por lo general, tambi茅n se realiza un paso (transferencia sin cambios) del flujo original para que el espectador pueda seleccionar 1080p mientras visualiza. No lo agregamos en el script, porque no utiliza transcodificaci贸n: hay una transferencia directa de datos de entrada a salida. Este escenario est谩 optimizado en Nimble y en condiciones reales aumentar谩 el consumo de memoria de forma relativamente leve.
Audio en las secuencias generadas - no. Agregar audio al script no causar谩 cargas significativas de CPU, pero por la pureza del experimento, excluimos el sonido.
Prueba de CPU, sin GPU
Para comenzar, lanzamos scripts de transcodificaci贸n sin usar una GPU, especificando el decodificador y codificador de software en los scripts.
Como resultado, fue posible procesar solo 16 flujos de entrada con la emisi贸n de 80 flujos de todos los permisos de salida.
Carga de CPU: 4600%, es decir 46 n煤cleos estuvieron involucrados. Consumo de RAM: aproximadamente 15 GB.
Prueba de CPU + GPU
La memoria cach茅 de contexto al inicio se configura como 0: 30: 15.1: 30: 15, es decir 30 contextos para codificar, 15 para decodificar, cada GPU.
Perm铆tame recordarle que en la GPU tenemos dos n煤cleos, lo que nos permite paralelizar las tareas, esto es 煤til para nosotros.
La carga m谩xima se obtuvo con la siguiente configuraci贸n de flujo.
El decodificador de entrada GPU0 y GPU1 - 15 flujos. De este modo, obtenemos 30 secuencias decodificadas, listas para su uso posterior. Cada secuencia se decodifica solo una vez, sin importar cu谩ntos escenarios se use en el futuro.
Los codificadores GPU0 y GPU1 recibieron 15 transmisiones cada uno para obtener 720p, es decir. Se produjeron 30 transmisiones de 720p en una salida.
Adem谩s, los codificadores GPU0 y GPU1 proporcionaron cada uno 15 flujos para 480p, y tambi茅n se emitieron 30 flujos de 480p.
Como los contextos del codificador se agotaron, la codificaci贸n de los permisos restantes se estableci贸 en la CPU. Result贸 lo siguiente:
- 30 transmisiones 360p
- 30 transmisiones 240p
- 30 transmisiones 160p
La carga result贸 ser 2600% de CPU, 75% de decodificador, 32% de codificador. Luego, la CPU se carg贸 con 6 transmisiones para decodificar, por cada 5 resoluciones similares configuradas, para un total de 30 hilos por salida.
En total, se recibieron
36 transmisiones en la entrada, 180 se emitieron en la salida . La carga final se repara de la siguiente manera:
4400% de CPU, 75% de decodificador de tarjeta, 32% de codificador de tarjeta, 30 GB de RAM .
Algunos detalles
Decidimos verificar la opci贸n en la que procesamos las tareas m谩s dif铆ciles en la GPU: decodificar 1080 y codificar 720 y 480, y dejar que el resto se procese a trav茅s de la CPU.
Primero, verificamos el l铆mite del decodificador. Con 22 hilos, la decodificaci贸n se vio afectada por el problema de los contextos, simplemente no se pudieron crear. Disminuy贸 a 21: se crearon contextos, pero la carga se volvi贸 100% y los artefactos comenzaron a observarse en la secuencia. Nos detuvimos en 20 transmisiones, decodificamos 20 transmisiones, codificamos a 160p, todo funciona bien.
Adem谩s, result贸 emp铆ricamente que esta tarjeta con 16 GB de RAM a bordo puede funcionar con confianza en 47 contextos, y no hay diferencia, estos son los contextos de un codificador o decodificador. Repito: se trata espec铆ficamente de esta GPU Tesla M60, en otras tarjetas este n煤mero puede ser diferente. Creemos que si la tarjeta tuviera 24 GB de RAM, el n煤mero de contextos podr铆a ser diferente, pero esto debe ser probado.
Como resultado, elegimos la f贸rmula de creaci贸n de cach茅 "15 contextos del decodificador y 30 contextos del codificador", que proporciona 30 secuencias a la entrada y para cada una le permite crear 2 permisos. Entonces, las resoluciones superiores, 720 y 480, se lanzaron en la GPU, y el resto, 360, 240 y 160, se enviaron a la CPU. Y como la CPU a煤n estaba libre despu茅s de eso, "terminamos" los n煤cleos libres con nuevos hilos, dejando 4 n煤cleos para tareas utilitarias.
3. Transcodificaci贸n de transmisiones HD 720p
Escenario de carga t铆pica La mayor parte del contenido ahora se crea en HD. Incluso el reciente SuperBowl LI, el programa mejor calificado en el mercado estadounidense, se
transmiti贸 en HD , dejando FullHD para el futuro.
Para generar las secuencias de origen, se tom贸 un archivo en
HD (1280 * 720) en un
perfil alto . El contenido es la serie favorita de "The Good Wife" de nuestro ingeniero, es decir Este es un video con una tasa de cambio de imagen promedio.
En la entrada del Nimble Streamer, se alimentaron 70 transmisiones id茅nticas, que luego se utilizaron en el transcodificador en diferentes escenarios.
Se utiliza el siguiente escenario de transcodificaci贸n: la transmisi贸n entrante es de
720p de perfil alto,
480p, perfil principal de 360p y luego se hacen
240p, 160p l铆neas de perfil de
l铆nea base . Total, en la entrada 1, en la salida 4. No se realiz贸 el paso de la secuencia original, como en el escenario anterior. El audio en las secuencias generadas tampoco lo es.
Prueba de CPU, sin GPU
Como en la secci贸n anterior, intentamos transcodificar secuencias solo en la CPU. Como resultado, fue posible procesar solo 22 flujos de entrada con la emisi贸n de 88 flujos de todos los permisos de salida. Carga de CPU: 4700%, es decir Participaron 47 n煤cleos. Consumo de RAM: aproximadamente 20 GB.
Prueba de CPU + GPU
La memoria cach茅 de contexto al inicio se configura como 0: 23: 23.1: 23: 23, es decir 23 contextos para codificar, 23 para decodificar para cada GPU.
Usando la GPU, se decodificaron 46 secuencias de 720p. All铆, en la GPU, se codificaron 46 secuencias de 480p. A continuaci贸n, se realizaron codificaciones de 360p, 240p y 160p en la CPU: 46 transmisiones cada una.
Carga fija de 2100% de CPU, 61% del decodificador, 16% del codificador.
Adem谩s, se lanz贸 la codificaci贸n y decodificaci贸n de 24 subprocesos a la CPU, por cada 1 subproceso - 4 salidas, como para la GPU.
En total,
se ingresaron 70 secuencias, se emitieron 280 secuencias .
Carga:
4600%, 61% del decodificador, 16% del codificador, 30 GB de RAM .
En cuanto a la prueba anterior, quiz谩s una GPU RAM m谩s grande dar铆a m谩s contextos y podr铆amos manejar m谩s hilos. Pero esto es solo en teor铆a, es necesario verificarlo.
4. El problema con la creaci贸n de contextos en la GPU NVidia
Algunas palabras sobre el problema que no nos permitieron procesar m谩s subprocesos en la GPU.
A fines del a帽o pasado, realizamos pruebas con el equipo de NVidia, con varias tarjetas. Al trabajar con m煤ltiples GPU, result贸 que la creaci贸n de contextos ralentiza enormemente el servidor: la creaci贸n de cada nuevo contexto tom贸 m谩s y m谩s tiempo del mapa. Si el primer contexto se cre贸 en el orden de 300 ms, cada uno de los siguientes agreg贸 200-300 ms y ya en los terceros diez contextos, crear uno nuevo tom贸 3-4 segundos cada uno. Cuando un usuario crea un script de transcodificaci贸n, se supone que comienza a trabajar de inmediato y sin demoras, y esta nueva circunstancia neg贸 todas las ventajas en la velocidad de Nimbl y dio demoras en la creaci贸n de contextos que condujeron a demoras en el inicio de la codificaci贸n.
Al principio, la sospecha recay贸 en Nimble, pero luego hicimos pruebas usando ffmpeg, que NVidia proporciona a los clientes y el resultado fue exactamente el mismo: la GPU est谩 gastando m谩s y m谩s tiempo creando cada nuevo contexto. En condiciones en las que el servidor ya est谩 transcodificando y necesita iniciar nuevos subprocesos para el procesamiento, esto afecta el rendimiento general y hace que el servidor simplemente sea inutilizable.
El problema fue descrito en detalle por el equipo de NVidia, pero hasta ahora no se ha proporcionado una soluci贸n a tiempo completo. Por lo tanto, hasta ahora hemos implementado un mecanismo de almacenamiento en cach茅 de contexto en nuestro servidor, con la creaci贸n preliminar de contextos al inicio del servidor. Esto resolvi贸 el problema desde el punto de vista del trabajo del usuario final, pero el inicio del Nimbl puede llevar algo de tiempo. La configuraci贸n de Nimbl para un trabajo efectivo con contextos
se describe en nuestro blog .
Adem谩s, los contextos no son f谩ciles de crear. Con una gran cantidad de contextos al incluir cualquier script de transcodificaci贸n, la API de NVENC comienza a arrojar errores: "La llamada a la API fall贸 porque no pudo asignar suficiente memoria para realizar la operaci贸n solicitada".
Emp铆ricamente, result贸 que una GPU puede comenzar y trabajar con confianza en 47 contextos, y no hay diferencia, estos son los contextos de un codificador o decodificador. Se supon铆a que esto se deb铆a a la cantidad de memoria en la GPU. Ahora hay 16 GB, si coloca una tarjeta con 24 GB, es probable que se puedan hacer m谩s contextos. Pero esto es solo una teor铆a, es necesario verificar, como se mencion贸 anteriormente. Los datos obtenidos son v谩lidos para un modelo de GPU espec铆fico, otras tarjetas deben probarse por separado.
Es la restricci贸n en el n煤mero de contextos lo que pone el obst谩culo principal cuando se trabaja con grandes cargas.
5. Conclusiones
Por lo tanto, el prop贸sito de las pruebas era estudiar la efectividad de la GPU para el rango de tareas indicado y desarrollar recetas para su uso adecuado. Cual es el resultado?Efecto econ贸mico
Arriba, vimos c贸mo la cantidad de subprocesos que se pueden procesar en la CPU y en el t谩ndem CPU + GPU es diferente. Veamos qu茅 significa esto en t茅rminos de dinero. Como base tomamos los mismos Softlayer y los precios de alquiler de sus equipos.- La configuraci贸n sin una GPU costar谩 $ 819 por mes . Aqu铆 puedes recoger un auto.
- La configuraci贸n con la GPU costar谩 $ 1729 por mes para el centro de datos en Amsterdam, los precios se pueden encontrar aqu铆 . Cuando se usa una GPU, el precio de alquiler del servidor aumenta ligeramente, ya que se usa el factor de forma de caso 2U m谩s grande. El efecto econ贸mico probablemente ser谩 mayor al comprar equipos (pero esto requiere un an谩lisis serio del TCO, teniendo en cuenta la actualizaci贸n constante de la l铆nea de GPU NVidia).
Ahora veamos los resultados de la prueba:para FullHD 1080p- CPU sin GPU: 16 hilos por entrada + 80 hilos por salida
- CPU + GPU: 36 hilos por entrada + 180 por salida
Beneficio de GPU: 2.25x.Beneficios del uso de la GPU: $ 819 * 2.25 - $ 1729 = $ 113 por mes al alquilar 1 servidor con una GPU.Para HD 720p- CPU sin GPU: 22 hilos por entrada + 88 hilos por salida
- CPU + GPU: 70 hilos por entrada + 280 por salida
Beneficio de GPU: 3.18x.Beneficio de usar la GPU: $ 819 * 3.18 - $ 1729 = $ 875 por mes al alquilar 1 servidor con una GPUEs decir, con la opci贸n de alquiler, los ahorros son bastante notables. Esto no tiene en cuenta los descuentos: en la oficina rusa de IBM prometen descuentos en el alquiler de recursos en la nube en comparaci贸n con los precios presentados aqu铆.No entramos en las opciones con la compra, porque aqu铆, el costo total de propiedad depende en gran medida de la elecci贸n del proveedor, el costo del servicio en el centro de datos y otros factores que son familiares para quienes trabajan con metal desnudo. Sin embargo, las cifras preliminares tambi茅n hablan a favor de una soluci贸n basada en GPU.Adem谩s, no olvide el tr谩fico y el ancho del canal: est谩n incluidos en una cierta cantidad en las tarifas presentadas anteriormente, pero deber谩 seleccionar las opciones para sus tareas en funci贸n del n煤mero de hilos, el n煤mero esperado de usuarios, etc.Escalamiento
La opci贸n con una tarjeta gr谩fica por servidor nos parece m谩s rentable que la opci贸n con dos o m谩s tarjetas. Como podemos ver, el decodificador de GPU siempre carg贸 m谩s que el codificador, pero incluso permaneci贸 subcargado debido a problemas con el uso de contextos. Si agrega una segunda tarjeta, el decodificador se usar谩 a煤n menos, los codificadores que no podremos cargar a plena capacidad, y todo el trabajo en la codificaci贸n a煤n tendr谩 que trasladarse a la CPU, lo que no se justificar谩 por el dinero. Tambi茅n probamos la opci贸n con dos GPU gracias al soporte de Softlayer, pero debido al d茅bil efecto econ贸mico, no damos detalles en el art铆culo.En consecuencia, para escalar la carga, es preferible agregar nuevos servidores con una tarjeta gr谩fica que agregar tarjetas a las m谩quinas existentes.Si el n煤mero de transmisiones entrantes y salientes para su proyecto es relativamente peque帽o, por ejemplo, una docena de transmisiones HD con una peque帽a cantidad de resoluciones de salida, con una cantidad relativamente peque帽a de filtrado, ser铆a m谩s conveniente utilizar un servidor sin una GPU.Tambi茅n vale la pena se帽alar que la cantidad de RAM para la tarea de convertir subprocesos no es tan importante como la potencia de procesamiento. Entonces, en algunos casos, tambi茅n puede ahorrar reduciendo la cantidad de memoria.Conclusi贸n
La soluci贸n de hardware presentada, una combinaci贸n de la CPU y GPU Tesla M60, fue perfecta para transcodificar transmisiones en vivo bajo cargas pesadas. La GPU se encarga de las operaciones m谩s intensivas en recursos: decodifica las secuencias y las codifica en las resoluciones m谩s altas, mientras que las resoluciones medias y peque帽as se procesan bien en la CPU.Si uno de los lectores tiene experiencia y est谩 optimizando el rendimiento de las tarjetas gr谩ficas para la transmisi贸n en vivo, estaremos encantados de conocer su experiencia: escriba los comentarios.