Roku Developer Program

Developers and content creators—a complete solution for growing an audience directly.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Level 7

Re: BuhByteArray

"squirreltown" wrote:

Also I tried using base64 and it was NOT a help, it consistently took maybe 15% longer to send the string on my test image. It would make sense since the hex string always uses 8 characters to describe a pixel, the base64 sometimes uses only 4, but more often than not uses 10.


That doesn't make sense to me. One pixel is four bytes, which should always convert to 5.33+ chars in base 64. It doesn't depend on the value of the bytes. However note that belltown's code doesn't use either hex or base64, it sends the raw unencoded bytes.

--Mark
0 Kudos
Highlighted
Level 9

Re: BuhByteArray

"RokuMarkn" wrote:
That doesn't make sense to me. One pixel is four bytes, which should always convert to 5.33+ chars in base 64. It doesn't depend on the value of the bytes. However note that belltown's code doesn't use either hex or base64, it sends the raw unencoded bytes.

--Mark

Sorry my mistake, yes I'm using belltown's code and sending unencoded bytes, but as i said that takes less time, every time, then converting that to a base64 string.
here is a snippet of base64 from the console
BUJC/wxISP+FkpL/hJKS/4WTk/+GlJT/hpOT/4aUlP+Gk5P/hZOT/4WSkv+Fk5P/hZOT/4WTk/+FkpL/hJKS/4SSkv+FlJ"...
unless i'm wrong that the slashes delineate the pixels there are as many as 10 characters per pixel. If I'm wrong about that i can still read a watch and it's not close - the unencoded string takes less time to send.
Kinetics Screensavers
0 Kudos
Highlighted
Level 8

Re: BuhByteArray

"squirreltown" wrote:
I tried using base64 and it was NOT a help, it consistently took maybe 15% longer to send the string on my test image. It would make sense since the hex string always uses 8 characters to describe a pixel, the base64 sometimes uses only 4, but more often than not uses 10.

You're right. I don't know what I was thinking when I used it earlier. I was getting binary and character data mixed up in my brain in another solution I was playing around with (not the one I posted). [I wasn't sure the Roku and the server would be able to handle POSTing a big chunk of binary data with an Http Content-Type of application/x-www-form-urlencoded, but apparently they can].

It might have helped in your earlier attempt where it looked like you were representing a 32-bit color in its hex form as ASCII characters: "FF0000FF", which would take up 8 x 8 = 64 bits, versus encoding the 32-bit value in Base-64, which would take 32 / 6 x 8 = 42.66666 bits. However, now that you're using straight binary data, you're only using 32 bits per pixel, so no need to encode.

What might help though would be to use some kind of compression algorithm at the Roku end, replacing groups of the same pixel value with a pixel value and a count, for example. If your images have repeating colors you may be able to end up transferring much less data, which is where your bottleneck is likely to be.
https://github.com/belltown/
0 Kudos
Highlighted
Level 7

Re: BuhByteArray

"squirreltown" wrote:

here is a snippet of base64 from the console
BUJC/wxISP+FkpL/hJKS/4WTk/+GlJT/hpOT/4aUlP+Gk5P/hZOT/4WSkv+Fk5P/hZOT/4WTk/+FkpL/hJKS/4SSkv+FlJ"...
unless i'm wrong that the slashes delineate the pixels there are as many as 10 characters per pixel. If I'm wrong about that i can still read a watch and it's not close - the unencoded string takes less time to send.


No, the slashes don't divide pixels. The slash is just one of the 64 characters used in the encoding. Base64 converts every 3 bytes of data to 4 printable characters, using the chars a-z, A-Z, 0-9, + and /. Wikipedia has a reasonable description. belltown's code does no encoding, so it sends only 3/4 of the data that base64 sends.

--Mark
0 Kudos
Highlighted
Level 9

Re: BuhByteArray

"RokuMarkn" wrote:
so it sends only 3/4 of the data that base64 sends.

--Mark


The times I got would back that up completely. I suspected the slashes were just MacGuffins, so good to know.
Kinetics Screensavers
0 Kudos
Highlighted
Roku Employee
Roku Employee

Re: BuhByteArray

"TheEndless" wrote:
"squirreltown" wrote:
Either way if Roku would like to add the ability to at least URLtransfer a bitmap thats - you know - already created - i won't stop them.

I'd prefer, and have requested multiple times, the ability to create a PNG on the device from an roBitmap. The libraries are already there, so it shouldn't require a major update, but to date, it doesn't seem to have gained any traction.


Feature request noted.
0 Kudos