[Live-devel] compilation issue / vcpkg / windows
Ross Finlayson
finlayson at live555.com
Mon Feb 14 07:09:17 PST 2022
> On Feb 15, 2022, at 3:53 AM, g.jaegy <g.jaegy at imagine3d.fr> wrote:
>
> So, you were right.
>
> Setting fPresentationTime using gettimeofday() solves the problem.
>
> Now, this however means the output frame time is not correlated to the time at which the original frame was captured (I'm capturing frames at 30Hz, but possibly the interval between two frames is not 100% constant, reason why I thought using the proper captured frame times would be a better idea to preserve smoothness).
>
> It also means different NALUs from a single frame have different time stamps, which I also thought was not correct.
>
> Do you know any source of information I could use to understand this two points ?
It’s OK to use frame counts etc. to set your “fPresentationTime” values, but the *base value* - i.e., the value at the very start of your streaming - MUST be the same as you’d get by calling “gettimeofday()”. I.e., it’s OK to do something like this (pseudo-code):
if (this is the first frame that we’re sending) {
fPresentationTime = BaseTime = value from “gettimeofday()”;
} else {
fPresentationTime = BaseTime + frameCount/frameRate;
}
That’s what I meant when I said that your “fPresentationTime” values "must be aligned with the values that you’d get by calling gettimeofday()”. Not that each “fPresentationTime” must be computed by calling “gettimeofday()”, but that “fPresentationTime” must start out with the same value as “gettimeofday()”, but then can increase smoothly for each frame (and with the same value for multiple NALUs within the same frame), based on the frame count and frame rate (assuming that the frame rate remains constant).
This will be my (and I hope your :-) last posting on this thread.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
More information about the live-devel
mailing list