RTP timestamp شمارندهٔ زمانِ رسانه در واحدِ قراردادِ همان جریان است؛ آن را مستقیم ساعت و تاریخ نخوانید. برایِ وصل‌کردنِ آن به یک مبنایِ دیگر، به رابطهٔ ساعت‌ها و شاهدِ هم‌بستگی نیاز داریم. Sender Report در RTCP می‌تواند یک جفتِ زمانِ مرجع و timestampِ متناظر بدهد. این تمرین فقط نگاشتِ عددیِ یک جفتِ ساختگی را حساب می‌کند؛ شبکه و هم‌زمان‌سازیِ واقعی اجرا نشده‌اند.
شمارهٔ بسته با زمانِ رسانه فرق دارد
sequence number ترتیبِ بسته را پیگیری می‌کند؛ timestamp به ساعتِ رسانه مربوط است. دو فیلد را برایِ محاسبهٔ مدت به جایِ هم نگذارید. حتی اندازهٔ گامِ timestamp باید با کدک و قراردادِ جریان خوانده شود؛ از تعدادِ بایتِ payload یا اسمِ کلیِ صوت، واحدِ ساعت را حدس نمی‌زنیم.
در مثالِ خودمان ساعت را۸۰۰۰تیک در ثانیه اعلام کرده‌ایم و منبع را owned-demo می‌نامیم. زمانِ مرجعِ۱۰۰۰ثانیه یک عددِ فرضیِ آموزشی است، نه ساعتِ یک تماسِ ضبط‌شده. هیچ ادعایی دربارهٔ خطایِ ساعتِ سیستم، منطقهٔ زمانی یا دقتِ UTC از این عدد نداریم.
لنگرِ ساختگی چگونه نگاشت می‌سازد؟
لنگرِ اول timestampِ برابر با 2^32−160 را به زمانِ مرجعِ۱۰۰۰ وصل می‌کند. بستهٔ بعدی۳۲۰تیک جلوتر است؛ شمارندهٔ۳۲بیتی دور می‌زند و عددِ ذخیره‌شده‌اش۱۶۰ می‌شود. تفریقِ سادهٔ۱۶۰منهایِ عددِ بزرگِ قبلی منفیِ بزرگی می‌دهد، اما اختلافِ پیمانه‌ایِ نزدیک۳۲۰ است.
۳۲۰تقسیم‌بر۸۰۰۰ برابرِ۰٫۰۴ثانیه است؛ بنابراین زمانِ نگاشت‌شده در همین فرض۱۰۰۰٫۰۴ می‌شود. کد هم مقدارِ کسریِ دقیقِ۲۵۰۰۱÷۲۵ و هم نمایشِ اعشاری را ثبت می‌کند. این چهارصدم، تأخیرِ شبکه یا زمانِ ورودِ بسته نیست؛ اختلافِ زمانِ رسانه نسبت به لنگرِ انتخاب‌شده است.
حسابِ پیمانه‌ای هم فرض دارد
تابع نزدیک‌ترینِ اختلافِ علامت‌دار را انتخاب می‌کند؛ یعنی از قبل فرض کرده‌ایم فاصلهٔ موردِ نظر کمتر از نصفِ یک دور است. خودِ timestampِ تنها این فرض را ثابت نمی‌کند. در فاصلهٔ دقیقاً نصفِ دور، جهت مبهم است و برنامه صریحاً خطا می‌دهد؛ گذشتِ چند دور یا توقفِ طولانی در این نسخه حل نشده است.
| وضعیتِ تمرین | نتیجهٔ واقعی |
|---|---|
| لنگرِ هم‌منبع و اختلاف۳۲۰تیک | نگاشت به۱۰۰۰٫۰۴ |
| لنگر نداریم | null؛ زمانِ مطلق حدس زده نمی‌شود |
| منبعِ دیگر یا ساعتِ صفر | خطایِ قرارداد |
| اختلافِ نصفِ دور | ردِ ابهامِ جهت |
دو لنگر چه کنترلِ بیشتری می‌دهند؟
در لنگرِ دومِ ساخته‌شده، زمانِ مرجع۱۰۰۱ و timestamp به اندازهٔ۸۰۰۰تیک جلوتر است. نسبتِ دو اختلاف دقیقاً۸۰۰۰تیک در ثانیه می‌شود. این کنترل، سازگاریِ دو عددِ ایده‌آلِ نویسنده را تأیید می‌کند؛ تخمینِ رانشِ ساعت از دادهٔ واقعی یا تضمینِ ثابت‌بودنِ نرخ در آینده نیست.
مرجعِ RTCP جفتِ زمان‌ها را برایِ هم‌بستگی و هم‌زمانی توضیح می‌دهد، اما دقتِ عددِ مرجع باید جدا ارزیابی شود. داشتنِ فیلدِ NTP به‌تنهایی اثبات نمی‌کند دستگاه از منبعِ دقیقِ ساعت همگام شده است. همچنین timestampِ گزارش لزوماً برابرِ timestampِ نزدیک‌ترین بستهٔ رسانه نیست.
برایِ گزارشِ واقعی چه چیزهایی را کنارِ هم نگه داریم؟
شناسهٔ منبع، واحدِ ساعت، جفتِ لنگرها، محلِ ثبت و فرضِ بازکردنِ دور را ثبت کنید. این کد RTCP باینری را parse نمی‌کند، SR جعلی را تشخیص نمی‌دهد و مبنایِ زمانیِ دو دستگاه را معتبر نمی‌سازد. خطایِ ورود، اتلاف و ترتیبِ دریافت هم مسئلهٔ دیگری است و نباید از این نگاشت به دست آورده شود.
دفترِ جیتر و مهلتِ پخش زمانِ ورود و برنامهٔ پخش را جدا بررسی می‌کند. برایِ پروژهٔ منشیِ تلفنیِ اپرا، نقطهٔ تحویل و معیارِ سنجشِ تأخیر را با تیم روشن کنید؛ زمان‌هایِ این تمرین، اندازه‌گیریِ محصول یا تماسِ واقعی نیستند.
فایل تمرین و منبع
با لنگرِ ساختگی، عبور از دورِ۳۲بیتی را حساب کنید · تفریقِ ساده و پیمانه‌ای، زمانِ نگاشت و سه ورودیِ ردشده
منابع در 2026-11-04 خوانده شدند؛ این تاریخ، تاریخ انتشار منبع نیست. مثال‌ها و فایل‌های این راهنما آموزشی و ساختهٔ تحریریه‌اند.