Log BWE stats in a compatible with Medooze stats viewer #155
Conversation
…ut sent packets. Add isRtx and isProbing flags to it.
…oze stats viewer.
Call it when we've processed a complete tcc packet.
|
cool, will take a look through this. i wonder, though, if we want to think about how we accomplish this sort of thing in the bigger picture of the other stats changes? |
|
Yeah, outputting this through a REST API (rather than as timeseries logs modified by a Perl script) would be a better approach. |
| /** | ||
| * Whether this packet was generated to be a probing packet. | ||
| */ | ||
| var isProbing: Boolean = false |
There was a problem hiding this comment.
i am a bit worried about PacketInfo 1) becoming a dumping ground for fields and, more fundamentally, holding data that doesn't really apply to all packets (true, marking an audio packet or sctp packet as isProbing = false is technically accurate, but it still feels a bit wrong). i don't think this change along ruins things terribly, but i worry about the precedent. i'm probably being a bit too paranoid and if we don't think it's too bad it's something we could wait to address down the line should it become a problem.
There was a problem hiding this comment.
Would making a VideoPacketInfo subclass be helpful?
There was a problem hiding this comment.
I thought about that, but wondered what sort of guarantees we could make as to when one would actually be used. For example, would we convert it on the ingress as well when we discovered a packet was video? Or would it only be in certain places? Also, if we were going to do this we'd have to test and cast it, but at that point would it be that much different than just testing and casting the underlying packet? If not, then maybe we could just do different packet types to denote probing?
This is modifications to our system so that we can use Medooze's useful log viewer.