Araw-araw, milyun-milyong manonood ang nanonood ng mga video sa Internet. Ngunit para maging available ang 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, isang taon na ang nakalipas sumali ako sa Yandex video technology team. Ngayon ay sasabihin ko sa madaling sabi sa mga mambabasa ng Habr tungkol sa kung paano, sa pamamagitan ng pagkakatulad ng proseso ng pag-encode, pinamamahalaan naming makabuluhang mapabilis ang paghahatid ng video sa gumagamit.
Ang post na ito ay pangunahing magiging interesado sa mga hindi pa nag-iisip tungkol sa kung ano ang nangyayari sa ilalim ng hood ng mga serbisyo ng video. Sa mga komento maaari kang magtanong at magmungkahi ng mga paksa para sa mga susunod na post.
Ang ilang mga salita tungkol sa gawain mismo. Hindi lamang tinutulungan ka ng Yandex na maghanap 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 orihinal na programa o isang sports match on air, isang pelikula sa KinoPoisk o mga video sa Zen at News - lahat ng ito ay ina-upload sa aming mga server. Upang mapanood ng mga user ang video, kailangan itong maging handa: na-convert sa kinakailangang format, gumawa ng preview, o kahit na tumakbo sa pamamagitan ng teknolohiya . Ang isang hindi nakahandang file ay tumatagal lamang ng espasyo. Bukod dito, pinag-uusapan natin hindi lamang ang tungkol sa pinakamainam na paggamit ng hardware, kundi pati na rin ang tungkol sa bilis ng paghahatid ng nilalaman sa mga gumagamit. Halimbawa: ang isang recording ng mapagpasyang sandali ng isang hockey match ay maaaring hanapin sa loob ng isang minuto pagkatapos ng mismong kaganapan.
Sequential encoding
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. Sa simula ng aming paglalakbay, ganito kami nagtrabaho:
Ina-upload ng kliyente ang video sa storage, kinokolekta ng component ng Analyzer ang meta information at inililipat ang video sa component ng Worker para sa conversion. Ang lahat ng mga yugto ay isinasagawa nang sunud-sunod. Sa kasong ito, maaaring mayroong maraming mga server ng pag-encode, ngunit isa lamang ang abala sa pagproseso ng isang partikular na video. Simple, transparent na diagram. Dito nagtatapos ang mga pakinabang nito. Ang scheme na ito ay maaari lamang i-scale nang patayo (dahil sa pagbili ng mas makapangyarihang mga server).
Sequential encoding na may intermediate na resulta
Upang kahit papaano mapawi ang masakit na paghihintay, ang industriya ay gumawa ng isang mabilis na opsyon sa pag-coding. Ang pangalan ay nakaliligaw, dahil sa katunayan, ang buong coding ay nangyayari nang sunud-sunod at tumatagal ng kasing tagal. Ngunit may isang intermediate na resulta. Ang ideya ay ito: maghanda at mag-publish ng isang mababang resolution na bersyon ng video sa lalong madaling panahon, at pagkatapos lamang ng mga mas mataas na resolution na bersyon.
Sa isang banda, mas mabilis na nagiging available ang video. At ito ay kapaki-pakinabang para sa mahahalagang kaganapan. Ngunit sa kabilang banda, lumalabas na malabo ang larawan, at nakakainis ito sa mga manonood.
Lumalabas na kailangan mong hindi lamang mabilis na iproseso ang video, ngunit mapanatili din ang kalidad nito. Ito ang inaasahan ng mga user mula sa isang serbisyo ng video ngayon. Maaaring mukhang sapat na ang pagbili ng mga pinaka-produktibong server (at regular na i-upgrade ang mga ito nang sabay-sabay). Ngunit ito ay isang patay na dulo, dahil palaging may isang video na magpapabagal kahit na ang pinakamalakas na hardware.
Parallel encoding
Mas mahusay na hatiin ang isang kumplikadong problema 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 i-scale nang pahalang (sa pamamagitan ng pagdaragdag ng mga bagong makina).
Sa pamamagitan ng paraan, ang ideya ng paghahati ng mga video sa maliliit na piraso, pagproseso ng mga ito nang magkatulad at pagdikit ng mga ito ay hindi isang lihim. Makakahanap ka ng maraming sanggunian sa diskarteng ito (halimbawa, sa HabrΓ© inirerekumenda ko ang isang post tungkol sa proyekto ). Ngunit hindi ito ginagawang mas madali sa pangkalahatan, dahil hindi ka maaaring kumuha ng isang handa na solusyon at itayo ito sa iyong tahanan. Kailangan natin ng adaptasyon sa ating imprastraktura, sa ating video at maging sa ating load. Sa pangkalahatan, mas madaling magsulat ng iyong sarili.
Kaya, sa bagong arkitektura, hinati namin ang monolithic Worker block na may sequential coding sa microservices Segmenter, Tcoder, Combiner.
- Hinahati ng Segmenter ang video sa mga fragment na humigit-kumulang 10 segundo. Ang mga fragment ay binubuo ng isa o higit pang mga GOP (). Ang bawat GOP ay independyente at naka-encode nang hiwalay upang ito ay ma-decode nang walang reference sa mga frame mula sa iba pang mga GOP. Iyon ay, ang mga fragment ay maaaring i-play nang nakapag-iisa sa bawat isa. Binabawasan ng sharding na ito ang latency, na nagpapahintulot sa pagproseso na magsimula nang mas maaga.
- Pinoproseso ng Tcoder ang bawat fragment. Ito ay nangangailangan ng isang gawain mula sa pila, nagda-download ng isang fragment mula sa imbakan, nag-encode nito sa iba't ibang mga resolusyon (tandaan na ang player ay maaaring pumili ng isang bersyon batay sa bilis ng koneksyon), pagkatapos ay ibabalik ang resulta sa imbakan at markahan ang fragment bilang naproseso sa database. Matapos maproseso 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 ang lahat ng mga fragment na ginawa ng Tcoder, bumubuo ng mga stream para sa iba't ibang mga resolusyon.
Ilang salita tungkol sa tunog. Ang pinakasikat na AAC audio codec ay may hindi kanais-nais na tampok. Kung magkahiwalay kang mag-e-encode ng mga fragment, hindi mo magagawang idikit ang mga ito nang walang putol. Mapapansin ang mga transition. Ang mga video codec ay walang ganitong problema. Sa teoryang, maaari kang maghanap ng isang kumplikadong teknikal na solusyon, ngunit ang larong ito ay hindi pa sulit sa kandila (ang audio ay mas mababa kaysa sa video). Samakatuwid, ang video lamang ang naka-encode nang magkatulad, at ang buong audio track ay pinoproseso.
Natuklasan
Salamat sa parallel na pagpoproseso ng video, nabawasan namin nang husto ang pagkaantala sa pagitan ng isang video na ina-upload sa amin at pagiging available sa mga user. Halimbawa, dati ay maaaring tumagal ng dalawang oras upang lumikha ng ilang buong bersyon ng iba't ibang kalidad para sa isang FullHD na pelikula na tumatagal ng isang oras at kalahati. Ngayon ang lahat ng ito ay tumatagal ng 15 minuto. Bukod dito, sa parallel processing, gumagawa kami ng high-resolution na bersyon na mas mabilis pa kaysa sa low-resolution na bersyon na may lumang intermediate result approach.
At isa pa. Sa lumang diskarte, maaaring walang sapat na mga server, o sila ay walang ginagawa nang walang mga gawain. Ang parallel coding ay nagbibigay-daan sa iyo upang madagdagan ang bahagi ng pag-recycle ng bakal. Ngayon ang aming kumpol ng higit sa isang libong mga server ay palaging abala sa isang bagay.
Sa katunayan, mayroon pa ring puwang para sa pagpapabuti. Halimbawa, makakatipid tayo ng malaking oras kung sisimulan natin ang pagproseso ng mga fragment ng video bago ito dumating sa amin sa kabuuan nito. Sabi nga nila, more to come.
Isulat sa mga komento kung anong mga gawain sa larangan ng pagtatrabaho sa video na gusto mong basahin.
Mga kapaki-pakinabang na link sa karanasan ng mga kasamahan sa industriya
Pinagmulan: www.habr.com