Cách tạo AVI không nén từ một loạt 1000 ảnh PNG bằng FFMPEG

Làm cách nào tôi có thể tạo AVI không nén từ một loạt 1000 ảnh PNG bằng FFMPEG?

Tôi đã sử dụng lệnh này để chuyển đổi một input.avitệp thành một loạt các khung PNG:

ffmpeg -y -i input.avi  -an -vcodec png  -s 1024x768 pic%d.png`

Bây giờ tôi cần biết cách tạo một video AVI không nén từ tất cả các khung PNG đó. Tôi đã thử điều này:

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

Nhưng video kết quả mất rất nhiều chất lượng so với AVI gốc.

Có một số cách để loại bỏ AVI "không nén" ffmpeg, nhưng tôi nghi ngờ bạn thực sự có nghĩa là "mất mát". Cả hai thuật ngữ đều có một chút công bằng của phòng ngọ nguậy trong định nghĩa của chúng, như bạn sẽ thấy.

Tôi sẽ kết thúc cuộc thảo luận này với phiên bản HD 720p của Big Buck Bunny , vì đây là video có sẵn miễn phí, tất cả chúng ta đều có thể thử nghiệm và nhận được kết quả mà chúng ta có thể so sánh. Tốc độ dữ liệu thô của video 1280 × 720p ở 24 khung hình / giây gần bằng với tốc độ 1024 × 768 đã nêu của bạn ở mục tiêu 29,97 khung hình / giây, vì vậy kết quả của tôi sẽ là một hướng dẫn khá tốt về tốc độ dữ liệu bạn có thể mong đợi trên đoạn phim của mình.

Danh sách tự động các tùy chọn có sẵn

Lệnh POSIX sau đây cung cấp cho bạn một danh sách hầu hết phù hợp với những gì chúng ta thảo luận dưới đây:

$ ffmpeg -codecs 2> /dev/null | grep '^..EV..S ' | grep -vE 'bitmap|image'

Bạn có thể muốn chạy lệnh đó trên máy của mình để xem bản dựng FFmpeg của bạn sẽ hỗ trợ gì. FFmpeg hiếm khi được xây dựng với mọi bộ mã hóa có thể được kích hoạt.

Bây giờ hãy thảo luận về các tùy chọn đó.

Hoàn toàn không nén

Nếu định nghĩa của bạn về "nén" là hình thức video là ở bên phải trước khi nó quay sang photon bởi một màn hình kỹ thuật số, gần nhất tôi nhìn thấy trong ffmpeg -codecsdanh sách là -c:v r210, r10k, v410, v308, ayuvvà v408. Đây là tất cả đáng kể điều tương tự, chỉ khác nhau ở độ sâu màu , không gian màu , và alpha kênh hỗ trợ.

• R210 và R10K là 4: 4: 4 RGB ở mức 10 bit cho mỗi thành phần (bpc), vì vậy cả hai đều yêu cầu khoảng 708 Mbit / s cho 720p trong thử nghiệm của tôi. (Đó là khoảng ⅓ TB mỗi giờ, các bạn!)

  Các codec này đều đóng gói các thành phần màu 3 × 10 bit cho mỗi pixel thành giá trị 32 bit để dễ dàng thao tác bằng máy tính, giống như kích thước power-of-2. Sự khác biệt duy nhất giữa các codec này là phần cuối của từ 32 bit mà hai bit không sử dụng được bật. Sự khác biệt nhỏ này không nghi ngờ gì vì chúng đến từ các công ty cạnh tranh, Blackmagic Design và AJA Video Systems , tương ứng.

  Mặc dù đây là những codec tầm thường, nhưng có lẽ bạn sẽ phải tải xuống codec Blackmagic và / hoặc AJA để phát các tệp bằng cách sử dụng chúng trên máy tính của bạn. Cả hai công ty này sẽ cho phép bạn tải về codec của họ mà không cần phải mua phần cứng của họ đầu tiên, kể từ khi họ biết bạn có thể đối phó với các tập tin được tạo ra bởi những khách hàng làm có một số phần cứng của họ.

• V410 về cơ bản chỉ là phiên bản YUV của R210 / R10K; tốc độ dữ liệu của họ là giống hệt nhau. Tuy nhiên, codec này có thể mã hóa nhanh hơn, bởi vì ffmpegnhiều khả năng có đường dẫn chuyển đổi không gian màu được tăng tốc giữa không gian màu của khung hình đầu vào của bạn và không gian màu này.

  Tuy nhiên, tôi không thể đề xuất codec này vì tôi không thể tải tệp kết quả để phát trong bất kỳ phần mềm nào tôi đã thử, ngay cả với các codec AJA và Blackmagic được cài đặt.

• V308 là biến thể 8 bpc của V410, do đó, nó đạt đến 518 Mbit / s trong thử nghiệm của tôi. Như với V410, tôi không thể lấy các tệp này để phát lại trong phần mềm trình phát video thông thường.

• AYUV và V408 về cơ bản giống như V308, ngoại trừ việc chúng bao gồm một kênh alpha, cho dù nó có cần thiết hay không! Nếu video của bạn không sử dụng độ trong suốt, điều này có nghĩa là bạn phải trả tiền phạt kích thước của các codec 10 bpc R210 / R10K ở trên mà không nhận được lợi ích của không gian màu sâu hơn.

  AYUV có một ưu điểm: đó là codec "bản địa" trong Windows Media, vì vậy nó không yêu cầu phần mềm đặc biệt để chơi.

  V408 được cho là có nguồn gốc từ QuickTime theo cùng một cách, nhưng tệp V408 sẽ không phát trong cả 7 hoặc 10 trên máy Mac của tôi.

Vì vậy, đặt tất cả những thứ này lại với nhau, nếu PNG của bạn được đặt tên frame0001.pngvà vv:

$ 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

Lưu ý rằng tôi đã chỉ định AVI trong trường hợp của AYUV, vì nó gần như là một codec chỉ dành cho Windows. Những cái khác có thể hoạt động ở dạng QuickTime hoặc AVI, tùy thuộc vào loại codec nào trên máy của bạn. Nếu một định dạng chứa không hoạt động, hãy thử định dạng khác.

Các lệnh trên - cũng như các lệnh bên dưới - giả sử các khung đầu vào của bạn có cùng kích thước như bạn muốn cho video đầu ra của mình. Nếu không, thêm một cái gì đó như -s 1280x720vào lệnh, trước tên tệp đầu ra.

RGB nén, nhưng cũng không mất mát

Nếu, như tôi nghi ngờ, bạn thực sự có nghĩa là "lossless" thay vì "không nén", một lựa chọn tốt hơn nhiều so với bất kỳ điều nào ở trên là Apple QuickTime Animation , thông qua-c:v qtrle

Tôi biết bạn nói rằng bạn muốn có AVI, nhưng thực tế là có lẽ bạn sẽ phải cài đặt codec trên máy Windows để đọc bất kỳ định dạng tệp dựa trên AVI nào được đề cập ở đây, trong khi với QuickTime thì có khả năng video ứng dụng bạn chọn đã biết cách mở tệp QuickTime Animation. (Bộ giải mã AYUV ở trên là ngoại lệ đơn độc mà tôi biết, nhưng tốc độ dữ liệu của nó rất cao, chỉ để nhận được lợi ích của AVI.)

ffmpegsẽ nhét qtrlevào thùng chứa AVI cho bạn, nhưng kết quả có thể không tương thích rộng rãi. Trong thử nghiệm của tôi, QuickTime Player sẽ hiểu một chút về một tệp như vậy, nhưng sau đó nó sẽ phát nó. Mặc dù, điều kỳ lạ là VLC sẽ không chơi nó, mặc dù nó dựa một phần vào ffmpeg. Tôi sẽ dính vào các thùng chứa QT cho codec này.

Bộ giải mã hình ảnh động sử dụng một sơ đồ RLE tầm thường , vì vậy đối với các hình ảnh động đơn giản, nó nên làm như Huffyuv bên dưới. Càng nhiều màu sắc trong mỗi khung hình, nó sẽ càng tiếp cận tốc độ bit của các tùy chọn không nén hoàn toàn ở trên. Trong thử nghiệm với Big Buck Bunny, tôi đã có thể ffmpegđưa cho tôi tệp 165 Mbit / s ở chế độ RGB 4: 4: 4, thông qua -pix_fmt rgb24.

Mặc dù định dạng này được nén, nhưng nó sẽ cung cấp các giá trị pixel đầu ra giống hệt cho các tệp đầu vào PNG của bạn, vì lý do tương tự rằng nén không mất dữ liệu của PNG không ảnh hưởng đến các giá trị pixel.

Việc ffmpegtriển khai QuickTime Animation cũng hỗ trợ -pix_fmt argb, giúp bạn có được 4: 4: 4: 4 RGB, nghĩa là nó có kênh alpha. Theo một cách rất thô sơ, nó là tương đương với -c:v ayuv, được đề cập ở trên. Tuy nhiên, do nén không mất dữ liệu, nó chỉ đạt 214 Mbit / s , ít hơn tốc độ dữ liệu của AYUV mà không mất chất lượng hoặc tính năng.

Có các biến thể của Animation Animation với ít hơn 24 bit cho mỗi pixel, nhưng chúng được sử dụng tốt nhất cho các kiểu hoạt hình đơn giản dần dần. ffmpegdường như chỉ hỗ trợ một trong các định dạng khác được xác định bởi thông số kỹ thuật -pix_fmt rgb555be, có nghĩa là 15 bpp big endian RGB. Nó có thể chấp nhận được đối với một số video và phù hợp với hầu hết các cảnh quay screencast và hoạt hình đơn giản. Nếu bạn có thể chấp nhận số thập phân không gian màu, bạn có thể thấy tốc độ dữ liệu 122 Mbit / s của nó hấp dẫn.

Đặt tất cả những thứ này lại với nhau:

$ 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

Hiệu quả không mất mát: Thủ thuật YUV

Bây giờ, điều về RGB và YUV 4: 4: 4 là các mã hóa này rất dễ xử lý cho máy tính, nhưng chúng bỏ qua một thực tế về tầm nhìn của con người, đó là mắt chúng ta nhạy cảm hơn với sự khác biệt màu đen và màu trắng so với sự khác biệt màu sắc .

Do đó, hệ thống lưu trữ và phân phối video hầu như luôn sử dụng ít bit trên mỗi pixel cho thông tin màu hơn so với thông tin độ chói. Điều này được gọi là mẫu phụ sắc độ . Các lược đồ phổ biến nhất là 4: 2: 0 và 4: 2: 2.

Tốc độ dữ liệu của YUV 4: 2: 0 chỉ cao hơn 50% so với video không nén màu đen và trắng (chỉ có Y) và speed tốc độ dữ liệu của 4: 4: 4 RGB hoặc YUV.

4: 2: 2 là một loại điểm giữa 4: 2: 0 và 4: 4: 4. Nó gấp đôi tốc độ dữ liệu của video chỉ có Y và tốc độ dữ liệu là 4: 4: 4.

Đôi khi bạn cũng thấy 4: 1: 1, như trong tiêu chuẩn máy ảnh DV cũ . 4: 1: 1 có cùng tốc độ dữ liệu không nén như 4: 2: 0, nhưng thông tin màu được sắp xếp khác nhau.

Điểm chính của tất cả những điều này là nếu bạn bắt đầu với tệp H.264 4: 2: 0, hãy mã hóa lại thành RGB không nén 4: 4: 4, bạn hoàn toàn không mua gì YUV nén 4: 2: 0. Điều này đúng ngay cả khi bạn biết quy trình làm việc của mình là 4: 4: 4 RGB, vì đó là một chuyển đổi tầm thường; phần cứng và phần mềm video thực hiện chuyển đổi như vậy một cách thường xuyên.

Bạn thực sự chỉ cần 4: 4: 4 khi bạn nhìn trộm pixel hoặc bạn đang thực hiện thay đổi màu ở cấp độ pixel trên video và bạn cần giữ nguyên các giá trị pixel chính xác. Ví dụ, công việc hiệu ứng hình ảnh (VFX) dễ thực hiện hơn với định dạng pixel 4: 4: 4, vì vậy, các nhà VFX cao cấp thường sẵn sàng chịu đựng tốc độ dữ liệu cao hơn mà nó yêu cầu.

Hiệu quả không mất mát: Lựa chọn Codec

Khi bạn tự mở các codec YUV bằng cách khử màu, các tùy chọn của bạn cũng mở ra. ffmpegcó nhiều codec không mất hiệu quả .

Huffyuv

Tùy chọn tương thích rộng rãi nhất là Huffyuv . Bạn nhận được điều này thông qua -c:v huffyuv.

Bộ giải mã Windows Huffyuv ban đầu chỉ hỗ trợ hai định dạng pixel: RGB24 và YUV 4: 2: 2. (Trên thực tế, nó hỗ trợ hai hương vị của YUV 4: 2: 2, chỉ khác nhau theo thứ tự các byte trên đĩa.)

Các phiên bản cũ hơn của codec FFmpeg Huffyuv không bao gồm hỗ trợ RGB24, vì vậy nếu bạn dùng thử và FFmpeg cho bạn biết nó sẽ sử dụng yuv422pđịnh dạng pixel, bạn cần nâng cấp.

FFmpeg cũng có một codec biến thể Huffyuv có tên FFVHuff, hỗ trợ YUV 4: 2: 0. Biến thể này không tương thích với codec Windows DirectShow Huffyuv, nhưng nó sẽ mở trong mọi phần mềm dựa trên libavcodec, chẳng hạn như VLC.

• RGB24 - RGB 4: 4: 4 về cơ bản giống như tùy chọn không gian màu RGB24 của QuickTime Animation. Hai codec sẽ khác nhau một chút về nén cho một tệp nhất định, nhưng chúng thường sẽ đóng.

  Về cơ bản, nó cũng giống như chế độ YUV 4: 4: 4 được sử dụng bởi tùy chọn V308 ở trên. Sự khác biệt về không gian màu làm cho không có sự khác biệt thực tế, vì việc chuyển đổi không gian màu rất dễ thực hiện trong thời gian thực.

  Do khả năng nén không mất dữ liệu của Huffyuv, tôi đã có thể có được một video thử nghiệm để nén tới khoảng 251 Mbit / giây ở chế độ RGB24, với chất lượng hình ảnh giống hệt với những gì bạn nhận được từ V308 hoặc AYUV. Nếu AVI là điều bắt buộc đối với bạn, việc cài đặt codec Huffyuv có lẽ ít đau đớn hơn so với việc trả chi phí tốc độ dữ liệu 3 × của AYUV.

• YUV 4: 2: 2 - Chế độ này thực tế hơn cho video so với RGB24, không nghi ngờ gì tại sao các ffmpegnhà phát triển lại chọn triển khai nó trước. Như bạn mong đợi từ mức giảm lý thuyết đã thảo luận ở trên, tệp thử nghiệm của tôi được mã hóa thành 173 Mbit / s . Điều đó khá chính xác, nếu bạn tính đến thực tế là đoạn âm thanh không thay đổi giữa hai bài kiểm tra này.

• YUV 4: 2: 0 - Tùy chọn này xác định thông tin màu nhiều hơn 4: 2: 2, giảm tốc độ dữ liệu xuống 133 Mbit / s trong thử nghiệm của tôi.

Đặt tất cả những thứ này lại với nhau:

$ 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

Mặc dù ffvhuffcodec mặc định là 4: 2: 0 khi tôi viết điều này và thực sự chỉ hỗ trợ định dạng pixel đó trong phiên bản phát hành mà tôi đang sử dụng, điều này đang thay đổi , vì vậy bạn nên bao gồm cờ trong trường hợp thay đổi mặc định này.

Út Video

Một lựa chọn gần đây hơn với tinh thần tương tự như Huffyuv và FFVHuff là Ut Video . Giống như Huffyuv, có một codec video Windows , có nghĩa là bất kỳ chương trình Windows nào có thể phát phim đều có thể phát video bằng cách sử dụng codec này với codec được cài đặt. Không giống như Huffyuv, cũng có một codec video Mac, vì vậy bạn không bị hạn chế đối với phần mềm dựa trên FFmpeg hoặc libavcodecđể đọc các tệp này trên máy Mac.

Bộ giải mã này rất linh hoạt về các không gian màu, vì vậy tôi sẽ chỉ đưa ra một vài ví dụ về các không gian màu phổ biến:

• 4: 4: 4 RGB thông qua -f avi -c:v utvideo -pix_fmt rgb24cung cấp cho 178 Mbit / giây đầu ra

• 4: 4: 4 YUV qua -f avi -c:v utvideo -pix_fmt yuv444pcho 153 Mbit / giây đầu ra

• 4: 2: 2 YUV qua -f avi -c:v utvideo -pix_fmt yuv422pcho 123 Mbit / giây đầu ra

• 4: 2: 0 YUV qua -f avi -c:v utvideo -pix_fmt yuv420pcho 100 Mbit / giây đầu ra

Tôi nghi ngờ YUV 4: 4: 4 làm tốt hơn 4: 4: 4 RGB trong thử nghiệm này mặc dù hai cái này tương đương về mặt kỹ thuật vì video nguồn là 4: 2: 0 YUV, vì vậy việc sắp xếp dữ liệu theo định dạng YUV cho phép nén không mất dữ liệu tốt hơn bằng cách nhóm các kênh U và V dự phòng một phần lại với nhau trong tệp.

FFV1

Một tùy chọn thú vị khác trong không gian này là FFV1codec riêng của FFmpeg . Phần lớn này được sử dụng như một codec lưu trữ thay vì codec phát lại hoặc chỉnh sửa, nhưng vì rất nhiều phần mềm dựa trên libavcodecthư viện làm nền tảng cho FFmpeg hoặc có thể được sử dụng libavcodecthông qua các công cụ như ffdshow, dù sao nó cũng có thể hữu ích cho bạn.

Theo mặc định, ffmpegsẽ duy trì không gian màu của các tệp đầu vào của bạn khi sử dụng codec linh hoạt như FFV1, để nếu bạn cung cấp cho nó một trong các tệp MP4 Big Buck Bunny chính thức, sử dụng YUV 4: 2: 0, đó là những gì bạn sẽ nhận được trừ khi bạn đưa một -pix_fmtlá cờ cho ffmpeg. Điều này dẫn đến một tệp đầu ra 63 Mbit / s .

Nếu bạn buộc FFV1 sử dụng không gian màu YUV 4: 4: 4 -pix_fmt yuv444p, kích thước tệp chỉ lên tới 86 Mbit / giây , nhưng trong trường hợp này, chúng tôi sẽ không mua gì cho chúng tôi vì chúng tôi mã hóa từ bản gốc 4: 2: 0 . Tuy nhiên, thay vào đó, nếu bạn cung cấp một bộ PNG, như trong câu hỏi ban đầu, tệp đầu ra có thể sử dụng không gian bgrahoặc bgr0màu, chỉ là sự sắp xếp lại các không gian argbvà rgb24màu được đưa lên ở trên.

Mất dữ liệu H.264

Một lựa chọn thú vị khác là Lossless H.264 . Đây là khá nhiều một x264-chỉ điều như các văn bản này, nhưng những người sử dụng FFmpeg ở phía mã hóa có thể sẽ được sử dụng phần mềm khác bao gồm libx264trên giải mã bên cũng vậy, chẳng hạn như VLC.

Cách đơn giản nhất để có được một tập tin như vậy là:

$ ffmpeg -i frame%04d.png -c:v libx264 -qp 0 -f mp4 output.mp4

Các -qp 0lá cờ là chìa khóa: giá trị cao hơn cho nén lossy. (Bạn cũng có thể cung cấp -crf 0để có được hiệu ứng tương tự.)

Như với FFV1, ffmpegsẽ cố gắng đoán không gian màu đầu ra tốt nhất được cung cấp không gian màu đầu vào, vì vậy để so sánh với kết quả ở trên, tôi đã chạy nhiều lượt mã hóa trên tệp nguồn Big Buck Bunny với các không gian màu khác nhau:

• yuv444p : Đây là những gì bạn ffmpegchọn khi bạn cung cấp cho nó một luồng RGB PNG, như trong câu hỏi ban đầu và dẫn đến một tệp 44 Mbit / giây với tệp thử nghiệm của chúng tôi

• yuv422p : Điều này tương tự như không gian màu mặc định cho Huffyuv, nhưng chúng tôi nhận được tệp 34 Mbit / giây trong trường hợp này, khá tiết kiệm!

• yuv420p : Đây là mặc định cho các MP4 chính thức của Big Buck Bunny mà tôi đang thử nghiệm và cho kết quả là tệp 29 Mbit / giây .

Coi chừng bạn đang giao dịch rất nhiều khả năng tương thích để có được kích thước tệp nhỏ như vậy. Đó là lý do tại sao tôi thậm chí không buồn cố nhét cái này vào thùng chứa AVI hoặc MOV. Nó gắn chặt với x264 đến mức bạn cũng có thể sử dụng loại thùng chứa tiêu chuẩn (MP4) của nó thay thế. Bạn cũng có thể sử dụng một cái gì đó như Matroska cho việc này.

Bạn có thể đánh đổi một số tốc độ bit đó để có thời gian mã hóa nhanh hơn bằng cách thêm -preset ultrafast. Điều đó đã tăng tốc độ bit của tệp thử nghiệm của tôi lên 44 Mbit / s ở chế độ YUV 4: 2: 2, nhưng được mã hóa nhanh hơn nhiều, như đã hứa. Các tài liệu cho rằng điều đó -preset veryslowcũng đáng giá, nhưng nó dẫn đến thời gian mã hóa lâu hơn nhiều trong khi chỉ tiết kiệm được một chút dung lượng; Tôi không thể khuyên bạn nên nó.

Khác

ffmpegcũng hỗ trợ chế độ chỉ giải mã cho Lagarith và chế độ chỉ mã hóa cho JPEG lossless . Hai codec này thực sự hơi giống nhau và sẽ cho các tệp nhỏ hơn một chút so với Huffyuv với cùng chất lượng. Nếu các ffmpegnhà phát triển thêm mã hóa Lagarith, nó sẽ là một sự thay thế mạnh mẽ cho Huffyuv. Tuy nhiên, tôi không thể khuyên dùng JPEG lossless vì nó không được hỗ trợ giải mã rộng.

Mất cảm nhận: Hoặc, có lẽ bạn có thể thoát khỏi một số mất mát

Sau đó, có các codec bị mất cảm giác . Trừ khi bạn nhìn trộm pixel, bạn gần như chắc chắn không thể nói rằng những cái này cho kết quả hình ảnh khác với hai nhóm trước. Bằng cách từ bỏ ý tưởng thay đổi hoàn toàn bằng không giữa cảm biến quay video và thiết bị hiển thị, bạn mua được khoản tiết kiệm đáng kể:

• Apple ProRes :-c:v proreshoặc-c:v prores_ks- ProRes là một codec dựa trên hồ sơ, có nghĩa là có một số biến thể, mỗi biến thể có chất lượng khác nhau so với đánh đổi không gian:

  • ProRes 4444 mã hóa video thử nghiệm của chúng tôi chỉ bằng 114 Mbit / s , nhưng chất lượng VFX . Hiện tại có baprores*codeckhác nhautrong FFmpeg, nhưng chỉprores_kshỗ trợ ProRes 4444, khi tôi viết điều này, thông qua-profile:v 4444tùy chọn.

    Nếu bạn đang tự hỏi tại sao bạn lại bận tâm với ProRes 4444 trên Lossless H.264, thì đó là khả năng tương thích, tốc độ giải mã, khả năng dự đoán và kênh alpha.

  • ProRes 422 tiết kiệm nhiều không gian hơn, chỉ cần 84 Mbit / s để đưa ra kết quả mà bạn có thể biết từ ProRes 4444 chỉ bằng cách nhìn trộm pixel. Trừ khi bạn cần kênh alpha được cung cấp bởi ProRes 4444, có lẽ không có lý do gì để nhấn mạnh vào ProRes 4444.

    ProRes 422 là đối thủ cạnh tranh gần hơn với tùy chọn Lossless H.264 ở trên, vì không hỗ trợ kênh alpha. Bạn sẽ muốn chấp nhận tốc độ bit cao hơn của ProRes nếu bạn cần khả năng tương thích với các ứng dụng video chuyên nghiệp của Apple, chi phí CPU thấp hơn để mã hóa và giải mã hoặc tốc độ bit có thể dự đoán được. Cái sau là quan trọng với các bộ mã hóa phần cứng, ví dụ. Mặt khác, nếu bạn có thể đối phó với các vấn đề tương thích của Lossless H.264, bạn có tùy chọn sử dụng không gian màu 4: 2: 0, đây không phải là một tùy chọn từ bất kỳ cấu hình ProRes nào.

    Tất cả ba bộ mã hóa ProRes trong FFmpeg đều hỗ trợ cấu hình ProRes 422, vì vậy tùy chọn đơn giản nhất là sử dụng -c:v prores, thay vì -c:v prores_ks -profile hq, hoặc phụ thuộc vào tính năng tự động cấu hình prores_ksđể thực hiện đúng.

  Thậm chí còn có các cấu hình ProRes tuyệt vời hơn, nhưng chúng có nghĩa là cho video SD hoặc dưới dạng proxy cho các tệp độ phân giải đầy đủ.

  Vấn đề chính với ProRes là nó chưa có sự hỗ trợ rộng rãi ngoài thế giới video của Apple và pro.

• DNxHD của Avid là một codec tương tự như ProRes, nhưng không gắn liền với thế giới video chuyên nghiệp của Apple. Avid cung cấp các codec có thể tải xuống miễn phí cho cả Windows và Macintosh và FFmpeg hiện hỗ trợ nó thông qua-c:v dnxhd.

  Vì DNxHD là một codec dựa trên cấu hình như ProRes, bạn chọn cấu hình từ bộ được xác định trước và thông báo cho codec biết kích thước khung hình, tốc độ khung hình và tốc độ bit sẽ sử dụng. Đối với tệp thử nghiệm Big Buck Bunny, -b:v 60Mhồ sơ là phù hợp nhất. Không có gì đáng ngạc nhiên, tệp kết quả là khoảng 59 Mbit / s .

• MJPEG tổn thất thấp :-vcodec mjpeg -qscale:v 1- Điều này phổ biến hơn nhiều so với JPEG lossless. Trên thực tế, đây từng là một codec chỉnh sửa video khá phổ biến và nó vẫn thường được sử dụng bởi những thứ như máy quay video phát trực tuyến. Tất cả lịch sử đó có nghĩa là rất dễ tìm thấy phần mềm hỗ trợ nó.

  Mong đợi sự thay đổi khá rộng về tốc độ dữ liệu từ codec này. Một thử nghiệm tôi vừa thực hiện ở đây đã cho tôi 25 Mbit / s cho video 720p. Đó là mức nén đủ cao để khiến tôi lo lắng về sự mất mát, nhưng nó có vẻ khá tốt với tôi. Chỉ dựa trên tốc độ dữ liệu, tôi có thể nói rằng nó có thể ngang tầm với 12 Mbit / s MPEG-2 hoặc 6 Mbit / s H.264.

Đặt tất cả những thứ này lại với nhau:

$ 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

Điểm mấu chốt của các phương pháp này là trừ khi bạn làm một việc gì đó rất khắt khe, "đủ tốt" thực sự là đủ tốt.

Chú thích và lạc đề

1. Lệnh sẽ hoạt động như được đưa ra trên Linux, macOS, BSD và Unix. Nếu bạn đang ở trên Windows, bạn có thể nhận được dòng lệnh POSIX thông qua Cygwin hoặc WSL .

2. Có một số lý do tại sao danh sách được tạo bởi lệnh đó không hoàn toàn khớp với bộ codec tôi đã chọn để thảo luận ở trên:

   • Thứ hai greplà để lọc các bộ mã hóa không phù hợp như bmpkhông phải là codec "video", mặc dù được gắn thẻ Vtrong danh sách này. Mặc dù về mặt kỹ thuật, bạn có thể nhét nhiều thứ này vào một thùng chứa như AVI, MP4 hoặc MKV để có được một video một tệp, nhưng tệp đó sẽ không thể đọc được bởi bất cứ thứ gì ngoại trừ một chương trình dựa trên ffmpeghoặc libavcodec.

     Có một vài trường hợp ngoại lệ, chẳng hạn như điều đó -f avi -c:v ljpegmang lại thứ mà bạn có thể gọi là "lossless MJPEG", nhưng theo quy định, chúng tôi không quan tâm đến việc nhét nhiều tệp hình ảnh tĩnh vào thùng chứa A / V ở đây để làm phim. Chúng tôi muốn các codec video được công nhận rộng rãi ở đây, không phải là mánh khóe ngữ nghĩa.

   • Lệnh hiện không thể lọc ra một số bộ mã hóa không phù hợp như GIF vì chúng hiện không được mô tả trong ffmpeg -codecsđầu ra dưới dạng bitmaphoặc imageđịnh dạng tệp.

     GIF là một trường hợp thú vị: nó hỗ trợ nhiều khung hình ảnh trong một tệp GIF với thông tin thời gian để phát lại chuyển động, nhưng vì nhiều lý do, nó hoàn toàn không phù hợp với cuộc thảo luận của chúng tôi ở đây.

   • Một vài trong số các tùy chọn được hiển thị là đã lỗi thời hoặc không bao giờ thực sự có nhiều lực kéo, chẳng hạn như flashsv, diracvà snow, do đó, nó không đáng thảo luận chúng ở trên.

   • Một số tùy chọn trong danh sách đó có nghĩa là chỉ để sử dụng trong đường ống giữa ffmpegtrường hoặc giữa ffmpegvà một chương trình khác, chẳng hạn như rawvideovà wrapped_avframe, và do đó không phù hợp với mục đích của chúng tôi ở đây.

   • Gần cuối cuộc thảo luận ở trên, tôi thận trọng mở rộng phạm vi câu hỏi một chút để bao gồm một vài tùy chọn mất mát được lựa chọn cẩn thận, vì vậy chúng không vượt qua grepbộ lọc đầu tiên trong lệnh trên.

Vì vậy, tôi đã kết thúc câu trả lời của mình quá lâu.
Tóm tắt TL; DR: Để lưu trữ một cách dễ dàng một chuỗi hình ảnh, sử dụng libx264hoặc libx264rgbvới -preset ultrafast -qp 0. Nó nhanh gần như ffvhuff, với tốc độ bit thấp hơn nhiều và giải mã nhanh hơn. huffyuvđược hỗ trợ rộng rãi hơn nhiều ngoài ffmpeg, nhưng không hỗ trợ nhiều định dạng pixel như ffvhuff. Vì vậy, đó là một lý do khác để sử dụng h.264, giả sử các công cụ khác của bạn có thể xử lý High 4:4:4 Predictivecấu hình h.264 mà x264 sử dụng ở chế độ lossless. x264 chỉ có thể thực hiện trong nội bộ nếu cần truy cập ngẫu nhiên nhanh vào các khung tùy ý.

Cảnh giác với một lỗi ffmpeg ảnh hưởng đến libx264rgb khi đọc từ một thư mục hình ảnh. (và ai biết những trường hợp khác.) Kiểm tra sự mất mát trong thiết lập của bạn trước khi sử dụng. (dễ dàng với ffmpeg -i in -pix_fmt rgb24 -f framemd5nguồn và lossless-nén))

chỉnh sửa: utvideomã hóa và giải mã khá nhanh, và là một codec đơn giản hơn nhiều so với h.264. Về cơ bản, nó là một thiết bị hiện đại huffyuv, với sự hỗ trợ cho các không gian màu hữu ích hơn. Nếu bạn gặp sự cố với h.264, hãy thử utvideo tiếp theo cho các tệp tạm thời.

edit2: PNG dưới dạng codec RGB dường như hoạt động tốt, ít nhất là trên trailer Sintel.

Xem thêm câu trả lời tương tự của tôi cho một câu hỏi tương tự: https://superuser.com/a/860335/20798

Có rất nhiều thông tin trong câu trả lời của Warren Young về các định dạng thô và codec khác nhau. Tôi nghĩ rằng câu trả lời sẽ hữu ích hơn nếu nó ngắn hơn, vì vậy tôi đang đưa ra một câu trả lời mới. Nếu bạn đang làm việc với phần mềm không hỗ trợ lossless x264 hoặc ffvhuff, thì một số thông tin đó có thể vẫn hữu ích.

Định nghĩa hữu ích nhất về "lossless" trong ngữ cảnh này là bạn có thể khôi phục bit đầu vào cho bit. Không lo lắng về sự xuống cấp chất lượng từ mã hóa video, bất kể bạn làm gì.

http://en.wikipedia.org/wiki/Chroma_subampling

Tốt nhất, tránh chuyển đổi nhiều không gian màu. Các lỗi làm tròn có khả năng xây dựng. Nếu bạn sẽ vận hành trên video của mình bằng các bộ lọc hoạt động trong không gian màu RGB, thì việc giữ cho RGB có ý nghĩa, miễn là bitrate cao hơn không phải là vấn đề. Cuối cùng, bạn có thể sẽ tạo ra một yuv 4:2:0video, nhưng việc giữ độ phân giải màu sắc thêm có khả năng hữu ích, tùy thuộc vào những bộ lọc bạn sẽ áp dụng.

Dù bằng cách nào, lossless x264 và ffvhuff cả hỗ trợ RGB và YUV 4:4:4, 4:2:2và 4:2:0. Tôi muốn đề xuất x264, vì nó nhanh để giải mã. Nếu bạn đang cố gắng phát lại video RGB HD trong thời gian thực, hãy thử opengl thay vì xv, vì xv trên hệ thống của tôi chỉ chấp nhận đầu vào yuv. mplayer đã mất thêm thời gian CPU để thực hiện chuyển đổi không gian màu.

Nguồn cho các bài kiểm tra mã hóa sau: https://media.xiph.org/ . https://media.xiph.org/sintel/sintel_trailer-1080-png.tar.gz Họ đã quên gzip các tệp y4m cho trailer sintel, vì vậy tarball png thực sự nhỏ hơn rất nhiều.

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

ví dụ

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

Lưu ý rằng tôi đã quên chỉ định -r 24khung hình / giây, vì vậy nó sẽ không giữ đồng bộ av với âm thanh. (và các số bitrate (nhưng không phải kích thước tệp) cũng sẽ bị tắt. ffmpeg mặc định là 25fps). CPU trong máy này là core2duo 2.4GHz (E6600) thế hệ 1.

các kết quả:

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

Lưu ý rằng mediainfokhông biết về RGB h.264, nó vẫn nói rằng các tệp là YUV.

Kiểm tra xem nó thực sự là lossless:

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

Vì vậy, bạn có thể khôi phục đầu vào PNG gốc theo cách đó, tức là bạn có thể tạo các PNG với dữ liệu hình ảnh giống hệt nhau trong đó.

Lưu ý -pix_fmt rgb24kiểm tra x264. Bộ giải mã h.264 của ffmpeg xuất ra đầu ra gbrp (phẳng, không được đóng gói), vì vậy các bit là như nhau, nhưng theo một thứ tự khác. "Container" framemd5 không áp đặt bất kỳ hạn chế định dạng nào, nhưng bạn sẽ chỉ nhận được cùng md5 nếu các bit được sắp xếp theo cùng một cách. Tôi chỉ nhìn vào những gì ffmpeg nói rằng nó đang sử dụng cho một pix fmt khi tôi cho nó ăn PNG, sau đó sử dụng nó làm -pix_fmtđối số để giải mã. Ngẫu nhiên, đây là lý do vlc sẽ không phát các tệp RGB h.264 (cho đến khi phát hành tiếp theo hoặc các bản dựng hàng đêm hiện tại): Nó không hỗ trợ định dạng pixel gbrp.

Đối với yuv sử dụng libx264, không libx264rgb. Bạn không cần cài đặt phiên bản RGB của x264, thư viện thực tế hỗ trợ cả hai. Chỉ là ffmpeg đã triển khai nó như hai bộ mã hóa có tên khác nhau. Tôi nghĩ rằng nếu họ không làm điều đó, hành vi mặc định sẽ là để đầu vào rgb là rgb và chạy rất chậm trong khi tạo ra đầu ra bitrate cao hơn nhiều cho cùng chất lượng. (đôi khi bạn vẫn phải sử dụng -pix_fmt yuv420pnếu bạn muốn 420thay vì 444đầu ra h.264.

Trừ khi bạn đang tạo các tệp để lưu trữ lâu dài, luôn luôn sử dụng -preset ultrafastcho lossless x264. Nhiều khung tham chiếu và tìm kiếm chuyển động hầu như không tạo ra bất kỳ sự khác biệt nào cho lossless, đối với vật liệu không hoạt hình với bất kỳ tiếng ồn nào. CABAC cần một lượng lớn CPU với tốc độ bit không mất, thậm chí để giải mã. Chỉ sử dụng cho mục đích lưu trữ, không phải các tập tin cào. (cực nhanh vô hiệu hóa CABAC). CABAC cung cấp tiết kiệm bitrate 10 đến 15%.

Nếu bạn cần mọi khung hình là khung hình chính, hãy đặt -keyint 1. Sau đó, phần mềm chỉnh sửa video chỉ muốn cắt trên khung hình chính hoặc w / e sẽ không giới hạn bạn.

Để trả lời câu hỏi ban đầu: Đây là những gì bạn nên làm để ném xung quanh các tệp tạm thời trong khi thử mọi thứ theo giai đoạn (ví dụ: khử chậm, tiết kiệm đầu ra không mất dữ liệu trước khi thử những thứ khác):

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

Nếu bạn thực sự cần đầu ra của mình trong các tệp hình ảnh mà bạn có thể sửa đổi bằng các công cụ hình ảnh tĩnh, thì chắc chắn, hãy giải mã thành png. Bạn sẽ không mất bất cứ thứ gì nhiều hơn có thể là ít nhất trong số 8 bit của mỗi giá trị Y, Cb và Cr cho mỗi pixel.

x264 xuất hiện thực sự tốt trong điều này bởi vì có rất nhiều khung màu đen với một chút văn bản, mờ dần và mờ dần, và sự tương đồng hoàn hảo giữa các khu vực lớn của nhiều khung hình, mà nó quản lý để tận dụng lợi thế ngay cả với -preset ultrafast. Trên live-action, tôi vẫn thấy x264 ở một nửa kích thước tệp của ffvhuff (yuv420).

Đối với bất kỳ ai tò mò: Mã hóa rgb không mất thời gian cpu cao có (x264 lõi 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

Lưu ý phần thực sự cao của khung p có trọng số và cũng là phần thực sự cao của bỏ qua macroblocks. Mọi chuyển đổi cảnh đều mờ dần, không bị cắt và x264 tận dụng lợi thế nếu bạn cho nó thời gian CPU để tìm ra cách.

ghi chú thêm (codec mất dữ liệu để chỉnh sửa):

Để cọ rửa tiến / lùi thông qua các clip, các codec chỉ trong nội bộ thường được ưa chuộng (utvideo, ffvhuff, mjpeg, jpeg2000, pro-res, AVC-Intra). Tôi tưởng tượng AVC thông thường với các GOP ngắn (1/2 đến 1 giây) cũng sẽ hoạt động tốt, miễn là phần mềm biết nó đang làm gì (giải mã khung hình gần nhất của tôi khi chà nhanh, giải mã trong GOP để có được một khung liên kết nếu bạn phóng to đủ theo dòng thời gian cho điều đó là cần thiết).

Tôi đã đăng một số điều tiêu cực về điều này và https://video.stackexchange.com/ về pro-res, như "điều gì sẽ xảy ra nếu nén chậm và tệ hơn so với codec không mất dữ liệu", nhưng nó có một số tính năng thú vị. Apple nói rằng họ có thể giải mã ở độ phân giải một nửa bằng cách sử dụng ít nhất 1/3 thời gian CPU để giải mã rez đầy đủ.

Việc triển khai prores của ffmpeg có lẽ cũng không được tối ưu hóa cho tốc độ như của Apple, đó là lý do tại sao thử nghiệm của tôi với ffmpeg đã khiến nó trông chậm. Có thể không đáng để sử dụng nếu bạn có quy trình làm việc Phần mềm miễn phí với các công cụ dựa trên ffmpeg, nhưng có thể đáng để thử nếu bạn đang sử dụng phần mềm thương mại.

Tôi không thực hiện nhiều chỉnh sửa video, chủ yếu chỉ là mã hóa, vì vậy tôi không có ý thức tốt về những thử nghiệm nào sẽ phù hợp với codec như prores. Tôi đoán rằng có lẽ mjpeg sẽ là một sự thay thế nhanh, nếu GOP x264 ngắn không hoạt động tốt. Có các triển khai jpeg được tăng tốc asm trong các bản phân phối Linux và đó là một codec khá đơn giản. Bạn có thể tăng chất lượng lên hoặc xuống khi cần để đánh đổi chất lượng so với tốc độ tập tin + mã hóa / giải mã. Nó cổ xưa, nhưng nếu bạn muốn một codec chỉ nội bộ thực sự nhanh, nó có thể đánh bại x264.

Đối với x264, tôi sẽ thử một cái gì đó như x264 --crf 10 --keyint=1 --preset superfast --tune fastdecode (chỉ dành cho nội bộ, không có bất kỳ nội dung nào khác được --avcintra-classđặt.) Lưu ý superfast(không có CABAC), hoặc faster, ultrafastcó lẽ không phải là tốt nhất cho hoạt động mất mát. Tôi nghĩ rằng cực nhanh sẽ mất rất nhiều chất lượng mà không nhanh hơn nhiều. Chất lượng thấp hơn (crf cao hơn) bạn sử dụng, càng đáng để dành nhiều thời gian CPU hơn để tìm mã hóa tốt hơn. Mặc dù vậy, rất nhiều điều này có thể không phù hợp với kích thước GOP = 1.

Với kích thước GOP> 1, nếu bạn ném quá nhiều bit vào mã hóa, dự đoán tương tác tốt hơn sẽ không tiết kiệm được nhiều bit khi mã hóa phần dư (vì thay đổi nhiễu / hạt / tinh tế giữa các khung được bảo toàn rất chính xác), sau đó chỉ cần siêu tốc có lẽ là tốt Nếu không, với --keyint=30hoặc một cái gì đó, có lẽ --preset veryfast --crf 12sẽ thú vị.

Về lý thuyết, chất lượng tại một cài đặt CRF nhất định phải không đổi trên các cài đặt trước. Nếu bạn đang tìm kiếm các tệp nhỏ hơn (giải mã nhanh hơn), giao dịch giảm chất lượng và thời gian mã hóa có ý nghĩa.

Tôi nghĩ rằng ffmpeg thực sự hỗ trợ chuyển đổi sang video không nén.
Tôi đã sử dụng ffmpeg -i input.mp4 -vcodec rawvideo out.avi và kết quả .avi gần như đúng kích thước tệp. Windows media player dường như không thể phát chính xác nhưng VirtualDub có thể đọc được và tôi không thấy bất kỳ sự mất mát nào về chất lượng hình ảnh.