1 puan yazan GN⁺ 2024-02-09 | 1 yorum | WhatsApp'ta paylaş
  • Aras, Blender’da Video Sequence Editor (VSE) olduğunu bile bilmiyordu; ancak Blender HQ ziyaretinden sonra yaklaşık iki ay boyunca yarı zamanlı olarak Blender 4.1 için performans ve kalite iyileştirmelerine katkı yaptı
  • En dikkat çekici değişiklik zaman çizelgesi tepkiselliği oldu; yaklaşık 3000 strip’in göründüğü Sprite Fright projesinde kaydırma ve panning arayüzü yaklaşık 15 fps’ten 60 fps’in üzerine çıktı
  • ffmpeg tabanlı RGB↔YUV dönüşümü, Audaspace ses yeniden örnekleme, görüntü dönüşümü ve filtreleme, VSE efekt işleme için çoklu iş parçacığı, SIMD ve matematiksel sadeleştirme uygulandı
  • Blender Studio’nun üç veri setinde, yazarın PC’si baz alındığında VSE film son render süresi yaklaşık 2 kat hızlandı; Sprite Fright render süresi de yaklaşık 13 dakikadan 7 dakikaya düştü
  • Toplam 37 pull request incelendi ve birleştirildi; Blender 4.1’e bu değişiklikler şu anda dahil ediliyor ve sonraki VSE çalışmaları Blender 4.2’den itibaren devam edecek

Blender VSE’ye katkı yapma süreci

  • Aras, Unity’nin Unite 2023 etkinliğine katılmak için Amsterdam’a gitti ve boş zamanında Blender HQ'yu ziyaret etti
  • Orada Francesco ve Sergey, VSE’ye katkı verip vermeyeceğini sordu; bunun ardından Blender’ın Video Sequence Editor bölümünü kurcalamaya başladı
  • Video düzenleme, zaman çizelgesi, sequencer, color grading, ffmpeg ve ses miksajı konularını pek bilmese de, tartışma yaratma ihtimali düşük olan performans optimizasyonu ile başladı
  • Yaklaşık iki aylık yarı zamanlı çalışmanın sonunda Blender 4.1’e girecek bir iyileştirme paketi ortaya çıktı
    • Blender 4.1 beta aşamasına geldi ve genel daily builds üzerinden indirilebiliyor

Zaman çizelgesi çizimi ve arayüz tepkiselliği

  • VSE zaman çizelgesi ekranın alt kısmındaki alandır; Sprite Fright edit tam proje görünümünde uzaklaştırıldığında aynı anda yaklaşık 3000 strip görünüyor
  • Önceden bu zaman çizelgesinde yalnızca kaydırma ve panning yapmak bile arayüz yenilenmesini yaklaşık 15 fps seviyesinde tutuyordu
  • Değişikliklerden sonra bu değer 60 fps’in üzerine çıktı
  • Darboğaz, grafik API draw call’larını her seferinde iki üçgenlik parçalara ayırarak gönderen yapıdaydı; Superluminal profiler’da sürenin büyük kısmı “bir quad çizmeye başla” ve “bir quad çizmeyi bitir” fonksiyonlarında harcanıyordu
  • Bu sırada ses waveform gösterimindeki hatalı davranış da düzeltildi ve arayüz elden geçirildi; waveform gösterimi artık varsayılan olarak açık

Scope gösteriminde kalite ve hız iyileştirmeleri

  • VSE; görüntü histogramı, waveform ve vectorscope gibi yaygın scope görüntüleme seçenekleri sunuyor
  • Histogram daha önce pikselli bir görüntü ve çok güçlü doygunlukla çiziliyordu; artık daha yumuşak polygon’lar, grid ve daha düşük doygunlukla gösteriliyor
  • Waveform’un parade seçeneği çok hızlı doygunluğa ulaşıyordu; çoklu iş parçacığı uygulandıktan sonra 15 kat hızlandı
  • Vectorscope’un dıştaki renk altıgeni ciddi biçimde pikselleniyordu; görüntü düzenleyicideki vectorscope için güncellenen design kopyalanıp uygulandı
  • “Aşırı pozlanan alanları gösterme”ye karşılık gelen zebra stripes seçeneği de 2 ila 3 kat hızlandı
  • Tüm scope’ların ve görüntü düzenleyici scope’larının bir gün GPU compute shader ile işlenmesi gerektiği düşüncesi de ekleniyor

ffmpeg RGB↔YUV dönüşümü optimizasyonu

  • Blender, ses ve video okuma-yazma için ağırlıklı olarak ffmpeg kütüphanesini kullanıyor
  • Blender içinde ffmpeg komut satırı aracı değil, libavcodec gibi kod kütüphaneleri kullanılıyor; libswscale ise film karelerinin RGB↔YUV dönüşümünü üstleniyor
  • libswscale çok iş parçacıklı dönüşümü destekliyor, ancak yalnızca sws_getContext() ve sws_scale() kullanılırsa tamamen tek iş parçacıklı çalışıyor
  • Çoklu iş parçacığı kullanmak için başlatma aşamasında "threads" parametresinin ayarlanması gerekiyor; bu yüzden sws_alloc_context(), av_opt_set_int() ve sws_init_context() doğrudan kullanılmalı
  • Ayrıca sws_scale() kendi içinde çoklu iş parçacığı yapmadığı için sws_scale_frame() kullanılmak zorunda kaldı; bu süreçte AVFrame oluşturma biçimindeki bir sorun da ortaya çıktı
  • Sonuç olarak film dosyası yazarken RGB→YUV dönüşümü belirgin biçimde hızlandı
  • Film dosyası okuma tarafında da çok iş parçacıklı YUV→RGB dönüşümü kullanıldı ve vertical flip aynı işe birleştirildi

Ses yeniden örnekleme

  • VSE’de video render edilirken, “video veya ses karesi üretme” süresinin neredeyse yarısının Blender’ın kullandığı ses kütüphanesi Audaspace içinde harcandığı görüldü
  • Darboğaz ses kodlama değil, kodlama öncesi miksaj tarafındaydı; sürenin büyük kısmı, 48 kHz’lik bir filme 44.1 kHz gibi ses strip’leri karıştığında gereken yeniden örneklemeye gidiyordu
  • Audaspace’te iki yeniden örnekleme modu vardı
    • Blender içi oynatma: örnekler arasında doğrusal enterpolasyon yapan Linear resampler
    • Film render’ı: Julius O Smith’s algorithm tabanlı resampler
  • Resampler kalitesi, frekansı artan tek tonlu sentetik bir sesi yeniden örnekledikten sonra spectrogram üzerinden karşılaştırıldı
    • Hedef, Audacity'nin “best” ayarındaki gibi mümkün olduğunca az ek frekans üreten bir sonuçtu
  • Audaspace’in önizleme için kullandığı yeniden örnekleme hesaplama açısından hızlıydı ama çok sayıda ek frekans üretiyordu; render için kullanılan yeniden örnekleme ise spectrogram kalitesi açısından iyiydi
  • Audaspace’e yeni bir orta seviye yeniden örnekleme kalitesi eklendi; yazarın gözlemine göre neredeyse aynı sonucu verirken hesaplama maliyeti yaklaşık 3 kat daha düşüktü
  • Blender artık render sırasında bu orta seviye ayarı kullanıyor
    • Windows Ryzen 5950X PC’de Sprite Fright için 2000 karelik render süresi 92 saniyeden 73 saniyeye indi
    • İlgili PR: #116059

Görüntü dönüşümü ve filtreleme

  • VSE’de görüntü, film, metin ve scene gibi görsel çıktı üreten strip’lere konum, döndürme, ölçekleme ve crop uygulanabiliyor
  • Bu dönüşümler, strip’in ürettiği görüntünün yeni bir görüntüye dönüştürülmesi şeklinde yapılıyor; bu işlem daha önce de CPU üzerinde çok iş parçacıklı olarak yürütülüyordu
  • GPU yerine CPU kullanılmasının nedeni henüz bir GPU uygulamasının olmaması ve GPU’suz render farm’larda render almak isteyen kullanım senaryoları için şu anda CPU fallback’inin gerekli olması
  • Half-pixel hatalarının düzeltilmesi

    • Mevcut kodda çeşitli yarım piksel sapması hataları vardı; çoğu durumda bunlar birbirini dengeliyor ya da görünmüyordu, ancak bazı durumlarda ortaya çıkıyordu
    • Küçük bir görüntü 16 kat büyütüldüğünde Bilinear filtre, görüntüyü kaynak pikselin yarısı kadar kaydırıyor ve arka plan rengi olan magenta’nın araya girmesine yol açıyordu
    • Tersine, görüntü tam 2 kat küçültüldüğünde Bilinear filtrenin hiç filtreleme yapmaması gibi bir sorun da vardı
    • Bilinear ve diğer filtrelerdeki “bir miktar kayma” hataları düzeltildi
    • İlgili PR: #116628
  • Bilinear şeffaf kenar davranışı

    • Blender 4.0 öncesi VSE’de Nearest, Bilinear ve Subsampled3x3 olmak üzere üç filtre seçeneği vardı; bunlardan yalnızca Bilinear, sonuç görüntüsünün etrafına kaynak texel’in yarı genişliği kadar şeffaflık ekliyordu
    • Bu davranış medya büyütüldüğünde fark ediliyordu ve bu farkın neden ortaya çıktığını hatırlayan kimse kalmamıştı
    • VSE’nin Bilinear filtre kodundaki “şeffaflıkla blend etme” davranışı kaldırıldı
    • Ancak yalnızca döndürme uygulandığında önceki şeffaflık işlemi kenarlarda bir tür anti-aliasing sağladığı için, bunun yerine hedef görüntünün kenar piksellerine transparency anti-aliasing uygulandı
    • İlgili PR: #117717
  • Cubic, Box, Auto filtreler

    • Genel VSE strip dönüşümlerinde cubic filtre seçeneği yoktu; yalnızca özel Transform Effect strip’inde bulunuyordu
    • Blender’da “Bicubic” aslında Cubic B-Spline filtresi anlamına geliyor; bu da Mitchell-Netravali filtresinin B=1, C=0 katsayılarına eşdeğer
    • Yazar bunu “ringing yok ama bulanıklığı fazla” bir seçenek olarak özetliyor
    • VSE’ye iki tür cubic filtering seçeneği eklendi
    • İlgili PR: #117100, #117517
    • Blender 3.5’teki “Subsampled 3x3” filtresi aslında 3x3 boyutuna sabitlenmiş bir box filter’dı ve 3x3 dışındaki oranlarda küçültmede bozulmaya başlıyordu
    • Bu filtre, sabit 3x3 yerine uyarlanmış bir Box filter ile değiştirildi
    • İlgili PR: #117584
    • Kullanıcının seçmesi gereken filtre sayısı arttığı için, VSE strip’leri için varsayılan olarak Auto filter option eklendi
    • İlgili PR: #117853
    • Ölçekleme ve döndürme yoksa Nearest
    • 2 katın üzerinde büyütmede Cubic Mitchell
    • 2 katın üzerinde küçültmede Box
    • Diğer durumlarda Bilinear
  • Filtreleme performansı iyileştirmeleri

    • Görüntü filtreleme süreci de hızlandı
    • İç döngülerde virtual function kaldırıldı, Bilinear filtrelemeye kısmi SIMD uygulandı: #115653
    • Cubic filtreleme sadeleştirildi ve SIMD eklendi: #117100
    • Box filter için matematik sadeleştirildi: #117125
    • Tüm ekranı kaplayan solid image altındaki öğeleri atlama optimizasyonunun ölçekleme olduğunda çalışmaması sorunu düzeltildi: #117786
    • Yazarın PC’sinde, 3840x2160 projede tek bir 1920x1080 görüntü 2 kat büyütülüp Bilinear filtreleme kullanıldığında sequencer preview’un tamamını çizme süresi 36.8 ms’den 15.9 ms’ye indi
    • Yükseltme filtrelerini karşılaştırmak için etkileşimli bir sayfa da sunuluyor: aras-p.info/img/misc/upsample_filter_comp_2024

VSE efekt optimizasyonları

  • Blender Studio’nun gerçek film veri setleri efektleri yoğun kullanmasa da, kodda göze çarpan yerler ağırlıklı olmak üzere VSE efektleri de optimize edildi
  • Değişikliklerin çoğu çoklu iş parçacığı uygulanmasıyla ilgili
    • Glow effect: çoklu iş parçacığı eklendi, 6 ila 10 kat hızlandı #115818
    • Wipe effect: çoklu iş parçacığı eklendi, Clock wipe’taki aşırı trigonometrik hesaplama sadeleştirildi, 6 ila 20 kat hızlandı #115837
    • Gamma Cross effect: tek bir karekök çağrısından kaçınmak için kullanılan karmaşık tablo ve enterpolasyon yaklaşımı değiştirildi, 4 kat hızlandı #115801
    • Gaussian Blur effect: yinelenen hesaplamalar önlenerek 1.5 kat hızlandı #116089

Son render süresindeki değişim

  • Blender Studio’dan alınan üç veri setine göre, yazarın PC’sinde VSE film son render süresi yaklaşık 2 kat hızlandı
  • Sprite Fright edit render süresi yaklaşık 13 dakikadan 7 dakikaya düştü
  • Yazar daha fazla hız artışı umuyor ve bunu “2 kat hızlanmayı üç kez daha yaparsak oldukça iyi olur” şeklinde ifade ediyor

Çalışma biçimi ve sonraki adımlar

  • Kullanıcının gördüğü değişikliklerin dışında test ekleme, refactor ve temizlik işleri için de pull request’ler vardı; toplam 37 pull request tamamlandı, incelendi ve birleştirildi
  • Yazar, bu düzeyde bir işi “gerçek bir işte” yapmanın zor olacağını düşünüyor
    • Unity’de 2015-2022 arasında olsaydı, aynı sürede yukarıdaki işlerin ancak yaklaşık %30’unu, belki daha da azını yapabileceğini söylüyor
    • 2010 civarındaki “ancient” Unity döneminde bunun mümkün olabileceğini de ekliyor
  • Şirket ölçeği, süreçler, beklentiler, iletişim ve politika gibi unsurlar bir araya geldiğinde, ücretli bir şirket ortamında aynı işin daha yavaş ilerlemesi ya da yarıda iptal edilmesi mümkün olabiliyor
  • Blender’ın, süreçlerin insanlara yardım etmek yerine heves kıran ve işleri yavaşlatan bir ölçek, karmaşıklık ve iş akışına dönüşmemesini umuyor
  • Blender 4.1 beta aşamasına geldiği için özellik tarafı tamamlanmış durumda; VSE ile ilgili 4.1 değişiklikleri şu anda release notes içinde yer alıyor
  • Blender 4.2 çalışmaları başlıyor ve bundan sonra da net bir plan olmadan VSE ile uğraşmayı sürdürmeyi düşünüyor

1 yorum

 
GN⁺ 2024-02-09
Hacker News yorumları
  • “Gerçek bir iş” olsaydı böyle bir şeyi yapamazdım sanırım
    Kariyerimde yolunda gitmeyen bir şey varsa, hiç de özgün olmayan matematiği kendim çözdüğüm ücretsiz bir projede iki ayda normalde iki yılda yaptığımdan fazlasını yaparken, para aldığım projelerde sonuçlarımın genelde ortalama kalması gibi bir ayrım oluşmasıydı
    Gerçekten çok uğraştım ama bunun ortasını bulamadım; geçen yıl ücretsiz yaptığım bir iş için para alma ihtimali doğunca da sonunda ona hiç dokunamaz hale geldim

    • Yalnız değilsin. Hayatım boyunca benzer şeyler yaşadım ve bu yüzden insanların motivasyon hakkında söyledikleri her şeyden, örneğin yalnızca kâr ve ücretlerin işi bitirmeyi sağladığı fikrinden şüphe etmeye başladım
      Sonra Marx’ın yabancılaşma teorisiyle karşılaştım ve her şey çok daha anlamlı gelmeye başladı. Marx, işin sağlıklı insanların başlıca faaliyetlerinden biri olduğu gözleminden yola çıkıyordu; ama bunu başkası için çalışmak ve kendi emeğinin ürününe yabancılaşmakla karıştırmamak gerektiğini düşünüyordu
      https://en.m.wikipedia.org/wiki/Marx's_theory_of_alienation
    • Şimdiye kadar yaptığım en iyi ya da en ilginç işlerin hiçbiri para aldığım işler değildi
    • Proje yönetimi bu tür işlerin hepsini öldürüyor
      Bazı yerlerde 1-2 hafta boyunca istediğini yapabildiğin bir tampon dönem bırakan iyi sistemler var; bu da bu sorunu hafifletiyor
    • En tatmin edici ve etkili işlerimin hepsi ya çok az para aldığım ya da hiç para almadığım işlerdi. Artık kaçınılması zor bir şey gibi geliyor ve yazılım işini biraz moral bozucu hale getiriyor
    • Oldukça ilginç bir olgu ve bunun çoğunlukla ekip ölçeğinden ve para kazanma zorunluluğundan kaynaklandığını düşünüyorum
      Tutku projelerinde para almadığın için beklentiler düşük oluyor, bir şey yapma yükümlülüğün olmuyor ve fiilen istediğini yapmakta özgür oluyorsun. Bu yüzden ilgini çeken yeni teknolojileri ya da araçları keşfetmek gibi, sana ilginç gelen ve etkili olabilecek işleri seçiyorsun
      Para işin içine girdiği anda, parayı ödeyen kişinin beklentileri de devreye giriyor; yeni ve yabancı denemelerin başarısız olma ihtimali yüksek olduğu için işler zorlaşıyor
      Sonuçta para söz konusu olduğunda insanlar, potansiyel olarak daha iyi çözümler olsa bile risk büyükse bunlardan kaçınıp öngörülebilir sonuçları tercih ediyor diye düşünüyorum
  • Gerçekten etkileyici; ayrıca asıl yazının yazarının öylece sokaktan Blender HQ’ya girip bunu yapmadığı da açık. Unity’de edindiği uzun deneyim, bu alanı anlamasında epey yardımcı olmuş olmalı
    Bu değişiklik [1] özellikle hoşuma gitti. Görüntü işleme adımını optimize ederken tablo tabanlı pek çok “optimizasyonu” kaldırıp doğrudan kayan nokta hesaplamasına çevirmiş; yazarın makinesinde yaklaşık 4 kat hızlanmış. Harika
    [1]: https://projects.blender.org/blender/blender/pulls/115801/fi...

    • Üstelik yalnızca bu da değil; farklara bakınca 100-150 satır kodu 3 satırla değiştirmiş. Böyle bir pull request ancak rüyada yapılır herhalde
    • Güzel bir optimizasyon ama return c * c; gerçekten sRGB gamması için iyi bir yaklaşık değer mi, merak ediyorum
  • Aras’ın çeşitli açık kaynak grafik projelerine birden dalıp muazzam hız artışları ve iyileştirmeler yapmasını, sonra da rastgele başka bir grafik projesine geçip aynı şeyi tekrarlamasını son birkaç yılın en sevdiğim akışlarından biri olarak görüyorum

  • Kullandığım müzik çalar MusicBee için de böyle bir şey yapmayı isterdim
    Tabii açık kaynak olsaydı. Geliştiricisi artık neredeyse hiç ellemiyor; tamamen ücretsizdi ve hep öyle oldu, neden açık kaynak olmadığını anlamıyorum
    Küçük küçük rahatsız eden, bozuk ya da yavaş ya da tuhaf o kadar çok ayrıntı var ki boş zamanımda mutlaka düzeltmek isterdim
    Üstelik şu saatten sonra FooBar gibi başka bir şeye geçmek de çok iş. HQPlayer’ı da denedim ama UI/UX’i o kadar berbattı ki geçemedim

    • Steven’ın 2013’te defalarca söylediği gibi, yakın gelecekte MusicBee’yi açık kaynak yapma planı yok
      Projeye devam etmek istemez hale gelirse kaynak kodunu yayımlamak değerlendirebileceği seçeneklerden biri; ama bunun programlama keyfi için yaptığı bir hobi projesi olduğunu ve asla profesyonel biçimde yürütülmeyeceğini söylemişti
      Ana işinde insan yönetimine zaten yeterince zaman harcadığını, burada da bunu yapmak istemediğini; “ya otobüs çarparsa” gibi endişeleri olanların başka bir uygulama kullanmasının doğru olacağını da söylemişti
      https://web.archive.org/web/20170721042120/https://getmusicb...
    • Çünkü bir yazılım projesini açık kaynak yaptığın anda o bir insan yönetimi projesine dönüşüyor
    • Bir kodu açık kaynak proje olarak yazmak, insanların sandığından çok daha yüksek bir olgunluk seviyesi gerektiriyor. Sadece programın iyi çalışmasını sağlamaktan çok daha fazla iş var
    • Bir alternatif var: tamamını açık kaynak olarak yeniden yazmak
    • Windows kullanmayı bıraktıktan sonra özlemeye devam ettiğim tek yazılım MusicBee’ydi
      Bakımı sürüyor olsaydı Wine ile çalıştırmayı düşünürdüm; ama artık müzik yöneticisi kavramından tamamen vazgeçtim ve dinleyeceğim albümü mpv ile çalıyorum. Üstelik her zaman albüm bazında dinliyorum. Çalma listelerine hayır
  • 2020’den beri tüm video düzenleme işlerimde Blender VSE kullanıyorum ve geliştiğini görmek gerçekten güzel
    Kararlılığı ve özellik setini düşününce, zaten Linux’taki en iyi video düzenleyici olduğunu düşünüyordum. Blender’ın mevcut animasyon araçlarının tamamını kullanabilmek de bir avantaj

  • VSE’nin gerçekten çok sevgiye ihtiyacı var. Podcast için tüm araçları açık kaynak kullanmak istemiştim ama Blender’da chroma key içeren bir mp4 sekansını render edince 1,5 saatlik video 10 saat sürdü
    Sonunda DaVinci Resolve’un ücretsiz sürümüne geçtim

    • Blender VSE’de şu anda video render için GPU hızlandırma yok; bu yüzden tüm işi CPU yapıyor
      Ayrıca yeniden kodlama gerekmediğinde bile DaVinci Resolve gibi atlayamıyor, tüm kareleri tek tek render ediyor. Bu kısım iyileşirse Blender’ın performansına ve verimliliğine büyük katkı sağlar
    • Blender’ın çok iş parçacıklı render sistemi VSE işleri için iyi ölçeklenmiyor. Odak noktası her kareyi bölmek olduğu için birden fazla çekirdeği iyi kullanamıyor
      Eskiden zaman çizelgesinin farklı noktalarından birden çok render işini ayrı süreçler olarak başlatan bir eklentiyi [1] denemiştim ve render’ı ciddi şekilde hızlandırabiliyordu
      Şimdi Linux’ta da Resolve’a geçtim; Blackmagic kamera kullandığım için o taraf daha uygun oluyor
      [1] https://github.com/AkBKukU/blenderSubprocessRender
    • Bir projede VSE kullandım. Acı vericiydi ama sonucu çıkardım; o dönemde kesinlikle en iyi ücretsiz yazılım video editörüydü
      Şimdi yeni sürümü Final Cut Pro ile hazırlıyorum
  • Blender 3D programının herhangi bir bölümünü daha hızlı yapmak epey zor olacak gibi. Zaten açık ara en hızlı açılan 3D uygulaması ve GUI tepkisi de en hızlı olanı
    Houdini ikinci sırada ama yakın bir ikinci değil

    • Şaşırtıcı biçimde hâlâ çok fazla kolay kazanım var
      Birkaç yıl önce ‘blobby’ üreteci koduyla uğraşırken çoklu iş parçacığı ekleyip onu çok daha yavaş hale getirmiştim. Çoklu iş parçacığının ek yükünü aşınca daha hızlı oluyordu ama hatırladığım kadarıyla tipik kullanım örneklerinin içine pek girmiyordu, bu yüzden vazgeçtim. Kesin bazı hatalar da yapmışımdır
    • Kodun bir kısmına baktım ve hâlâ çok iyileştirme alanı olduğunu düşünüyorum. Yazıda geçtiği gibi, optimizasyon adı altında yaklaşımı çok karmaşık ama pratikte yavaşlatma ihtimali de olan şaşırtıcı derecede çok benzer kod var
      Örneğin texture painting, piksel başına yaklaşık 3 kez pointer dolaylı erişimi yapıyor ve benim PC’mde de epey takılıyor
    • Animasyon araçlarında muazzam iyileştirme alanı var ve gerçekten de üzerinde çalışılıyor gibi. Vulkan’a geçiş de çok yardımcı olacak gibi görünüyor
  • “Blender’da video düzenleme araç seti olduğunu biliyor muydunuz? Ben de bilmiyordum :)” demiş ama Blender ile animasyon yapanların çoğu bunu biliyordur diye düşünüyorum
    Çünkü render edilen kareleri video dosyasına dönüştürmenin temel yolu bu

    • Kareleri doğrudan video dosyasına render edebilirsiniz (ffmpeg seçenekleri) ve yeni başlayanlar ya da hafif kullanıcılar muhtemelen bunu sıkça yapıyordur
      Compositor kullanarak önceden render edilmiş kare sekanslarını video dosyasına dönüştürmek de mümkün
      Yine de çoğu kişi video düzenlemeyi Resolve gibi başka bir programda yapmayı tercih ediyordur; VSE ise “temel kesme gerekiyor ama transform, başlık, efekt gerekmiyor” gibi dar bir alanda kaldığından çok kullanılmıyor hissi veriyor
      Birilerinin transform ve efekt iyileştirmelerini sürdürüp bir gün 3 noktalı kurgu da eklemesini isterim
  • Ah, Aras’mış. O müthiş biri. Hatta tam adının gerçekten Müthiş Aras olduğunu hatırlıyorum
    Grafik programlama vb. konularda çok iyi ve kod yazarken iyi bir akış hâli de var gibi
    Yazısı okunaklı ve eğlenceli. Sanki bir insanın konuşmasını dinliyormuşsunuz gibi. Ortadaki “However!” gibi cümleler de öyle
    Sonda, standart kültür ve süreç beklentileriyle ezildiğiniz tipik bir şirkette üretkenliğin %30’a düştüğü kısmına da katılıyorum. Çalışanları “kendi işleri”ne bağlı tutmanın maliyeti, gerçekte muazzam bir üretkenlik düşüşünü içeriyor
    Böyle örnekleri gördükçe, teknik insanların insanları ve faaliyetleri daha iyi organize etmenin yollarını öğrenmesini ve bu öğrenime güvenip yüksek üretkenlik/yüksek odaklanmayı gerçek organizasyon biçimlerine entegre etmeye başlamasını umuyorum
    Yazının ima ettiği gibi, böyle olursa teknoloji sektöründe çalışmak daha keyifli hale gelebilir. Teknolojiyle oynamak kadar neredeyse eğlenceli bile olabilir

  • https://projects.blender.org/blender/blender/pulls/116089 hakkında ek olarak, inline her şeyden önce tek tanım kuralını etkiler
    Kısaca, bir fonksiyonu header’da tanımlayıp birden çok .cc dosyasından çağırırsanız, inline olarak işaretlemediğiniz sürece linker hatası alırsınız
    Gerçek inline optimizasyonuna etkisi “yok”tan, “derleyici bağlantı biçimi nedeniyle ağırlığı farklı değerlendirebilir”e, “gerçekten ipucu olarak kabul eder”e kadar değişir; link-time optimization için de benzer değerlendirmeler geçerlidir
    Derleyiciye çok daha güçlü bir inline sinyali vermek istiyorsanız, özellikle yalnızca tanımlandığı dosya içinde kullanılan fonksiyonlar için, bunları anonim namespace içinde tanımlamak daha iyidir
    O fonksiyona başta inline eklenmesinin amacı gerçek inline’a almayı denemek olabilir. Ölçülebilir kazanç net değil ama imkânsız da değil