Bộ mã hóa video MIPS thấp

Tôi đang tìm kiếm một MIPS thấp, bộ mã hóa video nén thấp. Đây là mức nén chất lượng 10fps, VGA. Những lựa chọn của tôi là gì? Tôi cần có khả năng thực hiện việc nén này bằng CPU ARM M4 150 MHz với hỗ trợ Điểm nổi. (STM32F4) ..

Ý tưởng của tôi là đẩy dữ liệu nén này ra khỏi CPU bằng một bus song song, sẽ không có xử lý nào được thực hiện trên dữ liệu. Tốc độ nén khôn ngoan, càng nhiều càng tốt, tôi chỉ muốn xem ranh giới. Đây là một ứng dụng camera quan sát giá rẻ, tôi muốn xem những gì tôi có thể đạt được với cpu 5USD và rất nhiều băng tần truyền với bộ mã hóa 30USD với dữ liệu truyền dữ liệu thấp bw.

10 khung hình / giây, VGA sẽ tạo ra dữ liệu khoảng 25Mbit / giây. Đây là tốc độ dữ liệu khá cao cho bất cứ điều gì ngoài đó. Nếu tôi có thể giảm mức này xuống 5Mbit / giây, tôi nghĩ rằng tôi có thể xây dựng một hệ thống camera quan sát có chi phí rất thấp. Khi tôi nhận được dữ liệu về cơ sở, tôi có thể mã hóa lại dữ liệu, do đó không có vấn đề gì với cơ chế nén, miễn là nó không bị mất dữ liệu.

Video đơn sắc là những gì cần thiết tại thời điểm trên màu sắc.

Cập nhật

• CPU này có 120 MHz được phân bổ cho nhiệm vụ này.
• Giao diện bộ nhớ là 16 bit, do đó ghi / đọc bộ nhớ ngoài chậm hơn so với bộ nhớ trong.
• Bộ nhớ trong là 120KByte và nó có quyền truy cập nhanh 32 bit. Cả hai trường hợp bộ nhớ được truy cập thông qua bus AHB mà chúng ta nên giả sử 60 MHz là tần số xung nhịp.
• Dự kiến ​​luồng dữ liệu sau:
  1. Camera -> DMA -> Bộ nhớ ngoài (không có sự tham gia của cpu)
  2. Bộ nhớ ngoài -> CPU -> Nén -> Bộ nhớ trong
  3. Bộ nhớ trong -> DMA -> Bus dữ liệu -> Thiết bị ngoài

CPU sẽ chỉ đọc một đoạn nén dữ liệu và ghi vào bộ nhớ trong của nó (dữ liệu đã nén), sau đó bắt đầu truyền DMA.

1. Phân loại xem bạn cần MIPS thấp hay tổng thể có độ phức tạp thấp
Hãy để tôi có một sự tự do nhỏ để chia vấn đề này thành hai phần.

1. Mã hóa có độ phức tạp thấp - cho phép các tài nguyên thấp hơn (đặc biệt là trong bộ nhớ) giúp mã hóa đáp ứng nhanh trong hệ thống nhất định.
2. Rõ ràng thấp trong tính toán (MIPS). - chỉ liên quan đến chu kỳ CPU tối thiểu có thể.

Có tiêu chí thứ ba - trong đó mọi người nói về "Độ trễ thấp" - cho ứng dụng như Hội nghị truyền hình trong đó tài nguyên tính toán có thể không đáng lo ngại - nhưng độ trễ chung được giới thiệu bởi mã hóa

Điều quan trọng cần lưu ý là trong các hệ thống có độ phức tạp thấp hơn - truy cập vào bộ nhớ (tốc độ và độ rộng của bộ nhớ) và đôi khi IO thường cực kỳ chậm, đó là lý do tại sao lớp thuật toán MPEG bị ảnh hưởng mặc dù thuật toán tính toán có thể đơn giản.

Trước khi bạn đưa ra đánh giá về yêu cầu về tiền mã hóa - bạn nên cố gắng tạo ngân sách theo -

a. Chu kỳ CPU mỗi giây.
b. Bộ nhớ tối đa thông qua đặt.
c. Độ trễ IO

2. Bạn nên tùy chỉnh MPEG thay vì phát minh lại
Nói chung - Lớp codec MPEG cung cấp cho bạn một cơ chế rất linh hoạt để thực hiện việc này. Theo nghĩa đó, bạn hoàn toàn không phải phát minh lại codec nhiều như bạn muốn tùy chỉnh MPEG 2 hoặc MPEG 4 để hoàn thành công việc của mình.

Trước hết, hãy nói những gì tất cả các yếu tố có thể nén và sắp xếp chúng theo thứ tự phức tạp:

1. Dự toán chuyển động và bù chuyển động. 1.a. Dự đoán chuyển tiếp (khung P) 1.b. Dự đoán kép (khung B) 1.c. vectơ chuyển động độ phân giải cao
2. Mã hóa nội bộ - DCT (+ IDCT)
3. Qunatization - và lựa chọn chế độ mã hóa
4. VLC - mã hóa chiều dài thay đổi. (CABAC trong H.264)
5. Dự đoán đồng hiệu quả [Trong mpeg2 chỉ dự đoán DC- MPEG4 có nhiều hơn]

Trong lớp thuật toán MPEG, mã hóa và VLC dựa trên DCT trở nên bắt buộc khá nhiều mà không có nhiều sự lựa chọn - nhưng phần còn lại của tất cả các cơ chế là rất cần thiết

Ví dụ: Ước tính chuyển động và bù chuyển động là một trong những yếu tố tiêu thụ MIPS cao nhất. Nếu bạn không có tài nguyên để thực hiện việc này - bạn chỉ có thể mã hóa tất cả các khung như khung I (điều này làm cho nó khá giống với MJPEG - nhưng bộ giải mã MPEG tiêu chuẩn có thể giải mã điều này). Nếu bạn có thể chi trả nhiều tài nguyên hơn một chút - bạn có thể thực hiện bù chuyển động tầm thường bằng cách sử dụng Chênh lệch khung hình - thay vì gửi mọi khung hình như Intra, bạn có thể trừ mọi blcok khỏi khối khung trước đó; nếu chênh lệch cao hơn tín hiệu ban đầu, hãy gửi nó dưới dạng Intra.

Tất nhiên - tất cả điều này có nghĩa là bạn sẽ mất đi một số hiệu quả được hứa hẹn bởi bộ mã hóa ở trên - nhưng tôi nghĩ bạn sẵn sàng từ bỏ điều đó!

EDIT:
Bạn có thể xem các codec sau đây là điểm tham chiếu tốt:

1. MSSG: http://www.mpeg.org/MPEG/video/mssg-free-mpeg-software.html
   Tốt để hiểu nhưng có thể là chậm nhất trên thế giới.

2. FFMPEG: http://ffmpeg.org/ Có lẽ là nhanh nhất trên trái đất. Tốt để bắt đầu như hộp đen nhưng đừng cố thay đổi mã từ bên trong. Có thể cung cấp cho bạn các tùy chọn tốt để kiểm soát nội dung khi bạn sử dụng API thư viện. Nó đã được chuyển sang nhiều nền tảng - nhưng thực hiện nó trên một nền tảng mới có thể là một số nhiệm vụ.

3. FAME: http://fame.sourceforge.net/ Điều này ban đầu được bắt đầu với mục đích giống như bạn mô tả. Mặc dù, tôi hơi mất liên lạc với điều này - nhưng bạn có thể thử nó.

4. Xvid: http://www.xvid.org/ Đây là MPEG-4. Đây là một trong những sự cân bằng tốt nhất giữa mã sạch và tốc độ hợp lý. Nên dễ dàng nhất để làm việc với nếu bạn kết thúc ở bên trong bộ mã hóa.

5. JPEG: http://www.ijg.org/ Đây là JPEG. Đây là một trong những thư viện tốt nhất để chuyển nó trên các nền tảng. Ngoài ra, JPEG vốn đã đơn giản hơn một số khía cạnh của MPEG - vì vậy có thể bạn nên thử điều này trước. Hầu hết các máy ảnh trên thế giới có lẽ đã sử dụng thư viện này - thay vì tạo ra thứ gì đó của riêng nó!

Có thể tôi sai khi sử dụng MPEG! Nhưng đó là một loại rủi ro đáng để chấp nhận.

Có lẽ biện pháp tốt nhất để kiểm tra xem điều đó có hiệu quả hay không - chỉ cần thử lấy một DCT tiêu chuẩn 8x8 với lượng tử hóa trên hình ảnh của bạn; tối ưu hóa chỉ này. Nếu bạn có thể đạt được gần với yêu cầu thời gian thực của mình, tôi nghĩ bạn nên làm tất cả các khung hình JPEG hoặc tất cả các khung hình MPEG của tôi. Nếu bạn đang rời khỏi mục tiêu - hơn là không đáng.

Vấn đề đầu tiên của bạn là bộ nhớ - ngay cả phiên bản lớn nhất của bộ xử lý đó cũng không có nhiều SRAM bên trong (về mặt video - đó là bộ xử lý nhúng đáng kinh ngạc so với nhiều người!) - khung hình VGA là 300kB, so với 100ishkB trong bộ xử lý . Điều đó có nghĩa là bạn sẽ phải xử lý nó khi nó xuất hiện - nói theo 8 hoặc 16 dòng, điều này làm cho vấn đề trở nên khó khăn hơn nhiều vì thời hạn thực sự ít bị chậm lại.

Không rõ bạn sẽ thu thập dữ liệu như thế nào, nhưng tôi cho rằng bạn sẽ có một số loại DMA từ ADC hoặc một số cổng kỹ thuật số, nếu không bạn sẽ dành một nửa thời gian để xáo trộn dữ liệu!

Nhằm mục đích cho các tỷ lệ nén thấp, bạn có thể chỉ muốn xem xét việc mã hóa các vùng đồng bằng giữa các pixel dọc theo một dòng hoặc một hình vuông 3x3 và sau đó mã số hóa chúng.

Xem thêm Đơn giản, phát trực tuyến, nén hình ảnh không mất dữ liệu - mặc dù tôi đã yêu cầu nén không mất dữ liệu rõ ràng, có thể có một số ý tưởng cho bạn ở đó.

Là một cơ sở dữ liệu, một trong những đồng nghiệp của tôi đã thực hiện nén JPG đơn sắc 320x240 8 bit trong một micro 32 bit 32 MHz với đơn vị điểm nổi và bộ đệm nhỏ. Ông đã sử dụng một số mã tham chiếu (nghĩa là tối ưu hóa cho khả năng đọc, không phải hiệu suất) và có 5 khung hình / giây khá dễ dàng. Tỷ số nén là theo thứ tự của 10x IIRC. Việc chụp ảnh được thực hiện bằng bus phần cứng bên ngoài - làm chủ dữ liệu vào RAM ngoài của micro.