geekmaster kindle video player

[geekmaster]

Originally Posted by twobob

...
As this is the thread about that (library and it's usage) hope you don't mind some noise.
...
Anyways. apologies for the noise. looked like the best place to tag the refs.

If I get something happening I will let you know.

A little "noise" keeps the thread alive so it does not fade into oblivion. And besides, noobies may discover that a kindle CAN play watchable videos, from this thread that just got bumped to their attention.

A bit of noise is better than a blatant "bump". Your noise is welcome here.

[twobob]

[root@kindle lib]# Xephyr -nolisten tcp -screen 600x800 :1

Backtrace:
Segmentation fault

Helpful. Not.

Nor was the strace...

... blah
28886 read(4, "ARD:SetNamedIndicator\nR017 XKEYB"..., 4096) = 2574
28886 read(4, "", 4096) = 0
28886 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7b39fc} ---
28886 gettimeofday({1353902045, 783127}, NULL) = 0
28886 write(2, "\nBacktrace:\n", 12) = 12
28886 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x52} ---
28886 +++ killed by SIGSEGV +++

Tomorrow...

[waterlubber]

Now this is NICE!!! Here's an idea: make it an Active Content thingy!!! (woot! woot!!!)

[waterlubber]

Wait...how do the videos look? Do you know the frame rate? (I tolerate 15 fps)

[qlob]

fps is 7.7 IIRC... beware that 7.7 looks amazing for eink so don't diss it based on fps

[twobob]

well. you can expect about 7.7, they don't look how you might expect they would at that speed. There are several example videos posted around showing eink video. It's surprisingly good on the 4 and 5's when done right. Even the 3's can do it.

Here's some fun.


And yes. it would be great to make this an extension. it has taken months of work to get here though and TBH it has taken me weeks to begin to integrate this into other things, never mind find a unified audio format and encoding scripts. GM is the man for that, should he ever find the time or inclination but in his absence the demo and code is there.

Interested devs? jump in!

[geekmaster]

Originally Posted by twobob

well. you can expect about 7.7, they don't look how you might expect they would at that speed. There are several example videos posted around showing eink video. It's surprisingly good on the 4 and 5's when done right. Even the 3's can do it.

Here's some fun.


And yes. it would be great to make this an extension. it has taken months of work to get here though and TBH it has taken me weeks to begin to integrate this into other things, never mind find a unified audio format and encoding scripts. GM is the man for that, should he ever find the time or inclination but in his absence the demo and code is there.

Interested devs? jump in!

Not absent. Just busy. I check in here every day...

The Nook Simple Touch already has android built-in, so tons of stuff "just runs" on it. The kindles OTOH require a lot of TLC to get ANYTHING to work on them.

[twobob]

yeah I'm feeling that. : )

finally got to humping some "ioctl(fd,_IO('F', 0xdd), &myarea);"'s all of my very own

Who knows. maybe one day I will understand your code enough to use it : D

The last 6 months has seen HUGE leaps for all the kindles in terms of software and support. The issue is many of the original and even current devs have lives / get bored / move on etc etc : )

ce la vie.

[geekmaster]

Originally Posted by twobob

yeah I'm feeling that. : )

finally got to humping some "ioctl(fd,_IO('F', 0xdd), &myarea);"'s all of my very own

Who knows. maybe one day I will understand your code enough to use it : D

The last 6 months has seen HUGE leaps for all the kindles in terms of software and support. The issue is many of the original and even current devs have lives / get bored / move on etc etc : )

ce la vie.

I think when I get a little time I will make a "human readable" version of my eink code... Because I use logical expressions instead of if-else chains, it makes for complex parsing to understand the formula. But if-else causes branching and possible cache-misses and cache flushing, so is not friendly on modern multi-level cache systems (yes, even the kindle)... Branch-free programming is the ONLY way to go, for maximum speed and minimum energy consumption. Table lookups (the OLD speedup method) are slow on modern processors. CPU is far faster than RAM access. Often better to recompute (especially low-cost differential computations like I use) than even a table lookup. I have studied this stuff a LOT for other projects. For multi-processor apps, I like lock-free queues too. Mutexes suck.

And 5.3.0 is a big reason for devs to move on to "greener pastures" (non-amazon devices).

[stepk]

Originally Posted by geekmaster

Branch-free programming is the ONLY way to go, for maximum speed and minimum energy consumption.

You mean as in this ref http://cellperformance.beyond3d.com/...imination.html?

[geekmaster]

Originally Posted by stepk

You mean as in this ref http://cellperformance.beyond3d.com/...imination.html?

Exactly! Excellent reference. Even with extra execution units performing the unused code branches in parallel, code with branches consumes more power, and even if battery consumption is not of concern, heat generation certainly is. You can see examples in my various eink demos published here.

[twobob]

This was the one I was thinking of.

[knc1]

That video is a good demonstration of what geekmaster reported.
That small areas of the screen can be updated much faster than the entire screen.
That demo is only updating about 1/4 of the screen.

Another interesting point -
That demo is running on one of the TI OMAP processors, the processor family that runs the Kindle Fire product line, not the Kindle e-ink product line.

[twobob]

well. if we are talking about ACTUALLY impressive shit.



now THAT is pretty tidy

(by my calcs. that screen could do full colour with 1.2s updates) SLOW

[geekmaster]

Originally Posted by knc1

That video is a good demonstration of what geekmaster reported.
That small areas of the screen can be updated much faster than the entire screen.
That demo is only updating about 1/4 of the screen.

Another interesting point -
That demo is running on one of the TI OMAP processors, the processor family that runs the Kindle Fire product line, not the Kindle e-ink product line.

But the K4 and K5 have an embedded eink controller in the SoC that can simultaneously do partial updates to 20 non-overlapping areas. And even with a fullscreen update, I successfully did up to 50 frames per second, but it gets horrible artifacts (like grayscale updates) if you go past about 18 FPS.

The K3 uses an external eink controller chip that has a hard limit of 7.7 FPS average (sometimes faster and sometimes slower), because the ioctl() calls do not return until that time. I slowed down all my code for all kindle models to run at the speed limit determined by the K3 firmware, because 7.7 FPS looked "good enough" and allows a consistent experience across platforms (and compresses better than a higher framerate).