[sip-comm-dev] Video capture - FMJ and lti-civil


#1

I was browsing the SIP-communicator source and noticed that you are using JMF for video capture devices.

FMJ (via the lti-civil project) has support for video capture devices. It is not as mature as JMF in yet in some regards, but it does support a wider range of platforms (Mac OS X, 64-bit Linux, in addition to Windows and Linux).

I thought this might be of interest for the future of SC.

Ken Larson
FMJ project

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hi Ken,

It's funny you should bring the subject since Damian and I were discussing exactly the same thing a few hours ago, so I am very glad you showed up.

We had already noticed FMJ's rich support for video capture devices and we were wondering (we haven't got around to reading the code yet) whether we could start by borrowing only the video data sources and temporarily use them with JMF.

I think you are aware that Chris is working on the RTP stack and we are generally prepared to help any way we can in bringing FMJ to a level that would allow us to use it instead of JMF. However, since this might take a while we were thinking that we should start by gradually replacing all bits of JMF with those that already work in FMJ.

Do you see any potential issues with this? Would you suggest a different approach?

Thanks
Emil

Ken Larson wrote:

···

I was browsing the SIP-communicator source and noticed that you are using JMF for video capture devices.

FMJ (via the lti-civil project) has support for video capture devices. It is not as mature as JMF in yet in some regards, but it does support a wider range of platforms (Mac OS X, 64-bit Linux, in addition to Windows and Linux).

I thought this might be of interest for the future of SC.

Ken Larson
FMJ project

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

The CIVIL datasource in FMJ will work with JMF.

I agree that the best approach is to use the more mature parts of FMJ with JMF. FMJ still has a way to go with its filter graph building and processing (lots of issues with things like optimization using multiple threads, audio and video synchronization, etc).

Ideally, this could be done by keeping the source in the FMJ project, and creating a special build for a jar that only includes the parts you want. This way we don't have to sync changes between the two projects. You are of course free to copy the parts of FMJ you like into your project, I just see this as creating some adminstrative headaches down the road. I'm happy to give anyone on your project who need it developer access to FMJ.

(That said, I did copy SC's speex and ilbc RTP packetizers/depacketizers into the FMJ project - and applied the patch that i submitted to this list a while back. If we go with the approach outlined above, we might want to consider keeping those there and making them part of the special FMJ build. BTW I am considering switching FMJ's license to LGPL which will make it easier to combine efforts).

The bottom line is I want both of our projects to succeed and be able to work smoothly together, so whatever works best towards that end is what we should do.

Thanks,

Ken

Emil Ivov wrote:

···

Hi Ken,

It's funny you should bring the subject since Damian and I were discussing exactly the same thing a few hours ago, so I am very glad you showed up.

We had already noticed FMJ's rich support for video capture devices and we were wondering (we haven't got around to reading the code yet) whether we could start by borrowing only the video data sources and temporarily use them with JMF.

I think you are aware that Chris is working on the RTP stack and we are generally prepared to help any way we can in bringing FMJ to a level that would allow us to use it instead of JMF. However, since this might take a while we were thinking that we should start by gradually replacing all bits of JMF with those that already work in FMJ.

Do you see any potential issues with this? Would you suggest a different approach?

Thanks
Emil

Ken Larson wrote:

I was browsing the SIP-communicator source and noticed that you are using JMF for video capture devices.

FMJ (via the lti-civil project) has support for video capture devices. It is not as mature as JMF in yet in some regards, but it does support a wider range of platforms (Mac OS X, 64-bit Linux, in addition to Windows and Linux).

I thought this might be of interest for the future of SC.

Ken Larson
FMJ project

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi Ken,

(comments inline)

Ken Larson wrote:

The CIVIL datasource in FMJ will work with JMF.

I agree that the best approach is to use the more mature parts of FMJ
with JMF. FMJ still has a way to go with its filter graph building
and processing (lots of issues with things like optimization using
multiple threads, audio and video synchronization, etc).

Excellent. I also saw your post on JMF-INTEREST announcing support for
V4L2 in your latest release. This is really nice. We've been having lots
of issues with JMF and capture devices, and this has been a huge problem
for SIP Communicator. I believe that moving to a viable alternative is
very important so we'll definitely get on this as soon as possible
(either this week or the one after).

Ideally, this could be done by keeping the source in the FMJ project,
and creating a special build for a jar that only includes the parts
you want. This way we don't have to sync changes between the two
projects.

I agree. I wonder what would be the best way to create the custom
builds. We have a CruiseControl daemon running nightly builds for us, we
could also make it do the same for you if you are interested (unless you
already have nightlies of course). Apart from a complete jar, the
nightly builds could also be producing the custom SIP Communicator lib
that you mention. Then, every now and then, someone would be uploading
the latest version of the fmj4sc.jar to the SIP Communicator repository.
Does this sound reasonable, or did you already have something else in mind?

You are of course free to copy the parts of FMJ you like into your
project, I just see this as creating some adminstrative headaches
down the road. I'm happy to give anyone on your project who need it
developer access to FMJ.

You are right, there's no point in forking FMJ (especially since you are
offering your help on resolving potential issues). This would only
create unnecessary hassle.

(That said, I did copy SC's speex and ilbc RTP
packetizers/depacketizers into the FMJ project - and applied the
patch that i submitted to this list a while back. If we go with the
approach outlined above, we might want to consider keeping those
there and making them part of the special FMJ build.

Good idea! I don't see any reason why we shouldn't. Our media package is
complex enough even without the media itself, so we'd be happy to
delegate to FMJ anything you'd take.

Incidentally, how do you handle audio capture and playback on linux? Are
you using javasound or do you have something else? Jean Lorchat wrote an
alsa data source some time ago but we haven't had the time to test it
and use it by default on linux, and we really need a replacement for
javasound.

BTW I am considering switching FMJ's license to LGPL which will make
it easier to combine efforts).

That's very kind of you thanks. We'd appreciate it.

The bottom line is I want both of our projects to succeed and be able
to work smoothly together, so whatever works best towards that end
is what we should do.

Glad to hear you saying this. I completely agree and I believe other SC
members also would. I really think that working together is the best way
to go and I, personally, am eager to get started.

Cheers
Emil

···

Thanks,

Ken

Emil Ivov wrote:

Hi Ken,

It's funny you should bring the subject since Damian and I were
discussing exactly the same thing a few hours ago, so I am very
glad you showed up.

We had already noticed FMJ's rich support for video capture devices
and we were wondering (we haven't got around to reading the code
yet) whether we could start by borrowing only the video data
sources and temporarily use them with JMF.

I think you are aware that Chris is working on the RTP stack and we
are generally prepared to help any way we can in bringing FMJ to a
level that would allow us to use it instead of JMF. However, since
this might take a while we were thinking that we should start by
gradually replacing all bits of JMF with those that already work in
FMJ.

Do you see any potential issues with this? Would you suggest a
different approach?

Thanks Emil

Ken Larson wrote:

I was browsing the SIP-communicator source and noticed that you
are using JMF for video capture devices.

FMJ (via the lti-civil project) has support for video capture
devices. It is not as mature as JMF in yet in some regards, but
it does support a wider range of platforms (Mac OS X, 64-bit
Linux, in addition to Windows and Linux).

I thought this might be of interest for the future of SC.

Ken Larson FMJ project

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net For additional
commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net For additional
commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net For additional
commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Emil - see inline, Ken.

Emil Ivov wrote:

Hi Ken,

(comments inline)

Ken Larson wrote:
  

The CIVIL datasource in FMJ will work with JMF.

I agree that the best approach is to use the more mature parts of FMJ
with JMF. FMJ still has a way to go with its filter graph building and processing (lots of issues with things like optimization using multiple threads, audio and video synchronization, etc).
    
Excellent. I also saw your post on JMF-INTEREST announcing support for
V4L2 in your latest release. This is really nice. We've been having lots
of issues with JMF and capture devices, and this has been a huge problem
for SIP Communicator. I believe that moving to a viable alternative is
very important so we'll definitely get on this as soon as possible
(either this week or the one after).

Ideally, this could be done by keeping the source in the FMJ project,
and creating a special build for a jar that only includes the parts you want. This way we don't have to sync changes between the two projects.
    
I agree. I wonder what would be the best way to create the custom
builds. We have a CruiseControl daemon running nightly builds for us, we
could also make it do the same for you if you are interested (unless you
already have nightlies of course). Apart from a complete jar, the
nightly builds could also be producing the custom SIP Communicator lib
that you mention. Then, every now and then, someone would be uploading
the latest version of the fmj4sc.jar to the SIP Communicator repository.
Does this sound reasonable, or did you already have something else in mind?

I don't know how to do nightly builds on sourceforge. However, perhaps you could get your nightly build process to pull the relevant code from FMJ's cvs and build it? We can add a build target in FMJ's build.xml for fmj4sc.jar.

You are of course free to copy the parts of FMJ you like into your project, I just see this as creating some adminstrative headaches down the road. I'm happy to give anyone on your project who need it developer access to FMJ.
    
You are right, there's no point in forking FMJ (especially since you are
offering your help on resolving potential issues). This would only
create unnecessary hassle.

(That said, I did copy SC's speex and ilbc RTP packetizers/depacketizers into the FMJ project - and applied the patch that i submitted to this list a while back. If we go with the approach outlined above, we might want to consider keeping those there and making them part of the special FMJ build.
    
Good idea! I don't see any reason why we shouldn't. Our media package is
complex enough even without the media itself, so we'd be happy to
delegate to FMJ anything you'd take.

Incidentally, how do you handle audio capture and playback on linux? Are
you using javasound or do you have something else? Jean Lorchat wrote an
alsa data source some time ago but we haven't had the time to test it
and use it by default on linux, and we really need a replacement for
javasound.
  

I wrote a javasound capture data source, which is used for all platforms.

···

  

BTW I am considering switching FMJ's license to LGPL which will make it easier to combine efforts).
    
That's very kind of you thanks. We'd appreciate it.

The bottom line is I want both of our projects to succeed and be able
to work smoothly together, so whatever works best towards that end
is what we should do.
    
Glad to hear you saying this. I completely agree and I believe other SC
members also would. I really think that working together is the best way
to go and I, personally, am eager to get started.

Cheers
Emil

Thanks,

Ken

Emil Ivov wrote:
    

Hi Ken,

It's funny you should bring the subject since Damian and I were discussing exactly the same thing a few hours ago, so I am very glad you showed up.

We had already noticed FMJ's rich support for video capture devices
and we were wondering (we haven't got around to reading the code yet) whether we could start by borrowing only the video data sources and temporarily use them with JMF.

I think you are aware that Chris is working on the RTP stack and we
are generally prepared to help any way we can in bringing FMJ to a
level that would allow us to use it instead of JMF. However, since
this might take a while we were thinking that we should start by gradually replacing all bits of JMF with those that already work in
FMJ.

Do you see any potential issues with this? Would you suggest a different approach?

Thanks Emil

Ken Larson wrote:
      

I was browsing the SIP-communicator source and noticed that you are using JMF for video capture devices.

FMJ (via the lti-civil project) has support for video capture devices. It is not as mature as JMF in yet in some regards, but it does support a wider range of platforms (Mac OS X, 64-bit Linux, in addition to Windows and Linux).

I thought this might be of interest for the future of SC.

Ken Larson FMJ project

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hey Ken,

(inline)

Ken Larson wrote:

I agree. I wonder what would be the best way to create the custom
builds. We have a CruiseControl daemon running nightly builds for us, we
could also make it do the same for you if you are interested (unless you
already have nightlies of course). Apart from a complete jar, the
nightly builds could also be producing the custom SIP Communicator lib
that you mention. Then, every now and then, someone would be uploading
the latest version of the fmj4sc.jar to the SIP Communicator repository.
Does this sound reasonable, or did you already have something else in mind?

I don't know how to do nightly builds on sourceforge. However, perhaps
you could get your nightly build process to pull the relevant code from
FMJ's cvs and build it?

Yes, that's what I was suggesting, and in addition to this we could also
do completely night builds for the generic FMJ packages. (You only have
to make sure you have the necessary targets)

We can add a build target in FMJ's build.xml
for fmj4sc.jar.

Yes this will be perfect. Most of us are in the middle of several things
right now and some developers will be going on vacation, but we'll move
to this as soon as we find the time. I am really very enthusiastic about
such a tight collaboration between our projects, and can't wait to have
the various pieces of FMJ working in SIP Communicator!

Cheers
Emil

···

You are of course free to copy the parts of FMJ you like into your
project, I just see this as creating some adminstrative headaches
down the road. I'm happy to give anyone on your project who need it
developer access to FMJ.
    
You are right, there's no point in forking FMJ (especially since you are
offering your help on resolving potential issues). This would only
create unnecessary hassle.

(That said, I did copy SC's speex and ilbc RTP
packetizers/depacketizers into the FMJ project - and applied the
patch that i submitted to this list a while back. If we go with the
approach outlined above, we might want to consider keeping those
there and making them part of the special FMJ build.
    
Good idea! I don't see any reason why we shouldn't. Our media package is
complex enough even without the media itself, so we'd be happy to
delegate to FMJ anything you'd take.

Incidentally, how do you handle audio capture and playback on linux? Are
you using javasound or do you have something else? Jean Lorchat wrote an
alsa data source some time ago but we haven't had the time to test it
and use it by default on linux, and we really need a replacement for
javasound.
  

I wrote a javasound capture data source, which is used for all platforms.

  

BTW I am considering switching FMJ's license to LGPL which will make
it easier to combine efforts).
    
That's very kind of you thanks. We'd appreciate it.

The bottom line is I want both of our projects to succeed and be able
to work smoothly together, so whatever works best towards that end
is what we should do.
    
Glad to hear you saying this. I completely agree and I believe other SC
members also would. I really think that working together is the best way
to go and I, personally, am eager to get started.

Cheers
Emil

Thanks,

Ken

Emil Ivov wrote:
    

Hi Ken,

It's funny you should bring the subject since Damian and I were
discussing exactly the same thing a few hours ago, so I am very
glad you showed up.

We had already noticed FMJ's rich support for video capture devices
and we were wondering (we haven't got around to reading the code
yet) whether we could start by borrowing only the video data
sources and temporarily use them with JMF.

I think you are aware that Chris is working on the RTP stack and we
are generally prepared to help any way we can in bringing FMJ to a
level that would allow us to use it instead of JMF. However, since
this might take a while we were thinking that we should start by
gradually replacing all bits of JMF with those that already work in
FMJ.

Do you see any potential issues with this? Would you suggest a
different approach?

Thanks Emil

Ken Larson wrote:
      

I was browsing the SIP-communicator source and noticed that you
are using JMF for video capture devices.

FMJ (via the lti-civil project) has support for video capture
devices. It is not as mature as JMF in yet in some regards, but
it does support a wider range of platforms (Mac OS X, 64-bit
Linux, in addition to Windows and Linux).

I thought this might be of interest for the future of SC.

Ken Larson FMJ project

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net For additional
commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net For additional
commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net For additional
commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Sounds good. The first thing to do is to come up with a list of classes/packages for the sc fmj jar.

1. At a maximum, this would include all FMJ classes that are not javax.media.*, com.sun.*, com.ibm.*. This would basically be the parts of FMJ that can be safely "added" to JMF, while still using JMF's infrastructure. Which FMJ classes that are actually used could be controlled through the registry (not that you would actually write the registry to a file, you'd just need to register the desired packages and plugins on startup).

2. At a minimum, it would probably be:
A. the RTP implementation
B. the SC RTP packetizers/depacketizers
C. the capture code (and lti civil, which is a separate jar).

Since #1 is something I can easily do, I'll go ahead and do it. If that turns out to be too bloated, we'll look at #2 when your team is back from vacation and has time.

Ken

Emil Ivov wrote:

···

Hey Ken,

(inline)

Ken Larson wrote:
  

I agree. I wonder what would be the best way to create the custom
builds. We have a CruiseControl daemon running nightly builds for us, we
could also make it do the same for you if you are interested (unless you
already have nightlies of course). Apart from a complete jar, the
nightly builds could also be producing the custom SIP Communicator lib
that you mention. Then, every now and then, someone would be uploading
the latest version of the fmj4sc.jar to the SIP Communicator repository.
Does this sound reasonable, or did you already have something else in mind?

I don't know how to do nightly builds on sourceforge. However, perhaps
you could get your nightly build process to pull the relevant code from
FMJ's cvs and build it?
    
Yes, that's what I was suggesting, and in addition to this we could also
do completely night builds for the generic FMJ packages. (You only have
to make sure you have the necessary targets)

We can add a build target in FMJ's build.xml
for fmj4sc.jar.
    
Yes this will be perfect. Most of us are in the middle of several things
right now and some developers will be going on vacation, but we'll move
to this as soon as we find the time. I am really very enthusiastic about
such a tight collaboration between our projects, and can't wait to have
the various pieces of FMJ working in SIP Communicator!

Cheers
Emil

You are of course free to copy the parts of FMJ you like into your project, I just see this as creating some adminstrative headaches down the road. I'm happy to give anyone on your project who need it developer access to FMJ.
    

You are right, there's no point in forking FMJ (especially since you are
offering your help on resolving potential issues). This would only
create unnecessary hassle.

(That said, I did copy SC's speex and ilbc RTP packetizers/depacketizers into the FMJ project - and applied the patch that i submitted to this list a while back. If we go with the approach outlined above, we might want to consider keeping those there and making them part of the special FMJ build.
    

Good idea! I don't see any reason why we shouldn't. Our media package is
complex enough even without the media itself, so we'd be happy to
delegate to FMJ anything you'd take.

Incidentally, how do you handle audio capture and playback on linux? Are
you using javasound or do you have something else? Jean Lorchat wrote an
alsa data source some time ago but we haven't had the time to test it
and use it by default on linux, and we really need a replacement for
javasound.
  

I wrote a javasound capture data source, which is used for all platforms.
    

BTW I am considering switching FMJ's license to LGPL which will make it easier to combine efforts).
    

That's very kind of you thanks. We'd appreciate it.

The bottom line is I want both of our projects to succeed and be able
to work smoothly together, so whatever works best towards that end
is what we should do.
    

Glad to hear you saying this. I completely agree and I believe other SC
members also would. I really think that working together is the best way
to go and I, personally, am eager to get started.

Cheers
Emil

Thanks,

Ken

Emil Ivov wrote:
    

Hi Ken,

It's funny you should bring the subject since Damian and I were discussing exactly the same thing a few hours ago, so I am very glad you showed up.

We had already noticed FMJ's rich support for video capture devices
and we were wondering (we haven't got around to reading the code yet) whether we could start by borrowing only the video data sources and temporarily use them with JMF.

I think you are aware that Chris is working on the RTP stack and we
are generally prepared to help any way we can in bringing FMJ to a
level that would allow us to use it instead of JMF. However, since
this might take a while we were thinking that we should start by gradually replacing all bits of JMF with those that already work in
FMJ.

Do you see any potential issues with this? Would you suggest a different approach?

Thanks Emil

Ken Larson wrote:
      

I was browsing the SIP-communicator source and noticed that you are using JMF for video capture devices.

FMJ (via the lti-civil project) has support for video capture devices. It is not as mature as JMF in yet in some regards, but it does support a wider range of platforms (Mac OS X, 64-bit Linux, in addition to Windows and Linux).

I thought this might be of interest for the future of SC.

Ken Larson FMJ project

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

I've added a new ant target to the FMJ build file, jar-nojmf, which builds the first jar I described in my last email. We can start from there and refine.

Ken

Emil Ivov wrote:

···

Hey Ken,

(inline)

Ken Larson wrote:
  

I agree. I wonder what would be the best way to create the custom
builds. We have a CruiseControl daemon running nightly builds for us, we
could also make it do the same for you if you are interested (unless you
already have nightlies of course). Apart from a complete jar, the
nightly builds could also be producing the custom SIP Communicator lib
that you mention. Then, every now and then, someone would be uploading
the latest version of the fmj4sc.jar to the SIP Communicator repository.
Does this sound reasonable, or did you already have something else in mind?

I don't know how to do nightly builds on sourceforge. However, perhaps
you could get your nightly build process to pull the relevant code from
FMJ's cvs and build it?
    
Yes, that's what I was suggesting, and in addition to this we could also
do completely night builds for the generic FMJ packages. (You only have
to make sure you have the necessary targets)

We can add a build target in FMJ's build.xml
for fmj4sc.jar.
    
Yes this will be perfect. Most of us are in the middle of several things
right now and some developers will be going on vacation, but we'll move
to this as soon as we find the time. I am really very enthusiastic about
such a tight collaboration between our projects, and can't wait to have
the various pieces of FMJ working in SIP Communicator!

Cheers
Emil

You are of course free to copy the parts of FMJ you like into your project, I just see this as creating some adminstrative headaches down the road. I'm happy to give anyone on your project who need it developer access to FMJ.
    

You are right, there's no point in forking FMJ (especially since you are
offering your help on resolving potential issues). This would only
create unnecessary hassle.

(That said, I did copy SC's speex and ilbc RTP packetizers/depacketizers into the FMJ project - and applied the patch that i submitted to this list a while back. If we go with the approach outlined above, we might want to consider keeping those there and making them part of the special FMJ build.
    

Good idea! I don't see any reason why we shouldn't. Our media package is
complex enough even without the media itself, so we'd be happy to
delegate to FMJ anything you'd take.

Incidentally, how do you handle audio capture and playback on linux? Are
you using javasound or do you have something else? Jean Lorchat wrote an
alsa data source some time ago but we haven't had the time to test it
and use it by default on linux, and we really need a replacement for
javasound.
  

I wrote a javasound capture data source, which is used for all platforms.
    

BTW I am considering switching FMJ's license to LGPL which will make it easier to combine efforts).
    

That's very kind of you thanks. We'd appreciate it.

The bottom line is I want both of our projects to succeed and be able
to work smoothly together, so whatever works best towards that end
is what we should do.
    

Glad to hear you saying this. I completely agree and I believe other SC
members also would. I really think that working together is the best way
to go and I, personally, am eager to get started.

Cheers
Emil

Thanks,

Ken

Emil Ivov wrote:
    

Hi Ken,

It's funny you should bring the subject since Damian and I were discussing exactly the same thing a few hours ago, so I am very glad you showed up.

We had already noticed FMJ's rich support for video capture devices
and we were wondering (we haven't got around to reading the code yet) whether we could start by borrowing only the video data sources and temporarily use them with JMF.

I think you are aware that Chris is working on the RTP stack and we
are generally prepared to help any way we can in bringing FMJ to a
level that would allow us to use it instead of JMF. However, since
this might take a while we were thinking that we should start by gradually replacing all bits of JMF with those that already work in
FMJ.

Do you see any potential issues with this? Would you suggest a different approach?

Thanks Emil

Ken Larson wrote:
      

I was browsing the SIP-communicator source and noticed that you are using JMF for video capture devices.

FMJ (via the lti-civil project) has support for video capture devices. It is not as mature as JMF in yet in some regards, but it does support a wider range of platforms (Mac OS X, 64-bit Linux, in addition to Windows and Linux).

I thought this might be of interest for the future of SC.

Ken Larson FMJ project

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

Hi Ken,

Sorry for not replying earlier. Thanks for adding the target. Damian has
recently started working on this. Personally, I hope we'll be able to
have a first FMJ version of SIP Communicator by the end of September or
beginning of October.

We'll see how it goes.

Cheers
Emil

Ken Larson wrote:

···

I've added a new ant target to the FMJ build file, jar-nojmf, which
builds the first jar I described in my last email. We can start from
there and refine.

Ken

Emil Ivov wrote:

Hey Ken,

(inline)

Ken Larson wrote:
  

I agree. I wonder what would be the best way to create the custom
builds. We have a CruiseControl daemon running nightly builds for us, we
could also make it do the same for you if you are interested (unless you
already have nightlies of course). Apart from a complete jar, the
nightly builds could also be producing the custom SIP Communicator lib
that you mention. Then, every now and then, someone would be uploading
the latest version of the fmj4sc.jar to the SIP Communicator repository.
Does this sound reasonable, or did you already have something else in mind?

I don't know how to do nightly builds on sourceforge. However, perhaps
you could get your nightly build process to pull the relevant code from
FMJ's cvs and build it?
    
Yes, that's what I was suggesting, and in addition to this we could also
do completely night builds for the generic FMJ packages. (You only have
to make sure you have the necessary targets)

We can add a build target in FMJ's build.xml
for fmj4sc.jar.
    
Yes this will be perfect. Most of us are in the middle of several things
right now and some developers will be going on vacation, but we'll move
to this as soon as we find the time. I am really very enthusiastic about
such a tight collaboration between our projects, and can't wait to have
the various pieces of FMJ working in SIP Communicator!

Cheers
Emil

You are of course free to copy the parts of FMJ you like into your
project, I just see this as creating some adminstrative headaches
down the road. I'm happy to give anyone on your project who need it
developer access to FMJ.
    

You are right, there's no point in forking FMJ (especially since you are
offering your help on resolving potential issues). This would only
create unnecessary hassle.

(That said, I did copy SC's speex and ilbc RTP
packetizers/depacketizers into the FMJ project - and applied the
patch that i submitted to this list a while back. If we go with the
approach outlined above, we might want to consider keeping those
there and making them part of the special FMJ build.
    

Good idea! I don't see any reason why we shouldn't. Our media package is
complex enough even without the media itself, so we'd be happy to
delegate to FMJ anything you'd take.

Incidentally, how do you handle audio capture and playback on linux? Are
you using javasound or do you have something else? Jean Lorchat wrote an
alsa data source some time ago but we haven't had the time to test it
and use it by default on linux, and we really need a replacement for
javasound.
  

I wrote a javasound capture data source, which is used for all platforms.
    

BTW I am considering switching FMJ's license to LGPL which will make
it easier to combine efforts).
    

That's very kind of you thanks. We'd appreciate it.

The bottom line is I want both of our projects to succeed and be able
to work smoothly together, so whatever works best towards that end
is what we should do.
    

Glad to hear you saying this. I completely agree and I believe other SC
members also would. I really think that working together is the best way
to go and I, personally, am eager to get started.

Cheers
Emil

Thanks,

Ken

Emil Ivov wrote:
    

Hi Ken,

It's funny you should bring the subject since Damian and I were
discussing exactly the same thing a few hours ago, so I am very
glad you showed up.

We had already noticed FMJ's rich support for video capture devices
and we were wondering (we haven't got around to reading the code
yet) whether we could start by borrowing only the video data
sources and temporarily use them with JMF.

I think you are aware that Chris is working on the RTP stack and we
are generally prepared to help any way we can in bringing FMJ to a
level that would allow us to use it instead of JMF. However, since
this might take a while we were thinking that we should start by
gradually replacing all bits of JMF with those that already work in
FMJ.

Do you see any potential issues with this? Would you suggest a
different approach?

Thanks Emil

Ken Larson wrote:
      

I was browsing the SIP-communicator source and noticed that you
are using JMF for video capture devices.

FMJ (via the lti-civil project) has support for video capture
devices. It is not as mature as JMF in yet in some regards, but
it does support a wider range of platforms (Mac OS X, 64-bit
Linux, in addition to Windows and Linux).

I thought this might be of interest for the future of SC.

Ken Larson FMJ project

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net For additional
commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net For additional
commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net For additional
commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

Emil -

No problem, sounds good. Let me know if I can help in any way,

Ken

Emil Ivov wrote:

···

Hi Ken,

Sorry for not replying earlier. Thanks for adding the target. Damian has
recently started working on this. Personally, I hope we'll be able to
have a first FMJ version of SIP Communicator by the end of September or
beginning of October.

We'll see how it goes.

Cheers
Emil

Ken Larson wrote:
  

I've added a new ant target to the FMJ build file, jar-nojmf, which
builds the first jar I described in my last email. We can start from
there and refine.

Ken

Emil Ivov wrote:
    

Hey Ken,

(inline)

Ken Larson wrote:
  

I agree. I wonder what would be the best way to create the custom
builds. We have a CruiseControl daemon running nightly builds for us, we
could also make it do the same for you if you are interested (unless you
already have nightlies of course). Apart from a complete jar, the
nightly builds could also be producing the custom SIP Communicator lib
that you mention. Then, every now and then, someone would be uploading
the latest version of the fmj4sc.jar to the SIP Communicator repository.
Does this sound reasonable, or did you already have something else in mind?

I don't know how to do nightly builds on sourceforge. However, perhaps
you could get your nightly build process to pull the relevant code from
FMJ's cvs and build it?
    

Yes, that's what I was suggesting, and in addition to this we could also
do completely night builds for the generic FMJ packages. (You only have
to make sure you have the necessary targets)

We can add a build target in FMJ's build.xml
for fmj4sc.jar.
    

Yes this will be perfect. Most of us are in the middle of several things
right now and some developers will be going on vacation, but we'll move
to this as soon as we find the time. I am really very enthusiastic about
such a tight collaboration between our projects, and can't wait to have
the various pieces of FMJ working in SIP Communicator!

Cheers
Emil

You are of course free to copy the parts of FMJ you like into your project, I just see this as creating some adminstrative headaches down the road. I'm happy to give anyone on your project who need it developer access to FMJ.
    

You are right, there's no point in forking FMJ (especially since you are
offering your help on resolving potential issues). This would only
create unnecessary hassle.

(That said, I did copy SC's speex and ilbc RTP packetizers/depacketizers into the FMJ project - and applied the patch that i submitted to this list a while back. If we go with the approach outlined above, we might want to consider keeping those there and making them part of the special FMJ build.
    

Good idea! I don't see any reason why we shouldn't. Our media package is
complex enough even without the media itself, so we'd be happy to
delegate to FMJ anything you'd take.

Incidentally, how do you handle audio capture and playback on linux? Are
you using javasound or do you have something else? Jean Lorchat wrote an
alsa data source some time ago but we haven't had the time to test it
and use it by default on linux, and we really need a replacement for
javasound.
  

I wrote a javasound capture data source, which is used for all platforms.
    

BTW I am considering switching FMJ's license to LGPL which will make it easier to combine efforts).
    

That's very kind of you thanks. We'd appreciate it.

The bottom line is I want both of our projects to succeed and be able
to work smoothly together, so whatever works best towards that end
is what we should do.
    

Glad to hear you saying this. I completely agree and I believe other SC
members also would. I really think that working together is the best way
to go and I, personally, am eager to get started.

Cheers
Emil

Thanks,

Ken

Emil Ivov wrote:
    

Hi Ken,

It's funny you should bring the subject since Damian and I were discussing exactly the same thing a few hours ago, so I am very glad you showed up.

We had already noticed FMJ's rich support for video capture devices
and we were wondering (we haven't got around to reading the code yet) whether we could start by borrowing only the video data sources and temporarily use them with JMF.

I think you are aware that Chris is working on the RTP stack and we
are generally prepared to help any way we can in bringing FMJ to a
level that would allow us to use it instead of JMF. However, since
this might take a while we were thinking that we should start by gradually replacing all bits of JMF with those that already work in
FMJ.

Do you see any potential issues with this? Would you suggest a different approach?

Thanks Emil

Ken Larson wrote:
      

I was browsing the SIP-communicator source and noticed that you are using JMF for video capture devices.

FMJ (via the lti-civil project) has support for video capture devices. It is not as mature as JMF in yet in some regards, but it does support a wider range of platforms (Mac OS X, 64-bit Linux, in addition to Windows and Linux).

I thought this might be of interest for the future of SC.

Ken Larson FMJ project

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net