ฉันจะสร้าง AVI ที่ไม่บีบอัดได้จากชุดภาพ PNG 1,000 รายการโดยใช้ FFMPEG ได้อย่างไร
ฉันใช้คำสั่งนี้เพื่อแปลงinput.aviไฟล์เป็นชุดของเฟรม PNG:
ffmpeg -y -i input.avi -an -vcodec png -s 1024x768 pic%d.png`
ตอนนี้ฉันต้องรู้วิธีสร้างวิดีโอ AVI ที่ไม่บีบอัดจากเฟรม PNG เหล่านั้นทั้งหมด ฉันลองสิ่งนี้:
ffmpeg -i pic%d.png -y -f avi -b 1150 -s 1024x768 -r 29.97 -g 12 -qmin 3 -qmax 13 -ab 224 -ar 44100 -ac 2 test.avi
แต่วิดีโอที่ได้นั้นจะเสียคุณภาพมากเมื่อเทียบกับ AVI ดั้งเดิม
คำตอบ:
มีหลายวิธีในการดึง AVI ออกจาก "ไม่บีบอัด" ffmpegแต่ฉันสงสัยว่าคุณหมายถึง "lossless" คำศัพท์ทั้งสองมีห้องกระดิกเล็กน้อยในคำจำกัดความของพวกเขาตามที่คุณจะเห็น
ฉันจะทอดทิ้งการสนทนานี้กับBig Buck Bunnyรุ่น 720p HD เนื่องจากเป็นวิดีโอที่ใช้งานได้อย่างอิสระเราทุกคนสามารถทดสอบและรับผลลัพธ์ที่เราสามารถเปรียบเทียบได้ อัตราข้อมูลดิบของวิดีโอ 1280 × 720p ที่ 24 fps นั้นใกล้เคียงกับที่คุณระบุไว้ที่ 1024 × 768 ที่เป้าหมาย 29.97 fps ดังนั้นผลลัพธ์ของฉันควรเป็นแนวทางที่ดีสำหรับอัตราข้อมูลที่คุณคาดหวังจากวิดีโอของคุณ
คำสั่ง POSIX ต่อไปนี้ให้รายการที่ส่วนใหญ่²ตรงกับสิ่งที่เราพูดถึงด้านล่าง:
$ ffmpeg -codecs 2> /dev/null | grep '^..EV..S ' | grep -vE 'bitmap|image'
คุณอาจต้องการรันคำสั่งนั้นบนเครื่องของคุณเองเพื่อดูว่าบิลด์ของ FFmpeg ของคุณรองรับอะไร FFmpeg สร้างขึ้นไม่ค่อยพร้อมกับเปิดใช้งานโปรแกรมเข้ารหัส
ตอนนี้ขอหารือเกี่ยวกับตัวเลือกเหล่านั้น
ถ้าความหมายของ "การบีบอัด" เป็นรูปแบบวิดีโอที่อยู่ในที่เหมาะสมก่อนที่จะหันไปโฟตอนโดยจอแสดงผลดิจิตอลที่อยู่ใกล้ที่สุดที่ฉันเห็นในffmpeg -codecsรายการมี-c:v r210, r10k, v410, v308, และayuv v408เหล่านี้ล้วนเป็นอย่างมากในสิ่งเดียวกันที่แตกต่างกันเพียง แต่ในความลึกของสี , พื้นที่สีและช่องอัลฟาสนับสนุน
R210และ R10Kเป็น RGB แบบ 4: 4: 4 ที่ 10 บิตต่อส่วนประกอบ (bpc) ดังนั้นทั้งคู่จึงต้องใช้ประมาณ 708 Mbit / sสำหรับ 720p ในการทดสอบของฉัน (นั่นคือประมาณ⅓ TB ต่อชั่วโมงเพื่อน!)
ตัวแปลงสัญญาณทั้งสองนี้บรรจุส่วนประกอบสี 3 × 10 บิตต่อพิกเซลเป็นค่า 32- บิตเพื่อความสะดวกในการจัดการโดยคอมพิวเตอร์ซึ่งเหมือนกับขนาดกำลังของ 2 ความแตกต่างเพียงอย่างเดียวระหว่างตัวแปลงสัญญาณเหล่านี้คือจุดสิ้นสุดของคำ 32 บิตที่บิตที่ไม่ได้ใช้สองบิตอยู่บน ความแตกต่างเล็กน้อยนี้ไม่ต้องสงสัยเลยว่ามาจาก บริษัท คู่แข่งคือBlackmagic DesignและAJA Video Systemsตามลำดับ
ถึงแม้ว่าสิ่งเหล่านี้เป็นตัวแปลงสัญญาณเล็กน้อยคุณอาจจะต้องดาวน์โหลดตัวแปลงสัญญาณ Blackmagic และ / หรือ AJA เพื่อเล่นไฟล์โดยใช้พวกเขาบนคอมพิวเตอร์ของคุณ ทั้งสอง บริษัท จะช่วยให้คุณดาวน์โหลดตัวแปลงสัญญาณของพวกเขาโดยไม่ต้องมีการซื้อฮาร์ดแวร์แรกของพวกเขาเพราะพวกเขารู้ว่าคุณอาจจะจัดการกับไฟล์ที่ผลิตโดยลูกค้าที่ทำมีบางส่วนของฮาร์ดแวร์ของพวกเขา
V410เป็นเพียงแค่รุ่น YUV ของ R210 / R10K; อัตราข้อมูลของพวกเขาเหมือนกัน อย่างไรก็ตามตัวแปลงสัญญาณนี้อาจเข้ารหัสเร็วกว่าเนื่องจากffmpegมีแนวโน้มที่จะมีเส้นทางการแปลงพื้นที่สีเร่งระหว่างพื้นที่สีของเฟรมอินพุตของคุณและพื้นที่สีนี้
ฉันไม่สามารถแนะนำตัวแปลงสัญญาณนี้ แต่เนื่องจากฉันไม่สามารถรับไฟล์ผลลัพธ์ที่จะเล่นในซอฟต์แวร์ใด ๆ ที่ฉันพยายามแม้จะติดตั้งตัวแปลงสัญญาณ AJA และ Blackmagic
V308เป็นตัวแปร 8 bpc ของ V410 ดังนั้นมันถึง 518 Mbit / sในการทดสอบของฉัน เช่นเดียวกับ V410 ฉันไม่สามารถทำให้ไฟล์เหล่านี้เล่นด้วยซอฟต์แวร์เครื่องเล่นวิดีโอธรรมดาได้
AYUVและV408นั้นเป็นสิ่งเดียวกับ V308 ยกเว้นว่าพวกเขามีช่องอัลฟาไม่ว่าจะจำเป็นหรือไม่! หากวิดีโอของคุณไม่ใช้ความโปร่งใสหมายความว่าคุณจ่ายค่าปรับขนาดของตัวแปลงสัญญาณ 10 bpc R210 / R10K ด้านบนโดยไม่ได้รับประโยชน์จากพื้นที่สีที่ลึกกว่า
AYUV มีข้อดีเพียงอย่างเดียวนั่นคือตัวแปลงสัญญาณ "ดั้งเดิม" ใน Windows Media ดังนั้นจึงไม่จำเป็นต้องมีซอฟต์แวร์พิเศษในการเล่น
V408 นั้นน่าจะเป็น QuickTime เหมือนกัน แต่ไฟล์ V408 จะไม่เล่นใน QuickTime 7 หรือ 10 บน Mac ของฉัน
ดังนั้นให้รวมทั้งหมดเข้าด้วยกันหาก PNG ของคุณมีชื่อframe0001.pngและอื่น ๆ :
$ ffmpeg -i frame%04d.png -c:v r10k output.mov
...or... -c:v r210 output.mov
...or... -c:v v410 output.mov
...or... -c:v v408 output.mov
...or... -c:v v308 output.mov
...or... -c:v ayuv output.avi
โปรดสังเกตว่าฉันได้ระบุ AVI ในกรณีของ AYUV เนื่องจากเป็นตัวแปลงสัญญาณ Windows เท่านั้น ผู้อื่นอาจทำงานใน QuickTime หรือ AVI ขึ้นอยู่กับว่าตัวแปลงสัญญาณใดอยู่ในเครื่องของคุณ หากรูปแบบคอนเทนเนอร์หนึ่งไม่ทำงานลองอีกรูปแบบหนึ่ง
คำสั่งข้างต้น - และคำสั่งด้านล่างด้วย - สมมติว่าอินพุตเฟรมของคุณมีขนาดเดียวกันกับที่คุณต้องการสำหรับวิดีโอเอาต์พุตของคุณแล้ว ถ้าไม่เพิ่มสิ่งที่ต้องการ-s 1280x720คำสั่งก่อนที่ชื่อไฟล์ที่ส่งออก
ถ้าอย่างที่คุณสงสัยคุณหมายถึง "lossless" แทนที่จะเป็น "uncompressed" ตัวเลือกที่ดีกว่าตัวเลือกใด ๆ ข้างต้นคือApple QuickTime Animationผ่าน-c:v qtrle
ฉันรู้ว่าคุณบอกว่าคุณต้องการ AVI แต่ความจริงก็คือคุณอาจจะต้องติดตั้งตัวแปลงสัญญาณบนเครื่อง Windows เพื่ออ่านรูปแบบไฟล์ที่ใช้ AVI ที่กล่าวถึงที่นี่ในขณะที่ QuickTime มีโอกาสวิดีโอ แอพที่คุณเลือกรู้วิธีเปิดไฟล์ QuickTime Animation (ตัวแปลงสัญญาณ AYUV ด้านบนเป็นข้อยกเว้นเดียวที่ฉันทราบ แต่อัตราข้อมูลของมันสูงมากเพียงเพื่อให้ได้ประโยชน์จาก AVI)
ffmpegจะqtrleบรรจุลงในคอนเทนเนอร์ AVI สำหรับคุณ แต่ผลลัพธ์อาจไม่เข้ากันอย่างแพร่หลาย ในการทดสอบของฉัน QuickTime Player จะจับไฟล์ดังกล่าวเล็กน้อย แต่ก็เล่นได้ แม้ว่าผิดปกติVLCจะไม่เล่นแม้ว่ามันจะเป็นส่วนหนึ่งffmpegก็ตาม ฉันจะติดกับภาชนะ QT สำหรับตัวแปลงสัญญาณนี้
ตัวแปลงสัญญาณภาพเคลื่อนไหว QuickTime ใช้รูปแบบRLE ที่ไม่สำคัญดังนั้นสำหรับแอนิเมชั่นที่เรียบง่ายก็ควรทำเช่นเดียวกับ Huffyuv ด้านล่าง ยิ่งมีสีมากขึ้นในแต่ละเฟรมมากเท่าไหร่มันก็จะยิ่งเข้ามาถึงอัตราบิตของตัวเลือกที่ไม่มีการบีบอัดด้านบนทั้งหมด ในการทดสอบกับ Big Buck Bunny ฉันสามารถffmpegให้ไฟล์165 Mbit / sในโหมด RGB 4: 4: 4 ผ่านทาง-pix_fmt rgb24ฉันได้
แม้ว่ารูปแบบนี้จะถูกบีบอัด แต่จะให้ค่าพิกเซลเอาต์พุตที่เหมือนกันกับไฟล์อินพุต PNG ของคุณด้วยเหตุผลเดียวกับการบีบอัด lossless ของ PNG ที่ไม่มีผลต่อค่าพิกเซล
การffmpegใช้งาน QuickTime Animation ยังช่วย-pix_fmt argbให้คุณได้รับ RGB 4: 4: 4: 4 ซึ่งหมายความว่ามีช่องอัลฟา ในวิธีที่คร่าวๆมันเป็น QuickTime ที่เทียบเท่ากับที่-c:v ayuvกล่าวถึงข้างต้น อย่างไรก็ตามเนื่องจากการบีบอัดแบบไม่สูญเสียข้อมูลมันมีเพียง214 Mbit / sซึ่งน้อยกว่า data อัตราข้อมูลของ AYUV โดยไม่มีการสูญเสียคุณภาพหรือคุณลักษณะ
QuickTime Animation มีหลากหลายรูปแบบที่น้อยกว่า 24 บิตต่อพิกเซล แต่พวกมันถูกใช้อย่างดีที่สุดสำหรับสไตล์แอนิเมชั่นที่เรียบง่ายขึ้น ffmpegดูเหมือนจะสนับสนุนรูปแบบอื่นเพียงหนึ่งรูปแบบที่กำหนดโดยสเป็ค-pix_fmt rgb555beซึ่งหมายถึง RGB บิ๊ก - เอนเดียน 15 bpp สามารถใช้งานได้กับวิดีโอบางวิดีโอและใช้ได้ดีสำหรับการบันทึกหน้าจอ screencast และภาพเคลื่อนไหวที่เรียบง่าย หากคุณสามารถยอมรับการลดพื้นที่สีคุณอาจพบว่าอัตราการส่งข้อมูล122 Mbit / sน่าดึงดูด
นำทั้งหมดนี้มารวมกัน:
$ ffmpeg -i frame%04d.png -c:v qtrle -pix_fmt rgb24 output.mov
...or... -pix_fmt argb output.mov
...or... -pix_fmt rgb555be output.mov
ทีนี้สิ่งที่เกี่ยวกับ RGB และ4: 4: 4 YUVคือการเข้ารหัสเหล่านี้ง่ายมากสำหรับคอมพิวเตอร์ที่จะประมวลผล แต่พวกเขาไม่สนใจข้อเท็จจริงเกี่ยวกับการมองเห็นของมนุษย์ซึ่งดวงตาของเราไวต่อความแตกต่างของสีดำและขาวมากกว่าความแตกต่างของสี .
ระบบจัดเก็บและจัดส่งวิดีโอเกือบทุกครั้งจึงใช้บิตต่อพิกเซลสำหรับข้อมูลสีน้อยกว่าข้อมูลความสว่าง สิ่งนี้เรียกว่าการย่อยตัวอย่างด้วยสี แผนการที่พบบ่อยที่สุดคือ 4: 2: 0 และ 4: 2: 2
อัตราการส่งข้อมูล 4: 2: 0 YUV สูงกว่าวิดีโอขาวดำ (Y เท่านั้น) ที่ไม่ได้บีบอัดและมีอัตราการส่งข้อมูล 4: 4: 4 RGB หรือ YUV เพียง 50%
4: 2: 2 เป็นจุดกึ่งกลางระหว่าง 4: 2: 0 และ 4: 4: 4 เป็นอัตราข้อมูลสองเท่าของวิดีโอ Y เท่านั้นและอัตราข้อมูล 4: 4: 4
นอกจากนี้คุณยังบางครั้งเห็น 4: 1: 1 ในขณะที่เก่ามาตรฐานกล้อง DV 4: 1: 1 มีอัตราการส่งข้อมูลที่ไม่บีบอัดเท่ากับ 4: 2: 0 แต่ข้อมูลสีถูกจัดเรียงต่างกัน
ประเด็นทั้งหมดนี้คือถ้าคุณเริ่มต้นด้วยไฟล์ 4: 2: 0 H.264 ให้ทำการเข้ารหัสอีกครั้งเป็น 4: 4: 4 RGB ที่ไม่มีการบีบอัดซื้อคุณไม่มีอะไรมากไปกว่า YUV ที่บีบอัด 4: 2: 0 สิ่งนี้เป็นจริงแม้ว่าคุณจะรู้ว่าเวิร์กโฟลว์ของคุณเป็นอย่างอื่น 4: 4: 4 RGB เนื่องจากเป็นการแปลงที่ไม่สำคัญ ฮาร์ดแวร์วิดีโอและซอฟต์แวร์ทำการแปลงในทันทีอย่างสม่ำเสมอ
คุณต้องการเพียง 4: 4: 4 เมื่อคุณมองพิกเซลหรือคุณกำลังเปลี่ยนสีระดับพิกเซลของวิดีโอและคุณต้องรักษาค่าพิกเซลที่แน่นอน วิชวลเอฟเฟ็กต์ (VFX) ทำงานได้ง่ายกว่าด้วยรูปแบบพิกเซล 4: 4: 4 ดังนั้นบ้าน VFX ระดับไฮเอนด์จึงมักจะยอมทนต่ออัตราข้อมูลที่สูงขึ้นตามที่ต้องการ
เมื่อคุณเปิดตัวแปลงสัญญาณสูงถึง YUV พร้อมการลดสีตัวเลือกของคุณก็เปิดขึ้นเช่นกัน ffmpegมีตัวแปลงสัญญาณlossless อย่างมีประสิทธิภาพมาก
ตัวเลือกที่เข้ากันได้อย่างกว้างขวางมากที่สุดคือHuffyuv คุณได้รับทาง-c:v huffyuvนี้
ตัวแปลงสัญญาณ Windows Huffyuv ดั้งเดิมรองรับรูปแบบพิกเซลสองรูปแบบเท่านั้น: RGB24 และ YUV 4: 2: 2 (ที่จริงแล้วมันรองรับสองรสชาติของ YUV 4: 2: 2 ซึ่งแตกต่างกันตามลำดับของไบต์บนดิสก์เท่านั้น)
รุ่นเก่าของ FFmpeg Huffyuv codec ไม่ได้รวมการสนับสนุน RGB24 ดังนั้นหากคุณลองใช้และ FFmpeg บอกว่ากำลังจะใช้yuv422pรูปแบบพิกเซลคุณต้องอัปเกรด
FFmpeg ยังมีตัวแปลงสัญญาณตัวแปร Huffyuv ที่เรียกว่า FFVHuff ซึ่งรองรับ YUV 4: 2: 0 ตัวแปรนี้เข้ากันไม่ได้กับตัวแปลงสัญญาณ Windows DirectShow Huffyuv แต่ควรเปิดในซอฟต์แวร์ที่อ้างอิงlibavcodecเช่น VLC
RGB24 - RGB 4: 4: 4 เป็นหลักเหมือนกับตัวเลือกพื้นที่สี RGB24 Animation ตัวแปลงสัญญาณที่สองจะแตกต่างกันบ้างในการบีบอัดสำหรับแฟ้มที่กำหนด แต่โดยปกติจะปิด
มันก็เป็นสิ่งเดียวกันกับโหมด YUV 4: 4: 4 ที่ใช้โดยตัวเลือก V308 ด้านบน ความแตกต่างของพื้นที่สีไม่ได้มีความแตกต่างในทางปฏิบัติเนื่องจากการแปลงพื้นที่สีทำได้ง่ายในเวลาจริง
เนื่องจากการบีบอัดแบบไม่มีการสูญเสียของ Huffyuv ฉันสามารถรับวิดีโอทดสอบเพื่อบีบอัดได้ถึง251 Mbit / sในโหมด RGB24 ด้วยคุณภาพภาพที่เหมือนกันกับสิ่งที่คุณได้รับจาก V308 หรือ AYUV หาก AVI เป็นสิ่งที่จำเป็นอย่างยิ่งสำหรับคุณการติดตั้งตัวแปลงสัญญาณ Huffyuvอาจเจ็บปวดน้อยกว่าการจ่ายค่าอัตราข้อมูล 3 เท่าของ AYUV
YUV 4: 2: 2 - โหมดนี้มีประโยชน์มากกว่าสำหรับวิดีโอมากกว่า RGB24 ซึ่งไม่ต้องสงสัยเลยว่าทำไมffmpegนักพัฒนาจึงเลือกที่จะใช้งานมันก่อน ในขณะที่คุณคาดหวังจากการลด⅔ทฤษฎีที่กล่าวข้างต้นไฟล์ทดสอบของฉันเข้ารหัส173 Mbit / s นั่นเป็นเรื่องที่ค่อนข้าง⅔หากคุณคำนึงถึงความจริงที่ว่าแทร็กเสียงไม่เปลี่ยนแปลงระหว่างการทดสอบทั้งสองนี้
YUV 4: 2: 0 - ตัวเลือกนี้ decimates ข้อมูลสีมากกว่า 4: 2: 2 ทำลดอัตราข้อมูลเป็น133 Mbit / sในการทดสอบของฉัน
นำทั้งหมดนี้มารวมกัน:
$ ffmpeg -i frame%04d.png -c:v huffyuv -pix_fmt rgb24 output.avi
...or... -pix_fmt yuv422p output.avi
...or... -c:v ffvhuff -pix_fmt yuv420p output.avi
แม้ว่าffvhuffตัวแปลงสัญญาณจะมีค่าเริ่มต้นเป็น 4: 2: 0 ตามที่ฉันเขียนและรองรับเฉพาะรูปแบบพิกเซลนั้นในรุ่นที่วางจำหน่ายที่ฉันกำลังใช้งาน แต่สิ่งนี้กำลังเปลี่ยนแปลงดังนั้นคุณควรรวมค่าสถานะไว้ในกรณีที่การเปลี่ยนแปลงเริ่มต้นนี้
ตัวเลือกที่มากขึ้นล่าสุดในจิตวิญญาณเดียวกับ Huffyuv และ FFVHuff เป็นUt วิดีโอ เช่นเดียวกับ Huffyuv มีตัวแปลงสัญญาณวิดีโอ Windowsซึ่งหมายความว่าโปรแกรม Windows ใด ๆ ที่สามารถเล่นภาพยนตร์สามารถเล่นวิดีโอโดยใช้ตัวแปลงสัญญาณนี้เมื่อติดตั้งตัวแปลงสัญญาณ ซึ่งแตกต่างจาก Huffyuv นอกจากนี้ยังมีตัวแปลงสัญญาณวิดีโอ Mac ด้วยดังนั้นคุณจึงไม่ จำกัด เฉพาะซอฟต์แวร์ที่อ้างอิง FFmpeg หรือlibavcodecอ่านไฟล์เหล่านี้บน Macs
ตัวแปลงสัญญาณนี้มีความยืดหยุ่นมากในแง่ของพื้นที่สีดังนั้นฉันจะให้ตัวอย่างของพื้นที่สีทั่วไป:
4: 4: 4 RGBผ่าน-f avi -c:v utvideo -pix_fmt rgb24ให้เอาต์พุต178 Mbit / วินาที
4: 4: 4 YUVผ่าน-f avi -c:v utvideo -pix_fmt yuv444pให้เอาต์พุต153 Mbit / วินาที
4: 2: 2 YUVผ่าน-f avi -c:v utvideo -pix_fmt yuv422pให้เอาต์พุตMbit 123 / วินาที
4: 2: 0 YUVผ่าน-f avi -c:v utvideo -pix_fmt yuv420pให้เอาต์พุต100 Mbit / วินาที
ฉันสงสัยว่า 4: 4: 4 YUV ทำได้ดีกว่า RGB 4: 4: 4 ในการทดสอบนี้แม้จะมีเทคนิคเทียบเท่ากันเพราะวิดีโอต้นฉบับเป็น 4: 2: 0 YUV ดังนั้นการจัดเรียงข้อมูลในรูปแบบ YUV ช่วยให้การบีบอัดแบบ lossless ดีกว่า โดยการจัดกลุ่มช่องสัญญาณ U และ V ที่ซ้ำซ้อนบางส่วนเข้าด้วยกันในไฟล์
อีกหนึ่งทางเลือกที่น่าสนใจในพื้นที่นี้เป็นของตัวเอง FFmpeg ของตัวแปลงสัญญาณFFV1 ส่วนใหญ่จะใช้เป็นตัวแปลงสัญญาณจดหมายเหตุมากกว่าการเล่นหรือการแก้ไขตัวแปลงสัญญาณ แต่เนื่องจากซอฟต์แวร์จำนวนมากมีพื้นฐานมาจากlibavcodecไลบรารีที่สนับสนุน FFmpeg หรือสามารถใช้libavcodecเครื่องมือเช่นffdshowนี้จึงอาจเป็นประโยชน์สำหรับคุณอยู่ดี
โดยค่าเริ่มต้นffmpegจะรักษาพื้นที่สีของไฟล์อินพุตของคุณเมื่อใช้ตัวแปลงสัญญาณที่ยืดหยุ่นเช่น FFV1 ดังนั้นหากคุณป้อนหนึ่งในไฟล์ทางการของ Big Buck Bunny MP4 ซึ่งใช้ 4: 2: 0 YUV นั่นคือสิ่งที่คุณจะได้รับ ออกจนกว่าคุณจะให้ธง-pix_fmt ffmpegสิ่งนี้ส่งผลให้ไฟล์เอาต์พุต63 Mbit / s
หากคุณบังคับให้ FFV1 ใช้พื้นที่สี YUV 4: 4: 4 ด้วย-pix_fmt yuv444pขนาดไฟล์จะสูงถึง86 Mbit / วินาทีแต่มันไม่ได้ซื้อเราในกรณีนี้เนื่องจากเราเข้ารหัสจากต้นฉบับ 4: 2: 0 . อย่างไรก็ตามหากคุณป้อนชุด PNG แทนเช่นเดียวกับคำถามเดิมไฟล์ที่ส่งออกมีแนวโน้มที่จะใช้bgraหรือbgr0ช่องว่างสีซึ่งเป็นเพียงการจัดเรียงใหม่ของช่องว่างสีargbและrgb24ด้านบน
อีกทางเลือกที่น่าสนใจคือLossless H.264 นี่เป็นสิ่งที่x264 เพียงอย่างเดียวของการเขียนนี้ แต่ผู้ที่ใช้ FFmpeg ที่ด้านการเข้ารหัสนั้นมีแนวโน้มที่จะใช้ซอฟต์แวร์อื่นที่รวมถึงlibx264ด้านการถอดรหัสเช่น VLC
วิธีที่ง่ายที่สุดในการรับไฟล์คือ:
$ ffmpeg -i frame%04d.png -c:v libx264 -qp 0 -f mp4 output.mp4
การ-qp 0ตั้งค่าสถานะเป็นคีย์: ค่าที่สูงกว่าให้การบีบอัดแบบ lossy (คุณสามารถให้-crf 0ผลเหมือนเดิมได้ด้วย)
เช่นเดียวกับ FFV1 ffmpegจะพยายามคาดเดาพื้นที่สีเอาท์พุทที่ดีที่สุดที่ได้รับจากพื้นที่สีอินพุทดังนั้นเมื่อเปรียบเทียบกับผลลัพธ์ข้างต้นฉันใช้การเข้ารหัสหลายรอบในไฟล์ต้นฉบับ Big Buck Bunny ที่มีช่องว่างสีต่างกัน:
yuv444p : นี่คือสิ่งที่ffmpegเลือกเมื่อคุณให้มันเป็นสตรีม PNG RGB เช่นเดียวกับในคำถามเดิมและส่งผลให้ไฟล์44 Mbit / วินาทีพร้อมไฟล์ทดสอบของเรา
yuv422p : นี่คล้ายกับพื้นที่สีเริ่มต้นสำหรับ Huffyuv แต่เราได้รับไฟล์34 Mbit / วินาทีในกรณีนี้ค่อนข้างประหยัด!
yuv420p : นี่เป็นค่าเริ่มต้นสำหรับ MP4 อย่างเป็นทางการของ Big Buck Bunny ที่ฉันกำลังทดสอบและให้ผลลัพธ์เป็นไฟล์29 Mbit / วินาที
ระวังว่าคุณกำลังแลกเปลี่ยนความเข้ากันได้มากมายเพื่อให้ได้ขนาดไฟล์เล็ก ๆ นั่นเป็นเหตุผลที่ฉันไม่ได้แม้แต่จะพยายามยัดสิ่งนี้ลงในคอนเทนเนอร์ AVI หรือ MOV มันเชื่อมโยงกับ x264 อย่างใกล้ชิดจนคุณอาจใช้ประเภทคอนเทนเนอร์มาตรฐาน (MP4) แทน คุณสามารถใช้บางอย่างเช่นMatroskaสำหรับสิ่งนี้
-preset ultrafastคุณสามารถค้าปิดบางส่วนของอัตราบิตที่เป็นเวลาเข้ารหัสเร็วขึ้นโดยการเพิ่ม นั่นเพิ่มอัตราบิตของไฟล์ทดสอบของฉันเป็น44 Mbit / sในโหมด YUV 4: 2: 2 แต่เข้ารหัสเร็วกว่ามากตามที่สัญญา เอกสารที่อ้างว่า-preset veryslowยังคุ้มค่า แต่ก็ส่งผลให้มากเวลาเข้ารหัสอีกต่อไปขณะที่มีเพียงประหยัดบิตขนาดเล็กของพื้นที่; ฉันไม่สามารถแนะนำได้
ffmpegนอกจากนี้ยังสนับสนุนโหมดการถอดรหัสเท่านั้นสำหรับLagarithและโหมดการเข้ารหัสเท่านั้นสำหรับLossless JPEG ตัวแปลงสัญญาณทั้งสองนี้ค่อนข้างคล้ายกันจริง ๆ และควรให้ไฟล์เล็กกว่า Huffyuv ที่มีคุณภาพเท่ากัน หากffmpegนักพัฒนาเคยเพิ่มการเข้ารหัส Lagarith มันจะเป็นทางเลือกที่ดีสำหรับ Huffyuv ฉันไม่สามารถแนะนำ Lossless JPEG ได้เนื่องจากไม่รองรับการถอดรหัสแบบกว้าง
จากนั้นก็มีตัวแปลงสัญญาณที่ไม่สูญเสียการรับรู้เป็น คุณจะไม่สามารถบอกได้ว่าสิ่งเหล่านี้ให้ผลลัพธ์ทางภาพที่แตกต่างจากสองกลุ่มก่อนหน้านี้ ด้วยการละทิ้งแนวคิดที่ไม่มีการเปลี่ยนแปลงอย่างแน่นอนระหว่างเซ็นเซอร์จับภาพวิดีโอและอุปกรณ์แสดงผลคุณจึงประหยัดได้มาก:
Apple ProRes :-c:v proresหรือ-c:v prores_ks- ProRes เป็นตัวแปลงสัญญาณตามโปรไฟล์ซึ่งหมายความว่ามีหลายรูปแบบโดยแต่ละรุ่นมีคุณภาพแตกต่างกันเมื่อเทียบกับการแลกเปลี่ยนพื้นที่:
ProRes 4444ถอดรหัสวิดีโอการทดสอบของเราใช้เพียง 114 Mbit / sแต่เป็นคุณภาพ VFX ขณะนี้มีprores*ตัวแปลงสัญญาณที่แตกต่างกันสามตัวใน FFmpeg แต่prores_ksรองรับ ProRes 4444 เท่านั้นขณะที่ฉันเขียนสิ่งนี้ผ่าน-profile:v 4444ตัวเลือก
หากคุณสงสัยว่าทำไมคุณถึงต้องกังวลกับ ProRes 4444 มากกว่า Lossless H.264 มันมาพร้อมกับความเข้ากันได้ความเร็วในการถอดรหัสการคาดการณ์และช่องอัลฟา
ProRes 422ช่วยประหยัดพื้นที่ได้มากขึ้นต้องการเพียง 84 Mbit / sเพื่อให้ผลลัพธ์ที่คุณสามารถบอกได้จาก ProRes 4444 เพียงแค่การพิกเซลแบบ peeping หากคุณไม่ต้องการช่องอัลฟาที่เสนอโดย ProRes 4444 อาจไม่มีเหตุผลที่จะยืนยัน ProRes 4444
ProRes 422 เป็นคู่แข่งที่ใกล้กว่าตัวเลือก Lossless H.264 ด้านบนเนื่องจากไม่รองรับช่องอัลฟ่า คุณจะต้องทนต่ออัตราบิตที่สูงขึ้นของ ProRes หากคุณต้องการความเข้ากันได้กับแอป Apple pro วิดีโอ, ค่าใช้จ่าย CPU ที่ต่ำกว่าสำหรับการเข้ารหัสและถอดรหัสหรืออัตราบิตที่คาดการณ์ได้ หลังมีความสำคัญกับตัวเข้ารหัสฮาร์ดแวร์ตัวอย่างเช่น ในทางกลับกันถ้าคุณสามารถรับมือกับปัญหาความเข้ากันได้ของ Lossless H.264 คุณจะได้รับตัวเลือกในการใช้พื้นที่สี 4: 2: 0 ซึ่งไม่ใช่ตัวเลือกจากโปรไฟล์ ProRes ใด ๆ
ตัวเข้ารหัส ProRes ทั้งสามใน FFmpeg สนับสนุนโปรไฟล์ ProRes 422 ดังนั้นตัวเลือกที่ง่ายที่สุดคือการใช้-c:v proresแทนที่จะใช้-c:v prores_ks -profile hqหรือขึ้นอยู่กับฟีเจอร์โปรไฟล์อัตโนมัติของprores_ksการทำสิ่งที่ถูกต้อง
มีโปรไฟล์ ProRes ที่น่าจดจำมากขึ้น แต่มันมีไว้สำหรับวิดีโอ SD หรือพร็อกซี่สำหรับไฟล์ความละเอียดเต็ม
ปัญหาหลักของ ProRes คือยังไม่มีการสนับสนุนอย่างกว้างขวางนอก Apple และโลกวิดีโอมืออาชีพ
DNxHD ของ Avidเป็นตัวแปลงสัญญาณที่คล้ายคลึงกับ ProRes แต่ไม่ได้เชื่อมโยงกับโลกวิดีโอของ Apple pro ข้อเสนอ Avidตัวแปลงสัญญาณได้อย่างอิสระที่สามารถดาวน์โหลดได้ทั้ง Windows และ Macintosh และ FFmpeg -c:v dnxhdขณะนี้สนับสนุนผ่านทาง
เนื่องจาก DNxHD เป็นตัวแปลงสัญญาณตามโปรไฟล์เช่น ProRes คุณจึงเลือกโปรไฟล์จากชุดที่กำหนดไว้ล่วงหน้าและนั่นจะบอกตัวแปลงสัญญาณว่าขนาดเฟรมอัตราเฟรมและอัตราบิตที่จะใช้ สำหรับไฟล์ทดสอบ Big Buck Bunny -b:v 60Mโปรไฟล์จะเหมาะสมที่สุด แปลกใจแฟ้มผลเป็นเรื่องเกี่ยวกับ59 Mbit / s
MJPEG ที่สูญเสียต่ำ :-vcodec mjpeg -qscale:v 1- นี่เป็นเรื่องธรรมดามากกว่า JPEG ที่ไม่มีการสูญเสีย ในความเป็นจริงแล้วนี่เคยเป็นตัวแปลงสัญญาณวิดีโอที่ใช้กันทั่วไปและมันก็ยังถูกใช้อย่างแพร่หลายโดยสิ่งต่างๆเช่นกล้องวิดีโอสตรีมมิ่งบนเครือข่าย ประวัติทั้งหมดนั้นหมายความว่าง่ายต่อการค้นหาซอฟต์แวร์ที่รองรับ
คาดหวังความแปรปรวนในอัตราข้อมูลจาก codec นี้ การทดสอบที่ฉันทำที่นี่ให้ฉัน25 Mbit / sสำหรับวิดีโอความละเอียด 720p การบีบอัดสูงพอที่จะทำให้ฉันกังวลเกี่ยวกับการสูญเสีย แต่มันก็ดูดีสำหรับฉัน จากอัตราการส่งข้อมูลเพียงอย่างเดียวฉันอาจบอกได้ว่ามันคงเป็นเรื่องคุณภาพที่ดีสำหรับ12 Mbit / s MPEG-2 หรือ6 Mbit / s H.264
นำทั้งหมดนี้มารวมกัน:
$ ffmpeg -i frame%04d.png -c:v prores_ks -profile:v 4444 output.mov
...or... -c:v prores_ks -profile:v hq output.mov
...or... -c:v prores output.mov
...or... -c:v dnxhd -b:v 60M output.mov
...or... -c:v mjpeg -qscale:v 1 output.avi
บรรทัดล่างของวิธีการเหล่านี้คือถ้าคุณไม่ทำสิ่งที่ท้าทายมาก "ดีพอ" ดีพอ
เชิงอรรถและการแยกย่อย
คำสั่งควรทำงานตามที่กำหนดไว้บน Linux, macOS, BSDs และ Unix หากคุณอยู่ใน Windows คุณสามารถได้รับบรรทัดคำสั่ง POSIX ผ่านCygwinหรือWSL
มีสาเหตุหลายประการที่ทำให้รายการที่สร้างโดยคำสั่งนั้นไม่ตรงกับชุดของตัวแปลงสัญญาณที่ฉันเลือกที่จะกล่าวถึงข้างต้น:
ประการที่สองgrepมีวัตถุประสงค์เพื่อกรองตัวเข้ารหัสที่ไม่เหมาะสมbmpซึ่งไม่ใช่ตัวแปลงสัญญาณ "วิดีโอ" แม้จะถูกติดแท็กVในรายการนี้ ในขณะที่ในทางเทคนิคคุณอาจจะสิ่งที่หลายเหล่านี้ลงในภาชนะเช่น AVI, MP4, MKV หรือที่จะได้รับวิดีโอไฟล์เดียวไฟล์ที่จะไม่น่าจะอ่านได้จากอะไร แต่โปรแกรมที่อยู่บนพื้นฐานหรือffmpeglibavcodec
มีข้อยกเว้นบางประการเช่น-f avi -c:v ljpegสิ่งนี้ให้บางสิ่งที่คุณสามารถเรียกว่า "Lossless MJPEG" แต่ตามกฎแล้วเราไม่สนใจที่จะบรรจุไฟล์ภาพนิ่งจำนวนมากลงในคอนเทนเนอร์ A / V ที่นี่เพื่อสร้างภาพยนตร์ เราต้องการตัวแปลงสัญญาณวิดีโอที่ได้รับการยอมรับอย่างกว้างขวางที่นี่ไม่ใช่กลอุบายความหมาย
คำสั่งในขณะนี้ล้มเหลวในการกรองเข้ารหัสที่ไม่เหมาะสมบางอย่างเช่น GIF เพราะพวกเขาจะไม่ได้อธิบายไว้ในปัจจุบันffmpeg -codecsออกเป็นbitmapหรือimageรูปแบบไฟล์
GIF เป็นกรณีที่น่าสนใจ: มันรองรับเฟรมรูปภาพหลายเฟรมในไฟล์ GIF เดียวพร้อมข้อมูลเวลาสำหรับเล่นภาพเคลื่อนไหว แต่ด้วยเหตุผลหลายประการมันไม่เหมาะสมอย่างสิ้นเชิงกับการอภิปรายของเราที่นี่
ไม่กี่ตัวเลือกที่แสดงจะล้าสมัยหรือไม่เคยมีแรงดึงมากเช่นflashsv, diracและsnowดังนั้นจึงไม่คุ้มค่าการหารือดังกล่าวข้างต้น
บางตัวเลือกในรายการที่มีความหมายเฉพาะสำหรับการใช้งานในท่อระหว่างffmpegอินสแตนซ์หรือระหว่างffmpegและโปรแกรมอื่นเช่นrawvideoและwrapped_avframeและเพื่อให้มีที่ไม่เหมาะสมสำหรับวัตถุประสงค์ของเราที่นี่
ใกล้ถึงจุดสิ้นสุดของการสนทนาข้างต้นฉันจะขยายขอบเขตของคำถามเล็กน้อยเพื่อรวมตัวเลือกการสูญเสียที่เลือกไว้อย่างระมัดระวังเพื่อให้พวกเขาไม่ผ่านgrepตัวกรองแรกในคำสั่งด้านบน
ดังนั้นฉันเลยทำให้คำตอบของตัวเองนานเกินไป
TL; DR สรุป: สำหรับการจัดเก็บ losslessly ลำดับของภาพใช้libx264หรือมีlibx264rgb -preset ultrafast -qp 0มันเกือบจะเร็วเท่ากับ ffvhuff ที่มีอัตราบิตต่ำกว่ามากและถอดรหัสได้เร็วขึ้น huffyuvได้รับการสนับสนุนอย่างกว้างขวางมากขึ้นนอก ffmpeg แต่ไม่รองรับรูปแบบพิกเซลมากเท่าที่ffvhuffควร นั่นเป็นอีกเหตุผลหนึ่งที่ใช้ h.264 สมมติว่าเครื่องมืออื่น ๆ ของคุณสามารถจัดการHigh 4:4:4 Predictiveโปรไฟล์h.264 ที่ x264 ใช้ในโหมด lossless x264 สามารถทำการภายในเท่านั้นถ้าต้องการการเข้าถึงเฟรมสุ่มอย่างรวดเร็ว
ระวังข้อผิดพลาด ffmpeg ที่มีผลต่อ libx264rgb เมื่ออ่านจากไดเรกทอรีรูปภาพ (และใครจะรู้ว่ามีกรณีอื่น ๆ อีกบ้าง) ทดสอบความสูญเสียในการตั้งค่าของคุณก่อนใช้งาน (ง่ายกับffmpeg -i in -pix_fmt rgb24 -f framemd5แหล่งที่มาและการบีบอัดแบบไม่สูญเสีย)
แก้ไข: utvideoเข้ารหัสและถอดรหัสค่อนข้างเร็วและเป็นตัวแปลงสัญญาณที่ง่ายกว่า h.264 มันเป็นพื้นที่ทันสมัยhuffyuvพร้อมการรองรับ colorpaces ที่มีประโยชน์มากขึ้น หากคุณเคยมีปัญหากับ h.264 ลอง utvideo ถัดไปสำหรับไฟล์ชั่วคราว
แก้ไข 2: PNG ในฐานะตัวแปลงสัญญาณ RGB ดูเหมือนว่าจะทำได้ดีอย่างน้อยในตัวอย่าง Sintel
ดูคำตอบที่คล้ายกันของฉันสำหรับคำถามที่คล้ายกัน: https://superuser.com/a/860335/20798
มีข้อมูลจำนวนมากในคำตอบของ Warren Young เกี่ยวกับรูปแบบและตัวแปลงสัญญาณดิบที่หลากหลาย ฉันคิดว่าคำตอบจะมีประโยชน์มากกว่านี้ถ้ามันสั้นกว่านี้ดังนั้นฉันจึงสร้างคำตอบใหม่ หากคุณกำลังทำงานกับซอฟต์แวร์ที่ไม่สนับสนุน lossless x264 หรือ ffvhuff แสดงว่าข้อมูลบางอย่างนั้นยังคงมีประโยชน์
คำจำกัดความที่มีประโยชน์ที่สุดของ "lossless" ในบริบทนี้คือคุณสามารถกู้คืนบิตอินพุตสำหรับบิตได้ ไม่ต้องกังวลกับการลดคุณภาพจากการเข้ารหัสวิดีโอไม่ว่าคุณจะทำอะไร
http://en.wikipedia.org/wiki/Chroma_subsampling
เป็นการดีหลีกเลี่ยงการแปลงหลายสี ข้อผิดพลาดในการปัดเศษอาจเกิดขึ้นได้ หากคุณกำลังจะใช้งานวิดีโอของคุณด้วยตัวกรองที่ทำงานในพื้นที่สี RGB แสดงว่า RGB นั้นเหมาะสมแล้วตราบใดที่บิตเรตที่สูงขึ้นก็ไม่ใช่ปัญหา คุณอาจจะผลิตyuv 4:2:0วิดีโอในท้ายที่สุดแต่การรักษาความละเอียดของสีเพิ่มอาจมีประโยชน์ขึ้นอยู่กับตัวกรองที่คุณจะนำไปใช้
ทั้งทาง x264 lossless และ ffvhuff ทั้งสนับสนุน RGB และ YUV 4:4:4, และ4:2:2 4:2:0ฉันแนะนำ x264 เพราะมันเร็วในการถอดรหัส หากคุณกำลังพยายามเล่นวิดีโอ RGB HD แบบเรียลไทม์ลองใช้ opengl แทน xv เนื่องจาก xv ในระบบของฉันยอมรับเฉพาะอินพุต yuv เท่านั้น mplayer ใช้เวลา CPU เพิ่มเพื่อทำการแปลงพื้นที่สี
แหล่งที่มาสำหรับการทดสอบการเข้ารหัสต่อไปนี้: https://media.xiph.org/ https://media.xiph.org/sintel/sintel_trailer-1080-png.tar.gz พวกเขาลืม gzip ไฟล์ y4m สำหรับตัวอย่าง sintel ดังนั้น png tarball จึงมีขนาดเล็กกว่ามาก
ffmpeg -i 1080/sintel_trailer_2k_%4d.png -i sintel_trailer-audio.flac \
-c:a copy -c:v libx264rgb -preset ultrafast -qp 0 \
frompng.sintel.264rgb.mkv
เช่น
peter@tesla:/mnt/GP1TB/p/encoder-sample/sintel$ time ffmpeg -i 1080/sintel_trailer_2k_%4d.png -i sintel_trailer-audio.flac -c:a copy -c:v libx264rgb -preset ultrafast -qp 0 frompng.sintel.264rgb.mkv
ffmpeg version N-67983-g2b358b4 Copyright (c) 2000-2015 the FFmpeg developers
built on Jan 10 2015 05:32:37 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
configuration: --enable-gpl --enable-version3 --enable-nonfree --disable-doc --disable-ffserver --enable-libx264 --enable-libx265 --enable-libmp3lame --enable-libopus --enable-libwebp --enable-libvpx --disable-outdev=oss --disable-indev=oss --disable-encoder=vorbis --enable-libvorbis --enable-libfdk-aac --disable-encoder=aac --disable-decoder=jpeg2000
libavutil 54. 16.100 / 54. 16.100
libavcodec 56. 20.100 / 56. 20.100
libavformat 56. 18.100 / 56. 18.100
libavdevice 56. 3.100 / 56. 3.100
libavfilter 5. 7.100 / 5. 7.100
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
Input #0, image2, from '1080/sintel_trailer_2k_%4d.png':
Duration: 00:00:50.12, start: 0.000000, bitrate: N/A
Stream #0:0: Video: png, rgb24, 1920x1080 [SAR 72:72 DAR 16:9], 25 fps, 25 tbr, 25 tbn, 25 tbc
Input #1, flac, from 'sintel_trailer-audio.flac':
Duration: 00:00:52.00, start: 0.000000, bitrate: 721 kb/s
Stream #1:0: Audio: flac, 48000 Hz, stereo, s16
File 'frompng.sintel.264rgb.mkv' already exists. Overwrite ? [y/N] y
No pixel format specified, rgb24 for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.
[libx264rgb @ 0x2770760] using SAR=1/1
[libx264rgb @ 0x2770760] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
[libx264rgb @ 0x2770760] profile High 4:4:4 Predictive, level 4.0, 4:4:4 8-bit
[libx264rgb @ 0x2770760] 264 - core 144 r2525+2 6a4fca8 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=0 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=0 chroma_qp_offset=0 threads=3 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=0 intra_refresh=0 rc=cqp mbtree=0 qp=0
Output #0, matroska, to 'frompng.sintel.264rgb.mkv':
Metadata:
encoder : Lavf56.18.100
Stream #0:0: Video: h264 (libx264rgb) (H264 / 0x34363248), rgb24, 1920x1080 [SAR 72:72 DAR 16:9], q=-1--1, 25 fps, 1k tbn, 25 tbc
Metadata:
encoder : Lavc56.20.100 libx264rgb
Stream #0:1: Audio: flac ([172][241][0][0] / 0xF1AC), 48000 Hz, stereo (16 bit)
Stream mapping:
Stream #0:0 -> #0:0 (png (native) -> h264 (libx264rgb))
Stream #1:0 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame= 1253 fps= 18 q=-1.0 Lsize= 834790kB time=00:00:51.96 bitrate=131592.5kbits/s
video:830198kB audio:4575kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.002025%
[libx264rgb @ 0x2770760] frame I:6 Avg QP: 0.00 size:612470
[libx264rgb @ 0x2770760] frame P:1247 Avg QP: 0.00 size:678787
[libx264rgb @ 0x2770760] mb I I16..4: 100.0% 0.0% 0.0%
[libx264rgb @ 0x2770760] mb P I16..4: 50.3% 0.0% 0.0% P16..4: 12.0% 0.0% 0.0% 0.0% 0.0% skip:37.6%
[libx264rgb @ 0x2770760] coded y,u,v intra: 71.1% 68.2% 70.0% inter: 22.8% 22.8% 23.2%
[libx264rgb @ 0x2770760] i16 v,h,dc,p: 50% 48% 1% 1%
[libx264rgb @ 0x2770760] kb/s:135693.94
โปรดทราบว่าฉันลืมระบุ-r 24fps ดังนั้นมันจะไม่ซิงค์ av กับเสียง (และขนาดบิตเรต (แต่ไม่ใช่ขนาดไฟล์)) จะถูกปิดเช่นกัน ffmpeg มีค่าเริ่มต้นที่ 25fps) ซีพียูในเครื่องนี้เป็นรุ่นที่ 1 เจนเนอร์ (conroe) core2duo 2.4GHz (E6600)
ผล:
4.5M sintel_trailer-audio.flac # this is muxed in to every mkv
948M 1080 # the directory of PNGs
940M /var/tmp/dl/sintel_trailer-1080-png.tar.gz
7434M sintel.y4m # yuv444, uncompressed. mplayer gets the colors wrong?
2342M qtrle.mkv # encode went at 16fps, so qtrle is slower and worse filesize
2105M sintel.huff.mkv # ffvhuff with default options, rgb pix fmt
1228M sintel.utvideo.mkv # muxed without audio, I should update the others this way
946M png-copy.mkv # -codec copy makes a MPNG stream. Use -codec png for non-png sources, but it won't make PNGs as small. Decodes very fast
824M lossy.prores_ks.mov # yuv444p10le extremely slow to encode (2.3fps), and worse bitrate.
816M frompng.sintel.264rgb.mkv
735M sintel.x264rgb.medium.nocabac.mkv # encode went at 3.3 fps instead of 18. Better gain than for live-action, though
626M sintel_trailer.rgb.lossless.veryslow.mkv # 1.1fps. With CABAC, 16 ref frames, etc. etc.
512M lossy.prores.mov # yuv422p10le, 12fps
341M sintel.yuv420.x264.lossless.mkv
21M lossy.rgb.crf26.preset=medium.mkv
13M lossy.yuv420.crf26.preset=medium.mkv # remember this is WITH 4.5MB audio
โปรดทราบว่าmediainfoไม่ทราบเกี่ยวกับ RGB h.264 แต่ก็ยังกล่าวว่าไฟล์ดังกล่าวเป็น YUV
ตรวจสอบว่ามันเป็นแบบไม่สูญเสียจริง ๆ :
ffmpeg -i 1080/sintel_trailer_2k_%4d.png -f framemd5 png.framemd5
ffmpeg -i fromhuff.sintel.264rgb.mkv -an -sn -pix_fmt rgb24 -f framemd5 x264rgb.framemd5
diff -s *.framemd5
Files png.framemd5 and x264rgb.framemd5 are identical
ดังนั้นคุณสามารถกู้คืนอินพุต PNG ดั้งเดิมด้วยวิธีนั้นได้เช่นคุณสามารถสร้าง PNG ด้วยข้อมูลภาพเหมือนกันได้
สังเกตการ-pix_fmt rgb24ทดสอบ x264 ตัวถอดรหัส h.264 ของ ffmpeg จะเอาต์พุต gbrp (ระนาบ, ไม่ได้บรรจุ) ดังนั้นบิตจะเหมือนกัน แต่อยู่ในลำดับที่ต่างกัน framemd5 "container" ไม่ได้กำหนดข้อ จำกัด การจัดรูปแบบใด ๆ แต่คุณจะได้รับ md5 เท่ากันถ้าบิตมีการจัดเรียงแบบเดียวกัน ฉันแค่ดูสิ่งที่ ffmpeg บอกว่ามันใช้สำหรับ pix fmt เมื่อฉันป้อน PNGs จากนั้นใช้สิ่งนั้นเป็นอาร์กิวเมนต์-pix_fmtสำหรับการถอดรหัส อนึ่งนี่คือเหตุผลที่ vlc จะไม่เล่นไฟล์ RGB h.264 (จนกว่าจะมีการเปิดตัวครั้งต่อไปหรือสร้างขึ้นทุกค่ำคืน): ไม่รองรับรูปแบบพิกเซล gbrp
สำหรับการใช้งาน YUV ไม่libx264 libx264rgbคุณไม่จำเป็นต้องติดตั้งรุ่น RGB ของ x264 ห้องสมุดจริงรองรับทั้งสองอย่าง มันเป็นเพียง ffmpeg ที่ใช้มันเป็นเครื่องเข้ารหัสสองชื่อที่แตกต่างกัน ฉันคิดว่าถ้าพวกเขาไม่ได้ทำสิ่งนั้นพฤติกรรมเริ่มต้นก็คือปล่อยอินพุต rgb เป็น rgb และทำงานช้ามากในขณะที่ให้ผลผลิตบิตเรตที่สูงกว่ามากสำหรับคุณภาพเดียวกัน (บางครั้งคุณยังต้องใช้-pix_fmt yuv420pถ้าคุณต้องการ420แทนการ444ส่งออก h.264
นอกจากว่าคุณกำลังสร้างไฟล์สำหรับการจัดเก็บระยะยาวให้ใช้-preset ultrafastสำหรับ lossless x264 เสมอ เฟรมอ้างอิงเพิ่มเติมและการค้นหาการเคลื่อนไหวแทบจะไม่สร้างความแตกต่างใด ๆ สำหรับการสูญเสียสำหรับวัสดุที่ไม่มีภาพเคลื่อนไหวพร้อมเสียงรบกวน CABAC ใช้ CPU จำนวนมากที่บิตเรตแบบไม่สูญเสียแม้กระทั่งการถอดรหัส ใช้เพื่อวัตถุประสงค์ในการเก็บถาวรเท่านั้นไม่ทำให้ไฟล์เป็นรอย (ปิดใช้งาน CABAC เร็วมาก) CABAC ให้การประหยัดบิตเรต 10 ถึง 15%
-keyint 1หากคุณต้องการทุกกรอบจะเป็นคีย์เฟรมชุด จากนั้นซอฟต์แวร์ตัดต่อวิดีโอที่ต้องการตัดเฉพาะคีย์เฟรมหรือ w / e จะไม่ จำกัด คุณ
ในการตอบคำถามเดิม: นี่คือสิ่งที่คุณควรทำเมื่อทิ้งไฟล์ชั่วคราวขณะลองทำสิ่งต่าง ๆ เป็นระยะ ๆ (เช่น deinterlace ช้าการบันทึกเอาต์พุตแบบไม่สูญเสียก่อนที่จะลองสิ่งอื่น):
ffmpeg -i dv-video-source.ts -vf yadif=2:1,mcdeint=3:1:10 -c:a copy -c:v libx264 -preset ultrafast -qp 0 deinterlaced.mkv
หากคุณต้องการเอาท์พุทของคุณในไฟล์ภาพที่คุณสามารถแก้ไขด้วยเครื่องมือภาพนิ่งคุณต้องถอดรหัสเป็น png คุณจะไม่สูญเสียอะไรมากไปกว่าความสำคัญน้อยที่สุดของ 8 บิตสำหรับแต่ละค่า Y, Cb และ Cr สำหรับแต่ละพิกเซล
x264 -preset ultrafastออกมาได้ดีจริงๆในเรื่องนี้เพราะมีจำนวนมากของเฟรมสีดำกับบิตของข้อความในการจางหายและจางหายออกและสมบูรณ์แบบคล้ายคลึงกันระหว่างพื้นที่ขนาดใหญ่ของเฟรมจำนวนมากซึ่งจะจัดการการใช้ประโยชน์จากแม้จะมี ในไลฟ์แอ็กชันฉันยังเห็น x264 ครึ่งหนึ่งของขนาดไฟล์ของ ffvhuff (yuv420)
สำหรับทุกคนที่สงสัย: การเข้ารหัส rgb lossless เวลาสูงมี (x264 core 144 r2525):
[libx264rgb @ 0x35b97a0] frame I:27 Avg QP: 0.00 size:604367
[libx264rgb @ 0x35b97a0] frame P:1226 Avg QP: 0.00 size:517512
[libx264rgb @ 0x35b97a0] mb I I16..4..PCM: 46.3% 38.1% 15.7% 0.0%
[libx264rgb @ 0x35b97a0] mb P I16..4..PCM: 24.3% 5.4% 4.5% 0.0% P16..4: 10.5% 3.3% 5.7% 0.0% 0.0% skip:46.3%
[libx264rgb @ 0x35b97a0] 8x8 transform intra:17.3% inter:46.1%
[libx264rgb @ 0x35b97a0] coded y,u,v intra: 81.6% 77.5% 80.0% inter: 28.0% 27.7% 28.1%
[libx264rgb @ 0x35b97a0] i16 v,h,dc,p: 35% 64% 1% 0%
[libx264rgb @ 0x35b97a0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 49% 13% 2% 1% 1% 1% 1% 1%
[libx264rgb @ 0x35b97a0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 37% 5% 5% 6% 5% 5% 4% 3%
[libx264rgb @ 0x35b97a0] Weighted P-Frames: Y:41.1% UV:40.7%
[libx264rgb @ 0x35b97a0] ref P L0: 74.5% 4.2% 9.1% 4.1% 2.1% 1.7% 1.2% 0.8% 0.6% 0.5% 0.3% 0.2% 0.2% 0.2% 0.2% 0.1%
[libx264rgb @ 0x35b97a0] kb/s:99721.66
สังเกตสัดส่วน p น้ำหนักที่สูงมาก ๆ และส่วนที่สูงของข้าม macroblocks การเปลี่ยนฉากทุกครั้งจะจางหายไปไม่ใช่การตัดและ x264 จะได้เปรียบถ้าคุณให้เวลากับซีพียูเพื่อหาวิธี
สำหรับการขัดเกลาไปข้างหน้า / ข้างหลังผ่านคลิปมักใช้ตัวแปลงสัญญาณภายในเท่านั้น (utvideo, ffvhuff, mjpeg, jpeg2000, pro-res, AVC-Intra) ฉันคิดว่า AVC ปกติกับ GOPs สั้น ๆ (1/2 ถึง 1 วินาที) จะค่อนข้างดีเช่นกันตราบใดที่ซอฟต์แวร์รู้ว่ามันกำลังทำอะไรอยู่ (ถอดรหัสที่ใกล้ที่สุดฉันใส่เฟรมเมื่อขัดอย่างรวดเร็วถอดรหัสภายใน GOP เพื่อไปที่ กรอบระหว่างถ้าคุณซูมเข้าไปในเส้นเวลามากพอที่จะต้องใช้)
ฉันได้โพสต์สิ่งที่เป็นลบเกี่ยวกับเรื่องนี้และhttps://video.stackexchange.com/เกี่ยวกับการลดความละเอียดเช่น "อะไรคือจุดที่ว่าถ้าการบีบอัดช้าลงและแย่ลงกว่าตัวแปลงสัญญาณแบบไม่สูญเสีย" แต่มีคุณสมบัติที่น่าสนใจ Apple บอกว่ามันสามารถถอดรหัสที่ความละเอียดครึ่งหนึ่งโดยใช้เวลาเพียง 1/3 ของเวลา CPU ในการถอดรหัส full rez
การใช้ prores ของ ffmpeg อาจไม่ได้รับการปรับให้เหมาะสมกับความเร็วเช่นเดียวกับของ Apple ซึ่งเป็นสาเหตุที่การทดสอบของฉันกับ ffmpeg ทำให้มันดูช้า อาจไม่คุ้มค่าหากคุณมีเวิร์กโฟลว์ซอฟต์แวร์ฟรีพร้อมเครื่องมือที่ใช้ ffmpeg แต่อาจคุ้มค่าที่จะลองใช้หากคุณใช้ซอฟต์แวร์เชิงพาณิชย์
ฉันไม่ทำการตัดต่อวิดีโอจำนวนมากส่วนใหญ่เป็นเพียงการเข้ารหัสดังนั้นฉันจึงไม่มีความรู้สึกที่ดีว่าการทดสอบใดที่เหมาะสมสำหรับตัวแปลงสัญญาณเช่นการแสดงผล ฉันเดาว่า mjpeg อาจจะเป็นทางเลือกที่รวดเร็วถ้า GOP สั้น x264 ทำงานได้ไม่ดี มีการใช้งาน jpeg ใน asm-accelerated ของ Linux distros และมันก็เป็น codec ธรรมดา ๆ คุณสามารถเปลี่ยนคุณภาพขึ้นหรือลงได้ตามต้องการเพื่อแลกกับคุณภาพเทียบกับขนาดไฟล์ + ความเร็วในการเข้ารหัส / ถอดรหัส มันเป็นของโบราณ แต่ถ้าคุณต้องการตัวแปลงสัญญาณภายในเท่านั้นที่เร็วจริงๆมันอาจชนะ x264
สำหรับ x264 ฉันจะลองแบบx264 --crf 10 --keyint=1 --preset superfast --tune fastdecode (ภายในอย่างเดียวโดยไม่มีสิ่งอื่นใดที่--avcintra-classกำหนดไว้) หมายเหตุsuperfast(ไม่มี CABAC) หรืออาจfasterไม่ultrafastดีที่สุดสำหรับการสูญเสียการดำเนินการ ฉันคิดว่า Ultrafast สูญเสียคุณภาพจำนวนมากโดยไม่ต้องเร็วขนาดนั้น คุณภาพที่ต่ำกว่า (crf สูงกว่า) ที่คุณใช้ยิ่งคุ้มค่ากับการใช้เวลาของ CPU มากขึ้นในการค้นหาการเข้ารหัสที่ดีขึ้น สิ่งนี้อาจไม่เกี่ยวข้องกับขนาด GOP = 1
ด้วยขนาด GOP> 1 หากคุณขว้างบิตจำนวนมากที่การเข้ารหัสที่ดีกว่าการทำนายระหว่างกันจะไม่บันทึกหลายบิตเมื่อเข้ารหัสส่วนที่เหลือ แค่เร็วสุด ๆ คงไม่เป็นไร ไม่อย่างนั้นก็ด้วย--keyint=30หรือบางอย่างอาจ--preset veryfast --crf 12จะน่าสนใจ
ในทางทฤษฎีคุณภาพของการตั้งค่า CRF ที่กำหนดควรเป็นค่าคงที่ข้ามค่าที่ตั้งไว้ล่วงหน้า หากคุณกำลังมองหาไฟล์ที่มีขนาดเล็กลง (ถอดรหัสได้เร็วขึ้น) การแลกเปลี่ยนคุณภาพและเวลาในการเข้ารหัสจะสมเหตุสมผล
ฉันคิดว่า ffmpeg รองรับการแปลงเป็นวิดีโอที่ไม่มีการบีบอัด
ฉันใช้ ffmpeg -i input.mp4 -vcodec rawvideo out.avi และผลลัพธ์. avi นั้นเป็นขนาดไฟล์ที่ถูกต้อง เครื่องเล่นสื่อ Windows ดูเหมือนจะไม่สามารถเล่นได้อย่างถูกต้อง แต่สามารถอ่านได้โดย VirtualDub และฉันไม่เห็นการสูญเสียคุณภาพของภาพ
ffmpeg -i input.avi -c:v qtrle -pix_fmt rgb24 output.movสำหรับการอ้างอิงมันเป็น