skrb3 wrote:Actually there is (often) no information other than the filename indicating 3D content. Aspect ratio is same as the file itself - for both SBS (half width, doubled by TV = same aspect) and TAB (half height, doubled by TV = same aspect). (EDIT: actually some TAB files include black bars in the actual encoded image... Hmmm) So "simply" determining whether 3D type is NONE, SBS or TAB based on filename would be enough. Then it should be possible to adjust sampling area to the 3D type (or less fancy, to allow different profile selection for the 3D type).
So I finally got hold of a sample of a half SBS 3D movie. It actually does report back the correct AR. So the only way I could see doing this currently would be to duplicate all of the profiles in AmbiBox that you have for non-3D materials in profiles for HSBS and HOU/HTAB, changing the capture areas accordingly. So you would have a standard 16:9, a HSBS 16:9, a HTAB 16:9, a standard 2.4:1, a HSBS 2.4:1, a HTAB 2.4:1, etc.
If users want that, I can implement that in the automatic switching so that when a 3D movie is played and the AR data is available, it will look up the corresponding profile in the dardata.xml file.
I get some stutter using ambibox 2.1.5 and playclaw with xbmc and wmc in xbmc i notice the fps moves around alot like 23-24.90 but with it off the lights it stay sturdy at 23.98 no stutter.Also can't test xbmc direct because it never lights up but xbmc shows ambibox connected and all.
With a bit of rework but I don't think all that much, we could have:
1) LED number and placement could be entered once (are always same but now has to be set up for each profile)
2) From knowing aspect ratio, Ambi could automatically scale to accomodate from black bars
3) From knowing 3D on/off and TAB/SBS mode (from XBMC UI - not from movie), Ambi could automatically halve either vertically or horizontally
So sending 2)+3) from XBMC to AmbiBox via API would essentially only require user to define LED number and layout once and nothing more.
Some rework required, but it would be much more elegant
skrb3 wrote:With a bit of rework but I don't think all that much, we could have:
1) LED number and placement could be entered once (are always same but now has to be set up for each profile)
2) From knowing aspect ratio, Ambi could automatically scale to accomodate from black bars
This would have to be done by denmax2004. It's not a bad idea, but would require a major rework of the code. In addition, I'm pretty sure one reason that there are predefined profiles is to reduce the latency. The profiles are loaded and ready to go without recalculating. Making the profiles only needs to be done once ever. Perhaps a better tool to quickly make the other profiles based upon the initial full screen profile would be a cleaner, simpler implementation. It may be able to be done with a separate tool if denmax2004 is too busy by reading the initial profile in from the registry and then creating the other profiles programmatically in the registry as well.
skrb3 wrote:
3) From knowing 3D on/off and TAB/SBS mode (from XBMC UI - not from movie), Ambi could automatically halve either vertically or horizontally
So sending 2)+3) from XBMC to AmbiBox via API would essentially only require user to define LED number and layout once and nothing more.
Some rework required, but it would be much more elegant
To the best of my knowledge, there is no way to get that information directly from the currently implemented python interface with XBMC (http://mirrors.xbmc.org/docs/python-doc ... tml#Player. That is why I had to use the filename as you suggested. If someone else knows a way, please share.
Little confused now - based on your recent work and most recent suggestion - is it possible to have say 6 profiles (for simplicity, could be more) like 16:9 2D, 16:9 SBS and 16:9 TAB plus 2.35:1 2D, 2.35:1 SBS and 2.35:1 TAB and have the profile selection work automatically ?
If you need I can test different 3D files for aspect etc, just need to be sure exactly what to test for ?
Little confused now - based on your recent work and most recent suggestion - is it possible to have say 6 profiles (for simplicity, could be more) like 16:9 2D, 16:9 SBS and 16:9 TAB plus 2.35:1 2D, 2.35:1 SBS and 2.35:1 TAB and have the profile selection work automatically ?
If you need I can test different 3D files for aspect etc, just need to be sure exactly what to test for ?
Thanks :)
It's possible, but I haven't implemented that yet. But it seems that is the only way to go at the moment. Give me a couple of days and I'll post back with a link to a new version. Make sure you back-up you dardata.xml file since that may get overwritten.
One question: are any of the 3D rips in 'full' SBS or OU/TAB or are all of them 'half'?
Xotli wrote:Everything works great for a couple of hours and then my lights turn off.
I have to close the program and restart for it to work again.
This never happened with Processing scripts. Anyone get this or know of a fix?
I haven't encountered this, however, to troubleshoot, please post your system configuration (your computer hardware, what hardware is running the lights, what software is on that hardware and what LED's you have), which capture mode that you are using, and any relevant details from Ambibox.log from the program directory after an issue.
KenV99 wrote:One question: are any of the 3D rips in 'full' SBS or OU/TAB or are all of them 'half'?
Personally I only have half, and right now with XBMC there is no point in having full (until frame packing and 3d mode through HDMI 1.4 is supported).
I have checked a few files with mediainfo:
SBS 1920x800 (no black bars) - aspect shows 2,40:1
SBS 1920x1080 (no black bars) - aspect shows 16:9
TAB 1920x1080 (with black bars) - aspect shows 16:9 but movie is really 2,40:1
The last one is interesting. And not so good for our cause. It seems most TAB versions that are 2,4:1 format are encoded including the black bars. So the actual image is 16:9 and XBMC displays it (correctly) as 16:9. But for Ambibox it's actually 2,40:1 and we have no way to detect that... :(
Found a small but significant bug in AmbiBox wizard mode. When 3D over/under mode is selected, then "aspect ratio" scaling is wrong. For instance if choosing 3D over/under and setting aspect ratio to 2,35:1, the resulting capture areas are "sqaushed" too much, i.e. it's downscaled too much so that it doesn't match the actual 2,35:1 image. Hope it makes sense, probably just some scaling factor that forgot to take into account the extra ½ factor for over/under
KenV99 wrote:One question: are any of the 3D rips in 'full' SBS or OU/TAB or are all of them 'half'?
Personally I only have half, and right now with XBMC there is no point in having full (until frame packing and 3d mode through HDMI 1.4 is supported).
I have checked a few files with mediainfo:
SBS 1920x800 (no black bars) - aspect shows 2,40:1
SBS 1920x1080 (no black bars) - aspect shows 16:9
TAB 1920x1080 (with black bars) - aspect shows 16:9 but movie is really 2,40:1
The last one is interesting. And not so good for our cause. It seems most TAB versions that are 2,4:1 format are encoded including the black bars. So the actual image is 16:9 and XBMC displays it (correctly) as 16:9. But for Ambibox it's actually 2,40:1 and we have no way to detect that... :(
OK, good to know. I guess it makes some sense that the TAB versions need to do that because there is no way to specify the vertical end of one frame and the 'default' way of displaying the image would not be centered in the half frame properly.
I implemented using auto switch with 3D files by including a <Format> tag in dardata.xml. Choices are Normal, SBS or TAB.
Download is here: https://github.com/AmbiBox/AmbiBox-XBMC ... master.zip
Please let me know if there are any issues.
Xotli wrote:Everything works great for a couple of hours and then my lights turn off.
I have to close the program and restart for it to work again.
This never happened with Processing scripts. Anyone get this or know of a fix?
I haven't encountered this, however, to troubleshoot, please post your system configuration (your computer hardware, what hardware is running the lights, what software is on that hardware and what LED's you have), which capture mode that you are using, and any relevant details from Ambibox.log from the program directory after an issue.
I'm using the adalight kit with an Arduino UNO flashed with adalight LEDstream. I have two 25 LED strips together with the bigger AC adapter. USB is directly connected to my PC. i7 3770k, 16 GB DDR3, Windows 8.1 (64-bit, version 6.2, Build 9200), found nothing relevant in the log. It says the adalight is connected even after the LED lights go off after a couple of hours. Also Prismatik works but only stays on for about 1 minute compared to Ambibox which works for about 2 hours perfectly then the LEDs turn off and only works again when I close and restart Ambibox.
Processing running colorswirl and adalight works perfectly and stays on but adalight lags my CPU too much. I will donate BANNED if I can get this issue solved. Thanks!
skrb3 wrote:Found a small but significant bug in AmbiBox wizard mode. When 3D over/under mode is selected, then "aspect ratio" scaling is wrong. For instance if choosing 3D over/under and setting aspect ratio to 2,35:1, the resulting capture areas are "sqaushed" too much, i.e. it's downscaled too much so that it doesn't match the actual 2,35:1 image. Hope it makes sense, probably just some scaling factor that forgot to take into account the extra ½ factor for over/under
