search

moq-wg / moq-transport

draft-ietf-moq-transport
Other
87 stars 22 forks source link

Allow padding streams #534

Open vasilvv opened 2 months ago

vasilvv commented 2 months ago

Since we currently don't allow unknown frame types and unknown stream types, there is no way to inject padding on the application level. I believe it would be useful to allow for at least padding unidirectional streams (i.e. streams where receiver ignores everything past the stream type), those could be used for probing (e.g. sending a unidirectional stream at the lowest priority to determine if the connection could sustain more application data).

ianswett commented 2 months ago

As a publisher, one can publish a track like what you're describing, but it sounds like you want it built into the transport.

Understanding how it might be used would be helpful. Is the subscriber trying to see if it has more bandwidth so it can increase quality? If so, why not just subscribe to the higher quality at a lower priority?

suhasHere commented 2 months ago

Agree with Ian . We already do a mix of these things today ( hi/low tracks, low priority probe-like stuff) .. May be I am lacking to understand the requirement here ?

vasilvv commented 2 months ago

Understanding how it might be used would be helpful. Is the subscriber trying to see if it has more bandwidth so it can increase quality? If so, why not just subscribe to the higher quality at a lower priority?

Those are valid if you have one publisher and a lot of subscriber, but for 1:1 scenarios, you would typically have the sender produce only one video stream (and then adjust its bitrate unilaterally), so that's not really an option.

ianswett commented 2 months ago

For 1:1 scenarios where the sender is only producing a single stream, the publisher/sender can decide to probe for more bandwidth unilaterally. The simplest but effective approach is to just retransmit data you've already sent, aka world's simplest FEC.