Gambaran Umum Aliran Data di DirectShow
[Fitur yang terkait dengan halaman ini, DirectShow, adalah fitur warisan. Ini telah digantikan oleh MediaPlayer, IMFMediaEngine, dan Pengambilan Audio/Video di Media Foundation. Fitur-fitur tersebut telah dioptimalkan untuk Windows 10 dan Windows 11. Microsoft sangat menyarankan agar kode baru menggunakan MediaPlayer, IMFMediaEngine , dan Pengambilan Audio/Video di Media Foundation alih-alih DirectShow, jika memungkinkan. Microsoft menyarankan agar kode yang ada yang menggunakan API warisan ditulis ulang untuk menggunakan API baru jika memungkinkan.]
Bagian ini memberikan gambaran umum yang luas tentang cara kerja aliran data di DirectShow. Detail dapat ditemukan di bagian lain dari dokumentasi.
Data disimpan dalam buffer, yang hanya merupakan array byte. Setiap buffer dibungkus oleh objek COM yang disebut sampel media, yang mengimplementasikan antarmuka IMediaSample . Sampel dibuat oleh jenis objek lain, yang disebut alokator, yang mengimplementasikan antarmuka IMemAllocator . Alokator ditetapkan untuk setiap koneksi pin, meskipun dua atau beberapa koneksi pin mungkin memiliki alokator yang sama. Gambar berikut mengilustrasikan proses ini.
Setiap alokator membuat kumpulan sampel media dan mengalokasikan buffer untuk setiap sampel. Setiap kali filter perlu mengisi buffer dengan data, filter meminta sampel dari alokator dengan memanggil IMemAllocator::GetBuffer. Jika alokator memiliki sampel yang saat ini tidak digunakan oleh filter lain, metode GetBuffer segera kembali dengan penunjuk ke sampel. Jika semua sampel alokator sedang digunakan, metode akan memblokir hingga sampel tersedia. Ketika metode mengembalikan sampel, filter memasukkan data ke dalam buffer, mengatur bendera yang sesuai pada sampel (biasanya termasuk stempel waktu), dan mengirimkan sampel hilir.
Saat filter perender menerima sampel, filter memeriksa stempel waktu dan menahan sampel hingga jam referensi grafik filter menunjukkan bahwa data harus dirender. Setelah filter merender data, filter akan merilis sampel. Sampel tidak kembali ke kumpulan sampel alokator sampai jumlah referensi sampel adalah nol, yang berarti bahwa setiap filter telah merilis sampel. Gambar berikut mengilustrasikan proses ini.
Filter upstram mungkin berjalan di depan perender — yaitu, mungkin mengisi buffer lebih cepat daripada yang dikonsumsi perender. Meskipun demikian, sampel tidak dirender lebih awal, karena perender memegang masing-masing sampai waktu presentasinya. Selain itu, filter upstram tidak akan menimpa buffer secara tidak sengaja, karena GetSample hanya mengembalikan sampel yang tidak digunakan sebaliknya. Jumlah di mana filter hulu dapat berjalan di depan ditentukan oleh jumlah sampel di kumpulan alokator.
Diagram sebelumnya hanya menunjukkan satu alokator, tetapi biasanya ada beberapa alokator per aliran. Dengan demikian, ketika perender merilis sampel, perender dapat memiliki efek berskala. Diagram berikut menunjukkan situasi di mana dekoder menyimpan bingkai video terkompresi saat menunggu perender merilis sampel. Filter pengurai juga menunggu dekoder untuk merilis sampel.
Saat perender merilis sampelnya, panggilan tertunda dekoder ke GetBuffer akan kembali. Dekoder kemudian dapat mendekode bingkai video terkompresi dan melepaskan sampel yang dipegangnya, sehingga membuka blokir panggilan GetBuffer parser yang tertunda.
Topik terkait