🥇Paano namin pinabilis ang pag-encode ng video ng walong beses

Araw-araw, milyun-milyong manonood ang nanonood ng mga video online. Ngunit para maging available ang isang video, hindi lang ito dapat i-upload sa server kundi maproseso din. Kung mas mabilis itong mangyari, mas mabuti para sa serbisyo at sa mga gumagamit nito.

Ang pangalan ko ay Askar Kamalov, at isang taon na ang nakalipas sumali ako sa koponan ng teknolohiya ng video ng Yandex. Ngayon, maikli kong ibabahagi sa mga mambabasa ng Habr kung paano, sa pamamagitan ng pag-parallelize ng proseso ng pag-encode, nagawa naming makabuluhang mapabilis ang paghahatid ng video sa mga user.

Ang post na ito ay magiging partikular na interes sa mga hindi pa napag-isipan kung ano ang nangyayari sa ilalim ng hood ng mga serbisyo ng video. Huwag mag-atubiling magtanong at magmungkahi ng mga paksa para sa mga susunod na post sa mga komento.

Ang ilang mga salita tungkol sa gawain mismo. Ang Yandex ay hindi lamang tumutulong sa paghahanap ng mga video sa iba pang mga site, ngunit nag-iimbak din ng mga video para sa sarili nitong mga serbisyo. Maging ito ay isang espesyal na programa o isang laban sa palakasan sa Efir, isang pelikula sa KinoPoisk, o mga video sa Zen at Novosti—lahat ito ay ina-upload sa aming mga server. Para mapanood ng mga user ang video, kailangan itong ihanda: i-convert sa kinakailangang format, isang preview na ginawa, o kahit na tumakbo sa teknolohiya. DeepHDAng isang hindi nakahanda na file ay kumukuha lamang ng espasyo. Bukod dito, ito ay hindi lamang isang bagay ng pinakamainam na paggamit ng hardware, kundi pati na rin ang bilis ng paghahatid ng nilalaman sa mga gumagamit. Halimbawa, ang isang recording ng isang mapagpasyang sandali sa isang hockey match ay maaaring hanapin sa loob ng isang minuto ng kaganapan.

Sequential coding

Kaya, ang kaligayahan ng user ay higit na nakadepende sa kung gaano kabilis naging available ang video. At ito ay pangunahing tinutukoy ng bilis ng transcoding. Kapag walang mahigpit na kinakailangan para sa bilis ng pag-upload ng video, walang mga problema. Kumuha ka ng isang solong, hindi mahahati na file, i-convert ito, at i-upload ito. Ganito kami nagtrabaho noong nagsimula kami:

Ina-upload ng kliyente ang video sa storage, kinokolekta ng component ng Analyzer ang metadata, at ipinapasa ang video sa component ng Worker para sa conversion. Ang lahat ng mga yugto ay isinasagawa nang sunud-sunod. Bagama't maaaring mayroong maraming mga server ng pag-encode, isa lamang ang nakatuon sa pagproseso ng isang partikular na video. Ito ay isang simple, transparent na pamamaraan. Doon nagtatapos ang mga pakinabang nito. Ang scheme na ito ay sumusukat lamang nang patayo (sa pamamagitan ng pagbili ng mas makapangyarihang mga server).

Sequential coding na may intermediate na resulta

Upang maibsan ang masakit na paghihintay, ang industriya ay gumawa ng isang paraan na tinatawag na "mabilis na pag-encode." Ang pangalan ay nakaliligaw, dahil ang buong pag-encode ay aktwal na nagaganap nang sunud-sunod at kasing haba. Ngunit nag-aalok ito ng isang intermediate na resulta. Ang ideya ay upang maghanda at mag-upload ng isang mababang resolution na bersyon ng video sa lalong madaling panahon, at pagkatapos ay i-release ang mga mas mataas na resolution na bersyon sa ibang pagkakataon.

Sa isang banda, mas mabilis na nagiging available ang video, na kapaki-pakinabang para sa mahahalagang kaganapan. Ngunit sa kabilang banda, malabo ang imahe na nakakairita sa mga manonood.

Lumalabas na ang video ay kailangang maproseso hindi lamang nang mabilis ngunit mapanatili din ang kalidad nito. Ito ang inaasahan ng mga user mula sa isang serbisyo ng video sa mga araw na ito. Maaaring mukhang tulad ng pagbili ng pinakamakapangyarihang mga server (at regular na pag-upgrade ng mga ito nang sabay-sabay) ay sapat na. Ngunit ito ay isang patay na dulo, dahil palaging may isang video na magpapabagal kahit na ang pinakamalakas na hardware.

Parallel coding

Mas mahusay na hatiin ang isang kumplikadong gawain sa maraming hindi gaanong kumplikado at lutasin ang mga ito nang magkatulad sa iba't ibang mga server. Ito ay MapReduce para sa video. Sa kasong ito, hindi kami nalilimitahan ng pagganap ng isang server at maaaring mag-scale nang pahalang (sa pamamagitan ng pagdaragdag ng higit pang mga machine).

Sa pamamagitan ng paraan, ang ideya ng paghiwa-hiwalayin ang mga video sa maliliit na piraso, pagproseso ng mga ito nang magkatulad, at pagsasama-sama ng mga ito ay hindi lihim. Makakahanap ka ng maraming sanggunian sa diskarteng ito (halimbawa, inirerekomenda ko ang isang post tungkol sa proyekto sa Habr). DistVIDc). Ngunit hindi nito ginagawang mas madali ang mga bagay, dahil hindi ka maaaring kumuha ng isang handa na solusyon at ipatupad ito. Kailangan mo itong iakma sa iyong imprastraktura, iyong video, at maging sa iyong workload. Karaniwan, mas madaling magsulat ng iyong sarili.

Kaya, sa bagong arkitektura, hinati namin ang monolithic Worker block na may sequential coding sa mga microservice Segmenter, Tcoder, at Combiner.

Hinahati ng Segmenter ang isang video sa mga fragment na humigit-kumulang 10 segundo bawat isa. Ang mga fragment ay binubuo ng isa o higit pang mga GOP (pangkat ng mga larawan). Ang bawat GOP ay independyente at naka-encode nang hiwalay, kaya maaari itong i-decode nang walang reference sa mga frame mula sa iba pang mga GOP. Nangangahulugan ito na ang mga fragment ay maaaring laruin nang hiwalay sa isa't isa. Binabawasan ng segmentation na ito ang latency, na nagbibigay-daan sa pagproseso na magsimula nang mas maaga.
Pinoproseso ng Tcoder ang bawat fragment. Ito ay nangangailangan ng isang gawain mula sa pila, i-download ang fragment mula sa imbakan, i-encode ito sa iba't ibang mga resolusyon (tandaan, ang player ay maaaring pumili ng bersyon batay sa bilis ng koneksyon), pagkatapos ay iimbak ang resulta pabalik sa imbakan at markahan ang fragment bilang naproseso sa database. Pagkatapos iproseso ang lahat ng mga fragment, ipinapadala ng Tcoder ang gawain upang makabuo ng mga resulta para sa susunod na bahagi.
Kinokolekta ng Combiner ang mga resulta nang magkasama: dina-download nito ang lahat ng mga fragment na ginawa ng Tcoder at bumubuo ng mga stream para sa iba't ibang mga resolusyon.

Ilang salita tungkol sa audio. Ang pinakasikat na audio codec, ang AAC, ay may kapus-palad na quirk. Kung i-encode mo ang mga fragment nang hiwalay, hindi mo lang maitatahi ang mga ito nang walang putol. Mapapansin ang mga transition. Walang ganitong problema ang mga video codec. Sa teorya, maaaring makahanap ng isang sopistikadong teknikal na solusyon, ngunit sa ngayon, ito ay hindi sulit ang pagsisikap (ang audio ay makabuluhang mas maliit kaysa sa video). Samakatuwid, ini-encode lang namin ang video nang magkatulad, habang ang audio track ay ganap na pinoproseso.

Natuklasan

Salamat sa parallel na pagpoproseso ng video, makabuluhang nabawasan namin ang pagkaantala sa pagitan ng pag-upload ng video sa amin at ginagawa itong available sa mga user. Halimbawa, dati, ang paggawa ng maraming buong kalidad na bersyon ng isang Full HD na pelikula na tumatagal ng isang oras at kalahati ay maaaring tumagal ng dalawang oras. Ngayon, ang buong proseso ay tumatagal lamang ng 15 minuto. Bukod dito, sa parallel processing, ginagawa namin ang high-resolution na bersyon nang mas mabilis kaysa sa low-resolution na bersyon gamit ang lumang diskarte ng pansamantalang resulta.

At isa pa. Sa lumang diskarte, maaaring walang sapat na mga server o nakaupo silang walang ginagawa. Ang parallel coding ay nagbibigay-daan sa amin na pataasin ang paggamit ng hardware. Ngayon ang aming kumpol ng higit sa isang libong mga server ay patuloy na abala.

Sa katunayan, mayroon pa ring puwang para sa pagpapabuti. Halimbawa, makakatipid kami ng malaking oras kung sinimulan naming iproseso ang mga fragment ng video bago sila ganap na natanggap. Tulad ng sinasabi nila, ang hinaharap ay may hawak.

Ipaalam sa amin sa mga komento kung anong mga gawaing nauugnay sa video ang gusto mong basahin.