Page 9 of 13

Re: [App] libAmbiLight E/F/H

Posted: Thu Oct 11, 2018 4:34 pm
by 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 :)

Re: [App] libAmbiLight E/F/H

Posted: Sat Oct 13, 2018 10:35 am
by adonis
aimaim wrote:
Thu Oct 11, 2018 4:34 pm
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 ;-)

Re: [App] libAmbiLight E/F/H

Posted: Sat Oct 13, 2018 12:23 pm
by Mubis
F6-MST12 H6-MST14 F7,F8-GFS
libAmbilight likes microstar chipset

Re: RE: Re: [App] libAmbiLight E/F/H

Posted: Sat Oct 13, 2018 1:13 pm
by bobiturboto
adonis wrote:
aimaim wrote:
Thu Oct 11, 2018 4:34 pm
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.



Re: [App] libAmbiLight E/F/H

Posted: Sat Oct 13, 2018 5:09 pm
by 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

Re: [App] libAmbiLight E/F/H

Posted: Sat Oct 13, 2018 5:27 pm
by adonis
How do you guys now if it's MST or not.
My TV is:
UE55H6470
T-MST14DEUC-2781.0

Re: [App] libAmbiLight E/F/H

Posted: Sat Oct 13, 2018 6:29 pm
by 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 ;)

Re: [App] libAmbiLight E/F/H

Posted: Sat Oct 13, 2018 10:46 pm
by aimaim
adonis wrote:
Sat Oct 13, 2018 10:35 am
aimaim wrote:
Thu Oct 11, 2018 4:34 pm
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!

Re: [App] libAmbiLight E/F/H

Posted: Sun Oct 14, 2018 9:38 am
by adonis
aimaim wrote:
Sat Oct 13, 2018 10:46 pm
adonis wrote:
Sat Oct 13, 2018 10:35 am
aimaim wrote:
Thu Oct 11, 2018 4:34 pm
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.

Re: [App] libAmbiLight E/F/H

Posted: Sun Oct 14, 2018 9:54 am
by adonis
zoelechat wrote:
Sat Oct 13, 2018 6:29 pm
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 :-D

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.