Định dạng video phổ quát lossless

Tôi đang cố gắng tìm định dạng video lossless phù hợp nhất cho video 1280x720 25fps. Video có 4 phút. Âm thanh sẽ là mp3 320 kbps, đó không phải là vấn đề lớn. Điều kiện lý tưởng:

Lossless (có thể nhận thức được lossless)
Container + codec có thể được phát trên hầu hết các nền tảng
Container + codec có thể được phát trên các đầu DVD hiện đại (hỗ trợ các định dạng khác ngoài DVD)
Kích thước nhỏ hơn 700 MB

Điều đó thậm chí có thể? Đã ba ngày vật lộn, không có kết quả thỏa mãn, thậm chí nhận được các tệp 12 GB (có vẻ rất nhiều - 3 GB / phút).

video ffmpeg video-editing

— mrkva
nguồn

Để so sánh, xem en.wikipedia.org/wiki/List_of_codecs#Lossless_compression

— artistoex

Tôi xin lỗi nhưng thực tế bạn không thể có được một video 720p (trực quan) không mất thời lượng 4 phút được nén xuống dưới 700 MB (tôi giả sử Megabyte ở đây, không phải là "mb" có nghĩa là "bit"). Tại sao bạn có một ràng buộc như vậy? Video có thể được mã hóa h.264 không?

— slhck

vâng, MB, xin lỗi về sự nhầm lẫn. Tôi cần điều chỉnh video cca 5 x 4 phút thành 4 GB (giới hạn trung bình).

— mrkva

Vì bạn đang nhận tệp 12GiB, tôi giả sử rằng bạn sử dụng độ sâu màu 24Bit. Luồng dữ liệu video không nén là khoảng 4GiB mỗi phút. Đó là một lượng dữ liệu khổng lồ. Những gì bạn muốn là khoảng 170MiB mỗi phút. Bất kể codec nào bạn chọn, bạn chỉ có thể đạt được điều này với một cảnh tĩnh mà không cần di chuyển nhiều. Tôi e rằng bạn phải thư giãn để không bị mất dữ liệu, giảm tốc độ khung hình hoặc chịu được kích thước tệp lớn hơn.

— Marco

Bạn có thể làm rõ, "Container + codec có thể được phát trên các đầu DVD hiện đại (hỗ trợ các định dạng khác ngoài DVD)" không?

— llogan

Câu trả lời:

Định dạng thực tế, không mất dữ liệu tốt nhất mà tôi biết là huffyuv, nhưng điều đó sẽ tạo ra các tệp cực kỳ vui nhộn và sẽ không tương thích với nhiều. Đối với bản ghi, ffmpeg có thể làm điều đó với:

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

X264, bộ mã hóa h.264 mã nguồn mở, có chế độ lossless. Điều này có thể đi vào bên trong một thùng chứa MP4 và phải tương thích với hầu hết các phần cứng được sản xuất trong vài năm qua. Lệnh đầu tiên sẽ cho tốc độ mã hóa nhanh, nhưng tệp lớn; lệnh thứ hai sẽ mất nhiều thời gian hơn, nhưng tệp phải có kích thước bằng một nửa so với lệnh được mã hóa nhanh (mặc dù vậy nó vẫn sẽ khá lớn):

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

Nếu điều đó không cung cấp cho bạn một tệp đủ nhỏ, thì crf 18 thường được coi là 'không mất dữ liệu':

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

Tôi thường khuyên bạn nên cài đặt trước rất nhanh để mã hóa với x264, theo kinh nghiệm của tôi, nó cung cấp sự cân bằng tốc độ / kích thước tốt nhất (có sự sụt giảm lớn về kích thước tệp giữa siêu nhanh và rất nhanh, chậm hơn tốc độ đó và tăng dần). Lời khuyên chung là sử dụng các cài đặt trước chậm nhất mà bạn có thể xử lý, các cài đặt trước là: cực nhanh, cực nhanh, rất nhanh, nhanh, nhanh, trung bình, chậm, chậm, rất chậm.

Xem ở đây để có hướng dẫn sâu hơn về mã hóa x264.

— tệ nạn
nguồn

Đừng đề xuất veryfastnhư một mặc định tốt cho mất x264. mediumlà một nền tảng tốt, nhưng tôi thường sử dụng veryslowcho mã hóa cuối cùng của bất cứ điều gì. Cũng huffyuvkhông nhanh lắm, tôi sẽ không đề xuất nó cho bất cứ điều gì ngoài khả năng tương thích.

— Peter Cordes

ffmpeg có một vài codec không mất dữ liệu khác có thể đáng để thử [FFv1 đến với tâm trí]. GL!

— rogerdpack

Không libx264 giảm mẫu của hai kênh màu (trong YUV UV) một nửa theo cả hai hướng ngay cả khi bạn sử dụng CRF bằng 0 để nó không thực sự mất mát. Ngoài ra, với các lỗi làm tròn, dữ liệu không được đảm bảo là bit-bit-bit sau khi nén x264.

— Adisak

Trong các thử nghiệm của tôi với ffmpeg 3.4.1, libx264 đã sử dụng định dạng pixel yuv444, trong đó "444" có nghĩa là "không lấy mẫu của phần U, V". Và, OP rõ ràng không bận tâm đến các lỗi làm tròn: "có thể bị mất nhận thức". Vì vậy, @Adisak, mối quan tâm của bạn là hợp lý, nhưng không áp dụng cho câu trả lời này.

— Jim DeLaHunt

ffmpeg và libx264 ở chế độ YUV sẽ đàm phán định dạng pixel YUV dựa trên đầu vào. Vì vậy, nếu đầu vào là YUV 4: 2: 0 thì định dạng pixel đầu ra cũng vậy. Nếu đầu vào là YUV 4: 4: 4 hoặc RGB, thì đầu ra là YUV 4: 4: 4.

— Gyan

Những ngày này tôi thích webm :

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

Để chuyển đổi nhanh hơn, với bộ xử lý đa lõi, tôi đã đọc nên sử dụng một luồng ít hơn so với lõi thực của bạn. Vì vậy, với 8 lõi, bạn có thể chỉ định 7 luồng như thế này:

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

— LonnieBest
nguồn

Tôi thích sử dụng biến môi trường% NUMBER_OF_PROCESSORS% để xác định số lượng luồng sử dụng. Nếu số đếm là 1 hoặc 2, tôi đã sử dụng tất cả các bộ xử lý. Nếu số lượng là 3 hoặc 4, tôi sử dụng tất cả trừ một bộ xử lý. Và nếu số lượng cao hơn, tôi sử dụng tất cả trừ hai bộ xử lý cho số lượng luồng.

— Adisak

Là một biểu thức của DOS, nó trông giống như sau: if EQU 3 (set ADJUSTED_CPUCOUNT = 2) else if% NUMBER_OF_PROCESSORS% EQU 4 (set ADJUSTED_CPUCOUNT = 3) khác (set / A ADJUSTED_CPUCOUNT =% NUMBER_OF_PROCESSORS% -2))

— Adisak

superuser.com/questions/155305/ cảm nói rằng ffmpeg đã chọn số lượng chủ đề tối ưu

— Boris

Một lựa chọn tốt hơn webm (ngày nay) có lẽ là định dạng av1 .

— LonnieBest

-1

# THÙNG ĐỰNG HÀNG

để có khả năng tương thích hoàn toàn với đầu phát DVD, bạn sẽ cần sử dụng định dạng MPEG-2, thùng chứa, hạn chế, codec. Tôi đoán, "trình phát hiện đại" có nghĩa là khả năng tương thích "mp4", về cơ bản và chủ yếu là trình phát tệp mp4 - H.264, MPEG-4, AVC => libx264
đọc thêm: https://de.wikipedia.org/wiki /H.264

# VIDEO

Hãy xem https://trac.ffmpeg.org/wiki/Encode/H.264 , đặc biệt là phần nói về "hồ sơ" và "cấp độ", để tương thích
Sử dụng -profile:v high -level 4.0nên làm điều đó

# ÂM THANH

Tránh mã hóa lại các bản âm thanh với các codec bị mất - mọi định dạng mp3 đều bị mất, thậm chí là 320kbps.
Sử dụng -c:a copythay thế.

Cho đến nay, nó đã làm một công việc khá tốt cho tôi. không có vấn đề đồng bộ.
Luồng âm thanh không bị ràng buộc với khung hình chính. Cắt giảm chính xác là có thể.
Nếu bản nhạc âm thanh của bạn được ghi ở tốc độ lấy mẫu 44kHz, hãy sử dụng tối đa. 256kbps Chỉ

sử dụng codec mất dữ liệu cho mã hóa cuối cùng của video, nếu bạn cần phù hợp với các điều kiện tiên quyết nhất định.

Tôi đã nghe nói về một số vấn đề đồng bộ hóa âm thanh, nhưng có vẻ như vấn đề chính là, đó là tài liệu được bảo vệ (!).

# Cuối cùng

Tôi thích cái gì đó như thế này:
ffmpeg -i input -c:v libx264 -crf 5 -preset faster -profile:v high -level 4.0 -c:a copy output.mp4

— doo
nguồn

Tùy chọn "-level 4.0" là không cần thiết. Cấp độ trong x264 được xác định dựa trên độ phân giải và FPS, vì vậy thường không có điểm nào để đặt thủ công, điều này sẽ không cải thiện bất cứ điều gì. Theo như tôi biết, ffmpeg có thể tự động đặt mức chính xác, vì vậy trừ khi bạn có lý do chính đáng để ép buộc và hiểu đầy đủ cách chọn cấp độ dựa trên FPS và độ phân giải, bạn không nên sử dụng tùy chọn "-level". Nếu bạn quan tâm đến khả năng tương thích cao nhất, hãy sử dụng cấu hình "đường cơ sở" thay vì "cao".

— Lissanro Rayen