jffmpeg-devel

Re: [Jffmpeg-devel] Patch to enable more formats in NativeDecoder.

[David S. <da...@si...>]

Hello,

See below ...

Jonathan Hueber wrote:

> Hi,
>
> The changes I supplied are really a "proof-of-concept" to show that 
> the jffmpeg project is feasible for codecs other than H263.  In actual 
> fact, other than a few obstacles for fast-forward/rewind of mpeg1/2 it 
> was all rather smoother than I thought it would be.
>
> This is what I am proposing to do from here:
>
> 1)  Create a pure Java class implementing Codec (probably 
> net.sourceforge.ffmpeg.FFMpegDecoder).  This codec will handle *all* 
> codecs that we supply (native and pure Java).
>
> 2)  A CodecManagement class will be used to control which codecs are 
> available.  This will be configured by a .properties file, so that the 
> codecs can be configured without recompilation.


So far this sounds OK to me. I was sort of anticipating there would be a 
need for more framework in this area. Keep in mind that we should have a 
solution for webstart as well however (meaning, the reading of the 
.properties file should be optional, or there should be support for 
putting the .properties file in the classpath somewhere).


> 3)  I will abstract all Codec functionality into a non-JMF linked 
> interface "JFFMpegCodec".
>
>
> For the getNativeData() calls, I am happy to keep the concept, I am 
> just unhappy about calling Sun classes directly.  I think that the 
> functionality is simply "(*env)->GetByteArrayElements()" without 
> freeing afterwards.  I don't know how expensive this call is, but it 
> should be relatively easy to make this optional at compile-time.


I could be wrong, but doesn't every call to GetByteArrayElements need to 
be matched with the corresponding release call? (If I am wrong it could 
explain the source of some remaining VM crashes). If you can keep the 
concept but remove our dependency on the Sun classes, I would be for it.


> Other bits of C that I need to change:
> - I am using ANSI C, so variables must go at the start of braces.


Probably should have been done from the outset ..

> - Native pointers can be 64 bits, so will not fit into Java ints!


I agree this is a problem, I guess this is the price we pay for the new 
64 bit architectures.. :( The only requirement is that somehow the java 
side must be able to track a pointer to the native side; I'm not sure 
how this can be implemented otherwise, do you have a proposal? An 
interesting bit here is that JMF itself uses this technique in their 
native codec implementations (so they will have to update their native 
codecs as well, I would imagine).

Is it possible (I wonder) that we will eventually see a 64 bit integer 
in Java?

That reminds me, maybe you could (somehow) use a "BigInt"?

> The main problem I see is that I will have to be careful not to break 
> the existing investment in your H263/RTP functionality.  All I know 
> about H263 is that it is used in video conferencing.  Do you have some 
> specific requirements/test streams that I should adhere to?


Yes, this would be my requirement as well (heh) ;)

Most of our tests have been done using JMStudio directly. You can try a 
few different things. Do you have a webcam?

    * Save an H263 encoded file using ffmpeg. Try to play it back using
      jffmpeg and JMStudio. These are pure video files, no audio.
    * The reverse, try to play a jffmpeg encoded file in ffmpeg.
    * Save it from jffmpeg, and play it back using jffmpeg.
    * Transmit H263/RTP to another JMStudio (running jffmpeg) which
      opens an RTP session at that port. Monitor your output to test the
      decoder and renderer. This is easier if you have access to two
      machines.
    * Try different sizes sqcif, qcif, cif, 4cif, etc.
    * Try different frame rates 5, 10, 15, 20, 30
    * Use the "controls" to try different settings, sending and receiving

FYI, it only works with legacy/existing JMF H263 if the "compatibility" 
mode is turned on (there is a compatibility control). Basically these 
are the kinds of tests I was doing ad nauseum, looking for visual 
defects (packets that shouldn't be dropped etc).

In order to REALLY test it one needs to integrate it into an application 
and test interop with other applications (for instance, we have a 
SIP-based application which allows me to test interop with lots of other 
H263 devices). But unfortunately I cannot release this code. ;-)

So for now, just test it as well as you can within the confines of 
JMStudio. It doesn't get all the bugs, but it will flush out most of them.

> Time scale:  I like to keep myself on my toes.  In three weeks I 
> should have the above implemented to a suitable standard.  I aim to 
> support the decoding of at least:
>   - Mpeg1/2/4
>   - MsMpeg1/2/3
>   - MP3/Ogg Vorbis/AC3
>
> Ideally, I would like to have an end-user installable download 
> available by the end of September.
>
> Note that I haven't mentioned encoders or ffmpeg demultiplexers - I 
> only need to support MPEG and AVI files only, so I'll leave that fun 
> to others.  My aim is to produce a LAN "Java Media Center" with an 
> HTML based front-end.  That is why I have DVD format playback, and one 
> MPG4 codec.


What, no encoders? but, but ..

Well, I guess decoding is a good start. It's always best to have native 
support for encoding anyways due to the CPU requirements. Although 
obviously having a good native mpeg4 encoder would be fantastic!


-- 
David Stuart, SIPquest
Email: dave (at) sipquest (dot) com
Phone: 254-8886 x234  Web: http://www.sipquest.com/
Address: 106 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5

Re: [Jffmpeg-devel] Patch to enable more formats in NativeDecoder.

[Jonathan H. <jon...@ho...>]

Hi,

The changes I supplied are really a "proof-of-concept" to show that the 
jffmpeg project is feasible for codecs other than H263.  In actual fact, 
other than a few obstacles for fast-forward/rewind of mpeg1/2 it was all 
rather smoother than I thought it would be.

This is what I am proposing to do from here:

1)  Create a pure Java class implementing Codec (probably 
net.sourceforge.ffmpeg.FFMpegDecoder).  This codec will handle *all* codecs 
that we supply (native and pure Java).

2)  A CodecManagement class will be used to control which codecs are 
available.  This will be configured by a .properties file, so that the 
codecs can be configured without recompilation.

3)  I will abstract all Codec functionality into a non-JMF linked interface 
"JFFMpegCodec".


For the getNativeData() calls, I am happy to keep the concept, I am just 
unhappy about calling Sun classes directly.  I think that the functionality 
is simply "(*env)->GetByteArrayElements()" without freeing afterwards.  I 
don't know how expensive this call is, but it should be relatively easy to 
make this optional at compile-time.

Other bits of C that I need to change:
- I am using ANSI C, so variables must go at the start of braces.
- Native pointers can be 64 bits, so will not fit into Java ints!

The main problem I see is that I will have to be careful not to break the 
existing investment in your H263/RTP functionality.  All I know about H263 
is that it is used in video conferencing.  Do you have some specific 
requirements/test streams that I should adhere to?


Time scale:  I like to keep myself on my toes.  In three weeks I should have 
the above implemented to a suitable standard.  I aim to support the decoding 
of at least:
   - Mpeg1/2/4
   - MsMpeg1/2/3
   - MP3/Ogg Vorbis/AC3

Ideally, I would like to have an end-user installable download available by 
the end of September.

Note that I haven't mentioned encoders or ffmpeg demultiplexers - I only 
need to support MPEG and AVI files only, so I'll leave that fun to others.  
My aim is to produce a LAN "Java Media Center" with an HTML based front-end. 
  That is why I have DVD format playback, and one MPG4 codec.

Jonathan H




>From: David Stuart <da...@si...>
>To: Jonathan Hueber <jon...@ho...>
>CC: jff...@li...
>Subject: Re: [Jffmpeg-devel] Patch to enable more formats in NativeDecoder.
>Date: Tue, 27 Jul 2004 00:20:11 -0400
>
>Hi Jonathan,
>
>Sounds like you have been busy..
>
>Good to have you on board!
>
>The "getNativeData()" method is indeed for maintaining a native byte array. 
>Basically the idea is to keep the data on the native side and not move it 
>into the Java side unless needed (reducing the amount of memory copies that 
>are done).
>
>You're free to try to remove it, but if I were you I might try some 
>benchmarks before and after, to make sure that we're not making it 
>significantly slower. For me, the h263 encoding/decoding performance is one 
>of the main draws of using the jffmpeg codec (the performance of normal JMF 
>h263 is really terrible)!
>
>Having said that, there are still the occasional memory problems I am 
>noticing (resulting in crashes from time to time). It's possible the native 
>byte arrays are involved. I might be willing to sacrifice speed (should it 
>prove to be inconsequential) for an increase in stability. I also see the 
>need for some cleanup (did some myself recently). Note, There is a memory 
>issue somewhere in the code (along the H263 code path to be certain) which 
>causes a crash today and it is causing me some pain. If anyone here feels 
>like taking on the problem I would be most grateful..
>
>Having said all that, it might take me a little while to getting around to 
>inspecting and/or submitting this patch (things are crazy at my day job 
>right now), unless someone else in the group would care to step up (he 
>said; looking around).
>
>What kind of time frame were you looking at?
>
>
>Jonathan Hueber wrote:
>
>>Hi,
>>
>>I had a look through the NativeDecoder and made a few changes to get a
>>few more codecs working, namely:
>>
>>  - mpeg1/2
>>  - mpeg4
>>  - msmpeg1/2/3
>>  - WMV1
>>  - mjpeg
>>
>>The biggest changes are to allow multiple frames appear in the same
>>incoming Buffer.  The IBM demultiplexer places MPEG sequences of
>>frames into the same base buffer (I assume make handling inverse
>>telecine easier).
>>
>>To this end, the native code returns the quantity of data consumed (0
>>not enough data, <0 error).  Also, I have added the CODE_FLAG_TRUNCATED
>>option to the ffmpeg calls - this tells ffmpeg to output frame-by-frame.
>>
>>Next up, I have added code to set the time stamp on outgoing buffers
>>correctly (otherwise the video will not play smoothly).  This is based
>>on the input framerate.
>>
>>There are other bits and pieces, but these are more obvious changes.
>>
>>
>>If this is all OK, there is still a fair amount of tidying up.  In
>>particular I would like to remove the direct use of undocumented Sun
>>methods and classes (e.g. getNativeData()).  This appears to maintain
>>a pinned byte array in the JVM, which may be a little faster, but the
>>code would be much simpler without it.
>>
>>Enjoy,
>>
>>Jonathan H
>>
>>_________________________________________________________________
>>MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
>>http://join.msn.com/?page=features/virus
>
>
>--
>David Stuart, SIPquest
>Email: dave (at) sipquest (dot) com
>Phone: 254-8886 x234  Web: http://www.sipquest.com/
>Address: 106 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5
>

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

Re: [Jffmpeg-devel] JMF Codecs

[Francisco J. C. <pa...@ca...>]

Jonathan, in order to give you access to cvs, you should create you own 
sourceforge user. Tell me which is you user and I'll add you as a jffmpeg 
developer asap.

Paco


On Wednesday 28 July 2004 03:13, Stephen Davidson wrote:
> Hi Francisco.
>
> I should have been more precise (sorry).  I was referring to giving him
> write access
> to the code base.
>
> Regards,
> Steve
>
> Francisco Javier Cabello wrote:
> >everybody can join to the list. It's as easy as fill your email address in
> > the following url:
> >https://lists.sourceforge.net/lists/listinfo/jffmpeg-devel
> >
> >On Tuesday 27 July 2004 12:04, Stephen Davidson wrote:
> >>Greetings.
> >>
> >>Can somebody add Jonathan to the Developers List????
> >>Might want to figure out as well if this should go on HEAD, or be split
> >>out on a separate branch (Dave - you are the guy most likely to have a
> >>conflict here).
> >>
> >>Regards,
> >>Steve

Re: [Jffmpeg-devel] JMF Codecs

[Stephen D. <go...@fr...>]

Hi Francisco.

I should have been more precise (sorry).  I was referring to giving him
write access
to the code base.

Regards,
Steve

Francisco Javier Cabello wrote:

>everybody can join to the list. It's as easy as fill your email address in the 
>following url:
>https://lists.sourceforge.net/lists/listinfo/jffmpeg-devel
>
>On Tuesday 27 July 2004 12:04, Stephen Davidson wrote:
>  
>
>>Greetings.
>>
>>Can somebody add Jonathan to the Developers List????
>>Might want to figure out as well if this should go on HEAD, or be split
>>out on a separate branch (Dave - you are the guy most likely to have a
>>conflict here).
>>
>>Regards,
>>Steve
>>
>>    
>>


-- 
Java/J2EE Developer/Integrator
Chair, Dallas/FortWorth J2EE Sig
214-724-7741

Re: [Jffmpeg-devel] JMF Codecs

[Francisco J. C. <pa...@ca...>]

everybody can join to the list. It's as easy as fill your email address in the 
following url:
https://lists.sourceforge.net/lists/listinfo/jffmpeg-devel

On Tuesday 27 July 2004 12:04, Stephen Davidson wrote:
> Greetings.
>
> Can somebody add Jonathan to the Developers List????
> Might want to figure out as well if this should go on HEAD, or be split
> out on a separate branch (Dave - you are the guy most likely to have a
> conflict here).
>
> Regards,
> Steve
>
> Jonathan Hueber wrote:
> > Hi,
> >
> > Thanks for the good response.  I have attached the code I have for
> > people who are interested in trying it.  I have included a readme
> > file.  You will need jmf.jar.
> >
> > I still need to do a lot of bashing into shape - remove debug
> > statemements, add comments, sort out naming conventions, etc.
> >
> > I have briefly looked through the code on the jffmpeg site and I
> > should be able to follow the conventions you are using.
> >
> > The approach I have is that if you want to use these codecs at all, it
> > is because you don't want to use native code (security, crossplatform,
> > or perhaps applets).  As such the plan was to have three levels of
> > functionality:
> >
> > - A "decoder only" version that doesn't require JMF (small for applets)
> > - A JMF wrapper for the above [this is what we have currently]
> > - A wrapper to fit in seamlessly with your project
> >
> > So at the end of the day, I would like an extensible infrastructure from:
> > - No client install what-so-ever [pure Java codecs only]
> > - Install Java-based JMF on the client
> > - Full jffmpeg native support
> >
> > Regards,
> >
> > Jonathan H

Re: [Jffmpeg-devel] JMF Codecs

[Stephen D. <go...@fr...>]

Greetings.

Can somebody add Jonathan to the Developers List????
Might want to figure out as well if this should go on HEAD, or be split 
out on a separate branch (Dave - you are the guy most likely to have a 
conflict here).

Regards,
Steve

Jonathan Hueber wrote:

> Hi,
>
> Thanks for the good response.  I have attached the code I have for 
> people who are interested in trying it.  I have included a readme 
> file.  You will need jmf.jar.
>
> I still need to do a lot of bashing into shape - remove debug 
> statemements, add comments, sort out naming conventions, etc.
>
> I have briefly looked through the code on the jffmpeg site and I 
> should be able to follow the conventions you are using.
>
> The approach I have is that if you want to use these codecs at all, it 
> is because you don't want to use native code (security, crossplatform, 
> or perhaps applets).  As such the plan was to have three levels of 
> functionality:
>
> - A "decoder only" version that doesn't require JMF (small for applets)
> - A JMF wrapper for the above [this is what we have currently]
> - A wrapper to fit in seamlessly with your project
>
> So at the end of the day, I would like an extensible infrastructure from:
> - No client install what-so-ever [pure Java codecs only]
> - Install Java-based JMF on the client
> - Full jffmpeg native support
>
> Regards,
>
> Jonathan H
>
>


-- 
Java/J2EE Developer/Integrator
Chair, Dallas/FortWorth J2EE Sig
214-724-7741

Re: [Jffmpeg-devel] Patch to enable more formats in NativeDecoder.

[David S. <da...@si...>]

Hi Jonathan,

Sounds like you have been busy..

Good to have you on board!

The "getNativeData()" method is indeed for maintaining a native byte 
array. Basically the idea is to keep the data on the native side and not 
move it into the Java side unless needed (reducing the amount of memory 
copies that are done).

You're free to try to remove it, but if I were you I might try some 
benchmarks before and after, to make sure that we're not making it 
significantly slower. For me, the h263 encoding/decoding performance is 
one of the main draws of using the jffmpeg codec (the performance of 
normal JMF h263 is really terrible)!

Having said that, there are still the occasional memory problems I am 
noticing (resulting in crashes from time to time). It's possible the 
native byte arrays are involved. I might be willing to sacrifice speed 
(should it prove to be inconsequential) for an increase in stability. I 
also see the need for some cleanup (did some myself recently). Note, 
There is a memory issue somewhere in the code (along the H263 code path 
to be certain) which causes a crash today and it is causing me some 
pain. If anyone here feels like taking on the problem I would be most 
grateful..

Having said all that, it might take me a little while to getting around 
to inspecting and/or submitting this patch (things are crazy at my day 
job right now), unless someone else in the group would care to step up 
(he said; looking around).

What kind of time frame were you looking at?


Jonathan Hueber wrote:

> Hi,
>
> I had a look through the NativeDecoder and made a few changes to get a
> few more codecs working, namely:
>
>  - mpeg1/2
>  - mpeg4
>  - msmpeg1/2/3
>  - WMV1
>  - mjpeg
>
> The biggest changes are to allow multiple frames appear in the same
> incoming Buffer.  The IBM demultiplexer places MPEG sequences of
> frames into the same base buffer (I assume make handling inverse
> telecine easier).
>
> To this end, the native code returns the quantity of data consumed (0
> not enough data, <0 error).  Also, I have added the CODE_FLAG_TRUNCATED
> option to the ffmpeg calls - this tells ffmpeg to output frame-by-frame.
>
> Next up, I have added code to set the time stamp on outgoing buffers
> correctly (otherwise the video will not play smoothly).  This is based
> on the input framerate.
>
> There are other bits and pieces, but these are more obvious changes.
>
>
> If this is all OK, there is still a fair amount of tidying up.  In
> particular I would like to remove the direct use of undocumented Sun
> methods and classes (e.g. getNativeData()).  This appears to maintain
> a pinned byte array in the JVM, which may be a little faster, but the
> code would be much simpler without it.
>
> Enjoy,
>
> Jonathan H
>
> _________________________________________________________________
> MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
> http://join.msn.com/?page=features/virus


-- 
David Stuart, SIPquest
Email: dave (at) sipquest (dot) com
Phone: 254-8886 x234  Web: http://www.sipquest.com/
Address: 106 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5

[Jffmpeg-devel] Patch to enable more formats in NativeDecoder.

[Jonathan H. <jon...@ho...>]

Hi,

I had a look through the NativeDecoder and made a few changes to get a
few more codecs working, namely:

  - mpeg1/2
  - mpeg4
  - msmpeg1/2/3
  - WMV1
  - mjpeg

The biggest changes are to allow multiple frames appear in the same
incoming Buffer.  The IBM demultiplexer places MPEG sequences of
frames into the same base buffer (I assume make handling inverse
telecine easier).

To this end, the native code returns the quantity of data consumed (0
not enough data, <0 error).  Also, I have added the CODE_FLAG_TRUNCATED
option to the ffmpeg calls - this tells ffmpeg to output frame-by-frame.

Next up, I have added code to set the time stamp on outgoing buffers
correctly (otherwise the video will not play smoothly).  This is based
on the input framerate.

There are other bits and pieces, but these are more obvious changes.


If this is all OK, there is still a fair amount of tidying up.  In
particular I would like to remove the direct use of undocumented Sun
methods and classes (e.g. getNativeData()).  This appears to maintain
a pinned byte array in the JVM, which may be a little faster, but the
code would be much simpler without it.

Enjoy,

Jonathan H

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
http://join.msn.com/?page=features/virus

Re: [Jffmpeg-devel] JMF Codecs

[Jonathan H. <jon...@ho...>]

Hi,

Thanks for the good response.  I have attached the code I have for people 
who are interested in trying it.  I have included a readme file.  You will 
need jmf.jar.

I still need to do a lot of bashing into shape - remove debug statemements, 
add comments, sort out naming conventions, etc.

I have briefly looked through the code on the jffmpeg site and I should be 
able to follow the conventions you are using.

The approach I have is that if you want to use these codecs at all, it is 
because you don't want to use native code (security, crossplatform, or 
perhaps applets).  As such the plan was to have three levels of 
functionality:

- A "decoder only" version that doesn't require JMF (small for applets)
- A JMF wrapper for the above [this is what we have currently]
- A wrapper to fit in seamlessly with your project

So at the end of the day, I would like an extensible infrastructure from:
- No client install what-so-ever [pure Java codecs only]
- Install Java-based JMF on the client
- Full jffmpeg native support

Regards,

Jonathan H




>From: David Stuart <da...@si...>
>To: Jonathan Hueber <jon...@ho...>
>CC: jff...@li...
>Subject: Re: [Jffmpeg-devel] JMF Codecs
>Date: Tue, 13 Jul 2004 09:01:45 -0400
>
>Hi Jonathan,
>
>So initially our project's goal was simply to encapsulate the native codecs 
>in ffmpeg.
>
>But, that being said, I see no problem with adding new java codecs (or for 
>that matter, having both a java version and a native version available- 
>like JMF already does with some).
>
>There will be a little infrastructure work required, probably. If you want 
>to pursue it I would recommend taking a copy of the code and working 'off 
>stream' for awhile (the code is not churning very much these days). Then 
>come back to us when you're ready. Make sure it works within the JMF Studio 
>application (a reasonable simulation of JMF apps in general).
>
>
>Jonathan Hueber wrote:
>
>>Hi,
>>
>>I have been searching around Sourceforge for a while and it seems that you 
>>guys are the closest project to what I am looking for.
>>
>>I have ported some codecs from ffmpeg to pure Java.  Namely:
>>   - mpeg 1 and 2
>>   - div3
>>   - a52
>>   - mp3
>>   - vob demux
>>
>>This is enough to give me a working Java DVD player (on a very fast 
>>computer!)
>>
>>I am trying to decide whether:
>>   1)  Try to include my work with your project
>>   2)  Tack on to the original ffmpeg project
>>   3)  Start a new sourceforge project.
>>
>>Are you interested in this as part of your project?
>>
>>Regards,
>>
>>Jonathan H
>>
>>_________________________________________________________________
>>The new MSN 8: smart spam protection and 2 months FREE*  
>>http://join.msn.com/?page=features/junkmail
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email sponsored by Black Hat Briefings & Training.
>>Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self 
>>defense, top technical experts, no vendor pitches, unmatched networking 
>>opportunities. Visit www.blackhat.com
>>_______________________________________________
>>Jffmpeg-devel mailing list
>>Jff...@li...
>>https://lists.sourceforge.net/lists/listinfo/jffmpeg-devel
>
>
>--
>David Stuart, SIPquest
>Email: dave (at) sipquest (dot) com
>Phone: 254-8886 x234  Web: http://www.sipquest.com/
>Address: 106 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5
>
>
>

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

Re: [Jffmpeg-devel] JMF Codecs

[David S. <da...@si...>]

Hi Jonathan,

So initially our project's goal was simply to encapsulate the native 
codecs in ffmpeg.

But, that being said, I see no problem with adding new java codecs (or 
for that matter, having both a java version and a native version 
available- like JMF already does with some).

There will be a little infrastructure work required, probably. If you 
want to pursue it I would recommend taking a copy of the code and 
working 'off stream' for awhile (the code is not churning very much 
these days). Then come back to us when you're ready. Make sure it works 
within the JMF Studio application (a reasonable simulation of JMF apps 
in general).


Jonathan Hueber wrote:

> Hi,
>
> I have been searching around Sourceforge for a while and it seems that 
> you guys are the closest project to what I am looking for.
>
> I have ported some codecs from ffmpeg to pure Java.  Namely:
>   - mpeg 1 and 2
>   - div3
>   - a52
>   - mp3
>   - vob demux
>
> This is enough to give me a working Java DVD player (on a very fast 
> computer!)
>
> I am trying to decide whether:
>   1)  Try to include my work with your project
>   2)  Tack on to the original ffmpeg project
>   3)  Start a new sourceforge project.
>
> Are you interested in this as part of your project?
>
> Regards,
>
> Jonathan H
>
> _________________________________________________________________
> The new MSN 8: smart spam protection and 2 months FREE*  
> http://join.msn.com/?page=features/junkmail
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
> self defense, top technical experts, no vendor pitches, unmatched 
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Jffmpeg-devel mailing list
> Jff...@li...
> https://lists.sourceforge.net/lists/listinfo/jffmpeg-devel


-- 
David Stuart, SIPquest
Email: dave (at) sipquest (dot) com
Phone: 254-8886 x234  Web: http://www.sipquest.com/
Address: 106 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5

[Jffmpeg-devel] JMF Codecs

[Jonathan H. <jon...@ho...>]

Hi,

I have been searching around Sourceforge for a while and it seems that you 
guys are the closest project to what I am looking for.

I have ported some codecs from ffmpeg to pure Java.  Namely:
   - mpeg 1 and 2
   - div3
   - a52
   - mp3
   - vob demux

This is enough to give me a working Java DVD player (on a very fast 
computer!)

I am trying to decide whether:
   1)  Try to include my work with your project
   2)  Tack on to the original ffmpeg project
   3)  Start a new sourceforge project.

Are you interested in this as part of your project?

Regards,

Jonathan H

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

Re: [Jffmpeg-devel] Re: Related with jffmpeg

[Stephen D. <go...@is...>]

Hi Omer.

Thanks for the complement, but I am not a Sun Developer, just a Java guy 
that has been around for a while.  Check out http://j2eeguys.com if you 
want some extra details.

Regards,
Steve

David Stuart wrote:

> I've cc-ed the devel list, just in case.
>
> Although the end goal of the project is to support all of the ffmpeg 
> types of codecs in the JMF wrappers, we are still quite a ways away 
> from this today. It might be easy or it might be hard to add 3gp 
> (presumably we are talking about coding and decoding this to/from a 
> file, and not sending over RTP) .. but I can't really offer you any 
> guarantees.
>
> avi and mov if I'm not mistaken are container files. What codecs are 
> we talking, here?
>
> Anyway currently we only are really working with H263, and to some 
> extent MPG (though the support for that might need to be fixed). So as 
> you can see what we have probably won't do the trick for you.
>
> But, if you like, please download the source code and have a look at it.
>
>

-- 
Java/J2EE Developer/Integrator
Chair, Dallas/FortWorth J2EE Sig
214-724-7741

[Jffmpeg-devel] Re: Related with jffmpeg

[David S. <da...@si...>]

I've cc-ed the devel list, just in case.

Although the end goal of the project is to support all of the ffmpeg 
types of codecs in the JMF wrappers, we are still quite a ways away from 
this today. It might be easy or it might be hard to add 3gp (presumably 
we are talking about coding and decoding this to/from a file, and not 
sending over RTP) .. but I can't really offer you any guarantees.

avi and mov if I'm not mistaken are container files. What codecs are we 
talking, here?

Anyway currently we only are really working with H263, and to some 
extent MPG (though the support for that might need to be fixed). So as 
you can see what we have probably won't do the trick for you.

But, if you like, please download the source code and have a look at it.


Omer Faruk Kurt wrote:

>Currently, I am developing a project related with 3gp movies. My aim
>is to convert 3gp to avi or mov and avi or mov to 3gp. I am using JMF
>and as you they are not supporting 3gp format. I contacted with a sun
>developer and he made two suggestions. The first one is to use ffmpeg
>through JNI or Jexec (which I don't prefer until there is no way). The
>other suggestion is that to contact with the developers of Jffmpeg.
>
>So,I need your help about your project. What is the project's
>position? Are you able to do this conversion? Or what conversions are
>you supporting?
>
>I really need your help...
>
>Thanks in advance...
>
>Omer Faruk Kurt
>  
>

-- 
David Stuart, SIPquest
Email: dave (at) sipquest (dot) com
Phone: 254-8886 x234  Web: http://www.sipquest.com/
Address: 106 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5

[Jffmpeg-devel] bug fixes, and slight simplification

[David S. <da...@si...>]

Hi Guys,

Just to let you know I recently checked in some code for some bug-fixes 
(causing VM crash), and I also simplified the JMF format negotiation code.

-- 
David Stuart, SIPquest
Email: dave (at) sipquest (dot) com
Phone: 254-8886 x234  Web: http://www.sipquest.com/
Address: 106 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5

Re: [Jffmpeg-devel] State of the project...

[Stephen D. <go...@fr...>]

Luca Foschini wrote:
> Hi all!
> I was wondering if the jffmpeg project is still active, as its homepage 
> seems to be empty...
> 
> Can anyone tell me sth. about it?!?
> 
> Thanks in advance!
> 
> Luca
> 
> 
It is still quite active, although there is not much traffic on the mailing
list.

Currently, there are two main "revisions";
r-0-0-0, which is compatible with FFMPEG CVS HEAD
HEAD, which is compatbile with FFMpeg 0.4.7
   - needs the (supplied) patch to work
   - Supplies H263 & H263_RTP protocols

There are a couple of firms that are actively developing/maintaining this
project.  At least two firms are using it for mission critical applications.
Although, not being a large project, there are not a lot of developers
actually dedicated here, but there are two or three, who are (mostly if
not entirely) corporate sponsored.

Regards,
Steve

-- 
Java/J2EE Developer/Integrator
Chair, Dallas/FortWorth J2EE Sig
214-724-7741

Re: [Jffmpeg-devel] State of the project...

[David S. <da...@si...>]

It is active (though somewhat sluggish).

It's homepage is empty mainly because nobody bothered to update the 
sourceforge page. All the activity is in CVS at the moment, and on the 
mailing list.

What do you want to know?


Luca Foschini wrote:

> Hi all!
> I was wondering if the jffmpeg project is still active, as its 
> homepage seems to be empty...
>
> Can anyone tell me sth. about it?!?
>
> Thanks in advance!
>
> Luca
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Jffmpeg-devel mailing list
> Jff...@li...
> https://lists.sourceforge.net/lists/listinfo/jffmpeg-devel


-- 
David Stuart, SIPquest
Email: dave (at) sipquest (dot) com
Phone: 254-8886 x234  Web: http://www.sipquest.com/
Address: 106 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5

[Jffmpeg-devel] State of the project...

[Luca F. <luc...@st...>]

Hi all!
I was wondering if the jffmpeg project is still active, as its homepage 
seems to be empty...

Can anyone tell me sth. about it?!?

Thanks in advance!

Luca

Re: [Jffmpeg-devel] updates etc.

[David S. <da...@si...>]

Hi All,

The deed is done.

The old version (should people still want access to it) has been tagged 
with the name "r0-0-0" (Since to my knowledge we have not released a 
version of jffmpeg yet).

I updated the README to include some new steps.

Let me know if/when you have some trouble with it. ;)


Bill Snyder wrote:

>Hi David,
>
>Would you mind tagging the cvs repository before you do your check in?
>That would make it easy for others to grab the version that isn't dependant
>upon ffmpeg 0.4.7.
>
>Thanks,
>Bill
>
>----- Original Message ----- 
>From: "David Stuart" <da...@si...>
>To: <jff...@li...>
>Sent: Friday, March 19, 2004 8:13 AM
>Subject: [Jffmpeg-devel] updates etc.
>
>
>  
>
>>Hi All,
>>
>>As you might have noticed, I've been quite busy at work lately, and I 
>>still haven't gotten around to checking in my update for jffmpeg..
>>
>>Actually the update is more or less ready, but I was originally planning 
>>on trying to incorporate some other functionality before checking in. I 
>>now find I don't really have the time to do this.
>>
>>As you know, there are two remaining problems with my update:
>>- MPEG support temporarily removed in this update (it doesn't work in 
>>the current load but there are a few people who know how to fix it on 
>>this mailing list)
>>- It will introduce a dependency on ffmpeg-0.4.7 because of the h263_rtp 
>>packetization. We had previously resolved to work around this with 
>>compiler directives.
>>
>>At the moment I don't have time to address these issues BEFORE I check 
>>it in (the task keeps getting postponed), and I don't want to continue 
>>to deny the JMF community the improvements in H263 and H263_RTP (they 
>>really are striking, the ffmpeg version is a LOT faster). So, would it 
>>be OK if I just checked it in, and then employed the magic of open 
>>source to allow the rest of the group to re-add MPEG support and to 
>>remove the ffmpeg-0.4.7 dependency at compile-time?
>>
>>
>>-- 
>>David Stuart, SIPquest
>>Email: dave (at) sipquest (dot) com
>>Phone: 254-8886 x234  Web: http://www.sipquest.com/
>>Address: 106 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: IBM Linux Tutorials
>>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>>GenToo technologies. Learn everything from fundamentals to system
>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>>_______________________________________________
>>Jffmpeg-devel mailing list
>>Jff...@li...
>>https://lists.sourceforge.net/lists/listinfo/jffmpeg-devel
>>
>>    
>>

-- 
David Stuart, SIPquest
Email: dave (at) sipquest (dot) com
Phone: 254-8886 x234  Web: http://www.sipquest.com/
Address: 106 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5

Re: [Jffmpeg-devel] updates etc.

[David S. <da...@si...>]

Oh yes, I was going to suggest that as well. Good idea.

Bill Snyder wrote:

>Hi David,
>
>Would you mind tagging the cvs repository before you do your check in?
>That would make it easy for others to grab the version that isn't dependant
>upon ffmpeg 0.4.7.
>
>Thanks,
>Bill
>
>----- Original Message ----- 
>From: "David Stuart" <da...@si...>
>To: <jff...@li...>
>Sent: Friday, March 19, 2004 8:13 AM
>Subject: [Jffmpeg-devel] updates etc.
>
>
>  
>
>>Hi All,
>>
>>As you might have noticed, I've been quite busy at work lately, and I 
>>still haven't gotten around to checking in my update for jffmpeg..
>>
>>Actually the update is more or less ready, but I was originally planning 
>>on trying to incorporate some other functionality before checking in. I 
>>now find I don't really have the time to do this.
>>
>>As you know, there are two remaining problems with my update:
>>- MPEG support temporarily removed in this update (it doesn't work in 
>>the current load but there are a few people who know how to fix it on 
>>this mailing list)
>>- It will introduce a dependency on ffmpeg-0.4.7 because of the h263_rtp 
>>packetization. We had previously resolved to work around this with 
>>compiler directives.
>>
>>At the moment I don't have time to address these issues BEFORE I check 
>>it in (the task keeps getting postponed), and I don't want to continue 
>>to deny the JMF community the improvements in H263 and H263_RTP (they 
>>really are striking, the ffmpeg version is a LOT faster). So, would it 
>>be OK if I just checked it in, and then employed the magic of open 
>>source to allow the rest of the group to re-add MPEG support and to 
>>remove the ffmpeg-0.4.7 dependency at compile-time?
>>
>>
>>-- 
>>David Stuart, SIPquest
>>Email: dave (at) sipquest (dot) com
>>Phone: 254-8886 x234  Web: http://www.sipquest.com/
>>Address: 106 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: IBM Linux Tutorials
>>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>>GenToo technologies. Learn everything from fundamentals to system
>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>>_______________________________________________
>>Jffmpeg-devel mailing list
>>Jff...@li...
>>https://lists.sourceforge.net/lists/listinfo/jffmpeg-devel
>>
>>    
>>

-- 
David Stuart, SIPquest
Email: dave (at) sipquest (dot) com
Phone: 254-8886 x234  Web: http://www.sipquest.com/
Address: 106 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5

Re: [Jffmpeg-devel] updates etc.

[Bill S. <bi...@gw...>]

Hi David,

Would you mind tagging the cvs repository before you do your check in?
That would make it easy for others to grab the version that isn't dependant
upon ffmpeg 0.4.7.

Thanks,
Bill

----- Original Message ----- 
From: "David Stuart" <da...@si...>
To: <jff...@li...>
Sent: Friday, March 19, 2004 8:13 AM
Subject: [Jffmpeg-devel] updates etc.


> Hi All,
> 
> As you might have noticed, I've been quite busy at work lately, and I 
> still haven't gotten around to checking in my update for jffmpeg..
> 
> Actually the update is more or less ready, but I was originally planning 
> on trying to incorporate some other functionality before checking in. I 
> now find I don't really have the time to do this.
> 
> As you know, there are two remaining problems with my update:
> - MPEG support temporarily removed in this update (it doesn't work in 
> the current load but there are a few people who know how to fix it on 
> this mailing list)
> - It will introduce a dependency on ffmpeg-0.4.7 because of the h263_rtp 
> packetization. We had previously resolved to work around this with 
> compiler directives.
> 
> At the moment I don't have time to address these issues BEFORE I check 
> it in (the task keeps getting postponed), and I don't want to continue 
> to deny the JMF community the improvements in H263 and H263_RTP (they 
> really are striking, the ffmpeg version is a LOT faster). So, would it 
> be OK if I just checked it in, and then employed the magic of open 
> source to allow the rest of the group to re-add MPEG support and to 
> remove the ffmpeg-0.4.7 dependency at compile-time?
> 
> 
> -- 
> David Stuart, SIPquest
> Email: dave (at) sipquest (dot) com
> Phone: 254-8886 x234  Web: http://www.sipquest.com/
> Address: 106 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Jffmpeg-devel mailing list
> Jff...@li...
> https://lists.sourceforge.net/lists/listinfo/jffmpeg-devel
> 

Re: [Jffmpeg-devel] updates etc.

[Stephen D. <go...@fr...>]

David Stuart wrote:
> Hi All,
> 
> As you might have noticed, I've been quite busy at work lately, and I 
> still haven't gotten around to checking in my update for jffmpeg..
> 
> Actually the update is more or less ready, but I was originally planning 
> on trying to incorporate some other functionality before checking in. I 
> now find I don't really have the time to do this.
> 
> As you know, there are two remaining problems with my update:
> - MPEG support temporarily removed in this update (it doesn't work in 
> the current load but there are a few people who know how to fix it on 
> this mailing list)
> - It will introduce a dependency on ffmpeg-0.4.7 because of the h263_rtp 
> packetization. We had previously resolved to work around this with 
> compiler directives.
> 
> At the moment I don't have time to address these issues BEFORE I check 
> it in (the task keeps getting postponed), and I don't want to continue 
> to deny the JMF community the improvements in H263 and H263_RTP (they 
> really are striking, the ffmpeg version is a LOT faster). So, would it 
> be OK if I just checked it in, and then employed the magic of open 
> source to allow the rest of the group to re-add MPEG support and to 
> remove the ffmpeg-0.4.7 dependency at compile-time?
> 
> 
Hi David.

Not currently a problem from me.  I am currently not working on this
particular project, so no argument here.  Unfortunately, due to time
demands by what I AM working on, no support currently available,
either.

Bottom line?  I have no objection.

Regards,
Steve


-- 
Java/J2EE Developer/Integrator
Co-Chair, Dallas/FortWorth J2EE Sig
214-724-7741

[Jffmpeg-devel] updates etc.

[David S. <da...@si...>]

Hi All,

As you might have noticed, I've been quite busy at work lately, and I 
still haven't gotten around to checking in my update for jffmpeg..

Actually the update is more or less ready, but I was originally planning 
on trying to incorporate some other functionality before checking in. I 
now find I don't really have the time to do this.

As you know, there are two remaining problems with my update:
- MPEG support temporarily removed in this update (it doesn't work in 
the current load but there are a few people who know how to fix it on 
this mailing list)
- It will introduce a dependency on ffmpeg-0.4.7 because of the h263_rtp 
packetization. We had previously resolved to work around this with 
compiler directives.

At the moment I don't have time to address these issues BEFORE I check 
it in (the task keeps getting postponed), and I don't want to continue 
to deny the JMF community the improvements in H263 and H263_RTP (they 
really are striking, the ffmpeg version is a LOT faster). So, would it 
be OK if I just checked it in, and then employed the magic of open 
source to allow the rest of the group to re-add MPEG support and to 
remove the ffmpeg-0.4.7 dependency at compile-time?


-- 
David Stuart, SIPquest
Email: dave (at) sipquest (dot) com
Phone: 254-8886 x234  Web: http://www.sipquest.com/
Address: 106 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5

Re: [Jffmpeg-devel] libavformat incorporation

[David S. <da...@si...>]

Yes that is true, nothing in libavformat is being used in jffmpeg at the 
moment. To my knowledge nobody is looking into this. By all means, 
please look into it (just let us know before you check anything in as 
there are some updates brewing in the pipe).


Bill Snyder wrote:

>Hi All,
>
>From the looks of things,  it appears that there has been no effort
>to incorporate libavformat into jffmpeg.  Before I start looking into
>what this might take, I just wanted to make sure that there isn't already
>an effort under way to do this.  It seems to me that this is a pretty
>critical thing have since some of the codec formats supported by
>libavcodec are not supported by any of the linux JMF multiplexers.
>
>Thanks,
>Bill
>  
>
-- 
David Stuart, SIPquest
Email: dave (at) sipquest (dot) com
Phone: 254-8886 x234  Web: http://www.sipquest.com/
Address: 106 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5

[Jffmpeg-devel] libavformat incorporation

[Bill S. <bi...@gw...>]

Hi All,

From the looks of things,  it appears that there has been no effort
to incorporate libavformat into jffmpeg.  Before I start looking into
what this might take, I just wanted to make sure that there isn't already
an effort under way to do this.  It seems to me that this is a pretty
critical thing have since some of the codec formats supported by
libavcodec are not supported by any of the linux JMF multiplexers.

Thanks,
Bill

Re: [Jffmpeg-devel] project direction?

[Stephen D. <go...@fr...>]

Bill Snyder wrote:
> Hi David,
> 
> 
> - Try to use compiler directives for the 263/RTP part to remove the 
>    0.4.7 dependency at compile time
> - Create a separate branch just for H263_RTP
> - Fold everything into the main project causing the 0.4.7 dependency
> 
> Thanks,
> Bill
> 
> 
Hi Guys.

+1 from me for Bill's suggestion.

Regards,
Steve
-- 
Java/J2EE Developer/Integrator
Co-Chair, Dallas/FortWorth J2EE Sig
214-724-7741