9 puan yazan GN⁺ 2025-01-15 | 1 yorum | WhatsApp'ta paylaş
  • FFmpeg işlemlerinde seçenek kombinasyonları kolayca karmaşıklaşabilir; FFmpeg By Example, gerçek komut örnekleriyle gereken medya işleme yöntemini hızlıca bulmayı sağlayan bir dokümantasyon sitesi
  • GitHub deposu, Discord topluluğu ve katkı sayfası da sunarak kullanıcıların yeni FFmpeg kullanım fikirlerini doğrudan göndermesine imkân tanıyor
  • testsrc filtresi örneğinde olduğu gibi giriş kaynağını, çözünürlüğü, kare hızını ve çıktı dosyasını tek bir komutta göstererek komut yapısını aynen takip etmeyi mümkün kılıyor
  • Örnekler bit hızı hesaplama, görsel yeniden boyutlandırma, ses gürültüsü azaltma, geçiş efektleri, stream mapping, donanım hızlandırma, metadata işleme gibi medya işleme işlerinin genelini kapsıyor
  • Her örnek etiketlere ve ayrı sayfalara ayrıldığı için belirli bir filtreye ya da dönüştürme amacına göre gereken FFmpeg komutunu bulmak kolay

Örnek odaklı FFmpeg dokümantasyon sitesi

  • FFmpeg By Example, FFmpeg kullanmanın çeşitli yollarını örnekler bazında derleyen bir web sitesi
  • Topluluk katılımı ve katkı için bağlantılar da sunuyor

testsrc test videosu oluşturma örneği

ffmpeg -f lavfi -i testsrc=duration=10:size=1280x720:rate=30 testsrc.mpg

Kodlama, dönüştürme ve donanım hızlandırma

Ses işleme

Görseller ve animasyon

Filtreler ve görsel efektler

Çıkarma, analiz ve metadata

Üretim kaynakları ve çıktı pipe'ları

1 yorum

 
GN⁺ 2025-01-15
Hacker News yorumları
  • ffmpeg kullanmanın keyfi %1000 arttı
    Eskiden sıkıcı biçimde Google'da Stack Overflow yanıtlarını arayıp birleştirerek komut oluştururdum; artık ChatGPT komutu benim yerime yazdığı için çok daha rahat

    • LLM sayesinde ffmpeg'i haftada birkaç kez kullanıyorum
      llm cmd aracımın en iyi kullanım alanı:

      uv tool install llm
      llm install llm-cmd

      llm cmd use ffmpeg to extract audio from myfile.mov and save that as mp3

      https://github.com/simonw/llm-cmd

    • Uzun süre ffmpeg'i düzenli ifadelerle aynı kutuya koymuştum: “Bunu gerçekten öğrenmeliyim ama muhtemelen nefret edeceğim” hissi vardı
      Sonra ChatGPT çıktı ve ikisini de çözdü

    • Benim için de aynı. Bu tür işleri yapay zeka tamamen devraldı; ben sadece hata izlerini kopyalayıp yapıştıran bir aracıdan ibaretim

    • Başka birçok araç da çıktı ama bu tür zincirleme komutları epey basitleştiren bir betiği az önce yaptım: llmpeg https://github.com/jjcm/llmpeg
      ffmpeg kuruluysa ve OpenAI ortam değişkeni API anahtarı ayarlanmışsa hemen çalışacaktır

      Demo: https://image.non.io/1c7a92ef-0917-49ef-9460-6298c7a9116c.we...

    • Karmaşık filtrelerin nasıl çalıştığını öğrenince ffmpeg kullanma deneyimim daha da iyileşti

  • Dijitalleştirdiğim ev tipi video kasetleri sahne algılamayla kliplere dönüştürme yöntemini derleyip yayımlamam gerektiği aklıma geldi
    Birileri arayabilir diye, oldukça iyi çalışan gist'i bırakıyorum [0]. Ancak kamera flaşı veya sarsıntıya kandığı durumlar oldu; bu yüzden başlangıç/bitiş dosyalarını ayrı verip ffmpeg ile tekrar birleştirmem gerekti [1]

    Tuhaf olan, son Mac güncellemesinde -c:v h264_videotoolbox olmadan daha iyi performans almış olmamdı. Sequoia'da bir performans gerilemesi olabilir, emin değilim. Nvidia GPU'lu bir Windows makinesindeki karşılık gelen bayrak -c:v h264_nvenc. ffmpeg'in bunu neden otomatik algılamadığını merak ediyorum. Bununla yaklaşık 8 kat performans artışı elde ettim
    Şirkette maaşımın hakkını gerçekten verdiğim tek an, video işleme için GPU'lu bir bulut sunucusuna pahalı biçimde daha fazla harcama yapmak üzereyken, kurulu ffmpeg'in GPU hızlandırması olmadan derlenmiş olduğunu fark ettiğim andı

    [0] https://gist.githubusercontent.com/nielsbom/c86c504fa5fd61ae...

    [1] https://gist.githubusercontent.com/jazzyjackson/bf9282df0a40...

    • Bulut CPU'larının sorunu, tüketici sınıfı CPU'larda bulunan donanımsal video kodlayıcının olmaması; bu yüzden çok daha pahalı GPU makinelerine geçmek gerekiyor
      Açıkçası bulutta donanım hızlandırma kullanarak düzgün bir fiyat karşılaştırması yapmadım; bunu gerçekten denediğinizi ve maliyet açısından fena olmadığını mı kastediyorsunuz, merak ettim

    • ffmpeg ile boş sahne algılama denedim
      SFO uçuş rotasına bakan bir kameram var; hareket olmayan tüm kareleri kaldırınca, sıkıcı bölümler olmadan sadece uçakların geçtiği kesintisiz bir video kaldı

    • -c:v h264_nvenc, aynı anda birden çok videoyu kodlayan toplu kodlama için kullanışlıdır. Çünkü kodlama verimini artırabilir
      Ancak daha önce sınırlı biçimde denediğimde çıktı kalitesi libx264'ten biraz daha kötüydü. Bir geçici çözümü var mı bilmiyorum ama bunu yaşayan tek kişi ben değildim

    • ffmpeg'in bunu otomatik algılamamasının nedeni, donanımsal kodlamanın genellikle daha dar ayar aralığına sahip olması, ince ayarlı yazılım codec'lerine kıyasla daha fazla ödün gerektirmesi ve aynı parametrelerle bile tam olarak aynı sonucu üretmemesidir
      Üstelik sistemde seçilebilecek birden çok donanım API'si olması da sık görülür ve özellikleri de birbirinden farklıdır

      FFmpeg karmaşık bir komut satırı aracıdır ve ayrıntıları öğrenmeye istekli kullanıcıları hedefler; bu yüzden varsayımlara dayanarak varsayılanlar belirlemenin doğru olup olmadığından emin değilim

    • Parçaya bakınca deinterlace yapılmıyor gibi görünüyor
      Dijitalleştirme öncesi klip zaten deinterlace edildiyse sorun yok; değilse, interlaced materyali progressive olarak kodlayıp kaliteyi bozmuş olursunuz. bwdif filtresini ekleyip 30i içeriğin 60p olarak kodlanmasını denemek iyi olur. Orijinal video kasete daha yakın görünecektir

  • Zamanla ffmpeg'in birçok kısmına oldukça aşina oldum. CLI'ın kendi içinde bir mantığı var ve sıraya bağımlı. Tüm Unix CLI'ları böyle değil
    Son zamanlarda biraz daha anlaşılması zor özelliklerle uğraşıyorum. Örneğin oldukça yavaş bir makinede video kameranın ham görüntüsünü doğrudan kaydetmek gibi. Bir mikroskop yaptım ve kameradan 120FPS'te ham video biçiminde (YUYV 1280x720) kareler okuyorum; bunları olduğu gibi diske kaydedince dakikada gigabaytlarca büyüyor. Disk ucuz ama israf gibi geldiği için, görüntüyü hızlıca ve neredeyse kayıpsız sıkıştırarak kaydedebilecek yöntemlere baktım

    ffmpeg'de RGB24 dönüşümünün çok yavaş olduğunu fark ettim; komut satırını epey kurcaladıktan sonra şunda karar kıldım:

    ffmpeg -f rawvideo -pix_fmt yuyv422 -s 1280x720 -i test.raw -vcodec libx264 -pix_fmt yuv420p movie.mp4 -crf 13 -y

Ham videoda konteyner olmadığı için “piksel biçimi” veya “görüntü boyutu” gibi meta veriler yoktur; bu yüzden bunları doğrudan vermek gerekir. Sıra bağımlıdır: -i test.raw öncesindeki her şey girişin decode edilmesi, sonrasındaki her şey de çıktının yazılması içindir. Yalnızca çok küçük bir piksel biçimi dönüşümü yapar (ffmpeg bunu çok hızlı işleyebilir) ve veriyi konteyneri olan, neredeyse kayıpsız bir biçimde yazar. Çoğu durumda en iyi konteyner .mkv idi

Komut satırını sevmediğim için sonunda ffmpeg-python kullandım ve aşağıdaki kodun komut satırını oluşturmasını sağladım:

self.process = (
ffmpeg.
input(
"pipe:",
format="rawvideo",
pix_fmt="yuyv422",
s="{}x{}".format(1280, 720),
threads=8
)
.output(
fname, pix_fmt="yuv422p", vcodec="libx264", crf=13
)
.overwrite_output()
.global_args("-threads", "8")
.run_async(pipe_stdin=True)
)

Sonra pratikte kareleri o sürecin standart girdisine write() ediyorum. Makinede 12 çekirdek var ve mikroskobu çalıştırmak için her zaman en az 2 tanesini kullandığım için iş parçacığı sayısını sınırlamam gerekiyordu

Hâlâ daha iyi ve daha hızlı kayıpsız YUV kodlama arıyorum

  • Sıra bağımlı olması yerinde. Unix pipeline’ları da bileşenlerin sırasına bağlıdır; karmaşık FFMpeg çağrıları da buna benzer işler yapar
    ffmpeg-python gibi “akıcı arayüz” estetiğini seven çok kişi var, ama Python’da bu çoğu zaman Python’a uygun değilmiş gibi görülür. Benim anladığım kadarıyla ffmpeg-python, komut satırı sırasını yakından yansıtacak şekilde tasarlanmış

    Standart kütüphane ve yerleşik tip tasarımının güçlendirdiği tercih, güçlü bir https://en.wikipedia.org/wiki/Command%E2%80%93query_separati... yaklaşımıdır. Bu ilkeye göre kabaca şöyle görünürdü:

    ffmpeg(global_args=..., overwrite_output=True).process_async(piped_input(...), output(...))

    Girişi ayrı bir yapılandırma süreci yaparsanız farklı çalışma zamanı tipleri oluşur ve işleme koduna da standart girdiden okuması gerektiği sinyalini verebilirsiniz

  • Daha fazla aramana gerek yok: FFV1 https://trac.ffmpeg.org/wiki/Encode/FFV1

  • Tek kelime önermek istiyorum: ramdisk
    Ara aşama işlemler yapıyor ama saklamak istemediğin dosyalar varsa çözüm ramdisk. Gerçekten iyi

  • FFmpeg konusunda uzman kişilerin biriktirdiği bilgileri derleyip yönettiği bir web sitesi sanmıştım, ama ilk tıkladığım örnekte hemen hayal kırıklığına uğradım
    https://www.ffmpegbyexample.com/examples/l1bilxyl/get_the_du...

    String işlemek için iki araç daha çağırmamak gerekir. FFprobe tek başına süreyi veya istediğiniz değeri doğrudan verebilir:

    ffprobe -loglevel quiet -output_format csv=p=0 -show_entries format=duration video.mp4

    İlk çalışan şeyde durmamalı; çalıştıktan sonra daha iyi bir yol olup olmadığını düşünmelisiniz

    • Asıl yazının yazarıyım. Buna “çılgınca” demek biraz abartı değil mi diye düşünüyorum
      Yine de önerdiğiniz çözüm daha çok hoşuma gitti
  • Güzel. Kullandığım ffmpeg cheat sheet aklıma geldi. ffmpeg’i sık kullanan herkesin benzer bir not koleksiyonu vardır sanırım
    https://github.com/fastily/cheatsheet/blob/master/ffmpeg.md

  • FFmpeg, o kadar seyrek kullandığım için doğru sözdiziminin asla aklımda kalmadığı araçlardan biri. Sonunda gereken komut satırını LLM’e yazdırıyorum
    Benzer şekilde zorlandığım tek araç, LSI Logic’in 1990’lar tarzı MegaCLI aracıydı. Onu da yılda neredeyse hiç kullanmam ama baskı altında doğru şekilde kullanmak gereken türdendi

    • FFMPEG’i 15 yıldan uzun süredir kullanıyorum ama hâlâ komutları neredeyse hiç hatırlamıyorum. Yine de FFMPEG kullanırken LLM gerçekten harika
      ChatGPT ve Claude’a “videoyu mkv’ye remux et, subtitle.srt’yi dosyaya dahil et ve yalnızca 0:00:05 ile 0:01:00 arasını istiyorum” derseniz gayet iyi hallediyor. Merak edenler için sonuç şuydu: ffmpeg -i input.mp4 -i subtitle.srt -ss 00:00:05 -to 00:01:00 -map 0 -map 1 -c copy -c:s mov_text output.mkv

      Yalnızca ffmpeg komutu üretmeyi hedeflesek ne kadar küçük bir LLM yapılabilir merak ediyorum. Statik bir web sayfasına koyup yerelde çalıştırılabilecek kadar küçük olabilir mi acaba?

    • 15 yıldır sık kullandığım sözdizimini içeren kişisel not belgesi tutuyorum. O da yetmezse bash geçmişini grep’liyorum

    • Ben de aynıyım. Aklımda kalan tek şey X biçiminden .mp4’e dönüştürmek. Geri kalan her şeyi her seferinde yeniden aramam gerekiyor
      İlgili XKCD https://xkcd.com/1168/

    • Birkaç gün önce yarı şaka yarı ciddi, LLM bana istediğim ffmpeg bayraklarını söyleyecekse bütün yağmur ormanlarını yakmaya değer olabilir demiştim

  • GStreamer olduğunu da unutmamak gerek. Pipeline tabanlı olduğu için komut satırı ve belgeleri ffmpeg’e göre biraz daha anlaşılır; bileşenleri bir araya getirme biçimi de biraz daha akla yatkın
    Ben ağır video işlerinde ffmpeg’i tamamen bıraktım, yalnızca GStreamer kullanıyorum

    • Programatik olarak pipeline oluştururken GStreamer daha fazla denetim ve daha kullanışlı bir API sağlayabiliyor
      Ama tek seferlik işler için ffmpeg çok daha kullanıcı dostu görünüyor. Örneğin ffmpeg’de makul x264 varsayılanları var; gst-launch ile kaliteli x264 encoding yapmak içinse ne yaptığınızı gerçekten bilmeniz gerekiyor
    • FFmpeg’in de pipeline tabanlı olduğunu düşünüyordum. Filter graph yok mu? Bir şeyi mi kaçırıyorum
      Kaynaklar, sink’ler ve dönüştürme filtrelerinden oluşan karmaşık graph’lar kurabiliyor
    • GStreamer terk edilmiş bir proje gibi hissettiriyor. Yakın zamanda büyük bir güvenlik açığı da vardı ve belgeleri de epey bozuk
  • Bu siteyi tamamlamak için iyi olabilecek bir ffmpeg kitabı GitHub deposu var:
    https://github.com/jdriselvato/FFmpeg-For-Beginners-Ebook

  • ffmpeg bana hep bir GUI uygulamasının TUI biçimine zorla sıkıştırılmış hâli gibi gelmiştir
    C API’sini de birkaç kez tatsız biçimde kullandım; birçok açıdan sezgisel olsa da hatalı durumları ifade etmek fazla kolay. “Sadece çalışan” bir gerçek zamanlı AV1 encoding framework’ü olsa güzel olurdu

    • Varsayılan olarak önce GUI alternatifi olan HandBrake’e yöneldiğim neredeyse tek araç bu. Toplu işleme yaptığım zamanlar istisna
      Saf ffmpeg GUI’leri de birkaç tane var. Video işlerinde komut satırının kafamdaki işleme biçimiyle pek uyuşmayan bir yanı var

    • API olarak GStreamer’ı önerebilirim. Rust binding’lerini kullandığım için C API’ye çok aşina değilim ama iyi görünüyordu
      GObject yüzünden lafı uzayan kısımlar var; ama mantığını kavradıktan sonra API’deki tüm nesnelerle tutarlı biçimde etkileşime geçebiliyorsunuz. Gerçekten çok gerekli karmaşıklık var (video zordur), fakat tasarımı, implementasyonu ve dokümantasyonu oldukça iyi

      Genel kullanım senaryolarında Bins (decodebin, transcodebin, playbin) işi epey kolaylaştırıyor. Daha karmaşık kullanım senaryoları bile tasarımın esnekliği sayesinde mümkün

    • İçgörüyü beğendim ama TUI grafiksel bir şeydir; ffmpeg ise sadece CLI
      Bir TUI aracı olsa harika olurdu. https://github.com/Twinklebear/fbed gibi, ama özellikleri daha tamamlanmış bir şey olsa iyi olurdu

  • Linux sistemlerde ffmpeg’i statik build etmeyi seviyorum. Çünkü dağıtım sürümü bazen çok eski oluyor ya da tercih ettiğim modüller eksik olabiliyor
    Bu container’laştırılmış sürüm çok işime yaradı: https://github.com/wader/static-ffmpeg