สารบัญ
การตั้งค่าเครื่องเล่นสตรีม UDP บนเครื่องส่งสัญญาณวิดีโอและตัวรับสัญญาณไร้สาย COFDM HDMI
UDP Stream Player เป็นทางออกที่ดีที่สุดสำหรับตัวเข้ารหัสวิดีโอแบบอะนาล็อก CVBs ที่ต่ำที่สุด. ตัวรับสัญญาณวิดีโอไร้สาย COFDM VCAN1776-RX เฟิร์มแวร์เริ่มต้นรองรับผู้เล่น RTSP. ลูกค้าบางรายจำเป็นต้องใช้โปรโตคอล UDP.
สามารถกำหนดค่าที่อยู่ IP และหมายเลขพอร์ตได้บนหน้าเว็บ, http://192.168.0.215 (ค่าเริ่มต้น)
- หลังจากอัพเกรดเฟิร์มแวร์, จุดสิ้นสุดที่ได้รับจะคืนค่าพารามิเตอร์เริ่มต้นจากโรงงาน (ความถี่กลาง: 320เมกะเฮิรตซ์, แบนด์วิดธ์ไร้สาย: 6เมกะเฮิรตซ์, ที่อยู่ IP ของพอร์ตเครือข่าย: 192.168.0.215), ลูกค้าจำเป็นต้องปรับเปลี่ยนความถี่กลางและแบนด์วิดท์ผ่าน เครื่องมือบอร์ดการกำหนดค่าพารามิเตอร์, และเครื่องส่งสัญญาณจะประหยัดอย่างสม่ำเสมอ.
- ลูกค้าเข้าถึงเว็บเซิร์ฟเวอร์ตัวรับสัญญาณผ่านหน้าเว็บ (HTTP://192.168.0.215), และปรับเปลี่ยนที่อยู่ IP ของตัวเองและการตั้งค่าที่อยู่ IP ของ Windows PC End ที่เชื่อมต่อกับตัวรับสัญญาณ:
บันทึก: ในหมู่พวกเขา, IP ในพื้นที่เป็น IP ของตัวรับสัญญาณเอง, และ IP ระยะไกลคือ Docking Windows PC End IP. ลูกค้าสามารถกำหนดค่าได้ตามสถานการณ์จริงของเขา. โปรดทราบว่าการดัดแปลงจะมีผลหลังจากรีสตาร์ทตัวรับสัญญาณเท่านั้น.
ดาวน์โหลดเครื่องเล่น UDP สเพลเยอร์
- ดาวน์โหลดเครื่องเล่น UDP สเพลเยอร์.
- Splayer_v4.2_2020.6.6
- https://drive.google.com/file/d/1ihzUhfnx2Wo3zLO8UAs1aUQeLswonJD-/view?usp=sharing
- สเพลเยอร์_v4.3_2022.10.22
- https://drive.google.com/file/d/1PQc-LZ55qGnjeMsjkHYSloHfY3NEUsGH/view?usp=drive_link
- Splayer_v4.3.1_2024.4.16
- https://drive.google.com/file/d/1uv7GqP8P4r6qGOWJ5gYn0b8bZ4ptL8H6/view?usp=drive_link
- Splayer_qt_v1.0 สำหรับ win10 หรือ win11
- https://drive.google.com/file/d/1VAegQjd-PmIL2XbJf7K8dnujMxhoIuhd/view?usp=drive_link
- splayer_qt_v1.1.1 สำหรับ win10 หรือ win11
- https://drive.google.com/file/d/1YMr2xxurGnbIBjFihc7f77afrdbOcc6l/view?usp=drive_link
- splayer_qt_v2.0
- https://drive.google.com/file/d/1sASbARCL1lXAIsVKqkmEObRGPREbaSES/view?usp=drive_link
- เปิดเครื่องเล่น Splayer บนพีซี Windows, คลิกปุ่มการตั้งค่าที่มุมล่างขวา, และหน้าการตั้งค่าจะปรากฏขึ้น:
บันทึก:
- จะเห็นได้ว่าหมายเลขพอร์ตถูกตั้งค่าเป็น 1234, ซึ่งเป็นรหัสที่ยากโดยโปรแกรมการสตรีม UDP ของตัวรับสัญญาณและไม่สามารถแก้ไขได้;
- ในคอลัมน์ถอดรหัส, กำหนดค่าตามคุณสมบัติสตรีมวิดีโอปัจจุบัน, เช่นการกำหนดค่าสตรีมวิดีโอความล่าช้า H264 ดังกล่าวข้างต้น;
- หลังจากตั้งค่าและคลิกไฟล์ “ยืนยัน” ปุ่มเพื่อบันทึกพารามิเตอร์, คลิกปุ่มเล่นที่มุมล่างซ้าย. หลังจาก Windows PC ได้รับสตรีมพุช UDP, มันจะถอดรหัสและเล่นทันที.

การตั้งค่าเครื่องเล่นสตรีม UDP ข้างต้นเหมาะสำหรับรุ่นด้านล่าง.
มันรองรับ Linux VLC Player ได้อย่างไร? เล่นสตรีมความล่าช้าต่ำภายใต้ Linux?
คำถาม: ตอนนี้สตรีม UDP ไม่ได้เล่นกับเครื่องเล่น VLC. ฉันต้องเล่นสตรีม UDP นี้ภายใต้ Linux และฉันพยายามเข้าใจรายละเอียดของสตรีมนี้. สคริปต์หรือกุญแจหรือสิ่งอื่นใด?
ฉันต้องการสร้างผู้เล่นของตัวเองภายใต้ Linux และฉันต้องการเข้าใจรายละเอียดของสตรีมวิดีโอ UDP นี้จาก demodulator.
หากเป็นสตรีมวิดีโอ UDP ปกติ, จากนั้นถามว่าทำไมมันถึงไม่เล่นกับ VLC หรือ OBS Studio.
ตอบ: สำหรับรุ่น VCAN1726-RX, เรามีเฟิร์มแวร์สองตัวสำหรับตัวเลือก, เฟิร์มแวร์แรกสำหรับผู้เล่น RTSP รองรับผู้เล่น VLC, แต่ลูกค้าบางรายกล่าวว่ามีความล่าช้าที่ยาวนาน, ดังนั้นเราจึงสร้างเฟิร์มแวร์ที่สอง, UDP ออกอากาศที่ Splayer, ซึ่งรองรับเวลาแฝงที่ต่ำกว่า.
สตรีมเสียงและวิดีโอ UDP นี้เป็นรูปแบบที่กำหนดเองของเรา, ดังนั้น VLC จึงไม่สามารถอธิบายได้. หากลูกค้าของคุณต้องการเปิดผู้เล่นของตัวเอง (ภายใต้ Linux), ขณะนี้มีสองตัวเลือก:
- อัปเดตการเข้าถึงสตรีม RTSP เริ่มต้น (เฟิร์มแวร์แรกสำหรับเครื่องเล่น RTSP)
- เราให้บริการไลบรารีและกิจวัตร Demux ที่สอดคล้องกัน (เราจำเป็นต้องเข้าใจสภาพแวดล้อม Linux ของลูกค้าเพื่อรวบรวมไฟล์ไลบรารีที่เหมาะสม)
- นี่คือ “ห้องสมุดและกิจวัตร Demux” เขียนโดยวิศวกรของเราภายใต้ Ubuntu 14.04 64ระบบบิต
ประเภทที่สองยากเกินไปสำหรับลูกค้าทั่วไป, และเราไม่ทราบความสามารถในการพัฒนาของผู้เล่นของลูกค้าของคุณเอง.
เนื่องจากลูกค้าบางรายพบกับปัญหาเวลาแฝงต่ำที่ Windows OS VLC Player, ไม่ว่าเราจะทดสอบอย่างไรที่นี่, เราไม่พบปัญหานี้. ในขณะนั้น, คุณใช้หน้าต่างเพื่อทดสอบ. บางทีถ้ามันเปลี่ยนเป็น Linux, จะไม่มีปัญหาการสตรีม RTSP. โปรดลองทดสอบตัวอย่าง VCAN1726 ด้วยเฟิร์มแวร์เวอร์ชันแรกบน Linux. บางทีนี่อาจไม่ใช่ปัญหาใน Linux OS.
คำถาม: คุณสามารถสร้างอิมเมจนักเทียบท่าสำหรับแอปพลิเคชันนี้ได้ไหม? พอร์ตใดที่ใช้สำหรับสตรีมที่เข้ามา, และอีกพอร์ตสำหรับสตรีมขาออกที่มีตัวแปลงสัญญาณที่ใช้กันอย่างแพร่หลาย (H264)?
Splayer และเครื่องเล่นสตรีม UDP คืออะไร?
Splayer เป็นเครื่องเล่นสื่อที่รองรับรูปแบบวิดีโอต่างๆ, รวมถึงการสตรีม UDP.
การสตรีม UDP เป็นวิธีการส่งข้อมูลวิดีโอผ่านอินเทอร์เน็ตโดยใช้โปรโตคอล DataGram ผู้ใช้ (UDP), ซึ่งเป็นโปรโตคอลที่รวดเร็วและง่ายดายที่ไม่รับประกันการจัดส่งหรือสั่งซื้อแพ็กเก็ต.
การสตรีม UDP สามารถใช้สำหรับการถ่ายทอดวิดีโอสดหรือการส่งวิดีโอความล่าช้าต่ำ, แต่ก็อาจประสบกับการสูญเสียแพ็คเก็ตหรือการทุจริต.
ตามผลการค้นหาเว็บ, Splayer สามารถเล่นสตรีม UDP ได้โดยใช้ขั้นตอนต่อไปนี้:
- เปิด Splayer แล้วคลิกที่ “เปิด URL” ปุ่มที่มุมขวาบน.
- ป้อน URL ของสตรีม UDP ในรูปแบบ UDP://@ip: ท่าเรือ, ที่ที่อยู่ IP คือที่อยู่ IP ของเซิร์ฟเวอร์และพอร์ตคือหมายเลขพอร์ตของสตรีม. ตัวอย่างเช่น, UDP://@224.0.0.1:1234.
- คลิกที่ “ตกลง” ปุ่มและรอให้สตรีมโหลด.
Splayer ทำงานได้ดีอย่างไรสำหรับ win10?
คำถาม: เราไม่สามารถเริ่ม Splayer ได้ 4.2 และ 4.3 ใต้ Windows 10. คุณช่วยจัดหา Splayer เวอร์ชันที่ถูกต้องให้เราได้ไหม 10 และ 11?
4.2 เริ่มต้นและปิดในขณะนี้. 4.3 เริ่มต้นด้วยข้อความแสดงข้อผิดพลาด.
ชื่อแอปพลิเคชันที่ผิดพลาด: Splayer.exe, รุ่น: 1.0.0.1, ตราประทับเวลา: 0x646d83e2
ชื่อโมดูลข้อบกพร่อง: dvb_demux.dll, รุ่น: 1.0.0.1, ตราประทับเวลา: 0x5fe5bdbf
รหัสยกเว้น: 0xc0000005
ชดเชยความผิดพลาด: 0x0001484a
รหัสกระบวนการที่ผิดพลาด: 0x3888
เวลาเริ่มต้นแอปพลิเคชันที่ผิดพลาด: 0X01DA1164B89C78EB
เส้นทางแอปพลิเคชันที่ผิดพลาด: C:\Users\admin\Downloads\Splayer_v4.3_2022.10.22\Splayer.exe
เส้นทางโมดูลที่ผิดพลาด: C:\Users\admin\Downloads\Splayer_v4.3_2022.10.22\dvb_demux.dll
รายงานรหัส: 4AF19407-045E-48E5-A0F7-86FC90C6B3D3
แพ็คเกจข้อบกพร่องชื่อเต็ม:
ID แอปพลิเคชันที่เกี่ยวข้องกับแพ็คเกจที่ผิดพลาด:
ตอบ: โปรดลองใช้ splayer_qt_v1.0.zip ของเรา (103.5Mb).
ข้อเสนอแนะ: Splayer เวอร์ชันใหม่ทำงานได้ดีที่ไซต์ปัญหาด้วยการชนะ 10! ขอบคุณ!
คำถาม: เราพบว่าการหน่วงเวลาเพิ่มขึ้นในขณะที่เล่นวิดีโอจากโปรแกรม Reciver by Splayer (สตรีม UDP).
ถ้าพูดในรายละเอียด – ตัวรับสัญญาณเชื่อมต่อกับสายเคเบิลอีเธอร์เน็ตโดยตรงกับพีซี. พีซีและตัวรับสัญญาณอยู่ในเครือข่ายท้องถิ่นเดียวกัน. เมื่อเราเริ่ม Splayer การหน่วงเวลาเป็นเรื่องปกติและการนับที่แม่นยำจะแสดงให้เราเห็น 330 MSEC, ซึ่งเป็นมากกว่าหนึ่งเล็กน้อยจากเอาต์พุต HDMI ที่เราสังเกต 270 MSEC. เป็นสิ่งที่ดี. แต่ถ้าเรารอไม่กี่นาทีโดยไม่มีการเปลี่ยนแปลงใด ๆ ในที่ทำงานเราจะสังเกตเห็นการเพิ่มขึ้นอย่างต่อเนื่องในเวลาที่ล่าช้า 1-1,5 ก.ล.ต. ซึ่งไม่เป็นที่ยอมรับในแอปพลิเคชันลูกค้า.
เมื่อวานฉันทดสอบด้วยตัวเองเมื่อชนะ 10, และ win11 บนพีซีที่แตกต่างกันด้วยการปิดการปิดแบรนเมอร์ที่ซับซ้อนด้วย Splayer qt (เวอร์ชันสุดท้ายจากคุณ), และ splayer 4.3 (เวอร์ชันเก่า). ฉันทำซ้ำปัญหานี้ทุกครั้งในการกำหนดค่าใด ๆ.
โปรดช่วยฉันแก้ไขปัญหานี้. เราต้องการเวลาหน่วงเวลาอย่างต่อเนื่องจากการเล่น splayer ซึ่งอาจไม่มากไปกว่า 350 MSEC.
ตอบ: ปัญหาดังกล่าวไม่ควรเกิดขึ้น, เพราะผู้เล่นไม่มีแคชในโหมดความล่าช้าต่ำ, และความล่าช้าอย่างสมบูรณ์ขึ้นอยู่กับความสามารถในการถอดรหัสของพีซี. วิศวกรจะตั้งค่าสภาพแวดล้อมและทดสอบในวันจันทร์หน้า.
อีกประเด็นหนึ่งคือขอให้ลูกค้าตรวจสอบการตั้งค่าอัตราการรีเฟรชของจอภาพแล็ปท็อปของพวกเขา. ตัวอย่างเช่น, หากกล้องป้อน 1080p60, จากนั้นอัตราการรีเฟรชของจอภาพแล็ปท็อปของลูกค้าจะต้องเป็น 60Hz. มิฉะนั้น, จอแสดงผลจะช้าเกินไป, ซึ่งจะทำให้เกิดความแออัดของข้อมูลและแนะนำความล่าช้า.
ผู้เล่น Slayer มีความล่าช้าอย่างมาก, การถอดรหัสนั้นช้าหรือจอแสดงผลช้า, มันเกิดจากพีซีทั้งหมด.
กล้อง HDMI เข้ารหัสตัวรับสัญญาณ HDMI, เอาต์พุตไปยังจอแสดงผล, และการทดสอบการล่าช้าในการเล่นคอมพิวเตอร์ของเครื่องเล่น Splayer


เราไม่พบปัญหาที่คุณพูดถึง.
จะเห็นได้ว่าหน้าจอเครื่องเล่น Splayer ปัจจุบันและเอาต์พุต HDMI ของตัวรับสัญญาณนั้นสอดคล้องกัน, และความล่าช้าระหว่างพวกเขาต่ำมาก.
คุณช่วยถามลูกค้าได้ไหม, ความละเอียดและอัตราเฟรมของอินพุตกล้องคืออะไร? สมมติว่ากล้องของลูกค้าคือ 1080p60, นอกจากนี้คุณยังสามารถทำสองขั้นตอนต่อไปนี้เพื่อแก้ไขปัญหาเพิ่มเติม:
- ให้ลูกค้าเปลี่ยนกล้องเป็นอัตราเฟรมที่ต่ำกว่าสำหรับการทดสอบ, เช่น 1080p50/30;
- คุณสามารถตั้งค่าพารามิเตอร์เซ็กเมนต์การเข้ารหัสเพื่อให้การเข้ารหัสเฟรมลง. ตัวอย่างเช่น, ส่งคำสั่ง atso0,30_ ผ่านพอร์ตพารามิเตอร์, และการเข้ารหัสเอาต์พุต 1080p30 สำหรับการทดสอบ.
บันทึก:
- Splayer ได้รับการพัฒนาโดยเฉพาะสำหรับโปรโตคอลสตรีมมิ่งที่เป็นกรรมสิทธิ์/กำหนดเองของเรา และในปัจจุบันไม่รองรับการแยกวิเคราะห์หรือเล่นโปรโตคอล MPEG-TS มาตรฐาน.
- ปัจจุบัน Splayer มีให้บริการเฉพาะบน Windows เท่านั้น. เวอร์ชัน Linux และ Android ยังไม่ได้รับการพัฒนาและยังไม่รองรับในขั้นตอนนี้.
- นอกจากนี้, ไม่ใช่โปรโตคอล mpeg-ts ที่ทำให้เกิดความล่าช้าเพิ่มขึ้น. แม้ว่าจะเปลี่ยนไปใช้โปรโตคอลที่เรากำหนดเองก็ตาม, ความล่าช้าจะไม่ลดลง (โปรโตคอลแบบกำหนดเองของเราจะทำการตรวจสอบ CRC กับแพ็กเก็ตข้อมูลทั้งหมดเป็นหลัก, ในขณะที่โปรโตคอล mpeg-ts ไม่มี, ซึ่งเป็นความแตกต่างที่ใหญ่ที่สุดระหว่างโปรโตคอล). ผลกระทบที่ใหญ่ที่สุดต่อเวลาแฝงคือการประมวลผลการถอดรหัสวิดีโอและการแสดงผลในเครื่องเล่น. ผู้เล่น Splayer ของเราจะได้รับการปรับให้เหมาะกับสถานการณ์การใช้งานการส่งภาพ.
- แม้ว่าลูกค้าจะได้รับไลบรารี demux ของเราและแยกสตรีมเสียงและวิดีโอก็ตาม, มันยังต้องทำการถอดรหัสวิดีโอและแสดงผลด้วยตัวเอง. ลูกค้าธรรมดารายนี้ไม่มีความสามารถนี้. ลูกค้าส่วนใหญ่จะใช้เฉพาะเครื่องเล่นโอเพ่นซอร์สเท่านั้น (เช่นอิงจาก gstreamer), และความล่าช้าของวิดีโอของผู้เล่นโอเพ่นซอร์สเหล่านี้จะไม่ดี. หากคุณต้องการดีเลย์วิดีโอที่ดี, โดยพื้นฐานแล้วคุณต้องพัฒนานักเตะของคุณเอง.
- หากลูกค้ายืนยันในไลบรารี demux และบอกว่าเขามีความสามารถในการจัดการกับการถอดรหัสและการเล่นวิดีโอในภายหลัง, ฉันยังสามารถร่วมมือกับคุณได้ (แต่เราจัดเตรียมเฉพาะไลบรารี demux และรูทีนภายใต้ Linux/android เท่านั้น, และไม่ให้การสนับสนุนการถอดรหัสและการแสดงผลในภายหลัง)
- โปรโตคอลแบบกำหนดเองของเราปรับปรุงการตรวจสอบ CRC เป็นหลักเพื่อจัดการกับข้อผิดพลาดในการส่งได้ดียิ่งขึ้น, ซึ่งช่วยป้องกันปัญหาการถอดรหัสวิดีโอที่ไม่คาดคิด หรือแม้แต่ปัญหาของเครื่องเล่นที่เกิดจากแพ็กเก็ตข้อมูลที่เสียหาย. โปรโตคอล demuxing นั้นไม่ได้ทำให้เกิดเวลาแฝงที่มีนัยสำคัญ, ไม่ว่าจะเป็นโปรโตคอลแบบกำหนดเองของเราหรือโปรโตคอล MPEG-TS มาตรฐาน. ปัจจัยหลักที่ส่งผลต่อเวลาในการตอบสนองคือขั้นตอนการถอดรหัสและการเรนเดอร์ในภายหลัง. โดยทั่วไปแล้ว:
- เนื่องจากการสตรีม UDP และการถอดรหัส/การเรนเดอร์เครื่องเล่นเป็นกระบวนการแบบอะซิงโครนัส, ผู้เล่นส่วนใหญ่จะแนะนำการบัฟเฟอร์จำนวนหนึ่งก่อนที่จะเริ่มเล่น. ยิ่งบัฟเฟอร์มีขนาดใหญ่เท่าไร, ยิ่งเวลาแฝงสูงขึ้นเท่านั้น.
ตัวอย่างเช่น, โดยทั่วไปแล้วเครื่องเล่นสื่อ VLC จะใช้การบัฟเฟอร์ที่ค่อนข้างใหญ่, และขนาดบัฟเฟอร์อาจเพิ่มขึ้นแบบไดนามิกระหว่างการเล่น. ในทางตรงกันข้าม, Splayer รักษาบัฟเฟอร์การเล่นโดยเจตนาให้มีขนาดเล็กมากเพื่อลดเวลาแฝง. - การถอดรหัสวิดีโอและการเรนเดอร์เฟรมก็เป็นกระบวนการอะซิงโครนัสเช่นกัน. หากการเรนเดอร์ไม่สามารถทันเวลาได้, เฟรมวิดีโอที่ถอดรหัสอาจสะสมอยู่ในคิวการเรนเดอร์, ซึ่งแนะนำเวลาแฝงเพิ่มเติมคล้ายกับการบัฟเฟอร์ล่วงหน้าการถอดรหัส. Splayer ยังได้รับการปรับให้เหมาะสมในพื้นที่นี้เพื่อลดการสะสมเฟรมและรักษาการเล่นที่มีเวลาแฝงต่ำ.
- เนื่องจากการสตรีม UDP และการถอดรหัส/การเรนเดอร์เครื่องเล่นเป็นกระบวนการแบบอะซิงโครนัส, ผู้เล่นส่วนใหญ่จะแนะนำการบัฟเฟอร์จำนวนหนึ่งก่อนที่จะเริ่มเล่น. ยิ่งบัฟเฟอร์มีขนาดใหญ่เท่าไร, ยิ่งเวลาแฝงสูงขึ้นเท่านั้น.
- โปรโตคอลแบบกำหนดเองของเรายังรวมถึงการเพิ่มประสิทธิภาพเพิ่มเติมหลายประการ, ซึ่งเป็นสาเหตุที่ท้ายที่สุดเราจึงตัดสินใจนำมาใช้แทนการใช้โปรโตคอล MPEG-TS มาตรฐานต่อไป (ซึ่งเราใช้แต่แรกเริ่ม):
- เปรียบเทียบกับโปรโตคอล MPEG-TS มาตรฐาน, โปรโตคอลแบบกำหนดเองของเราช่วยลดค่าใช้จ่ายของโปรโตคอลที่ซ้ำซ้อนและปรับปรุงการใช้แบนด์วิดท์ไร้สาย. นี่เป็นสิ่งสำคัญอย่างยิ่งสำหรับลิงก์ไร้สายที่มีแบนด์วิธจำกัด เช่น ระบบส่งสัญญาณวิดีโอ COFDM.
- โปรโตคอลแบบกำหนดเองของเราให้ความยืดหยุ่นที่มากขึ้นสำหรับการมัลติเพล็กซ์ข้อมูลประเภทต่างๆ. นอกจากภาพและเสียงแล้ว, สามารถห่อหุ้มข้อมูลพอร์ตอนุกรมและสตรีมข้อมูลที่ผู้ใช้กำหนดอื่นๆ ได้อย่างสะดวก, ทำให้มีความยืดหยุ่นและขยายได้ง่ายกว่า MPEG-TS มาตรฐาน.
- โปรโตคอลแบบกำหนดเองของเรารองรับการเข้ารหัสและถอดรหัส AES แบบรวมโดยตรงภายในชั้นโปรโตคอล. สิ่งนี้มีประโยชน์อย่างยิ่งสำหรับลิงค์ไร้สายที่ไม่รองรับการเข้ารหัส AES โดยกำเนิด, เช่นการเชื่อมต่อ Wi-Fi มาตรฐาน.
- นอกจากนี้, โปรโตคอลแบบกำหนดเองของเราได้รับการออกแบบมาโดยเฉพาะสำหรับสถานการณ์การส่งข้อมูลที่มีความหน่วงต่ำและมีความน่าเชื่อถือสูง, ช่วยให้สามารถเพิ่มประสิทธิภาพที่เข้มงวดยิ่งขึ้นตลอดทั้งการส่งและการเล่นไปป์ไลน์เมื่อเปรียบเทียบกับโปรโตคอลมาตรฐานทั่วไป.
ญาติ



ถามคำถาม
ข้อความของคุณถูกส่งแล้ว