presentation time to MultiFramedRTPSink

[Massimo Perrone]

Hi Ross,

I am working on a RTSP media server based on live555 framework, which 
uses h264 video contained in fragmented mp4 files as source and streams 
their contents towards RTSP client.

I'm having an apparently strange problem when resuming a paused session. 
In short, when the session begins, streaming starts just after the 
reception of the RTSP PLAY, doing a seek to the specified NTP time.

After a while I issue a PAUSE on the client side and the streaming gets 
stopped accordingly. All correct, up to this point. When, after 10-20s, 
the play is resumed, my RTSP server gets a PLAY command with no NPT 
specified, so a nullSeekStream() is invoked to resume the paused 
session: the streaming resumes, as can be observed also on the client 
side, but after a while I receive a kind of "spurious" RTSP PAUSE from 
the client, which doesn't correspond to a real user action on the client.

Apparently this is a client issue, but a more accurate probe has shown 
that the TCP packet which contains the "spurios" PAUSE has a null (i.e. 
zero) TCP window size (take into account that, due to constraints that 
do not depend on my will, RTP streaming is done over RTSP). I noticed 
that the frames read after resuming the paused stream are sent with a 
wrong timing, in a burst.

I then tested to see what happens with live555MediaServer, with the same 
client and the same use case, and things worked well. I noticed that, 
while for live555MediaServer the presentation time of the frame passed 
to MultiFramedRTPSink are aligned with the server clock, in my case the 
same presentation time, as read from the mp4 container, are relative to 
the Unix epoch (that is, first frame has (0, 0), second has (0, 40000) 
and so on. So I arranged the server in order to normalize the 
presentation time as read from the file, by adding a timeval 
corresponding to the session starting time.

This way things seems to work well, but I would like to be sure, so my 
question is: the fact that the frame presentation times are 
aligned/normalized with respect to server clock is an essential 
prerequisite in order to grant the correct timing for the sending of RTP 
packets? Can you help me to better understand this point?

Thank you in advance,

Massimo