गलती से इस्तेमाल किया गया Blender VSE

 (aras-p.info)
1 पॉइंट द्वारा GN⁺ 2024-02-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Aras को यह भी नहीं पता था कि Blender में Video Sequence Editor(VSE) है, लेकिन Blender HQ की विज़िट के बाद उन्होंने लगभग दो महीनों तक पार्ट-टाइम Blender 4.1 के लिए performance और quality सुधारों में योगदान दिया
  • सबसे स्पष्ट बदलाव timeline responsiveness में है: Sprite Fright project में, जहाँ लगभग 3000 strips दिखते हैं, scroll और panning UI करीब 15fps से बेहतर होकर 60fps से ऊपर हो गया
  • ffmpeg-आधारित RGB↔YUV conversion, Audaspace audio resampling, image conversion/filtering, और VSE effects processing में multithreading, SIMD और math simplification लागू किए गए
  • तीन Blender Studio datasets पर, लेखक के PC के हिसाब से VSE movie final render time लगभग 2 गुना तेज हुआ, और Sprite Fright rendering लगभग 13 मिनट से घटकर 7 मिनट रह गई
  • कुल 37 pull requests review और merge हुए; मौजूदा बदलाव Blender 4.1 में शामिल हैं और आगे का VSE काम Blender 4.2 से जारी रहेगा

Blender VSE में योगदान देने की पृष्ठभूमि

  • Aras Unity के Unite 2023 में शामिल होने के लिए Amsterdam गए थे और खाली समय में Blender HQ देखने गए
  • वहाँ Francesco और Sergey ने उनसे पूछा कि क्या वे VSE में योगदान देना चाहेंगे, और उसके बाद उन्होंने Blender के Video Sequence Editor को छूना शुरू किया
  • video editing, timeline, sequencer, color grading, ffmpeg, और audio mixing की अच्छी जानकारी नहीं थी, फिर भी उन्होंने कम विवादित performance optimization से शुरुआत की
  • लगभग दो महीनों के पार्ट-टाइम काम के बाद Blender 4.1 में जाने वाले सुधारों का एक सेट तैयार हुआ
    • Blender 4.1 beta हो चुका है, और सामान्य daily builds से डाउनलोड किया जा सकता है

Timeline drawing और UI responsiveness

  • VSE timeline स्क्रीन के नीचे वाला क्षेत्र है, और Sprite Fright edit के पूरे project को zoom out करने पर एक साथ लगभग 3000 strips दिखते हैं
  • पहले इस timeline में सिर्फ scrolling और panning करने पर भी UI refresh करीब 15fps तक ही रहता था
  • बदलावों के बाद यह 60fps से ऊपर चलता है
    • संबंधित PR: #115311
  • bottleneck यह था कि graphics API draw calls दो triangles की unit में submit किए जा रहे थे, और Superluminal profiler में ज्यादातर समय “एक quad draw शुरू करना” और “एक quad draw खत्म करना” functions में खर्च हो रहा था
  • इसी दौरान audio waveform display के अजीब व्यवहार को भी ठीक किया गया और UI को polish किया गया; waveform display अब default रूप से enabled है
    • संबंधित issue: #115274

Scope display quality और speed में सुधार

  • VSE image histogram, waveform, और vectorscope जैसे सामान्य scope display options देता है
  • histogram पहले pixelated image और बहुत strong saturation के साथ draw होता था, लेकिन अब यह ज्यादा smooth polygon, grid, और कम saturation के साथ दिखता है
    • संबंधित PR: #116798
  • Waveform के parade option में बहुत जल्दी saturate होने की समस्या थी, और multithreading के बाद यह 15 गुना तेज हो गया
    • संबंधित PR: #115579
  • Vectorscope के outer color hexagon में काफी pixelation था, इसलिए image editor vectorscope के updated design को copy करके लागू किया गया
    • संबंधित PR: #117738
  • “overexposed areas दिखाने” वाला zebra stripes option भी 2–3 गुना तेज हुआ
    • संबंधित PR: #115622
  • उन्होंने यह विचार भी जोड़ा कि सभी scopes और image editor scopes को किसी दिन GPU compute shader से process किया जाना चाहिए

ffmpeg RGB↔YUV conversion optimization

  • Blender audio और video पढ़ने-लिखने के लिए मुख्य रूप से ffmpeg library का इस्तेमाल करता है
  • Blender के अंदर ffmpeg command-line tool नहीं, बल्कि libavcodec जैसी code libraries इस्तेमाल होती हैं, और libswscale movie frames के RGB↔YUV conversion को संभालता है
  • libswscale multithreaded conversion support करता है, लेकिन सिर्फ sws_getContext() और sws_scale() इस्तेमाल करने पर यह पूरी तरह single-threaded चलता है
  • multithreading इस्तेमाल करने के लिए initialization के समय "threads" parameter set करना पड़ता है, इसलिए sws_alloc_context(), av_opt_set_int(), sws_init_context() को सीधे इस्तेमाल करना होता है
  • साथ ही sws_scale() internally multithreading नहीं करता, इसलिए sws_scale_frame() इस्तेमाल करना पड़ा, और इस प्रक्रिया में AVFrame बनाने के तरीके की समस्या भी सामने आई
  • नतीजतन movie file लिखते समय RGB→YUV conversion काफी तेज हो गया
    • संबंधित PR: #116008
  • movie file पढ़ते समय भी multithreaded YUV→RGB conversion इस्तेमाल किया गया, और vertical flip को उसी काम में मिला दिया गया
    • संबंधित PR: #116309

Audio resampling

  • VSE में video render करते समय “video या audio frame बनाने” के समय का लगभग आधा हिस्सा Blender द्वारा इस्तेमाल की जाने वाली audio library Audaspace के अंदर खर्च हो रहा था
  • bottleneck audio encoding नहीं, बल्कि encoding से पहले की mixing थी, और इसका ज्यादातर हिस्सा तब resampling में जाता था जब 48kHz movie में 44.1kHz जैसे audio strips मिले होते थे
  • Audaspace में दो resampling modes थे
    • Blender internal playback: samples के बीच linear interpolation करने वाला Linear resampler
    • Movie rendering: Julius O Smith’s algorithm आधारित resampler
  • resampler quality की तुलना एक synthetic sound, जिसकी single frequency बढ़ती जाती है, को resample करने के बाद spectrogram देखने के तरीके से की गई
    • लक्ष्य Audacity की “best” setting जैसा result था, जिसमें extra frequencies जितनी कम हों उतना अच्छा
  • Audaspace का preview resampling compute में तेज था, लेकिन बहुत सारी extra frequencies बनाता था; rendering resampling की spectrogram quality अच्छी थी
  • Audaspace में नई medium resampling quality जोड़ी गई, और लेखक के अनुसार यह लगभग समान result देते हुए computation को करीब 3 गुना तेज कर देती है
  • Blender rendering के समय इस medium setting का इस्तेमाल करने लगा
    • Windows Ryzen 5950X PC पर Sprite Fright के 2000 frames render करना 92 सेकंड से 73 सेकंड पर आ गया
    • संबंधित PR: #116059

Image transforms और filtering

  • VSE में image, movie, text, scene आदि visual result बनाने वाले strips पर position, rotation, scale, crop apply किए जा सकते हैं
  • ये transforms, strip द्वारा बनाई गई image को नई image में transform करने के तरीके से होते हैं, और पहले से ही CPU पर multithreaded तरीके से process किए जाते थे
  • GPU के बजाय CPU पर process होने की वजह यह है कि अभी GPU implementation नहीं है, और जिन render farms में GPU नहीं है वहाँ render करने के use case के लिए CPU fallback फिलहाल जरूरी है

  • Half-pixel error fix

    • पुराने code में कई off by half a pixel errors थे; कई मामलों में वे cancel हो जाते थे या दिखते नहीं थे, लेकिन कुछ स्थितियों में सामने आ जाते थे
    • छोटे image को 16 गुना upscale करते समय Bilinear filter image को original pixel के आधे हिस्से जितना shift कर देता था, और background color magenta भी बीच में दिखने लगता था
    • इसके उलट, image को ठीक 2 गुना downscale करते समय Bilinear filter बिल्कुल filtering नहीं कर रहा था
    • Bilinear और दूसरे filters के “off by something” errors ठीक किए गए
    • संबंधित PR: #116628

  • Bilinear transparent border handling

    • Blender 4.0 से पहले VSE में Nearest, Bilinear, Subsampled3x3 तीन filter options थे, और इनमें से सिर्फ Bilinear result image के आसपास original texel की आधी width जितनी transparency जोड़ता था
    • media को upscale करते समय यह behavior साफ दिखता था, और किसी को याद नहीं था कि यह फर्क क्यों आया था
    • VSE के Bilinear filter code से “transparency में blend” करने वाला behavior हटाया गया
    • हालांकि जब सिर्फ rotation apply की जाती थी, तो पुराने transparency handling की वजह से edge पर एक तरह की anti-aliasing मिलती थी, इसलिए उसकी जगह destination image के edge pixel पर transparency anti-aliasing लागू की गई
    • संबंधित PR: #117717

  • Cubic, Box, Auto filters

    • सामान्य VSE strip transform में cubic filter option नहीं था, और यह केवल special Transform Effect strip में मौजूद था
    • Blender में “Bicubic” असल में Cubic B-Spline filter को दर्शाता है, और Mitchell-Netravali filter के B=1, C=0 coefficients जैसा है
    • लेखक ने इसे “ringing नहीं, लेकिन blur ज्यादा” वाले विकल्प के रूप में संक्षेपित किया
    • VSE में दो तरह के cubic filtering options जोड़े गए
    • संबंधित PR: #117100, #117517
    • Blender 3.5 का “Subsampled 3x3” filter असल में 3x3 size में hardcoded box filter था, और 3x3 के अलावा किसी ratio में downscale करने पर टूटने लगता था
    • यह filter fixed 3x3 की जगह adjusted Box filter में बदल दिया गया
    • संबंधित PR: #117584
    • users को चुनने के लिए filters ज्यादा हो गए, इसलिए VSE strip के default के रूप में Auto filter option जोड़ा गया
    • संबंधित PR: #117853
    • scale/rotation न हो तो Nearest
    • 2 गुना से अधिक upscale हो तो Cubic Mitchell
    • 2 गुना से अधिक downscale हो तो Box
    • बाकी मामलों में Bilinear

  • Filtering performance improvements

    • image filtering process भी तेज हुआ
    • inner loop से virtual function हटाना, Bilinear filtering में कुछ SIMD लागू करना: #115653
    • Cubic filtering simplification और SIMD जोड़ना: #117100
    • Box filter की math simplification: #117125
    • पूरे screen को cover करने वाली solid image के नीचे के items को skip करने वाला optimization scale होने पर काम नहीं कर रहा था, इसे ठीक किया गया: #117786
    • लेखक के PC पर, 3840x2160 project में 1920x1080 image को 2 गुना upscale करके Bilinear filtering इस्तेमाल करने पर, sequencer preview की पूरी drawing 36.8ms से 15.9ms पर आ गई
    • upsample filters की तुलना के लिए interactive page भी दिया गया है: aras-p.info/img/misc/upsample_filter_comp_2024

VSE effects optimization

  • Blender Studio के real movie datasets में effects ज्यादा इस्तेमाल नहीं हुए थे, लेकिन code में दिखने वाले हिस्सों के आधार पर VSE effects को भी optimize किया गया
  • ज्यादातर बदलाव multithreading लागू करने के थे
    • Glow effect: multithreaded किया गया, 6–10 गुना तेज #115818
    • Wipe effect: multithreaded किया गया, Clock wipe में excessive trigonometric calculations simplify किए गए, 6–20 गुना तेज #115837
    • Gamma Cross effect: एक square root call से बचने के लिए complex table और interpolation इस्तेमाल करने का तरीका बदलकर 4 गुना तेज हुआ #115801
    • Gaussian Blur effect: duplicate calculations से बचाकर 1.5 गुना तेज हुआ #116089

Final render time में बदलाव

  • Blender Studio से मिले तीन datasets के आधार पर, लेखक के PC पर VSE movie final render time लगभग 2 गुना तेज हुआ
  • Sprite Fright edit rendering लगभग 13 मिनट से 7 मिनट पर आ गई
  • लेखक और speed improvements चाहते हैं, और उन्होंने इसे कुछ इस तरह कहा कि “अगर 2x speedup तीन बार और हो जाए तो काफी अच्छा होगा”

काम करने का तरीका और अगले कदम

  • user-visible changes के अलावा tests जोड़ने, refactoring और cleanup work के लिए भी pull requests थे, और कुल 37 pull requests complete, reviewed और merged हुए
  • लेखक का आकलन है कि इतना काम “real job” में करना शायद मुश्किल होता
    • वे कहते हैं कि Unity में 2015–2022 के बीच, इसी समय में ऊपर के काम का लगभग 30%, शायद उससे भी कम, हो पाता
    • उन्होंने यह भी जोड़ा कि 2010 के आसपास की “ancient” Unity में शायद यह संभव हो सकता था
  • उनका मानना है कि company size, process, expectations, communication, politics जैसे factors मिलें तो paid company environment में वही काम उल्टा धीमा हो सकता है या बीच में cancel भी हो सकता है
  • वे उम्मीद करते हैं कि Blender ऐसे scale, complexity और workflow में न जाए जहाँ process लोगों की मदद करने के बजाय उनका उत्साह तोड़ दे और उन्हें धीमा कर दे
  • Blender 4.1 beta हो चुका है, इसलिए feature के लिहाज से यह complete state में है, और VSE से जुड़े 4.1 changes अभी release notes की state में शामिल हैं
  • Blender 4.2 work शुरू हो रहा है, और आगे भी वे बिना किसी स्पष्ट plan के VSE पर काम जारी रखने का सोच रहे हैं
    • progress Weekly Updates forum section में देखी जा सकती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-02-09
Hacker News की राय

  • अगर यह “असली नौकरी” होती, तो शायद मैं ऐसा काम नहीं कर पाता
    करियर में अगर कोई बात ठीक नहीं चली, तो वह यह रही कि बिना पैसे वाले किसी ऐसे unpaid project में, जिसमें बिल्कुल अनोखी गणित खुद हल करनी हो, मैं दो महीनों में आमतौर पर दो साल में जितना करता उससे ज्यादा कर देता हूं, लेकिन पैसे लेकर किए जाने वाले projects में नतीजे अक्सर औसत ही रहते हैं
    मैंने सचमुच बहुत कोशिश की, फिर भी बीच का रास्ता नहीं ढूंढ पाया, और पिछले साल जब उस काम के लिए पैसे मिलने की संभावना बनी जिसे मैं मुफ्त में कर रहा था, तो आखिरकार मैं उसे छू भी नहीं पाया

    • आप अकेले नहीं हैं। पूरी जिंदगी मेरे साथ भी कुछ ऐसा ही हुआ है, और इसी वजह से motivation के बारे में लोगों की कही बातों पर, जैसे कि सिर्फ मुनाफा और वेतन ही काम पूरा करवाते हैं, मुझे गहरा शक होने लगा
      फिर मैं Marx की alienation theory से रूबरू हुआ, और चीजें कहीं ज्यादा समझ में आने लगीं। उन्होंने इस observation से शुरुआत की थी कि काम स्वस्थ लोगों की मुख्य गतिविधियों में से एक है, लेकिन माना कि इसे दूसरों के लिए काम करने और अपने श्रम के उत्पाद से अलग-थलग हो जाने के साथ गड्डमड्ड नहीं करना चाहिए
      https://en.m.wikipedia.org/wiki/Marx's_theory_of_alienation
    • अब तक मैंने जो सबसे शानदार या दिलचस्प काम किए हैं, उनमें से कोई भी पैसे लेकर नहीं किया था
    • Project management ऐसे सारे कामों को खत्म कर देता है
      कुछ जगहों पर 1–2 हफ्ते की ऐसी buffer अवधि रखने का अच्छा सिस्टम होता है, जिसमें आप कुछ भी कर सकते हैं, और यह इस समस्या को कम कर देता है
    • सबसे संतोषजनक और असरदार काम वे रहे जिनके लिए या तो बहुत कम पैसे मिले या बिल्कुल नहीं मिले। अब यह टाली न जा सकने वाली बात जैसी लगती है, और software का काम थोड़ा उदास कर देती है
    • यह काफी दिलचस्प phenomenon है, और मुझे लगता है कि इसका ज्यादातर कारण team size और पैसा कमाने की जरूरत है
      passion project में आप पैसे नहीं ले रहे होते, इसलिए expectations कम होती हैं, कुछ करने की बाध्यता भी नहीं होती, और व्यावहारिक रूप से आप अपनी पसंद का काम करने के लिए स्वतंत्र होते हैं। इसलिए आप ऐसे काम चुनते हैं जो आपके लिए दिलचस्प और प्रभावशाली हों, जैसे किसी नई technology या tool को explore करना
      जैसे ही पैसा शामिल होता है, पैसे देने वाले व्यक्ति की expectations आ जाती हैं, और नए व अपरिचित प्रयोग इसलिए मुश्किल हो जाते हैं क्योंकि उनके असफल होने की संभावना ज्यादा होती है
      आखिरकार, जब पैसा दांव पर होता है, तो लोग संभावित रूप से बेहतर समाधान होने पर भी, अगर risk बड़ा हो तो उससे बचते हैं और predictable results को तरजीह देते हैं

  • वाकई प्रभावशाली है, और यह भी साफ है कि मूल लेखक बस सड़क से चलते-चलते Blender HQ में नहीं घुस गए थे। Unity में उनका लंबा अनुभव इस domain को समझने में काफी मददगार रहा होगा
    यह बदलाव [1] खास तौर पर अच्छा लगा। image processing चरण को optimize करते हुए उन्होंने table-based “optimization” की बहुत सारी चीजें हटाकर उसे सीधे floating-point calculations से बदल दिया, और मूल लेखक की machine पर यह लगभग 4 गुना तेज हो गया। शानदार
    [1]: https://projects.blender.org/blender/blender/pulls/115801/fi...

    • इतना ही नहीं, diff देखने पर पता चलता है कि code की 100–150 lines को 3 lines में बदल दिया गया। ऐसा pull request तो सपनों में ही बन पाएगा
    • optimization अच्छी है, लेकिन मुझे जिज्ञासा है कि return c * c; सचमुच sRGB gamma का अच्छा approximation है या नहीं

  • पिछले कुछ सालों में मुझे यह pattern सबसे ज्यादा पसंद आया है कि Aras अलग-अलग open source graphics projects में अचानक आते हैं, जबरदस्त speedups और improvements करते हैं, फिर किसी और random graphics project पर जाकर वही दोहराते हैं

  • मैं अपने music player MusicBee के साथ भी ऐसा कुछ करना चाहता हूं
    अगर वह open source होता। creator अब लगभग उस पर हाथ नहीं लगाते, यह पूरी तरह free था और हमेशा रहा है, फिर भी समझ नहीं आता कि यह open source क्यों नहीं है
    इतनी सारी छोटी-छोटी चिढ़ाने वाली समस्याएं, broken या slow या अजीब minor parts हैं कि मैं उन्हें खाली समय में जरूर ठीक करना चाहूंगा
    और अब FooBar जैसी किसी दूसरी चीज पर जाना बहुत बड़ा काम है। HQPlayer भी आजमाया, लेकिन उसका UI/UX इतना भयानक था कि switch नहीं कर पाया

    • 2013 में Steven ने कई बार कहा था कि निकट भविष्य में MusicBee को open source करने की कोई योजना नहीं है
      उन्होंने कहा था कि जब project जारी रखने का मन नहीं रहेगा, तब source code जारी करना विचार करने लायक विकल्पों में से एक है, लेकिन यह programming में मजा आने की वजह से किया जाने वाला hobby project है और इसे कभी professional तरीके से चलाया नहीं जाएगा
      अपने day job में वे लोगों को manage करने में पर्याप्त समय बिताते हैं, इसलिए यहां भी वैसा नहीं करना चाहते, और जिन लोगों को “अगर bus ने टक्कर मार दी तो क्या होगा” जैसी चिंता है, उनके लिए कोई दूसरा app इस्तेमाल करना ही सही है
      https://web.archive.org/web/20170721042120/https://getmusicb...
    • क्योंकि software project को open source बनाते ही वह उसी पल people management project बन जाता है
    • open source project के रूप में code लिखने के लिए लोगों की सोच से कहीं ज्यादा उच्च स्तर की polish चाहिए होती है। सिर्फ program को ठीक से चलाने से यह बहुत ज्यादा काम है
    • विकल्प है। पूरी चीज को open source के रूप में दोबारा लिखा जा सकता है
    • Windows छोड़ने के बाद भी जिस एकमात्र software की कमी महसूस होती रही, वह MusicBee था
      अगर उसका maintenance हो रहा होता तो उसे Wine में चलाने पर विचार करता, लेकिन अब मैंने music manager की अवधारणा ही छोड़ दी है और बस mpv में album चलाकर सुनता हूं। और हमेशा album के हिसाब से सुनता हूं। playlists नहीं चाहिए

  • 2020 से सभी video editing के लिए Blender VSE इस्तेमाल कर रहा हूं, और इसमें सुधार होते देखना सचमुच अच्छा है
    stability और feature set को देखते हुए मुझे यह पहले से ही Linux पर सबसे अच्छा video editor लगता था। Blender के मौजूदा animation tools का पूरा इस्तेमाल कर पाना भी इसका फायदा है

  • VSE को सच में बहुत प्यार और सुधार की ज़रूरत है। मैं पॉडकास्ट के लिए सभी टूल open source इस्तेमाल करना चाहता था, लेकिन Blender में chroma key वाला mp4 sequence render करने पर 1.5 घंटे के वीडियो में 10 घंटे लग गए
    आखिरकार मैं DaVinci Resolve के free version पर चला गया

    • Blender VSE में अभी वीडियो rendering के लिए GPU acceleration नहीं है, इसलिए CPU पूरा काम संभालता है
      साथ ही, जब re-encoding की ज़रूरत नहीं होती तब भी यह DaVinci Resolve की तरह skip नहीं कर पाता और हर frame को एक-एक करके render करता है। अगर यह हिस्सा सुधर जाए तो Blender की performance और efficiency को बहुत फायदा होगा
    • Blender की multi-threaded rendering VSE tasks के लिए अच्छी तरह scale नहीं होती, यह भी एक समस्या है। इसका focus हर frame को split करने पर है, इसलिए कई cores का सही इस्तेमाल नहीं हो पाता
      पहले मैंने एक plugin [1] के साथ प्रयोग किया था, जो timeline के अलग-अलग points पर कई render jobs को अलग processes के रूप में शुरू करता था, और इससे rendering काफी तेज़ हो सकती थी
      अब मैं Linux पर भी Resolve पर चला गया हूं, क्योंकि मैं Blackmagic camera इस्तेमाल करता हूं और वह workflow उसके साथ बेहतर fit बैठता है
      [1] https://github.com/AkBKukU/blenderSubprocessRender
    • एक project में मैंने VSE इस्तेमाल किया था। तकलीफदेह था, लेकिन output बना लिया, और उस समय यह निश्चित रूप से सबसे अच्छा free software video editor था
      अब मैं नया version Final Cut Pro में बना रहा हूं

  • Blender 3D program के किसी भी हिस्से को और तेज़ बनाना काफी मुश्किल लगता है। यह पहले से ही साफ तौर पर सबसे तेज़ शुरू होने वाला 3D application है, और GUI response भी सबसे तेज़ है
    Houdini दूसरे नंबर पर है, लेकिन बहुत करीब वाला दूसरा नंबर नहीं

    • हैरानी की बात है कि अभी भी काफी low-hanging fruit मौजूद है
      कुछ साल पहले ‘blobby’ generator code में बदलाव करते हुए मैंने multi-threading जोड़ दी थी और उसे काफी धीमा बना दिया था। multi-threading के overhead से आगे निकलने पर वह तेज़ हो जाता था, लेकिन जहां तक याद है, वह आम use cases में अच्छी तरह नहीं आता था, इसलिए मैंने छोड़ दिया। निश्चित रूप से मुझसे कुछ गलतियां भी हुई होंगी
    • मैंने code के कुछ हिस्से देखे हैं और मुझे लगता है कि अभी भी सुधार की काफी गुंजाइश है। लेख में जैसा बताया गया है, optimization के नाम पर approach बहुत जटिल है लेकिन असल में धीमा बना देने की संभावना भी उतनी ही रखने वाला code आश्चर्यजनक रूप से बहुत है
      उदाहरण के लिए texture painting में हर pixel पर pointer indirection लगभग 3 बार होती है, और मेरे PC पर भी यह काफी अटकता है
    • animation tools में सुधार की जबरदस्त गुंजाइश है, और लगता है कि उस पर सच में काम चल रहा है। Vulkan transition भी काफी मददगार दिखता है

  • “क्या आपको पता था कि Blender में video editing tools का set है? मुझे भी नहीं पता था :)” ऐसा कहा गया था, लेकिन Blender से animation बनाने वाले ज्यादातर लोग शायद जानते होंगे
    क्योंकि rendered frames को video file में बदलने का यह basic तरीका है

    • frames को सीधे video file में render किया जा सकता है (ffmpeg options), और beginners या हल्के users शायद अक्सर ऐसा ही करते होंगे
      compositor का इस्तेमाल करके पहले से rendered frame sequence को video file में भी बदला जा सकता है
      हालांकि ज्यादातर लोग शायद video editing के लिए Resolve जैसे दूसरे programs को पसंद करेंगे, और VSE “basic cuts चाहिए लेकिन transforms, titles, effects नहीं चाहिए” वाले सीमित दायरे में है, इसलिए लगता है कि इसका ज्यादा इस्तेमाल नहीं होता
      अच्छा होगा अगर कोई transforms और effects में सुधार जारी रखे और किसी दिन 3-point editing भी जोड़ दे

  • ओह, यह Aras था। वह कमाल है। मुझे याद है कि उसका full name शायद Really Awesome Aras था
    वह graphics coding वगैरह में बेहतरीन है, और coding करते समय उसके पास अच्छा flow state भी लगता है
    उसकी writing पढ़ने में अच्छी और मजेदार है। ऐसा लगता है जैसे किसी इंसान को बोलते हुए सुन रहे हों। बीच में “However!” जैसे वाक्य भी ऐसे ही लगते हैं
    अंत में यह बात भी relatable लगी कि सामान्य company में standard culture और process expectations के नीचे दब जाने पर productivity 30% रह जाती है। employees को “उनके काम” तक बांधकर रखने की cost में सचमुच भारी productivity loss शामिल होता है
    ऐसी examples लगातार देखते हुए उम्मीद है कि technologists लोग लोगों और activities को बेहतर तरीके से organize करना सीखेंगे, और उस सीख पर भरोसा करके high-productivity/high-flow को असली organizational methods में शामिल करना शुरू करेंगे
    जैसा लेख संकेत देता है, ऐसा करने से tech industry में काम करना और ज्यादा आनंददायक हो सकता है। यह technology से खेलने जितना लगभग मजेदार भी हो सकता है

  • https://projects.blender.org/blender/blender/pulls/116089 के बारे में जोड़ते हुए, inline सबसे पहले one definition rule को प्रभावित करता है
    आसान शब्दों में, अगर आप header में function define करके उसे कई .cc files से call करते हैं, तो जब तक उसे inline के रूप में mark नहीं करते, linker error आएगा
    actual inline optimization पर इसका असर “कुछ नहीं” से लेकर “compiler linking method की वजह से अलग weighting दे सकता है”, और “वास्तव में hint के रूप में लेता है” तक हो सकता है; link-time optimization में भी इसी तरह की बातें लागू होती हैं
    compiler को बहुत stronger inline signal देना हो, खासकर अगर function सिर्फ उसी file में इस्तेमाल होता है जहां define है, तो उसे anonymous namespace के अंदर define करना बेहतर है
    मूल रूप से उस function पर inline लगाने का मकसद actual inlining पाने की कोशिश रहा होगा। measurable benefit साफ नहीं है, लेकिन असंभव भी नहीं