Apakah kontrol versi memiliki bagian dalam alur kerja produksi video?


20

Saya seorang pengembang perangkat lunak dan saya juga tertarik pada fotografi (selama empat tahun) dan produksi video (hanya untuk beberapa bulan).

■ Dalam pengembangan perangkat lunak, ada aturan penting yang diikuti setiap pengembang pada setiap proyek: semuanya harus di bawah kendali versi : kode sumber, file konfigurasi, skema basis data, dokumentasi — segala sesuatu yang memungkinkan membangun proyek dari awal. Ini memiliki dua konsekuensi yang menyenangkan:

  1. Dalam peristiwa bencana ketika Anda kehilangan segalanya kecuali repositori kontrol versi, Anda harus dapat melanjutkan seolah-olah tidak ada yang terjadi.

  2. Jika terjadi perubahan bodoh yang berdampak negatif pada proyek, pengembang dapat kembali ke revisi sebelumnya.

■ Dalam fotografi, setiap perubahan yang saya buat pada foto disimpan selamanya di katalog Lightroom , memungkinkan untuk kembali ke keadaan sebelumnya kapan saja. Dengan fitur salinan virtual, Lightroom juga memungkinkan untuk melakukan apa yang disebut cabang dalam kontrol versi: kemampuan untuk menguji sesuatu yang berbeda, dan entah menyimpan kedua hasil atau menghapus salah satu dari mereka nanti.

Katalog tidak menyimpan foto RAW sendiri, tetapi mereka tetap tidak berubah.

■ Dalam produksi video, segalanya tampak berbeda. Saya bekerja dengan Premiere Pro, After Effects and Soundbooth.

  • Sepertinya tidak ada yang menyimpan riwayat secara permanen: jika saya melakukan suatu tindakan secara tidak sengaja dan hanya melihatnya pada hari berikutnya, tidak ada cara untuk memulihkan versi sebelumnya.

  • Soundbooth juga mengubah secara langsung file WAV, yang membutuhkan upaya tambahan untuk memisahkan rekaman asli dari yang dimodifikasi.

  • Kontrol versi jarang disebutkan, dan saya belum menemukan orang yang mengatakan bagaimana ia sebenarnya menggunakan kontrol versi dalam alur kerjanya. Selain itu, tidak ada yang menyebutkan kontrol versi mana yang harus digunakan, dan karena sebagian besar sistem kontrol versi dioptimalkan untuk file teks, bukan yang biner, ini menciptakan tantangan tambahan.

  • Video.SE tidak memiliki tag atau .

Jadi, saya punya dua pertanyaan:

  1. Apakah kontrol versi memiliki bagian dalam alur kerja seseorang yang bekerja dengan produksi video? Bagaimana cara terintegrasi?

  2. Apakah migrasi ke Adobe Creative Cloud membantu? Apakah ada fitur spesifik yang memungkinkan, di Creative Cloud, untuk melacak revisi berturut-turut dari proyek Premiere Pro atau After Effects?

Catatan: untuk menghindari jawaban di luar topik, saya menyoroti bahwa pertanyaan saya tidak terkait dengan cadangan , dan secara khusus tentang menyimpan revisi berturut-turut dari pekerjaan saya, tidak memiliki cadangan data di tempat / di luar situs.

Jawaban:


10

Kontrol versi dalam arti Git tidak terlalu praktis di dunia video. Anda perlu membuat alat kontrol versi khusus untuk setiap alat audio dan video di luar sana karena semua bekerja dengan format proyek mereka sendiri. Tetapi bisa membaca format ini hanya satu hal, maka Anda juga perlu mesin render alat itu untuk menunjukkan perbedaan.

Meskipun semua alat ini bekerja dengan cara yang tidak merusak kecuali Anda melakukan pra-render beberapa barang (bandingkan dengan mengkompilasi dll / lib sepotong kode Anda dan bekerja dengan itu mulai sekarang), sehingga Anda hanya dapat kembali ke revisi lama dengan melakukan ctrl + z atau menggunakan alat sejarah di beberapa program.

Meskipun menyimpan sub versi biasanya cara untuk pergi. Seperti stib yang dijelaskan dalam jawabannya atau dengan melakukannya secara manual.

Sesuatu yang saya suka lakukan dan bekerja dengan baik dengan setiap perangkat lunak adalah meletakkan file proyek saya (tanpa rekaman sumber) ke Dropbox. Jika Anda memiliki kecepatan unggah yang agak cepat (~ 1 Mbit / s) dan file proyek Anda tidak 100MB +, Anda dapat mengunggah proyek Anda sebelum Anda menyimpan waktu berikutnya. Proyek Premiere / AE / FCP rata-rata sekitar 10-20MB sehingga file Anda yang baru disimpan akan diunggah dalam 1-2 menit. Lebih cepat lagi jika Anda memiliki lebih banyak bandwidth unggah.

Lalu jika Anda harus kembali, Anda dapat mengakses riwayat Dropbox dari file Anda dan mengunduh atau mengembalikan ke revisi itu. Dropbox menyimpan revisi file selamanya * pada akun berbayar (* setidaknya saat mereka memiliki opsi paket tikus, sekarang ini tahun menurut saya) dan selama 30 hari dengan akun gratis. Saya yakin ada host cloud lain yang menawarkan fitur serupa. Ini seperti menggunakan versi git super terbatas yang menangani file biner dengan sangat baik dan bebas sakit kepala. Ini memiliki keuntungan bahwa Anda tidak mengacaukan folder dengan banyak file dan memiliki cadangan pada saat bersamaan.

Sebagian besar host cloud juga menawarkan Keanggotaan Tim sehingga Anda dapat bekerja dengan banyak editor. Atau Anda membagikan folder proyek dengan anggota tim lainnya.


Dropbox menyimpan revisi file selamanya? Lalu bagaimana jika Anda memiliki file video 5 GB dengan 800 revisi?
Pacerier

Saya mengedit jawabannya sedikit. Dengan opsi pak tikus lama itu memang selamanya sekarang satu tahun, dan ya Anda bisa melakukan apa yang baru saja Anda jelaskan tetapi seperti saya tulis dalam jawaban saya jangan taruh file sumber (mis. Video / gambar / audio) di sana, hanya Anda file proyek. Kecuali Anda memiliki koneksi gigabit yang sangat tidak praktis untuk menyimpan versi dari perubahan sumber atau membuat file.
PTS

1
Anda hanya perlu VCS Anda untuk memahami format jika Anda perlu diff. Itu agak banyak yang diharapkan.
Peter Cordes

1
Jadi Anda dapat dengan mudah mengontrol versi file proyek Anda, karena 10-20MB data biner tidak masalah untuk git. Anda hanya perlu menulis pesan komit yang berguna untuk menggambarkan status penyimpanan file Anda ketika Anda melakukannya. Jika Anda beruntung, maka perubahan edit kecil seringkali tidak mengubah sebagian besar bit dalam file proyek, dan kompresi delta git akan menggunakan jauh lebih sedikit dari 10MB penuh untuk setiap komit. Dan kemudian backup semudah git pushke server cadangan Anda. (dengan beberapa metode lain untuk melacak video master mana yang berjalan dengan proyek mana, mungkin md5sums dari file sumber?)
Peter Cordes

Nah itulah kasus yang ideal, jika proyek Anda berakhir dengan file proyek yang lebih besar Anda tidak dapat mengunggah revisi sesering tergantung pada koneksi Anda. Sebuah perangkat lunak penyimpanan awan berskala sempurna, git pada akhirnya akan mengalami masalah. Pesan komit jelas merupakan nilai tambah untuk git.
PTS

6

Hanya untuk menambah tanggapan sebelumnya: Meskipun tidak ada yang seperti Git untuk dunia video, ada alat Digital Asset Management / Media Asset Management yang dapat lebih atau kurang melakukan hal yang sama - kontrol versi dan izin / manajemen pengguna (mereka juga melakukan Git untuk dunia video). lebih banyak, karena mereka benar-benar dibangun sebagai perpustakaan untuk media Anda). Selama bertahun-tahun, saya menggunakan aplikasi Final Cut Server Apple (sekarang usang) yang terintegrasi dengan Final Cut Suite (Final Cut Pro 7, Soundtrack Pro, dll) di fasilitas pos kecil.

Kami menggunakannya untuk kontrol versi dan bercabang pada file proyek, yang memungkinkan beberapa editor bekerja pada satu proyek yang relatif mulus. Karena ini adalah produk Apple, ia dirancang untuk digunakan dengan Final Cut Pro dan karenanya dapat membaca dan bekerja dengan file proyek FCP dengan sangat mudah. Bahkan mengingat ini, kontrol versi Final Cut Server mengandalkan menyimpan versi sebelumnya dari seluruh file proyek, itu tidak menggunakan diff. Saya tidak tahu ada DAM yang melakukannya karena alasan yang sudah dijawab oleh jawaban sebelumnya - ada terlalu banyak format kepemilikan (walaupun, ironisnya, banyak dari mereka sekarang mengandalkan XML sebagai tulang punggung untuk format file proyek tersebut) ).

FCS bagus karena relatif terjangkau. Tidak pernah ada yang analog dengan Premiere Pro. Sayangnya, saat ini, Anda harus membagikan banyak perubahan untuk mendapatkan kemampuan yang sama - terutama karena alat ini benar-benar dirancang untuk fasilitas posting, bukan editor tunggal. Mereka juga memerlukan integrasi / pengaturan yang berpotensi signifikan.

Berikut adalah beberapa opsi (Saya tidak memiliki hubungan dengan salah satu dari perusahaan-perusahaan ini, ini murni didasarkan pada penelitian saya mencari solusi yang serupa):


5

Kontrol versi tidak benar-benar memiliki banyak tempat dalam pengeditan video karena secara alami tidak merusak. Inti dari NLE (editor video non-linear) apa pun, output sebenarnya adalah sesuatu yang dikenal sebagai Editing Decision List atau EDL. Ini sangat analog dengan sejarah di Lightroom karena riwayat itu adalah catatan dari semua perubahan yang telah diterapkan secara berurutan.

NLE bekerja dari klip sumber. Mereka mengambil titik awal dan akhir klip itu untuk menempatkannya dalam timeline dan kemudian efek dapat diterapkan pada aset tersebut dalam urutan tertentu (berdasarkan penempatan efek), namun ini semua adalah keputusan pengeditan dan diterapkan dengan cepat ( atau mungkin diberikan ke file pratinjau sementara). Render keluaran akhir adalah hasil dari penerapan seluruh EDL ke klip sumber.

Anda bisa menyimpan versi proyek agar dapat kembali ke versi EDL sebelumnya jika Anda mau, tetapi ini biasanya tidak diperlukan kecuali Anda dengan sengaja bercabang untuk mencoba pendekatan alternatif untuk mengedit urutan ( dalam hal ini salinan dari timeline itu seringkali merupakan pilihan yang lebih baik.)


Apa yang Anda maksud dengan "non-destruktif" dan NLE di sini?
Pacerier

NLE adalah editor non-linear (nama teknis untuk sebagian besar perangkat lunak pengeditan video). Non-destruktif berarti bahwa perubahan tidak mengakibatkan penghancuran aset. Itu membentuk daftar perubahan yang harus dibuat, yang pada dasarnya adalah hal yang sama yang dibuat oleh kontrol versi. Ketika Anda membuat perubahan pada kode, itu merusak karena perubahan baru Anda menghancurkan yang lama. Dengan NLE, semua aset Anda tetap tidak berubah dan Anda hanya memodifikasi daftar bagian yang akan digunakan dan memfilter untuk diterapkan.
AJ Henderson

Jadi maksud Anda, kami dapat memberi tahu program pengeditan video "kembalilah ke versi 2.5", edit abit, lalu katakan "kembalikan ke versi 7" dan ia dapat melakukannya?
Pacerier

1
Tidak, maksudnya Anda selalu memiliki video master. Asumsinya adalah mereproduksi efek / pemotongan yang Anda miliki sebelumnya tidak sulit, atau bahwa menyimpan file proyek dengan VCS akan lebih berhasil daripada hanya memasukkan ulang keputusan edit. Jika bukan itu masalahnya, maka tentu saja, versi mengontrol file proyek Anda. Meskipun tanpa kemampuan untuk menggabungkan perubahan dari cabang-cabang yang berbeda, mungkin lebih berguna untuk hanya menuliskan nomor bingkai persis yang Anda perlukan waktu lama untuk mencari tahu adalah tempat yang tepat untuk pemotongan, atau sesuatu.
Peter Cordes

3

Jika Anda mengaktifkannya dalam preferensi After Effects dan Premiere secara otomatis membuat menyimpan file proyek tambahan. preferensi penyimpanan otomatis

Penghematan tambahan ini dapat digunakan untuk kembali ke versi sebelumnya, yang seperti implementasi kontrol versi yang sangat mendasar (Anda mungkin ingin menambah jumlah versi dari 5). FCP memiliki fungsi "restore from versi sebelumnya", yang bagus untuk ketika file-file proyek Anda rusak. Setelah efek memiliki (tetapi Premiere tidak memiliki, bayangkan) kemampuan untuk menyimpan proyek secara bertahap. Saya menggunakan ini setiap saat ketika saya membuat perubahan besar pada sebuah proyek, dan ingin dapat kembali ke bagasi utama, jadi untuk berbicara.

Untuk kontrol tambahan, Anda dapat saya bayangkan, menggunakan perangkat lunak kontrol versi untuk mengelola folder tempat Anda menyimpan file proyek dan penyimpanan otomatis, sehingga editor akan memeriksa pemotongan saat ini dan melakukan perubahan, selama semua media dapat diakses atau disalin secara terpusat ke mesin semua orang di jalur relatif yang sama. Itu tidak akan membiarkan Anda bercabang dan menggabungkan suntingan orang lain, seperti Anda dapat dengan kode - itu akan menjadi fitur yang menarik (saya akan mengatakan itu dapat diimplementasikan dengan skrip extendscript Adobe, selama keterampilan Anda hingga menulis ulang Git atau SVN dalam Javascript).


1
ya, untuk melakukan diff dan menggabungkan, baik VCS Anda harus memahami file save NLE Anda, atau NLE harus menyediakan diff / menggabungkan. (mis. Diberikan program yang dapat menggabungkan perubahan dalam file proyek, mengingat leluhur yang sama, saya pikir Anda dapat mengatur git untuk menggunakannya git mergetool, agar dapat menggabungkan komit pohon yang berisi file proyek yang dimodifikasi.)
Peter Cordes

Anda mungkin dapat menggunakan skrip extends untuk 'menyimpan' proyek Anda saat ini dengan mendapatkan semua properti dari semua item proyek Anda dan menyimpan data ke file. Tetapi bahkan untuk proyek yang cukup besar mungkin perlu waktu lama untuk dilakukan. Jika Anda melakukannya, Anda mungkin dapat membangun sistem kontrol versi.
stib

3

Sebagai seorang profesional video jangka panjang saya dapat membuktikan fakta bahwa kebutuhan akan bentuk VCS yang ringan, kuat, transparan dan terbuka sangat kurang di sebagian besar alur kerja media. Namun masalahnya multi-faceted dan merupakan masalah budaya serta teknis.

Secara tradisional kami telah bekerja di pabrik sosis seperti cara di mana sebuah proyek berwarna hijau dari skrip, pindah ke produksi, setelah dibungkus pergi ke pasca-produksi dan kemudian hasil akhir dikirim ke lengan distribusi yang kemudian memutar perangkat / platform output .

Saat ini pendekatan seperti pabrik adalah ilusi di mana perbedaan antara pasca-produksi dan distribusi tidak pernah jelas. Ada banyak bolak-balik dengan pemotongan / pengeditan untuk berbagai bahasa / pasar tidak pernah kembali dan melakukan penguasaan kembali untuk format terbaru misalnya. Lalu ada kebutuhan untuk mengakses versi final untuk tujuan pemasaran ... Sebagai akibatnya, kebutuhan tidak hanya pihak-pihak yang jauh tetapi juga orang-orang yang mungkin tidak pernah bertemu untuk memiliki katalog, pemahaman definitif tentang versi apa yang mereka butuhkan untuk dikerjakan adalah kuncinya. Ini meluas tidak hanya untuk master encode tetapi semua versi master untuk pasar yang berbeda serta versi aset yang digunakan untuk membuat masing-masing master.

Hanya sekarang komunitas teknologi media terlibat tentang apa sebenarnya versi itu dan secara teratur diperdebatkan karena banyaknya alur kerja dan masalah yang berbeda. Saya memecahnya sebagai versi yang berfungsi dan versi distribusi. Ada upaya untuk memperbaiki ini dalam distribusi dengan membuat format file arsip yang melacak versi di dalam dirinya sendiri (untuk memerangi fakta bahwa ada beberapa alat, platform dll) - ini disebut Interoperable Master Format (IMF - jangan bingung dengan bank) dan sedang dikendalikan melalui SMPTE. Hal yang baik tentang ini adalah bergerak untuk menyediakan interoperabilitas antara berbagai sistem manajemen aset digital (yang ingin mendukungnya) yang ada di luar sana - beberapa studio yang saya tahu memiliki sistem manajemen aset yang jumlahnya ratusan - ini akan bantu mereka secara internal apalagi untuk penyerahan eksternal. Tentu saja ia belum digunakan dalam lingkungan produksi karena ia dirancang sebagai format tingkat arsip (Netflix sekarang menggunakannya). Ini juga file yang sangat besar tanpa cara mudah membuatnya kecuali Anda memiliki modal yang diperlukan untuk berinvestasi dalam alat. Netflix memang merilis perangkat sumber terbuka yang menyediakan kemampuan membaca yang bagus. Ini juga file yang sangat besar tanpa cara mudah membuatnya kecuali Anda memiliki modal yang diperlukan untuk berinvestasi dalam alat. Netflix memang merilis perangkat sumber terbuka yang menyediakan kemampuan membaca yang bagus. Ini juga file yang sangat besar tanpa cara mudah membuatnya kecuali Anda memiliki modal yang diperlukan untuk berinvestasi dalam alat. Netflix memang merilis perangkat sumber terbuka yang menyediakan kemampuan membaca yang bagus.

Versi kerja atau tingkat produksi bijak saya merasa bahwa ada kebutuhan untuk menyediakan VCS (seperti bentuk git yang dimodifikasi mungkin) bahwa siapa pun dapat memanfaatkan tidak peduli seberapa besar atau kecil untuk memfasilitasi kerja jarak jauh. File media tentu saja jauh lebih besar daripada menukar kode atau pustaka tetapi keputusan yang dibuat pada file-file tersebut adalah komponen utama. I untuk satu ingin menguji bekerja dari jarak jauh melalui git melakukan jika hanya untuk menghindari konvensi penamaan 'file_Final_FINAL_MASTER_version3.mxf' konvensi penamaan yang dapat bolak-balik bertukar.


2

Saya memiliki pertanyaan yang sama, juga menjadi insinyur perangkat lunak berdasarkan perdagangan, memikirkan pekerjaan photoshop.

kita dapat memberi tahu program pengeditan video "kembalikan ke versi 2.5", edit sedikit, lalu katakan "kembalilah ke versi 7" dan apakah bisa melakukannya?

Saya menemukan bahwa Photoshop memungkinkan saya menetapkan versi yang disebutkan dalam sejarah, dan saya pikir itu tersimpan dalam file ...? Untuk revisi (entri dalam daftar riwayat) yang tidak bernama, node akan hilang dari tampilan saat edit dilakukan ke tempat sebelumnya (bercabang) dan tidak ada reflog yang terbuka.

Versi baru Premiere tampaknya memiliki log riwayat yang serupa dan saya kira sedang berkembang menuju arsitektur internal yang sama, di mana setiap perubahan adalah salinan lain dari proyek yang berbagi sebagian besar statistik dengan sebelumnya. Jika histori memiliki pos-pos pemeriksaan yang disimpan, itu sangat mirip dengan git store: setiap versi berisi referensi (dibagi) untuk elemen-elemen yang mendasarinya hingga ke definisi Segmen. Karena video itu sendiri tidak ada dalam file, itu cocok untuk menumbuhkan lebih banyak versi dengan sedikit peningkatan ukuran.

Saya melihat sebuah seminar di mana seseorang di tim pengembangan Photoshop menjelaskan arsitekturnya. Sepertinya entri riwayat yang Anda lihat analog dengan versi git, seperti tampilan gitk. Memberi nama versi sama dengan tag git. Anda dapat mengatur ulang ke revisi apa pun yang terlihat dengan mengarahkannya, dan mengatur ulang kembali juga. Tetapi membuat perubahan apa pun yang dimasukkan ke dalam sejarah sama seperti melakukan penyegaran penuh (shift atau ctrl F5) - Anda kehilangan apa pun yang tidak dirantai ke dari kepala cabang saat ini atau tag bernama (tapi saya pikir hal-hal seperti referensi sumber klon masih arahkan ke versi yang sekarang tidak terlihat).

Tapi bukan itu yang saya tulis untuk menyarankan. Saya mengatur volume NAS di mana proyek saya berada untuk membuat snapshot setiap 3 jam. Windows memiliki mekanisme pos pemeriksaan tetapi saya pikir itu tidak dapat dikonfigurasi; Mac Time Machine melakukan hal serupa.

Secara umum, Anda dapat mengarsipkan semua versi file yang disimpan , dan di Premiere yang tidak mengandung semua aset yang diimpor (konstan), jadi masuk akal untuk menyimpan semuanya, bahkan tanpa dapat menggunakan delta untuk menyimpan hanya apa yang diubah.

Hanya mempelajari ulang Premiere dan menjadi lebih agresif dengan mencoba berbagai hal, saya yakin bahwa saya dapat kembali jika lain kali saya mengerjakannya, saya menyesali apa yang saya lakukan, atau menemukan cara yang lebih baik dan ingin melakukannya lagi. Itu adalah sistem versi revisi yang efektif. Melakukannya di NAS, saya juga terlindungi dari BSOD yang merusak seluruh proyek saat menyimpan. :)

memperbarui sejarah adalah panjang pendek, standarnya adalah 32 entri. Itu kosong ketika proyek dimuat. Namun, simpan otomatis tidak hanya menyimpan file yang sama seperti yang kita lihat di sebagian besar program; melainkan memberi nomor pada mereka dan menyimpannya. Jadi, saya bisa melihat cap waktu file dan memuat salinan yang lebih lama, yang memberi saya riwayat versi 15 menit pos pemeriksaan. Dalam kasus saya, setiap file adalah 44K, yang tidak seberapa dibandingkan dengan ukuran aset — ukurannya 76 milidetik audio, atau 1/7 dari frame rekaman kartu SD kelas 10 .

Jika Anda ingin hadir untuk menjaga pos pemeriksaan dengan nama yang bermakna, cukup Simpan salinan Sebagai. Tetapi penyimpanan otomatis, diatur ke frekuensi tinggi, dapat digunakan untuk meninjau kembali keadaan apa pun (saat itu granulatity) tanpa perencanaan terlebih dahulu, dengan sedikit usaha.

Catatan untuk non-insinyur yang tidak terbiasa dengan kontrol versi: Selain kemampuan untuk melacak kembali pekerjaan Anda dengan cara yang jelas, saya juga sering menggunakannya untuk memeriksa apa yang baru saja saya ubah, atau membandingkan dengan keadaan sebelum memulai tugas saat ini. , atau bandingkan dengan ayat terakhir yang telah dibagikan dengan grup.

Karena Premeire sekarang mendukung pembukaan beberapa proyek di ruang kerja, akan layak untuk memiliki pengaturan ruang kerja pengaturan jendela untuk membandingkan dua jadwal. Artinya, membuat lebih efektif menggunakan memiliki orang-orang versi, bukan hanya untuk cadangan. Saya sering memberi tahu programmer yang tidak menggunakan git bagaimana itu menjadi alat tujuan umum, seperti editor teks.

Saya bertanya-tanya bagaimana pembuat film profesional menangani kontrol versi, jika ada lebih dari ad-hoc? Desain penyimpanan otomatis tampaknya cukup bertujuan, dan alat groupware penulisan naskah terintegrasi memang memiliki pelacakan revisi yang terlihat jelas.


0

Memiliki kontrol versi untuk file video itu sendiri tidak praktis karena pertama, mereka sangat besar, kedua mereka bergerak (apakah Anda akan menjaga setiap frame?), Ketiga, mereka tidak dapat diubah. Artinya, file asli tidak pernah berubah saat mengedit.

Tetapi kontrol versi untuk file proyek sangat masuk akal. Saat ini, setelah setiap perubahan signifikan saya membuat file proyek baru dan memberinya beberapa nama deskriptif - apa yang saya lakukan, apa yang saya tambahkan dan apa yang saya hapus. Intinya, saya harus menjaga sejarah secara manual dengan menggunakan nama file. Memiliki file proyek di bawah kontrol versi adalah ide bagus, mengapa saya belum memikirkan ini sebelumnya!

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.