Open obilodeau opened 3 years ago
This is tricky, AFAIK H264 doesn't support dynamic resolution changes within the same stream. I can think of two approaches:
Approach 2 seems like the easiest to implement, but not the most user-friendly.
I'll take a look at the dynamic resolution handling code and see if I can handle it in the Mp4Handler to implement approach 2
I think option 1) is the only option. Especially if one would create a conversion pipeline. Creating a new file would be surprising and hard to track.
Then again, how fast is this first pass going to be? I hope it'll be fast.
An interim fix would be to emit a warning and exit with a non-zero status if there's a resolution change in a conversion. That would send a clear message to users.
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 off-band, otherwise I'll try to prepare one myself.~ I see you attached the files above... D:
client updates to a higher resolution (tested: via client dynamic resolution update, not tested: via manual resolution change)
This isn't allowed by MSTSC as far as I know. Maybe some Linux clients allow it, though?
Preconditions during the MITM session:
Converting this
.pyrdp
file to an MP4 will result in a video that uses the first low resolution throughout the duration of the video meaning you will miss out on some screen elements.Attaching a capture to repro the issue.