Feature request: WebVTT sidecar subtitles instead of burn-in

Right now the converter burns subtitles into the video, which means every subtitle track requires a separate re-encode.

This is painful for a few reasons:

1. Each subtitle language requires a full re-encode of the same file

2. Switching subtitle language after the fact triggers ANOTHER full video re-encode, just to change the subs.

3. The burn-in encoding is broken for certain languages. Thai renders as [] boxes, clearly not encoded correctly (missing font or wrong encoding). This is a daily issue for me, my partner is Thai

Proposed fix: extract the subtitle tracks, convert them to WebVTT and serve them alongside the original source as separate tracks instead of burning them in.

Benefits:

• Single encode per file, not one per subtitle language

• Switching subtitle language is instant, no re-encoding at all

• No more rendering issues with non-Latin scripts, the browser/player handles the text with the user's system fonts

• Much easier to consume via the API in a custom player (just point a <track> element at the VTT URL)

• Users can toggle subs on/off or switch languages without waiting

This would massively simplify the pipeline on your end, save you compute and make the API far more useful for anyone building a custom frontend.

Thanks.