docs: document tokenId-scoped restream dedup behavior#705
docs: document tokenId-scoped restream dedup behavior#705devin-ai-integration[bot] wants to merge 7 commits into
Conversation
Co-Authored-By: zita.liao <zita.liao@dolby.com>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
|
|
|
||
| To disable re-streaming on specific feeds add the **norestream** boolean [publishing parameter](/millicast/broadcast/publishing-parameters.md) to your configured publishing URLs. This is used to indicate which sources specifically should be used or not. For example, in a Multi-bitrate (MBR) configuration where there are multiple quality layers being ingested, you might re-stream only the highest quality layer and then add `&norestream` to any additional contribution layers. Similarly, if you have an interactive [multi-view](/millicast/playback/multi-view.md) broadcast where multiple sources are sharing the same publishing token, you can configure the URLs to only re-stream your intended source. | ||
|
|
||
| :::info Token-scoped dedup behavior |
There was a problem hiding this comment.
- make another ## tile with something like "Restrict per publish token scope"
- "publisher node" is a bit too internal for the user. Find a better way for it, and hide tech details to just mention that if user would like to restream different ingest, better to use different token to each ingest, or explicitly use norestream to disable the ingest to restream with a same publish token
…l terminology Co-Authored-By: zita.liao <zita.liao@dolby.com>
|
|
||
| ## Re-streaming scope per publish token | ||
|
|
||
| Re-streaming is scoped to the **publish token**. Only one active ingest per publish token will be re-streamed at a time. If a new ingest starts using the same publish token while another is already re-streaming, the existing re-stream is stopped and the new ingest takes over. |
There was a problem hiding this comment.
if it happens to route to different publish node, then it would not stop. So here, change "the existing re-stream is stopped" to "would be stopped". Let user knows restream with a same publish token is not suggest
There was a problem hiding this comment.
Addressed — changed "is stopped" → "would be stopped" and added a bold recommendation that re-streaming multiple ingests with the same publish token is not recommended, noting the behavior may be unpredictable.
Co-Authored-By: zita.liao <zita.liao@dolby.com>
|
|
||
| ## Re-streaming scope per publish token | ||
|
|
||
| Re-streaming is scoped to the **publish token**. Only one active ingest per publish token will be re-streamed at a time. If a new ingest starts using the same publish token while another is already re-streaming, the existing re-stream would be stopped and replaced by the new ingest. Because of this, **re-streaming multiple ingests with the same publish token is not recommended** — the behavior may be unpredictable. |
There was a problem hiding this comment.
"Only one active ingest per publish token will be re-streamed at a time. If a new ingest starts using the same publish token while another is already re-streaming, the existing re-stream would be stopped and replaced by the new ingest."
Change to (please polish)
"Only one active ingest per publish token per publish node will be re-streamed at a time. If a new ingest starts using the same publish token route to (decided by load balance strategy) a same publish node with another is already re-streaming, the existing re-stream would be stopped and replaced by the new ingest. So multiple stream with a same public token would randomly fail. In general, restream different streams with a same publish token is not full-function supported and so not suggest."
|
|
||
| ## Re-streaming scope per publish token | ||
|
|
||
| Re-streaming is scoped to the **publish token**. Only one active ingest per publish token will be re-streamed at a time. If a new ingest starts using the same publish token while another is already re-streaming, the existing re-stream would be stopped and replaced by the new ingest. Because of this, **re-streaming multiple ingests with the same publish token is not recommended** — the behavior may be unpredictable. |
There was a problem hiding this comment.
"If a new ingest starts using the same publish token while another is already re-streaming, the existing re-stream would be stopped and replaced by the new ingest."
Change to (Pleae polish)
"If a new ingest starts using the same publish token while another is already re-streaming, behavior is undefine. Either the existing re-streamed ingest stopped, or both ingest restream to a same endpoint. Both cases would end up restream endpoint to error or confuse stats."
|
|
||
| ## Re-streaming scope per publish token | ||
|
|
||
| Re-streaming is scoped to the **publish token**. Only one active ingest per publish token will be re-streamed at a time. If a new ingest starts using the same publish token while another is already re-streaming, the existing re-stream would be stopped and replaced by the new ingest. Because of this, **re-streaming multiple ingests with the same publish token is not recommended** — the behavior may be unpredictable. |
There was a problem hiding this comment.
"re-streaming multiple ingests with the same publish token is not recommended" --> "re-streaming multiple ingests with the same publish token is not supported"
There was a problem hiding this comment.
Addressed all three review comments:
- Rewrote to explain that load balancing routes ingests to different internal nodes, making the behavior undefined when sharing a publish token.
- Described both failure modes (one stopped, or both re-streaming to the same endpoint causing errors/corrupted stats).
- Changed "not recommended" → "not supported".
Co-Authored-By: zita.liao <zita.liao@dolby.com>
|
|
||
| ## Re-streaming scope per publish token | ||
|
|
||
| Re-streaming is scoped to the **publish token**. When multiple ingests share the same publish token, the system's load balancer may route them to different internal nodes, resulting in undefined behavior: |
There was a problem hiding this comment.
hide tech details about routing. Just let reader knows the undefined behavior. Remove all tech terms such as "route", "internal nodes", "node"
There was a problem hiding this comment.
Addressed — removed all tech terms ("route", "internal nodes", "load balancer"). The section now simply states that behavior is undefined when multiple ingests share a publish token, without exposing any infrastructure details.
Co-Authored-By: zita.liao <zita.liao@dolby.com>
Co-Authored-By: zita.liao <zita.liao@dolby.com>
Co-Authored-By: zita.liao <zita.liao@dolby.com>
2 participants
Summary
Adds a new "Re-streaming scope per publish token" section to
millicast/distribution/re-streaming.mdxdocumenting that re-streaming is scoped per publish token — only one active ingest per token will be re-streamed at a time. Recommends using separate publish tokens for independent re-streams, or&norestreamwhen multiple ingests must share a token.Related: millicast/media-server#534 (code comments in
Restreamer.js)Link to Devin session: https://dolby.devinenterprise.com/sessions/3581ac14a78b4b269c43b4be6af6f620
Requested by: @ZitaLiao