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
...
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
