RTP time stamps should not be scaled when Speed header is used
The current implementation of the RTSP Speed header scales the RTP time stamps according to the value of the Speed header. For example, for a 30 fps video stream played at normal speed (Speed=1.0) the RTP time stamps will increase with approximately 3000 between frames. However, if Speed=2.0 then in our current implementation they will increase with approximately 1500, i.e. the time stamps are scaled with the Speed.
That behavior is wrong. The value of the Speed header is supposed to determine the speed at which the data is sent, but it's not supposed to change the playback time. The primary use case is client scaling of the media.
RFC 7826, section 251, defines the Speed as follows:
"Speed: The ratio of playback time delivered per unit of wallclock time."
It's further explained as:
"Speed (Section 18.50) affects how much of the playback timeline is delivered in a given wallclock period. The default is Speed = 1 which means to deliver at the same rate the media is consumed. Speed > 1 means that the receiver will get content faster than it regularly would consume it."
In essence, Speed controls the delivery speed, not the playback speed. Thus the time stamps should not be scaled. For more information please see http://ietf.10.n7.nabble.com/RTSP-Speed-and-Scale-overview-text-td191370.html.
One possible to this is to instrument the the RTP payloader (through a property?).