เผลอได้ใช้ Blender VSE

 (aras-p.info)
1 คะแนน โดย GN⁺ 2024-02-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Aras เองก็ไม่รู้มาก่อนว่า Blender มี Video Sequence Editor (VSE) แต่หลังจากไปเยี่ยม Blender HQ ก็ได้ช่วยปรับปรุงด้านประสิทธิภาพและคุณภาพให้ Blender 4.1 แบบพาร์ตไทม์อยู่ราวสองเดือน
  • การเปลี่ยนแปลงที่เห็นชัดที่สุดคือ ความลื่นไหลของไทม์ไลน์ โดยในโปรเจ็กต์ Sprite Fright ที่มี strip ให้เห็นราว 3000 รายการ การเลื่อนและแพน UI ดีขึ้นจากประมาณ 15fps เป็นมากกว่า 60fps
  • มีการนำ มัลติเธรด, SIMD และการทำคณิตศาสตร์ให้เรียบง่ายขึ้น ไปใช้กับการแปลง RGB↔YUV บน ffmpeg, การรีแซมเพิลเสียงใน Audaspace, การแปลงและฟิลเตอร์ภาพ รวมถึงการประมวลผลเอฟเฟ็กต์ของ VSE
  • เวลาการเรนเดอร์สุดท้ายของภาพยนตร์ใน VSE บนชุดข้อมูล Blender Studio สามชุด เร็วขึ้น ประมาณ 2 เท่า บนพีซีของผู้เขียน และการเรนเดอร์ Sprite Fright ลดจากเกือบ 13 นาทีเหลือ 7 นาที
  • มี 37 pull request ที่ได้รับการรีวิวและ merge แล้ว โดยการเปลี่ยนแปลงชุดนี้กำลังเข้า Blender 4.1 และงาน VSE หลังจากนั้นจะดำเนินต่อใน Blender 4.2 เป็นต้นไป

ที่มาของการได้มาช่วย Blender VSE

  • Aras เดินทางไป Amsterdam เพื่อเข้าร่วม Unite 2023 ของ Unity และใช้เวลาว่างแวะไปเยี่ยม Blender HQ
  • ที่นั่น Francesco และ Sergey ถามว่าอยากช่วยพัฒนา VSE หรือไม่ และหลังจากนั้นเขาก็เริ่มลงมือแตะ Video Sequence Editor ของ Blender
  • แม้จะยังไม่ค่อยรู้เรื่องการตัดต่อวิดีโอ, ไทม์ไลน์, ซีเควนเซอร์, color grading, ffmpeg และ audio mixing มากนัก แต่ก็เริ่มจากงาน ปรับแต่งประสิทธิภาพ ที่มีข้อถกเถียงน้อยก่อน
  • หลังทำงานแบบพาร์ตไทม์ราวสองเดือน ก็ได้ชุดการปรับปรุงที่จะเข้า Blender 4.1
    • Blender 4.1 เข้าสู่สถานะเบตาแล้ว และดาวน์โหลดได้จาก daily builds ทั่วไป

การวาดไทม์ไลน์และความลื่นไหลของ UI

  • ไทม์ไลน์ของ VSE อยู่บริเวณด้านล่างของหน้าจอ และเมื่อซูมออกทั้งโปรเจ็กต์ Sprite Fright edit จะเห็น 3000 strip ได้พร้อมกัน
  • เดิมทีแค่เลื่อนหรือแพนในไทม์ไลน์นี้ การรีเฟรช UI ก็ทำได้เพียงราว 15fps
  • หลังการเปลี่ยนแปลง ทำงานได้ที่ มากกว่า 60fps
    • PR ที่เกี่ยวข้อง: #115311
  • คอขวดอยู่ที่โครงสร้างที่ส่ง draw call ไปยัง graphics API ทีละสองสามเหลี่ยม และใน Superluminal profiler เวลาส่วนใหญ่หมดไปกับฟังก์ชัน “เริ่มวาด quad หนึ่งอัน” และ “จบการวาด quad หนึ่งอัน”
  • ระหว่างทางยังได้แก้พฤติกรรมผิดปกติของ การแสดง waveform เสียง และเก็บรายละเอียด UI เพิ่มเติม โดยการแสดง waveform ถูกเปิดเป็นค่าเริ่มต้นแล้ว
    • issue ที่เกี่ยวข้อง: #115274

ปรับปรุงคุณภาพและความเร็วของการแสดงสโคป

  • VSE มีตัวเลือกการแสดง สโคป (scope) มาตรฐาน เช่น histogram ของภาพ, waveform และ vectorscope
  • เดิม histogram ถูกวาดแบบเป็นพิกเซลและมีความอิ่มสีสูงมาก แต่ตอนนี้แสดงผลด้วย polygon ที่เนียนขึ้น มี grid และใช้ความอิ่มสีต่ำลง
    • PR ที่เกี่ยวข้อง: #116798
  • ตัวเลือก parade ของ waveform มีปัญหาอิ่มตัวเร็วเกินไป และหลังใส่มัลติเธรดแล้วก็เร็วขึ้น 15 เท่า
    • PR ที่เกี่ยวข้อง: #115579
  • หกเหลี่ยมสีรอบนอกของ vectorscope เดิมมีอาการเป็นพิกเซลหนักมาก จึงคัดลอก design ที่อัปเดตแล้วจาก vectorscope ของ image editor มาใช้
    • PR ที่เกี่ยวข้อง: #117738
  • ตัวเลือก zebra stripes สำหรับแสดงบริเวณที่ overexposed ก็เร็วขึ้น 2–3 เท่าเช่นกัน
    • PR ที่เกี่ยวข้อง: #115622
  • ผู้เขียนยังเสริมว่า สักวันหนึ่งสโคปทั้งหมด รวมถึงสโคปใน image editor ควรถูกประมวลผลด้วย GPU compute shader

การปรับแต่ง ffmpeg RGB↔YUV

  • Blender ใช้ไลบรารี ffmpeg เป็นหลักในการอ่านและเขียนเสียงกับวิดีโอ
  • ภายใน Blender ใช้โค้ดไลบรารีอย่าง libavcodec ไม่ใช่เครื่องมือ command line ของ ffmpeg และ libswscale ทำหน้าที่แปลง RGB↔YUV ของเฟรมภาพยนตร์
  • แม้ libswscale จะรองรับการแปลงแบบมัลติเธรด แต่ถ้าใช้แค่ sws_getContext() กับ sws_scale() จะทำงานแบบเธรดเดียวทั้งหมด
  • หากต้องการใช้มัลติเธรด ต้องตั้งค่าพารามิเตอร์ "threads" ตอนเริ่มต้น จึงต้องใช้ sws_alloc_context(), av_opt_set_int(), sws_init_context() โดยตรง
  • นอกจากนี้ sws_scale() ก็ไม่ได้ทำมัลติเธรดภายใน ทำให้ต้องใช้ sws_scale_frame() แทน และระหว่างนั้นก็พบปัญหาในวิธีสร้าง AVFrame ด้วย
  • ผลลัพธ์คือการแปลง RGB→YUV ตอนเขียนไฟล์ภาพยนตร์เร็วขึ้นอย่างมาก
    • PR ที่เกี่ยวข้อง: #116008
  • ฝั่งการอ่านไฟล์ภาพยนตร์ก็เปลี่ยนมาใช้การแปลง YUV→RGB แบบมัลติเธรด และรวมการกลับภาพแนวตั้งเข้าไปในงานเดียวกัน
    • PR ที่เกี่ยวข้อง: #116309

การรีแซมเพิลเสียง

  • ระหว่างเรนเดอร์วิดีโอใน VSE พบว่าเวลาเกือบครึ่งของการ “สร้างเฟรมวิดีโอหรือเสียง” ถูกใช้ไปภายในไลบรารีเสียง Audaspace ที่ Blender ใช้งาน
  • คอขวดไม่ใช่การเข้ารหัสเสียง แต่เป็นการ มิกซ์ ก่อนเข้ารหัส โดยส่วนใหญ่เกิดจากการรีแซมเพิลเมื่อมี audio strip อย่าง 44.1kHz ปะปนในภาพยนตร์ 48kHz
  • Audaspace มีโหมดรีแซมเพิลอยู่สองแบบ
    • การเล่นภายใน Blender: Linear resampler ที่ใช้ linear interpolation ระหว่าง sample
    • การเรนเดอร์ภาพยนตร์: รีแซมเพลอร์ที่อิง Julius O Smith’s algorithm
  • คุณภาพของรีแซมเพลอร์ถูกเปรียบเทียบด้วยการรีแซมเพิลเสียงสังเคราะห์ที่มีความถี่เดี่ยวเพิ่มขึ้น แล้วดูผลผ่าน spectrogram
    • เป้าหมายคือให้ผลลัพธ์มีความถี่แทรกให้น้อยที่สุด คล้ายการตั้งค่า “best” ของ Audacity
  • การรีแซมเพิลสำหรับ preview ของ Audaspace คำนวณเร็วแต่สร้างความถี่แทรกจำนวนมาก ขณะที่การรีแซมเพิลสำหรับ rendering ให้คุณภาพ spectrogram ที่ดี
  • จึงเพิ่ม คุณภาพการรีแซมเพิลระดับ medium เข้าไปใน Audaspace ซึ่งจากมุมมองของผู้เขียนให้ผลแทบไม่ต่างกัน แต่คำนวณเร็วขึ้นราว 3 เท่า
  • Blender จะใช้การตั้งค่า medium นี้ตอนเรนเดอร์
    • บนพีซี Windows Ryzen 5950X การเรนเดอร์ Sprite Fright 2000 เฟรมลดจาก 92 วินาทีเหลือ 73 วินาที
    • PR ที่เกี่ยวข้อง: #116059

การแปลงและฟิลเตอร์ภาพ

  • ใน VSE strip ที่สร้างผลลัพธ์ภาพ เช่น image, movie, text และ scene สามารถใช้ตำแหน่ง การหมุน สเกล และ crop ได้
  • การแปลงเหล่านี้คือการ แปลง ภาพที่ strip สร้างออกมาไปเป็นภาพใหม่ และเดิมก็ประมวลผลแบบมัลติเธรดบน CPU อยู่แล้ว
  • เหตุที่ยังทำบน CPU ไม่ใช่ GPU เพราะยังไม่มี implementation บน GPU และในกรณีใช้งานที่ต้องเรนเดอร์บน render farm ที่ไม่มี GPU ก็ยังต้องมี CPU fallback อยู่ในตอนนี้

  • แก้ความคลาดเคลื่อนระดับ half-pixel

    • โค้ดเดิมมีข้อผิดพลาดแบบ off by half a pixel อยู่หลายจุด ซึ่งส่วนมากหักล้างกันเองหรือมองไม่เห็น แต่ในบางสถานการณ์จะเห็นชัด
    • เมื่อต้องขยายภาพเล็ก 16 เท่า Bilinear filter จะเลื่อนภาพออกไปครึ่งพิกเซลจากพิกเซลต้นฉบับ และยังมีสีพื้นหลัง magenta แทรกเข้ามาด้วย
    • ในทางกลับกัน เมื่อลดภาพลงครึ่งหนึ่งพอดี Bilinear filter กลับไม่ทำการฟิลเตอร์เลย
    • จึงมีการแก้ข้อผิดพลาด “off by something” ทั้งของ Bilinear และฟิลเตอร์อื่น ๆ
    • PR ที่เกี่ยวข้อง: #116628

  • การจัดการขอบโปร่งใสของ Bilinear

    • ก่อน Blender 4.0 นั้น VSE มีตัวเลือกฟิลเตอร์สามแบบคือ Nearest, Bilinear, Subsampled3x3 และมีเพียง Bilinear เท่านั้นที่เพิ่ม ความโปร่งใส กว้างครึ่ง texel รอบภาพผลลัพธ์
    • พฤติกรรมนี้เห็นได้ชัดเวลา zoom สื่อให้ใหญ่ขึ้น และไม่มีใครจำได้แล้วว่าทำไมถึงมีความต่างแบบนี้
    • จึงลบพฤติกรรม “blend ด้วยความโปร่งใส” ออกจากโค้ด Bilinear filter ของ VSE
    • แต่ในกรณีที่มีแค่การหมุน การจัดการความโปร่งใสเดิมช่วยให้ขอบเกิด anti-aliasing แบบหนึ่งอยู่แล้ว จึงเปลี่ยนไปใช้ transparency anti-aliasing กับ edge pixel ของภาพปลายทางแทน
    • PR ที่เกี่ยวข้อง: #117717

  • ฟิลเตอร์ Cubic, Box และ Auto

    • ปกติการ transform ของ strip ทั่วไปใน VSE ไม่มีตัวเลือก cubic filter มีเฉพาะใน strip แบบ Transform Effect พิเศษเท่านั้น
    • ใน Blender คำว่า “Bicubic” แท้จริงหมายถึงฟิลเตอร์ Cubic B-Spline ซึ่งตรงกับค่าสัมประสิทธิ์ B=1, C=0 ของ Mitchell-Netravali filter
    • ผู้เขียนสรุปมันว่าเป็นตัวเลือกที่ “ไม่มี ringing แต่เบลอมาก”
    • ตอนนี้มีตัวเลือก cubic filtering สองแบบเพิ่มเข้ามาใน VSE
    • PR ที่เกี่ยวข้อง: #117100, #117517
    • ฟิลเตอร์ “Subsampled 3x3” ใน Blender 3.5 แท้จริงคือ box filter ที่ hardcode ขนาด 3x3 และจะเริ่มให้ผลเสียเมื่อย่อภาพในสัดส่วนที่ไม่ใช่ 3x3
    • ฟิลเตอร์นี้จึงถูกเปลี่ยนเป็น Box filter ที่ปรับขนาดได้ แทนที่จะเป็น 3x3 แบบตายตัว
    • PR ที่เกี่ยวข้อง: #117584
    • เนื่องจากมีฟิลเตอร์ให้ผู้ใช้เลือกมากขึ้น จึงเพิ่ม Auto filter option เป็นค่าเริ่มต้นให้ strip ใน VSE
    • PR ที่เกี่ยวข้อง: #117853
    • ถ้าไม่มีการสเกลหรือหมุน ให้ใช้ Nearest
    • ถ้าขยายเกิน 2 เท่า ให้ใช้ Cubic Mitchell
    • ถ้าย่อเกิน 2 เท่า ให้ใช้ Box
    • นอกนั้นใช้ Bilinear

  • ปรับปรุงประสิทธิภาพของฟิลเตอร์

    • กระบวนการฟิลเตอร์ภาพก็เร็วขึ้นเช่นกัน
    • ลบ virtual function ออกจากลูปภายใน และใส่ SIMD บางส่วนใน Bilinear filtering: #115653
    • ทำ Cubic filtering ให้ง่ายขึ้นและเพิ่ม SIMD: #117100
    • ทำคณิตศาสตร์ของ Box filter ให้ง่ายขึ้น: #117125
    • แก้ปัญหาที่ optimization สำหรับข้ามรายการใต้ solid image ที่ปิดเต็มหน้าจอไม่ทำงานเมื่อมีการสเกล: #117786
    • บนพีซีของผู้เขียน เมื่อใช้ภาพ 1920x1080 หนึ่งภาพในโปรเจ็กต์ 3840x2160 แล้วขยาย 2 เท่าพร้อม Bilinear filtering เวลาวาด sequencer preview ทั้งหมดลดจาก 36.8ms เหลือ 15.9ms
    • ยังมีหน้าอินเทอร์แอกทีฟสำหรับเทียบฟิลเตอร์ upsample ให้ดูด้วย: aras-p.info/img/misc/upsample_filter_comp_2024

การปรับแต่งเอฟเฟ็กต์ VSE

  • แม้ชุดข้อมูลภาพยนตร์จริงจาก Blender Studio จะไม่ได้ใช้ effect มากนัก แต่ก็มีการปรับแต่ง effect ของ VSE จากส่วนของโค้ดที่เห็นได้ชัด
  • การเปลี่ยนแปลงส่วนใหญ่คือการใส่ มัลติเธรด
    • Glow effect: ใส่มัลติเธรด เร็วขึ้น 6–10 เท่า #115818
    • Wipe effect: ใส่มัลติเธรด, ทำการคำนวณตรีโกณมิติที่มากเกินไปของ Clock wipe ให้ง่ายขึ้น เร็วขึ้น 6–20 เท่า #115837
    • Gamma Cross effect: เปลี่ยนจากวิธีที่ใช้ตารางและ interpolation ซับซ้อนเพื่อเลี่ยงการเรียก square root เพียงหนึ่งครั้ง ทำให้เร็วขึ้น 4 เท่า #115801
    • Gaussian Blur effect: เลี่ยงการคำนวณซ้ำ ทำให้เร็วขึ้น 1.5 เท่า #116089

การเปลี่ยนแปลงของเวลาเรนเดอร์สุดท้าย

  • จากชุดข้อมูลสามชุดที่ได้จาก Blender Studio เวลาการเรนเดอร์สุดท้ายของภาพยนตร์ใน VSE บนพีซีของผู้เขียนเร็วขึ้น ประมาณ 2 เท่า
  • การเรนเดอร์ Sprite Fright edit ลดจากเกือบ 13 นาทีเหลือ 7 นาที
  • ผู้เขียนยังหวังว่าจะเร่งได้มากกว่านี้ และพูดประมาณว่า “ถ้าเพิ่มความเร็วได้ 2 เท่าอีกสักสามครั้งก็คงดีมาก”

วิธีการทำงานและก้าวถัดไป

  • นอกเหนือจากการเปลี่ยนแปลงที่ผู้ใช้มองเห็น ยังมี pull request สำหรับเพิ่มการทดสอบ, refactor และเก็บกวาดโค้ด รวมแล้วมี 37 pull request ที่เสร็จสิ้น ได้รับการรีวิว และ merge
  • ผู้เขียนมองว่างานระดับนี้คงทำได้ยากใน “งานจริง”
    • หากเป็นที่ Unity ช่วงปี 2015–2022 เขาคิดว่าในเวลาเท่ากันอาจทำได้ราว 30% ของงานข้างต้น หรืออาจน้อยกว่านั้น
    • และเสริมว่าใน Unity ยุค “ancient” ราวปี 2010 อาจพอเป็นไปได้
  • เขามองว่าปัจจัยอย่างขนาดบริษัท, กระบวนการ, ความคาดหวัง, การสื่อสาร และการเมือง เมื่อรวมกันแล้ว อาจทำให้งานแบบเดียวกันในสภาพแวดล้อมบริษัทที่รับเงินเดือนกลับช้าลงหรือถูกยกเลิกกลางทางได้
  • เขาหวังว่า Blender จะไม่ไปสู่ระดับของขนาด ความซับซ้อน หรือ workflow ที่กระบวนการกลายเป็นตัวบั่นทอนแรงจูงใจและทำให้คนทำงานช้าลง แทนที่จะช่วยเหลือพวกเขา
  • เนื่องจาก Blender 4.1 เข้าสู่สถานะเบตาแล้ว จึงถือว่าด้านฟีเจอร์เสร็จสมบูรณ์ และการเปลี่ยนแปลงเกี่ยวกับ VSE ใน 4.1 ก็ถูกรวมอยู่ในสถานะ release notes ปัจจุบัน
  • งานของ Blender 4.2 เริ่มขึ้นแล้ว และหลังจากนั้นผู้เขียนตั้งใจจะยังคงแตะ VSE ต่อไปโดยยังไม่มีแผนที่ตายตัว
    • ติดตามความคืบหน้าได้ในหมวดฟอรัม Weekly Updates

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-02-09
ความเห็นจาก Hacker News

  • ถ้าเป็น “งานจริง” ก็คงทำแบบนี้ไม่ได้
    ถ้ามีอะไรในเส้นทางอาชีพที่ไม่ค่อยลงตัว ก็คือการที่ในโปรเจกต์ไม่รับค่าจ้างซึ่งได้แก้โจทย์คณิตศาสตร์ที่แปลกใหม่จริง ๆ ด้วยตัวเอง กลับทำผลงานได้ภายในสองเดือนมากกว่างานปกติสองปีรวมกันเสียอีก แต่พอเป็นโปรเจกต์ที่รับเงิน ผลลัพธ์กลับออกมาอยู่ในระดับกลาง ๆ เป็นส่วนใหญ่
    ทั้งที่พยายามอย่างมากแล้วก็ยังหาจุดกึ่งกลางไม่เจอ และเมื่อปีที่แล้วพองานที่ทำฟรีเริ่มมีโอกาสจะได้เงิน สุดท้ายก็กลับแตะต้องมันไม่ได้ไปเลย

    • ไม่ได้เป็นอยู่คนเดียว เจอเรื่องคล้าย ๆ กันมาทั้งชีวิต เลยเริ่มตั้งคำถามกับสิ่งที่คนชอบพูดเรื่องแรงจูงใจ เช่นความคิดที่ว่ากำไรกับค่าจ้างเท่านั้นที่ทำให้คนทำงานให้เสร็จ
      แล้วพอได้เจอกับทฤษฎีความแปลกแยกของ Marx ทุกอย่างก็เริ่มสมเหตุสมผลขึ้นมาก เขาเริ่มจากข้อสังเกตว่างานคือกิจกรรมหลักที่คนสุขภาพดีทำกัน แต่ไม่ควรเอาสิ่งนั้นไปปนกับการทำงานเพื่อคนอื่นและการถูกตัดขาดจากผลผลิตแห่งแรงงานของตัวเอง
      https://en.m.wikipedia.org/wiki/Marx's_theory_of_alienation
    • งานที่ยอดเยี่ยมหรือน่าสนใจที่สุดเท่าที่เคยทำมาทั้งหมด ไม่ใช่งานที่ทำเพราะได้เงินเลย
    • การบริหารโครงการฆ่างานประเภทนี้ทิ้งหมด
      บางที่มีระบบที่ดี โดยเผื่อช่วงกันชนไว้ 1~2 สัปดาห์ให้ไปทำอะไรก็ได้ ซึ่งช่วยบรรเทาปัญหาแบบนี้ได้
    • งานที่ให้ความรู้สึกคุ้มค่าและมีอิทธิพลมากที่สุดทั้งหมด ล้วนเป็นงานที่แทบไม่ได้ค่าตอบแทนหรือไม่ได้เลย ตอนนี้มันเลยรู้สึกเหมือนเป็นสิ่งที่หลีกเลี่ยงไม่ได้ และทำให้งานซอฟต์แวร์ดูหม่นลงนิดหน่อย
    • เป็นปรากฏการณ์ที่น่าสนใจมาก และคิดว่าส่วนใหญ่มาจากขนาดของทีมกับความจำเป็นที่ต้องทำเงิน
      ใน passion project นั้นไม่ได้รับเงิน จึงมีความคาดหวังต่ำ ไม่มีภาระว่าต้องทำอะไรให้ได้ และในทางปฏิบัติก็มีอิสระจะทำสิ่งที่ตัวเองอยากทำได้เต็มที่ เลยเลือกทำงานที่ตัวเองสนใจและมีผลกระทบได้ เช่นการสำรวจเทคโนโลยีหรือเครื่องมือใหม่ ๆ ที่ตัวเองสนใจ
      แต่พอมีเงินเข้ามาเกี่ยว ความคาดหวังของคนจ่ายเงินก็เข้ามาด้วย และการลองอะไรใหม่ ๆ ที่ไม่คุ้นเคยก็ยิ่งยาก เพราะมีโอกาสล้มเหลวสูง
      สุดท้ายเมื่อมีเงินเป็นเดิมพัน คนก็มักหลีกเลี่ยงความเสี่ยงแม้อาจมีทางออกที่ดีกว่าอยู่ และเลือกผลลัพธ์ที่คาดเดาได้มากกว่า

  • น่าประทับใจจริง ๆ และก็ชัดเจนว่าผู้เขียนต้นฉบับไม่ได้แค่เดินจากถนนเข้าไปที่ Blender HQ เฉย ๆ ประสบการณ์ยาวนานที่สะสมมาจาก Unity น่าจะช่วยให้เข้าใจโดเมนนี้ได้มากทีเดียว
    การเปลี่ยนแปลงนี้ [1] ดีมากเป็นพิเศษ ระหว่างที่ปรับปรุงประสิทธิภาพขั้นตอนประมวลผลภาพ ก็ลบ “การเพิ่มประสิทธิภาพ” แบบอิงตารางออกไปจำนวนมาก แล้วเปลี่ยนเป็นการคำนวณ floating-pointตรง ๆ ซึ่งบนเครื่องของผู้เขียนต้นฉบับเร็วขึ้นราว 4 เท่า ยอดเยี่ยมมาก
    [1]: https://projects.blender.org/blender/blender/pulls/115801/fi...

    • ไม่ใช่แค่นั้น พอดู diff แล้วพบว่าเปลี่ยนโค้ด100~150 บรรทัดให้เหลือ 3 บรรทัด แบบนี้ pull request ในฝันชัด ๆ
    • เป็นการปรับแต่งที่ดีนะ แต่ก็สงสัยว่า return c * c; เป็นค่าประมาณของsRGB gammaที่ดีจริงไหม

  • สิ่งที่ชอบที่สุดในช่วงไม่กี่ปีมานี้คือการที่ Aras โผล่เข้าไปในโปรเจกต์กราฟิกโอเพนซอร์สหลายตัวแบบไม่ทันตั้งตัว สร้างการเพิ่มความเร็วและการปรับปรุงแบบมหาศาล แล้วก็ย้ายไปยังโปรเจกต์กราฟิกสุ่มอีกตัวเพื่อทำแบบเดิมซ้ำอีก

  • อยากทำอะไรแบบนี้กับโปรแกรมเล่นเพลงที่ใช้อยู่คือ MusicBee เหมือนกัน
    ถ้ามันเป็นโอเพนซอร์สนะ ผู้พัฒนาแทบไม่ได้แตะมันแล้วตอนนี้ มันฟรีมาโดยตลอด และก็ยังไม่เข้าใจว่าทำไมถึงไม่เป็นโอเพนซอร์ส
    มีปัญหาจุกจิกที่น่ารำคาญเล็ก ๆ น้อย ๆ เยอะมาก ทั้งส่วนที่พัง ช้า หรือแปลก ๆ จนอยากใช้เวลาว่างเข้าไปแก้จริง ๆ
    และตอนนี้จะย้ายไปอย่างอื่นอย่าง FooBar ก็งานใหญ่เกินไปแล้ว เคยลอง HQPlayer ด้วย แต่ UI/UX แย่มากจนย้ายไปไม่ได้

    • ย้อนกลับไปปี 2013 Steven เคยพูดไว้หลายครั้งแล้วว่าไม่มีแผนจะทำ MusicBee เป็นโอเพนซอร์สในเร็ว ๆ นี้
      ถ้าวันหนึ่งไม่อยากทำโปรเจกต์นี้ต่อแล้ว การเปิดซอร์สโค้ดก็อาจเป็นหนึ่งในตัวเลือกที่พิจารณาได้ แต่เขาบอกว่านี่เป็นโปรเจกต์งานอดิเรกที่ทำเพราะสนุกกับการเขียนโปรแกรม และจะไม่มีวันบริหารมันแบบมืออาชีพ
      เขาใช้เวลากับการจัดการคนในงานประจำมากพอแล้ว เลยไม่อยากมาทำแบบนั้นต่อที่นี่ด้วย และยังบอกอีกว่าถ้าใครกังวลเรื่องแนว “ถ้าโดนรถบัสชนจะทำยังไง” ก็ควรไปใช้แอปอื่น
      https://web.archive.org/web/20170721042120/https://getmusicb...
    • เพราะพอทำโปรเจกต์ซอฟต์แวร์ให้เป็นโอเพนซอร์ส มันก็จะกลายเป็นโปรเจกต์บริหารคนทันที
    • การเขียนโค้ดให้โปรเจกต์โอเพนซอร์สต้องการความเรียบร้อยสมบูรณ์มากกว่าที่คนส่วนใหญ่คิดไว้มาก งานมันเยอะกว่าการแค่ทำให้โปรแกรมใช้งานได้ดีมาก
    • ทางเลือกก็มีนะ เขียนใหม่ทั้งระบบแบบโอเพนซอร์สไปเลย
    • หลังเลิกใช้ Windows ไปแล้ว ซอฟต์แวร์เดียวที่ยังคิดถึงอยู่ตลอดก็คือ MusicBee
      ถ้ามันยังได้รับการบำรุงรักษาอยู่ก็คงพิจารณารันผ่าน Wine แต่ตอนนี้เลิกยึดติดกับแนวคิดเรื่องตัวจัดการเพลงไปแล้ว แล้วก็เปิดอัลบั้มที่อยากฟังผ่าน mpv เฉย ๆ แถมฟังเป็นอัลบั้มตลอดด้วย เพลย์ลิสต์ไม่เอาแล้ว

  • ตั้งแต่ปี 2020 มาก็ใช้Blender VSEตัดต่อวิดีโอทุกอย่างมาตลอด และดีใจมากที่ได้เห็นมันพัฒนาขึ้น
    ถ้ามองเรื่องความเสถียรและชุดความสามารถ ก็คิดว่ามันเป็นโปรแกรมตัดต่อวิดีโอที่ดีที่สุดบน Linux อยู่แล้ว และการที่ใช้เครื่องมือแอนิเมชันเดิมของ Blender ได้ทั้งหมดก็เป็นข้อดีด้วย

  • VSE ต้องการการดูแลอีกมาก อยากใช้เครื่องมือโอเพนซอร์สทั้งหมดสำหรับพอดแคสต์ แต่พอเรนเดอร์ซีเควนซ์ mp4 ที่มีโครมาคีย์ใน Blender แล้ว วิดีโอ 1.5 ชั่วโมงใช้เวลา 10 ชั่วโมง
    สุดท้ายเลยย้ายไปใช้ DaVinci Resolve รุ่นฟรี

    • ตอนนี้ Blender VSE ยังไม่มี การเร่งความเร็วด้วย GPU สำหรับการเรนเดอร์วิดีโอ ดังนั้น CPU จึงต้องรับภาระงานทั้งหมด
      อีกทั้งแม้ในกรณีที่ไม่จำเป็นต้องรีเอนโค้ด ก็ยังข้ามไปไม่ได้แบบ DaVinci Resolve และต้องเรนเดอร์ทุกเฟรมทีละเฟรมทั้งหมด ถ้าจุดนี้ดีขึ้นก็น่าจะช่วยเรื่องประสิทธิภาพและความคุ้มค่าของ Blender ได้มาก
    • มีปัญหาว่าการเรนเดอร์แบบมัลติเธรดของ Blender ขยายไปให้เข้ากับงาน VSE ได้ไม่ดีนัก โดยเน้นที่การแบ่งแต่ละเฟรมออกเป็นส่วนย่อย จึงใช้หลายคอร์ได้ไม่เต็มที่
      ก่อนหน้านี้เคยลองปลั๊กอิน [1] ที่เริ่มงานเรนเดอร์หลายงานจากหลายจุดบนไทม์ไลน์เป็นโปรเซสแยกกัน และมันช่วยให้เรนเดอร์เร็วขึ้นมาก
      ตอนนี้ก็ย้ายไปใช้ Resolve บน Linux แล้ว เพราะใช้กล้อง Blackmagic อยู่ เลยเข้าทางนั้นมากกว่า
      [1] https://github.com/AkBKukU/blenderSubprocessRender
    • เคยใช้ VSE ในโปรเจ็กต์หนึ่ง มันทรมานอยู่บ้างแต่ก็ทำงานเสร็จได้ และในตอนนั้นมันก็เป็น ซอฟต์แวร์ตัดต่อวิดีโอฟรี ที่ดีที่สุดอย่างไม่ต้องสงสัย
      ตอนนี้กำลังทำเวอร์ชันใหม่ใน Final Cut Pro

  • การทำให้ส่วนไหนก็ตามของโปรแกรม Blender 3D เร็วขึ้นน่าจะค่อนข้างยากอยู่แล้ว มันเป็นแอป 3D ที่เปิดได้เร็วที่สุดแบบทิ้งห่าง และการตอบสนองของ GUI ก็เร็วที่สุดด้วย
    Houdini มาเป็นอันดับ 2 ก็จริง แต่ไม่ได้ใกล้กันเลย

    • น่าแปลกที่ยังมี ของที่เก็บได้ง่าย เหลืออยู่อีกมาก
      เมื่อหลายปีก่อนเคยไปยุ่งกับโค้ดตัวสร้าง ‘blobby’ แล้วเพิ่มมัลติเธรดเข้าไปจนมันช้าลงมาก พอข้ามต้นทุน overhead ของมัลติเธรดไปได้แล้วมันก็เร็วขึ้นจริง แต่เท่าที่จำได้มันแทบไม่ครอบคลุมกรณีใช้งานทั่วไป เลยเลิกไป และก็น่าจะมีความผิดพลาดของตัวเองอยู่บ้างแน่นอน
    • เคยดูบางส่วนของโค้ดแล้วคิดว่ายังมีพื้นที่ให้ปรับปรุงอีกเยอะ อย่างที่บทความบอกไว้ มีโค้ดที่ซับซ้อนมากในนามของการปรับแต่งประสิทธิภาพ แต่ในความเป็นจริงกลับมีโอกาสทำให้ช้าลงพอๆ กันอยู่เยอะอย่างน่าตกใจ
      ตัวอย่างเช่น การเพนต์เท็กซ์เจอร์ มีลักษณะเหมือนอ้างอิงพอยน์เตอร์ทางอ้อมประมาณ 3 ครั้งต่อพิกเซล และบนพีซีของฉันก็กระตุกพอสมควร
    • เครื่องมือแอนิเมชันยังมีพื้นที่ให้ปรับปรุงอีกมหาศาล และดูเหมือนกำลังทำอยู่จริง การ ย้ายไป Vulkan ก็ดูจะช่วยได้มากเช่นกัน

  • มีประโยคว่า “รู้ไหมว่า Blender มีชุดเครื่องมือตัดต่อวิดีโอด้วย? ผมก็ไม่รู้เหมือนกัน :)” แต่คิดว่าคนส่วนใหญ่ที่ทำแอนิเมชันด้วย Blender น่าจะรู้
    เพราะมันเป็นวิธีพื้นฐานในการทำให้เฟรมที่เรนเดอร์แล้วกลายเป็นไฟล์วิดีโอ

    • คุณสามารถเรนเดอร์เฟรมออกเป็นไฟล์วิดีโอได้โดยตรงเลย (ตัวเลือก ffmpeg) และมือใหม่หรือผู้ใช้ทั่วไปก็น่าจะทำแบบนั้นกันมาก
      จะใช้ compositor เพื่อเปลี่ยนลำดับเฟรมที่เรนเดอร์ไว้ล่วงหน้าให้เป็นไฟล์วิดีโอก็ได้
      แต่โดยมากคนคงชอบตัดต่อวิดีโอในโปรแกรมอื่นอย่าง Resolve มากกว่า และ VSE ก็ดูเหมือนอยู่ในขอบเขตแคบๆ แบบ “ต้องการแค่ตัดพื้นฐาน แต่ไม่ต้องการการแปลง, ชื่อเรื่อง, หรือเอฟเฟ็กต์” เลยทำให้ไม่ค่อยมีคนใช้
      อยากให้มีคนพัฒนาส่วนการแปลงและเอฟเฟ็กต์ต่อไป และสักวันเพิ่ม การตัดต่อแบบ 3 จุด เข้ามาด้วย

  • อ้อ Aras นี่เอง เขาเก่งมาก เก่งจริงๆ ฉันจำได้ว่าชื่อเต็มคือ The Amazing Aras
    เขาโดดเด่นมากในเรื่องการเขียนโค้ดกราฟิกส์และด้านอื่นๆ และดูเหมือนจะมี ภาวะลื่นไหลในการทำงาน ที่ดีมากเวลาเขียนโค้ดด้วย
    งานเขียนของเขาอ่านง่ายและสนุก ให้ความรู้สึกเหมือนกำลังฟังเจ้าตัวพูดอยู่ ประโยคอย่าง “However!” ตรงกลางก็เป็นแบบนั้น
    ตอนท้ายที่พูดว่าถ้าต้องถูกกดทับด้วยความคาดหวังเรื่องวัฒนธรรมและกระบวนการมาตรฐานของบริษัททั่วไป ผลิตภาพจะเหลือแค่ 30% ก็โดนใจมาก ต้นทุนของการผูกพนักงานไว้กับ “งานของตัวเอง” นั้นมีการลดลงของผลิตภาพอย่างมหาศาลรวมอยู่จริงๆ
    หวังว่าเมื่อเห็นกรณีแบบนี้เรื่อยๆ วิศวกรจะเรียนรู้วิธีจัดระเบียบผู้คนและกิจกรรมให้ดีขึ้น เชื่อในสิ่งที่เรียนรู้นั้น และเริ่มผสาน ผลิตภาพสูง/ภาวะจดจ่อสูง เข้ากับวิธีจัดองค์กรจริงๆ
    อย่างที่บทความสื่อไว้ ถ้าทำได้ งานในอุตสาหกรรมเทคโนโลยีก็น่าจะสนุกขึ้น อาจจะเกือบสนุกพอๆ กับการเล่นกับเทคโนโลยีเลยก็ได้

  • ขอกล่าวเสริมเกี่ยวกับ https://projects.blender.org/blender/blender/pulls/116089 ว่า inline ส่งผลกับ กฎการนิยามเพียงหนึ่งเดียว เป็นอันดับแรก
    พูดง่ายๆ คือถ้านิยามฟังก์ชันไว้ใน header แล้วเรียกจากหลายไฟล์ .cc ก็จะเกิด linker error เว้นแต่จะทำเครื่องหมายเป็น inline
    ส่วนผลต่อการทำ inline optimization จริงนั้นมีได้ตั้งแต่ “ไม่มีเลย” ไปจนถึง “คอมไพเลอร์อาจให้น้ำหนักต่างกันเพราะวิธีการลิงก์” หรือ “ยอมรับเป็นคำใบ้จริงๆ” และใน link-time optimization ก็มีข้อพิจารณาคล้ายกัน
    ถ้าต้องการส่งสัญญาณเรื่องการอินไลน์ให้แรงกว่านี้กับคอมไพเลอร์ โดยเฉพาะกับฟังก์ชันที่ใช้เฉพาะในไฟล์ที่นิยามมันไว้ การนิยามไว้ใน anonymous namespace จะดีกว่า
    เจตนาเดิมของการใส่ inline ให้ฟังก์ชันนั้นอาจเป็นความพยายามที่จะให้เกิดการอินไลน์จริง แม้ประโยชน์ที่วัดได้จะไม่ชัดเจน แต่ก็ไม่ใช่ว่าจะเป็นไปไม่ได้