{"id":75722,"date":"2020-03-28T07:42:04","date_gmt":"2020-03-28T05:42:04","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-my-uskorili-kodirovanie-video-v-vosem-raz"},"modified":"2020-03-28T07:42:04","modified_gmt":"2020-03-28T05:42:04","slug":"kak-my-uskorili-kodirovanie-video-v-vosem-raz","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-my-uskorili-kodirovanie-video-v-vosem-raz","title":{"rendered":"Come abbiamo accelerato la codifica video di otto volte","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Come
\n
\nOgni giorno milioni di spettatori guardano video online. Ma per rendere un video accessibile, deve essere non solo caricato sul server, ma anche elaborato. Pi\u00f9 velocemente avviene questo, meglio \u00e8 per il servizio e i suoi utenti. <\/p>\n

Mi chiamo Askar Kamalov, e un anno fa mi sono unito al team di tecnologie video di Yandex. Oggi racconter\u00f2 brevemente ai lettori di Habr come, attraverso il parallelismo del processo di codifica, siamo riusciti ad accelerare notevolmente la consegna dei video agli utenti. <\/p>\n

Questo post sar\u00e0 particolarmente interessante per coloro che non hanno mai riflettuto su ci\u00f2 che avviene dietro le quinte dei servizi video. Nei commenti puoi porre domande e proporre argomenti per futuri post.
\n<\/a><\/noindex>
\nQualche parola sulla questione stessa. Yandex non solo aiuta a cercare video su altri siti, ma archivia anche video per i propri servizi. Che si tratti di un programma originale, di una partita sportiva in diretta, di un film su Kinopoisk o di clip su Zen e Notizie, tutto questo viene caricato sui nostri server. Affinch\u00e9 gli utenti possano guardare i video, \u00e8 necessario prepararli: convertirli nel formato necessario, creare una miniatura o anche passarli attraverso la tecnologia DeepHD<\/a><\/noindex>. Un file non preparato occupa semplicemente spazio. Ed \u00e8 una questione che riguarda non solo l'uso ottimale dell'hardware, ma anche la velocit\u00e0 di consegna dei contenuti agli utenti. Un esempio: una registrazione con un momento decisivo di una partita di hockey pu\u00f2 essere cercata gi\u00e0 un minuto dopo l'evento stesso.<\/p>\n

Codifica sequenziale<\/h3>\n

\nQuindi, la felicit\u00e0 dell'utente dipende in gran parte da quanto rapidamente il video diventa disponibile. E questo \u00e8 principalmente determinato dalla velocit\u00e0 di transcodifica. Quando non ci sono requisiti rigorosi per la velocit\u00e0 di pubblicazione dei video, non ci sono neanche problemi. Prendi un file unico e indivisibile, lo converti e lo carichi. All'inizio del nostro percorso, abbiamo lavorato in questo modo:<\/p>\n

\"Come
\n
\nIl cliente carica il video nel vault, il componente Analyzer raccoglie i metadati e invia il video al componente Worker per la conversione. Tutte le fasi vengono eseguite in sequenza. Sebbene ci possano essere molti server per la codifica, solo uno \u00e8 impegnato a elaborare un video specifico. Uno schema semplice e trasparente. Ma qui finiscono i suoi pregi. Questo schema pu\u00f2 scalare solo verticalmente (acquistando server pi\u00f9 potenti). <\/p>\n

Codifica sequenziale con risultato intermedio<\/h3>\n

\nPer alleviare l'inevitabile attesa, nel settore \u00e8 stata inventata una variante di codifica rapida. Un nome ingannevole, perch\u00e9 in realt\u00e0 la codifica completa avviene in sequenza e richiede lo stesso tempo. Ma offre un risultato intermedio. L'idea \u00e8 quella di preparare e pubblicare la versione video a bassa risoluzione il pi\u00f9 rapidamente possibile, per poi seguire con versioni ad alta risoluzione. <\/p>\n

Da un lato, il video \u00e8 disponibile pi\u00f9 rapidamente. Questo \u00e8 utile per eventi importanti. Dall'altro, la qualit\u00e0 dell'immagine risulta sfocata, che irrita gli spettatori.<\/p>\n

\u00c8 fondamentale non solo elaborare rapidamente i video, ma anche preservarne la qualit\u00e0. Questo \u00e8 ci\u00f2 che gli utenti si aspettano da un servizio video al giorno d'oggi. Potrebbe sembrare sufficiente acquistare i server pi\u00f9 potenti (e aggiornarli regolarmente). Ma questo \u00e8 un vicolo cieco, poich\u00e9 ci sar\u00e0 sempre un video che far\u00e0 rallentare anche l'hardware pi\u00f9 potente. <\/p>\n

Codifica parallela<\/h3>\n

\n\u00c8 molto pi\u00f9 efficiente suddividere un compito complesso in molteplici compiti pi\u00f9 semplici e risolverli in parallelo su server diversi. Una sorta di MapReduce per i video. In questo modo non ci limitiamo alle prestazioni di un singolo server e possiamo scalare orizzontalmente (aggiungendo nuove macchine). <\/p>\n

A proposito, l'idea di frammentare i video in piccoli pezzi, elaborarli in parallelo e poi riunirli non \u00e8 un segreto. Puoi trovare numerosi riferimenti a questo approccio (ad esempio, su Habr, consiglio un post sul progetto DistVIDc<\/a><\/noindex>). Ma questo non rende tutto pi\u00f9 semplice, perch\u00e9 non puoi semplicemente prendere una soluzione pronta e integrarla con la tua. \u00c8 necessaria un'adattamento alla nostra infrastruttura, ai nostri video e persino ai nostri carichi di lavoro. Insomma, \u00e8 spesso pi\u00f9 facile scrivere il proprio. <\/p>\n

Nella nuova architettura del blocco monolitico Worker con codifica sequenziale, abbiamo suddiviso il sistema in microservizi Segmenter, Tcoder e Combiner.<\/p>\n

\"Come
\n<\/p>\n

    \n
  1. Segmenter suddivide il video in frammenti di circa 10 secondi. I frammenti sono composti da uno o pi\u00f9 GOP (group of pictures<\/a><\/noindex>). Ogni GOP \u00e8 indipendente e viene codificato separatamente, consentendo la decodifica senza fare riferimento ai frame di altre GOP. Ci\u00f2 significa che i frammenti possono essere riprodotti indipendentemente l'uno dall'altro. Questa segmentazione riduce la latenza, permettendo di avviare l'elaborazione anticipatamente.<\/li>\n
  2. Tcoder elabora ogni frammento. Prende un compito dalla coda, scarica il frammento dal deposito, lo codifica in diverse risoluzioni (ricordiamo che il lettore pu\u00f2 scegliere la versione in base alla velocit\u00e0 della connessione), quindi ripone il risultato nuovamente nel deposito e segna il frammento come elaborato nel database. Dopo aver elaborato tutti i frammenti, Tcoder invia il compito per la generazione dei risultati al prossimo componente.<\/li>\n
  3. Combiner raccoglie i risultati insieme: scarica tutti i frammenti creati da Tcoder e forma flussi per diverse risoluzioni.<\/li>\n<\/ol>\n

    \nAlcune parole sul suono. Il codec audio AAC, il pi\u00f9 popolare, ha una sgradevole peculiarit\u00e0. Se si codificano i frammenti separatamente, non sar\u00e0 possibile unirli senza soluzione di continuit\u00e0. Le transizioni saranno visibili. I codec video, invece, non hanno questo problema. Teoricamente, sarebbe possibile cercare una soluzione tecnica complessa, ma al momento non ne vale la pena (l'audio pesa notevolmente meno del video). Pertanto, codifichiamo parallelamente solo il video, mentre la traccia audio viene elaborata nella sua interezza.<\/p>\n

    Risultati<\/h3>\n

    \nGrazie all'elaborazione parallela del video, abbiamo ridotto significativamente il ritardo tra il caricamento del video e la sua disponibilit\u00e0 per gli utenti. Ad esempio, in passato, per creare diverse versioni complete di qualit\u00e0 diversa per un film in FullHD della durata di un'ora e mezza, potevano servire fino a due ore. Ora, tutto questo richiede solo 15 minuti. Inoltre, nell'elaborazione parallela, riusciamo a creare una versione ad alta risoluzione anche pi\u00f9 velocemente rispetto a una versione a bassa risoluzione con l'approccio precedente che prevedeva un risultato intermedio. <\/p>\n

    E un'ultima cosa. Con il vecchio approccio, a volte mancavano i server o rimanevano inattivi senza compiti. La codifica parallela aumenta la percentuale di utilizzo dell'hardware. Ora il nostro cluster, composto da oltre mille server, \u00e8 sempre impegnato in qualche attivit\u00e0. <\/p>\n

    In realt\u00e0, c'\u00e8 ancora molto da migliorare. Ad esempio, potremmo risparmiare significativamente tempo se iniziassimo a elaborare i frammenti video ancora prima che arrivino completamente. Come si suol dire, il meglio deve ancora venire. <\/p>\n

    Scrivete nei commenti quali argomenti legati alla lavorazione video vi piacerebbe leggere. <\/p>\n

    Link utili sulle esperienze dei colleghi del settore<\/h3>\n

    <\/p>\n