Dekodowanie plików JPEG na mikrokontrolerze

[atlantis86]

Szukam jakiejś biblioteki, która pozwoliłaby na w miarę szybkie dekodowanie plików JPEG, a jednocześnie była prosta w implementacji. Preferuję coś napisanego w czystym C, w oderwaniu od warstwy sprzętowej (a więc bez wstawek asemblerowych czy odwołań do rejestrów konkretnego układu), dzięki czemu mógłbym taki kod w miarę prosto przenosić np. pomiędzy PIC32, STM32, ESP32 czy RPi Pico.

Na chwilę obecną dekodowane pliki będą bardzo lekkie - kilkadziesiąt na kilkadziesiąt pikseli, w skali szarości. Ponieważ jednak planuję eksperymentować z odtwarzaniem wideo skompresowanego MJPEG byłoby dobrze, gdyby w ciągu sekundy dało się przetworzyć przynajmniej kilkanaście takich klatek, na 32-bitowym układzie taktowanym z prędkością co najmniej 80-100 MHz.

Jest jakaś warta polecenia biblioteka, która byłaby sobie w stanie z tym poradzić?

[H1M4W4R1]

LibJPEG
OpenJPEG

O MJPEG - nie jest standaryzowany, więc nie wiadomo jak są rozdzielone pliki w strumieniu 😉  Musiałbyś to sprawdzić jakimś edytorem hexów; spróbować samodzielnie rozdzielić strumień na pliki.

Zastanawiam się tylko czy wystarczy Ci mocy obliczeniowej... 😄 100MHz to jednak dość mało... Tutaj najprawdopodobniej najlepiej byłoby zacząć od RPi Pico, ale to tylko moja opinia..., ale patrząc na to, że to mały obrazek to raczej da radę wyciągnąć sporo klatek 😉 

Edytowano Luty 16, 2021 przez H1M4W4R1

[deshipu]

Ostatnio znajomy trochę przysiadł i zopytmalizował biblioteki do jpeg i gif: https://github.com/bitbank2/JPEGDEC

[atlantis86]

4 godziny temu, H1M4W4R1 napisał:

LibJPEG
OpenJPEG

Na te biblioteki już trafiłem przeglądając wyniki wyrzucone przez Google'a. Tę pierwszą można też chyba wyklikać w STM32CubeMX.

Czy są gdzieś dostępne materiały wyjaśniające jak dodać bibliotekę do projektu pod mikrokontroler? Bo z tego co widzę, to paczki do ściągnięcia ze stron projektu są przystosowane raczej do kompilacji na PC. Jest może coś "embedded friendly", podobnego np. do "FatFS-a"?

Cytat

Zastanawiam się tylko czy wystarczy Ci mocy obliczeniowej... 😄 100MHz to jednak dość mało... Tutaj najprawdopodobniej najlepiej byłoby zacząć od RPi Pico, ale to tylko moja opinia..., ale patrząc na to, że to mały obrazek to raczej da radę wyciągnąć sporo klatek 😉 

Raspberry PI Pico chyba wcale aż tak bardzo nie wyprzedza innych układów, które biorę pod uwagę:

• PIC32MX795F512L to jednak ciągle całkiem wydajny układ MIPS, taktowany 80 MHz.
• Popularne STM32F1 to 72 MHz. W przypadku serii STM32F4 taktownie może mocno przekraczać 100 MHz, a do tego dochodzą takie udogodnienia jak FPU. 🙂
• ESP32 to dwa rdzenie i taktowanie nawet 240 MHz.

Poza tym, mówimy tutaj o dekodowaniu miniaturek o rozmiarze znaczka pocztowego w skali szarości (w sumie wystarczy bajt na piksel). To raczej nie powinno być problemem. Pamiętam jak niecałe 20 lat temu używałem kodeka MJPEG przy nagrywaniu materiałów z karty telewizyjnej. Był to właściwie jedyny kodek, z którym ówczesny sprzęt radził sobie w czasie rzeczywistym. Skoro Duron 700 był wtedy w stanie zakodować w ciągu sekundy 25 klatek 640x480 w kolorze, to w miarę współczesny MCU powinien dać sobie radę ze zdekodowaniem kilkunastu szarych klatek np. 64x32. Tym bardziej, że nie będzie musiał jednocześnie obsługiwać systemu operacyjnego.

Ale jeśli budzi to wasze wątpliwości, to jaki algorytm kompresji waszym zdaniem powinienem rozważyć? W najgorszym razie oczywiście mogę sobie pozwolić na zupełne zrezygnowanie z kompresji - karty SD są dostatecznie duże i szybkie (nawet w trynie SPI), ale zwyczajnie wolałbym zaoszczędzić trochę miejsc.

Edytowano Luty 16, 2021 przez atlantis86

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[kaworu]

Dnia 16.02.2021 o 14:49, H1M4W4R1 napisał:

Zastanawiam się tylko czy wystarczy Ci mocy obliczeniowej... 😄 100MHz to jednak dość mało... Tutaj najprawdopodobniej najlepiej byłoby zacząć od RPi Pico,

Rrrrajt. Rdzeń RPi @133MHz ma wydajność mniej więcej STM32F1/F4 @90MHz (lub F7 @60MHz).

[H1M4W4R1]

3 godziny temu, kaworu napisał:

Rrrrajt. Rdzeń RPi @133MHz ma wydajność mniej więcej STM32F1/F4 @90MHz (lub F7 @60MHz).

Tylko pamiętaj, że RPi ma 2 rdzenie, co jest znaczącą przewagą jeżeli umiesz to wykorzystać 😉 - może i są wolniejsze, ale za to przetwarzanie równoległe daje im znacznie lepszą wydajność. Teraz powiedz, którego STM32 znajdziesz w podobnej cenie z dwoma rdzeniami albo wydajnością >= 2.2*<rdzeń RPi>... (budżet: 19.90 PLN (razem z wszystkimi komp. pasywnymi); 1 unit price). Jedynie ESP siedzi w podobnym przedziale cenowym, z tym, że ESP ma parę zbędnych rzeczy, które trochę prądu ciągną, nawet jak je wyłączysz...

[ethanak]

12 minut temu, H1M4W4R1 napisał:

ESP ma parę zbędnych rzeczy, które trochę prądu ciągną, nawet jak je wyłączysz...

Już chyba wspominałem, że pobór prądu jest podobny dla ESP i RPi? Przy okazji: wyjaśnij które to rzeczy niepotrzebne ciągną prąd jak się je wyłączy.

 

[kaworu]

1 minutę temu, H1M4W4R1 napisał:

Tylko pamiętaj, że RPi ma 2 rdzenie, co jest znaczącą przewagą jeżeli umiesz to wykorzystać

Tak, ale wykorzystać będzie ciężko używając bibliotek, które nie mają wsparcia dla wielowątkowości, choć niby można próbować dekodować ramki parzyste/nieparzyste na różnych rdzeniach. Aaaaale... chyba widziałem coś wyżej o przenośności kodu tej biblioteki.

Więc śmiem twierdzić, że one tu nie mają sensu, chyba, że autor zmieni założenia. 😉 Poza tym, nawet gdyby brać na dwa wątki - one razem wciąż są wolniejsze niż jeden wątek na F7 nawet przy tej samej częstotliwości (@133), a te F7 (CM7F) rozpędzają się do 216MHz. Sorry, Pico ma prawie najgorsze rdzenie Cortex jakie w ogóle istnieją, plus pamięć flash jest na QSPI.

I jakby to miał byc już nieprzenośny kod, niektóre STM mają sprzętowy kodek JPEG, tu juz w ogole Pico polegnie.

4 minuty temu, H1M4W4R1 napisał:

Jedynie ESP siedzi w podobnym przedziale cenowym, z tym, że ESP ma parę zbędnych rzeczy, które trochę prądu ciągną, nawet jak je wyłączysz...

A to ma być energooszczędne rozwiązanie? Bo może mi umknęło.

[atlantis86]

Ok, na razie udało mi się znaleźć coś takiego. Kompiluje się bez problemu pod RPi Pico, bez konieczności wprowadzania żadnych zmian do kodu. Zobaczymy czy i jak działa. 🙂

https://github.com/richgel999/picojpeg

[atlantis86]

Ok, pierwsze testy biblioteki PicoJPEG są bardzo obiecujące. Na RaspberryPi Pico pojedynczy plik 64x32 w skali szarości dekoduje się w jakieś 8-9 ms. W rzeczywistości będzie trochę więcej, bo kod nie uwzględnia jeszcze przepisywania zdekodowanych danych do bufora na bitmapę, ale tutaj różnica będzie minimalna. Ponieważ zadowoli mnie kilkanaście klatek na sekundę, pozostaje naprawdę sporo  czasu na pozostałe zadania - nawet jeśli uwzględni się wyłuskiwanie ramek JPEG z pliku AVI zakodowanego MJPEG czy jakieś dekodowanie audio. A mam przecież jeszcze drugi rdzeń i PIO do pomocy. 😉

Swoją drogą, ktoś mógłby mnie odesłać do jakichś materiałów tłumaczących w jaki sposób dobrać się do klatek JPEG zapisanych w pliku AVI/MJPEG?

[ethanak]

Co do MJPEG może to pomoże: https://gist.github.com/russss/1143799

Nie bardzo rozumiem o co chodzi z tym AVI - masz MJPEG zaszyty w AVI i chcesz go wyciągnąć?

[atlantis86]

10 minut temu, ethanak napisał:

Nie bardzo rozumiem o co chodzi z tym AVI - masz MJPEG zaszyty w AVI i chcesz go wyciągnąć?

Jeśli byłaby taka możliwość, to tak. AVI to format kontenera do przechowywania strumieni multimedialnych, MJPEG to format bardzo lekkiego kodeka wideo w którym każda klatka jest obrazkiem JPEG. Gdyby udało mi się dobrać do tych danych z poziomu mikrokontrolera, ułatwiłoby mi to bardzo mocno przygotowywanie treści, bo są to formaty obsługiwane przez popularne programy do kompresji wideo.

[ethanak]

OK - pytanie było kontrolne 🙂

Cóż - AVI to zwykły RIFF, czyli bez problemu powinieneś wyciągnąć klocki odpowiadające strumieniowi video. Jak masz duszę eksperymentatora to sobie sam znajdziesz jak te klocki są oznaczone, a jak nie to pewnie gdzieś w sieci jest to opisane 🙂

[atlantis86]

To może jeszcze przy okazji zapytam: istnieje jakaś prosta w implementacji biblioteka do dekodowania MP3, którą też mógłbym przetestować na RPi Pico?

[ethanak]

Nie wnikałem w szczegóły (użyłem, działa i nie zaglądałem do kodu) ale zerknij do źródeł ESP8266Audio, konkretnie do libmad. Jeśli działa na ESP8266 to tym bardziej powinno działać na Pico.