Devcon 8 is in Mumbai in about three months. I’d like to try something with the network and I want to find out early whether it’s daft.
The idea
Take the on-the-ground AV feed from Devcon, run live speech-to-text on it, and serve English and Hindi subtitles simultaneously — both rendered on the same timeline, from the same session, by Livepeer orchestrators being paid in PM tickets.
Not a hosted demo on someone’s laptop. Two or three orchestrators, real capability discovery, real payments, at an event with an audience that includes a lot of Hindi speakers.
There’s also a strong chance the event needs plain transcoding, and that would land with the network too. I want to be clear that nothing on that is confirmed — I’m not announcing a deal, and I’d rather under-promise here than have anyone plan around it. But it’s worth saying out loud because of how this capability is built: renditions and captions come out of the same session, one upload decoded once. So if transcoding is needed anyway, the subtitles are close to free — the marginal cost is the speech-to-text, not a second pipeline.
The exciting part, for me, is testing the new thing. Transcoding at an event is a known quantity and the network does it every day. Live English→Hindi subtitles from a Livepeer orchestrator is not, and that’s the bit I actually want to find out about.
Where this comes from
I’ve been running a live-runner capability, transcoding-with-captions/whisper, which takes one live A/V stream and returns transcoded renditions and live captions from the same session — one upload, decoded once, feeding both the encoder ladder and speech-to-text. It’s been running paid on mainnet: winning tickets redeemed on Arbitrum, fees credited to the orchestrator. Details in my earlier post.
The captions half is deliberately pluggable, so adding translation is an extension of an existing seam rather than a new bet. I’ve done the local work to convince myself it’s feasible: ctranslate2 is already in the container because faster-whisper depends on it, so machine translation is model weights plus a few lines rather than a new stack.
The framing that interests me is the same one as before: this is an add-on to transcoding an orchestrator already does. Same input, captions as the differentiator, and now a second language as the differentiator on top.
The event side is covered
I’m deeply connected into the Devcon organisers and I know how to reach the people at the EF who handle AV. So this isn’t a proposal that depends on a stranger being talked round — I can get the conversation about a feed started, and I’ll do that once there’s something concrete enough to be worth their time.
That’s deliberately the order I’m doing it in. I don’t want to ask the AV team for a feed and then discover the network can’t serve it, so I’m asking here first.
Why Hindi specifically, and why it’s the hard part
Because Mumbai. But also because it’s genuinely harder than the easy wins, and I’d rather find that out in public than quietly ship something mediocre.
Generic open MT models are weak on English→Hindi. Opus-MT’s en-hi pair has far less parallel data behind it than en-fr or en-de, and it shows. NLLB-200 is better. The strongest open option I’m aware of is IndicTrans2 from AI4Bharat, which is purpose-built for Indic languages — but I have not benchmarked it, and I have not benchmarked any of them on ASR output, which is the actual workload.
That last point matters more than model choice: we would be translating whisper transcripts, which are fragmentary and unreliably punctuated. Every MT benchmark you’ve seen was measured on clean written text. Expect worse. Translating only finalised segments rather than interim previews mitigates it, but does not erase it.
What I’m asking for
1. Two or three orchestrators willing to run an English→Hindi capability. Redundancy is the point, not capacity — I don’t want a single box to be the reason subtitles stop mid-talk. The failure mode I most want to design against is the one where a capability is advertised and then returns insufficient capacity at inference time, burning the client’s tickets for nothing. Two or three independent operators makes that survivable.
GPU requirements are modest by this network’s standards — whisper small in int8 wants ~1–2 GB VRAM, and an MT model on top is small. Anything from a 1660 up should do. The container is one podman pull.
2. Opinions on model choice from anyone who actually speaks Hindi. I don’t. I can measure BLEU and I can measure latency; I cannot tell you whether the output is embarrassing. If you speak Hindi and would look at sample output, that’s worth more to me than another GPU.
3. The capability naming question, again. Discovery matches capability strings exactly — no prefixes, no wildcards — so if two of us ship near-identical translation capabilities under different names we fragment supply for nothing. I raised this last time and it’s still open. Does the target language belong in the capability name, in metadata, or as a request parameter? I have a working opinion (parameter) but no authority, and I’d rather converge than claim.
Honest state of it
- The captioning capability works and is paid. That part is real.
- Translation is designed but not built. Next step is benchmarking
en-franden-cson ARM CPU to find out what a second target costs. - Hindi quality is an open question I expect to be the weakest link.
- Nobody has run any of this at event scale, under event conditions, with an audience.
- Three months is enough time, but it is not lavish.
If this is interesting, the useful replies are “I’d run an orchestrator for it”, “here’s why the model choice is wrong”, or “I speak Hindi and I’ll review output”. If it’s daft, I’d genuinely rather hear that now than in Mumbai.