Get Ready!



We want you!

Fame, fortune and a trip to Austin, Texas -- not necessarily in that order!

Everything is going in a good direction. Go Zig!

R&B :)

As an added note, have a look:

EFIKA Project #337 has been awarded with one of these:



As you might guess, Highly flexible/ultra low cost framebuffer for the EFIKA and FPGA technologies support is something that Freescale is very interested in supporting. We are about to make some very useful connections. This comes to mind:



We may have not followed a direct route, but what happens next reminds us of a large electrical discharge. Anytime an object gains a net charge, it will try to become more neutral. When there is a great enough difference in the charge between a cloud and its surroundings, the cloud discharges a lightning bolt.

Lightening is about to strike. We can feel the POWER. :)

Do your best.

R&B :)

Hi.

Good job Noel!
Hopefully there will be many more success stories like that.


Best regards,
Johan

Please update your EFIKA Project blog! 8)

Many thanks to bbrv, Genesi & Freescale.

Special thanks also to Johan for his donation and hardware support. ;-)

Stellae

Noel, you're welcome :-)

Here is an update about qualifying as a Freescale Selected Demo. The first major focus is on a MobileTV device. The primary device features: view television programming via the net, view stored video (e.g., memory stick, etc.) and video conferencing. The secondary device features: picture viewer, music player, web browsing and email.

1. We need to use the cellular network, but WIFI connectivity needs to be possible. We will build in a SIM card. Authentication, authorization and accounting (billing) make this device different than a normal computer. This can be promoted and sold on a subscription basis.

2. Codecs require computing resources and increase power requirements. We want most of the compression burden to stay with the service provider. We are thinking JPEG2000 or something similar that can be scaled to the bandwidth and computing power available.

3. The content is transcoded at the head-end to the media format required that has been optimized for the client. The client decodes and views the content.

The target is a seven inch screen as seen and discussed here: http://portable.powerdeveloper.org/

It seems certain that this EFIKA Project proves to be one of the key ingredients of this effort:

http://projects.powerdeveloper.org/project/efika/163

R&B :)

2. Codecs require computing resources and increase power requirements. We want most of the compression burden to stay with the service provider. We are thinking JPEG2000 or something similar that can be scaled to the bandwidth and computing power available.

If I've understanded well, this JPEG2000 is to be transmitted via cellphone network channel to the Efika? While decoding stream of JPEG2000 frames can be done on Efika in realtime, I'm affraid the transmission will require just too much bandwidth. Let's assume 352 x 288 @ 25 fps stream. One RGB frame of it is 304128 bytes. If we compress it with JPEG2000 to 5% of its size (at significant quality loss), then we need 3 Mbit/s to transfer the stream.

In my opinion choosing MPEG-1 codec would be better. While it is not as advanced as JPEG2000 with frame compression, it can exploit inter-frame redundancy effectively. Decoder computational complexity is relatively low. With nowadays encoders we can achieve acceptable quality with 1,2 Mbit/s stream (for the same parameters as above). It will also double video storage capacity (for 2 GB flash memory and 1,5 Mbit/s (with sound) we get 3 hours of program).

@bbrv

Remember when talking today about enthusiastic people waiting for MorphOS and about the fact that even normal users can do much for an OS and when I told you about Carsten Siegner, his VCR case and the ideas he came up in the past.

Well, once again he came up with a solution which is quite easy.

He found out that latest MPlayer is already capable of playing network streams like tv broadcasts. :D

Just tested and it works.

MorphOS: Be prepared to be surprised! :D

Geit

geit

Sounds exciting! How about some pics? :)

Why not just use MPEG-4 Simple Profile or 3GPP?

Well, it looks like playing a normal video stream from hard disk. Here is a picture of playing the official NASA-TV stream.

Sorry that the window is so small, but for grabbing I had to turn off overlay. I also didn't used the Efika to make this shot, but
it works there exactly like this.

http://www.geit.de/images/genesi/mplaystream.jpg

http://playlist.yahoo.com/makeplaylist.dll?id=1369080&segment=149773

Geit

You can of course. But CPU usage will be much higher.

If that's pretty much all it's doing, does it matter?

The basic point of a device like this, is not that it will be multitasking, doing a POVray render and folding proteins while streaming. Each task is independant but not running at the same time. You will not be watching stored content AND streamed content AND video conferencing at the same time.

As Bill noted; the burden is on the service provider to give an adequately coded stream for the client. RTSP handles this just fine by scaling content, MPEG-4 can change the macroblock size to something huge or discard hpel/qpel information.. quality suffers but consistency of framerate is preserved. People notice held frames and broken audio much more than they do a legobricking effect for a 25th of a second..

The Efika can easily handle decoding MPEG-4 video at low resolutions and bitrates (at least QVGA, possibly higher).

Video conferencing may be a different story, but video conferencing does not necessarily entail such complex scenes (usually a static background and a fairly static subject) and there are specially designed video codecs for this (perhaps H.262 or H.263).