Hi,
I trust that we can hrlp you finding the right solution for your requirement but before i going in to details i would like to request you to send an official email to my ID - sri@clavib.com . I will wait for your email and respond back to you immidiatly. I request you to send in a supporting document if any.

Regards
Sriram

posted March 5, 2009

Regarding 3, many of the newer video presentation and recording platforms are based in Java. OCAP for cable, BluRay, cell phone apps. The trick here is to determine what functions need the horsepower of going "native" (crossing the barrier from Java to a native library written in C or C++), and adding that performance there.

Regarding Java performance in general, the old thinking about the performance of the VM just isn't as true as it used to be.

Finally, Java is already moving into the multimedia space, using JavaFX as a basis for UI development as well as providing multimedia capabilities far beyond what "traditional" Java has offered. It's been targeting RIA applications and cross-platform development ("platforms" in this case meaning cell phones, TV platforms, as well as the desktop), but can just as easily be used as a desktop development language. Because of the multimedia focus, many of the performance issues on the various platforms have been addressed for you, freeing your time up to concentrate more on your app rather than more common presentation issues.

Full disclosure: I'm a Sun employee (1.5 yrs), working on JavaFX, but I wouldn't bother putting this info out there if I didn't believe in the product. I'm a developer, not a marketing guy trying to push the product. In that capacity, I worked on cell phone encoding and decoding software in the C++ layer implementing Java interfaces. My last job was working on OCAP for cable systems for Vidiom Systems. My point being that I'm very familiar with the internals of how those systems work, and that Java can be a very viable cross-platform upper layer, even if you choose to develop your own platform-dependent lower layers. But I'd still take a gander at JavaFX... :)

Links:

• http://www.javafx.com

posted March 5, 2009

2.)
-Likely, but developing 2 versions will take more time than if you use something like Qt or wxWidgets. It also depends on what your team has experience with.

3.)
-Performance is not likely to be the main issue. Using multiple languages and frameworks will likely pose various unexpected problems, add complexity to the system, and make it harder to maintain.

I wrote my own GUI system in C++ using OpenGL for a similar application. This makes sense as most controls are custom. I also use wxWidgets for a few things.

"Can OpenGL also be used for things like compositing?"
-Yes, no problem using shaders.

posted March 5, 2009

Max,

One of my companies does a lot of software development in the area of high-performance video, including: creation of high-definition, high frame-rate video from high-performance cameras; and computer vision for automated extraction of data and information from the video.

Before offering some answers/commands on your specific questions, I will say this: video is really a big mess on computers due to multiple issues with both container formats and also codecs. Most people that use computers have experienced the results of this mess, with video not always playing back/encoding properly/at all. For developers, the problems can be even more of a challenge. So, expect this to be a major cause of headaches and general pain for your engineering team; and if they run into difficulties sometimes getting things to work well sometimes, it likely won't be (all) their fault ;-)

Now to your questions...

1) The Mac is an important platform; but so is Windows. I'm not sure it's possible to say which is *most* important for you - both could be. Also, don't forget that offering support for 64-bit versions could be important in this domain. Bottom line: the right answer could well be to plan to support both the Mac and Windows.

2) I really wouldn't buy any arguments from people about which is intrinsically more productive - Qt vs Cocoa. Productivity for the project is going to be much more about the skills of individual developers on the project than it is going to be on this. So, in picking Qt vs Cocoa, your decision is much more about which will give you the end-product you want; and what your developers are expert at. For what it's worth, I suspect Cocoa *could* lead to a more compelling product.

3) Flash and Java really aren't even in the same ball-park for significant application development. The Java run-time is light-years ahead of the Flash run-time in terms of power. Ignore people that say things like "Java is slow"; they're more than a few years behind the times in their knowledge. There's some real rocket-science in current Java VMs. The Java language is also rather more capable than ActionScript as a general-purpose prorgraming language, IMHO. What this means is - Java could be a viable choice for building your system to run on both Windows and Mac OS X; whereas, systems that run on the Flash run-time is much less likely be good enough, assuming your app is a major piece of software.

4). Depends what you mean by "viable". It's certainly possible, and not necessarily technically difficult (depending on how amazing you want your controls to be). However, if you're thinking about doing this to make your app more easy to make cross-platform, though, then I'm not sure it's going to be the best answer. It might be preferable to consider architecting your system to make the "business logic" as portable as possible, but then build unique GUIs for Mac OS X and Windows versions to so they have a "look and feel" that works really well for the different hardware/OS platforms.

5) As I hinted at the start of this post, your core internal video engine could well be the thing that gives you the most headaches. The devil is in the detail as to what your best answers are here i.e. it depends on what you want to do with your app, and how much new innovation is there. The bottom line, though, is: Quicktime isn't your only option; and it certainly doesn't always work well. For our business, we wrote our own core video engine from scratch. Removing the third-party dependencies means we're not at the mercy of deficiencies in anyone else's work. Not saying that we're perfect, of course, we have the control we need to absolutely ensure things work really well when we need to. The right answer for your business might well be different.

Hope the above helps, and good luck with your application - while video can be challenging, it's certainly fun!

posted March 7, 2009

I quite like the frameworks and tools for developing video applications found in both Cocoa (incl. QuickTime) as well as Java. Full disclosure, I was on the QuickTime team at Apple and I've worked with Java for years in the digital TV industry. So from my experience I'm happy with either approach.

I think it comes down to where the product will go down the road. If you will sit on the Apple platform for a while, and you need to build your business and be a stellar performer there for a while and most importantly look and feel like a Mac application for that audience, I'd go with the native frameworks you find on the Mac. That means Objective-C and Cocoa and QuickTime and related frameworks and tools.

If on the other hand you will need to move to other platforms relatively quickly, and having an environment that Mac users are comfortable with is not nearly as important as moving to multiple platforms quickly and being more platform agnostic, I'd go the Java route.

If you go the native Mac route first, I'd still recommend keeping other platforms in mind during the design phases. So having people that are expert at the media frameworks in Java as well as Cocoa as well as others is a good idea.

I'm not sure what a windowing system like Qt will by you. It is portable and works on Mac, Linux, etc., but so is DirectFB which is smaller and nicer in most ways. OK, I'm biased as I just developed an AWT that is based on DirectFB and am liking it quite a bit. :-)

Hope that helps.

posted March 7, 2009