YouTube qanday ishlaydi

Bu darsda nima o‘rganasiz

Oldingi uchta darsda — Slack, WhatsApp va qisman Reddit’da — biz kichik narsalarni tez yetkazish bilan shug‘ullandik: 400 baytlik xabar, 50 baytlik belgi, 8 baytlik ovoz. YouTube teskari dunyo: bitta ob’ekt gigabaytlar, va uni millionlab odam bir vaqtda ko‘radi.

Bu o‘zgarish muhandislik muammolarini tubdan o‘zgartiradi. Endi savol “xabar qancha tez yetadi” emas, balki: bir soatlik videoni 2G tarmoqdagi telefonga va 4K televizorga qanday qilib bir xil faylni yubormasdan ko‘rsatasiz? Kuniga 1 eksabaytdan ortiq trafikni kim to‘laydi? Va nega yuklangan videolarning ko‘pchiligini qimmat usulda siqish — pulni yoqish?

Yo‘l shunday: avval videoning o‘zini noldan tushunamiz — kadr, piksel, siqilmagan bitreyt, va kodek uni qanday qilib 150 barobar kichraytiradi. Keyin adaptiv bitreyt oqimi (ABR): video nega bo‘laklarga bo‘linadi va pleyer har 4 soniyada qanday qaror qabul qiladi. So‘ng transkodlash quvuri, CDN va internet provayderlar ichidagi keshlar, va darsning eng qiziq qismi — uzun dum iqtisodi: nega eng yaxshi kodek faqat videolarning 1–2% i uchun o‘zini oqlaydi.

Dars oldingi darslardan mustaqil o‘qiladi. Ba’zi joylarda Reddit (Zipf taqsimoti) va WhatsApp (media siqish, Little qonuni) darslariga havolalar bor, lekin ular shart emas.

1. Muammo: aslida nimani qurmoqchimiz?

1.1 Funksional talablar

Bu jadvalning birinchi uchta qatori bitta quvurni tashkil qiladi (yuklash → qayta ishlash → tomosha) va darsning 80% i shu haqida. Qolgan beshtasi — yirik mustaqil tizimlar, har biri alohida darsga arziydi. Biz ularni faqat quvurga ta’sir qiladigan darajada ko‘ramiz: tavsiyalar — qaysi videolar issiq bo‘lishini, hisoblagichlar — Reddit’dagi ovoz muammosining takrorini, mualliflik huquqi — yuklash quvuriga qo‘shilgan qo‘shimcha bosqichni.

1.2 Nofunksional talablar

Ikkinchi qator eng qat’iy va eng qiziq: buferlash tomosha vaqtining 0.5% idan kam. Bu raqam tasodifiy emas. Video tomosha qilish sifati bo‘yicha tadqiqotlar (masalan, 2011-yilgi SIGCOMM maqolasi — Dobrian va hammualliflar) buferlash ulushi oshishi bilan tomosha vaqti sezilarli kamayishini ko‘rsatgan. Ya’ni bu yerda texnik metrika to‘g‘ridan-to‘g‘ri biznes metrikasi: buferlash — yo‘qotilgan tomosha, yo‘qotilgan tomosha — yo‘qotilgan reklama.

Oxirgi qator esa Slack yoki WhatsApp’da umuman bo‘lmagan tur: narx — nofunksional talab. 12-bo‘limda ko‘ramizki, YouTube’ning arxitekturasi ko‘p jihatdan shu bitta qatordan kelib chiqadi.

1.3 Konvert orqasidagi hisob

Uchta xulosa, va ular darsning qolgan qismini belgilaydi.

Birinchi — bu o‘qish tizimi. Har bir yuklangan bayt o‘rtacha 430 marta o‘qiladi. Demak yozish yo‘lida (transkodlash, saqlash) qilingan har qanday ish, agar u o‘qish yo‘lini arzonlashtirsa, o‘zini ko‘p barobar oqlaydi. Butun “bir marta siq, ko‘p marta yubor” strategiyasi shu nisbatdan chiqadi.

Ikkinchi — chiqish trafigi astronomik. 104 Tbit/s o‘rtacha, cho‘qqida ikki-uch barobar ko‘p. Hech bir bitta ma’lumot markazi buni chiqara olmaydi, va hech bir kompaniya buni oddiy tranzit narxida to‘lay olmaydi. 8-bo‘lim shu muammoga bag‘ishlangan.

Uchinchi — “o‘rtacha” aldamchi. 430 barobar — bu o‘rtacha. Aslida ba’zi videolar milliard marta ko‘riladi, ko‘pchiligi esa deyarli hech qachon. 7-bo‘limda bu taqsimot eng qimmat qarorlarni qanday belgilashini ko‘ramiz.

2. Nol nuqta: video aslida nima

Servis, CDN va kodeklar haqida gapirishdan oldin bitta savolga aniq javob kerak: bir soniya video nechta bayt? Bu savolga javob butun tizimning o‘lchamini belgilaydi.

2.1 Siqilmagan video: kadr, piksel, rang

Video — bu tez almashadigan rasmlar (kadrlar) ketma-ketligi. Har bir kadr — piksellar to‘ri. Har bir piksel — rang.

746 Mbit/s — bu yaxshi uy internetidan 10–20 barobar ko‘p, mobil internetdan esa 100 barobardan ortiq. Siqilmagan video internet orqali umuman yuborib bo‘lmaydi. YouTube’dagi 1080p video esa odatda ~3–8 Mbit/s atrofida. Demak kodek videoni 100–250 barobar siqadi. Qanday qilib?

2.2 Kodek: nima takrorlanishini topish

Siqishning butun siri bitta kuzatishda: ketma-ket kadrlar deyarli bir xil. Odam gapirayotgan videoda fon qimirlamaydi, faqat og‘iz va qo‘llar harakatlanadi. Har bir kadrni to‘liq saqlash o‘rniga kodek faqat farqni saqlaydi.

Bu jadvaldagi raqamlar taxminiy va kontentga juda bog‘liq, lekin xulosa aniq: I-kadr qimmat, qolganlari arzon. Oddiy videoda har 2–5 soniyada bitta I-kadr bo‘ladi, orasidagi 60–150 kadr esa P va B.

I-kadrlar orasidagi guruhga GOP (Group of Pictures) deyiladi. Va GOP butun tizim uchun muhim, chunki videoni faqat I-kadrdan boshlab ochish mumkin: P-kadr “oldingi kadrga nisbatan” saqlangan, va agar oldingi kadr yo‘q bo‘lsa, uni tiklab bo‘lmaydi.

Vaqt  ->
I  B  B  P  B  B  P  B  B  P ... I  B  B  P ...
|<--------- GOP (masalan, 2 s) ------->|<--- keyingi GOP

Sakrash (seek) faqat I dan boshlanadi.
Bo'laklarga bo'lish (2.4) faqat I da mumkin.
Parallel siqish (5-bo'lim) faqat I chegarasida mumkin.

Bu uchta oqibatning har biri keyingi bo‘limlarda arxitektura qaroriga aylanadi. Hozircha eslab qoling: I-kadr — video olamidagi “tranzaksiya chegarasi”. U yerdan boshlash, kesish va bo‘lish mumkin; o‘rtasidan esa yo‘q.

Joriy kadrdagi blok (x=320, y=200)
  -> oldingi kadrda qidiruv oynasi (masalan, ±64 piksel)
  -> eng o'xshash blok (x=317, y=201) da topildi
  -> saqlanadi:
       harakat vektori: (-3, +1)            ~ 2-4 bayt
       qoldiq: joriy blok - topilgan blok   ~ ko'pincha deyarli nol,
                                              kuchli siqiladi
  Butun blokni saqlash o'rniga (16x16x1.5 = 384 bayt) — o'nlab bayt.

2.3 Bitreyt zinapoyasi: bitta video — o‘nta fayl

Telefon 2G’da 300 kbit/s oladi, televizor optik tolada 100 Mbit/s. Bitta faylni ikkalasiga ham yuborib bo‘lmaydi: biriga juda katta, ikkinchisiga juda xira. Yechim — bitta videoning bir nechta nusxasi, har biri boshqa o‘lcham va bitreytda. Bu to‘plam bitreyt zinapoyasi (bitrate ladder) deb ataladi.

Jadvaldagi eng muhim ustun — oxirgisi: har bir pog‘ona muayyan qurilma va tarmoq uchun. Zinapoyani loyihalash — bu “qanday tomoshabinlarimiz bor” degan savolga javob. Masalan, auditoriyaning katta qismi arzon telefonda va sekin tarmoqda bo‘lsa, pastki pog‘onalar zichroq bo‘lishi kerak (240p va 360p orasiga yana biri); agar tomoshabinlar asosan televizorda bo‘lsa — yuqori pog‘onalar.

Ikkinchi xulosa — saqlash: bitta videoning barcha pog‘onalari birgalikda taxminan 40 Mbit/s (jadval yig‘indisi), ya’ni eng yuqori sifatning ~2 barobari. Ya’ni zinapoya saqlashni taxminan ikki barobar oshiradi, va har bir qo‘shimcha kodek (VP9, AV1) yana shuncha qo‘shadi.

2.4 Bo‘laklar va manifest: pleyer har 4 soniyada qaror qiladi

Endi asosiy mexanizm. Bir nechta nusxa bor, lekin tarmoq tomosha davomida o‘zgaradi: metroga tushdingiz, Wi-Fi’dan mobilga o‘tdingiz. Pleyer sifatni video o‘rtasida almashtira olishi kerak.

Yechim — har bir nusxani qisqa bo‘laklarga (segmentlarga) bo‘lish, masalan, har biri 4 soniya. Muhim shart: barcha nusxalarda bo‘lak chegaralari bir xil vaqtda va har bir bo‘lak I-kadrdan boshlanadi (2.2). Shunda pleyer 17-bo‘lakni 720p’da, 18-sini 360p’da, 19-sini yana 720p’da olishi mumkin — va video uzilmasdan davom etadi.

Pleyer qaysi bo‘laklar borligini manifest fayldan biladi:

# HLS manifest (soddalashtirilgan) — master.m3u8
#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=700000,RESOLUTION=640x360
360p/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2500000,RESOLUTION=1280x720
720p/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
1080p/playlist.m3u8

# 720p/playlist.m3u8
#EXTM3U
#EXT-X-TARGETDURATION:4
#EXTINF:4.0,
seg_00000.m4s
#EXTINF:4.0,
seg_00001.m4s
...

Ikki standart format bor: Apple’ning HLS (2009) va MPEG’ning DASH (2012). Ular sintaksisda farq qiladi, g‘oyada esa bir xil: manifest nusxalarni sanaydi, har bir nusxa bo‘laklar ro‘yxati, har bir bo‘lak — oddiy HTTP orqali olinadigan fayl.

Oxirgi so‘zlar — “oddiy HTTP fayl” — butun arxitekturaning eng muhim qarori. Video uchun maxsus server, maxsus protokol, doimiy ulanish kerak emas. Har bir bo‘lak — statik fayl, uni har qanday HTTP kesh, har qanday CDN, har qanday proksi saqlay oladi. Slack darsida biz doimiy ulanishning narxini (35 KB xotira, qayta ulanish bo‘ronlari) hisobladik; video oqimi bu narxni butunlay chetlab o‘tadi.

Bu hisob klassik uch tomonlama savdoni ko‘rsatadi: qisqa bo‘lak — tez moslashish va tez boshlanish, lekin ko‘p so‘rov va yomonroq siqish; uzun bo‘lak — aksincha. HLS dastlab 10 soniyani tavsiya qilgan, keyinchalik 6 soniyaga tushirilgan; ko‘p xizmatlar 2–6 soniya oralig‘ida ishlaydi. Jonli efirda esa (5-bo‘lim, 14-qadam) kechikish talabi bo‘lakni yanada qisqartirishga majbur qiladi.

3. v0: eng sodda ishlaydigan yechim

Yuklangan faylni saqlash va uni qanday bo‘lsa, shunday qaytarish. YouTube’ning ilk kunlaridagi (2005) video saytlar aynan shunday ishlagan va bu haqiqatan ishlaydi.

@app.post("/upload")
def upload(file):
    vid = new_id()
    storage.put(f"videos/{vid}.mp4", file.read())       # bitta so'rovda butun fayl
    db.insert("videos", id=vid, owner=user.id, views=0)
    return {"id": vid}

@app.get("/watch/{vid}")
def watch(vid, request):
    db.execute("UPDATE videos SET views = views + 1 WHERE id = %s", vid)
    # HTTP Range: brauzer "baytlar 5 000 000 dan boshlab" so'rashi mumkin
    return storage.stream(f"videos/{vid}.mp4", range=request.headers.get("Range"))

Bu kodda yashiringan ikkita to‘g‘ri qaror bor, va ular keyin ham qoladi.

Birinchi — HTTP Range so‘rovlari. Brauzer butun faylni kutmaydi: u boshidan yuklay boshlaydi va o‘ynay boshlaydi (“progressiv yuklash”), foydalanuvchi o‘rtaga sakrasa esa Range: bytes=... bilan kerakli joydan so‘raydi. Bu 2.4-dagi bo‘laklar g‘oyasining ibtidoiy shakli: video allaqachon “oddiy HTTP fayl”.

Ikkinchi — ob’ekt ombori. Video ma’lumotlar bazasiga emas, alohida fayl omboriga yoziladi; bazada faqat metama’lumot. Bu ajratish oxirigacha saqlanadi.

Nima yetishmaydi — hamma narsa. Keyingi bo‘lim.

4. Nima sindi

4.1 Bitta fayl — hammaga noto‘g‘ri

Foydalanuvchi telefonida 1080p yozdi (~16 Mbit/s). Endi uni kim ko‘radi?

Jadval ikki tomonlama muvaffaqiyatsizlikni ko‘rsatadi: sekin tarmoqda video o‘ynamaydi, tez tarmoqda esa trafik isrof bo‘ladi. Birinchisi foydalanuvchini yo‘qotadi, ikkinchisi — pulni (sizniki va foydalanuvchining mobil paketi). Ikkalasining ham yechimi bitta: bitreyt zinapoyasi (2.3) va ABR (2.4).

Oxirgi ikki qator — ABR ning narxi, va u yozish yo‘lida to‘lanadi: transkodlash va qo‘shimcha saqlash. Birinchi uchta qator esa uning foydasi, va u o‘qish yo‘lida olinadi — har bir tomoshada. 430:1 nisbat (1.3) bu savdoni aniq hal qiladi.

4.2 Har bir qurilma boshqa format istaydi

Telefon kamerasi HEVC (H.265) da yozadi, eski brauzer faqat H.264 ni o‘ynaydi, televizor ilovasi 60 kadrni istaydi, planshet — vertikal video. Yuklangan fayl o‘z holida ko‘pchilik qurilmada umuman ochilmaydi yoki noto‘g‘ri ochiladi.

Demak serverda transkodlash — har bir yuklangan videoni standart formatlarga qayta siqish — majburiy. Va 1.3-dagi Check’da aytganimizdek, bu tizimning eng qimmat hisoblash operatsiyasi.

4.3 Chiqish trafigi

Bu hisobning xulosasi keskin: YouTube miqyosidagi video platformani “bulutdan chiqish trafigi” modelida qurib bo‘lmaydi. Trafik narxini tubdan boshqa modelga o‘tkazish kerak — va bu 8-bo‘limning mavzusi (internet provayderlar ichidagi keshlar).

4.4 Katta fayl bitta so‘rovda yuklanmaydi

Bu yerda kvadratik emas, lekin eksponensial tuzoq bor: muvaffaqiyat ehtimoli fayl hajmi bilan eksponensial kamayadi (0.98^daqiqalar). 4 GB fayl uchun bu 0.98^54 = 34%, ya’ni ko‘pchilik urinish muvaffaqiyatsiz. Yechim — yuklashni qayta tiklanadigan qilish: fayl bo‘laklarda yuboriladi, uzilishdan keyin oxirgi tasdiqlangan bo‘lakdan davom etadi (5-bo‘lim, 1-qadam).

4.5 Ko‘rishlar hisoblagichi — Reddit muammosi qaytdi

UPDATE videos SET views = views + 1 — bu Reddit darsidagi ovoz hisoblagichining aynan takrori (Reddit, 5.2).

Yechim ham Reddit’dagiga o‘xshash (guruhlash, shardlangan hisoblagichlar), lekin bitta yangi murakkablik bilan: ko‘rish — pul. Mualliflar ko‘rishlar soniga qarab daromad oladi, reklama beruvchilar esa ko‘rishlar uchun to‘laydi. Demak soxta ko‘rish — firibgarlik, va hisoblagich faqat tez emas, tekshirilgan bo‘lishi kerak. 5-bo‘limning 12-qadamida buni ko‘ramiz.

5. Evolyutsiya: o‘n to‘rt qadam

1. POST /upload/sessions  {hajm: 2 GB, tur: video/mp4}
   <- {upload_url: ".../sessions/abc123"}         (sessiya 7 kun yashaydi)

2. PUT .../sessions/abc123
   Content-Range: bytes 0-8388607/2147483648      (8 MB bo'lak)
   <- 308 Resume Incomplete, Range: bytes=0-8388607

   ... uzilish ...

3. PUT .../sessions/abc123   (bo'sh so'rov, "qayerdamiz?")
   Content-Range: bytes */2147483648
   <- 308, Range: bytes=0-754974719              (720 MB saqlangan)
   -> mijoz 754974720 dan davom etadi

Yuklash tugagach:
  h = SHA-256(fayl)                           # 1 GB uchun ~2-3 s CPU
  agar h allaqachon "transkodlangan" to'plamda bo'lsa:
      yangi video yozuvi -> mavjud nusxalarga ishora qiladi
      transkodlash YO'Q, saqlash YO'Q (faqat metama'lumot)
  aks holda:
      odatdagi quvur

Yuklanganda:        H.264 zinapoyasi (hamma uchun, darhol)
+ bir necha soatda: VP9 (ko'rishlar soni chegaradan oshsa)
+ mashhur bo'lsa:   AV1 (o'zini oqlaydigan chegaradan oshsa)

1. TEZ (taxminiy): har bir ko'rish hodisasi navbatga
   -> guruhlab shardlangan hisoblagichga (Reddit darsidagi kabi)
   -> "taxminan 1.2 M ko'rish" — interfeysda

2. SEKIN (tekshirilgan): fon jarayoni hodisalarni tahlil qiladi:
   - bitta IP / qurilmadan g'ayritabiiy ko'p ko'rish
   - avtomatik trafik belgilari
   - "ko'rish" uchun yetarli vaqt tomosha qilinganmi
   -> tekshirilgan son — daromad va reklama hisobi uchun

Oddiy:    [======== bo'lak 6 s ========] -> e'lon -> yuklash
LL-HLS:   [q1][q2][q3][q4][q5][q6]          har qism ~1 s, e'lon darhol
           ^ yaratilishi bilan pleyer oladi

Qo'shimcha: pleyer KEYINGI qismni oldindan so'raydi ("preload hint"),
server javobni qism tayyor bo'lguncha ushlab turadi (uzun so'rov!)

6. ABR: pleyer har 4 soniyada qanday qaror qiladi

5-bo‘limning 6-qadamida biz “pleyer sifatni tanlaydi” dedik. Bu bo‘lim — o‘sha tanlovning ichki mexanizmi. U butun tizimda foydalanuvchi tajribasini eng ko‘p belgilaydigan kod, va u butunlay mijozda ishlaydi.

6.1 Bufer — yagona haqiqiy holat

Pleyerning butun holati bitta sonda: buferda necha soniya video bor. Bu son ikki jarayon o‘rtasidagi poyga natijasi:

Bufer o'sadi:     bo'lak yuklab bo'lingach  +4 s  (bo'lak uzunligi)
Bufer kamayadi:   har real soniyada         -1 s  (video o'ynayapti)

Bo'lakni yuklash vaqti = bo'lak_hajmi / o'tkazuvchanlik
                       = (4 s x bitreyt R) / o'tkazuvchanlik C
                       = 4 x R / C  soniya

Bir bo'lak davomida bufer o'zgarishi:
  +4 - 4 x R / C  =  4 x (1 - R/C)

  R < C  -> bufer O'SADI
  R = C  -> bufer o'zgarmaydi
  R > C  -> bufer KAMAYADI -> nolga yetsa BUFERLASH

Hisobdagi birliklarga diqqat qiling: “10 / 2.67 = 3.75” — bu soniyalar emas, bo‘laklar, va har bir bo‘lak 6.67 soniya yuklanadi, ya’ni ~25 soniya. Bo‘laklar va soniyalarni aralashtirish ABR kodidagi eng keng tarqalgan xatolardan biri: pleyer “buferda 3 bo‘lak bor” ni “3 soniya bor” deb o‘qisa, qarorni juda erta yoki juda kech qabul qiladi.

Asosiy xulosa formulada: bufer faqat R/C nisbatiga bog‘liq. Pleyerning butun vazifasi — C ni to‘g‘ri baholash va R ni undan past tutish. Muammo shundaki, C ni aniq bilib bo‘lmaydi — u faqat o‘tmishda o‘lchangan.

6.2 O‘tkazuvchanlikka asoslangan tanlov

Eng tabiiy yondashuv: oxirgi bir necha bo‘lakning yuklanish tezligini o‘lchash, kelajakni shu bo‘yicha taxmin qilish va xavfsizlik koeffitsienti bilan tanlash.

def choose_by_throughput(history_mbps, ladder_mbps, safety=0.8):
    # oxirgi 5 ta o'lchovning GARMONIK o'rtachasi
    recent = history_mbps[-5:]
    estimate = len(recent) / sum(1 / x for x in recent)
    budget = estimate * safety
    candidates = [r for r in ladder_mbps if r <= budget]
    return max(candidates) if candidates else min(ladder_mbps)

Arifmetik o'rtacha: (10 + 10 + 1) / 3        = 7.0 Mbit/s
Garmonik o'rtacha:  3 / (1/10 + 1/10 + 1/1)  = 2.5 Mbit/s

20/10 + 20/10 + 20/1 = 2 + 2 + 20 = 24 s
Jami 60 Mbit / 24 s = 2.5 Mbit/s   <- garmonik o'rtacha

O‘tkazuvchanlikka asoslangan tanlovning asosiy muammosi — o‘lchov shovqini. Mobil tarmoqda tezlik soniyalar ichida 10 barobar o‘zgarishi mumkin, va bitta bo‘lak davomidagi o‘lchov keyingisini yomon bashorat qiladi. Natija — tebranish: sifat 1080p → 480p → 1080p → 360p almashadi, va foydalanuvchi har almashishda tasvir “sakrashini” ko‘radi.

6.3 Buferga asoslangan tanlov

Muqobil g‘oya (Netflix tadqiqotchilari 2014-yilgi SIGCOMM maqolasida batafsil tahlil qilgan): tarmoqni umuman bashorat qilmaslik. Buning o‘rniga bufer holatining o‘ziga qarab tanlash.

bufer (soniya)     tanlanadigan sifat
  0  - 5           eng past (xavf zonasi — tezroq to'ldirish kerak)
  5  - 25          chiziqli: bufer oshgan sari yuqoriroq
  25+              eng yuqori (zaxira yetarli — tavakkal qilish mumkin)
                   (maksimal bufer 30 s — undan keyin pleyer kutadi)

G‘oyaning mantig‘i: agar bufer o‘sayotgan bo‘lsa, demak R < C — tarmoq tanlangan sifatdan tezroq, va sifatni oshirish mumkin. Agar kamayayotgan bo‘lsa — aksincha. Bufer tarmoqni o‘zi o‘lchaydi, va eng muhimi — u amortizator vazifasini bajaradi: 20 soniyalik bufer 10 soniyalik tezlik tushishini buferlashsiz “yutib yuboradi”, shuning uchun pleyer har bir tushishda sifatni pasaytirishga shoshilmaydi.

To‘rtinchi qatorlar kutilmagan va buni o‘lchov ko‘rsatdi. Amaliyotning 2-darajasidagi simulyatorda (18-bo‘lim) tebranuvchi 3G izida:

Birinchi ikki qator bufer g‘oyasining kuchini ko‘rsatadi: buferlashsiz deyarli ikki barobar yuqori bitreyt — chunki pleyer har tushishda qo‘rqib sifatni tushirmaydi. Lekin almashishlar soni ham deyarli uch barobar. Sabab mexanikada: har bir bo‘lak buferni birdaniga 4 soniyaga oshiradi, va chiziqli xaritada 4 soniya — deyarli bitta pog‘ona. Bufer har bo‘lakda chegara atrofida yuqoriga-pastga sakraydi, sifat ham u bilan birga.

Uchinchi qator yechimni ko‘rsatadi: gisterezis (6.4 Callout) — yuqoriga ko‘tarilish uchun bufer chegaradan qo‘shimcha zaxira bilan oshishi kerak, pastga esa darhol tushiladi. Bitreytning deyarli hammasi saqlanadi, almashishlar ikki barobar kamayadi.

Bu jadval darsning muhim metodologik saboqlaridan biri: g‘oyaning to‘g‘riligi va uning oddiy amalga oshirilishining to‘g‘riligi — turli narsalar. “Bufer shovqinni silliqlaydi” — rost; “oddiy chiziqli bufer xaritasi barqaror” — yolg‘on. Buni faqat simulyatsiya yoki o‘lchov ko‘rsatadi, mulohaza emas.

Shuning uchun amaliy pleyerlar gibrid: boshlanishda o‘tkazuvchanlik, bufer to‘lgach bufer mantiqi, ustidan esa silliqlash va gisterezis (BOLA kabi algoritmlar bu tanlovni matematik optimallashtirish sifatida rasmiylashtiradi).

6.4 Boshlanish vaqti: nega birinchi bo‘lak past sifatda

1.2-bo‘limdagi talab: birinchi kadrgacha p90 < 1 s.

Shuning uchun deyarli barcha pleyerlar past sifatda boshlaydi va bir necha bo‘lakdan keyin ko‘taradi. Foydalanuvchi birinchi 2–4 soniya xira tasvirni ko‘radi — lekin darhol ko‘radi. Tadqiqotlar izchil ravishda ko‘rsatadiki, boshlanish kechikishi tomoshani tashlab ketishga kuchli ta’sir qiladi, dastlabki xiralik esa deyarli ta’sir qilmaydi.

Yana bir hiyla — birinchi bo‘lakni qisqaroq qilish yoki manifestni sahifaning o‘zi bilan birga yuborish (bitta RTT tejash). Har bir 50 ms bu yerda muhim.

7. Uzun dum iqtisodi

Bu bo‘lim darsning yuragi. 5-bo‘limda ikki marta “hamma videoni bir xil qilib bo‘lmaydi” dedik (4- va 10-qadam). Endi nima uchun va qayerda chegara qo‘yish kerakligini raqam bilan ko‘ramiz.

7.1 Ko‘rishlar qanday taqsimlangan

Video ko‘rishlari juda notekis: ozgina video tomosha vaqtining katta qismini oladi, katta ko‘pchilik esa deyarli hech qachon ko‘rilmaydi. Quyidagi jadval illyustratsiya — aniq raqamlar e’lon qilinmagan, lekin taqsimot shakli video platformalar bo‘yicha tadqiqotlarda izchil takrorlanadi.

Jadvalning ikki ustuni deyarli teskari. Videolarning yarmi tomoshaning yarim foizini oladi; videolarning 2% i — tomoshaning 80% ini. Bu Reddit darsidagi Zipf taqsimotining video versiyasi (Reddit, 12-bo‘lim), va u YouTube’dagi deyarli har bir qimmat qarorni belgilaydi.

Qaror shunday shakllanadi: har bir video uchun sarflangan pul uning ko‘rilishiga proporsional bo‘lishi kerak. Oxirgi qatordagi 2% uchun eng yaxshi kodek, eng ko‘p kesh nusxalari, eng tez ombor. Birinchi qatordagi 50% uchun — eng arzon hamma narsa.

7.2 Qachon AV1 o‘zini oqlaydi

Bu hisobdagi har bir kirish — kodlash narxi, yadro narxi, trafik narxi, tejash foizi — taxminiy va ikki-uch barobar xato bo‘lishi mumkin. Lekin xulosa hayratlanarli darajada chidamli: kirishlardan ikkitasini bir yo‘nalishda ikki barobar o‘zgartirsangiz, zararsizlik nuqtasi ~7 500 dan ~120 000 gacha siljiydi — va u baribir 7.1-jadvalning faqat oxirgi ikki qatorida qoladi. Ya’ni AV1 videolarning ~2–10% i uchun foydali, qolganlari uchun esa pul yoqish.

Bu hisobning eng qimmatli tomoni — u qarorni video bo‘yicha qiladi. “AV1 30% yaxshi, demak hammaga AV1” degan umumiy xulosa noto‘g‘ri: AV1 faqat ko‘rishlar soni × tejash > kodlash narxi bo‘lgan joyda yaxshi.

Signal                                  Nima aytadi
  birinchi 1-6 soatdagi ko'rishlar      eng kuchli signal: tezlik
  ko'rishlar tezlanishi (2-soat / 1-soat) o'syaptimi yoki so'nyaptimi
  muallifning oldingi videolari medianasi   "bu kanal odatda qancha"
  tomosha davomiyligi (necha % ko'riladi) sifat signali
  tavsiyalarga tushganmi                tarqalish mexanizmi ishga tushdimi

Yolg'on pozitiv (AV1 da siqildi, lekin mashhur bo'lmadi):
  yo'qotish = kodlash narxi = ~0.33 $ har video daqiqasiga

Yolg'on negativ (siqilmadi, lekin mashhur bo'ldi) — 1 kun kechikish:
  yo'qotish = 1 kunlik tejalmagan trafik
  mashhur video kuniga 100 000 ko'rilgan daqiqa (har video daqiqasi uchun)
  x 0.0000112 $ = ~1.1 $ har video daqiqasiga

7.3 Kesh: har o‘n barobar qo‘shimcha joy — bir necha foiz

Uzun dum keshga ham xuddi shunday ta’sir qiladi. Chekka serverda qancha videoni saqlash kerak?

Bu logarifmik qonun kesh loyihasining asosiy haqiqatini ko‘rsatadi: kesh sig‘imi bilan urish darajasi deyarli chiziqli emas, logarifmik o‘sadi. Birinchi terabaytlar juda foydali, keyingilari — tobora kam. Shuning uchun keshlash qatlamlarga bo‘linadi (8-bo‘lim): kichik, juda yaqin kesh — faqat eng issiq videolar uchun; kattaroq, uzoqroq kesh — iliq videolar uchun; qolgani — asosiy omborga.

jami  = 1/1 + 1/2 + 1/3 + ... + 1/N = H(N)   (N-chi garmonik son)
top K = 1/1 + 1/2 + ... + 1/K       = H(K)

urish darajasi = H(K) / H(N)

urish darajasi ≈ ln(K) / ln(N)

7.4 Vaqt ham taqsimotning bir qismi

Mashhurlik vaqt bo‘yicha o‘zgaradi: yangi klip birinchi haftada millionlab ko‘riladi, bir yildan keyin esa kuniga bir necha marta. Demak “issiq” va “sovuq” — videoning xossasi emas, videoning hozirgi holati.

Bu jadval 5-bo‘limning 13-qadamidagi saqlash qatlamlarining vaqt o‘lchovi. Xulosa: saqlash va kesh siyosati statik emas — har bir video hayoti davomida qatlamlar bo‘ylab pastga siljiydi, va ba’zan (eski video qayta viral bo‘lsa) yuqoriga qaytadi. Shuning uchun original fayl hech qachon o‘chirilmaydi: u har qanday qatlamni qayta qurish imkonini beradi.

Buni bitta videoning hayoti bo‘ylab ko‘ramiz — mashhur bo‘lib ketadigan 10 daqiqalik klipning birinchi ikki kuni:

Timeline’ning mantig‘i: har bir qadamda sarflangan pul o‘sha paytdagi dalilga proporsional. Birinchi daqiqada hech narsa ma’lum emas — eng arzon nusxa. 2 soatdan keyin mashhurlik belgilari bor — o‘rtacha narxli kodek. Bir kundan keyin mashhurlik tasdiqlangan — eng qimmat kodek. Bu — noaniqlik ostida qaror qabul qilishning umumiy naqshi: qaytarib bo‘lmaydigan xarajatni dalil to‘plangunicha kechiktiring.

8. CDN va provayder ichidagi keshlar

4.3-bo‘limdagi hisob: oddiy bulut trafigi narxida kuniga ~11 million dollar. Bu bo‘lim — o‘sha raqamni deyarli nolga tushiradigan arxitektura.

8.1 Kesh ierarxiyasi

Jadvaldagi urish darajalari taxminiy va 7.3-dagi logarifmik qonunga mos keladi: birinchi qatlam kichik, lekin so‘rovlarning katta qismini yopadi. Muhim xulosa — ular ko‘paytiriladi: agar birinchi qatlam 85% ni, ikkinchisi qolganning 60% ini yopsa, ma’lumot markaziga faqat 0.15 × 0.4 = 6% so‘rov yetib boradi. Chiqish trafigining 94% i Google tarmog‘idan tashqarida — provayderning o‘z ichida — beriladi.

8.2 Nega provayder buni o‘z tarmog‘iga qo‘yadi

Savol tabiiy: nega internet provayder o‘z ma’lumot markazida Google’ning serverlarini joylashtiradi, elektr va joy beradi?

Bu hisob uch tomonlama g‘alabani ko‘rsatadi: provayder tranzit xarajatini tejaydi, Google chiqish trafigini deyarli tekin beradi, foydalanuvchi tezroq video oladi. Shuning uchun bu model keng tarqalgan — va Netflix (Open Connect) kabi boshqa yirik video xizmatlar ham xuddi shunday tizimlar qurgan.

Diqqat qiling: bu arxitektura yechimi emas, biznes yechimi. Texnik jihatdan bu oddiy kesh; yangilik — uni boshqa kompaniyaning tarmog‘iga qo‘yish va bundan ikkala tomon ham foyda ko‘rishi. Katta tizimlarda eng katta tejashlar ko‘pincha shunday: kodda emas, kelishuvda.

8.3 Keshni to‘ldirish: kechasi, oldindan

Provayder keshi o‘zi ham trafik iste’mol qiladi — bo‘sh keshni to‘ldirish uchun. Agar u faqat so‘rov kelganda to‘ldirilsa, yangi mashhur video chiqqan paytda hamma keshlar bir vaqtda asosiy omborga murojaat qiladi.

Umumiy dars: bashorat qilinadigan talabni oldindan joylashtiring. Premyera vaqti ma’lum, muallifning auditoriyasi ma’lum — demak klip keshlarga premyeradan oldin, tarmoq bo‘sh paytda yuboriladi. Bu WhatsApp darsidagi “yangi yil kechasini kalendarga yozing” maslahatining CDN versiyasi.

9. Bugungi arxitektura

Diagrammadagi eng muhim ajratish — uchinchi qatlam: boshqaruv tekisligi va ma’lumot tekisligi. Tomosha sahifasi, manifest va URL’lar — kichik, shaxsiy, aqlli; ular Google ma’lumot markazlarida ishlaydi va har bir foydalanuvchi uchun alohida hisoblanadi. Video bo‘laklari esa — katta, umumiy, soqov; ular provayder keshlarida yotadi va hech qachon o‘zgarmaydi. Bu ajratish tufayli 104 Tbit/s trafik Google’ning o‘z serverlari orqali deyarli o‘tmaydi, lekin qaysi bayt qayerdan kelishini baribir Google hal qiladi.

9.1 Bosishdan birinchi kadrgacha

Byudjetdagi eng katta modda — bitta bo‘lakni yuklash, va uni kamaytirishning ikki yo‘li bor: birinchi bo‘lakni kichikroq qilish (past sifat yoki qisqaroq bo‘lak — 6.4) va uni oldindan yuklash. Ikkinchisi ayniqsa kuchli: tavsiyalar ro‘yxati ko‘rsatilganda eng ehtimolli 1–2 videoning birinchi bo‘lagi fonda yuklanadi. Agar foydalanuvchi bosmasa — bir necha yuz kilobayt isrof. Agar bossa — video deyarli bir zumda boshlanadi.

Bu savda — isrof qilingan baytlar evaziga kechikish — faqat bashorat yaxshi bo‘lganda foydali. Ya’ni tavsiya tizimining aniqligi to‘g‘ridan-to‘g‘ri boshlanish vaqtiga ta’sir qiladi — ikki mustaqil ko‘ringan tizim bir-biriga bog‘langan.

10. Ishonchlilik

10.1 Nosozliklar taksonomiyasi

Jadvaldagi naqsh: deyarli har qatorda javob “sifatni kamaytirish”, “xizmatni to‘xtatish” emas. Video platformasining ajoyib xususiyati — tanazzul silliq: 1080p o‘rniga 480p ko‘rsatish ham xizmat. Slack’da xabar yetib bormasa, u yetib bormaydi; bu yerda esa har doim “bir oz yomonroq” variant bor. Bitreyt zinapoyasi — nafaqat turli qurilmalar uchun, balki turli nosozlik darajalari uchun ham zinapoya.

10.2 Degradatsiya tartibi

Tartibning mantig‘i 1.3-bo‘limdagi nisbatdan kelib chiqadi: tomosha yuklashdan muhimroq (430:1), shuning uchun avval yozish yo‘li qurbon qilinadi (1, 2, 6-bosqichlar), o‘qish yo‘li esa faqat sifat bo‘yicha pasaytiriladi (3, 4, 5), lekin hech qachon to‘xtamaydi. Oxirgi bosqichda ham yuklashlar rad etilmaydi — xom fayl saqlanadi. Muallif videoni qayta yuklashga majbur bo‘lmasligi kerak, chunki 4.4-dagi hisob bo‘yicha bu mobil tarmoqda eng og‘riqli operatsiya.

Har bir yangi nusxa uchun:
  1. To'liq dekodlash — xatosiz o'qiladimi?
  2. Davomiylik — originaldan ±0.1 s farqdami?
  3. Ovoz-tasvir sinxronligi — bir nechta nuqtada solishtirish
  4. Sifat metrikasi (masalan, VMAF) — kutilgan oraliqdami?
     (juda past -> kodlash xatosi; juda yuqori -> noto'g'ri pog'ona)
  5. I-kadrlar kutilgan joylardami? (bo'laklash uchun, 2.4)

O'tmasa: nusxa nashr qilinmaydi, originaldan qayta transkodlash.

11. Xavfsizlik va huquq

YouTube’ning xavfsizlik muammolari Slack yoki WhatsApp’nikidan farq qiladi. Bu yerda asosiy tahdid — ma’lumot o‘g‘irlash emas, balki tizimdan suiiste’mol qilib foyda olish: boshqalarning kontentini o‘ziniki qilib yuklash, soxta ko‘rishlar bilan pul ishlash, videolarni o‘g‘irlab boshqa saytda tarqatish.

11.1 Mualliflik huquqi: har bir yuklamani tekshirish

Har bir yuklangan video mualliflar himoyalagan kontent bazasi bilan solishtiriladi (YouTube’da bu tizim Content ID deb ataladi). Mexanizm — barmoq izi: videodan va ovozdan qisqa, siqilgan “imzolar” olinadi va indeksda qidiriladi.

Muhim nozik joy — mos kelish natijasi har doim ikkilik emas. Qisqa parcha (sharh uchun iqtibos), fonda eshitilgan musiqa, qayta yozilgan qo‘shiq — bularning hammasi turli siyosatlarni talab qiladi, va ular texnik emas, huquqiy va mahsulot qarorlari. Tizimning texnik qismi faqat qayerda, qancha va qanchalik ishonch bilan mos kelganini aytadi; nima qilish (bloklash, daromadni muallifga berish, faqat kuzatish) — himoyalangan kontent egasining sozlamasi.

11.2 Imzolangan URL’lar: bo‘laklarni o‘g‘irlashga qarshi

Bo‘laklar oddiy HTTP fayllar (2.4) — demak har kim ularni to‘g‘ridan-to‘g‘ri yuklab olib, o‘z saytida ko‘rsatishi mumkin, trafikni esa YouTube to‘laydi. Himoya — imzolangan va muddatli URL:

https://kesh-42.provayder.example/videoplayback
    ?id=abc123&itag=137          (qaysi video, qaysi pog'ona)
    &expire=1700003600           (1 soatdan keyin yaroqsiz)
    &ip=203.0.113.7              (faqat shu IP uchun)
    &sig=Hmac(maxfiy_kalit, id|itag|expire|ip)

Kesh serveri har so'rovda imzoni tekshiradi:
  muddati o'tgan / boshqa IP / imzo noto'g'ri -> 403

Imzoni tekshirish arzon (bitta HMAC) va uni kesh serverining o‘zi bajaradi — markaziy xizmatga murojaat kerak emas. Bu WhatsApp darsidagi “imzolangan qurilma ro‘yxati” va Slack darsidagi “mahalliy token tekshiruvi” bilan bir xil tamoyil: ishonchni oldindan hisoblangan imzo bilan chekkaga olib chiqish.

Chegara: bu himoya emas, qiyinlashtirish. Brauzerda o‘ynaydigan video brauzerga yetib keladi va uni yozib olish mumkin. Pullik kontent uchun qo‘shimcha qatlam — DRM (shifrlangan bo‘laklar, kalit maxsus modulda) — lekin u ham faqat nusxalashni qimmatlashtiradi, imkonsiz qilmaydi.

12. Iqtisod: bir soat tomosha qancha turadi

Oldingi darslarda xarajatning asosiy moddasi aniq edi: Reddit’da chiqish trafigi (91%), Slack’da gateway fleti (47%), WhatsApp’da media (80%). YouTube’da esa manzara boshqacha, chunki eng katta modda — trafik — 8-bo‘limdagi provayder keshlari tufayli tubdan arzonlashtirilgan.

Bu raqamlar faqat tuzilmani ko‘rsatish uchun — haqiqiy narxlar, saqlash hajmi va samarali trafik narxi ma’lum emas va ancha farq qilishi mumkin. Lekin tuzilmadan chiqadigan xulosalar ishonchli.

Jadvalning oxirgi ustuni — eng muhimi. Yetkazish va transkodlash oqim xarajatlari: ular joriy faollikka bog‘liq va optimallashtirish bilan kamayadi. Saqlash esa zaxira xarajati: har yili yuklangan video kelgusi barcha yillarda saqlanadi. 20 yildan keyin saqlash — 20 yillik yuklamalar yig‘indisi.

Bundan uchta amaliy qaror chiqadi:

Birinchi: saqlash samaradorligi uzoq muddatda eng muhim optimallashtirish. Replikatsiyadan erasure coding’ga o‘tish (quyidagi Deep), sovuq qatlam, kam ko‘riladigan nusxalarni o‘chirish — bularning har biri butun kelajakdagi xarajatni kamaytiradi.

Ikkinchi: transkodlash arzonlashgani uchun endi uni ko‘proq qilish mumkin. Apparat tufayli 2% ga tushgan modda — bu yangi imkoniyat: ko‘proq videoni VP9/AV1 da siqish (yetkazishni kamaytiradi) yoki kerak bo‘lganda nusxalarni qayta yaratish (saqlashni kamaytiradi). Ya’ni arzonlashgan resurs qimmat resurslarni almashtirish uchun ishlatiladi.

Uchinchi: yetkazishni sifat standarti orqali boshqarish. Mobil qurilmalarda standart sifatni bir pog‘ona pasaytirish (masalan, “trafikni tejash” rejimi) yetkazish xarajatini sezilarli kamaytiradi va ko‘pchilik foydalanuvchi farqni sezmaydi — kichik ekranda 720p va 1080p deyarli bir xil.

Reed-Solomon (6, 3) misoli:
  fayl -> 6 ta ma'lumot bo'lagi + 3 ta paritet bo'lagi = 9 bo'lak
  9 ta turli mashinada
  istalgan 6 tasi -> fayl tiklanadi
  -> 3 ta mashina yiqilishiga chidaydi (3 nusxadan YAXSHIROQ: u 2 taga chidaydi)

Saqlash: 9 / 6 = 1.5x   (3 nusxada 3x)

20 EB ma'lumot uchun:
  3 nusxa:        60 EB fizik disk
  RS(6,3):        30 EB fizik disk
  Tejash:         30 EB — yuqoridagi narx bilan oyiga ~60 M $

13. Sig‘im rejalashtirish

Jadvaldagi signallar ketma-ketligiga qarang: har bir bosqichda cheklovchi resurs almashadi. A–B da — foydalanuvchi tajribasi (buferlash, nashr vaqti). C da — trafik narxi. D da — hisoblash narxi. E da — saqlash. Bu 12-bo‘limdagi xarajat tuzilmasining vaqt bo‘yicha ko‘rinishi: siz bitta xarajatni hal qilganingizda, keyingisi eng kattasiga aylanadi.

Bu naqsh deyarli barcha o‘sayotgan tizimlarda takrorlanadi va undan muhim amaliy xulosa chiqadi: xarajat tuzilmasini har chorakda qayta hisoblang. O‘tgan yilgi eng katta modda bugun kichik bo‘lishi mumkin (transkodlash apparat bilan 2% ga tushdi), va optimallashtirish kuchi eskirgan muammoga sarflanishi mumkin.

13.1 Viral video: sovuq ob’ektga bir vaqtda million so‘rov

Bu mexanizmning nomi — so‘rovlarni birlashtirish (request coalescing, ba’zan “collapsed forwarding”). U Slack darsidagi qayta ulanish bo‘roni va WhatsApp darsidagi yangi yil kechasi bilan bir oilada: sinxron hodisa bitta resursni bir vaqtda uradi. Farq — bu yerda yechim jitter emas (tomoshabinni kuttirib bo‘lmaydi), balki ierarxik birlashtirish: har bir qatlam o‘zidan yuqoriga bitta so‘rov yuboradi.

in_flight: dict[str, Future] = {}      # kalit -> yuklanayotgan javob

async def get(key):
    if (hit := cache.get(key)) is not None:
        return hit                       # oddiy urish
    if key in in_flight:
        return await in_flight[key]      # boshqasi allaqachon yuklayapti — KUTAMIZ
    fut = loop.create_future()
    in_flight[key] = fut
    try:
        data = await upstream.fetch(key) # yuqoriga FAQAT BITTA so'rov
        cache.put(key, data)
        fut.set_result(data)
        return data
    except Exception as e:
        fut.set_exception(e)             # kutayotganlarning hammasi xato oladi
        raise
    finally:
        del in_flight[key]

13.2 Yirik jonli efir: o‘rtacha kundan katta bitta hodisa

Bu hisob jonli efir uchun sig‘im rejalashtirishning asosiy qoidasini ko‘rsatadi: muammo markazda emas, chekkada. Asosiy serverdan chiqish ~1.5 Gbit/s — bitta server uchun ham oddiy. Lekin 150 Tbit/s ni provayder keshlari va ularning abonentlarga tarmog‘i ko‘tarishi kerak, va bu ko‘pincha provayderning sig‘imi. Shuning uchun eng yirik jonli hodisalar provayderlar bilan oldindan kelishiladi — WhatsApp darsidagi “sinxron hodisalarni kalendarga yozing” maslahati bu yerda provayderlar kalendari bilan to‘ldiriladi.

14. Kuzatuv: tajriba sifati (QoE)

Video platformasida server metrikalari (CPU, xatolik darajasi, kechikish) deyarli hech narsa demaydi. Server bo‘lakni muvaffaqiyatli yubordi — lekin u foydalanuvchiga 8 soniyada yetdi va video 4 soniya to‘xtab turdi. Haqiqiy metrikalar pleyerdan keladi.

14.1 Asosiy QoE metrikalari

Jadvalning birinchi ikki qatori ko‘pincha e’tibordan chetda qoladi, chunki ular muvaffaqiyatsiz tomoshalar haqida — va muvaffaqiyatsiz tomosha boshqa metrikalarda umuman ko‘rinmaydi. Agar sekin tarmoqdagi foydalanuvchilar kutishga chidamay chiqib ketsa, ularning buferlash ulushi hech qachon hisoblanmaydi — va o‘rtacha buferlash ulushi yaxshilangandek ko‘rinadi. Bu — tanlov og‘ishi (survivorship bias) ning klassik ko‘rinishi, va uni faqat EBVS va VSF ni alohida kuzatish tuzatadi.

14.2 Bo‘lish o‘lchovlari: qayerda buzilgan?

Global o‘rtacha QoE deyarli hech qachon muammoni ko‘rsatmaydi. Muammolar mahalliy: bitta provayder, bitta kesh, bitta qurilma modeli, bitta kodek. Shuning uchun har bir metrika kamida quyidagilar bo‘yicha bo‘linadi:

provayder (ASN)  x  mamlakat/shahar  x  kesh serveri  x
qurilma turi     x  pleyer versiyasi  x  kodek        x  jonli / yozilgan

Xulosa: global metrika katta nosozlikni ko‘rsatadi, mahalliy nosozlikni esa hech qachon. Video platformasidagi nosozliklarning ko‘pchiligi mahalliy, shuning uchun ogohlantirishlar bo‘lingan metrikalar ustiga quriladi — har bir kesh, har bir provayder uchun alohida bazaviy daraja va undan og‘ish.

O'TGAN OY                         BU OY
  Mobil: 70% tomosha, 1.5 Mbit/s    Mobil: 50% tomosha, 1.4 Mbit/s  (pasaydi)
  TV:    30% tomosha, 8.0 Mbit/s    TV:    50% tomosha, 7.5 Mbit/s  (pasaydi)

  O'rtacha: 0.7x1.5 + 0.3x8.0       O'rtacha: 0.5x1.4 + 0.5x7.5
          = 1.05 + 2.40                     = 0.70 + 3.75
          = 3.45 Mbit/s                     = 4.45 Mbit/s   (OSHDI!)

15. Antinaqshlar

Birinchi qator jozibali, chunki u “to‘g‘ri ish qilish” ga o‘xshaydi: agar AV1 30% yaxshi bo‘lsa, nega har bir videoga bermaslik? Javob 7.2-bo‘limda: AV1 videoning har bir daqiqasi uchun ~0.33 dollar turadi va faqat o‘n minglab ko‘rishdan keyin o‘zini oqlaydi. Yuklanganlarning yarmi 100 martadan kam ko‘riladi. Bu antinaqshning chuqur sababi — o‘rtacha bo‘yicha fikrlash: “o‘rtacha video 430 marta ko‘riladi” rost, lekin o‘rtacha video mavjud emas.

Ikkinchi qator jozibali, chunki birinchi taassurot muhim, va xira tasvir sifatsiz mahsulot taassurotini beradi. Lekin 6.4-dagi hisob ko‘rsatadiki, foydalanuvchi uchun kutish xiralikdan ancha qimmat: kutishga chidamaganlar chiqib ketadi (EBVS), xira tasvirni ko‘rganlar esa 4 soniyadan keyin tiniq tasvirni oladi.

Uchinchi qator eng texnik va eng yashirin. Har bir nusxa uchun kodek o‘zi optimal I-kadr joylarini tanlasa, siqish bir necha foiz yaxshilanadi — va bu test paytida ko‘rinadigan yagona natija. ABR almashishidagi buzilish esa faqat tarmoq o‘zgarganda va faqat sifat almashganda ko‘rinadi — ya’ni laboratoriyada hech qachon.

To‘rtinchi qator jozibali, chunki kichik miqyosda u eng oddiy arxitektura: bitta server hamma narsani biladi. Lekin 8-bo‘limning butun g‘oyasi — baytlar hech qachon ilova serveridan o‘tmasligi — shu yerda buziladi. To‘g‘ri naqsh 9-bo‘limda: ilova serveri faqat manifest va imzolangan URL beradi (boshqaruv tekisligi), baytlar esa keshdan to‘g‘ridan-to‘g‘ri (ma’lumot tekisligi).

Beshinchi qator — eng qaytarib bo‘lmaydigan xato. Originalni o‘chirish bugun saqlashni tejaydi va bir necha yil hech qanday muammo tug‘dirmaydi. Keyin yangi kodek chiqadi (VP9 → AV1), va siz uni faqat allaqachon siqilgan nusxadan kodlay olasiz — ya’ni ikki marta siqilgan, sifati yomonlashgan videodan. Yoki kodlash xatosi aniqlanadi (10-bo‘lim Deep) va tuzatish uchun manba yo‘q.

16. Trade-off‘lar

Jadvalni juftliklar bo‘yicha o‘qing. Birinchi va oltinchi qator — vaqt va sifat savdosi: tezroq javob evaziga vaqtincha yomonroq natija. Ikkinchi va uchinchi — saqlash/hisoblash va trafik savdosi: yozish yo‘lida ko‘proq ish, o‘qish yo‘lida kamroq bayt. To‘rtinchi va beshinchi — hozirgi va kelajakdagi moslashuvchanlik: bugun ko‘proq to‘lab, ertaga ko‘proq imkoniyat saqlash.

Uchala juftlikning umumiy mazmuni bitta: video tizimi — bu yozish bir marta, o‘qish ming marta bo‘lgan tizim, va deyarli har qanday qaror “yozishni qimmatlashtirib, o‘qishni arzonlashtirish” tomon og‘ishi kerak — lekin faqat haqiqatan ko‘p o‘qiladigan ob’ektlar uchun.

17. Intervyu savollari

17.1 Mexanizm

17.2 Miqyos

17.3 Tajriba

18. Amaliyot

To‘rt daraja. Birinchi va ikkinchi daraja uchun kod docs/amaliyot/youtube/ da: ladder.py to‘liq ishlaydi, sim.py — tayyor ABR simulyatori, abr.py esa TODO bilan skelet.

19. Lug‘at

20. Raqamlar manbasi

Yetkazilgan va yuklangan o‘rtacha bitreytlar, ko‘rishlar taqsimoti (7.1), kodlash narxlari (yadro-soniya), yadro, trafik va saqlash narxlari, kesh urish darajalari, provayder tranzit narxi, saqlash hajmi — illyustratsiya uchun taxminiy raqamlar. Ular tartib jihatidan ishonchli, lekin aniq emas; xulosalar esa (7.4-dagi Check) ularning ikki barobarlik xatosiga chidamli bo‘lishi uchun tanlangan.

21. Manbalar

• Apple, HTTP Live Streaming (RFC 8216)
• ISO/IEC 23009-1, MPEG-DASH
• Te-Yuan Huang va boshq. (2014), “A Buffer-Based Approach to Rate Adaptation: Evidence from a Large Video Streaming Service”, SIGCOMM
• Xiaoqi Yin va boshq. (2015), “A Control-Theoretic Approach for Dynamic Adaptive Video Streaming over HTTP”, SIGCOMM
• Kevin Spiteri va boshq. (2016), “BOLA: Near-Optimal Bitrate Adaptation for Online Videos”
• Florin Dobrian va boshq. (2011), “Understanding the Impact of Video Quality on User Engagement”, SIGCOMM
• Netflix texnik blogi (2015), “Per-Title Encode Optimization”
• Parthasarathy Ranganathan va boshq. (2021), “Warehouse-Scale Video Acceleration: Co-design and Deployment in the Wild”, ASPLOS
• Paul Covington, Jay Adams, Emre Sargin (2016), “Deep Neural Networks for YouTube Recommendations”, RecSys
• Alliance for Open Media — AV1 spetsifikatsiyasi