Adding video to a product looks like a storage problem and is actually a delivery problem. A single high-resolution file served to everyone will buffer on the connections a large share of Indian users have, and will consume data that many of them are counting.
Adaptive bitrate streaming is the baseline, not an optimisation. Encoding several renditions and letting the player switch between them as conditions change is what makes video usable on a fluctuating mobile connection. HLS is the widely supported format; DASH is the standards-based alternative, and most delivery platforms produce both.
The ladder of renditions deserves thought. Ladders designed for Western markets often start too high. Including a genuinely low rendition — small resolution, low bitrate — feels like a compromise until you look at how many sessions actually use it.
Codec choice trades encoding cost against delivery cost. H.264 plays everywhere and produces larger files. H.265 and AV1 compress substantially better and have narrower device support, particularly on the older Android hardware still common in India. Serving H.264 as a fallback alongside a modern codec captures most of the saving without excluding anyone.
Do not serve video from your application server. Egress from a compute instance is expensive and the instance was not designed for it. Object storage behind a CDN, or a dedicated video platform, is both cheaper and better. Cache hit ratio at the CDN is the number that determines the bill.
Finally, consider download. For education and training content in particular, allowing users to download over wifi and watch offline serves the actual usage pattern far better than insisting on streaming, and it costs you less bandwidth in aggregate.
