[{"author": "Ted Hardie", "text": "

Thanks to Ali for scribing.

", "time": "2023-11-09T16:02:49Z"}, {"author": "Spencer Dawkins", "text": "

@Ted Hardie \"How many codecs can we use back to back?\"

\n

All of them, Katie. All of them.

", "time": "2023-11-09T16:04:14Z"}, {"author": "Cullen Jennings", "text": "

+1 for AChat

", "time": "2023-11-09T16:11:40Z"}, {"author": "Mike English", "text": "

Maybe when you rewrite it in Rust it'll have to be called something different ;)

", "time": "2023-11-09T16:13:44Z"}, {"author": "Spencer Dawkins", "text": "

Cullen Jennings said:

\n
\n

+1 for AChat

\n
\n

Somewhat seriously, if we could leave AChat or the clock implementations up and running on the Internet, that would probably be helpful for students, and for implementers who don't work for one of the companies participating in this working group.

", "time": "2023-11-09T16:15:18Z"}, {"author": "Luke Curley", "text": "

https://relay.quic.video/clock track=now

", "time": "2023-11-09T16:16:26Z"}, {"author": "Luke Curley", "text": "

it'll be running for a while, same with https://quic.video/watch/bbb

", "time": "2023-11-09T16:17:50Z"}, {"author": "Lucas Pardue", "text": "

great work folks

", "time": "2023-11-09T16:18:22Z"}, {"author": "Sauli Kiviranta", "text": "

Awesome!

", "time": "2023-11-09T16:18:32Z"}, {"author": "Peter Thatcher", "text": "

Is it crazy to let multiple publishers publish to the same track ID and have them all be forwarded even if they aren't publishing the same content?

", "time": "2023-11-09T16:25:37Z"}, {"author": "Victor Vasiliev", "text": "

I believe we currently have an assumption that (track, group, object) implies unique content

", "time": "2023-11-09T16:26:27Z"}, {"author": "James Gruessing", "text": "

It is a bit crazy - what would be better is having both publishers push different identifiers and something in application link them together.

", "time": "2023-11-09T16:26:33Z"}, {"author": "Peter Thatcher", "text": "

Could you not change it to (track, publisher, group, object) implying unique content? That's somewhat similar to what Cullen is saying by \"allow it\".

", "time": "2023-11-09T16:29:15Z"}, {"author": "James Gruessing", "text": "

If they're separate namespaces, but known to be linked then a relay system can then make better assertions of separation and path diversity, right? If two competing publishers are in same namespace, you might not really know?

", "time": "2023-11-09T16:29:19Z"}, {"author": "Luke Curley", "text": "

my mental model is that ANNOUNCE is a single broadcast, so two publishers announcing the same namespace can produce bitwise identical content

", "time": "2023-11-09T16:31:03Z"}, {"author": "Victor Vasiliev", "text": "

Note that there are two questions here

", "time": "2023-11-09T16:31:18Z"}, {"author": "Victor Vasiliev", "text": "

One is what expectations do publishers have wrt announce, another is what does the relay actually do

", "time": "2023-11-09T16:31:35Z"}, {"author": "Ted Hardie", "text": "

Mo, I locked the queue.

", "time": "2023-11-09T16:31:35Z"}, {"author": "Luke Curley", "text": "

but it would be a mistake to allow both announces to produce different content

", "time": "2023-11-09T16:31:38Z"}, {"author": "Luke Curley", "text": "

because then a relay MUST subscribe to all of them

", "time": "2023-11-09T16:31:51Z"}, {"author": "Ali Begen", "text": "

does not have to be bitwise identical.

", "time": "2023-11-09T16:31:52Z"}, {"author": "Victor Vasiliev", "text": "

We need to specify the first one, but the second one is fine to be underdefined

", "time": "2023-11-09T16:32:01Z"}, {"author": "Christian Huitema", "text": "

Cullen is assuming that if two publishers publish object 25 in track foo, then the binary value of these object is thesame. Can we make that hypothesis

", "time": "2023-11-09T16:32:09Z"}, {"author": "Sauli Kiviranta", "text": "

Sounds like a use case specific thing what degree of difference is acceptable if it is bitwise identical or not?

", "time": "2023-11-09T16:32:58Z"}, {"author": "Jordi Cenzano", "text": "
\n

does not have to be bitwise identical.

\n
\n

YES. I'm with Cullen here

\n

we can publish 2 video GOPs (same objects) from 2 encoders that are totally interchangable / playable, but NOT binary identical

", "time": "2023-11-09T16:33:07Z"}, {"author": "Mike English", "text": "

I disagree with Cullen's dismissal of the deduplication complexity. I think that relies on far too many assumptions holding true.

", "time": "2023-11-09T16:33:12Z"}, {"author": "Jordi Cenzano", "text": "

BTW this is (more or less) how AWS output locking works
\nhttps://docs.aws.amazon.com/elemental-live/latest/ug/output-locking.html

", "time": "2023-11-09T16:34:08Z"}, {"author": "Kirill Pugin", "text": "

yeah, I don't think we need to require things to be binary identical

", "time": "2023-11-09T16:34:33Z"}, {"author": "Cullen Jennings", "text": "

Mike - what sort of thing are you thinking of ?

", "time": "2023-11-09T16:34:42Z"}, {"author": "Ali Begen", "text": "

Kirill Pugin said:

\n
\n

yeah, I don't think we need to require things to be binary identical

\n
\n

even if wanted to, there is no guarantee.

", "time": "2023-11-09T16:35:14Z"}, {"author": "Kirill Pugin", "text": "

@Ali agree

", "time": "2023-11-09T16:35:30Z"}, {"author": "Mike English", "text": "

Mainly issues with control messages and content timing out of the cache

", "time": "2023-11-09T16:35:35Z"}, {"author": "Mike English", "text": "

For conferencing use cases, what you describe may be true, but not necessarily in the general case

", "time": "2023-11-09T16:35:57Z"}, {"author": "Christian Huitema", "text": "

Do we need a concept of \"almost equivalent\" in which the streams can be picked at the GOB boundary?

", "time": "2023-11-09T16:36:40Z"}, {"author": "Cullen Jennings", "text": "

totally fair that I am not thinking enough about the other cases. I was thinking all the caches were controlled by a TTL and stuff got removed a after the TTL expired

", "time": "2023-11-09T16:36:51Z"}, {"author": "Spencer Dawkins", "text": "

@Will Law - Hi, Will, I'm thinking that we may still need to say something about multiple announcers in either Use Cases or Requirements. Does that sound right?

", "time": "2023-11-09T16:36:54Z"}, {"author": "James Gruessing", "text": "

Let's avoid saying \"binary identical\". What we want is media alignment - the segment of media is continuous with what was transmitted previous and aligns with what will come next.

", "time": "2023-11-09T16:37:00Z"}, {"author": "Mike English", "text": "

The queue is closed, but what I'd propose is an option where if we allow multiple publishers for a namespace, the first publisher to auth needs to denote the mode the relay should use to accept later publishers for the same namespace

", "time": "2023-11-09T16:37:18Z"}, {"author": "Will Law", "text": "

@Spencer- yes. Support for redundant ingest should be a core requirement.

", "time": "2023-11-09T16:37:36Z"}, {"author": "Victor Vasiliev", "text": "

I thought I've filed the issue for the token, but I can't

", "time": "2023-11-09T16:37:39Z"}, {"author": "Luke Curley", "text": "

yeah I constantly have to deal with the case where my BBB publisher crashes and tries to announce the same namespace again

", "time": "2023-11-09T16:37:39Z"}, {"author": "Luke Curley", "text": "

but it's a brand new broadcast, you can't treat it as an alternate source of the previous broadcast

", "time": "2023-11-09T16:38:06Z"}, {"author": "Christian Huitema", "text": "

Ted, we are not defeated roman generals. We should avoid bloody metaphors using swords...

", "time": "2023-11-09T16:38:14Z"}, {"author": "Cullen Jennings", "text": "

That makes sense - it fits with the general direction of explicit signalling.

", "time": "2023-11-09T16:38:18Z"}, {"author": "Victor Vasiliev", "text": "

The original problem the token was trying to solve was \"you sub to a track, and then you sub to the track named the same a day later, how do you know if it's the same track\"

", "time": "2023-11-09T16:38:20Z"}, {"author": "Mike English", "text": "

And without the first publisher saying \"there may be more later\" then later publishers would just be rejected with an error

", "time": "2023-11-09T16:38:25Z"}, {"author": "Suhas Nandakumar", "text": "

Agree with Will

", "time": "2023-11-09T16:38:26Z"}, {"author": "Jonathan Lennox", "text": "

James: I think the important thing is whether objects within a group from different publishers can be mixed. I would expect that they couldn't (because the reference frames wouldn't be the same).

", "time": "2023-11-09T16:38:29Z"}, {"author": "Luke Curley", "text": "

my new publisher instance starts back at group=0, so we certainly need a way to say please DON'T combine me with the previous announce

", "time": "2023-11-09T16:39:30Z"}, {"author": "Mike English", "text": "

I think \"don't combine\" should maybe just be the default

", "time": "2023-11-09T16:40:10Z"}, {"author": "Ted Hardie", "text": "

@Christian thanks for the reminder.

", "time": "2023-11-09T16:40:16Z"}, {"author": "James Gruessing", "text": "

Jonathan Lennox said:

\n
\n

James: I think the important thing is whether objects within a group from different publishers can be mixed. I would expect that they couldn't (because the reference frames wouldn't be the same).

\n
\n

If two separate encoders have same contribution and are sync'd to same clock, why not? If they're transmitting completely different stuff, yeah sure.

", "time": "2023-11-09T16:40:20Z"}, {"author": "Jonathan Lennox", "text": "

Slightly different encoder implementations?

", "time": "2023-11-09T16:40:41Z"}, {"author": "Jonathan Lennox", "text": "

Or slightly different decisions about available bandwidth?

", "time": "2023-11-09T16:40:53Z"}, {"author": "James Gruessing", "text": "

My assumption from the \"redundant encoder during big event\" usually is 2/4x same/similar enough encoding/connectivity etc. I agree the moment something is different in the output it gets murky.

", "time": "2023-11-09T16:42:36Z"}, {"author": "Martin Duke", "text": "

What state does ANNOUNCE create on the sender?

", "time": "2023-11-09T16:43:38Z"}, {"author": "Jonathan Lennox", "text": "

I'd expect \"similar enough encoding\" would mean that GOPs from the two encoders would be effectively interchangeable, but I wouldn't expect mixing-and-matching frames within a GOP to work well.

", "time": "2023-11-09T16:43:38Z"}, {"author": "Alan Frindell", "text": "

same track, same group, same object, different content = cache poison, right?

", "time": "2023-11-09T16:44:09Z"}, {"author": "Ali Begen", "text": "

@Jonathan Lennox thats more or less what mpeg dash part 9 (redundant encoding and packaging spec) says.

", "time": "2023-11-09T16:44:17Z"}, {"author": "Kirill Pugin", "text": "

why transport needs to \"worry\" about wither Object 1 from two publishers is binary identical or not? Isn't that application level problem?

", "time": "2023-11-09T16:44:19Z"}, {"author": "Luke Curley", "text": "

yeah that's why I think we need a resumption token, an explict \"I am the same encoder\" signal

", "time": "2023-11-09T16:45:04Z"}, {"author": "Kirill Pugin", "text": "", "time": "2023-11-09T16:45:04Z"}, {"author": "Luke Curley", "text": "

it's really just to avoid shooting yourself in the foot and accidentally poisoning the cache

", "time": "2023-11-09T16:45:59Z"}, {"author": "Kirill Pugin", "text": "

sure, but you don't need objects be binary identical for redundancy to work

", "time": "2023-11-09T16:46:56Z"}, {"author": "Kirill Pugin", "text": "

so, how and what going to protect app developers from \"shooting themselves in a foot\"?

", "time": "2023-11-09T16:47:25Z"}, {"author": "Luke Curley", "text": "

well you're making a lot of assumptions about the encoder being configured with the exact same settings and sequence numbers

", "time": "2023-11-09T16:47:29Z"}, {"author": "Luke Curley", "text": "

ex. the new instance starts at group=0 while the old instance was at group=69 when it crashed

", "time": "2023-11-09T16:48:02Z"}, {"author": "Luke Curley", "text": "

if the old instance was smart enough to flush the current state, it can also be smart enough to flush the resumption token

", "time": "2023-11-09T16:48:33Z"}, {"author": "Kirill Pugin", "text": "

I am not making these assumptions, I am saying it's not transport protocol, imho

", "time": "2023-11-09T16:48:39Z"}, {"author": "Kirill Pugin", "text": "
\n

ex. the new instance starts at group=0 while the old instance was at group=69 when it crashed

\n
\n

so you saying relay should return \"last announcer published group 69, object 101\"?

", "time": "2023-11-09T16:49:41Z"}, {"author": "Victor Vasiliev", "text": "

+1 to Alan, using existing standards is useful

", "time": "2023-11-09T16:50:14Z"}, {"author": "Kirill Pugin", "text": "

ugh: sorry, \"last publisher\"

", "time": "2023-11-09T16:50:31Z"}, {"author": "Peter Thatcher", "text": "

It seems like we conflating transport and media somewhat here, and that it might be more clear to focus on what the relay's deduping behavior is. Once that's clear, the publishers can decide what they want to make the relays do (and can choose to do weird things). And it seems like the crux of the problem is that deduping just by (track, group, object) might not be sufficient for all scenarios. Maybe we need something more in the mix that allows publishers to indicate when it wants deduping and when it doesn't.

", "time": "2023-11-09T16:52:06Z"}, {"author": "Ted Hardie", "text": "

Luke, did you join to talk to the sequence number removal?

", "time": "2023-11-09T16:53:10Z"}, {"author": "Luke Curley", "text": "

yeah

", "time": "2023-11-09T16:53:27Z"}, {"author": "Luke Curley", "text": "

but it's fine we can move on

", "time": "2023-11-09T16:53:38Z"}, {"author": "Ted Hardie", "text": "

Okay, thanks. I've locked the queue after you.

", "time": "2023-11-09T16:53:49Z"}, {"author": "Timothy Terriberry", "text": "

I will say that in WebRTC the SDP for large conferences gets quite large, and adding/removing a single stream a pretty common operation, and while I've used actual gzip compression to turn those into deltas, starting from native deltas avoids the need to parse the whole thing on every change.

", "time": "2023-11-09T16:57:32Z"}, {"author": "Luke Curley", "text": "

the other nice things with deltas is that it tells you exactly what changed

", "time": "2023-11-09T16:57:52Z"}, {"author": "Luke Curley", "text": "

otherwise you have to do a diff between two catalogs just to figure out a new track was added

", "time": "2023-11-09T16:58:05Z"}, {"author": "Timothy Terriberry", "text": "

Yes, it's work on both ends.

", "time": "2023-11-09T16:58:18Z"}, {"author": "James Gruessing", "text": "

Mic: I think the key system specific fields should be replaced with some more open fields that are agnostic. Also is this using the DASH list of UUIDs for key system ident? Should that be in IANA registry?

", "time": "2023-11-09T16:58:22Z"}, {"author": "James Gruessing", "text": "

Thanks, Ted.

", "time": "2023-11-09T16:59:04Z"}, {"author": "Ted Hardie", "text": "

I am going to close the queue soon on this, so if you plan on speaking, please join now.

", "time": "2023-11-09T17:01:29Z"}, {"author": "Timothy Terriberry", "text": "

The counter-argument is that layering gzip on top of SDP is 20 lines of code, but I can only do that because WebRTC doesn't define how the SDP gets exchanged.

", "time": "2023-11-09T17:01:58Z"}, {"author": "Peter Thatcher", "text": "

If you're signaling large RTC conferences using SDP, you're doing it wrong :). Every system I've seen for large RTC conferences uses deltas.

", "time": "2023-11-09T17:02:06Z"}, {"author": "Suhas Nandakumar", "text": "

@tim there was this one for SDP long long ago, but ... https://datatracker.ietf.org/doc/draft-roach-mmusic-pof-pan/02/

", "time": "2023-11-09T17:04:23Z"}, {"author": "Luke Curley", "text": "

I think that example is wrong :p

", "time": "2023-11-09T17:05:05Z"}, {"author": "Mike English", "text": "

<pre></pre>

", "time": "2023-11-09T17:05:53Z"}, {"author": "Kirill Pugin", "text": "

and full track name is tuple (namespace, track), right?

", "time": "2023-11-09T17:06:26Z"}, {"author": "Luke Curley", "text": "

yeah it's a tuple so this is trivial

", "time": "2023-11-09T17:06:45Z"}, {"author": "Kirill Pugin", "text": "

what Cullen just said

", "time": "2023-11-09T17:06:49Z"}, {"author": "Ali Begen", "text": "

that is not how DASH works to be honest, Luke!

", "time": "2023-11-09T17:08:19Z"}, {"author": "Luke Curley", "text": "

heh I have no idea how DASH works

", "time": "2023-11-09T17:09:13Z"}, {"author": "Luke Curley", "text": "

hls 4 lyfe

", "time": "2023-11-09T17:09:17Z"}, {"author": "Peter Thatcher", "text": "

+1 to what Luke just said: bitrates can very a lot when the network conditions of the publisher varies. So being able to update that matters a lot.

", "time": "2023-11-09T17:09:43Z"}, {"author": "Ali Begen", "text": "

I feel sorry for you, Luke :)

", "time": "2023-11-09T17:10:12Z"}, {"author": "Spencer Dawkins", "text": "

The conversation at the mike about having lots of bit rates is pointing to a larger question - how many things that are relevant to transport layers are also of interest here?

", "time": "2023-11-09T17:10:43Z"}, {"author": "Luke Curley", "text": "

my personal opinion is that ABR should be based on max bitrate, otherwise you can switch up to 4k during a VBR black screen, but get completely blasted when a complex scene starts

", "time": "2023-11-09T17:12:05Z"}, {"author": "Kirill Pugin", "text": "

type of bitrate is actually really depend on what ABR algo uses

", "time": "2023-11-09T17:12:43Z"}, {"author": "Luke Curley", "text": "

but yeah the worst part about HLS is that you have to have to set this value once

", "time": "2023-11-09T17:12:45Z"}, {"author": "Spencer Dawkins", "text": "

Peter Thatcher said:

\n
\n

It seems like we conflating transport and media somewhat here, and that it might be more clear to focus on what the relay's deduping behavior is. Once that's clear, the publishers can decide what they want to make the relays do (and can choose to do weird things). And it seems like the crux of the problem is that deduping just by (track, group, object) might not be sufficient for all scenarios. Maybe we need something more in the mix that allows publishers to indicate when it wants deduping and when it doesn't.

\n
\n

It's pretty easy to conflate transport and media when so many of us are coming out of DASH/HLS over TCP, so applications HAD to care about such things, and we're trying to decide how much applications can trust transports (specifically, how much they can trust QUIC).

", "time": "2023-11-09T17:13:03Z"}, {"author": "Luke Curley", "text": "

+1 Mo

", "time": "2023-11-09T17:14:15Z"}, {"author": "Ali Begen", "text": "

Luke Curley said:

\n
\n

my personal opinion is that ABR should be based on max bitrate, otherwise you can switch up to 4k during a VBR black screen, but get completely blasted when a complex scene starts

\n
\n

that is quite suboptimal if your max/peak bitrate is used quite seldomly

", "time": "2023-11-09T17:14:16Z"}, {"author": "Peter Thatcher", "text": "

Also +1 to Mo.

", "time": "2023-11-09T17:14:32Z"}, {"author": "Luke Curley", "text": "

yeah Ali but this is why Twitch was forced to use CBR

", "time": "2023-11-09T17:14:38Z"}, {"author": "Luke Curley", "text": "

in order to use VBR we would need to reserve bandwidth based on the theoretical max

", "time": "2023-11-09T17:15:05Z"}, {"author": "Ali Begen", "text": "

if you have a smart client, you can make wonders. If not, you use CBR :)

", "time": "2023-11-09T17:15:08Z"}, {"author": "Ali Begen", "text": "

Luke Curley said:

\n
\n

in order to use VBR we would need to reserve bandwidth based on the theoretical max

\n
\n

you don't need to. You just need to know about it to account for it,

", "time": "2023-11-09T17:15:34Z"}, {"author": "Spencer Dawkins", "text": "

Spend the last few minutes deciding how many interims we need before Brisbaine? :sunglasses:

", "time": "2023-11-09T17:15:38Z"}, {"author": "Suhas Nandakumar", "text": "

agree with ALi

", "time": "2023-11-09T17:16:01Z"}, {"author": "Kirill Pugin", "text": "

wallclock time of what?

", "time": "2023-11-09T17:17:02Z"}, {"author": "Luke Curley", "text": "

as in, if you want to switch up to 1080p, the player should make sure you can support the theoretical max bitrate (ex. 6Mb/s), not the current bitrate (1Mb/s due to black screen)

", "time": "2023-11-09T17:17:04Z"}, {"author": "Ali Begen", "text": "

you only need to know (mostly) the bitrate for the upcoming segment (not the max). Otherwise, you won't upshift most of the time.

", "time": "2023-11-09T17:17:40Z"}, {"author": "Ali Begen", "text": "

For your night time reading: https://ieeexplore.ieee.org/document/9772091/

", "time": "2023-11-09T17:18:16Z"}, {"author": "Luke Curley", "text": "

again Ali the problem is that if you do that with VBR, then most viewers will buffer when the black screen ends

", "time": "2023-11-09T17:18:17Z"}, {"author": "Luke Curley", "text": "

with CBR sure

", "time": "2023-11-09T17:18:28Z"}, {"author": "Ali Begen", "text": "

I can share the pdf with anyone who wants to read...

", "time": "2023-11-09T17:19:27Z"}, {"author": "Victor Vasiliev", "text": "

We will also need at some point figure out which of those bitrates we need to put in the transport since we may need some form of that for server-side ABR

", "time": "2023-11-09T17:22:17Z"}, {"author": "Spencer Dawkins", "text": "

Spencer Dawkins said:

\n
\n

Spend the last few minutes deciding how many interims we need before Brisbaine? :sunglasses:

\n
\n

That was not intended as sarcasm - my bad ...

\n

We've had two interims between IETF weeks before, and after the amount of progress we're making, we could jalmost certainly ustify one, and probably two (possibly scheduled after the first one).

", "time": "2023-11-09T17:23:12Z"}, {"author": "Alan Frindell", "text": "

I'll note that every single implementer tripped over this

", "time": "2023-11-09T17:23:48Z"}, {"author": "Ted Hardie", "text": "

Hi Spencer, sorry for misinterpreting your sunglass icon. We do plan on talking about it at the very end, but for one in particular.

", "time": "2023-11-09T17:24:03Z"}, {"author": "Victor Vasiliev", "text": "

If people dislike repurposing lowest bit of the type, we can have a block for varint params, and then a block for string params

", "time": "2023-11-09T17:25:52Z"}, {"author": "Christian Huitema", "text": "

+1 on length mismatch as error

", "time": "2023-11-09T17:26:10Z"}, {"author": "Spencer Dawkins", "text": "

Ted Hardie said:

\n
\n

Hi Spencer, sorry for misinterpreting your sunglass icon. We do plan on talking about it at the very end, but for one in particular.

\n
\n

@Ted Hardie - excellent, and I trust you and @Alan Frindell to Do The Right Thing. Epecially if we schedule the first in time to schedule a second interim if we need it.

\n

And people have misunderstood what I was saying before. :grinning_face_with_smiling_eyes:

", "time": "2023-11-09T17:26:48Z"}, {"author": "Jonathan Lennox", "text": "

I'd say error for any encoding error for a known parameter. (Same thing if a string is invalid, or a varint is out of its valid range.)

", "time": "2023-11-09T17:27:11Z"}, {"author": "Luke Curley", "text": "

I like explicit

", "time": "2023-11-09T17:27:28Z"}, {"author": "Spencer Dawkins", "text": "

@Will Law isn't wrong about 2 days plus interop versus 90 minutes plus interop ...

", "time": "2023-11-09T17:29:25Z"}, {"author": "Christian Huitema", "text": "

Yeah! Seattle, I might join...

", "time": "2023-11-09T17:29:35Z"}, {"author": "Alan Frindell", "text": "

+1 Seattle :D

", "time": "2023-11-09T17:29:53Z"}, {"author": "Luke Curley", "text": "

I'd like an in-person interim

", "time": "2023-11-09T17:29:59Z"}, {"author": "Luke Curley", "text": "

my wife is due during Brisbane :)

", "time": "2023-11-09T17:30:15Z"}, {"author": "Victor Vasiliev", "text": "

I am more likely to attend an in-person interim than Brisbane, fwiw

", "time": "2023-11-09T17:30:23Z"}, {"author": "Christian Huitema", "text": "

All IETF meetings should be in Seattle, or maybe Vancouver..

", "time": "2023-11-09T17:30:37Z"}]