Video capture - FMJ and lti-civil

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-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

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-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> 
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

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-unsubscribesip-communicator.dev.java.net
>> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>>
>>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

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-unsubscribesip-communicator.dev.java.net For additional 
>>> commands, e-mail: dev-helpsip-communicator.dev.java.net
>>> 
>>> 
>>
------------------------------------------------------------
---------
>>  To unsubscribe, e-mail: 
>> dev-unsubscribesip-communicator.dev.java.net For additional 
>> commands, e-mail: dev-helpsip-communicator.dev.java.net
>> 
>> 
> 
>
------------------------------------------------------------
---------
>  To unsubscribe, e-mail: 
> dev-unsubscribesip-communicator.dev.java.net For
additional 
> commands, e-mail: dev-helpsip-communicator.dev.java.net
> 
> 


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

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-unsubscribesip-communicator.dev.java.net For additional 
>>>>> commands, e-mail: dev-helpsip-communicator.dev.java.net
>>>>>
>>>>>
>>>>>         
>>>>
------------------------------------------------------------
---------
>>>>  To unsubscribe, e-mail: 
>>>> dev-unsubscribesip-communicator.dev.java.net For additional 
>>>> commands, e-mail: dev-helpsip-communicator.dev.java.net
>>>>
>>>>
>>>>       
>>>
------------------------------------------------------------
---------
>>>  To unsubscribe, e-mail: 
>>> dev-unsubscribesip-communicator.dev.java.net For additional 
>>> commands, e-mail: dev-helpsip-communicator.dev.java.net
>>>
>>>
>>>     
>>
>>
>>
------------------------------------------------------------
---------
>> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
>> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>>
>>
>>   

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net