Wawancara Frontend: Bagaimana Anda merancang pipeline video browser dengan WebCodecs?

Pertanyaan dan konteks

Jika Anda harus membangun pratinjau video real-time berbasis browser, filter, dan pengunggahan, bagaimana Anda akan menggunakan WebCodecs untuk capture, decode, pemrosesan, encode, dan muxing sambil menangani backpressure, timestamp, serta perbedaan kapabilitas browser?

Pertanyaan ini cocok untuk peran frontend, browser, media real-time, dan multimedia. Tujuannya adalah alur data dan batasan sumber daya, bukan menghafal nama API. WebCodecs mengekspos frame mentah, chunk terenkode, dan antarmuka encoder/decoder, tetapi tidak secara otomatis mengemas data terenkode menjadi file yang dapat diputar atau menjamin setiap codec di setiap browser.

Apa yang dievaluasi pewawancara

• Dapatkah Anda membedakan VideoFrame, EncodedVideoChunk, dan pengemasan kontainer?
• Apakah Anda membagi capture, pemrosesan, encoding, dan transport ke dalam bounded queues?
• Apakah Anda memahami siklus hidup configure, encode, flush, reset, dan close?
• Apakah Anda menggunakan worker, VideoFrame.close(), dan kedalaman antrean untuk mengontrol pekerjaan di main thread serta memori?
• Apakah Anda menangani timestamp, key frame, frame drop, dan sinkronisasi audio-video?
• Apakah Anda menggunakan isConfigSupported(), matriks kapabilitas, dan fallback untuk perbedaan browser?

Jawaban 30 detik

"Saya akan membagi pipeline menjadi capture, decode, pemrosesan frame, encode, mux, dan upload. Frame mentah dan chunk terenkode mempertahankan timestamp media, dan setiap antrean memiliki batasan. Ketika produksi lebih cepat daripada encoding atau konsumsi jaringan, saya membuang frame perantara yang dapat direkonstruksi sambil mempertahankan key frame dan metrik. Pekerjaan berat per frame berjalan di Dedicated Worker, dan objek VideoFrame yang telah digunakan segera ditutup. Saya menguji kapabilitas sebelum memilih konfigurasi, lalu melakukan fallback ke MediaRecorder atau pemrosesan server. Sebelum pengunggahan arsip, saya me-mux chunk tersebut, dan saya memantau latensi, kedalaman antrean, frame drop, serta kesalahan encoder."

Jawaban mendalam langkah demi langkah

Langkah 1: Tentukan tipe data dan batasan

Tahap capture dapat membaca frame dari MediaStreamTrack; decoding mengubah chunk terenkode menjadi VideoFrame; filter atau penskalaan mengonsumsi frame dan menghasilkan frame baru; encoding mengubah frame menjadi EncodedVideoChunk. Ini adalah tipe data yang berbeda, sehingga chunk terenkode bukanlah file yang dapat langsung diputar.

Muxing menulis chunk, timestamp, dan metadata trek ke dalam format seperti MP4 atau WebM. Untuk transport langsung (live), mengirimkan chunk beserta metadata konfigurasi sudah memadai. Untuk pengunduhan atau pemutaran ulang, tambahkan muxer dan validasi timeline yang dihasilkan.

Langkah 2: Tempatkan pemrosesan dalam pipeline yang dapat diobservasi

Catat panjang antrean, waktu tunggu, dan jumlah drop di setiap tahap. Pertahankan kontrol, pratinjau, dan interaksi pada main thread, dan pindahkan pemrosesan per frame ke Dedicated Worker. Transfer atau tutup objek frame secara terencana agar memori grafis tidak tertahan tanpa batas.

Filter tidak boleh menyalin frame tanpa batasan. Tentukan kepemilikan setelah pemrosesan: encoder atau renderer yang mengambil frame bertugas menutupnya, dan jalur pengecualian (exception paths) juga harus melepaskannya. Ketika antrean penuh, buang frame non-key yang belum terenkode terlebih dahulu alih-alih menyembunyikan kegagalan real-time di balik memori yang terus membengkak.

Langkah 3: Konfigurasikan encoder dan siklus hidupnya

Uji dukungan untuk codec, dimensi, frame rate, bitrate, dan opsi perangkat keras sebelum membuat VideoEncoder. Panggil encode() setelah configure() secara berurutan. Saat input berakhir, panggil flush() untuk menunggu pekerjaan yang dikirimkan; gunakan reset() untuk rekonfigurasi atau pemulihan, dan close() saat pipeline selesai.

Callback output harus menyerahkan chunk ke tahap berikutnya alih-alih melakukan pekerjaan sinkron tanpa batas. Pada kesalahan konfigurasi atau encoding, atau saat antrean output terlalu dalam, hentikan pengiriman frame dan masuk ke mode fallback atau restart alih-alih memperparah kegagalan.

Langkah 4: Rancang backpressure, drop, dan latensi

Pratinjau langsung biasanya mengutamakan kebaruan data (freshness), sedangkan pengunggahan arsip mengutamakan kelengkapan. Berikan kebijakan yang berbeda: pertahankan hanya jendela terbaru untuk pratinjau, dan jeda capture atau turunkan frame rate untuk arsip saat antreannya mencapai ambang batas atas (high watermark). Lanjutkan kembali pada ambang batas bawah (low watermark) alih-alih menebak beban dengan timer.

Saat membuang frame, pertahankan kontinuitas timestamp dan batasan key frame. Jika decoding memerlukan key frame untuk pemulihan, minta key frame pada titik pemulihan berikutnya. Di sisi transport, catat kedalaman antrean encode, kedalaman antrean kirim, dan acknowledgement delay untuk memisahkan bottleneck encoding, jaringan, dan rendering.

Langkah 5: Tangani timestamp dan sinkronisasi

Gunakan satu basis waktu media untuk frame dan chunk; waktu kedatangan tidak boleh menggantikan timestamp media. Filter dapat mengubah biaya pemrosesan tanpa mengubah waktu presentasi yang dimaksudkan. Resampling, dropping, dan perubahan kecepatan harus memperbarui timeline secara eksplisit.

Terapkan aturan yang sama pada audio dan koreksi pergeseran (drift) terhadap master clock. Jika pemutar atau pengunggah mendeteksi timestamp yang berjalan mundur, celah abnormal, atau ketidakcocokan waktu akhir trek, tandai segmen tersebut sebagai tidak valid alih-alih menggabungkannya secara diam-diam.

Langkah 6: Uji kapabilitas, lakukan degradasi, dan amati

Pengujian kapabilitas hanya menyatakan apakah suatu implementasi mendukung suatu konfigurasi; itu tidak membuktikan bahwa encoding berkelanjutan akan memenuhi target frame rate. Tetap catat waktu encode, interval output, jenis kesalahan, kedalaman antrean, dan informasi perangkat, serta gunakan beban kerja singkat untuk memverifikasi akselerasi perangkat keras yang sebenarnya.

Jika browser tidak memiliki codec target atau jalur worker, lakukan fallback ke MediaRecorder, turunkan resolusi atau frame rate, atau unggah segmen mentah yang dapat dipulihkan untuk diproses di server. Jaga agar status tetap dapat dipahami oleh pengguna dan simpan media asli sehingga hasil yang terputus dapat dipulihkan.

Keuntungan informasi dan batasan

Wawasan utamanya adalah mengubah konsep "browser dapat mengenkode video" menjadi stream yang berbatas dan dapat dipulihkan: WebCodecs menyediakan antarmuka frame dan chunk, worker mengurangi perebutan sumber daya di main thread, backpressure dan timestamp menjaga perilaku real-time, serta muxing ditambah pemeriksaan kapabilitas membuat output dapat diputar dan didegradasi.

Ini bukan berarti browser secara otomatis melakukan muxing, menyatukan codec di seluruh browser, atau menyediakan throughput tanpa batas. Desain tingkat produksi tetap harus mengevaluasi privasi, izin kamera, panas perangkat, batas memori, pengunggahan yang terputus, dan kompatibilitas server.

Contoh jawaban berkualitas tinggi

"Pertama-tama, saya akan memperjelas apakah tujuannya adalah pratinjau langsung, transport langsung, atau arsip yang dapat diunduh karena pertukaran (trade-off) antara drop dan kelengkapan berbeda. Media yang ditangkap mengalir melalui decode, pemrosesan frame, encode, mux, dan upload; VideoFrame, EncodedVideoChunk, dan file kontainer tetap menjadi model yang terpisah.

Pekerjaan per frame berjalan di Dedicated Worker. Setiap antrean memiliki watermark tinggi dan rendah, dengan metrik kedalaman, waktu tunggu, dan frame drop. Pratinjau menyimpan frame terbaru; arsip menjeda capture atau menurunkan frame rate pada watermark tinggi, dan restart dimulai dari key frame. Jam media bersama menjaga audio dan video tetap selaras.

Sebelum memulai, saya menguji codec, dimensi, frame rate, bitrate, dan opsi perangkat keras. Saat runtime, saya memantau waktu encode, interval output, kesalahan, dan sumber daya perangkat. flush menunggu pekerjaan yang dikirimkan, reset melakukan rekonfigurasi, dan close melepaskan sumber daya. Chunk output melewati muxer untuk kontainer target; saya tidak pernah mengasumsikan bahwa chunk tersebut dapat langsung diputar.

Jika kapabilitas atau performa tidak mencukupi, saya menurunkan resolusi atau frame rate, beralih ke MediaRecorder, atau memindahkan pemrosesan ke sisi server sambil mempertahankan segmen sumber yang dapat dipulihkan. Pendekatan itu mencakup kebenaran data, kebaruan, keamanan sumber daya, dan fallback browser."

Kesalahan umum

• Memperlakukan EncodedVideoChunk sebagai file → format ini tidak memiliki trek kontainer dan metadata pengemasan → tambahkan muxer dan validasi timeline untuk arsip.
• Mengklaim dukungan hanya setelah isConfigSupported() → beban berkelanjutan masih dapat menjatuhkan frame atau gagal → konfirmasikan dengan uji beban singkat dan metrik runtime.
• Menggunakan antrean tanpa batas → encoding yang lambat menyebabkan pertumbuhan memori yang tak terbatas → terapkan batas atas/bawah (watermarks) dan kebijakan drop yang eksplisit.
• Tidak pernah menutup VideoFrame → memori grafis terlambat dilepaskan → tutup sesuai kepemilikan pada jalur sukses maupun gagal.
• Menulis ulang timestamp dari waktu kedatangan → jitter menjadi pergeseran (drift) audio-video → pertahankan jam media dan catat koreksinya.
• Hanya menguji pada satu browser → perilaku codec, perangkat keras, dan worker berbeda-beda → pertahankan matriks kapabilitas dan rantai fallback.

Pertanyaan lanjutan dan jawaban

Mengapa chunk terenkode tidak dapat ditulis langsung sebagai MP4?

Chunk hanya berisi data codec dan pewaktuan, sedangkan MP4 juga membutuhkan trek, tabel sampel (sample tables), dan metadata kontainer. Gunakan muxer yang kompatibel, tulis chunk sesuai urutan timestamp, dan uji pemutarannya.

Mengapa membuang frame non-key terlebih dahulu saat antrean penuh?

Key frame adalah titik pemulihan untuk decoding berikutnya. Membuang frame biasa dapat mengurangi latensi sementara mempertahankan key frame memungkinkan decoder membangun kembali konteks. Mode arsip harus menjeda atau menurunkan kualitas alih-alih kehilangan data yang diperlukan secara diam-diam.

Bagaimana Anda membuktikan bahwa akselerasi perangkat keras efektif?

Bandingkan waktu encode, penggunaan CPU, interval output frame, dan suhu pada konfigurasi yang sama, lalu pantau kesalahan dan drop dari waktu ke waktu. Field konfigurasi hanyalah permintaan atau preferensi, bukan pengukuran runtime.

Kapan pemrosesan harus dipindahkan ke server?

Pindahkan saat kapasitas perangkat tidak mencukupi, browser tidak memiliki codec target, diperlukan transcoding yang konsisten, atau media sumber tidak boleh tersimpan di perangkat. Unggah segmen yang dapat dipulihkan dan tentukan batasan pemrosesan serta percobaan ulang (retry).