New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blackborder Improved + (bugfix and enhancement) #470

Closed
wants to merge 40 commits into
base: master
from

Conversation

Projects
None yet
6 participants
@wisc17
Contributor

wisc17 commented Jan 27, 2016

fixed a bug that caused undefined behaviour in detection,
causing it to get stuck at 0,0 border detection.

Also made json config accessable in blackborder classes for easy adjusting values that are static in current build.

Added different detection modes.

see config/hyperion.config.json

"blackborderdetector" :
    {
        "enable" : true,
        "threshold" : 0.01,
+       "unknownFrameCnt": 600,         <- optional
+       "borderFrameCnt" : 50,          <- optional
+       "maxInconsistentCnt" : 10,      <- optional
+       "blurRemoveCnt": 1,             <- optional
+       "mode" : "default"              <- optional
    }

Modes:
default: 3 scanlines per direction - fastest detection so far (because of the nature of movies to have none black content in the center area;)
classic: the original implementation - needs less cpu but only covers top left 1/3 of the image and could cause problems with station logos
osd: little bit less efficient then default mode but avoids changes caused by receiver OSD overlays like program info or volume bars

blackborder_scanlines
click the image for a better view of the scanlines in osd mode

wisc17 and others added some commits Jan 2, 2016

@bouwew

This comment has been minimized.

bouwew commented Feb 1, 2016

Both hyperion-versions, the Jan.13 version as well as the "blackborder"-compiled version, did not work when the comma was not there.

I have tested before with the Jan.21 original hyperion-version: only LEDs on the side would work, the top ones stayed off. I tested for 5-10 minutes.
I then put the Jan.13 binaries back, tested with the same movie, all was OK.
Today, I tested your blackborder-version, as described above, with the result as above, both times with the same movie, with lots of high intensity-scenes.
In the config.json file everything is as it should be, I have double-checked. And hyperion was running at every test, otherwise the side-LEDs would not have responded to the movie, which they did.

I'm sorry to read that you have trouble believing my results. I was just curious to test your new implementations, I thought I just give it a try. My intention was to give you my early feedback, to help out, to give a little something back to all the great open-source developers out there, you being one of them.

@wisc17

This comment has been minimized.

Contributor

wisc17 commented Feb 1, 2016

dont get me wrong i believe you
i would not try to find the reason if i not believe you.

the current tvdzwan master HAS a bug - as i said in my first post
"fixed a bug that caused undefined behaviour in detection,
causing it to get stuck at 0,0 border detection."
there is a workaround for that version - simply restart hyperion- but its still bugged and could cause undefined behavior - so i not really recommend running this version

please believe me this IS working now :)
if the top leds are not working .. maybe you pulled the master of tvdzwan again?
or you compiled my master which is the same as tvdzwan (instead of the blackborder branch )
did you "git checkout blackborder" before compiling?

i put the executables together in a package for the raspberry forum..
you could try those
http://www92.zippyshare.com/v/PhGRsaAD/file.html
its for Raspberry PI 2 B - jessi image

@bouwew

This comment has been minimized.

bouwew commented Feb 2, 2016

No problem, I understand :)

Yes, I did issue: git checkout blackborder to make sure I had selected the right branch.
There were some warnings during Cmake, don't remember exactly the problem. Also some messages during Make that I didn't understand. I guess something went wrong during compilation. No error-messages though.
I will be happy to try out your binaries once I'm home again, on Friday or Saturday.

@bouwew

This comment has been minimized.

bouwew commented Feb 2, 2016

Can you share the link to the raspberry forum thread your refer to? So I can follow that thread?

@wisc17

This comment has been minimized.

Contributor

wisc17 commented Feb 2, 2016

http://www.forum-raspberrypi.de/Thread-hyperion-blackborder-improved-development

some errors at cmake is normal coz it tries to check available options.
but if you can post the errors of the make process it could be quite helpfull

also i could compile a version with some extra debug output

and when you stop hyperion by hand
sudo /etc/init.d/hyperion stop
and restart it without the startscript
sudo /usr/bin/hyperiond /etc/hyperion.config.json
you will see a lot more output

@wisc17 wisc17 changed the title from Blackborder Improved + to Blackborder Improved + (bugfix and enhancement) Feb 4, 2016

@bouwew

This comment has been minimized.

bouwew commented Feb 4, 2016

Just tried the file on zippyshare: didn't work in my Pi 1 B.

@wisc17 wisc17 referenced this pull request Feb 4, 2016

Closed

Merging APA102 end frame fix #480

@wisc17

This comment has been minimized.

Contributor

wisc17 commented Feb 4, 2016

im sorry to hear that.
I added some output to this PR so
you could pull the changes, stop hyperion, copy over your compiled files and run it by hand

sudo /etc/init.d/hyperion stop
sudo cp bin/hyperion* /usr/bin/
sudo /usr/bin/hyperiond /etc/hyperion.config.json

and it should output something like this:

...
Hyperion created and initialised
V4L2 width=720 height=576
V4L2 pixel format=YUYV
Black border threshold set to 0.09 (23)
DETECTION MODE:default
V4L2 grabber signal threshold set to: {25,25,25}
V4L2 grabber started
...

if you see this and it still doesnt work .. maybe teamviewer would be helpful .. coz im out of ideas now

@wisc17 wisc17 closed this Feb 4, 2016

@wisc17 wisc17 reopened this Feb 4, 2016

@bouwew

This comment has been minimized.

bouwew commented Feb 5, 2016

A question about compiling: the CompileHowTo says that I should download the Pi firmware as part of the process. How does this work? I mean, the firmware that is downloaded is the very latest, while the firmware installed on the Pi can be much older, unless you frequently "rpi-update". Doesn't his cause compatibility problems with Hyperion?

@bouwew

This comment has been minimized.

bouwew commented Feb 5, 2016

Ok, just now I did a new pull and compiled the binaries again.

The only thing remarkable during building was this:

[ 45%] Built target hyperion-utils
[ 45%] Generating moc_LedDeviceFadeCandy.cxx
[ 46%] Generating moc_LedRs232Device.cxx
[ 46%] Generating moc_LedDeviceAdalight.cxx
[ 47%] Generating moc_LedDeviceAdalightApa102.cxx
[ 47%] Generating moc_LedDeviceAmbiLed.cxx
[ 47%] Generating moc_LedDevicePhilipsHue.cxx
[ 48%] Generating moc_LedHIDDevice.cxx
[ 48%] Generating moc_LedDeviceRawHID.cxx
[ 49%] Generating moc_LedDeviceTest.cxx
/root/hyperion/libsrc/leddevice/LedDeviceTest.h:0: Note: No relevant classes found. No output generated.
Scanning dependencies of target leddevice
[ 50%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/moc_LedRs232Device.cxx.o
[ 50%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/moc_LedDeviceAdalight.cxx.o
[ 51%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/moc_LedDeviceAdalightApa102.cxx.o
[ 51%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/moc_LedDeviceAmbiLed.cxx.o
[ 51%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/moc_LedDevicePhilipsHue.cxx.o
[ 52%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/moc_LedHIDDevice.cxx.o
[ 52%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/moc_LedDeviceRawHID.cxx.o
[ 53%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/moc_LedDeviceTest.cxx.o
[ 53%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/moc_LedDeviceFadeCandy.cxx.o
[ 54%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDeviceFactory.cpp.o
[ 54%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedRs232Device.cpp.o
[ 55%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedHIDDevice.cpp.o
[ 55%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDeviceAdalight.cpp.o
[ 55%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDeviceAdalightApa102.cpp.o
[ 56%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDeviceAmbiLed.cpp.o
[ 56%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDeviceRawHID.cpp.o
[ 57%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDeviceLightpack.cpp.o
[ 57%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDeviceMultiLightpack.cpp.o
[ 58%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDevicePaintpack.cpp.o
[ 58%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDevicePiBlaster.cpp.o
[ 59%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDeviceSedu.cpp.o
[ 59%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDeviceTest.cpp.o
[ 59%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDeviceFadeCandy.cpp.o
/root/hyperion/libsrc/leddevice/LedDeviceFadeCandy.cpp: In member function ‘virtual int LedDeviceFadeCandy::write(const std::vector<ColorRgb>&)’:
/root/hyperion/libsrc/leddevice/LedDeviceFadeCandy.cpp:52:18: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
  if (nrLedValues > MAX_NUM_LEDS)
                  ^
[ 60%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDeviceHyperionUsbasp.cpp.o
[ 60%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDevicePhilipsHue.cpp.o
[ 61%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDeviceTpm2.cpp.o
[ 61%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDeviceAtmo.cpp.o
[ 62%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedSpiDevice.cpp.o
[ 62%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDeviceLpd6803.cpp.o
[ 63%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDeviceLpd8806.cpp.o
[ 63%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDeviceP9813.cpp.o
[ 63%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDeviceWs2801.cpp.o
[ 64%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDeviceAPA102.cpp.o
[ 64%] Building CXX object libsrc/leddevice/CMakeFiles/leddevice.dir/LedDeviceTinkerforge.cpp.o
Linking CXX static library ../../lib/libleddevice.a
[ 64%] Built target leddevice

After copying the new binaries to /usr/bin I ran hyperion as you suggested above. It was still in classic-mode, everything was working OK.
Then I changed to default mode, and unfortunately again no top leds active, only the side leds light up when playing a 2:35:1 movie fullscreen.
Logged output from hyperion:

root@raspberrypi:~# /usr/bin/hyperiond /etc/hyperion.config.json
Application build time: Feb  5 2016 10:19:40
QCoreApplication initialised
Selected configuration file: /etc/hyperion.config.json
ColorTransform 'default' => [0; 81]
Device configuration:
{
        "colorOrder" : "rgb",
        "name" : "MyPi",
        "output" : "/dev/spidev0.0",
        "rate" : 250000,
        "type" : "ws2801"
}

Creating linear smoothing
Created linear-smoothing(interval_ms=33;settlingTime_ms=75;updateDelay=0
Effect loaded: Knight rider
Effect loaded: Blue mood blobs
Effect loaded: Cold mood blobs
Effect loaded: Full color mood blobs
Effect loaded: Green mood blobs
Effect loaded: Red mood blobs
Effect loaded: Warm mood blobs
Effect loaded: Police Lights Single
Effect loaded: Police Lights Solid
Effect loaded: Rainbow mood
Effect loaded: Rainbow swirl fast
Effect loaded: Rainbow swirl
Effect loaded: Snake
Effect loaded: Strobe blue
Effect loaded: Strobe Raspbmc
Effect loaded: Strobe white
Effect loaded: X-Mas
Initializing Python interpreter
Hyperion created and initialised
run effect Rainbow swirl fast on channel 0
Black border threshold set to 0.1 (26)
DETECTION MODE:default
Boot sequence(Rainbow swirl fast) created and started
V4L2 width=720 height=480
V4L2 pixel format=YUYV
Black border threshold set to 0.1 (26)
DETECTION MODE:default
V4L2 grabber signal threshold set to: {25,25,25}
V4L2 grabber started
V4l2 grabber created and started
Json server created and started on port 19444
Proto server created and started on port 19445
BORDER SWITCH REQUIRED!!
CURRENT BORDER TYPE: unknown=0 hor.size=0 vert.size=0
V4L2 grabber stopped
effect finished
V4L2 grabber started
@bouwew

This comment has been minimized.

bouwew commented Feb 5, 2016

hyperion.config.json.zip
This is my config file, for reference.

@wisc17

This comment has been minimized.

Contributor

wisc17 commented Feb 5, 2016

ok i dont get those errors of yours.. the ledtestdevice seems weird to me but i dont think thats the problem here.

i made a new branch with extended debug output
please compile my "test" branch and run it manual so you can see the debug output

it will output lines like this:

default c: 0 9 p: 0 25 n: 0 25 c:i 45: 0
default c: 0 9 p: 0 25 n: 0 25 c:i 46: 0
default c: 0 9 p: 0 25 n: 0 25 c:i 47: 0
default c: 0 9 p: 0 25 n: 0 21 c:i 48: 0
default c: 0 9 p: 0 25 n: 0 25 c:i 48: 1
default c: 0 9 p: 0 25 n: 0 25 c:i 49: 0
BORDER SWITCH REQUIRED!!
CURRENT BORDER TYPE: unknown=0 hor.size=25 vert.size=0
default c: 0 25 p: 0 25 n: 0 16 c:i 50: 0
default c: 0 25 p: 0 25 n: 0 25 c:i 50: 1
default c: 0 25 p: 0 25 n: 0 25 c:i 51: 0
default c: 0 25 p: 0 25 n: 0 25 c:i 52: 0
default c: 0 25 p: 0 25 n: 0 25 c:i 53: 0

explaination of the output
[mode] c:[Current active border] p:[Previous detected border that will be set if its consistent] n:[New border that was detected just now] c:i [ConsistentCount : InconsistentCount]

every time the "p" is detected again the consistent Count will be increased and once it hits the 50 (49) the border will be switched

in my output you see that there was current border x=0 y=9 but the 0 25 prooved 50 times that its consistent so the borderswitch is triggered
sometimes the detection is getting "wrong" values coz of interference or noise - you see at "c:i" if the "i" value goes up

default c: 0 9 p: 0 25 n: 0 25 c:i 47: 0 <- got 0 25 => c will be increased for next run
default c: 0 9 p: 0 25 n: 0 21 c:i 48: 0 <- got 0 21 => c will stay and i will be increased
default c: 0 9 p: 0 25 n: 0 25 c:i 48: 1 <- got 0 25 again => c +1 and i = 0 coz consistent

here the detector got 0 21 thats why in the next run the "c:i" is 48 consistent and 1 inconsistent frames

now im pretty curious of your output

P.S. of course i would recommend using latest release
apt-get update
apt-get upgrade
rpi-update

@RickDB

This comment has been minimized.

Contributor

RickDB commented Feb 6, 2016

Been testing this branch and works well using the settings posted:

"blackborderdetector" :
    {
        "enable" : true,
        "threshold" : 0.10,
        "mode" : "default"
    }

0.10 seems pretty high compared to the default 0.01, is that because the default is more accurate or is 0.01 for that mode too low?

@wisc17

This comment has been minimized.

Contributor

wisc17 commented Feb 6, 2016

thanks for taking the time to test

the threshold has the same effects for all methods .. it depends on your source material (the movie,station,player)
you can calculate your optimal value by taking a screenshot and examin the "real" color of the border
most of the time it is not #000000 - for me it was something like #131313 ...
so red is 13 green is 13 and blue is 13 HEX
you have to set the threshold to a value higher then that to make the detection "see" those #131313 pixels as black
13 HEX is 19 decimal
to get the threshold you divide that value by 255
19 / 255 = 0,074509....
round it up makes a minimum threshold of 0.08
but i added a bit to make sure in case of "brighter" blackborder it will still work
coz if the threshold is too low the detector will "see" the border pixels as part of the image

usualy 0.1 seems to be a good default that works for most people

@RickDB

This comment has been minimized.

Contributor

RickDB commented Feb 6, 2016

Great explanation and thanks for making these improvements 👍

@wisc17 wisc17 force-pushed the wisc17:blackborder branch from 488b319 to a0a9256 Feb 7, 2016

@wisc17

This comment has been minimized.

Contributor

wisc17 commented Feb 7, 2016

sorry had to rebase .. will cleanup and make a new PR
see #483

@wisc17 wisc17 closed this Feb 7, 2016

@bouwew

This comment has been minimized.

bouwew commented Feb 7, 2016

Debug_output.zip
Finally some time to test. Busy saterday :)
Test 1: classic, 2.35:1 movie, result OK
Test 2: default, full-screen movie, result OK
Test 3: default, 2.35:1 movie, result Not OK, top leds stay off.

On test 3, I have changed the threshold to 0.2, no difference in result.

Let me know what else you would like me to test.

@wisc17

This comment has been minimized.

Contributor

wisc17 commented Feb 7, 2016

this is quite interesting - thanks for taking the time
just one last thing for now -> the classic mode works when you switch around channels with border/no border ? letterbox fullscreen pilarbox
would be interesting to see if there are any changes in the debug output for the default and classic mode when you switch around
p.s. your grabber seems to produce very stable results .. i wished mine would do the same :|

@wisc17

This comment has been minimized.

Contributor

wisc17 commented Feb 7, 2016

i just had another idea .. can you make a screenshot of that 2.35:1 movie please
howto:
stop hyperion -> then type

sudo hyperion-v4l2 -d /dev/video0 -f 2 -s 8 --crop-left 32 --crop-right 29 --crop-top 7 --crop-bottom 8 --screenshot

this will create a screenshot.jpg in the current directory (with your settings taken from your config file) which you can download via FTP

and then please do it again without the croping

sudo hyperion-v4l2 -d /dev/video0 -f 2 -s 8 --screenshot

p.s. your crop left and right seem a bit high compared to other configurations i've seen

also it would be interesting to see which image you are running

cat /etc/os-release

if the screenshots dont give new hints i would anyways recommend that you get a fresh install of a current image - since those compiler errors you posted before are just not normal - but lets see those screenshots first

@bouwew

This comment has been minimized.

bouwew commented Feb 12, 2016

Result of cat /etc/os-release:

PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian

More to follow during tomorrow...

@bouwew

This comment has been minimized.

bouwew commented Feb 13, 2016

Problem solved. Issue was with HDMI to AV, it was set to NTSC. :(
After setting it to PAL, default mode works OK for all screen formats.

Thanks for your help and suggestions!

My grabber is this one: https://lightberry.eu/shop/shop/easycap-video-grabber/
The shop is in Poland and nice and cheap :)

@wisc17

This comment has been minimized.

Contributor

wisc17 commented Feb 13, 2016

very nice :D
as i read your answers i was thinking anyways that it must be the grabbed image coz if pillarbox works the widescreen MUST work too - except there is a problem with the analysed image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment