MOQ's week included a cinema programme, some overdue relay maintenance, and a browser microphone looking for someone to talk to.

There were new specification proposals too. Even a protocol with a social life has homework.

For October 5–11, the useful question was what happens around the successful demo: when a viewer arrives late, a connection fails, or the new transport meets an existing application.

DEMOQED put applications on the bill

Last issue's cinema invitation now has a programme worth exploring. DEMOQED's October 8 agenda at San Francisco's Alamo Drafthouse put concrete uses alongside protocol engineering.

Meta's Aman Sharma and Konstantin Tsoy were listed for Instagram and Facebook Live ingest. Alan Frindell was listed for scaling the OpenMOQ MOQX relay. Elsewhere on the bill: Evolve Robotics on MOQ beyond media, Cloudflare's Mike English on ham radio, and Daily's Vanessa Pyne benchmarking MOQ against HLS with a LaserDisc.

The LaserDisc has apparently survived long enough to interview its replacements.

That range is useful. Ingest, relay capacity, robotics and playback measurement put different demands on a transport. They give readers specific teams and applications to follow. A talk title alone does not establish deployment scale or a benchmark result, so those claims can wait for the supporting material.

Packets would like a deadline and an allowance

The core transport is still Draft 22, covered last week. This week's new work includes individual extension proposals, not newly adopted protocol behaviour.

Alan Frindell and Ian Swett's October 5 timestamp proposal supplies a common representation for object time. Aman Sharma's October 6 end-to-end delivery-timeout proposal uses it to account for delay accumulated through a relay chain.

A late object should not get a fresh allowance at every stop. That is a very generous travel policy for something the viewer no longer needs.

The first forwarded object establishes a reference. Later objects can expire when they fall too far behind that timeline. This measures relative lateness; it does not bound startup delay or guarantee capture-to-screen delivery.

A separate subscription flow-control proposal, announced October 8, would let subscribers grant stream and byte credit per subscription. That could help stop one eager source from overwhelming the receiver's resources. It is neither a bitrate limit nor a replacement for congestion control.

Useful boundaries. Still proposals.

OpenMOQ did the relay maintenance

The October 10 OpenMOQ moqx v0.3.6 release has the sort of changes that matter after the first successful playback.

One cache-eviction bug could discard the newest group of a still-live track under byte pressure. If that group held a catalog published only once, a late subscriber could miss the information needed to understand the media. The fix keeps that group available.

Welcome to the stream. Here is what the stream is.

The release also fixes an upstream connection that stopped retrying after failing mid-handshake, a cache-eviction thread that could consume 100% CPU, and several concurrency crashes. These are concrete reliability improvements in an implementation, rather than evidence that every MOQ deployment is now production-ready.

Last week's graceful-restart work in moq.dev tackled a related operational concern in a different codebase. This week OpenMOQ gets the spanner.

Read the upgrade note before reaching for it: v0.3.6 removes draft-14 support. A configuration that still lists version 14 fails at startup. This is not a draft-22 compatibility announcement.

A relieved solid rectangular Packet uses a small spanner while replacing a missing data block in a relay cabinet's cache drawer.
The newest group goes in the drawer. The CPU gets to sit down.

One smaller fix also deserves its line: MediaMTX v1.21.2, released October 8, changes its MOQ catalog track name from .catalog to catalog. A single dot is quite capable of arranging a compatibility meeting.

Built with MOQ: a voice room, with a new entrance

VoiceBlender's browser voice-room example sends microphone audio as Opus over MOQ and receives the room's mixed audio back. Its wider mixer also accepts SIP and WebRTC audio legs.

This is an existing, experimental draft-11 proof of concept, not a new release or a production-ready MOQ path. Follow the guide's matching local server/client setup, then add a second participant or its documented WAV source. Alone, you hear mix-minus-self silence: the room politely declines to repeat you.

It's a useful experiment in adding MOQ to an existing voice system. Bring the matching versions; leave assumptions about draft-22 interoperability outside.

Packet connects a laptop and microphone mixer to an old desk telephone, illustrating an experimental bridge between browser audio and existing voice systems.
A new transport meets the office phone.

After the demonstration

The programme gives us applications to follow. The proposals address late media and receiver limits. The release notes deal with missing catalogs and failed connections. The voice demo gives a curious reader somewhere to start.

MOQ is accumulating things you can inspect, questions you can test, and version numbers you really should check.

Keep the demo. Read the upgrade notes.