For video specifically I think HLS is the simplest standard, it doesn't produce a nice .mp4 link or use a fancy merktle tree but it would support multiple resolutions and many open source players support it

For live streaming you could upload new chunks to blossom servers (or normal FTP servers) and then keep updating the root HLS playlist. nostr:npub1v0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnkszrqj49's NIP-5E does something similar using nostr events https://github.com/nostr-protocol/nips/pull/1790

I've looked into BitTorrent V2 a while ago and it looks really promising since it uses a merkle tree instead of a flat list of hashes, but its fixed chunk size of 16KiB is way to small for almost all uses cases and produces 100s of chunks for a single image file. compared to most BitTorrent V1 torrents I've seen which have chunk sizes ranging from 1Mb to 4Mb

I also couldn't find any working implementations of the V2 protocol. so I don't think its being used

H.O.R.N.E.T.S looks promising and I read through the specification enough to understand how its Scionic Merkle Trees work but I don't think it would work well because it requires a backend server in order to communicate with the mainline DHT to fetch chunk metadata. which makes it impossible to implement in web apps, so no video playback in the browser :(

I also tried my hand at creating a simple chunking system on top of blossom https://github.com/hzrd149/blossom/blob/chunked-blobs/buds/10.md and https://github.com/hzrd149/cherry-tree which works but not well enough to implement at the protocol layer

Personally I don't think the solution is protocol level chunking. I think it makes more sense to chunk video at the file level using HLS since it seems to provide the best of both worlds