Mpeg data formatını TFT lcd de göstermek

[XX_CİHAN_XX]

8 bit paralel data olarak gelen bir MPEG yayın var. STM32F4 ile bu MPEG stream datalarını gerçek zamanlı olarak 3.2'' Lcd de oynatmak istiyorum. MPEG decoder kullanmadan bu işi nasıl yaparım. Bu konuda faydalanabileceğim bir kaynak yada yöntem var mıdır?

[chorckbey]

[fatih6761]

Hocam, kısaca ya MPEG decoder kullanacaksınız, ya da MPEG decoder yazacaksınız 

Eğer MPEG formatını öğreneyim sisteme hakim olayım diyorsanız MPEG veri formatı, frame formatı, kosinüs dönüşümleri vs. (ismen hatırladıklarım) üzerine epeyce sayfa karıştırır yaparsınız.
Ama sıkıntı şu ki siz bu işi koca bir pc de değil küçücük mikrodenetleyicide yapmak istiyorsunuz, haliyle işlem gücü kısıtlı. ARM çekirdeğine özgü matematiksel komutları
(SIMD gibi) sıkça kullanarak bir hayli optimize bir kod yazmak zorundasınız. (real time gerekliliğinden dolayı)
He, benim işin matematiğiyle, dosyasıyla, formatıyla bir derdim yok, veriyi alayım ekrana basayım diyorsanız hazır kütüphane aramaya başlayın.
Eğer bulabilirseniz -ki zannetmiyorum ama- hazır olarak cortex-m4f için port edilip derlenmiş kütüphane kullanabileceğiniz gibi başka platformlar için yazılmış
olan kütüphaneleri kaynak kodlarından port edebilirsiniz. Sıfırdan yazmaya göre daha pratik bir işlem olur.

Kötü haber: Gelgelelim ki yazılımsal görüntü işleme (software rendering) durumunda 2-3 küsür gigahertzlik baba işlemciler gigabytelarca ram'le birlikte k*çıkırık bi videoyu oynatırken bile zorlanabiliyorlar.
Bu durumu göz önüne alıp gerekli hesapları yaparak çalışmaya başlayın.
(mesela 168MHz'in ne kadarı decode için ayrılacak, bu sürede AxB çözünürlükte kaç tane frame çözülebilir? bu sayı akıcı bir oynatıma uygun mu?)

Örneğin burada arkadaş MotionJPEG formatıyla 320x240 çözünürlükte 30fps oynatabilmiş
(not 1: 250MHz'e overclock yapmış, ama ne kadar doğru? tartışmak lazım.)
(not 2: MotionJPEG denen format her frame'i alıp jpege dönüştürüp kaydetme durumu. Çözerken de tam tersi her frame için bir jpeg çözüp ekrana basılacak.)
https://www.youtube.com/watch?v=0ETyFmAMFjY

Buradaki arkadaş da 480x272 çözünürlükte 60fps görüntülediğini söylüyor. Ama bir gariplik var sanki.
Arada bi codec olsaydı o çip bu hıza yetişemezdi diye düşünüyorum.
Belki sdcardda film doğrudan ekrana basılabilecek bir formatta saklanıyorsa mantıklı.
https://www.youtube.com/watch?v=0Ld5t39lct4

[XX_CİHAN_XX]

3 sene önceki konu hortlamış Teşekkürler hocam bilgiler için. Bu videoyu daha önce izlemiştim. Bende sd kartta hazır ekrana basılacak türden bilgiler olduğunu düşünüyorum açıkçası. STMF4 ile zor gibi bu iş diye vaz geçtim. Beagle Bone tarzı birşeyle ilerde fırsat olursa deneyeceğim

[fatih6761]

Hakikaten, ilk mesaja bakmayıp ikinci mesajın bugün olduğunu görünce atlamışım hemen
Neyse, arayan için küçük bir kaynak olmuş.

Edit: Hocam, bu arada STM32F4 ile küçük çözünürlük ve düşük framerate'te mümkün gibi görünüyor.

[Gökhan BEKEN]

MPEG'de sonuçta bir sıkıştırma kullanıyor. Bence mpeg çevirmek yerine mjpeg formatını kullanın. Sonuçta jpeg resimleri bmp'ye çeviren kod  internette bolca mevcut.
İstenilen fps değerinde oynatır mı denemek lazım.
Ses olayını nasıl yapacaksınız? DAC'dan kulaklık çıkışı mı alacaksınız, yoksa codec entegresi mi kullanacaksınız?

[fatih6761]

MPEG'de sonuçta bir sıkıştırma kullanıyor. Bence mpeg çevirmek yerine mjpeg formatını kullanın. Sonuçta jpeg resimleri bmp'ye çeviren kod  internette bolca mevcut.
İstenilen fps değerinde oynatır mı denemek lazım.
Ses olayını nasıl yapacaksınız? DAC'dan kulaklık çıkışı mı alacaksınız, yoksa codec entegresi mi kullanacaksınız?

Hocam yanlış bilmiyorsam MPEG de MJPEG den farklı olarak frame'ler arasında da ilişkilendirme var.
Yani MJPEG de basitçe her kare bir fotoğrafmış gibi sıkıştırılırken MPEG de her pixel bir sonraki, iki sonraki, .. n sonraki karede ne olmuş diye bakılıp kodlanıyor.
Bu durumda şöyle bir senaryo ortaya çıkıyor:
- MJPEG de kare sayısı sabit olup farklı kare sayısına ulaşmak (upsampling or downsampling frames) daha fazla işlem gücü gerektiriyor.
- MPEG kareleri art arda incelediğinden durgun (pixellerin değerlerinin zamanla çok değişmediği) görüntülerde  MPEG bariz oranda yüksek bir sıkıştırmaya ulaşmasına rağmen
hareketli görüntülerde önemli sayılabilecek derecede fark yok. Normal çekimlerde de genellikle görüntü hareketli olduğundan denk sayılırlar.
Ancak güvenlik kamerası gibi kayıtlarda görüntü uzun süre hareketsiz kalabilir. Bu durumda MPEG avantajlı.
Hakeza görüntünün küçük bir bölgesinde değişiklik oldu diye tüm kareyi baştan kodlaması MJPEG için bir eksi gibi görünüyor.
- Gömülü sistemler için MJPEG in mantıksal bir avantajı olabiilir, şöyle ki MJPEG için bir kütüphane eklediğinizde muhtemelen bir de JPEG kütüphaneniz olmuş oluyor.
Bir taşla iki kuş.

İlk mesajda da belirttiğim gibi, konunun uzmanı değilim ama bildiklerimi ve okuduklarımı harmanlayarak böyle birkaç satır karaladım.
Eksik/yanlış varsa bilgisi olan hocalarımın müdahelesine açıktır

[Kabil ATICI]

MPEG decode etmek sınırlı kaynaklara sahip sistemin harcı değil. Gerçi çeşitli sıkıştırma derecelerine sahip yapıları var. Örneğih H264 formatındaki bir sıkıştırmada decode/encode etmek için ARM9 seviyesinde 2GB RAM ile birlikte bu iş için geliştirilmiş  decode encode entegresini kullanıyorsun, hatta üzerinde gömülü linux çalışıyor.. (flash tabii sisteme dahil)

örnek;
http://www.mouser.com/ds/2/256/MG2580-MG3500-81196.pdf

bu birkaç yıl önceki hikaye idi, şimdi biraz daha gelişmiş olabilir.

[MC_Skywalker]

Mpeg ve Mjpeg aslınd aynı dır sadece sıkıiştırma algoritmaları farklıdır.
Mpeg1, Mpeg2 ve Mpeg4 video sıkıştırması için kullanılır. Ses sıkıştırmasına mp3 dendiği için daha fazla kafa karıştırmamak için Mpg4 kullanılmıştır.