[App] libAmbiLight E/F/H (MST-only)

[aimaim]

samyGOso -d -T -B -l /mnt/opt/privateer/usr/libso/libAmbiLight.so H_LEDS:36 V_LEDS:18 SERVER_IP:192.168.1.32 SERVER_PORT:5050 OFFSET:17 REVERSE TEST ALT
--> tv (UE55F6770) freezes
--> AmbiLight1.log

samyGOso -d -A -B -l /mnt/opt/privateer/usr/libso/libAmbiLight.so H_LEDS:36 V_LEDS:18 SERVER_IP:192.168.1.32 SERVER_PORT:5050 OFFSET:17 REVERSE TEST ALT
--> tv (UE55F6770) does not freeze
--> AmbiLight2.log
--> Colors in Log seem very strange

samyGOso -d -T -B -l /mnt/opt/privateer/usr/libso/libAmbiLight.so H_LEDS:36 V_LEDS:18 SERVER_IP:192.168.1.32 SERVER_PORT:5050 OFFSET:17 REVERSE TEST
--> tv (UE55F6770) does not freeze
--> AmbiLight3.log
--> Colors in log seem to be a little off, assuming the codes are rgb

samyGOso -d -A -B -l /mnt/opt/privateer/usr/libso/libAmbiLight.so H_LEDS:36 V_LEDS:18 SERVER_IP:192.168.1.32 SERVER_PORT:5050 OFFSET:17 REVERSE TEST
--> tv (UE55F6770) does not freeze
--> AmbiLight4.log
--> Colors in log seem to be a little off, assuming the codes are rgb

What do the parameters "-d -T -B -l" / "-d -A -B -l" do? I've read about this many moons ago, but I cannot seem to find it anymore.

According to my test results I could run the normal version, right? I did not order the led-strip etc. yet, but if I read this correctly I could now, couldn't I? Looking at the log I noticed, that the colors are little bit off, hm...

There was no need to actually configure a fastled server to run this test right?

Sorry for the noob questions.


Thanks for this great project! Can't wait to pimp my tv

[adonis]

samyGOso -d -T -B -l /mnt/opt/privateer/usr/libso/libAmbiLight.so H_LEDS:36 V_LEDS:18 SERVER_IP:192.168.1.32 SERVER_PORT:5050 OFFSET:17 REVERSE TEST
--> tv (UE55F6770) does not freeze
--> AmbiLight3.log
--> Colors in log seem to be a little off, assuming the codes are rgb

I looked at your output, and this looks good.
Strange how your F-Model works with the same code as all other H-models, whereas other F-models don't.
The color arrangement is due to REVERSE and OFFSET, playing with these values should get your LED strip right

[Mubis]

F6-MST12 H6-MST14 F7,F8-GFS
libAmbilight likes microstar chipset

[bobiturboto]

samyGOso -d -T -B -l /mnt/opt/privateer/usr/libso/libAmbiLight.so H_LEDS:36 V_LEDS:18 SERVER_IP:192.168.1.32 SERVER_PORT:5050 OFFSET:17 REVERSE TEST
--> tv (UE55F6770) does not freeze
--> AmbiLight3.log
--> Colors in log seem to be a little off, assuming the codes are rgb

I looked at your output, and this looks good.
Strange how your F-Model works with the same code as all other H-models, whereas other F-models don't.
The color arrangement is due to REVERSE and OFFSET, playing with these values should get your LED strip right

F6770 is MST, F7000, 8000, 9000 are non MST they are with different hardware and more or less software.
Probably that is the thing

As Mubis answered before me.

[adonis]

Thank you Mubis and aimaim for the detailed testing... Your logs helped me a lot and I could run ALT method with "-d -A -B -l".

I hoped, that the ALT method would return RAW data, but it doesn't.
So my, next thing was to try to convert the ALT-data to JPEG with CRMSJPEGProc_EncodeARGB8888toJpegMem and then implement the jpge-encoder with libjpeg, as hinted by WarLLe: https://gist.github.com/PhirePhly/3080633

I followed this instruction to build libjpeg for ARM
http://www.ridgesolutions.ie/index.php/ ... ux-on-arm/

I copied the files to the sys-root of the toolchain folder and was able to compile AmbiLight.c without problems.

There are two problems happening:
Compiling without "-ljpeg" causes the TV to crash as soon as I invoke jpeg_create_decompress(&cinfo); in my script.
Compiling with "-ljpeg" doesn't inject the libAmbiLight.so at all. No AmbiLight.log in /dtv folder. For that I added "CFLAGS += -ljpeg" in the Makefile

Maybe someone can help? What kind of data does the ALT-method return?
You can find my sourcecode here, for further investigation: https://gitlab.com/ad-on-is/samsung-ambilight

[adonis]

How do you guys now if it's MST or not.
My TV is:
UE55H6470
T-MST14DEUC-2781.0

[zoelechat]

Where is libjpeg? TV doesn't own it, at least not outside exeDSP and not with C functions names you expect. You need either to link it statically, or call what TV owns (e.g.: _ZN8CJPEGLib16CreateDecompressEP22jpeg_decompress_struct, etc, IDA helps...). Now obviously you're trying to call unexisting jpeg_create_decompress, that explains crash if not linked (call to null) and no injection due to missing shared library if linked.

T-MST14DEUC-2781.0

It's in the title

[aimaim]

samyGOso -d -T -B -l /mnt/opt/privateer/usr/libso/libAmbiLight.so H_LEDS:36 V_LEDS:18 SERVER_IP:192.168.1.32 SERVER_PORT:5050 OFFSET:17 REVERSE TEST
--> tv (UE55F6770) does not freeze
--> AmbiLight3.log
--> Colors in log seem to be a little off, assuming the codes are rgb

I looked at your output, and this looks good.
Strange how your F-Model works with the same code as all other H-models, whereas other F-models don't.
The color arrangement is due to REVERSE and OFFSET, playing with these values should get your LED strip right

OFFSET and REVERSE should just influence which pixel has which color. What I was confused about was that the actual rgb values from the log did not correspond with the colors from the test image you posted (which I used for the test). Some were quiet similar but for example "
[AmbiLight] final-pixel: [0,200,246]" (from my AmbiLight3.log) is some kind of turquoise, which I cannot find in the test image at all.
Am I misunderstanding something here?

Thank you for your work!

[adonis]

samyGOso -d -T -B -l /mnt/opt/privateer/usr/libso/libAmbiLight.so H_LEDS:36 V_LEDS:18 SERVER_IP:192.168.1.32 SERVER_PORT:5050 OFFSET:17 REVERSE TEST
--> tv (UE55F6770) does not freeze
--> AmbiLight3.log
--> Colors in log seem to be a little off, assuming the codes are rgb

I looked at your output, and this looks good.
Strange how your F-Model works with the same code as all other H-models, whereas other F-models don't.
The color arrangement is due to REVERSE and OFFSET, playing with these values should get your LED strip right

OFFSET and REVERSE should just influence which pixel has which color. What I was confused about was that the actual rgb values from the log did not correspond with the colors from the test image you posted (which I used for the test). Some were quiet similar but for example "
[AmbiLight] final-pixel: [0,200,246]" (from my AmbiLight3.log) is some kind of turquoise, which I cannot find in the test image at all.
Am I misunderstanding something here?

Thank you for your work!

This is normal. It's due to the fact, that your TV shows a higher resolution, say 1920x1080, if you use Chromecast, like I did, sometimes the image is also of lower quality and has different colours in it (happend to me too) Also, libAmbiLight grabs a 96x54 sized image, which compresses everything down. This approach solves two problems, one is that it lets the TV calculate the "visible-color" pixel... so insted of having 1920 pixels (which can have 1920 different values), it reduces it to 96 values, of which you only need maybe 40-50. The other problem is speed. It's much more performant to work with 96 pixels instead of 960.

[adonis]

Where is libjpeg? TV doesn't own it, at least not outside exeDSP and not with C functions names you expect. You need either to link it statically, or call what TV owns (e.g.: _ZN8CJPEGLib16CreateDecompressEP22jpeg_decompress_struct, etc, IDA helps...). Now obviously you're trying to call unexisting jpeg_create_decompress, that explains crash if not linked (call to null) and no injection due to missing shared library if linked.

T-MST14DEUC-2781.0

It's in the title

Aaaaah sorry... I just got a little bit confused... The mentioned models are NON-mst... Forget what I asked

Phuu... unfortunatelly I'm not very familiar with IDA and reverse engineering. And it'd take too much time to dig into that. But thank you anyways for the hint.