Xcard plugin (alpha 0.0.8 - Jan 16)

[chrispy]

Tom,
You are correct.
I double checked the settings and still the same problem. I have attached the file requested along with another log file that seems to refer to a dll that is causing an issue.

Thanks again,
Chris

[chrispy]

Looks like my attachments did not take.

[ErsatzTom]

Originally Posted by RobDMB

Just a quick question in regards to the delay that is experienced due to the dithering of colors to 256. I'm sure future optimization will help this a little but if someone with studio made a stv that only used 256 colors does that mean this program would cause no performance hit on the cpu since no dithering would need to occur and most likely eliminate the lag?

Well, let me first make a very minor correction to the question, then expand on it a bit, and then talk about timeline. First off, it isn't so much the dithering that takes extra time (it takes a little bit but not a lot). Whether you dither or not, you need to make a pass through the image converting the full color info into a color palette index. When you do dithering, you just calculate how much of a difference there is between the closest color you found in the palette and the color you wanted (the error) and spread that error around to some nearby pixels that haven't been processed yet. That is why dithering is also called error diffusion. Having said that, if there was an STV that only output 256 colors, there would be absolutely no point in dithering (because there would never be any error to diffuse) and hence you would want to turn that off.

The part that really slows things down is finding the "optimal" color palette to represent the image. Currently this done by inserting each color in the image into a tree (usually done with an octree but since the OSD uses 32 bit colors including transparency instead of 24 it is a hextree) and merging leafs together to maintain a maximum of 256 colors. Other methods exist including using a default palette for all colors. I've considered implementing a default palette scheme that people can use optionally, and will probably do this at some point. It should make this quite a bit faster and with dithering might not look too bad.

Getting back to the theoretical 256 color STV. Just having such an STV and the option to turn off dithering would make things faster and the OSD would look better. You can see how reducing colors speeds things up just by changing the background between a one color image and an image with a color gradient. However, even bigger optimizations could be made. If you know that you are always using the same palette, you wouldn't have to keep recalculating it. I was thinking that I would/could write some code to save/load a set palette from a file. Additionally, if you know you don't have to reduce the number of colors, it might improve performance if the palette were loaded into a data structure with faster lookup characteristics like a hash table. Then you would have eliminated: time to calculate the color palette, tree based lookup overhead, dithering overhead. That would be a lot.

But there is one more, perhaps even better possible optimization that would work with any of the fixed palette techniques. The Sage OSD plugin architecture is setup so that the plugin can, if it is capable of supporting it, receive updates to just the region of the OSD that has changed (such as if you are moving around in a menu). Currently, I can't really implement this because, in order to modify only a portion of the screen, I would not be able to modify the palette. With a fixed palette, this problem goes away and I could implement the region based updates.

Finally, when will all this be done? Well, for the most part, implementing major functionality (divx, dvd, etc) is a priority for me. Once I have the major bases covered, I will once again address the quantization optimization problem. Having said that, let me add that I will probably release a sort of Xcard color reduction SDK at some point with which anybody could take the ball and run with it. Secondly, if someone actually comes up with an STV that is only 256 colors, it would certainly become a much higher priority for me to get that part of it implemented.

t

[ErsatzTom]

Originally Posted by chrispy

Looks like my attachments did not take.

Sorry, but could you also load the sagetv_0.txt (or sagetvclient_0.txt if you are running the client) that is created when you try to run it with the plugin? Thanks,

t

[RobDMB]

Thanks alot. You definitely have some great plans. I'm not sure if it is the memory leak that you mentioned, the new sagetv beta, or my low power cpu P4 1.7 ghz but I am experience cpu utilization around 75 percent when playing videos when with 350 tvout i only got around 10.

[chrispy]

Tom ,
Here it is

Chris

[ErsatzTom]

Originally Posted by RobDMB

Thanks alot. You definitely have some great plans. I'm not sure if it is the memory leak that you mentioned, the new sagetv beta, or my low power cpu P4 1.7 ghz but I am experience cpu utilization around 75 percent when playing videos when with 350 tvout i only got around 10.

It might be. I'll be posting an update sometime today with a fix for the memory leak.

t

[ErsatzTom]

Originally Posted by chrispy

Tom ,
Here it is

Looking into it. I'll probably have you try again with the new build when I post it later today. It will have a little more debug info.

t

[chrispy]

Originally Posted by ErsatzTom

Looking into it. I'll probably have you try again with the new build when I post it later today. It will have a little more debug info.

t

Ok I will be waiting.

One thing I like already with the xcard is the fact that I can play DVDs (even without this plugin) from an RDP session. I am that much closer to disconnectiong the KVM from the HTPC for good here soon.

Chris

[ErsatzTom]

Originally Posted by chrispy

Ok I will be waiting.

BTW, does your properties file really have all that junk up at the beginning?

t

[chrispy]

Originally Posted by ErsatzTom

BTW, does your properties file really have all that junk up at the beginning?

t

Tom,
Yes it does. Not being an expert I thought it belonged in there. I might try cutting it out and see how it goes.

I just cut it out and started Sage up again, and yes it is Sage that is adding it. Not sure what it could be. Am I the only one with the junk?

Chris

[Wheemer]

What is it that makes an stv 32 bit colour? Is it just the images? Can't all the images be run through a batch to reduce them to 256 colours?

[ErsatzTom]

That might help but the real goal would be to produce an STV that used a grand total of 256 colors so that all screens (except perhaps if you are displaying album covers, photos, etc) would use the same fixed color palette. Also, I haven't really looked to closely at how the STVs output the various gui components but I image that some of them are painted rather than just loaded from an image. To make it look good, I think that it probably be better to start with a design with a smaller color palette in mind.

t

[Wheemer]

Well, I don't even have an x-card but I'm still interested in seeing this fully developed. It would prove to be an excellent choice for output for anyone...

I've converted the images folder included with the SageMC STV from RGB to index 256 colours... Maybe I could email it to you to try out, if it'll help. Let me know. It's too large to post here.

[Opus4]

As mentioned above, the images are not the only things producing colors on the screen -- there are various colored shapes drawn also, some of which are semitransparent, which will change the color of whatever they are drawn over. Then, if all the images are converted to 256 colors, they would all have to use the _same_ 256 colors (maybe you did that too). So, I don't think it would be a simple matter of loading a new set of images: that might help, but the rest of the UI still affects the colors on the images, especially those semi-transparent UI colors.

- Andy

[ErsatzTom]

I'm going to have to put off making a new release until tomorrow. I'm in the middle of testing some new code, a few problems cropped up, and I'm too tired to get if fixed tonight. Definitely stay tuned for it tomorrow, though. I'll back out my changes if I have to.

t

[Stuntman]

I've been using this plugin for a week or so now, and am LOVING IT! I have only had the known problem of not being able to delete a show until another show has been loaded.. weird, annoying, but still worth the admission price!!!

Will today's update have a fix for that????

I'm still flushed and giddy with happiness over this plugin..

[ErsatzTom]

Alpha 0.0.7

• Scaling the OSD is no longer the default. Instead, you should probably use osd_rendering_height_ntsc and osd_rendering_width. If for some reason this doesn't work well for you (my ability to test this is limited) you can set xcard/scale_osd=true to go back to the previous behavior.
• Memory leak fixed. Major memory leak.
• VERY experimental testing with "play faster" and "play slower". I was going to pull it out because it is in a very raw state but I don't think it can hurt you, either, so play with it if you want.
• Various minor tweaks.

Sorry this is so late. As it turns out, I'm feeling a little ill today and just didn't have much energy to work on this. It isn't as well tested as I would like and there have been a couple of bug reports that I haven't been able to track down but it should be better than 0.0.5. At least the memory leak is fixed. Let me know what problems you experience.

t

[Stuntman]

Funny thing happened this morning when I fired up SageClient with the new 0.0.7 plugin.. the OSD fits the TV screen perfectly, but all my video is now compressed into the middle 4/5 of the screen.. it's squished with large black bars on the left and right of the video... but the OSD is right! Anybody have any idea how this happened, or how I can correct this?

Thanks!

I'm using Sage 2.2.3 beta and X-Card Plugin 0.0.7

Funny it worked last night after installing 0.0.7 (didn't reboot after install), but this morning after a PC reboot is when it started.

[Freegoo]

Ok here's another XCard noob. I've gotten the media player included with Xcard to work, so don't think it's hardware problem.

Problem I get is when I try to play a mpeg Sage just closes with no error message. Three error log files are created however.

To setup I installed drivers off the cd, then I installed the app in the winxp\apps\disk1 folder of the cd. I extracted xcard ver .07 to the Sage folder and added the 2 lines to the properties file. I also set the decoders to use the Sigma ones. I'm sure I'm missing some critical step, but can't figure it out yet.

Also just for fun I uninstalled the Sage client, deleted everything and reinstalled, doing all the above. does the same thing.

I attached the 3 log files that were created and the Client Properties file.

Thanks for the help,
Marc