when to play a video frame using NTP?

[Hughes]

I analysized Audio/Video synchronization (Raw/RTP/UDP, not TS/RTP/UDP).
and I know, using RTCP SR, Audio timestamp ->NTP,and Video timestamp->NTP。
So Audio and Video can synchronize on a timebase.

VLC has its systemclock(gettimeday(), as a timebase?), but when to play using NTP?
my understanding is when (a Video Frame's) NTP+ (end to end)delay=(now)gettimeday(),play the video Frame. Is this right?

Thanks very much!

in the (Ross Finlayson <finlayson@live555.com>,Derk-Jan Hartman <hartman@videolan.org>) mail, I find this part:
Perhaps the solution would be for VLC to maintain an offset - for each RTP stream
between the PTS that it reports and 'wall clock time'. I.e., do something like (pseudocode):
{
int64_t ptsToUse;
int64_t ptsWallClockOffset = 0;
bool haveSeenFirstValidPTS = false;

if (!haveSeenFirstValidPTS && tk->sub->rtpSource()->hasBeenSynchronizedUsingRTCP())
{
/* This is the first RTCP-synched reported PTS => set "ptsWallClockOffset" */
ptsWallClockOffset = gettimeofday() - reportedPTS;
haveSeenFirstValidPTS = true;
}
ptsToUse = reportedPTS + ptsWallClockOffset;
}

[Rémi Denis-Courmont]

If you think you should play the RTP samples at NTP time, you don't understand RFC3550. This is not the place to explain the specification.

[Hughes]

Thanks for your reply!
Idon't mean Player should play the RTP samples at NTP time.
I know that using RTCP SR, (Audio sample)timestamp->NTP, and (Video sample)timestamp->NTP.
So Audio and Video can synchronize on a timebase. Is this right?

how does Player(VLC) create a timebase?
Is there any relationship between Player's timebase and NTP time?
Is there any relationship between (Audio/Video Sample's)PTS and NTP time?

Thanks very much！

[Rémi Denis-Courmont]

VLC uses the RTCP SR as a clock reference for the RTP timestamps, so that it generates consistent PTS across multiple RTP sessions from the same sender. Of course.

The actual play time is determined by the RTP demuxer setting the clock reference, and the VLC estimating the long term drift between the real-time clock and the sender clock (for up-/down-sampling), and the delay jitter (for buffering).

[Hughes]

The reply is helpful, Thanks！
the real-time clock is the system clock of the player, is it? does VLC use gettimeofday() as the real-time clock?

in 13818-1, the end-to-end delay from the signal input to an encoder to the signal output from a decoder is a constant. This delay is the sum of encoding, encoder buffering, multiplexing, communication or storage, demultiplexing, decoder buffering, decoding, and presentation delays.
one question:
1.Player (VLC), how to calculate the constant end-to-end delay?

I know, in TS (Transport stream), using PCR, the decoder have a system clock whose frequency match the system clock of the encoder。
but in Raw RTP (not TS/RTP),Does Player (VLC) have a system clock whose frequency match the system clock of the encoder?

[Rémi Denis-Courmont]

The real-time clock is system-dependent, typically the system uptime. VLC does not compute the end-to-end delay - that's totally useless.

[Hughes]

Can you give me an example, how to use the system uptime, and the NTP?

Precondition:
Player's system uptime is 100,the frequency is 1.
Three Video Frames, their NTP is 80,90,100.
Five Audio Samples, their NTP is 80,85, 90,95,100.

Conclusion:
system uptime:?
the Video output:?
the audio output:?

thinks!

[Rémi Denis-Courmont]

I don't understand the question.

[Hughes]

I mean:
when player's system uptime is 100, it play a video frame and an audio sample whose NTP is 80.
the video frame and the audio sample whose NTP is 90 will be played when play's system uptime is 110, Is this right?

thanks for your help!

[Rémi Denis-Courmont]

For the last time: NTP clock and VLC clock are NOT IN SYNC. EVER.