Redfire/Spark Plugin: Ready for release with Spark 2.6.1?

A question to the group: Is the Spark Plugin for Redfire ready to be included in pending Spark Release 2.6.1?

Yes, No, Never, Maybe, Fixes needed?

Just let me know what you think so we can include it in the nightly builds…

Maybe it’s ready for the nightlies, but there is work to be done to solve some pending issues.

For instance, video stream quality is really bad, and there is no way to solve it from the client side.

There is also a problem with the redfire chat notification. When you push accept the notification doesn’t go away.

I’m all in for it to be in 2.6.1, because it’s a killer feature, and even though it’s not the best implementation that could be done (jitsi is brilliant here), it’s what’s there, and it has to be in.

Trust me, you don’t want to include JMF in a a Spark Plugin.

I took a hard look an SIP Communicator (Jitsi) when I started work on Redfire as a replacement for the Red5 plugin as way of providing a 100% platform independent solution, but there is a lot of of work to be done to migrate the Jitsi code and possibly replace JMF with something more lightweight and active. JMF is dead. All that work will take considerable time and require fulltime commitment from someone who knows their way arounf JIngle, Jingle Nodes and Audio/Video codecs as well as a suitable Java Media Frramework.

Flash Video is very good. Working with video is not straightforward. You have to know how to customise it. You can’t have good quality video at 1024x768 resolution with no dropped frames at 60 frames a second without high bandwidth, so something has to give

There are issues with the new RTMFP implementation and the use of native Spark windows, but it is the first attempt and I am optimisitic that the issues can be fixed before 2.6.1 release.

Well, I wasn’t talking about the technology itself. From what I gathered while having a look to their mailing list, ithey had to implement some workarounds for JMF shortcomings and they had to build custom interfaces for the hardware, so it has to be a PITA to glue everything together in a plug-in.

It’s clear that your flash implementation is the easiest path to reach the goal, but for now it’s lacking some integration that Jitsi currently provides on the usability side for instance.

Something that worries me thinking in corporate environments is the dependency on an external component I might not have control over.

Best case scenario a license to deploy the flash runtime is needed and the tested version should be enforced.

Have you tested Adobe AIR integration?

A small application can be deployed that integrates server side swf and adds some controls for audio and video.

Surely it can be skinned so it matches Spark’s one and provide a more seamless integration for OSX and Linux systems.

Adobe AIR 2.7 is a RC and should match Flash 10.3 features. Besides it looks like it’s more administrator-friendly for network deployments.

EDIT:

Just wanted to point out that it looks like FINALLY we are going to have h264 encoding through flash player and that should vastly improve video quality. It’s in the incubator release and available for all the platforms. Here is some discussion on this feature.

Whaoooaaa…

h264 encoding in Flash Player will make a BIG, BIG difference, not to mention the fact that I can finally add SIP video to Red5phone and add it to the Redfire plugin for Spark later. Thanks for the heads up.

I did look at AIR, but the problem is the ability to access Java code from Actionscript and vice-versa. It is do-able, but not straightforward and could be time consuming and a become convoluted solution in the end.

For now, I am staying with my simplistic UI approach of URLs using any Flash compatible browser and adding native integration for Windows users only.

The echo cancellation and h264 support in the Flash Player should make the trip worth-while for now

but for now it’s lacking some integration that Jitsi currently provides on the usability side for instance.
Could you kindly give us an idea of these features? It might be possible to get them implemented in the Flash UI.

This should not include the request for the Redfire to behave like a phone and handle signalling. If a replacement for the SIP plugin or the Jingle plugin is required, I am happy to add red5phone with support for video and re–skin it for Spark.

I spent some time getting current and up to speed with Jitsi since the days of SIP Communicator. Unfortunately, it does not have a 100% Java encoder/decoder for H264. It uses an FFMPEG wrapper like Xuggler does. We would need to package the dependencies as part of the Spark install. That is definitely outside the scope of a simple Spark plugin and should be part of the main stream Spark development.

I am looking at jCodec that has a 100% h264 decoder as a first step to supporting video in SIP phone calls using red5phone. Until the encoder is ready, I will use the Flash screen codec 2 to encode the video stream coming from the phone.

Version 0.0.9 looks and feels good enough to be included with Spark 2.6.1.

The plugin jar file can be found at http://community.igniterealtime.org/message/213745#213745

Hi Dele,

if we include the Redfire plugin in the release we will have an error message for all installation that do not have a redfire on the server. The plugin does not check on the availability of Redfire.

We can not include this plugin as default part of the installation in the moment and the deactivated plugin functionality does not feature default deactivated plugins (not coded right now).

With a release date on Wendsday, we won’t make it as part of the final 2.6.1. Maybe a 2.6.2?

Walter

Thanks. No problem. I will add service discovery and plan for 2.6.2