⛪️ 🗓️ 🤸🏾 HighLoad ++, Mikhail Raichenko (ManyChat): quase sem mágica, ou como é fácil distribuir stream de vídeo terabit ✌️ 👩🏿‍🤝‍👨🏾 🖕🏼

A próxima conferência HighLoad ++ será realizada nos dias 6 e 7 de abril de 2020 em São Petersburgo. Detalhes e ingressos aqui . HighLoad ++ Moscow 2018. Salão "Delhi + Calcutta". 8 de novembro, 14h Resumos e apresentação .

Trabalho na equipe VKontakte e estou desenvolvendo um sistema de transmissão de vídeo.
No relatório, compartilharei os recursos do desenvolvimento de back-end, a maneira como nosso sistema evoluiu e as soluções técnicas para as quais chegamos: 

como fizemos o backend da transmissão de vídeo e o processo de evolução como ele é;
o impacto dos requisitos comerciais e operacionais na arquitetura;
"Aguarde" e "tente novamente" falharão;
como as tarefas mais simples são complicadas pelo número de usuários;
como reduzir a latência sem UDP;
Realizamos testes de estresse 2 vezes ao dia, ou com o que Clover nos ajudou.

Mikhail Raichenko (a seguir - MR): - Uma pequena excursão. Vou falar sobre as pessoas que transmitem para nós, ao vivo (ao vivo), sobre quais plataformas recebemos o fluxo de vídeo e quais distribuímos. No final, falarei sobre a arquitetura atual do live, sobre suas limitações e capacidades, bem como sobre como a arquitetura atual sobreviveu a um efeito como "Clover".

Sobre transmissões ao vivo. Esboço do relatório

Primeiro, falarei um pouco sobre as próprias transmissões e transmissões ao vivo, enviando-nos o conteúdo de vídeo que mostramos a outros espectadores.
. ? , , , , - - , - , . , : , – .
. , . . , , .
, , . , . , , , , , 2014-2015 . , .
. , .
, . , . , .
, . .
, , «», .

Todos os serviços de transmissão são mais ou menos assim:

temos um pouco de streamer, ele envia um fluxo RTMP para nós e mostramos ao público - nada surpreendente, nada sobrenatural.

De onde vem o fluxo de vídeo? Uma fonte significativa de tráfego para nós é o nosso aplicativo móvel VKlife. O que há de bom nele? Nele, podemos controlar totalmente como codificamos o vídeo. Podemos fazer muitas otimizações no lado do cliente, para que mais tarde, com atrasos mínimos, mostrem aos nossos espectadores.

Das desvantagens: aplicativos móveis funcionam em cima de redes. Pode ser 3G ... De qualquer forma, são quase sempre redes móveis, o que apresenta alguns atrasos - você precisa armazenar em buffer adicionalmente os dados no lado do aplicativo, para que o fluxo funcione da maneira mais suave possível.

A segunda fonte são streamers com OBS, Wirecast ou aqueles que transmitem a partir de outros aplicativos de desktop. Esta é uma audiência bastante grande. Às vezes, são seminários, às vezes - fluxos de jogos (existem muitos deles em tais aplicativos). Do ponto positivo: existem poucas aplicações desse tipo, podemos oferecer boas recomendações de ajuste às nossas serpentinas. Mas, ao mesmo tempo, há muitas configurações e não enviamos exatamente o fluxo que queremos.

A terceira categoria é o fluxo RTMP dos servidores de mídia. Estes podem ser servidores de mídia muito pequenos, ou seja, um formato doméstico: uma pessoa transmite uma visão da rua ou qualquer outra coisa. Ou transmissões bastante sérias de nossos parceiros: pode haver qualquer coisa, não existem muitos desses fluxos, mas basicamente são muito importantes para nós.

Quem está assistindo?

Novamente, esta é uma aplicação móvel - tudo está claro aqui. O maior problema é a latência da rede. Dos profissionais: podemos personalizar o player - é conveniente para nós, bom, mas não em todos os lugares onde fica 100%.

Web player em vk.com. Aqui também tudo é simples - é um reprodutor de web comum que você pode abrir para assistir. Uma audiência suficientemente grande no vk.com, muitos espectadores nas transmissões. Algumas transmissões estão suspensas em nossa seção "Vídeo" - pode haver dezenas de milhares (às vezes sem PR), especialmente se esse for um conteúdo interessante.

Assim, os canais são grandes o suficiente para os espectadores que estão sentados em um web player. Portanto, há muito tráfego, inclusive para uma transmissão.

O terceiro é o web player VKontakte em algum site de terceiros. Você pode começar a transmitir tudo o que quiser e pendurar um web player VKontakte no seu site. Você pode se tornar nosso parceiro se tiver um conteúdo interessante: você pode pendurá-lo por conta própria, pode pendurar conosco - como desejar. Você pode organizar suas transmissões dessa maneira e tudo funcionará.

Comparação com videochamadas

Nas videochamadas, algumas distorções da imagem serão perdoadas. As videochamadas são mais simples: podemos degradar significativamente a imagem, mas, ao mesmo tempo, precisamos manter uma latência muito boa. Com um longo atraso, o serviço será absolutamente impossível de usar.

Nas transmissões nesse sentido, é um pouco vice-versa: precisamos manter alta qualidade de imagem, mas, ao mesmo tempo, podemos aumentar a latência devido a muitos fatores. Por exemplo, o player armazena em buffer o fluxo de uma maneira ou de outra (pode ser um segundo, dois para sobreviver à degradação da rede, por exemplo); portanto, na maioria dos casos, não é necessário um segundo atraso de milissegundos. Você pode se esforçar para isso, mas a comida não é um pré-requisito.

No vídeo comum, a situação é exatamente o oposto. Precisamos de muito boa qualidade. Ao mesmo tempo, é desejável minimizar o tamanho do vídeo, a taxa de bits e a qualidade, para que, com o fluxo mínimo, forneça a melhor solução. Dos profissionais: não temos tempo limitado: no momento do download do vídeo, temos tempo suficiente para otimizar o vídeo, ver como compactá-lo da melhor maneira, fazer alguma coisa, arrastá-lo para caches, se necessário - em geral, tudo é suficiente ESTÁ BEM.

Ao vivo, a situação é, novamente, o oposto: temos muito pouco tempo para transcodificar. Ao mesmo tempo, existem poucas oportunidades, mas não há expectativas para a transmissão. O público nos perdoará se tivermos apoio ou se a qualidade não for muito boa.

Primeira versão

É bastante esperado: na

verdade, é um pouco diferente:

"Streamer - servidor de mídia - nível de cache - visualizadores". Em princípio, esta versão permite escalar com bastante força. Eu diria que já deveria suportar dezenas de milhares de espectadores. Tem outras desvantagens ...

Por exemplo, se você olhar para este circuito (slide anterior), poderá ver que ele não é tolerante a falhas. Devemos adivinhar com o servidor de mídia para equilibrar bem o público. Não podemos pendurar muitos caches em cada servidor - é simplesmente caro. Portanto, vimos, percebemos que era simples e claro, havia algumas possibilidades de dimensionamento, mas obviamente algo estava faltando ... E começamos a formular requisitos.

Requisitos de infraestrutura

O que é importante?

. , , . ( ). (, ).
. : -, (, ) ; -, – , , .
Entrega para as regiões. Também é um ponto importante! É estúpido arrastar todo o conteúdo de vídeo de Petersburgo ou Moscou para algum tipo de Novosibirsk, Ecaterimburgo ou mesmo de São Petersburgo para Moscou. Isso não é muito bom, pois o atraso da rede será longo - haverá atrasos, tudo ficará lento e isso não será bom. Portanto, nossa infraestrutura deve levar em conta que entregamos conteúdo para as regiões.
Conveniência de operação e monitoramento. Uma propriedade importante. Como o sistema é grande, há muitos visualizadores, é importante enviar alertas aos administradores a tempo, em caso de problemas, incluindo o monitoramento de métricas técnicas e do produto.

Como é a infraestrutura de transmissão agora?

Como resultado, chegamos a uma infraestrutura bastante simples, mas eficaz ...

– , ( , ). RTMP-, . , .
, , , , . . , , , – : , -, (. . ); -, .
. – , . , , . , ( , ).
, (edge-). , . !
– edge-, , . : , – .

Curiosamente? Balanceamento! Nesse esquema, escolhemos o balanceamento, tentamos enviar espectadores que assistem o mesmo fluxo para cada servidor de borda. A localidade do cache é muito importante aqui, porque pode haver muitos servidores de borda; e se não observarmos o local temporário e o cache do ponto de vista do fluxo, sobrecarregaremos a camada interna. Também não gostaríamos disso.

Portanto, equilibramos da seguinte maneira: selecionamos um determinado servidor de borda para a região para a qual enviamos visualizadores e enviamos até começarmos a entender que ocorreu algum preenchimento e que deve ser enviado para outro servidor. O circuito é simples e funciona com muita confiabilidade. Naturalmente, para fluxos diferentes, você escolhe uma sequência diferente de servidores de borda (a sequência na qual enviamos espectadores). Consequentemente, o balanceamento funciona de maneira bastante simples.

Também fornecemos ao cliente um link para um servidor de borda disponível. Isso é feito para que, em caso de falha do servidor de borda, possamos redirecionar o visualizador para outro. Ou seja, quando o espectador assiste à transmissão, ele recebe um link para o servidor desejado uma vez a cada poucos segundos. Se ele entender que o link deve ser diferente, ele alterna (o player alterna) e continua a assistir à transmissão de outro servidor.

Outro papel importante dos servidores de borda é a proteção de conteúdo. Toda a proteção de conteúdo ocorre basicamente lá. Nós temos nosso próprio módulo nginx para isso. É um pouco semelhante ao Security Link.

Dimensionamento e balanceamento

. , : , . edge-, . . . … , – , -- – , – , , , – ! – .
. , , , , : . ( ) , – , . , , , edge-.
, , , .

?

Um dos principais protocolos que tínhamos era o RTMP (não apenas para entrada, mas também para distribuição de conteúdo). A principal vantagem é a baixa latência. Pode demorar meio segundo, segundo, dois segundos. De fato, os benefícios terminam aí ...

Esse protocolo de streaming é difícil de monitorar - é fechado em certo sentido, apesar do fato de haver uma especificação. O Flash player não funciona mais (na verdade, já é "tudo"). Precisa de suporte no nível da CDN - você precisa de módulos nginx especiais ou de seu próprio software para transferir o fluxo normalmente. Há também algumas dificuldades com os clientes móveis. Pronto para uso em clientes móveis, o suporte é péssimo - são necessárias melhorias especiais e tudo isso é muito difícil.
O segundo protocolo que usamos é o HLS. Parece bem simples: é um arquivo de texto, o chamado arquivo de índice. Ele contém links para arquivos de índice com permissões diferentes e os próprios arquivos contêm links para segmentos de mídia.

Como ele está bem? É muito simples, apesar de ser um pouco velho. Ele permite que você use CDN, ou seja, você só precisa do nginx para distribuir o protocolo HLS. É compreensível em termos de monitoramento.

Aqui estão suas vantagens:

facilidade de operação - nginx como servidor proxy;
é fácil monitorar e obter métricas (basta monitorar o mesmo que o monitor em seu site);
Agora, este protocolo é o principal para entrega de conteúdo.

Menos significativo:

Alta latência.

A latência do HLS é realmente aninhada no próprio protocolo; como é necessário um longo tempo de buffer, o player é forçado a esperar pelo menos quando um pedaço é carregado, mas, de uma maneira boa, ele deve esperar até que dois pedaços (dois segmentos de mídia) sejam carregados; caso contrário, no caso de um atraso, o cliente terá o player carregado e isso não afetará muito bem experiência de usuário.

O segundo ponto que atrasa o HLS é o cache. A lista de reprodução é armazenada em cache na camada interna e nos servidores de borda. Mesmo se armazenamos em cache, relativamente falando, por um segundo ou meio segundo, isso representa aproximadamente mais 2-3 segundos de atraso. No total, acontece de 12 a 18 segundos - isso não é muito agradável, obviamente é melhor.

Melhorando o HLS

Com esses pensamentos, começamos a melhorar o HLS. Melhoramos de uma maneira bastante simples: vamos dar o último segmento de mídia ainda não gravado da playlist um pouco antes. Ou seja, assim que começamos a escrever o último segmento de mídia, o anunciamos imediatamente na playlist. O que está acontecendo neste momento? .. O

tempo de buffer nos jogadores é reduzido. O jogador acredita que já baixou tudo e começa a baixar com calma os segmentos desejados. Dessa forma, "enganamos" o player dessa maneira, mas se monitorarmos bem o "aço" (cargas no player), isso não nos assusta - podemos parar de fornecer o segmento com antecedência e tudo voltará ao normal.

O segundo ponto: ganhamos um total de cerca de 5-8 segundos. De onde eles vêm? O tempo desse segmento é de 2 a 4 segundos por segmento, mais o tempo para armazenar em cache a lista de reprodução (são outros 2 ou 3 segundos). Além disso, nosso atraso está diminuindo significativamente. O atraso é reduzido de 12 a 15 segundos para 5-7.

O que mais há de bom nessa abordagem? É realmente grátis! Só precisamos verificar se os jogadores são compatíveis com essa abordagem. Aqueles que são incompatíveis, enviamos para os URLs antigos e enviamos players compatíveis para os novos URLs. Não precisamos atualizar clientes antigos que suportam isso, o que também é importante. Na verdade, não precisamos modificar, liberar players em clientes móveis. Não precisamos desenvolver um web player. Parece bom o suficiente!

Dos pontos negativos - a necessidade de controlar o fluxo de vídeo recebido. No caso de um cliente móvel, podemos fazer isso com bastante facilidade (quando o fluxo vem de um cliente móvel) ou transcodificá-lo sem falhas, pois o player deve saber quanto tempo leva para um segmento de mídia. E como o anunciamos antes de realmente ser gravado, precisamos saber quanto tempo levará para gravá-lo.

Métricas de qualidade

Assim, melhoramos o HLS. Agora, quero dizer como monitoramos e quais métricas de qualidade captamos:

Uma das principais métricas de qualidade é o horário de início. Idealmente, é quando você percorre o cliente móvel antes da transmissão, pressiona o botão e ele inicia imediatamente. Seria ideal se ele fosse iniciado antes de você pressionar o botão, mas, infelizmente, somente quando você pressionar.
O segundo ponto é o atraso do sinal. Acreditamos que alguns segundos são muito bons, 10 segundos são toleráveis, 20-30 segundos são muito ruins. Por que isso é importante? Por exemplo, para shows e alguns eventos públicos, essa é uma métrica absolutamente sem importância, não há feedback; apenas mostramos o fluxo - é melhor não ficar atrasado do que um pequeno atraso. E para um fluxo em que algum tipo de conferência está acontecendo ou uma pessoa diz algo e faz perguntas, isso começa a ser importante, porque eles fazem muitas perguntas nos comentários e eu quero que o público receba feedback o mais rápido possível.

Outra métrica importante é o buffer e as defasagens. De fato, essa métrica é importante não apenas do ponto de vista do cliente e da qualidade, mas do ponto de vista de quanto podemos "esticar" a entrega do HLS, quanto podemos extrair dados de nossos servidores. Portanto, monitoramos o tempo médio do buffer nos players e o "aço".

A escolha da qualidade nos jogadores é compreensível: mudanças inesperadas são sempre irritantes.

Portanto, essa também é uma métrica importante.

Monitoramento

Temos muitas métricas de monitoramento, mas aqui eu escolhi aquelas métricas que sempre funcionam se algo der errado:

-, . - , . , – , ( , – ).
/ . , , , , , . .
edge-. , , edge- .

«», ?

Agora, mostrarei como lidamos com um aplicativo como o "Player" quando usamos nossa infraestrutura para transmitir um fluxo de vídeo com perguntas e respostas.

Clover é um questionário online. O anfitrião diz algo, pergunta: perguntas caem - você responde. 12 perguntas, 10 minutos do jogo, no final - algum tipo de prêmio. O que é tão complicado? Isso é crescimento!

À direita, este gráfico: O

pico [no gráfico] é a carga nos servidores em termos da API no momento do início do "Clover". O resto do tempo é o fluxo usual de transmissões. Isso não pode ser equiparado ao número de espectadores. Talvez este seja o número de solicitações e a carga.

É difícil: em 5 minutos, um milhão de espectadores chegou até nós no pico. Eles começam a assistir à transmissão, registrar-se, executar algum tipo de ação, solicitar um vídeo ... Parece um jogo muito simples, mas isso acontece em um período muito curto de tempo (todas as ações, incluindo o jogo final) - isso gera uma carga bastante alta.

Que perguntas e desafios enfrentamos?

Crescimento rápido. Às vezes, era de + 50% por semana. Se, por exemplo, você tem 200 mil pessoas na quarta-feira, então no sábado ou domingo já pode haver 300. Isso é muito! Começam a surgir problemas que não eram visíveis anteriormente.
2 . . , . , , , , , .
12 . , , , , , - , , …
, . , , 200-300 , 400-500.
- , , , 3-5 . ? «», , , , .

( 3 , ), , 3-5 . ? – , – exponential backoff, .

exponential on backoff: – , 2 , 4, 8. backend-.

«»?

-, . , – .
« ». , , , , «». , , -, , -, .
, – , «» . «». , , , … – . 10% «» – , 10% «» 100 – .
«» , , «» . – - . 100 – , 1 15 – .
. «» , , , . , , .
. , . , latency, .
. – , .
«» 1 . , , . . , , . .

?

A arquitetura nos convém completamente, e eu posso recomendá-la com segurança. A HLS permanecerá conosco o protocolo principal para pelo menos o site e pelo menos o protocolo de backup para todo o resto. Talvez possamos mudar para MPEG-DASH.

RTMP abandonado. Apesar de apresentar um atraso menor, decidimos ajustar o HLS. Talvez considere outros veículos de entrega, incluindo o DASH como uma alternativa.

Vamos melhorar o saldo de entrada. Também queremos fazer um failover contínuo para o balanceamento de entrada, para que, em caso de problemas em um dos servidores de mídia do cliente, a comutação seja completamente invisível.

Talvez desenvolvamos sistemas de entrega de servidores de borda para o cliente. Provavelmente, será algum tipo de UDP. Qual deles - agora estamos pensando e estamos na fase de pesquisa.

Na verdade, é tudo. Obrigado a todos!

Questões

Pergunta da platéia (doravante - A): - Muito obrigado pelo relatório! Apenas o orador do Odnoklassniki falou e ele disse que eles tinham que reescrever a serpentina, o codificador, o codificador ... Você usa essas soluções ou usa as que estão no mercado (como Harmonic, etc.)?

MR: - Agora temos soluções de terceiros giratórias. Das soluções de código aberto que usamos, tivemos o nginx, o módulo RTMP (por um longo tempo). Por um lado, ele nos agradou porque trabalhou, bastante simples. Lutamos por muito tempo para que ele trabalhasse de forma estável. Agora ele está passando do Nginx-RTMP para sua própria solução. Estamos pensando com um transcodificador agora. O receptor, ou seja, a parte receptora, também foi reescrito do Nginx-RTMP para sua solução.

E:- Eu queria fazer uma pergunta sobre fatiar o RTMP no HLS, mas pelo que entendi, você já respondeu ... Diga-me, suas soluções são de código aberto?

MR: - Estamos considerando lançá-lo em código aberto. Nós preferimos lançá-lo, mas a questão é o momento do lançamento em código aberto. Basta colocar a fonte na Internet - isso não é suficiente. Você precisa pensar, fazer alguns exemplos de implantação. E com que finalidade você está perguntando? Deseja usar?

A: - Porque eu também me deparei com o Nginx-RTMP! É, para dizer o mínimo, que não é suportado por muito tempo. O autor nem sequer responde a perguntas particularmente ...

MR: - Se você quiser, pode escrever para o correio. Dar para uso próprio? Nós podemos concordar. Nós realmente planejamos abri-lo.

E:- Você também disse que pode passar do HLS para o DASH. HLS não combina?

MR: - Esta é uma pergunta sobre o que podemos, ou talvez não. Depende muito do que chegaremos em termos de pesquisa de métodos de entrega alternativos (ou seja, UDP). Se encontrarmos algo “completamente” bom, provavelmente não tocaremos no HLS. Se parece que o MPEG-DASH é mais confortável, talvez possamos mudar isso. Não parece ser muito difícil, mas não temos certeza se é necessário ou não. A sincronização entre fluxos, entre qualidades e outras coisas é claramente melhor lá. Existem vantagens.

A: - Em relação aos alertas. Você falou sobre o fato de que, se os fluxos param de transmitir, isso é imediatamente um alerta. E você não percebeu algo independente: o provedor caiu, Megafon caiu e as pessoas pararam de transmitir? ..

MR:- Digamos que algo independente de nós é basicamente todos os tipos de feriados e assim por diante. Sim eles fizeram. Bem, eles fizeram sim. Os administradores olharam - hoje são as férias, o restante das características estão bem - eles se acalmaram.

A: - E sobre dimensionamento. Em que nível ele escala? Por exemplo, solicitei um fluxo do telefone - receberei imediatamente um determinado link com o servidor ash correto?

MR: - Um link será enviado imediatamente e, se necessário, será alternado (se houver problemas em um servidor específico).

A: - Quem trocará?

MR: - player móvel ou web player.

A: - Ele irá reiniciar o stream ou o quê?

MR: - Um novo link chegará até ele, onde ele deve ir ao vivo. Ele vai lá e pede novamente o fluxo.

E:- Em que nível você tem caches? E playlists e pedaços, ou apenas isso? ..

MR: - E playlists, pedaços! Ele armazena em cache de maneira um pouco diferente, tanto em termos de tempo quanto em termos de retorno do tempo, mas os armazenamos em cache.

A: - Em relação à criação de servidores de cinzas? Você teve uma situação dessas que assiste a 2 milhões de telespectadores em uma transmissão, não tem tempo para algo e pega rapidamente algum servidor ash? Ou você eleva tudo antecipadamente com uma margem?

Senhor:- Talvez não tenha sido. Em primeiro lugar, o estoque é sempre pequeno ou grande - isso não importa. Em segundo lugar, não acontece que uma transmissão repentinamente se torne super popular. Podemos prever bem o número de espectadores. Basicamente, para termos muitas pessoas, precisamos fazer um esforço. Dessa forma, podemos ajustar o número de espectadores da transmissão, dependendo de quais esforços são feitos.

A: - Você disse que mede atrasos instrumentais por parte do player. Quão?

MR: - Muito simples. Nos trechos (nos segmentos de mídia), temos um registro de data e hora, no nome do segmento de mídia - no player, apenas o retornamos. Se ele não é explicitamente, ele retorna.

R: - Lembro de tentar executar o peering no WebRTC. Por que recusou?

Senhor:"Eu não posso responder a esta pergunta para você - aconteceu sem mim." Não sei dizer por que tentei e não sei por que me recusei.

R: - Em relação ao receptor e ao servidor de mídia. Pelo que entendi, você costumava ter o Nginx-RTMP, agora, lá e ali, você tem soluções criadas por você. Na verdade, este é um servidor de mídia que proxies outros servidores de mídia, e eles já estão no cache e na borda.

MR: - Então, na verdade não. Essa é uma solução criada por você, mas é diferente em termos de servidor de mídia e de receptor. Nginx-RTMP - era algum tipo de colheitadeira que podia fazer as duas coisas. Nossos interiores do receptor e do servidor de mídia são muito diferentes - tanto por código quanto por toda parte. A única coisa que os une é o processamento RTMP.

A: - Em relação ao equilíbrio entre as arestas. Como isso acontece?

MR: - Medimos o tráfego, enviamos para o servidor desejado. Não entendi um pouco a pergunta ...

R: Explico: o usuário solicita uma lista de reprodução através do player - ele retorna os caminhos relativos a manifestos e partes ou caminhos absolutos, por exemplo, por IP ou domínio? ..

MR: - Os caminhos são relativos.

R: - Ou seja, não há balanceamento ao visualizar um fluxo por um usuário?

MR: - Isso acontece. Complicado o suficiente. Podemos usar o redirecionamento 301 ao sobrecarregar o servidor. Se percebermos que tudo está completamente ruim por lá, para segmentos, podemos enviá-lo para outro servidor.

A: - Mas deve estar ligado à lógica do jogador?

Senhor:- Não, apenas esta parte não deve ser costurada. Redirecionamento 301! Simplesmente, o jogador deve conseguir sair do 301º link. Podemos enviá-lo para outro servidor do lado do servidor no momento da sobrecarga.

A: - Ou seja, ele pergunta ao servidor, e o servidor entrega a ele?

MR: - Sim. Isso não é muito bom, portanto, a lógica do jogador é usada para retuitar links para o caso de falha de um dos servidores - isso já está na lógica do jogador.

R: - E você não tentou trabalhar não de forma relativa, mas de maneiras absolutas: quando você pede ao jogador que faça alguma mágica, descubra onde existem recursos e onde não existem e já fornece listas de reprodução indicando um servidor específico?

Senhor:- Na verdade, parece uma solução funcional. Se você tivesse vindo então, teríamos pesado os dois! Mas a solução atual também está funcionando, então não quero realmente pular de uma para outra, embora, talvez, isso também pareça uma solução funcional.

A: - Diga-me, isso é de alguma forma amigável com o multicast? HLS, pelo que entendi, absolutamente nada ...

MR: - Na implementação atual, provavelmente não temos nada no sistema com o multicast ao vivo. Não incluímos o conceito de multicast aqui. Talvez em algum lugar nas profundezas da magia administrativa, haja algo dentro da rede, mas esteja oculto a todos e ninguém saiba ...

Um pouco de publicidade :)

Obrigado por ficar com a gente. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando aos seus amigos o VPS baseado em nuvem para desenvolvedores a partir de US $ 4,99 , um analógico exclusivo de servidores básicos que foi inventado por nós para você: Toda a verdade sobre o VPS (KVM) E5-2697 v3 (6 núcleos) 10GB DDR4 480GB SSD 1Gbps de 10GB de US $ 19 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).

Dell R730xd 2 vezes mais barato no data center Equinix Tier IV em Amsterdã? Somente nós temos 2 TVs Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV a partir de US $ 199 na Holanda!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US $ 99! Leia sobre como construir infraestrutura classe c usando servidores Dell R730xd E5-2650 v4 que custam 9.000 euros por um centavo?

HighLoad ++, Mikhail Raichenko (ManyChat): quase sem mágica, ou como é fácil distribuir stream de vídeo terabit