geekmaster kindle video player

[geekmaster]

The first post now has a good selection of videos to watch.

The video file sizes are up to 10 times smaller than the originals that they were encoded from. The motion is smoother with fewer visible artifacts than I expected. Only the "Living FPV 2" video has had spatiotemporal smoothing applied as recommented in the "Geek tech" notes inside the spoiler, and yet the others are also quite comfortably viewable.

Even on a DX and DXG they are nice (although a little like watching a "comic book").

[hawhill]

Now I found time to finally play with it a bit. It's actually great to see the display spitting out images at that pace. It shows the capabilities of the display quite well. Here on a K3, it spends most of its CPU time in kernel space, probably chewing within the einkfb driver.

Makes me really want to port ScummVM... Also it would be a good fit for a prdoom clone based on this. Yes I know that there has been a grayscale based port.

The hard part about audio would be syncing video and audio. OTOH, audio output might provide a cheap approach towards a timing source one could re-use for the video output, too.

Did you test LZO compression? Might be easier on the CPU, plus your program could implement it itself and decompress directly to the framebuffer, saving a copy. Compression ratio will probably be worse, though.

[silver18]

Originally Posted by hawhill

Makes me really want to port ScummVM...

Welcome Monkey Island!!

[geekmaster]

Originally Posted by hawhill

Did you test LZO compression? Might be easier on the CPU, plus your program could implement it itself and decompress directly to the framebuffer, saving a copy. Compression ratio will probably be worse, though.

I have some really fast LZW compression in other code on my kindle. For now I am relying on gzip and gunzip in the execution pipeline to handle compression for me. I tried zip/unzip but the files were actually a bit smaller with gzip/gunzip, and you do not need the extra "-p" parameter unzip needs.

My goal is always to get maximum performance from minimum lines of code, which is part of why I (and others) dislike whitespace so much.

I have been doing this since the days when business computers only had 4KB (yes kilobytes) of memory. One of the first hard drives I worked with was the size of a commercial laundry washing machine and could store an entire 512KB (half megabyte) on those big heavy disk packs.

The mind-boggling waste in modern code (just because you CAN) really astounds me. I lean the other direction.

Anyway, I had to go through a lot of iterations of stepwise-refinement to get this level of consistent performance from small code that works on all eink kindles, and I know of several ways to make major improvements in speed and performance (later). I work in baby-steps of small improvements that build upon each other.

The point is -- I like to push things was beyond what most people think is even possible. The eink Doom video on youtube (running on a different eink device) was only about 4 FPS, and I am doing nearly twice that even on a K3 (and I have seen my K5 go up to almost 40 FPS with carefully designed video content). Because eink persistence allows lower framerates, which allow more video compression (frame dropping), I have standardized on K3-speeds even for the newer kindles. The K4main "hybrid" video driver (K5 hardware using K3 driver by HAL translation) drops far more frames than the K3. K4diags has MUCH better animation support.

Anyway, to some my code may appear incomprehensible "write-only" code, but for my purposes being able to see more code without scrolling allows ME to comprehend more of it at the same time. Scrolling limits my thought processes while absorbing code. And people can always run my C code through AStyle to read it anyway...

[geekmaster]

Originally Posted by hawhill

Here on a K3, it spends most of its CPU time in kernel space, probably chewing within the einkfb driver.

We can probably fix that a bit. I am using "automatic update" mode where the driver needs to analyze and compare successive screens to see what changed and to decide what update method to use. We can control that by TELLING the driver what mode to use. That would probably save significant kernel processing time. Also, for video games, you can tell it to update a small region (within your known "dirty rectangle"), but for videos like this, there are usually changes all over the screen, preventing that option.

[geekmaster]

Originally Posted by hawhill

It's actually great to see the display spitting out images at that pace.

The pace is a lot lower than it looks. My research shows that although light-emitting displays (CRTs, LCDs, etc.) need a minimum of 15 FPS to prevent severe flicker, a reflective display such as eink can get by with half that speed (depending on ambient lighting conditions).

I want to do an "angry birds" type game. Moving objects cannot have many details. The bouncing ball is about the limit of detail you can use. So perhaps "angry balls" ???

[geekmaster]

Originally Posted by silver18

Welcome Monkey Island!!

First post now contains "Tales of Monkey Island" trailer.

[PoP]

Truly impressive achievement! After watching all videos from post#1, I still prefer gmvid.gmv, the synthetic one which gives you full credit .

By the way, which steps do you take to convert to .gmv format?

I call gmplay from the desktop with something like

ssh root@kindle "zcat | /mnt/us/gmplay" < c:\video.gmv.gz

so that I don't need to store the large video file on the Kindle.

Makes me thinking (since you mentioned the video surveillance application) the desktop could handle all the dirty work of recoding the camera output, compressing and piping the stream to an ssh session.

Very nice. Thanks for generously sharing again.

[hawhill]

PoP: I was also playing with that approach but found that my K3 will need ~15-20% CPU for SSH encryption in that case. So I switched to using netcat, i.e. raw tcp transfer.

# zcat the-vid.gmv.gz | netcat -l -p 5555
on the Desktop and

# netcat 192.168.2.1 5555 | ./gmplay
on the K3.

USB connection is fast enough for transmitting uncompressed video data.

-hwh

[geekmaster]

Originally Posted by PoP

By the way, which steps do you take to convert to .gmv format?

I call gmplay from the desktop with something like

ssh root@kindle "zcat | /mnt/us/gmplay" < c:\video.gmv.gz

so that I don't need to store the large video file on the Kindle.

the desktop could handle all the dirty work of recoding the camera output, compressing and piping the stream to an ssh session.

My desktop PC has been very busy encoding video. My encoder runs on the kindle, but somewhat more slowly. When ONLY encoding, it is much faster to compute the dither thresholds than to look them up in a table, but in a filter pipeline, the CPU slows to a crawl. Perhaps my filter version (STDIN->STDOUT) needs the dither lookup table... At this time it computes the dither threshold in the same logical expression that does the pixel packing (8 dithered pixels/bit).

I am using mplayer to convert video to a folder full of TGA files, then I wrote a "sequentially number TGA" to raw framebuffer sequence filter, which I pipe to my raw2gmv filter, which I pipe to gzip. That pipe has enough processes to bog down my quadcore PC.

To play (as shown in the first post since the beginning), I use "zcat gmvid.gmv.gz|./gmplay", to which I often add " &" so I can uplug it while it is playing video. I also used "nc" in the pipeline for remote video, but your method is simpler (I like simpler).

[geekmaster]

Originally Posted by hawhill

PoP: I was also playing with that approach but found that my K3 will need ~15-20% CPU for SSH encryption in that case. So I switched to using netcat, i.e. raw tcp transfer.

# zcat the-vid.gmv.gz | netcat -l -p 5555
on the Desktop and

# netcat 192.168.2.1 5555 | ./gmplay
on the K3.

USB connection is fast enough for transmitting uncompressed video data.

-hwh

As I mentioned in my reply to PoP, I started with netcat. His approach is simpler, but I see from your post that it adds encryption overhead. I put netcat earlier in the pipeline though to send compressed data over USB:

host pc: # cat the-vid.gmv.gz|nc -l 5555

kindle: # nc 192.168.2.1 5555|zcat|./gmplay

[geekmaster]

Originally Posted by PoP

... After watching all videos from post#1 ....

Now there is another one (Sand Art), so your job is not complete!

[geekmaster]

Originally Posted by hawhill

PoP: I was also playing with that approach but found that my K3 will need ~15-20% CPU for SSH encryption in that case. So I switched to using netcat, i.e. raw tcp transfer.

Or instead of netcat, we could switch to wget and play them directly off a web server. Just pipe wget to zcat to gmplay.

The gzipped bit-packed pre-dithered compression rate is so high that an 800x600 video consumes less than 1Mbps, so a typical broadband internet connection could stream these videos to the kindles just fine.

[geekmaster]

I spent significant time talking to "deep techs" at amazon about the broken eink header file issue (you cannot use the eink header files if you want application programs to run on both 5.0.x and 5.1.x firmware). My solution was to copy the structures and rename the one that is "broken", so I can use both structures needed to support different firmware MINOR versions.

They say they will "get back to me in a couple of days" (exactly what they said when I wanted more than just verbal approval to distribute partition images with my debricking solution -- but their legal staff never did get back to me with written permission).

We shall see... Meanwhile, I stopped using eink header files, as you can see in my gmplay source code. The structures add a significant number of lines of code to my program even though I compressed them.

[geekmaster]

Films with action sequences get choppy because I am converting framerates by dropping frames (keeping only one out of 3 frames), resulting in fast motions missing too many "in-between" frames to follow the action. Perhaps I should average the 3 frames together instead of dropping 2 of them, which would cause more "ghosting" but would help with high-motion sequences. Or perhaps the code could detect high action objects and only blend stuff that moves "too much". It all adds to the code and takes time, but increases realism. Like everything else, it is just a matter of time (and few productive people have enough of that to spare).