การบีบอัดวิดีโอสร้างไฟล์ที่ใหญ่ขึ้น

17

ฉันใช้ GUI (คลิกขวา => การบีบอัด) เพื่อลองและบีบอัด. tar ที่มีวิดีโอ 3 รายการรวม 1.7 กิกะไบต์ (.H264 MP4s) gzip, lrzip, 7z เป็นต้นทุกอย่างไม่ทำอะไรกับขนาดไฟล์และโฟลเดอร์ที่บีบอัดก็มีขนาด 1.7 gb

ฉันลองใช้ lrzip จากบรรทัดคำสั่ง (ในกรณีที่มันเป็นปัญหา gui) และใช้แฟล็ก -z (การบีบอัดมาก) และนี่คือผลลัพธ์ของฉัน

ป้อนคำอธิบายรูปภาพที่นี่

ตามที่อัตราส่วนการบีบอัดแสดงให้เห็นขนาดจริงของโฟลเดอร์ที่บีบอัดนั้นใหญ่กว่าขนาดดั้งเดิม! ฉันไม่รู้ว่าทำไมฉันจึงไม่มีโชค lrzip ควรมีประสิทธิภาพตามรีวิวแบบสุ่มที่ฉันอ่านและเอกสารทางการ (ไฟล์ที่มีขนาดใหญ่กว่า 100mb ยิ่งใหญ่ยิ่งดี) - ดูhttps: //wiki.archlinux org / index.php / Lrzip

เหตุใดฉันจึงบีบอัดไฟล์ไม่ได้

gzip

— ที่กำบัง
แหล่งที่มา

2

โดยส่วนตัวแล้วฉันจะไม่รบกวนการเก็บวิดีโอ mp4 เนื่องจากตัวแปลงสัญญาณวิดีโอเหล่านั้นถูกบีบอัดไว้แล้ว

— เรือท้องแบน

และคุณจะประสบความสำเร็จขนาดน้อยลงโดยใช้วิดีโอเครื่องมือแปลง / คอมเพรสเซอร์เช่นFFMpeg

— เจ็ท

เรือท้องแบนและ Jet ถูกต้อง นี่เป็นพฤติกรรมที่คาดหวัง มันตอบโต้การพยายามบีบอัดบางสิ่งที่ถูกบีบอัดไว้แล้ว หากคุณใช้เครื่องมือแปลงวิดีโอคุณอาจประหยัดพื้นที่ได้ด้วยคุณภาพของวิดีโอ (ชัดเจนหรือไม่) อย่างไรก็ตามเริ่มต้นด้วยสำเนาสูงสุดที่มีการบีบอัดน้อยที่สุดที่คุณมี

— John S Gruber

25

ดังที่ @pram กล่าวไว้ข้างต้นในความคิดเห็นวิดีโอ mp4 ถูกบีบอัดไว้แล้วและรูปแบบวิดีโออื่น ๆ อาจใช้การบีบอัดในระดับหนึ่ง ดังนั้นการพยายามบีบอัดจะไม่ทำให้ขนาดเล็กลง (ถ้ามี) ลดขนาดลง (อย่างน้อยก็ในส่วนนี้กับรูปภาพและเพลง) ในกรณีนี้ดูเหมือนว่าข้อมูลเมตา (สำหรับไฟล์บีบอัดเอง) อาจทำให้เพิ่มขึ้น รูปแบบการบีบอัดเท่านั้นที่อาจ (และที่อาจแข็งแกร่ง) ส่งผลให้การลดลงคือ xz

ในบันทึกอื่น ๆ หากคุณต้องการลดขนาดของวิดีโอเหล่านั้นให้ดูการเข้ารหัสวิดีโออีกครั้งโดยใช้ Handbrake แทน

— saiarcot895
แหล่งที่มา

3

ฉันพบว่า webm มีอัตราการบีบอัดข้อมูลที่ดีโดยทั่วไป เล็กกว่า mp4 มาก

— เซท

@Seth จริง MP4 (ซึ่งเป็น AVC หรือ h.264 หรือใหม่กว่าและดีกว่า h.265 aka codec HEVC) ให้ไฟล์ขนาดเล็กที่คุณภาพเดียวกัน (หรือคุณภาพที่ดีกว่าที่ขนาดไฟล์เดียวกัน)

— David Balažic

@ DavidBalažicเรากำลังเปรียบเทียบแอปเปิ้ลกับแอปเปิ้ลที่นี่เมื่อเราพยายามพูดคุยเกี่ยวกับส้ม mp4 และ webm เป็นทั้งตู้คอนเทนเนอร์พวกเขาไม่มีส่วนเกี่ยวข้องกับการบีบอัดข้อมูล คุณพูดถูกว่า h.264 และ h.265 เป็นตัวแปลงสัญญาณที่ใช้กันทั่วไปในคอนเทนเนอร์ mp4 แต่คุณไม่สามารถเปรียบเทียบ h.265 กับwebmได้ h.264 นั้นเปรียบได้กับตัวแปลงสัญญาณ vp8 ที่ใช้กันทั่วไปในภาชนะบรรจุ webm เช่นเดียวกับ h.265 เปรียบได้กับตัวแปลงสัญญาณ vp9 ซึ่งโดยทั่วไปแล้วยังมีอยู่ใน webm tl; dr: ใช้ h.265 ใน mp4 และ vp9 ใน webm และคุณจะได้คุณภาพ / ประสิทธิภาพที่เหมือนกัน

— forresthopkinsa

13

จริงๆแล้วความจริงที่ว่าไฟล์ที่ถูกบีบอัดแล้วนั้นไม่ใช่ปัญหาสำคัญ มันนี้: การบีบอัดในสามารถทำงานทั่วไปเท่านั้นหากข้อมูลที่มีชนิดของความซ้ำซ้อนบางอย่างในนั้น นั่นเป็นจริงเสมอไปสำหรับไฟล์บีบอัด - แต่ก็ไม่จำเป็นต้องเห็นได้ชัดว่าสิ่งที่ซ้ำซ้อนคือ อัลกอริธึมการบีบอัดวัตถุประสงค์ทั่วไปส่วนใหญ่กำหนดเป้าหมายเป็นประเภทของสิ่งที่ชัดเจนในไฟล์ข้อความ: หลาย ๆ คำปรากฏขึ้นไม่เพียงครั้งเดียว แต่มีเวลามากมายในรูปแบบเดียวกันบางทีวลีของคำสามารถรวมกัน ฯลฯ เป็นต้นอัลกอริทึมค่อนข้างดี การสรุปสิ่งนี้ให้กับทุกสิ่งตั้งแต่รายการหมายเลขโทรศัพท์ที่เข้ารหัส ASCII เหนือบทกวีจีนไปจนถึงรหัสเครื่องไบนารี แต่พวกเขาไม่สามารถทำงานกับข้อมูลประเภทใดก็ได้ โดยเฉพาะไฟล์มีเดียเป็นแนวคิดข้อมูลอะนาล็อกในรูปแบบดิจิตอลที่มีเสียงรบกวน นั่นหมายความว่าจริงๆแล้วไม่มี textfile-reduncancy ใด ๆ เลย: แรงจูงใจบางอย่างอาจเกิดขึ้นซ้ำ ๆ แต่มักจะมีการกำหนดค่าที่แตกต่างกันเล็กน้อยของสัญญาณรบกวนเซ็นเซอร์ นั่นเป็นเหตุผลว่าทำไมรูปแบบภาพ / AV ที่ถูกบีบอัดทั้งหมดใช้การแปลงที่เลือกอย่างชาญฉลาดเป็นขั้นตอนการเข้ารหัสครั้งแรกของพวกเขาซึ่งโดยปกติจะขึ้นอยู่กับDCTหรือเวฟเล็ต การแปลงเสียงเหล่านี้พูดอย่างหยาบ ๆ ย้ายส่วนภาพและเสียงรบกวนไปยังตำแหน่งต่างๆดังนั้นพวกเขาจึงสามารถแยกและบีบอัดแบบสูญเสียคุณเก็บข้อมูลที่คุณคิดว่าเป็น "สำคัญ" ซึ่งไม่รวมเสียงในขณะที่ " ข้อมูลที่ดี "มีความซ้ำซ้อนมากมาย (นั่นไม่ใช่วิธีการทำงานจริง ๆ แต่เป็นประเภท)

หากคอมเพรสเซอร์ที่ใช้งานทั่วไปใช้การแปลงเหล่านี้ผลที่ได้จะตรงกันข้าม: ข้อมูลดิจิทัลส่วนใหญ่จะถูกจัดเป็นเสียงรบกวนบางชนิดเนื่องจากไม่มีโครงสร้าง "ราบรื่น" ที่คุณพบในสัญญาณอะนาล็อก และหลังจากการบีบอัดวิดีโอที่สูญเสียอย่างเห็นได้ชัดทั้งอะนาล็อกความเรียบเนียนหรือการเกิดซ้ำแบบดิจิทัลสามารถพบได้อีกต่อไป (ถ้าเป็นตัวแปลงสัญญาณจะใช้ bzip-stage อื่นหรืออะไรบางอย่าง!)

— leftaroundabout
แหล่งที่มา

12

เหตุผลที่คุณไม่มีโชคคือ mp4 ถูกบีบอัดไว้แล้วคุณไม่สามารถบีบอัดได้อีก สิ่งที่คุณทำคือการเพิ่มข้อมูลส่วนหัวของรูปแบบการบีบอัดลงในไฟล์

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

— terdon
แหล่งที่มา

5

นี่คือตัวอย่างที่ดีของหลักรังนกพิราบ

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

— ลิวี
แหล่งที่มา

4

ฉันขอโทษ แต่นี่เป็นความผิดพลาดของหลักการดังกล่าว คุณสามารถใช้ตรรกะเดียวกันกับไฟล์ 1.7GB ที่มีค่าเป็นศูนย์และรับคำตอบที่ไม่ถูกต้อง หลักการ pigeonhole ถูกใช้โดยทั่วไปเพื่อพิสูจน์การมีอยู่ของไฟล์ที่ไม่บีบอัดไม่ได้เพื่อพิสูจน์ว่าไฟล์ใด ๆ ที่ไม่สามารถบีบอัดได้ (หลังไม่สามารถคำนวณได้เนื่องจากฟังก์ชันความซับซ้อนของ Kolmogorov ไม่ใช่ฟังก์ชันที่คำนวณได้)

— nneonneo

1

@nneonneo จากนั้นรู้สึกอิสระที่จะแก้ไขบทความ Wikipedia ที่เชื่อมโยง การมีอยู่ของไฟล์ที่บีบอัดไม่ได้นั้นจะตามมาโดยตรงจากนั้นจากนั้นคุณเพิ่มลงในเมตาดาต้าการบีบอัดและทันใดนั้นคุณก็มีไฟล์ที่ใหญ่กว่าเดิม ซึ่งเป็นสิ่งที่ฉันพูด หลักฐานที่แสดงว่าไฟล์นั้นไม่สามารถบีบอัดได้เพิ่มเติมภายใต้การนำไปใช้งานของอัลกอริทึมที่กำหนดคือเอาต์พุตไม่ได้เล็กลง แน่นอนเป็นไปได้ว่า meta-data นั้นใหญ่กว่าการบีบอัดที่ชนะ แต่ฉันไม่แน่ใจว่าฉันอธิบายว่ามันถูกบีบอัดในแง่ของผู้ใช้

— Livius

@Livius บทความวิกิพีเดียถูกต้อง: จะใช้หลักรังนกพิราบเพื่อพิสูจน์การดำรงอยู่ของไฟล์ uncompressable สำหรับขั้นตอนวิธีการบีบอัด lossless ใดก็ตาม แต่คุณไม่สามารถได้มาซึ่งความสามารถในการบีบอัดไฟล์ใด ๆ โดยเฉพาะจากหลักการของ pigeonhole

— David Richerby

@DavidRicherby ใช่ แต่ความจริงที่ว่าไฟล์ไม่ได้ถูกบีบอัดโดยการใช้งานที่กำหนดของอัลกอริทึมที่กำหนดเป็นหลักฐานว่ามันไม่สามารถบีบอัดได้ เว้นแต่จะมีเหตุผลอื่นสำหรับการมีอยู่ของไฟล์ที่บีบอัดไม่ได้ดังนั้นจึงเป็นไปตามที่ความล้มเหลวในการบีบอัดเกิดจาก PP เหตุผลที่เป็นไปได้อื่น ๆ อาจเป็นเพราะอัลกอริทึมที่กำหนดไม่เห็นวิธีที่จะลดขนาดของมันซึ่งดูเหมือนว่าจะเป็นกรณีของ "ภายใต้สมมติฐานของอัลกอริทึมไม่มีไฟล์ขนาดเล็กที่มีข้อมูลเดียวกัน; เพราะ PP "

— Livius

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

— Livius

4

หากคุณต้องการบีบอัดไฟล์เหล่านี้คุณจะต้องลดคุณภาพ

ไฟล์เหล่านี้มีรูปแบบและเนื้อหาประเภทใดและยากที่จะบอกได้ว่าไฟล์เหล่านี้มีที่ว่างให้เหลือน้อยแค่ไหน

BluRays พร้อมวิดีโอ 1080p นั้นมีแนวโน้มสูงกว่า 25GB ดังนั้นจึงไม่น่าเป็นไปได้ที่คุณจะได้อัตราส่วนคุณภาพต่อขนาดที่เหมาะสมสำหรับ H.264

คุณสามารถลองใช้ffmpegหรือavconvแปลงไฟล์

คุณสามารถเริ่มต้นด้วย ffmpeg -i input_file.mp4 -preset slower -crf 20 -c:a copy output_file.mp4

anconvคำสั่งจะทำงานในทำนองเดียวกัน

เพิ่ม-crfค่าเพื่อลดขนาดและคุณภาพของไฟล์ผมไม่แนะนำให้สูงกว่า 25
คุณสามารถเปลี่ยนการตั้งค่าล่วงหน้าเป็นslowหรือmediumเพื่อเพิ่มความเร็ว แต่ขนาดไฟล์ของคุณจะได้รับการเปรียบเทียบslowerหรือแม้กระทั่งveryslow(ถ้าคุณอดทนมาก!)
สามารถดูการตั้งค่าเพิ่มเติมได้ที่นี่: http://mewiki.project357.com/wiki/X264_Settings
ฉันขอแนะนำให้อยู่ห่างจากส่วนใหญ่เนื่องจากค่าที่ตั้งไว้ให้ค่าเริ่มต้นที่มีสติ-tuneยกเว้นข้อผิดพลาด
ลองใช้ denoiser หากเนื้อหาของคุณเป็นภาพยนตร์( -vf hqdn3d)คุณสามารถปรับปรุงคุณภาพของภาพเมื่อเทียบกับการใช้-crfค่าสูง
ลดขนาดเนื้อหาของคุณ-vf scale=-1:720สำหรับ 720p และ-vf scale=-1:480480p เพื่อปรับปรุงความเร็วการเข้ารหัสและรักษาคุณภาพ

— แดเนียลฮิลล์
แหล่งที่มา