Video upload & adaptive streaming

The client uploads in resumable chunks directly to object storage using pre-signed URLs. An event queues transcoding: workers split the file, encode each chunk into several resolutions, and package HLS/DASH segments with a manifest. Metadata and thumbnails go to a database. Playback fetches the manifest and segments from a CDN, and the player adapts the bitrate to the network.

The file lands in object storage, an event triggers a transcoding pipeline that splits it into segments and encodes several resolutions and bitrates in parallel, generates thumbnails and captions, packages HLS or DASH manifests, runs content checks, then marks the video ready and publishes it to the CDN-backed playback path.

Split the source into chunks (for example a few seconds each), transcode chunks in parallel on a worker fleet (often spot instances or GPUs), then stitch outputs. A job orchestrator tracks each chunk, retries failures, and priorities let short or popular uploads finish first.

Segments and manifests are cached on CDNs close to viewers, with long cache lifetimes because segments never change. The origin is object storage with an origin shield to reduce load. Popular videos are pre-warmed to edge caches; rare videos are fetched from origin on demand.

The video is encoded at several quality levels and cut into segments of a few seconds. A manifest lists them. The player measures bandwidth and buffer level and picks the quality for each next segment, dropping to a lower one before the buffer runs dry.

Both split video into small segments listed in a manifest at several bitrates. HLS (from Apple) uses .m3u8 playlists and is required on iOS Safari; DASH is an open standard with .mpd manifests. CMAF lets one set of fMP4 segments serve both, halving storage.

Store metadata (title, owner, status, renditions) in a database, cache it heavily, and count views asynchronously through an event stream aggregated into counters, so hot videos do not lock rows.

Ingest RTMP or SRT streams at the nearest point, transcode in real time into short segments (or low-latency HLS parts), push them to the CDN continuously, and keep latency low with small segments. Recording for replay happens in parallel.

Use DRM (Widevine, FairPlay, PlayReady) with encrypted segments and a licence server that checks entitlements, plus signed, short-lived CDN URLs or cookies so links cannot be shared.

Use efficient codecs (AV1, HEVC) for popular videos, fewer renditions for rarely watched ones, per-title encoding that picks bitrates by content complexity, tiered storage for old videos, and high CDN cache hit rates.

Choosing the bitrate ladder for each video based on its complexity: a static lecture needs far fewer bits than a sports match for the same quality, so storage and bandwidth drop without visible loss.

It measures download throughput and buffer level, then requests the highest bitrate it can sustain, switching between renditions at segment boundaries. Good players avoid frequent switches and start at a conservative bitrate for fast startup.

Count a view only after a minimum watch time, deduplicate by viewer and video within a window, filter bots by behaviour and known data-centre IPs, and aggregate counts asynchronously from playback events. Show approximate counts quickly and correct them after fraud analysis.

Have the player send its position every few seconds and on pause to a progress service keyed by user and video, store the latest value in a fast store, and on open fetch the position and seek there. Ignore positions in the last few seconds so finished videos start fresh.

Split the file into parts and upload each separately (S3 multipart or the tus protocol), recording which parts succeeded. After a drop, the client asks which parts exist and uploads only the missing ones, then completes the upload.

Extract frames at intervals during transcoding, pick candidates by quality or let creators choose, and create sprite sheets for scrubbing previews in the player.

Generate captions with speech recognition or accept uploaded files, store them as WebVTT tracks referenced in the manifest, and let viewers choose languages; machine translation can add more.

Fingerprint audio and video and compare against a reference database (like Content ID), run classifiers for policy violations, and queue uncertain cases for human review before or after publishing.

Players send telemetry: startup time, rebuffering ratio, bitrate switches, errors and watch time. Aggregate it by CDN, region, device and ISP to find and fix problems.

Viewing events feed a recommendation system that ranks candidates by predicted watch time; the platform pre-warms caches for videos likely to be recommended widely.

Chunk-level jobs retry independently; the orchestrator resumes from completed chunks, and after repeated failure marks the upload failed and notifies the creator, keeping the original for another attempt.

Multiply uploaded hours per day by the sum of rendition bitrates: 500 hours a minute of uploads at an average of 10 Mbps across renditions is roughly 2–3 PB per day before replication, which is why codec efficiency matters.

Most load is absorbed by the CDN, so pre-warm popular segments, enable origin shield, lower manifest cache times only if needed, and scale the metadata and view-count services, which still see a request per viewer.

Store chapters as a list of start times and titles with the video metadata, parse them from creator descriptions or generate them automatically from transcripts, and expose them in the player as markers and as deep links with a time parameter.

Let the app download an encrypted rendition at a chosen quality, protect it with DRM licences that allow offline playback for a limited period, limit the number of devices, and renew or revoke licences when the user reconnects.

Sample frames and audio continuously into classifiers, combine with user reports, show warnings or cut the stream when confidence is high, route uncertain cases to human moderators, and keep a short buffer so actions happen before most viewers see the content.

It is a mid-tier cache between edge locations and the origin, so many edges missing the same segment cause one origin fetch instead of hundreds.

Use multipart uploads with resumable chunks (S3 multipart or tus), verify checksums, and let processing start as soon as the upload completes.

An extension that publishes partial segments and preload hints so live latency drops from tens of seconds to a few seconds, at the cost of more requests.

Mark the video deleted, stop serving it, purge CDN caches, and delete renditions and originals from storage asynchronously according to retention rules.

Upload success rate, transcoding queue time, time to publish, playback start time, rebuffering ratio, CDN hit rate and cost per streamed hour.

Keep the source or a high-quality mezzanine plus a few common renditions, delete rarely used ones, move files to colder storage classes, and re-transcode on demand if a missing rendition is requested.

1. AProgressive download
2. BHLS / DASH adaptive bitrate segmentsCorrect answer
3. CA larger buffer only
4. DLossless encoding

Why: Segments at several bitrates let the player pick a different quality for each next segment.

1. ASegments at several bitrates listed in a manifestCorrect answer
2. BOne big MP4 file
3. CWebSockets
4. DA larger buffer only

Why: This is adaptive bitrate streaming.

1. ASplitting into chunks transcoded in parallelCorrect answer
2. BOne server per video
3. CTranscoding in the browser
4. DSkipping renditions

Why: Then outputs are stitched.

1. AThe transcoding workers
2. BThe metadata database
3. CThe upload service
4. DCDN edge cachesCorrect answer

Why: Segments never change and cache well.

1. AThey transcode automatically
2. BThey remove the need for a CDN
3. CThey compress the video
4. DClients upload directly to storage without passing through app serversCorrect answer

Why: A pre-signed URL grants time-limited permission to write one object straight to the bucket.

1. AHLSCorrect answer
2. BDASH only
3. CRTMP
4. DFLV

Why: Apple's streaming protocol.

1. ASmaller manifests only
2. BOne segment set for both HLS and DASHCorrect answer
3. CLive chat
4. DDRM removal

Why: Halves segment storage.

1. ABigger thumbnails
2. BDRM with a licence serverCorrect answer
3. CLonger URLs
4. DLower bitrates

Why: Widevine, FairPlay, PlayReady.

1. ACreator age
2. BFile name
3. CEach video's content complexityCorrect answer
4. DUpload time

Why: Simple content needs fewer bits.

1. AClient-side only
2. BAggregated asynchronously from eventsCorrect answer
3. CLocking a row per view
4. DCounting on every page load

Why: Hot videos would block rows.

1. ASMTP
2. BFTP
3. CIMAP
4. DRTMP or SRTCorrect answer

Why: Then transcoded into segments.

1. AA minimum watch timeCorrect answer
2. BThe page loads
3. CThe thumbnail renders
4. DThe user signs up

Why: Brief plays and bots would inflate counts.

1. AIn the manifest
2. BPer user and video in a fast storeCorrect answer
3. CIn the video file
4. DIn the CDN cache

Why: They change often and are read on every open.

1. APandoc
2. BWebpack
3. CImageMagick
4. DFFmpegCorrect answer

Why: FFmpeg is the standard open-source encoder behind most transcoding pipelines.

1. AThumbnail count
2. BRebuffering ratioCorrect answer
3. CNumber of renditions
4. DManifest size

Why: Stalls drive viewers away.

1. ACaption accuracy
2. BDuplicate origin fetches from many edgesCorrect answer
3. CVideo quality
4. DUpload speed

Why: It is a mid-tier cache before the origin.

1. APNG
2. BCSV
3. CZIP
4. DWebVTTCorrect answer

Why: Referenced in the manifest.

1. AAudio and video fingerprintingCorrect answer
2. BFile names
3. CUpload times
4. DCreator emails

Why: Compared against references.

1. ACaptions
2. BScrubbing previews in the playerCorrect answer
3. CDRM
4. DFaster uploads

Why: Frames combined into one image.

1. AMJPEG
2. BGIF
3. CAV1Correct answer
4. DMPEG-2

Why: Worth the encoding cost at scale.

1. APublish anyway
2. BRetry that chunk onlyCorrect answer
3. CRestart the whole video
4. DDelete the upload

Why: Only the failed chunk is retried.

1. ASharing links to protected contentCorrect answer
2. BCaching
3. CTranscoding
4. DThumbnails

Why: Signed URLs expire quickly.

1. AThe metadata database
2. BThe upload service
3. CThe CDNCorrect answer
4. DThe transcoding cluster

Why: Segments are cacheable and identical for every viewer.

1. APlain MP4 files
2. BSigned cookies only
3. CBigger bitrates
4. DDRM licences with offline expiryCorrect answer

Why: Licences control how long and where content plays.

1. ASeparate video files
2. BCDN headers
3. CThumbnail names
4. DStart times and titles with the metadataCorrect answer

Why: The player reads them to show markers.

1. AMore renditions in hot storage
2. BDeleting the source
3. CServing from the origin only
4. DFewer renditions in colder storageCorrect answer

Why: Missing renditions can be regenerated on demand.

1. APartial segments and preload hintsCorrect answer
2. BBigger segments
3. CRemoving the CDN
4. DUsing FTP

Why: Latency drops to seconds.

1. AEmail attachments
2. BWebSocket frames
3. CMultipart or tus uploadsCorrect answer
4. DSingle PUT only

Why: Failed chunks are retried individually.

1. ARecommended
2. BPurged from CDN cachesCorrect answer
3. CRe-transcoded
4. DShared

Why: Otherwise edges keep serving them.

1. ATo save storage
2. BFor DRM
3. CFor captions
4. DFor a fast start before measuring bandwidthCorrect answer

Why: Then step up quality.

1. A.mp4
2. B.srt
3. C.m3u8Correct answer
4. D.mpd

Why: DASH manifests use .mpd instead.

1. ASkip transcoding
2. BRemove the CDN
3. CAct before most viewers see harmful contentCorrect answer
4. DIncrease bitrate

Why: The buffer buys time for automated checks.