README.md

metadata

title: 'On'
emoji: 🚀
colorFrom: purple
colorTo: red
sdk: docker
pinned: false
app_port: 7860

Reoo88/On — relay-v2.29-smart-mode

تثبيت الـcanvas على مقاس FLV الحقيقي في v2.45

أظهر القياس الدائم أن وصف مرشح TikTok قد يبقى على مقاس أقدم بينما ترويسة الفيديو الفعلية مختلفة: مثلًا 432x864 في الوصف مقابل 640x1280 في STREAM_CONFIG، و540x960 مقابل 720x1280. كان matchgop يثبّت الـcanvas من الوصف قبل أن يصل المقاس الحقيقي، فيصغر الخرج من أول البث ويبقى ثابتًا.

أصبح فحص المصدر الموجود قبل الإرسال يقرأ أول سجل AVC/HEVC ضمن بادئة محدودة (افتراضيًا 256 KiB و4 ثوانٍ، YOUTUBE_FLV_PROBE_BYTES/SECONDS). إذا احتوى مقاسًا صالحًا، تُحفظ probed_width/probed_height بجانب المرشح ويستخدمها lock_gold بدل الوصف. لا يتغير اسم الجودة أو تثبيت الـrendition. وإذا لم تظهر ترويسة مقاس ضمن الحد، يبقى قبول توقيع FLV والسلوك السابق بلا تغيير.

هذا تصحيح لاختيار الـcanvas فقط؛ لا يغيّر copy أو tee/global_header أو القص ومعدل البت، ولا يغيّر مهلة بدء YouTube أو الاسترداد. يغطي test_source_probe.py التجزئة، والترويسة غير الصالحة أصغر من 32px، وعدم إعادة كتابة وصف المرشح، وثبات المسار القديم عند غياب المقاس.

توحيد ترويسة H.264 مع الاستقبال المزدوج في v2.44

عند إعادة الترميز والنشر المتزامن إلى الاستقبالين الأساسي والاحتياطي عبر FFmpeg tee، يضيف المرسِل الآن -flags:v +global_header. بذلك يقرأ كل مستقبل سجل SPS/PPS نفسه منذ البداية بدل أن يلتقطا إعدادَي عرض مختلفين. الدليل الإنتاجي كان resolutionMismatch [error] Bad secondary stream مع تغيّر حجم الصورة المعروضة، وهو نمط يطابق حالة FFmpeg الموثقة ‎#11527 لواجهة tee مع يوتيوب.

لا يغيّر الإصلاح المقاس أو فلاتر القص أو معدل البت، ولا يضيف الترويسة إلى مسار copy الذي يحمل سجل المفكك الأصلي أصلًا. ويبقى النشر المفرد بلا تغيير. يغطي test_ingest_routes.py وجود الترويسة مع الترميز المزدوج وعدم إضافتها إلى النسخ.

تنظيف تلقائي عند غياب البث في v2.27

عند غياب أي بث بشكل كامل ومستمر لمدة YOUTUBE_IDLE_RESET_SECONDS (الافتراضي 600 ث = 10 دقائق) يصفّر المدير تلقائيًا — مرة واحدة في كل فترة خمول — بقايا حالة التكيّف المتراكمة في الذاكرة: أوضاع الترميز اللاصقة (matchgop) ومقاساتها، تثبيتات الجودة، قوائم المصادر غير المستقرة، الرصد المحفوظ، عدّادات التأجيل والجوع، ووجهات RTMPS المحفوظة (لتُعاد قراءتها طازجة من YouTube API عند البث التالي). الرصد نفسه لا يتوقف لحظة (24/7)، وعودة أي بث تعيد ضبط مؤقّت الخمول من الصفر. لا يُحذف أي ملف ولا تُمسّ بيانات دائمة: ربط القناة ومصادر الاستقبال القابلة لإعادة الاستخدام وإعدادات المشغّل والتوكنات كلها محفوظة — حذف سجل الأحداث (youtube-api-state.json) كان سيضيّع الربط، وسجلّ أحداث البث (stream_events.json) محدود أصلًا بسقف 10,000 سجل ويُقلَّم تلقائيًا. القيمة 0 تعطّل الميزة. يُوثَّق كل تنظيف بحدث IDLE_AUTOCLEAN وسطر [IDLE] في السجل.

حاكم أوضاع ذكي في v2.29

سياسة اختيار copy/الترميز صارت قرارًا مبنيًا على نوع العطل لا على اللصق الدائم:

• النسخ هو الأصل لأي مصدر AVC أو HEVC مُثبت (HEVC يُحمل Enhanced RTMP ‏hvc1 كما هو)، والترميز علاج موجّه فقط.
• يدخل الترميز لأعطال تستطيع المعالجة إصلاحها: ترميز/مقاس/GOP لا يقبله الاستقبال، noData بينما بايتات المصدر تتدفق فعلًا، رفرفة مقاس متكررة، رفض خرج متكرر، أو نسخة مُعلنة أكبر بكثير من معدل بتّها. أما videoIngestionStarved وحده فهو جوع بيانات — لا يفرض ترميزًا بعد الآن.
• يعود إلى النسخ تلقائيًا: بعد جولة ترميز مستقرة (افتراضيًا ≥60 ثانية وخرج مُسلَّم ≥20 ثانية) يُفحَص النسخ لأي مصدر مدعوم AVC/HEVC؛ إن صمد الخرج (افتراضيًا 15 ثانية) يُنسى وضع الترميز من الذاكرة ومن سجل الحدث وتُحرَّر خانة المعالج، وإن فشل الفحص يُحسَب ويُمنع الرفرفة. وضع يفرضه المشغّل صراحة لا يُفحَص ولا يُلغى.
• كانفس الترميز مسقوف عند فئة 720p افتراضيًا (‏YOUTUBE_TRANSCODE_MAX_SHORT/LONG)، فلا يخنق المعالجَ فكُّ HEVC عالٍ وإعادة ترميزه بحجمه الكامل؛ وضع fixed1080 الصريح للمشغّل لا يُسقَف.
• حاكم سرعة: ترميز يبقى أبطأ من الزمن الحقيقي (افتراضيًا <0.90 لمدة 30 ثانية بعد 20 ثانية خرج) يُنهى ناشره ويُفحَص النسخ بدل حرق الحدث كله خلف مرمّز متأخر (‏TRANSCODE_TOO_SLOW).
• كل انتقالات الحاكم تُسجَّل في سجل الأحداث والقياس الدائم (‏COPY_RECOVERY وTRANSCODE_TOO_SLOW)، وضبطها من YOUTUBE_COPY_RECOVERY* وYOUTUBE_TRANSCODE_*، وإلغاء العودة للنسخ بـYOUTUBE_COPY_RECOVERY=0.

قياس تشخيصي دائم في v2.28

أضافت هذه النسخة قياسًا للقراءة فقط: لا يغيّر وضع الإرسال ولا الجودة ولا المرمّز ولا مهلات الحارس ولا إعادة الاتصال، ولا تُقرأ نتائجه داخل أي قرار بث. تُجمَّع عدّادات كل جلسة FFmpeg في الذاكرة (سرعة/إطارات FFmpeg، معدل بايتات المصدر وعمر آخر بايت، تغيّرات المقاس/الترميز/معدل البت/GOP، أخطاء فتح المصدر مع رمز HTTP، أحداث صحة YouTube، وحمل CPU العام)، ويكتبها خيط مستقل كل دقيقة كنقاط تفتيش وعند نهاية الجلسة.

الكتابة إلحاقية فقط في telemetry/telemetry.jsonl داخل Storage Bucket نفسه (0600)، من دون روابط موقّعة أو مفاتيح أو كوكيز أو وسائط. لا يوجد في الكود أي سقف أو تدوير أو حذف أو تقليم لهذا الملف، والتنظيف الخامل لا يلمسه؛ يبقى إلى أن يُراجَع ويُحذف يدويًا بقرار صريح خارج مسار التشغيل. إذا تعطّل التخزين أو امتلأت قائمة القياس تُسقَط عيّنات القياس نفسها ولا يتأثر البث. يمكن إيقاف القياس وحده بـTELEMETRY_ENABLED=0، وقراءته من المسار المحمي GET /api/telemetry?limit=200&broadcaster=user. الهدف جمع أدلة كافية أيامًا قبل أي تعديل معالجة/ترميز لاحق مبني على قياس لا على افتراض.

منع تعليق بدء البث في v2.25

liveStarting وtestStarting ليستا رفضًا للاستقبال. بعد قبول طلب الانتقال يجب أن يبقى إرسال نفس الحدث والمصدر جاريًا حتى يؤكد يوتيوب الحالة النهائية. كان شرط الجاهزية يوقف المرسل في المرحلتين، فيبقى الحدث عالقًا بلا بيانات. الآن يُستأنف المرسل نفسه، مع فحص الصحة والملكية المعتاد، بلا تكرار transition أو إنشاء حدث جديد. مرحلتا created وcomplete/revoked تبقيان محميتين. الاختبار test_transition_ingest.py يغطي الرصد الجديد والحالة المخزنة والحالات النهائية.

استعادة استقبال يوتيوب في v2.24

عند فشل خرج RTMPS المتكرر تُجرّب نقطة الاستقبال الاحتياطية الآمنة لنفس مصدر يوتيوب، لا قناة أو مفتاحًا أو حدثًا جديدًا. لا يُستعمل مسار محفوظ بعد تبديل القناة أو معرّف المصدر. تبقى query الخاصة بالاحتياطي بعد المفتاح في الرابط الصحيح، وتبقى عناوين الإرسال ومفاتيحها في الذاكرة فقط.

فشل بدء الخرج يفعّل تشخيص تفاوض RTMP للمحاولة التالية، مع إخفاء playpath من رسالة Sending publish command حتى إن لم يظهر كـURL. رسائل النجاح NetStream.Publish.Start وFCPublish لا تُعتبر رفضًا للنشر. التشخيص لا يُغيّر توكنات أو إعدادات نشر المستخدم.

إصلاح انقطاع المصدر في v2.23

كان القارئ البديل يبدأ قبل مسح swap_source، فيخرج أحيانًا دون قراءة أي بايت، ثم يُعاد فتح المصدر مرارًا بينما يوتيوب يعرض noData. الآن يُوقف القارئ القديم أولًا، ولا يُعاد استعمال جسر FLV إذا بقي حيًا؛ تُمسح علامة التسليم قبل تشغيل القارئ الجديد. لكل قارئ إلغاء مستقل لمنع بايت متأخر من الجلسة السابقة.

• إغلاق CDN للاستجابة أو خطأ القراءة يجرّب مصدرًا بديلًا داخل نفس FFmpeg ونفس حدث يوتيوب قبل إعادة تشغيل الناشر.
• تُمنح الاستجابة الجديدة مهلة أول بايت قدرها ثانيتان (YOUTUBE_REATTACH_GRACE_SECONDS، حد أقصى 5 ث ونصف مهلة الصمت). لا يُحدّث عدّاد وصول البيانات وهميًا، ولا تُخفى أعطال خرج RTMP.
• أثناء إعادة التوصيل نجرّب رابطًا متوافق الترميز من رصد LIVE حديث (بحد أقصى 45 ث) بدل تجويع الناشر بانتظار طلبات بيانات تيك توك الطويلة. الرصد القديم أو غير المتوافق لا يُعتمد، وفحص انتهاء البث يبقى كما هو.
• ترويسة البداية 16×16 لا تثبّت كانفس التحويل الخفيف. عند غياب مقاس صالح يستعمل matchgop كانفس ثابتًا 720×1280؛ أما مسار نسخ AVC/HEVC الأصلي فلا يُعاد ترميزه بسبب هذه الرقعة.

test_source_reconnect.py يشمل جدولة يبدأ فيها القارئ فورًا، وقارئًا قديمًا لم يتوقف، وإيقاف المستخدم، وعدم تزوير العمر، والترويسة الصغيرة، واختبار HTTP + FFmpeg حقيقيين: إغلاقات متكررة وتأخير أول بايت، مع استمرار الساعة بنفس عملية الإرسال في وضعي copy وmatchgop. لا يستعمل الاختبار بثوثًا حقيقية.

رصد TikTok LIVE → FFmpeg → YouTube RTMPS. لا تسجيل محلي، لا أرشيف فيديو، ولا ملفات فيديو على القرص.

TikTok H.264 أو H.265/FLV
  → FLVBridge: تحويل HEVC القديم إلى Enhanced RTMP hvc1
  → تمرير سجل SPS/PPS أو VPS/SPS/PPS المحدّث في الجلسة نفسها
  → FFmpeg stream copy للفيديو (من دون فك/ترميز) + تطبيع AAC فقط
  → جلسة YouTube RTMPS نفسها

الدخول

افتح واجهة الـSpace وأدخل قيمة Secret المسمى PASSWORD؛ اسم المستخدم الداخلي ثابت admin. الواجهة العامة لا تعرض بيانات تشغيلية قبل الدخول. GET /health عام ومحدود بحالة الحياة والإصدار فقط، أما /api/* فمحمي.

لا تلصق توكن Hugging Face في الواجهة، ولا تضع أي توكن أو كوكي أو مفتاح بث داخل Git.

تغيير قناة يوتيوب بعد تدوير Secrets

1. حدّث GOOGLE_CLIENT_ID وGOOGLE_CLIENT_SECRET وYOUTUBE_REFRESH_TOKEN للقناة المطلوبة.
2. اضغط فحص OAuth والقناة: تظهر القناة المفوضة الجديدة والقناة السابقة إن اختلفتا. الفحص لا يعتمد التبديل وحده.
3. اضغط اعتماد القناة الجديدة فقط وأكّد اسمها ومعرّفها، إن أردت تبديل الربط دون بدء بث؛ أو تفعيل البث التلقائي مع تأكيد القناة لبدء الأتمتة.

لا يحذف التبديل أحداث القناة السابقة ولا يعدّلها عبر YouTube API: يوقف مرسلاتها، يؤرشف قيودها محليًا مع معرّف قناتها، ويُسقط مصادرها ومفاتيح RTMPS المخزنة في الذاكرة. الاعتماد وحده يترك الأتمتة معطلة عند التبديل. تبقى الحماية من تغيّر القناة غير المؤكد مفعلة، ولا حاجة لحذف youtube-api-state.json أو تفريغ التخزين.

إصلاح الواجهة: نتيجة الفحص منفصلة الآن عن قناة السجل؛ التحديث الدوري لا يعيد اختيار القناة القديمة. يعاد فحص OAuth قبل الاعتماد/التفعيل، ويُرفض الطلب إذا لم يطابق التفويض معرّف القناة الذي أكّدته.

كوكيز تيك توك

تُقبل قيمة sessionid، أو سطر Cookie كامل، أو تصدير الكوكيز بصيغة JSON. يستبعد محلل JSON الكوكيز المنتهية ونطاقات المواقع الأخرى ويختار كوكي www.tiktok.com الأكثر تخصيصًا عند تكرار الاسم. لا تُحفظ القيم في Git ولا تُعرض في الـAPI.

أسرار Hugging Face تتقدم على مخزن الواجهة: TIKTOK_SESSIONID يتقدم على TIKTOK_COOKIES. عند تدوير الجلسة، حدّث القيمتين إلى سطر الكوكيز الجديد نفسه، أو احذف السر القديم TIKTOK_SESSIONID واكتفِ بـTIKTOK_COOKIES؛ لا تترك سرًا قديمًا يحجب الكوكيز الجديدة. تاريخ sid_guard تقديري، والقبول الفعلي تقرره تيك توك وقد تنتهي الجلسة قبل هذا التاريخ.

حدود الموارد الموصى بها لـ CPU Basic

الصورة تضبط:

• MAX_CONCURRENT_RELAYS=4: أربع عمليات نشر كحد أعلى.
• YOUTUBE_MAX_EVENTS=4: أربعة أحداث يوتيوب كحد أعلى.
• YOUTUBE_LIGHT_MAX=0 وYOUTUBE_AUTO_TRANSCODE=0: لا تحويل فيديو في المسار الافتراضي. H.264 يُنسخ كما هو، وH.265 يُحمل بـEnhanced RTMP hvc1. يبقى كود x264 القديم خيار تشغيل يدويًا فقط ولا يدخل في إصلاح تبدل سجلات المفكك.

متغيرات إعدادات الـSpace تتقدم على Dockerfile. اترك سقفي الناشرين/الأحداث على 4، وراقب الشبكة وحكم YouTube؛ كلفة stream copy وAAC أقل كثيرًا من تحويلي x264 اللذين سبق أن أشبعا موردي CPU.

الاعتمادية

• تغيّر AVCDecoderConfigurationRecord أو HEVCDecoderConfigurationRecord لا يرمي FormatChanged ولا يقتل FFmpeg: يمر السجل الجديد قبل الإطار الذي يحتاجه عبر RTMPS المفتوح نفسه.
• FLVBridge يحافظ على بايتات الصورة وCTS، ويصل أزمنة DTS عند تجديد رابط HTTP-FLV من دون رأس FLV ثانٍ. سجل جديد كامل يحل محل السابق؛ لا تُخلط مجموعات قد تحمل IDs متعارضة.
• FFmpeg 7 ينقل تغيير extradata من demuxer إلى muxer ويعيد كتابة SequenceStart؛ يثبت الاختبار الحتمي ذلك لـH.264 وH.265.
• يسجل stream_monitor.py أحداث CODEC_CHANGE وRESOLUTION_CHANGE وBITRATE_CHANGE وKEYFRAME_CHANGE وSOURCE_CHANGE وRECONNECT وCONNECTION_ERROR وYOUTUBE_HEALTH في logs/stream_events.json داخل Storage Bucket، من دون وسائط أو روابط أو مفاتيح.
• إذا صمت رابط الجودة المثبت وبقي TikTok يعيد الرابط نفسه، يختار الجسر أقرب FLV أقل جودة من عائلة الترميز نفسها ويدخله في FFmpeg/RTMP المفتوح بدل ترك YouTube يتوقف. لا يقطع مصدرًا منخفضًا يعمل لمجرد تحسين الدقة؛ يعيد الجودة المفضلة فقط عند تجديد طبيعي لاحق بعد استقرار افتراضي قدره 300 ثانية (YOUTUBE_SOURCE_UPGRADE_SECONDS).
• يمكن قراءة آخر الأحداث من المسار المحمي GET /api/stream-events?limit=200&broadcaster=user، والملف محدود افتراضيًا إلى 10,000 سجل وصلاحيته 0600.
• إذا بقي خيط الإشراف حيًا ومات FFmpeg لسبب آخر، يعيد watchdog تدويره بدل بقاء YouTube في noData.
• روابط المصدر الموقعة تُرصد من جديد، مع حارس صمت افتراضي 12 ثانية. تُسحب صحة YouTube كل 20 ثانية أثناء الحدث وتدخل السجل. الوضع الافتراضي يمنع تحويل الفيديو؛ خيارات matchgop القديمة لا تعمل إلا إذا فعّلها المشغل ورفع YOUTUBE_LIGHT_MAX عمدًا.
• الحماية من تكرار مذيع واحد ومن خلط مذيعين على مفتاح RTMPS بيئي واحد مفعلة.
• الحالة والتوكنات تحفظ في Storage Bucket المركب على /data؛ كوكيز TikTok المخزنة تُكتب بصلاحية 0600.
• كوكي TikTok لا يُرسل إلى روابط CDN الموقعة خارج tiktok.com؛ طلبات الوسائط العامة تستعمل Referer فقط.
• سجلات الأحداث المهمة تذهب إلى stdout، بينما access log الدوري معطل لتسهيل التشخيص.

حد معروف: تبدل المقاس/الـprofile داخل الترميز نفسه مدعوم ومختبر. أما تبدل H.264↔H.265 على track واحد فيمثله الجسر بايتيًا من دون رمي استثناء، لكن FFmpeg 7 ينشئ له AVStream متأخرًا لا يدخل في خريطة الخرج المفتوحة. لذلك تُثبّت سياسة المصدر الترميز نفسه عند تجديد الرابط ولا تدّعي تبدلًا سلسًا بين codecين؛ دعمه الحقيقي يحتاج ناشر RTMP tag-level أو مسار Enhanced-RTMP متعدد المسارات واختبار قبول YouTube، لا دمج SPS/PPS ولا إعادة تشغيل مخفية.

تنبيه التشغيل جنبًا إلى جنب

إذا فُعّلت أتمتة OAuth هنا وعلى Reoo88/Tktktk بالقناة نفسها، قد يفتح التطبيقان حدثين للمذيع نفسه. شغّل الأتمتة في Space واحد لكل قناة، أو استخدم قنوات/مفاتيح مختلفة.

تحقق محلي

PASSWORD=test DATA_DIR="$(mktemp -d)" sh verify.sh

تفاصيل التشخيص، الأدلة، المخاطر، وخطة التشغيل: AUDIT_AR.md.

Privacy Policy & Terms

This application uses YouTube API Services to allow authenticated users to broadcast live content to their own YouTube channels.

• By using this app, users agree to be bound by the YouTube Terms of Service and Google Privacy Policy.
• We do not store or share personal user data with third parties.