Todos os días, millóns de espectadores ven vídeos en Internet. Pero para que o vídeo estea dispoñible, non só debe cargarse no servidor, senón tamén procesarse. Canto máis rápido ocorra isto, mellor para o servizo e os seus usuarios.
Chámome Askar Kamalov, hai un ano entreime ao equipo de tecnoloxía de vídeo de Yandex. Hoxe contarei brevemente aos lectores de Habr sobre como, paralelizando o proceso de codificación, conseguimos acelerar significativamente a entrega de vídeo ao usuario.
Esta publicación será de interese principalmente para aqueles que non pensaron previamente no que ocorre baixo o capó dos servizos de vídeo. Nos comentarios podes facer preguntas e suxerir temas para futuras publicacións.
Unhas palabras sobre a tarefa en si. Yandex non só che axuda a buscar vídeos noutros sitios, senón que tamén almacena vídeos para os seus propios servizos. Tanto se se trata dun programa orixinal como dun partido deportivo en directo, unha película en KinoPoisk ou vídeos en Zen e News, todo isto cárgase nos nosos servidores. Para que os usuarios vexan o vídeo, ten que estar preparado: converterse ao formato necesario, crear unha vista previa ou mesmo executar a través da tecnoloxía . Un ficheiro non preparado só ocupa espazo. Ademais, non só falamos do uso óptimo do hardware, senón tamén da velocidade de entrega dos contidos aos usuarios. Exemplo: pódese buscar unha gravación do momento decisivo dun partido de hóckey nun minuto despois do propio evento.
Codificación secuencial
Polo tanto, a felicidade do usuario depende en gran medida da rapidez coa que estea dispoñible o vídeo. E isto está determinado principalmente pola velocidade de transcodificación. Cando non hai requisitos estritos para a velocidade de carga de vídeo, non hai problemas. Colles un único ficheiro indivisible, convérteo e cárgao. Ao comezo da nosa viaxe, así traballamos:
O cliente carga o vídeo no almacenamento, o compoñente Analyzer recolle metainformación e transfire o vídeo ao compoñente Worker para a súa conversión. Todas as etapas realízanse secuencialmente. Neste caso, pode haber moitos servidores de codificación, pero só un está ocupado procesando un vídeo específico. Diagrama sinxelo e transparente. Aquí é onde rematan as súas vantaxes. Este esquema só se pode escalar verticalmente (debido á compra de servidores máis potentes).
Codificación secuencial con resultado intermedio
Para suavizar dalgunha maneira a dolorosa espera, a industria presentou unha opción de codificación rápida. O nome é enganoso, porque de feito, a codificación completa ocorre secuencialmente e leva o mesmo tempo. Pero cun resultado intermedio. A idea é esta: preparar e publicar unha versión de baixa resolución do vídeo o máis rápido posible, e só entón versións de maior resolución.
Por unha banda, o vídeo está dispoñible máis rápido. E é útil para eventos importantes. Pero, por outra banda, a imaxe resulta borrosa, e isto molesta aos espectadores.
Resulta que non só cómpre procesar rapidamente o vídeo, senón tamén manter a súa calidade. Isto é o que os usuarios esperan agora dun servizo de vídeo. Pode parecer que é suficiente comprar os servidores máis produtivos (e actualizalos todos á vez). Pero este é un camiño sen saída, porque sempre hai un vídeo que fará que ata o hardware máis potente se ralentice.
Codificación paralela
É moito máis eficiente dividir un problema complexo en moitos menos complexos e resolvelos en paralelo en diferentes servidores. Este é MapReduce para vídeo. Neste caso, non estamos limitados polo rendemento dun servidor e podemos escalar horizontalmente (engadindo novas máquinas).
Por certo, a idea de dividir vídeos en anacos pequenos, procesalos en paralelo e pegalos non é ningún segredo. Podes atopar moitas referencias a este enfoque (por exemplo, en Habré recomendo unha publicación sobre o proxecto ). Pero isto non o facilita en xeral, porque non podes simplemente tomar unha solución preparada e incorporala á túa casa. Necesitamos adaptación á nosa infraestrutura, ao noso vídeo e mesmo á nosa carga. En xeral, é máis fácil escribir o teu.
Entón, na nova arquitectura, dividimos o bloque monolítico Worker con codificación secuencial en microservizos Segmenter, Tcoder, Combiner.
- O segmentador divide o vídeo en fragmentos de aproximadamente 10 segundos. Os fragmentos consisten en un ou máis GOP (). Cada GOP é independente e codificado por separado para que se poida decodificar sen referencia a fotogramas doutros GOP. É dicir, os fragmentos pódense reproducir independentemente uns dos outros. Esta fragmentación reduce a latencia, permitindo que o procesamento comece antes.
- Tcoder procesa cada fragmento. Leva unha tarefa da cola, descarga un fragmento do almacenamento, codificao en diferentes resolucións (lembre que o xogador pode escoller unha versión en función da velocidade de conexión), despois volve poñer o resultado no almacenamento e marca o fragmento como procesado. na base de datos. Despois de procesar todos os fragmentos, Tcoder envía a tarefa para xerar resultados para o seguinte compoñente.
- Combiner recolle os resultados xuntos: descarga todos os fragmentos feitos por Tcoder, xera fluxos para diferentes resolucións.
Algunhas palabras sobre o son. O códec de audio AAC máis popular ten unha característica desagradable. Se codificas fragmentos por separado, simplemente non poderás pegalos sen problemas. As transicións notaranse. Os códecs de vídeo non teñen este problema. Teoricamente, podes buscar unha solución técnica complexa, pero este xogo simplemente non paga a pena aínda (o audio pesa moito menos que o vídeo). Polo tanto, só se codifica o vídeo en paralelo e se procesa toda a pista de audio.
Descubrimentos
Grazas ao procesamento de vídeo paralelo, reducimos significativamente o atraso entre que se carga un vídeo e está dispoñible para os usuarios. Por exemplo, anteriormente podían levar dúas horas crear varias versións completas de diferente calidade para unha película FullHD dunha hora e media de duración. Agora todo isto leva 15 minutos. Ademais, co procesamento paralelo, creamos unha versión de alta resolución aínda máis rápido que unha versión de baixa resolución co antigo enfoque de resultados intermedios.
E unha cousa máis. Co vello enfoque, ou non había servidores suficientes, ou estaban inactivos sen tarefas. A codificación paralela permítelle aumentar a porcentaxe de reciclaxe de ferro. Agora o noso clúster de máis de mil servidores está sempre ocupado con algo.
De feito, aínda hai marxe de mellora. Por exemplo, podemos aforrar moito tempo se comezamos a procesar fragmentos do vídeo antes de que nos cheguen na súa totalidade. Como din, máis por vir.
Escribe nos comentarios que tarefas no campo do traballo con vídeo che gustaría ler.
Ligazóns útiles á experiencia dos compañeiros do sector
Fonte: www.habr.com