H264 frame corrupted when using rtpproxy about rtpproxy HOT 4 CLOSED

Julien, Thank you for your report. This is sort of well-known defficiency (missing feature?). The problem with handling video streams is that they have no fixed PPS, while the RTPProxy forwarding code is optimized to handling audio streams with fixed PPS rates that are multiple of 10ms and no less that 10ms. This serves two functions: it gives each session fairly equal access to forwarding resources preventing one session from jeopardizing network bandwidth and/or forwarding capacity (helpful with dealing brain-damaged devices spewing bazillions packets per seconds as well as certain types of attacks on infrastructure), but it also smoothes out any irregularities in the incoming RTP stream(s) without using jitter buffering. As you can see on the attached pictures it does pretty decent job on that, combing down your very irregular stream to one that has 10ms spaced apart. At the expense of dropping 40% of all packets of course. Now, way to fix it in long-term could be adding different type of forwarder that is event-driven and optimized to handling variable-rate streams. What you can do in a short-term, however, is to increase max PPS rate from 100 currently to say 1000, that would give you sufficient resolution to handle this kind of streams, at expense of some extra CPU burnout. This can be done by changing: #define MAX_RTP_RATE 100 to #define MAX_RTP_RATE 1000 and then re-compiling the code. It would be really helpful if you can check if suggested workaround works, we might then just make it a command-line option and add a manual entry.