Alexandre Beaulieu

This is tricky, AFAIK H264 doesn't support dynamic resolution changes within the same stream. I can think of two approaches: 1. Do a first passs of the replay to look...

I do not know how heavy it will be to parse the whole session without actually rendering it. ~If you have a repro capture, you can send it to me...

I would auto-close all "trash" connections that do not complete the connection sequence within a set amount of time. For the purpose of the live tabs, this could be considered...

As discussed offline, I think we need to fully revisit how to calculate FPS/insert still frames. As a starting point, we can know the expected wallclock duration of the recording...

Keep in mind #315 when addressing this. A big problem we have for larger captures is attempting to slurp the entire session file into memory and causing out of memory...

This is still reproducible. There's a lot of noise on the device redirection channel, so it's very hard to track what is happening to compare working transfers with non-working transfers....

NOTE: While we instrument this, we should address #222 since it's located in the same code area, and maybe shed some light on this.

To add to my initial description, here is what this would involve at the minimum: - [ ] (Maybe) Modify the AttackerMITM to expose a `isHijacked` property. - [ ]...

**Client Product ID** This could be paired with the `clientProductDigId` from `CLIENT_DATA` as it could be useful for fingerprinting actors or various tools. There isn't much documentation on the generation...

This could probably be fixed by reading the user file line by line instead of slurping it. I guess it would also have the added bonus of being able to...