🎬
Media & Streaming

Video Streaming Platform

YouTube/Netflix Ka Core
💡 Video streaming EK SINEMA CHAIN hai. Film ek baar banti hai (upload + encode), par use har sheher ke theatre tak pahunchana padta hai (CDN) — aur har darshak ki internet speed ke hisaab se alag print chahiye (adaptive bitrate).

Do bilkul alag pipelines hain. UPLOAD pipeline: video chunked upload se blob storage mein jaata hai, phir ek async TRANSCODING job use kai resolutions (240p se 4K) aur formats mein badalta hai, chhote segments mein todkar. Ye minutes-to-hours ka kaam hai, isliye queue-driven aur fully async.

PLAYBACK pipeline: player manifest file (HLS/DASH) maangta hai jisme saare quality levels ke segment URLs hote hain. Segments CDN se aate hain — origin server 99% traffic kabhi dekhta hi nahi. ADAPTIVE BITRATE mein player khud network speed dekhkar quality badalta hai, server nahi.

// Upload (async, minutes)
Upload → Blob storage → Kafka → Transcoding workers
       → segments (240p/480p/720p/1080p/4K, 4-10 sec each)
       → CDN par push + manifest generate

// Playback (real-time)
Player → manifest.m3u8 (saare quality levels)
       → CDN se segments (network speed ke hisaab se quality switch)
🎬
Video streaming EK SINEMA CHAIN hai. Film ek baar banti hai (upload + encode), par use har sheher ke theatre tak pahunchana padta hai (CDN) — aur har darshak ki internet speed ke hisaab se alag print chahiye (adaptive bitrate).
1 / 2
⚡ Quick Recap
  • Upload/transcode async pipeline, playback real-time CDN path
  • Video segments mein tuta hota hai, har quality ke apne segments
  • Adaptive bitrate ka faisla player karta hai, server nahi
Is page mein (2 subtopics)

Transcoding CPU-heavy aur slow hai — ek ghante ka video kai minute leta hai. Isliye video ko chunks mein todkar PARALLEL transcode kiya jaata hai: 100 chunks, 100 workers, kaam 100 guna tez.

Pipeline DAG hoti hai: validate → split → parallel transcode (har resolution ke liye) → thumbnail generation → subtitle extraction → package (HLS/DASH) → CDN push. Har step retry-able hona chahiye kyunki koi bhi worker fail ho sakta hai.

Upload → validate → split into chunks
                      ↓ (parallel workers)
       ┌──────────────┼──────────────┐
     240p           720p           1080p
       └──────────────┼──────────────┘
                      ↓
              package (HLS manifest) → CDN

On-demand mein poora video pehle se hai, transcode ke liye time hai. LIVE mein stream aa raha hai aur latency budget seconds ka hai — isliye transcoding real-time honi chahiye aur segment size chhota (2-4 second).

Trade-off saaf hai: chhote segments = kam latency par zyada overhead aur requests. Ultra-low latency ke liye WebRTC use hota hai (sub-second) par wo CDN se scale nahi karta. Ye batana ki "live aur VOD alag systems hain" important hai.

💡Tip: Agar interviewer "live bhi support karo" bole to scope clarify karo — normal live (5-30s latency, HLS se) ya interactive live (sub-second, WebRTC se)? Dono ke design bilkul alag hain.