[Live-devel] Timestamp conversion in RTPSink.cpp

[Roehrl, Simon]

we want to use live555 in one of our products on the WinCE platform and we have some issues with timestamp calculation.
>From file liveMedia/RTPSink.cpp:

u_int32_t RTPSink::convertToRTPTimestamp(struct timeval tv) {

// Begin by converting from "struct timeval" units to RTP timestamp units:

u_int32_t timestampIncrement = (fTimestampFrequency*tv.tv_sec);

timestampIncrement += (u_int32_t)((2.0*fTimestampFrequency*tv.tv_usec + 1000000.0)/2000000);

// note: rounding

...

Could you tell me why you are calculation the timstampIncrement like this?

It's done this way so that the result is rounded to the nearest integer.  Suppose, for example, that "fTimestampFrequency*tv.tv_usec" is 1990000.  Computing "tv.tv_usec*fTimestampFrequency/1000000.0" will give you 1 (when converted back to an "int").  However, computing "(2.0*fTimestampFrequency*tv.tv_usec + 1000000.0)/2000000" will give you 2, which is more accurate.

What specific 'issues' do you think you are having with timestamp calculation?  Are you having a problem specifically with this line of code??  If not, then your 'issues' are probably not with timestamp calculation.  Note that developers usually don't need to concern themselves with RTP timestamps; our software automatically converts presentation times to RTP timestamps (on transmission), and then back to presentation times (on reception).  As a developer, the important thing that you need to concern yourself with is ***presentation times***.  Your data sources' frames *must* have accurate presentation times, and they must be aligned to 'wall clock' time (i.e., the time that you would get by calling "gettimeofday()".)


Thank you very much for your answer. Your words make sense concerning the calculation!
There were two different (independent) problems:
1 the underlined line returns 0 on Freescale's I.MX53 ARM cpu, the reason:    "fTimestampFrequency*tv.tv_usec" is too large for 32bit. As the datatype of "timestampIncrement" is u_int32_t the calculation is performed with 32 bit width. On a 64bit PC this seems not to be a problem because it calculates automatically with 64bit. The fix for this is to use a u_int64_t variable which is casted back to 32bit in the addition of TimestampBase and incrementTimestamp.

2  in the gettimeofday function in GroupSockHelper.cpp (line 700):
    Theres a define for WinCE, but unfortunately the WinCE version oft gettimeofday is not working properly, I assume that it wasn't tested? You can find alot occurences of this problem in WinCE world. The problem is the "GetSystemTime()" call, which should fill the SYSTEMTIME struct, but it does not, at least not the milliseconds field (which is always 0). The solution I used:

int gettimeofday(struct timeval* tp, int* /*tz*/) {
#if defined(_WIN32_WCE)
  /* FILETIME of Jan 1 1970 00:00:00. */
  static const unsigned __int64 epoch = 116444736000000000LL;
  static Boolean isFirstCall = True;
  static LONGLONG unixStartTime = 0;
  static DWORD firstTickCount=0;

  if (isFirstCall) {

    FILETIME fileTime;

    GetSystemTimeAsFileTime(&fileTime);

    LARGE_INTEGER date;
    date.HighPart = fileTime.dwHighDateTime;
    date.LowPart = fileTime.dwLowDateTime;

    unixStartTime= (date.QuadPart - epoch) / 10000000L;

    firstTickCount = GetTickCount();

    tp->tv_sec=(long)unixStartTime;
    tp->tv_usec= 0L;

    isFirstCall = False; // for next time

  } else {
    // add elapsed seconds
    tp->tv_sec= (long)unixStartTime + (GetTickCount()-firstTickCount)/1000;
    tp->tv_usec=(GetTickCount()-firstTickCount)%1000 * 1000;
}

#else
...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121106/e19ad50f/attachment.html>