feat(moq-gst): add group-order feature, ascending/max-latency-ms properties, and consumer diagnostics#13
Conversation
…roperties - Declare group-order Cargo feature - Add max_latency_ms and ascending to Settings/ResolvedSettings - Expose max-latency-ms and ascending as GStreamer properties on moqsrc - Set track_ref.ordered = ascending behind #[cfg(feature = "group-order")] - Extract subscribe_track() helper to eliminate duplicated cfg block - Consumer latency uses Duration::MAX when ascending, else max_latency_ms Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
ascending and max_latency_ms are now orthogonal: the consumer always uses Duration::from_millis(max_latency_ms) regardless of ascending mode. The subscriber sets G_MAXUINT64 as the default when ascending=true and no explicit MOQ_MAX_LATENCY_MS is provided, preserving the unlimited-budget behaviour of bare moq-ascending while allowing moq-125-asc and similar variants to apply a real budget with ascending group ordering. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
… is no-op Add .mutable_ready() to all five moqsrc property builders so settings can be changed in READY state. Without this, writes after ReadyToPaused are silently accepted but never applied to the running session. Emit a gst::warning! when ascending=true is set but the group-order feature is not compiled in, so callers get an explicit signal instead of silent wrong behavior. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Code Review
This pull request introduces max-latency-ms and ascending settings to the moq-gst GStreamer source element, allowing users to configure group delivery order and latency. Feedback on these changes highlights a potential compilation error when the group-order feature is enabled due to a missing ordered field in the moq_net::Track dependency. Additionally, it is recommended to update the description of the max-latency-ms property, as it is no longer ignored when ascending is set to true.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| #[cfg(feature = "group-order")] | ||
| { track_ref.ordered = ascending; } |
There was a problem hiding this comment.
The moq_net::Track struct defined in rs/moq-net/src/model/track.rs does not currently have an ordered field. Enabling the group-order feature will result in a compilation error because track_ref.ordered does not exist.\n\nPlease ensure that the workspace dependency moq-net is updated to include the ordered field (as mentioned in the PR description regarding commit c7e8ab58), or that the required changes are merged/included in this branch.
72df500 to
c7e8ab5
Compare
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Summary
Builds on top of
c7e8ab58 Add group-order support, which added transport-layer support for ascending group ordering (Track::ordered,group_ascendingin the relay priority queue) but did not propagate it to the GStreamer plugin layer.This PR completes the work by exposing
ascendingandmax-latency-msas first-class GStreamer properties onmoqsrc, declaring thegroup-orderCargo feature, and decoupling the two axes so callers control them independently. Consumer latency is alwaysDuration::from_millis(max_latency_ms)with no special-casing of ascending mode.Additionally, the
Consumerinmoq-muxgains structuredINFOlog lines that let callers distinguish three distinct causes of frame loss: budget drops, stream errors, and ordering discards.A pre-merge review caught two additional property API issues, fixed before merge:
ParamSpecBuilderchains called.mutable_ready(). Settings snapshot is taken once atReadyToPausedand never re-read, so property writes after that transition are silently accepted but have no effect on the running session.ascendingproperty was registered unconditionally but compiles to a no-op (let _ = ascending;) when built without--features group-order. A caller settingascending=truewould see the getter returntruewhile the relay always gotordered=false. Fixed by emittinggst::warning!in the#[cfg(not(feature = "group-order"))]arm.Changed files
rs/moq-gst/Cargo.toml— declares[features]section withgroup-order = [](was referenced in source but never declared; building with--features group-orderpreviously failed)rs/moq-gst/src/source/imp.rs— addsmax_latency_ms/ascendingtoSettings/ResolvedSettings, exposes both as GStreamer properties, adds.mutable_ready()to all five property builders, emits warning when ascending is set without the feature, extractssubscribe_track()helper to avoid duplicating the#[cfg]block for video and audio tracksrs/moq-mux/src/container/consumer.rs— addsframes_in_current_groupcounter and three structuredINFOlog lines for loss attribution (budget drop / stream error / ordering discard)Test plan
cargo build --release --features group-ordercompiles cleanlymoqsrcexposesmax-latency-msandascendingas inspectable GStreamer properties with correct defaultsorderedflag🤖 Generated with Claude Code