Video Library Storage, Adaptive Streaming and a Visual Search Request

Why the current design fails, concretely:

• Backups and logs. A 40 TB BLOB footprint means the database backup stream carries 40 TB every night, and every insert or update of a video writes its full bytes through the transaction log. That explains the nine-hour backup and the oversized log.
• No range requests. Video playback and scrubbing depend on HTTP byte-range requests. Streaming a BLOB means every seek re-queries the row and pushes bytes through the application server, which is why scrubbing restarts and why startup takes 20 seconds.
• No CDN. Content served from a database cannot be cached at an edge; every viewer consumes application and database capacity.
• No cache headers, no partial-content semantics, no connection reuse - all the mechanics that make video cheap to deliver are unavailable.

Proposed architecture:

1. Object storage (S3-compatible, with lifecycle rules) for all renditions, thumbnails, captions and mezzanine files. It supports range requests natively, scales horizontally, and is cheap relative to block storage.
2. CDN in front of object storage, with signed URLs or tokens for entitlement, and long cache TTLs on immutable, content-hashed filenames.
3. Relational database for metadata only - asset ID, title, instructor, duration, tags, transcript, ownership, rendition manifest, and a pointer (bucket + key) to the media. Rows stay small, so transactions and backups are fast; a 200,000-row table is trivial.
4. Search index (Elasticsearch/OpenSearch or PostgreSQL full-text) for tags, titles and transcripts, kept in sync from the metadata store.
5. A migration plan that extracts the BLOBs in batches, verifies checksums, and only then drops the columns - never the reverse order.

Separating the catalogue from the bytes is the single decision that fixes backups, startup time and scrubbing at once.

moov placement first. In a plain MP4, the moov box holds the sample tables that tell the player where every frame lives. If it is written at the end of the file, the player must fetch the tail before it can decode anything - hence the 20-second start, or a second full request. Fixes: rewrite with faststart (moov at the front) for progressive download, or better for this portal, package as fragmented MP4/CMAF, where the initialisation segment carries the moov and each media segment is independently addressable.

Protocol. Publish HLS and DASH from the same CMAF segments where possible, so storage and CDN cache are shared. HLS remains necessary for Apple devices; DASH covers the rest; a single fMP4 set avoids duplicating the library.

Segment duration. Short segments (2 s) let the player switch bitrate quickly and reduce latency, but each segment starts with a keyframe, so shorter segments mean more I-frames and lower compression efficiency, plus more HTTP requests and more player overhead. Long segments (10 s) compress better but adapt slowly and start later. For VOD on mobile, 4 seconds is the usual compromise: roughly 6–8 s of buffered media on the first two segments, giving a sub-two-second start on a reasonable connection.

Ladder. Build 5–6 rungs with roughly 1.5× steps, from 240p at ~300 kbps up to 1080p at ~5 Mbps, all with aligned keyframes and identical segment boundaries so switching is seamless. Cap the top rung for mobile delivery. Generate per-title ladders for the high-traffic courses rather than one ladder for all 200,000 assets - a static slide presentation and a talking-head interview need very different bitrates.

Also: set #EXT-X-START or an equivalent start point, serve the init segment with a long TTL, and pre-warm the CDN for scheduled releases.

Short answer: descriptors help, but they do not understand rain or cars.

MPEG-7 visual descriptors are low-level statistics over pixels:

• Scalable Color / Color Histogram - distribution of colours, invariant to position and scale.
• Color Layout - a small grid of dominant colours, which does preserve coarse spatial arrangement.
• Color Structure - colour distribution plus local structure.
• Edge Histogram, Texture Browsing, Homogeneous Texture - coarse edge and texture statistics.

A global colour histogram would match every frame containing a lot of red - a red umbrella, a red jacket, a sunset - because it discards layout entirely. Colour Layout or Colour Structure reduces those false positives by requiring the red mass to sit in the lower central region, but neither can distinguish a car from a van, and neither has any notion of rain. Similarity is also fragile under colour grading, night scenes and heavy rain haze.

Realistic design for one quarter:

1. Manual and text metadata first. Tags, transcript and title search will satisfy most queries and are cheap. Ensure the 20 free-text tags are curated and searchable.
2. Keyframe extraction and indexing. Detect shot boundaries, extract representative keyframes, store them with timestamps, and compute MPEG-7 Colour Layout plus Colour Structure as a fast pre-filter. This is well-specified and implementable in weeks.
3. Learned embeddings for semantics. Run an open-vocabulary image–text model over the keyframes (or sampled frames, one per second) to produce vectors, store them in a vector index, and query with the text string. This is what actually maps "red car" and "rain" to visual content. Budget for GPU inference over 200,000 assets and for re-indexing when the model changes.
4. Human-in-the-loop. Return timestamped candidate clips with a confidence indicator and let users confirm; log the clicks as training signal.
5. Be explicit with the product owner that a one-quarter delivery is a similarity demo plus text search, not guaranteed semantic retrieval.