Di bawah ini adalah kisah terperinci tentang bagaimana kami memuat kartu dari NVidia dengan tugas transcoding video untuk streamingnya. Mari kita tunjukkan bahwa kami mencoba apa yang terjadi, dan cara terbaik menggunakan kartu video untuk streaming online.Selama beberapa tahun, tim kami telah mengembangkan produk untuk memproses dan mendistribusikan konten media online.
Artikel ini baru-baru ini
menjelaskan mengapa pemilik konten mungkin membutuhkan solusi seperti itu di usia YouTube kami.
Salah satu produk kami adalah server media
Nimble Streamer , yang merupakan perangkat lunak server yang mengambil streaming langsung dan file ke input dan membuatnya dapat diakses oleh sejumlah besar pemirsa, sementara secara bersamaan memungkinkannya untuk memonetisasi konten. Ini adalah aplikasi asli yang ditulis dalam C ++ dan porting ke semua OS populer (Linux, Windows, MacOS) dan platform (x64, ARM). Sejak awal, konsumsi sumber daya yang rendah dan produktivitas yang tinggi adalah persyaratan utama, dan kami berhasil mencapai
hasil yang baik dalam hal ini.
Tahun lalu, kami merilis Nimble Streamer add-on -
live stream transcoder . Aplikasi ini memungkinkan Anda untuk mengambil aliran input video dan / atau audio dalam berbagai format dan melakukan berbagai konversi dengannya secara real time. Fungsionalitas termasuk decoding (baik perangkat lunak dan perangkat keras), konversi video dan audio menggunakan filter (ukuran, overlay, dll.) Dan pengkodean (encoding) - baik perangkat lunak dan perangkat keras.
Transcoder dikendalikan melalui layanan web WMSPanel, skrip transcoding dibuat melalui antarmuka drag-n-drop, yang memungkinkan Anda untuk melihat proses secara visual. Berbagai skenario dapat dijalankan bersama - dengan pendekatan ini, nyaman untuk menjalankan kombinasi pengujian, memuat server dalam variasi apa pun.
Dalam video ini, Anda dapat melihat contoh cara kerja antarmuka.
Penguraian setiap aliran dilakukan hanya sekali sebelum semua konversi lebih lanjut ... Ini memungkinkan Anda untuk menghemat sumber daya pada operasi pengodean yang mahal, ini akan terlihat jelas di sepanjang pengujian.
Salah satu mekanisme konversi yang dapat digunakan dalam transcoder kami adalah decoding perangkat keras dan pengkodean video menggunakan GPU dari NVidia. Kartu grafis generasi terbaru memungkinkan Anda mengambil beberapa tugas khas, yang menghilangkan beban dari CPU. Transcoder kami dapat bekerja dengan perangkat keras ini, yang secara aktif digunakan oleh pelanggan kami.
Dalam proses komunikasi dengan perwakilan kantor Rusia NVidia, kami diminta untuk mencoba mengatur stress test bersama dari transcoder kami dan NVidia GPU untuk memahami apa dampak ekonomi dari tandem semacam itu akan dibandingkan dengan transcoding perangkat lunak eksklusif, tanpa akselerasi perangkat keras. Selain itu, saya ingin memahami cara menggunakan GPU secara optimal, dan jika mungkin memberikan resep yang baik.
Kami perlu segera mendapatkan zat besi yang sesuai dan akses ke sana, untuk siklus percobaan kami. Kami berencana untuk bertemu beberapa minggu. Masih mencari tempat untuk mendapatkan peralatan. Opsi terbaik adalah menemukannya di cloud dan mendapatkan akses jarak jauh. Setelah mencari opsi, ternyata AWS belum memiliki VM dengan GPU generasi Maxwell, dan di Azure cloud, hanya direncanakan untuk mulai menyediakannya segera.
1. Setrika dari NVidia di awan Softlayer, mengatur Nimble Streamer
Dengan bantuan NVidia, IBM memberi kami akses ke cloud-nya, Platform IBM Bluemix Cloud (sebelumnya
Softlayer ). Ini adalah jaringan besar pusat data modern (sekitar 50 pada saat publikasi) di seluruh dunia, terhubung oleh jaringan pribadi bersama dan menyediakan banyak pilihan layanan infrastruktur cloud. Semua pusat data disatukan dan memungkinkan Anda untuk menyewa dari satu hingga ratusan server virtual atau fisik dari konfigurasi yang diperlukan selama beberapa jam, serta penyeimbang, sistem penyimpanan, firewall - secara umum, semua yang diperlukan untuk membangun infrastruktur TI yang andal untuk layanan IT yang digunakan.
Kantor perwakilan Rusia dari IBM memberi kami akses penuh ke
portal swalayan untuk mengelola layanan cloud dan ke konfigurasi server yang diperlukan, di mana kami dapat bekerja dengan berbagai aliran input dan pengaturan transcoder kami.
Besi
Pertama, kami diberi server fisik (bare-metal) dengan 128 GB RAM dan 2xGPU NVidia Tesla M60 dan pra-instal OS Ubuntu 14.04. Semua parameter server, kata sandi, versi firmware, switching, IP khusus, status komponen perangkat keras, terlihat langsung di akun Anda, memungkinkan Anda untuk melakukan manipulasi yang diperlukan dengan perangkat sewaan, yang meminimalkan kebutuhan untuk interaksi dengan dukungan IBM. Selama uji coba, ternyata kami tidak dapat memuat konfigurasi ini secara optimal, karena sejumlah keterbatasan dalam pembuatan konteks.
Kami ingin mengurangi konfigurasi. Karena kami menggunakan platform cloud, diperlukan melalui portal swalayan untuk meminta perubahan konfigurasi. Setelah disetujui, operasi ini memakan waktu sekitar 2 jam ke jendela layanan yang disetujui. Selama waktu ini, staf teknis di pusat data Amsterdam menghapus komponen tambahan (slot RAM dan 1xGPU) dari server yang diberikan kepada kami sebelumnya dan mengembalikannya ke operasi. Perlu dicatat bahwa untuk pengembang opsi ini sangat mudah, karena tidak perlu berurusan dengan pengaturan perangkat keras, memperbaikinya, atau bahkan menghabiskan waktu menginstal OS. Biarkan saya mengingatkan Anda bahwa dalam kasus ini hypervisor tidak digunakan karena kami perlu memeras sumber daya perangkat keras secara maksimal.
Berdasarkan hasil penelitian kami, kami menetapkan konfigurasi server berikut:
Dual Intel Xeon E5-2690 v3 (2.60GHz)
24 core
RAM 64GB
SATA 1TB
Kami memiliki 2 prosesor dengan 12 core masing-masing, dan berkat Hyper threading, kami mendapatkan dua kali lipat, yaitu hampir 48 core.
Dalam skenario dengan akselerator grafis, kartu berbasis chip GM204 - Tesla M60 digunakan:
NVIDIA Tesla M60
1xGPU: 2 x Maxwell GM204
Memori: 16GB GDDR5
Kecepatan Clock: 2,5 GHz
NVIDIA CUDA Cores: 2 x 2048
Memory Bandwidth: 2 x 160GB / detik
Saya menarik perhatian Anda pada fakta bahwa tidak ada afinitas, chip tuning, overclocking, atau sihir lain yang dilakukan pada perangkat keras yang berkurang - hanya CPU dan GPU yang tidak di-overclock, dan untuk GPU hanya driver resmi yang diambil dari situs web NVidia yang digunakan. Jika seseorang memiliki pengalaman serupa - bagikan dalam komentar.
Jadi, kami mendapat akses. Seorang kenalan cepat dengan antarmuka web dari panel kontrol (semuanya sederhana dan jelas di sana), kemudian akses ke server melalui SSH - dan di sini kita berada di baris perintah Ubuntu yang biasa, letakkan Nimble Streamer, daftarkan lisensi transcoder baru dan lakukan sedikit pengaturan konfigurasi.
Transcoder streamer gesit
Nimble Streamer dikonfigurasikan untuk pra-membuat cache konteks GPU. Ini disebabkan oleh kenyataan bahwa GPU memiliki batasan jumlah maksimum dari konteks decoding dan encoding yang dibuat, dan di samping itu, menciptakan konteks dengan cepat dapat memakan waktu terlalu banyak.
Rincian lebih lanjut tentang masalah membuat konteks dapat ditemukan di bagian yang sesuai di bawah ini.
Pengaturan gesit pada contoh serangkaian tes pertama:
nvenc_context_cache_enable = true
nvenc_context_create_lock = true
nvenc_context_cache_init = 0: 30: 15.1: 30: 15
nvenc_context_reuse_enable = true
Rincian lebih lanjut tentang pengaturan ini ditulis
dalam artikel kami .
Sebelum memulai setiap rangkaian tes, cache dikonfigurasikan secara terpisah, dengan mempertimbangkan spesifikasi setiap tugas.
Buat Skrip Transkode
Pekerjaan lebih lanjut berlangsung di layanan WMSPanel kami, di mana skrip transcoder dikonfigurasi.
Seperti yang telah disebutkan, pekerjaan berjalan melalui antarmuka web, semuanya sangat jelas dan nyaman. Kami menciptakan sejumlah skenario yang menggabungkan berbagai opsi transcoding (CPU / GPU), opsi resolusi yang berbeda, dan parameter enkode yang berbeda (CPU / GPU, profil, bit rate, dll.)
Set skenario dapat dijalankan secara bersamaan, yang memungkinkan untuk memperkenalkan berbagai kombinasi pengujian, menambah beban dalam urutan yang berbeda, dan mengubahnya tergantung pada situasinya. Cukup pilih skenario yang diperlukan dan hentikan atau lanjutkan.
Berikut adalah sejumlah skenario:
Berikut ini adalah contoh dari salah satu skenario:
Dekoder GPU terlihat seperti ini:
Kami menerapkan filter ukuran gambar:
Dan inilah encoder untuk varian GPU:
Secara umum, pengoperasian antarmuka transcoder dapat
dilihat di video-video ini .
2. Transcoding stream FullHD 1080p
Untuk mulai dengan, kami menguji skenario dengan beban tertinggi untuk mengetahui batas kemampuan besi. Saat ini, resolusi terberat yang digunakan dalam praktek adalah FullHD 1080p.
Untuk menghasilkan streaming langsung asli, file diambil dalam
FullHD (1920 * 1080) di
profil tinggi H.264 . Konten itu sendiri adalah tur video kota, mis. Ini adalah video dengan tingkat perubahan gambar rata-rata. Tidak ada bingkai warna tunggal statis yang dapat memfasilitasi pekerjaan transcoder, tetapi tidak ada perubahan jenis dan warna yang terlalu cepat. Dalam satu kata - memuat yang cukup tipikal.
36 stream identik diumpankan ke input Nimble Streamer, yang kemudian digunakan dalam transcoder dalam berbagai skenario.
Skenario transcoding digunakan khas - aliran masuk adalah profil tinggi
1080p ,
720p, 480p, profil utama 360p dibuat darinya
, dan kemudian aliran
profil dasar: 240p, 160p . Secara total, ada 1 stream di input dan 5. di output. Biasanya, pass-through (transfer tanpa perubahan) dari stream asli juga dilakukan sehingga pemirsa dapat memilih 1080p itu sendiri ketika melihat. Kami tidak menambahkannya di skrip, karena tidak menggunakan transcoding - ada transfer data langsung dari input ke output. Skenario ini dioptimalkan dalam Nimble dan dalam kondisi nyata akan meningkatkan konsumsi memori yang relatif sedikit.
Audio dalam aliran yang dihasilkan - tidak. Menambahkan audio ke skrip tidak akan menyebabkan beban CPU yang signifikan, tetapi untuk kemurnian percobaan, kami mengecualikan suara.
Tes CPU, tidak ada GPU
Untuk memulai, kami meluncurkan skrip transkode tanpa menggunakan GPU, menentukan decoder dan encoder perangkat lunak dalam skrip.
Akibatnya, hanya mungkin memproses 16 arus input dengan penerbitan 80 aliran semua izin keluar.
Beban CPU - 4600%, mis. 46 core terlibat. Konsumsi RAM - sekitar 15GB.
Tes CPU + GPU
Tembolok konteks pada saat startup dikonfigurasikan sebagai 0: 30: 15.1: 30: 15 - mis. 30 konteks untuk encoding, 15 untuk decoding, masing-masing GPU.
Izinkan saya mengingatkan Anda bahwa pada GPU kami memiliki dua core, yang memungkinkan kami untuk melakukan paralelisasi tugas - ini berguna bagi kami.
Beban maksimum diperoleh dengan konfigurasi aliran berikut.
Input decoder, GPU0 dan GPU1 - 15 stream. Jadi kita mendapatkan 30 stream yang diterjemahkan, siap untuk digunakan lebih lanjut. Setiap aliran diterjemahkan hanya sekali, tidak peduli berapa banyak skenario yang digunakan di masa depan.
Encoder GPU0 dan GPU1 diberi makan masing-masing 15 aliran untuk mendapatkan 720p, mis. 30 aliran 720p saat keluar ternyata.
Juga, encoders GPU0 dan GPU1 masing-masing menyediakan 15 stream untuk 480p - dan 30 stream 480p juga merupakan output.
Karena konteks encoder telah habis, pengkodean dari izin yang tersisa ditetapkan pada CPU. Ternyata yang berikut ini:
- 30 stream 360p
- 30 stream 240p
- 30 stream 160p
Bebannya ternyata 2600% CPU, 75% decoder, 32% encoder. Selanjutnya, CPU dimuat dengan 6 stream untuk decoding, untuk masing-masing 5 resolusi yang sama dikonfigurasi, untuk total 30 utas per output.
Secara total,
36 stream diterima
pada input, 180 dikeluarkan pada output . Beban final ditetapkan sebagai berikut:
4400% CPU, decoder kartu 75%, encoder kartu 32%, RAM 30GB .
Beberapa detail
Kami memutuskan untuk memeriksa opsi di mana kami memproses tugas-tugas paling sulit pada GPU - decoding 1080 dan encoding 720 dan 480, dan biarkan sisanya diproses melalui CPU.
Pertama, kami memeriksa batas dekoder. Dengan 22 utas, decoding dipengaruhi oleh masalah dengan konteks, mereka tidak bisa dibuat. Berkurang 21 - konteks diciptakan, tetapi beban menjadi 100% dan artefak mulai diamati di sungai. Kami berhenti di 20 aliran - kami melakukan decoding dari 20 aliran, penyandian pada 160p - semuanya berfungsi dengan baik.
Selain itu, ternyata secara empiris bahwa kartu ini dengan RAM 16GB on board dengan percaya diri dapat bekerja dengan 47 konteks - dan tidak ada perbedaan, ini adalah konteks encoder atau decoder. Saya ulangi - ini khusus tentang Tesla M60 GPU ini, pada kartu lain nomor ini mungkin berbeda. Kami percaya bahwa jika kartu memiliki RAM 24GB, jumlah konteks bisa berbeda, tetapi ini perlu diuji.
Sebagai hasilnya, kami memilih formula pembuatan cache "15 konteks decoder dan 30 konteks encoder" - yang memberikan 30 stream ke input dan untuk masing-masing memungkinkan Anda membuat 2 izin. Jadi resolusi atas - 720 dan 480 - diluncurkan pada GPU, dan sisanya - 360, 240 dan 160 - dikirim ke CPU. Dan karena CPU masih bebas setelah itu, kami “menyelesaikan” core gratis dengan utas baru, meninggalkan 4 core untuk tugas utilitarian.
3. Transcoding stream HD 720p
Skenario pemuatan tipikal Sebagian besar konten sekarang dibuat dalam HD. Bahkan SuperBowl LI baru-baru ini - acara dengan rating tertinggi di pasar AS -
disiarkan dalam HD , meninggalkan FullHD untuk masa depan.
Untuk menghasilkan stream sumber, file diambil dalam
HD (1280 * 720) dalam
profil tinggi . Konten adalah seri "The Good Wife" favorit insinyur kami, yaitu Ini adalah video dengan tingkat perubahan gambar rata-rata.
Di pintu masuk ke Streamer Nimble, 70 aliran identik diumpankan, yang kemudian digunakan dalam transcoder dalam skenario yang berbeda.
Skenario transcoding berikut digunakan - aliran masuk adalah profil tinggi
720p ,
480p, profil utama 360p dan kemudian
240p, aliran profil
dasar 160p dibuat darinya. Total, pada input 1, pada output 4. Pass-through dari aliran asli, seperti dalam skenario sebelumnya, tidak dilakukan. Audio dalam aliran yang dihasilkan juga tidak.
Tes CPU, tidak ada GPU
Seperti pada bagian sebelumnya, kami mencoba transcoding stream hanya di CPU. Akibatnya, hanya dimungkinkan untuk memproses 22 arus input dengan penerbitan 88 aliran semua izin keluar. Beban CPU - 4700%, mis. 47 core terlibat. Konsumsi RAM - sekitar 20GB.
Tes CPU + GPU
Cache konteks saat startup dikonfigurasikan sebagai 0: 23: 23.1: 23: 23 - yaitu. 23 konteks untuk encoding, 23 untuk decoding untuk setiap GPU.
Menggunakan GPU, 46 720p stream diterjemahkan. Di sana, pada GPU, 46 aliran 480p dikodekan. Selanjutnya, pengkodean 360p, 240p dan 160p dilakukan pada CPU - masing-masing 46 stream.
Memperbaiki beban 2100% CPU, 61% dari decoder, 16% dari encoder.
Selain itu, encoding dan decoding dari 24 utas ke CPU diluncurkan, untuk setiap 1 utas - 4 output, seperti untuk GPU.
Secara keseluruhan,
70 stream adalah input, 280 stream adalah output .
Beban:
4600%, 61% dari decoder, 16% dari encoder, 30GB RAM .
Adapun tes sebelumnya, mungkin GPU RAM yang lebih besar akan memberikan lebih banyak konteks dan kami bisa menangani lebih banyak utas. Tapi ini hanya secara teori, perlu diperiksa.
4. Masalah dengan membuat konteks dalam NVidia GPU
Beberapa kata tentang masalah yang tidak memungkinkan kami memproses lebih banyak utas pada GPU.
Pada akhir tahun lalu, kami melakukan tes dengan tim NVidia, dengan beberapa kartu. Ketika bekerja dengan banyak GPU, ternyata menciptakan konteks sangat memperlambat server - membuat setiap konteks baru membutuhkan lebih banyak waktu dari peta. Jika konteks pertama dibuat pada urutan 300ms, maka masing-masing berikutnya menambahkan 200-300ms dan sudah dalam sepuluh konteks ketiga, membuat yang baru membutuhkan 3-4 detik masing-masing. Ketika seorang pengguna membuat skrip transkoding, diasumsikan bahwa ia mulai bekerja segera dan tanpa penundaan, dan keadaan baru ini meniadakan semua keuntungan dalam kecepatan Nimbl dan memberikan penundaan dalam menciptakan konteks yang menyebabkan keterlambatan dalam memulai pengkodean.
Pada awalnya, kecurigaan jatuh pada Nimble, tetapi kemudian kami melakukan tes menggunakan ffmpeg, yang NVidia sendiri berikan kepada pelanggan dan hasilnya ternyata persis sama - GPU menghabiskan lebih banyak waktu menciptakan setiap konteks baru. Dalam kondisi ketika server sudah melakukan transcoding dan Anda perlu memulai utas baru untuk diproses, ini memengaruhi kinerja keseluruhan dan membuat server tidak bisa digunakan.
Masalahnya dijelaskan secara rinci oleh tim NVidia, tetapi sejauh ini tidak ada solusi penuh yang telah disediakan. Oleh karena itu, kami sejauh ini menerapkan mekanisme caching konteks di server kami, dengan pembuatan konteks awal di server dimulai. Ini menyelesaikan masalah dari sudut pandang pekerjaan pengguna akhir, tetapi awal dari Nimbl mungkin memerlukan waktu. Menyiapkan Nimbl untuk pekerjaan yang efektif dengan konteks
dijelaskan di blog kami .
Selain itu, konteksnya tidak mudah dibuat. Dengan sejumlah besar konteks ketika menyertakan skrip transkoding, API NVENC mulai membuat kesalahan: "Panggilan API gagal karena tidak dapat mengalokasikan cukup memori untuk melakukan operasi yang diminta."
Secara empiris, ternyata satu GPU dapat memulai dan bekerja dengan penuh percaya diri dengan 47 konteks - dan tidak ada perbedaan, ini adalah konteks encoder atau decoder. Ada asumsi bahwa ini disebabkan oleh jumlah memori pada GPU. Sekarang ada 16 GB, jika Anda meletakkan kartu dengan 24 GB, ada kemungkinan lebih banyak konteks dapat dilakukan. Tapi ini hanya teori, perlu diperiksa, seperti yang disebutkan sebelumnya. Data yang diperoleh valid untuk model GPU tertentu, kartu lain harus diuji secara terpisah.
Ini adalah pembatasan jumlah konteks yang menempatkan kendala utama saat bekerja dengan beban besar.
5. Kesimpulan
Jadi, tujuan pengujian adalah untuk mempelajari efektivitas GPU untuk berbagai tugas yang ditunjukkan dan untuk mengembangkan resep untuk penggunaan yang tepat. Apa hasilnya?
Efek ekonomi
Di atas, kami melihat bagaimana jumlah utas yang dapat diproses pada CPU dan pada tandem CPU + GPU berbeda. Mari kita lihat apa artinya ini dalam hal uang. Sebagai dasar kami mengambil semua Softlayer yang sama dan harga sewa peralatan mereka.
- Konfigurasi tanpa GPU akan dikenakan biaya $ 819 per bulan . Di sini Anda dapat mengambil mobil.
- Konfigurasi dengan GPU akan dikenakan biaya $ 1729 per bulan untuk pusat data di Amsterdam, harga dapat ditemukan di sini . Saat menggunakan GPU, harga sewa server sedikit meningkat, karena faktor bentuk 2U yang lebih besar digunakan. Efek ekonomi mungkin akan lebih tinggi ketika membeli peralatan (tetapi ini membutuhkan analisis serius dari TCO, dengan mempertimbangkan pembaruan terus-menerus dari garis NVidia GPU).
Sekarang mari kita lihat hasil tes:Untuk FullHD 1080p- CPU tanpa GPU: 16 utas per input + 80 utas per output
- CPU + GPU: 36 utas per input + 180 per output
Manfaat GPU: 2.25x.Keuntungan menggunakan GPU: $ 819 * 2,25 - $ 1729 = $ 113 per bulan saat menyewa 1 server dengan GPU.Untuk HD 720p- CPU tanpa GPU: 22 utas per input + 88 utas per output
- CPU + GPU: 70 utas per input + 280 per output
Manfaat GPU: 3.18x.Keuntungan menggunakan GPU: $ 819 * 3,18 - $ 1729 = $ 875 per bulan saat menyewa 1 server dengan GPUArtinya, dengan opsi sewa, penghematannya cukup mencolok. Ini tidak memperhitungkan diskon akun - di kantor Rusia IBM, mereka menjanjikan diskon untuk menyewa sumber daya di cloud dibandingkan dengan harga yang disajikan di sini.Kami tidak masuk ke opsi dengan pembelian, karena di sini TCO sangat tergantung pada pilihan pemasok, biaya layanan di pusat data dan faktor-faktor lain yang akrab bagi mereka yang bekerja dengan logam telanjang. Namun, angka awal juga berbicara mendukung solusi berbasis GPU.Juga, jangan lupa tentang lalu lintas dan lebar saluran - mereka termasuk dalam jumlah tertentu dalam tarif yang disajikan di atas, tetapi Anda harus memilih opsi untuk tugas Anda berdasarkan jumlah utas, jumlah pengguna yang diharapkan, dll.Scaling
Opsi dengan satu kartu grafis per server bagi kami tampaknya lebih hemat biaya daripada opsi dengan dua kartu atau lebih. Seperti yang dapat kita lihat, dekoder GPU selalu memuat lebih dari encoder, tetapi bahkan tetap kurang karena masalah dengan penggunaan konteks. Jika Anda menambahkan kartu kedua, decoder akan digunakan lebih sedikit lagi, pembuat enkode kami tidak akan dapat memuat dengan kapasitas penuh, dan semua pekerjaan pada pengkodean masih harus dialihkan ke CPU, yang akan dibenarkan untuk uang. Kami juga menguji opsi dengan dua GPU berkat dukungan Softlayer, tetapi karena efek ekonomi yang lemah, kami tidak memberikan detail dalam artikel.Dengan demikian, untuk menskalakan beban, lebih baik menambahkan server baru dengan satu kartu grafis daripada menambahkan kartu ke mesin yang ada.Jika jumlah aliran masuk dan keluar untuk proyek Anda relatif kecil - katakanlah, selusin aliran HD dengan sejumlah kecil izin keluaran, dengan sejumlah kecil penyaringan, maka akan lebih bijaksana untuk menggunakan server tanpa GPU.Perlu juga dicatat bahwa jumlah RAM untuk tugas mengubah utas tidak sepenting kekuatan pemrosesan. Jadi dalam beberapa kasus, Anda juga dapat menghemat dengan mengurangi jumlah memori.Kesimpulan
Solusi perangkat keras yang disajikan - kombinasi dari Tesla M60 CPU dan GPU - sempurna untuk transcoding streaming langsung di bawah beban yang berat. GPU menangani operasi yang paling intensif sumber daya - mendekode stream dan mengkodekannya ke dalam resolusi tertinggi, sementara resolusi menengah dan kecil diproses dengan baik pada CPU.Jika salah satu pembaca memiliki pengalaman dan mengoptimalkan kinerja kartu grafis untuk siaran langsung, kami akan senang berkenalan dengan pengalaman Anda - tulis di komentar.