Pengaturan pemutar aliran UDP Splayer untuk protokol aliran Penerima COFDM Vcan1776-RX

Pengaturan pemutar UDP Stream pada pemancar dan penerima video Nirkabel HDMI COFDM

Pemutar aliran UDP adalah solusi terbaik untuk encoder video analog CVBS latensi terendah. Penerima Video Nirkabel COFDM Vcan1776-RX firmware default mendukung pemutar RTSP. Beberapa klien perlu menggunakan protokol UDP.

Alamat IP dan nomor port dapat dikonfigurasi di halaman web, http://192.168.0.215 (kegagalan)

1. Setelah mengupgrade firmware, pihak penerima akan mengembalikan parameter default pabrik (frekuensi pusat: 320MHz, Bandwidth nirkabel: 6MHz, alamat IP port jaringan: 192.168.0.215), pelanggan perlu mengubah frekuensi pusat dan bandwidth melalui Alat Papan Konfigurasi Parameter, dan Pemancar menyimpan secara konsisten.

2. Pelanggan mengakses server web penerima melalui halaman web (HTTP://192.168.0.215), dan mengubah alamat IP-nya sendiri dan pengaturan alamat IP PC Windows yang terhubung ke penerima:

Catatan: Diantara mereka, IP lokal adalah ip milik penerima, dan IP jarak jauh adalah ip akhir PC Windows dock. Pelanggan dapat mengkonfigurasinya sesuai dengan situasi aktualnya. Perhatikan bahwa modifikasi hanya akan berlaku setelah receiver dihidupkan ulang.

Unduh pemutar UDP Pemain voli

3. Unduh pemutar UDP Pemain voli.
   • Player_v4.2_2020.6.6
   • https://drive.google.com/file/d/1ihzUhfnx2Wo3zLO8UAs1aUQeLswonJD-/view?usp=sharing
   • Player_v4.3_2022.10.22
   • https://drive.google.com/file/d/1PQc-LZ55qGnjeMsjkHYSloHfY3NEUsGH/view?usp=drive_link
   • Pemain_v4.3.1_2024.4.16
   • https://drive.google.com/file/d/1uv7GqP8P4r6qGOWJ5gYn0b8bZ4ptL8H6/view?usp=drive_link
   • Pemain_QT_V1.0 untuk Win10 atau Win11
   • https://drive.google.com/file/d/1VAegQjd-PmIL2XbJf7K8dnujMxhoIuhd/view?usp=drive_link
   • Pemain_QT_V1.1.1 untuk Win10 atau Win11
   • https://drive.google.com/file/d/1YMr2xxurGnbIBjFihc7f77afrdbOcc6l/view?usp=drive_link
   • Pemain_QT_V2.0
   • https://drive.google.com/file/d/1sASbARCL1lXAIsVKqkmEObRGPREbaSES/view?usp=drive_link
4. Buka pemutar Splayer di PC Windows, klik tombol pengaturan di pojok kanan bawah, dan halaman pengaturan akan muncul:

Catatan:

1. Dapat dilihat bahwa nomor port Port diatur ke 1234, yang dikodekan secara keras oleh program streaming UDP pada receiver dan tidak dapat dimodifikasi;
2. Pada kolom Dekode, konfigurasikan sesuai dengan properti streaming video saat ini, seperti konfigurasi streaming video latensi rendah H264 seperti di atas;

4. Setelah mengatur dan mengklik “Mengonfirmasi” tombol untuk menyimpan parameter, klik tombol putar di pojok kiri bawah. Setelah PC Windows menerima aliran push UDP, itu akan memecahkan kode dan segera memutar.

Pengaturan pemutar aliran UDP di atas cocok untuk model di bawah ini.

Bagaimana cara mendukung pemutar VLC Linux? Memutar streaming dengan penundaan rendah di Linux?

Pertanyaan: Sekarang aliran UDP tidak dapat diputar dengan pemutar VLC. Saya perlu memutar aliran UDP ini di Linux dan saya mencoba memahami detail aliran ini. Skrip atau kunci apa pun atau hal lainnya?

Saya ingin membuat pemutar sendiri di Linux dan saya ingin memahami detail aliran video UDP dari demodulator.

Jika itu adalah aliran video UDP biasa, lalu pertanyakan kenapa tidak bisa diputar di VLC atau OBS studio.

Menjawab: Untuk model Vcan1726-RX, Kami memiliki dua firmware untuk opsional, Firmware pertama untuk pemutar RTSP mendukung pemutar VLC, tetapi beberapa klien menyebutkan bahwa ini memiliki latensi yang panjang, jadi kami membuat firmware kedua, UDP disiarkan di Splayer, yang mendukung latensi lebih rendah.

Aliran audio dan video UDP ini adalah format khusus kami, jadi VLC tidak bisa menjelaskannya. Jika pelanggan Anda ingin membuka pemutarnya sendiri (di bawah Linux), saat ini ada dua pilihan:

1. Perbarui ke akses aliran RTSP default (firmware pertama untuk pemutar RTSP)
2. Kami menyediakan perpustakaan dan rutinitas DEMUX yang sesuai (kita perlu memahami lingkungan Linux pelanggan untuk mengkompilasi file perpustakaan yang sesuai)
3. Ini adalah “Perpustakaan dan rutinitas DEMUX” ditulis oleh teknisi kami di bawah Ubuntu 14.04 64sistem bit

Tipe kedua terlalu sulit bagi pelanggan biasa, dan kami tidak mengetahui kemampuan pengembangan dari pemain pelanggan Anda sendiri.

Karena beberapa klien menemui masalah latensi rendah di pemutar VLC OS Windows, tidak peduli bagaimana kami mengujinya di sini, kami tidak menemukan masalah ini. Pada waktu itu, Anda menggunakan Windows untuk menguji. Mungkin kalau diubah ke Linux, tidak akan ada masalah streaming RTSP. Silakan coba uji sampel Vcan1726 dengan firmware versi pertama di Linux. Mungkin ini bukan masalah di OS Linux.

Pertanyaan: Bisakah Anda membuat gambar buruh pelabuhan untuk aplikasi ini? Port mana yang digunakan untuk aliran masuk, dan port lain untuk aliran keluar dengan beberapa codec yang banyak digunakan (h264)?

Apa itu Splayer dan UDP Stream Player?

SPlayer adalah pemutar media yang mendukung berbagai format video, termasuk streaming UDP.

Streaming UDP adalah metode pengiriman data video melalui internet menggunakan User Datagram Protocol (UDP), yang merupakan protokol cepat dan sederhana yang tidak menjamin pengiriman atau pemesanan paket.

Streaming UDP dapat digunakan untuk siaran video langsung atau transmisi video latensi rendah, tetapi mungkin juga mengalami kehilangan paket atau kerusakan.

Menurut hasil pencarian web, SPlayer dapat memutar aliran UDP dengan menggunakan langkah-langkah berikut:

• Buka SPlayer dan klik pada “Buka URL” tombol di pojok kanan atas.
• Masukkan URL aliran UDP dalam format udp://@aku p: pelabuhan, di mana ip adalah alamat IP server dan port adalah nomor port aliran. Sebagai contoh, udp://@224.0.0.1:1234.
• Klik pada “baik” tombol dan tunggu streaming dimuat.

Bagaimana Splayer bekerja dengan baik untuk Win10?

Pertanyaan: Kami tidak dapat memulai Splayer 4.2 dan 4.3 di bawah Windows 10. Bisakah Anda memberi kami versi Splayer yang benar untuk Windows 10 dan 11?

4.2 dimulai dan ditutup saat ini. 4.3 dimulai dengan pesan kesalahan.

Nama aplikasi salah: Splayer.exe, versi: 1.0.0.1, cap waktu: 0x646d83e2
Nama modul yang salah: dvb_demux.dll, versi: 1.0.0.1, cap waktu: 0x5fe5bdbf
Kode pengecualian: 0xc0000005
Pengimbangan kesalahan: 0x0001484a
Id proses yang salah: 0x3888
Kesalahan waktu mulai aplikasi: 0x01da1164b89c78eb
Jalur aplikasi yang salah: C:\PenggunaadminUnduhanSplayer_v4.3_2022.10.22Splayer.exe
Jalur modul bermasalah: C:\PenggunaadminUnduhanSplayer_v4.3_2022.10.22dvb_demux.dll
Id Laporan: 4af19407-045e-48e5-a0f7-86fc90c6b3d3
Nama lengkap paket salah:
ID aplikasi relatif paket bermasalah:

Menjawab: Silakan coba gunakan Splayer_qt_v1.0.zip kami (103.5Mb).

umpan balik: Versi baru SPlayer berfungsi dengan baik di lokasi masalah dengan Win 10! Terima kasih!

Pertanyaan: Kami menemukan waktu tunda meningkat saat memutar video dari program Reciver by Splayer (aliran UDP).

Jika berbicara secara detail – Penerima terhubung dengan kabel ethernet langsung ke PC. PC dan penerima berada di jaringan lokal yang sama. Saat kami memulai Splayer, waktu tundanya normal dan hitungan persisnya menunjukkan kepada kami 330 mdetik, yang sedikit lebih dari satu dari output HDMI yang kami amati 270 mdetik. Ini baik. Namun jika kita menunggu beberapa menit tanpa ada perubahan apa pun di tempat kerja, kita akan mengamati peningkatan terus-menerus dalam waktu tunda yang dicapai 1-1,5 detik yang tidak dapat diterima dalam aplikasi pelanggan.
Kemarin saya mengujinya sendiri di Win 10, dan Win11 pada PC berbeda dengan turn-OFF yang kompleks Win Brandmauer dengan Splayer qt (versi terakhir dari Anda), dan Pemain 4.3 (versi lama). Saya mengulangi masalah ini setiap kali dalam konfigurasi apa pun.
Tolong bantu saya untuk memperbaiki masalah ini. Kita memerlukan waktu tunda waktu yang konstan dari bermain Splayer yang tidak lebih dari itu 350 mdetik.

Menjawab: Masalah seperti ini seharusnya tidak terjadi, karena pemutar tidak memiliki cache dalam mode latensi rendah, dan penundaannya sepenuhnya bergantung pada kemampuan decoding PC. Insinyur akan menyiapkan lingkungan dan mengujinya Senin depan.

Poin lainnya adalah meminta pelanggan memeriksa pengaturan kecepatan refresh monitor laptop mereka. Sebagai contoh, jika kamera memasukkan 1080p60, maka refresh rate monitor laptop pelanggan juga harus 60Hz. Jika tidak, tampilannya akan terlalu lambat, yang juga akan menyebabkan kemacetan data dan menyebabkan penundaan.

Pemain Slayer memiliki penundaan yang besar, entah decodingnya lambat atau tampilannya lambat, itu semua disebabkan oleh PC.

Pengodean kamera HDMI Pengodean penerima HDMI, keluaran ke layar, dan tes penundaan pemutaran komputer dari pemutar Splayer

Kami tidak menemukan masalah yang Anda sebutkan.

Dapat dilihat bahwa layar pemutar Splayer saat ini dan output HDMI penerima konsisten, dan penundaan di antara keduanya sangat rendah.

Bisakah Anda bertanya kepada pelanggan, berapa resolusi dan frame rate input kamera? Dengan asumsi kamera pelanggan adalah 1080p60, Anda juga dapat melakukan dua langkah berikut untuk memecahkan masalah lebih lanjut:

1. Biarkan pelanggan mengubah kamera ke frame rate yang lebih rendah untuk pengujian, seperti 1080p50/30;
2. Anda dapat mengatur parameter segmen pengkodean untuk menurunkan pengkodean frame. Sebagai contoh, kirim perintah ATSO0,30_ melalui port parameter, dan pengkodean menghasilkan 1080p30 untuk pengujian.

Catatan:

1. Splayer secara khusus dikembangkan untuk protokol streaming khusus/pemilik kami dan saat ini tidak mendukung penguraian atau pemutaran protokol MPEG-TS standar.
2. Splayer saat ini hanya tersedia di Windows. Versi Linux dan Android belum dikembangkan dan tidak didukung pada tahap ini.
3. Sebagai tambahan, bukan protokol mpeg-ts yang menyebabkan penundaan meningkat. Meskipun itu dialihkan ke protokol khusus kami, penundaan tidak akan berkurang (protokol khusus kami terutama melakukan pemeriksaan CRC pada semua paket data, sedangkan protokol mpeg-ts tidak, yang merupakan perbedaan terbesar antara protokol). Dampak terbesar pada latensi adalah pemrosesan decoding dan tampilan video di pemutar. Pemain Splayer kami sendiri akan dioptimalkan untuk skenario aplikasi transmisi gambar.
4. Bahkan jika pelanggan mendapatkan perpustakaan demux kami dan mengekstrak aliran audio dan video, itu masih harus melakukan decoding dan tampilan video dengan sendirinya. Pelanggan biasa ini tidak memiliki kemampuan ini. Kebanyakan pelanggan hanya akan menggunakan pemutar sumber terbuka (seperti berdasarkan gstreamer), dan penundaan video dari pemutar sumber terbuka ini tidak akan bagus. Jika Anda ingin penundaan video yang bagus, Anda pada dasarnya harus mengembangkan pemain Anda sendiri.
5. Jika pelanggan bersikeras pada perpustakaan demux dan mengatakan bahwa dia memiliki kemampuan untuk menangani decoding dan pemutaran video selanjutnya, Saya juga bisa bekerja sama dengan Anda (tapi kami hanya menyediakan perpustakaan demux dan rutinitas di Linux/android, dan tidak memberikan decoding berikutnya dan dukungan terkait tampilan)
6. Protokol khusus kami terutama meningkatkan verifikasi CRC untuk menangani kesalahan transmisi dengan lebih baik, yang membantu mencegah masalah decoding video yang tidak terduga atau bahkan kerusakan pemutar yang disebabkan oleh paket data yang rusak. Protokol demuxing itu sendiri tidak menimbulkan latensi yang signifikan, apakah itu protokol khusus kami atau protokol standar MPEG-TS. Faktor utama yang mempengaruhi latensi sebenarnya adalah tahap decoding dan rendering setelahnya. Umumnya:
   • Karena streaming UDP dan decoding/rendering pemutar adalah proses asinkron, sebagian besar pemain memperkenalkan sejumlah buffering sebelum memulai pemutaran. Semakin besar buffernya, semakin tinggi latensinya.
     Sebagai contoh, Pemutar media VLC biasanya menggunakan buffering yang relatif besar, dan ukuran buffernya bahkan mungkin meningkat secara dinamis selama pemutaran. Sebaliknya, Splayer sengaja menjaga buffer pemutaran menjadi sangat kecil untuk meminimalkan latensi.
   • Dekode video dan rendering bingkai juga merupakan proses asinkron. Jika rendering tidak dapat mengikuti waktu, bingkai video yang didekodekan mungkin terakumulasi dalam antrian rendering, yang memperkenalkan latensi tambahan yang mirip dengan buffering pra-decoding. Splayer juga dioptimalkan di area ini untuk mengurangi akumulasi frame dan mempertahankan pemutaran latensi rendah.
7. Protokol khusus kami juga mencakup beberapa pengoptimalan tambahan, itulah sebabnya kami akhirnya memutuskan untuk mengadopsinya daripada melanjutkan dengan protokol standar MPEG-TS (yang awalnya kami gunakan di awal):
   • Dibandingkan dengan protokol MPEG-TS standar, protokol khusus kami mengurangi overhead protokol yang berlebihan dan meningkatkan pemanfaatan bandwidth nirkabel. Hal ini sangat penting untuk tautan nirkabel dengan bandwidth terbatas seperti sistem transmisi video COFDM.
   • Protokol khusus kami memberikan fleksibilitas lebih besar untuk multiplexing berbagai jenis data. Selain video dan audio, itu dapat dengan mudah merangkum data port serial dan aliran data lain yang ditentukan pengguna, membuatnya lebih fleksibel dan lebih mudah untuk diperluas dibandingkan MPEG-TS standar.
   • Protokol khusus kami mendukung enkripsi dan dekripsi AES terintegrasi langsung di dalam lapisan protokol. Hal ini sangat berguna terutama untuk tautan nirkabel yang tidak mendukung enkripsi AES, seperti koneksi Wi-Fi standar.
   • Sebagai tambahan, protokol khusus kami dirancang khusus untuk skenario transmisi latensi rendah dan keandalan tinggi, memungkinkan pengoptimalan yang lebih ketat di seluruh saluran transmisi dan pemutaran dibandingkan dengan protokol standar tujuan umum.

Relatif

1. Apakah Anda ingin mendapatkan Data UART dari papan encoder DATA UART Video HDMI CVBS?
2. SDK Pemutar UDP Latensi Rendah untuk Windows x64

Q: Apakah sistem mendukung multicast? Bisakah saya mengeluarkan satu aliran ke beberapa IP?

SEBUAH: iya nih. Sistem ini mendukung multicast UDP, memungkinkan satu aliran dikirimkan ke beberapa penerima secara bersamaan tanpa menduplikasi aliran per IP.Untuk menggunakan multicast, mengaturIP jarak jauh di sisi pengirim ke alamat multicast, sebagai contoh224.0.0.23. Semua penerima bergabung dalam grup multicast yang sama menggunakan alamat yang sama. Di sisi penerima, konfigurasikan IP multicast yang sama:

• Pemain voli: atur IP Grup ke224.0.0.23
• VLC: membukaudp://@224.0.0.23:8090

Multicast memungkinkan streaming satu-ke-banyak dalam jaringan yang sama. IP perangkat sebenarnya tidak penting; alih-alih, pengiriman tergantung pada dukungan multicast jaringan dan perangkat yang bergabung dalam grup yang sama.Catatan: Kondisi jaringan dapat mempengaruhi kinerja. Lingkungan dengan VPN, mesin virtual, beberapa adaptor jaringan, atau switch tanpa dukungan IGMP dapat mempengaruhi penerimaan multicast.

Multicast

Unicast

Q: Jika ada beberapa papan multicast encoder di jaringan yang sama, sebaiknya kita mengganti port pada masing-masing board untuk menghindari konflik?

SEBUAH: Belum tentu. Ada dua cara valid untuk memastikan bahwa beberapa aliran encoder tidak bertentangan di jaringan yang sama:

1. Gunakan alamat IP multicast UDP yang berbeda untuk setiap aliran encoder.
2. Gunakan nomor port UDP yang berbeda untuk setiap aliran encoder.

Streaming UDP dibedakan berdasarkan kombinasi alamat IP (unicast atau multicast) dan nomor pelabuhan. Bersama, mereka mendefinisikan identitas aliran UDP unik di jaringan.

Di papan encoder, itu Pengaturan Aliran UDP memasukkan:

• IP jarak jauh: Menentukan alamat IP tujuan (jika alamat multicast digunakan, aliran menjadi aliran multicast UDP).
• Terima kasih Pelabuhan: Menentukan nomor port transmisi.

Kombinasi IP jarak jauh + Terima kasih Pelabuhan menentukan aliran UDP unik.

Untuk menghindari konflik ketika beberapa papan multicast encoder dikerahkan di jaringan yang sama, Anda dapat menetapkan alamat IP multicast yang berbeda, port UDP yang berbeda, atau gunakan keduanya tergantung pada persyaratan desain jaringan.

Q: Bagaimana cara mendapatkan alamat IP multicast untuk sistem saya?

SEBUAH: Alamat IP multicast tidak ditetapkan secara otomatis; mereka dipilih dari rentang multicast standar 224.0.0.0 untuk 239.255.255.255. Dalam praktiknya, alamat-alamat ini harus direncanakan dan dialokasikan oleh administrator jaringan untuk memastikan tidak ada konflik dengan layanan atau perangkat multicast yang ada di jaringan.

Q: Papan encoder perlu mengeluarkan video melalui antarmuka HDMI dan AV, tapi kedua aliran menggunakan alamat UDP yang sama. Bagaimana kita bisa memainkan atau beralih di antara keduanya?

SEBUAH: Ketika aliran HDMI dan AV ditransmisikan melalui alamat UDP yang sama, mereka biasanya tidak dipisahkan oleh port jaringan, tapi oleh pengidentifikasi aliran internal, mirip dengan sebuah MPEG-TS (transport Stream) struktur.

Cara kerjanya

• Input HDMI dan AV keduanya dimultipleks menjadi satu aliran UDP
• Setiap sumber video ditugaskan a ID aliran unik (misalnya, PID / ID layanan)
• Penerima melakukan demultiplexing berdasarkan ID ini, daripada memisahkan berdasarkan IP atau port
• Hal ini memungkinkan beberapa saluran video hidup berdampingan dalam satu aliran UDP

Bagaimana Splayer menangani ini

Dengan kami Pemain voli 2.0 Pemain UDP, sistem mendukung arsitektur ini secara asli:

• Penguraian kode secara bersamaan beberapa aliran video dari satu alamat UDP
• Pemisahan aliran berdasarkan ID internal (Pemetaan PID/layanan MPEG-TS)
• Peralihan waktu nyata antara sumber HDMI dan AV tanpa mengubah pengaturan jaringan
• Pemutaran multi-saluran yang fleksibel menggunakan satu sumber input UDP

Desain ini menyederhanakan penerapan dengan menjaga satu konfigurasi UDP, selagi masih aktif penanganan video multi-input dan peralihan tanpa batas.

Anda dapat mengunduh Pemain voli 2.0 Pemain UDP sini: Pemain voli 2.0 Unduh Pemutar UDP