รูปแบบวิดีโอ lossless สากล


14

ฉันพยายามค้นหารูปแบบวิดีโอlosslessที่เหมาะสมที่สุดสำหรับวิดีโอ 1280x720 25fps วิดีโอมีความยาว 4 นาที เสียงจะเป็น 320 kbps mp3 ซึ่งไม่ใช่เรื่องใหญ่ เงื่อนไขในอุดมคติ:

  • Lossless (สามารถรับรู้แบบไม่สูญเสีย)
  • Container + codec สามารถเล่นได้บนแพลตฟอร์มส่วนใหญ่
  • Container + codec สามารถเล่นกับเครื่องเล่น DVD รุ่นใหม่ (รองรับรูปแบบอื่นที่ไม่ใช่ DVD)
  • ขนาดน้อยกว่า 700 MB

เป็นไปได้ไหม ได้รับการดิ้นรนสามวันแล้วโดยไม่มีผลลัพธ์ที่น่าพอใจแม้จะได้รับไฟล์ 12 GB (ดูเหมือนมาก - 3 GB / นาที)


1
สำหรับการเปรียบเทียบดูen.wikipedia.org/wiki/List_of_codecs#Lossless_compression
artistoex

4
ฉันขอโทษ แต่คุณจริงแล้วไม่สามารถรับวิดีโอ 720p lossless ที่มองเห็นได้จาก 4 นาทีที่บีบอัดให้น้อยกว่า 700 MB (ฉันถือว่า Megabyte ที่นี่ไม่ใช่ "mb" ซึ่งหมายถึง "บิต") ทำไมคุณถึงมีข้อ จำกัด เช่นนี้? วิดีโอไม่สามารถเข้ารหัส h.264 ได้หรือไม่
slhck

ใช่ MB เสียใจด้วยความสับสน ฉันต้องใส่ cca 5 วิดีโอ x 4 นาทีเป็น 4 GB (ข้อ จำกัด ปานกลาง)
mrkva

2
เนื่องจากคุณได้รับไฟล์ 12GiB ฉันถือว่าคุณใช้ความลึกของสี 24Bit สตรีมข้อมูลวิดีโอที่ไม่มีการบีบอัดประมาณ 4GiB ต่อนาที นั่นเป็นข้อมูลจำนวนมหาศาล สิ่งที่คุณต้องการคือประมาณ 170MiB ต่อนาที ไม่ว่าคุณจะเลือกตัวแปลงสัญญาณใดคุณก็สามารถทำสิ่งนี้ได้ด้วยฉากคงที่โดยไม่มีการเคลื่อนไหว ฉันเกรงว่าคุณจะต้องผ่อนคลายความกังวลที่จะสูญเสียลดอัตราเฟรมหรือทนต่อไฟล์ขนาดใหญ่
Marco

คุณสามารถอธิบายได้ไหมว่า "Container + codec สามารถเล่นกับเครื่องเล่น DVD รุ่นใหม่ (รองรับรูปแบบอื่นที่ไม่ใช่ DVD)"
llogan

คำตอบ:


24

รูปแบบที่ดีที่สุดที่เกิดขึ้นจริงและไม่สูญเสียทางคณิตศาสตร์ที่ฉันรู้จักคือ huffyuv แต่นั่นจะสร้างไฟล์ขนาดใหญ่อย่างสนุกสนานและจะไม่เข้ากันได้มากนัก สำหรับเร็กคอร์ด ffmpeg สามารถทำได้ด้วย:

ffmpeg -i input -c:v huffyuv -c:a libmp3lame -b:a 320k output.avi

X264 โปรแกรมเข้ารหัส h.264 แบบโอเพ่นซอร์สมีโหมดแบบไม่สูญเสีย สิ่งนี้สามารถเข้าไปในคอนเทนเนอร์ MP4 ได้และควรเข้ากันได้กับฮาร์ดแวร์ส่วนใหญ่ที่ผลิตในช่วงไม่กี่ปีที่ผ่านมา คำสั่งแรกจะให้ความเร็วการเข้ารหัสที่รวดเร็ว แต่ไฟล์ขนาดใหญ่ คำสั่งที่สองจะใช้เวลานานกว่านี้มาก แต่ไฟล์ควรมีขนาดประมาณครึ่งหนึ่งของการเข้ารหัสที่รวดเร็ว (มันจะยังคงค่อนข้างใหญ่):

ffmpeg -i input -c:v libx264 -crf 0 -preset ultrafast -c:a libmp3lame -b:a 320k output.mp4

ffmpeg -i input -c:v libx264 -crf 0 -preset veryslow -c:a libmp3lame -b:a 320k output.mp4

หากไม่ได้ให้ไฟล์ขนาดเล็กพอให้คุณ crf เท่ากับ 18 โดยทั่วไปถือว่าเป็น 'สูญเสียการมองเห็น':

ffmpeg -i input -c:v libx264 -crf 18 -preset veryfast -c:a libmp3lame -b:a 320k output.mp4

โดยทั่วไปฉันแนะนำให้ตั้งค่าล่วงหน้าที่เร็วมากสำหรับการเข้ารหัสด้วย x264 จากประสบการณ์ของฉันมันให้การแลกเปลี่ยนความเร็ว / ขนาดที่ดีที่สุด คำแนะนำทั่วไปคือการใช้ค่าที่ตั้งล่วงหน้าที่ช้าที่สุดที่คุณสามารถจัดการได้ค่าที่ตั้งล่วงหน้าคือ: เร็วมากเร็วสุดเร็วมากเร็วเร็วปานกลางช้าช้าช้ามาก

ดูที่นี่สำหรับคำแนะนำเพิ่มเติมในเชิงลึกเกี่ยวกับการเข้ารหัส x264


2
ไม่แนะนำveryfastเป็นค่าเริ่มต้นที่ดีสำหรับการสูญเสีย x264 mediumเป็นดินกลางที่ดี แต่ฉันมักจะใช้veryslowสำหรับการเข้ารหัสสุดท้ายของอะไร ยังhuffyuvไม่เร็วมากฉันจะไม่แนะนำสิ่งอื่นนอกจากความเข้ากันได้
Peter Cordes

ffmpeg มีตัวแปลงสัญญาณแบบไม่สูญเสียอื่น ๆ อีกสองสามตัวที่อาจคุ้มค่าที่จะลอง [FFv1 คำนึงถึง] เช่นกัน GL!
rogerdpack

อย่าลด libx264 ลงตัวอย่างช่องสองสี (ใน YUV the UV) ครึ่งละครึ่งในทิศทางใดทิศทางหนึ่งแม้ว่าคุณจะใช้ CRF เท่ากับ 0 ดังนั้นมันจึงไม่สูญเสียอย่างแท้จริง นอกจากนี้เมื่อมีข้อผิดพลาดในการปัดเศษข้อมูลจะไม่รับประกันว่าจะได้รับการเยื้องเล็กน้อยสำหรับบิตหลังจากการบีบอัด x264 รอบ
Adisak

1
ในการทดลองของฉันกับ ffmpeg 3.4.1, libx264 ใช้รูปแบบ yuv444 พิกเซลโดยที่ "444" หมายถึง "อย่าดาวน์โหลตัวอย่าง U, V" และ OP อย่างชัดเจนไม่สนใจข้อผิดพลาดในการปัดเศษ: "สามารถรับรู้การสูญเสีย" ดังนั้น @Adisak ความกังวลของคุณนั้นสมเหตุสมผล แต่ไม่สามารถใช้ได้กับคำตอบนี้
Jim DeLaHunt

ffmpeg และ libx264 ในโหมด YUV จะเจรจารูปแบบพิกเซล YUV ตามอินพุต ดังนั้นหากอินพุตคือ YUV 4: 2: 0 ดังนั้นรูปแบบพิกเซลเอาต์พุต หากอินพุตคือ YUV 4: 4: 4 หรือ RGB แสดงว่า YUV 4: 4: 4
Gyan

2

วันนี้ฉันชอบwebm :

ffmpeg -i input.avi -c:v libvpx-vp9 -lossless 1 output.webm

ในการแปลงที่เร็วขึ้นด้วยตัวประมวลผลแบบมัลติคอร์ฉันได้อ่านแนะนำให้ใช้เธรดที่น้อยกว่าหนึ่งคอร์ของคุณ ดังนั้นด้วย 8 คอร์คุณสามารถระบุ 7 เธรดดังนี้:

ffmpeg -i input.avi -c:v libvpx-vp9 -threads 7 -lossless 1 output.webm

1
ฉันต้องการใช้ตัวแปรสภาพแวดล้อม% NUMBER_OF_PROCESSORS% เพื่อกำหนดจำนวนเธรดที่จะใช้ ถ้านับเป็น 1 หรือ 2 ฉันใช้โปรเซสเซอร์ทั้งหมด หากการนับเป็น 3 หรือ 4 ฉันจะใช้ทั้งหมดยกเว้นโปรเซสเซอร์เดียว และถ้านับสูงกว่าฉันใช้ตัวประมวลผลทั้งหมดยกเว้นสองตัวสำหรับการนับจำนวนเธรด
Adisak

1
ในฐานะที่เป็นนิพจน์ DOS ดูเหมือนว่าสิ่งนี้: หาก "% ADJUSTED_CPUCOUNT%" EQU "" (ถ้า% NUMBER_OF_PROCESSORS% EQU 1% (ตั้งค่า ADJUSTED_CPUCOUNT = 1) หากตั้งไว้อีก% NUMBER_OF_PROCESSORS% EQU 2 EQU 3 (ตั้งค่า ADJUSTED_CPUCOUNT = 2) หาก% NUMBER_OF_PROCESSORS% EQU 4 (ตั้งค่า ADJUSTED_CPUCOUNT = 3) อื่น ๆ (ตั้งค่า / A ADJUSTED_CPUCOUNT =% NUMBER_OF_PROCESSORS% -2)
Adisak

1
superuser.com/questions/155305/…บอกว่า ffmpeg เลือกจำนวนเธรดที่เหมาะสมแล้ว
Boris

ทางเลือกที่ดีกว่า webm (สมัยนี้) อาจเป็นรูปแบบav1
LonnieBest

-1
# คอนเทนเนอร์

เพื่อให้สามารถใช้งานร่วมกับเครื่องเล่น DVD ได้อย่างสมบูรณ์คุณจะต้องใช้รูปแบบ MPEG-2, คอนเทนเนอร์, ข้อ จำกัด , ตัวแปลงสัญญาณ ฉันเดาว่า "เครื่องเล่นสมัยใหม่" หมายถึงความเข้ากันได้ "mp4" ซึ่งโดยทั่วไปแล้วและส่วนใหญ่เป็นเครื่องเล่น mp4 ไฟล์ - H.264, MPEG-4, AVC => libx264
อ่านเพิ่มเติมได้ที่: https://de.wikipedia.org/wiki /H.264

# วิดีโอ

ดูที่https://trac.ffmpeg.org/wiki/Encode/H.264โดยเฉพาะส่วนที่เกี่ยวกับ "โปรไฟล์" และ "ระดับ" เพื่อความเข้ากันได้
การใช้-profile:v high -level 4.0ควรทำ

# AUDIO

หลีกเลี่ยงการเข้ารหัสแทร็กเสียงด้วยตัวแปลงสัญญาณที่สูญหาย - รูปแบบ MP3 ใด ๆ ที่สูญหายแม้กระทั่ง 320kbps
ใช้-c:a copyแทน

จนถึงตอนนี้มันทำงานได้ค่อนข้างดีสำหรับฉัน ไม่มีปัญหาการซิงค์
กระแสเสียงไม่ได้ถูกผูกไว้กับคีย์เฟรม สามารถตัดได้แม่นยำ
หากแทร็กเสียงของคุณถูกบันทึกที่อัตราการสุ่มตัวอย่าง 44kHz ให้ใช้สูงสุด 256kbps

ใช้ตัวแปลงสัญญาณที่เสียสำหรับการเข้ารหัสขั้นสุดท้ายของวิดีโอของคุณเท่านั้นหากคุณจำเป็นต้องติดตั้งข้อกำหนดเบื้องต้นบางอย่าง

ฉันเคยได้ยินปัญหาเกี่ยวกับการซิงค์ด้วยเสียง แต่ดูเหมือนว่าเป็นปัญหาหลักที่มีอยู่มันเป็นวัสดุที่มีการป้องกัน (!)

# ในที่สุด

ฉันชอบสิ่งนี้:
ffmpeg -i input -c:v libx264 -crf 5 -preset faster -profile:v high -level 4.0 -c:a copy output.mp4


ตัวเลือก "- ระดับ 4.0" ไม่จำเป็น ระดับใน x264 ขึ้นอยู่กับความละเอียดและ FPS ดังนั้นโดยปกติจะไม่มีจุดตั้งค่าด้วยตนเองสิ่งนี้จะไม่ปรับปรุงอะไรเลย เท่าที่ฉันทราบ ffmpeg สามารถตั้งค่าระดับที่ถูกต้องโดยอัตโนมัติดังนั้นถ้าคุณไม่มีเหตุผลที่ดีที่จะบังคับและเข้าใจวิธีเลือกระดับตาม FPS และความละเอียดอย่างสมบูรณ์คุณไม่ควรใช้ตัวเลือก "ระดับ" หากคุณสนใจความเข้ากันได้สูงสุดให้ใช้โปรไฟล์ "พื้นฐาน" แทน "สูง"
Lissanro Rayen
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.