Android Developer Friendly Version
174 views
Skip to first unread message
Edison Wang
Apr 10, 2013, 8:58:48 PM4/10/13
to jjmpeg-...@googlegroups.com
Hey Michael,
First of all, thank you again for the JJMpeg library. Is there a way that I can help contribute to the project? I'm thinking of posting the jjmpeg folder as a LGPL strict project on Github, but I will be more than happy to merge in any changes that I make to the Google Code repository as well. I'm thinking of making a more Android development friendly version (such as adding support for TextureView, etc.) so that the community can better benefit from it.
Sincerely,
Edison
Michael Zucchi
Apr 11, 2013, 2:00:18 AM4/11/13
to jjmpeg-...@googlegroups.com
Hi Edison,
Well as you know there is already a GPLv3 branch which includes support
for FFmpeg 1.0 and android. I personally don't want to recreate that
work myself (or relicense it; otherwise i wouldn't have chosen GPLv3 for
that work to start with).
But as the project is free software you're obviously welcome to fork the
LGPL version so long as you don't include any of the GPL code from the
other branch - this includes any of the generator scripts in the
jjmpeg-1.0 branch, Android frontend code, and so on.
However, I am using jjmpeg-head for an in-house project including
android as of a couple of weeks ago, so I would accept patches there.
Currently the jar file isn't fully functional as is in android as some
of the high level classes (JJMedia*) use Java2D stuff. I was thinking
of creating a JJMediaReader that uses factory methods for creating the
sub-streams, and an overriding implementation could provide platform
specific utilities such as javafx, java2d, or android image support.
The build probably needs breaking out in a similar way to the jjmpeg-1.0
branch, and including some extra JNI for handling Android objects like
Bitmap more efficiently. I would only accept patches that retain the
ability to build the java inside Netbeans as for all it's warts that is
what I use.
Perhaps a similar layout to the jjmpeg-1.0 branch would work, although I
also experimented with a build that placed the platform specific project
junk inside a sub-directory. I would like to know if you (or anyone
else) have any thoughts on something more elegant. maven or any other
build system isn't more elegant.
LGPL adds some complications to distributing android applications
including other non-copyleft code - a user must be able to replace the
LGPL classes in the actual apk; just distributing the source of the LGPL
components is insufficient. e.g.
http://code.google.com/p/droidtext/wiki/LGPLCompliance Note that this
complication doesn't arise with the GPLv3 branch as the source for the
full application must be available anyway. Nor does it occur when
projects have their own jni code and are just using .so files from
FFmpeg as the .so files can be replaced after installation (even if it
requires a root login).
FWIW There isn't any community that i'm aware of. A search in the
internet shows that the only valid mentions of jjmpeg is my blog or a
couple of links on stackoverflow. If people are using it they're not
sharing that fact.
Z
> You received this message because you are subscribed to the Google
> Groups "jjmpeg-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jjmpeg-discus...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
Edison Wang
Apr 11, 2013, 11:47:23 AM4/11/13
to jjmpeg-...@googlegroups.com
Hi Michael,
Thanks for taking time to write a detailed reply.
I don't think it will have any of the JJ-prefixed classes but the layout should be similar to the layout on jjmpeg-1.0 (it will have the trunk, and an Android Library Project that uses it to produce the java bindings that can be used, which will simply build the code) but I think the build system should definitely better. Isolate ffmpeg into separate .so library files when build etc. I am not sure what will end up happen yet.
My goal is to make so that there is an easy way for people to build the low level code that controls jjmpeg. The high level code will not there for LGPL compliance (which is the same reason your samples and jjmpeg-1.0, the code in jjmpeg-android and jjmpeg demos are excellent examples but GPL-ed).
I read your blog on the project that you are working on, it looks very promising, and I wish you the best with it. :)
As for the community, I'm more or less referring to the devs that just want simple ffmpeg with java bindings to use (I found yours to be one of the most complete).
Thanks again for a great library,
Edison
Michael Zucchi
Apr 11, 2013, 8:41:51 PM4/11/13
to jjmpeg-...@googlegroups.com
Morning,
On 12/04/13 01:17, Edison Wang wrote:
> Thanks for taking time to write a detailed reply.
>
> I don't think it will have any of the JJ-prefixed classes but the layout
> should be similar to the layout on jjmpeg-1.0 (it will have the trunk,
> and an Android Library Project that uses it to produce the java bindings
> that can be used, which will simply build the code) but I think the
> build system should definitely better. Isolate ffmpeg into separate .so
> library files when build etc. I am not sure what will end up happen yet.
I guess you would have noticed that I recently added some android
support to the head version. It works by dlopening the raw libraries
directly. I didn't commit the ffmpeg build script yet although it's
just a slight modification to the one in the v1 branch. It mostly 'just
works' but there is a bit of a pain with some detail I can't recall
right now (something configure gets wrong) but that might be due to it
being an older FFmpeg build too. IIRC there is also a pain with the way
android doesn't add the application lib directory to the ld load path
(ffs ...), so one needs to manually open the libraries in the correct
order. What is the point of a lib directory specifically intended for
shared libraries, and then not adding it to the path?
Using the stuff generated isn't too hard with other android projects,
just need to include all the shared libraries in the Android.mk and put
the jar file in libs. I don't know if there is a "shared library" way
to do it on android between separate applications, or if that is even
desirable. An extra 4mb to the download isn't much these days.
> My goal is to make so that there is an easy way for people to build the
> low level code that controls jjmpeg. The high level code will not there
> for LGPL compliance (which is the same reason your samples and
> jjmpeg-1.0, the code in jjmpeg-android and jjmpeg demos are excellent
> examples but GPL-ed).
Ok yeah, makes sense.
The build system is perfect for me as in a couple of seconds I can
rebuild everything for every platform I have compilers for (gnu
x86/amd64, ms x86/amd64, gnu arm 32, android arm 32). I don't consider
any microsoft platform a viable development environment so i'll never
support it other than as a 'legacy target'.
BTW let me say i'm kind of in two minds about your fork - in some way
i'd like to influence it a bit and include stuff back into jjmpeg, but
I'm also considering that i'd rather just let it "go free" and let you
have a go with whatever you want to do and i'll keep working in
isolation as it already does what i need and I have other more
interesting stuff to play with.
> I read your blog on the project that you are working on, it looks very
> promising, and I wish you the best with it. :)
I'm always working on something, ... but I never seem to finish
anything. Once the fun and/or learning bits are out of the way I
usually lose interest (i prefer to be paid to do boring bits!), but it's
a bit early to tell on that one. I'll eventually drop the code at some
point; finished or otherwise. It's at the point (apart from sound) it
needs a lot of fluffy ui work which I tend to find a bit boring and
time-consuming. Or frustrating if it involves fighting with the fancy
and ill-behaving widgets everyone expects.
> As for the community, I'm more or less referring to the devs that just
> want simple ffmpeg with java bindings to use (I found yours to be one of
> the most complete).
Well there's been a good few downloads, just no free software using it
that I know of.
I rambled on a bit here with some history and thoughts on C binding to
Java ...
Many libraries seem to be over-engineered for no apparent reason other
than because they can. I'm also much more fond of pull interfaces
rather than callback/listener ones, since it's much easier to implement
callbacks ontop of that than the other way around, and often it's easier
just writing stuff to use a pull version. FFmpeg already has a mostly
good and usable api (AVDictionary though?), so wrapping it in objects
wasn't that difficult (tracking changes is more of a hassle mind you
particularly since the libav fork, which is why i don't care to very often).
I found xuggle impossible to compile even on GNU let alone a
cross-compile, and the callback interface a bit of a pain to use anyway
although all the kids seem to like that approach. The design based on a
giant hard-to-compile c++ library then wrapped in jni just seemed odd
and sub-optimal. It's memory management is crazily complex too. jjmpeg
pretty much came into existence as I needed a 64-bit microsoft version
of xuggle and really had no other practical option.
The code generator is a bit crap ... but it works and I think the
approach is sound. Leaving the C-specific stuff like address offset
calculations to a C compiler is a lot saner than trying to compile it
separately and then wrap it in Java-side accessors. JNI is simple and
sane enough that it doesn't need wrapping in some 'framework' to be
usable. The problem with frameworks is they only solve the problems
they're designed to solve - every c library has a different
convention/approach to their apis, and all you end up with is some
horrible to use tool that you end up developing and then fighting with
rather than solving the problem at hand. The jjmpeg codegen is bad but
at least it's tailor made and not cluttered with 'general support' that
is not needed.
I think JOCL is great, but it's binding is based on a gigantic compiler
and code generator framework which is a pain to configure and use and
builds very slowly, and despite all that work and effort and code it is
still too tied to the open* api conventions to be able to use it as a
general binding tool. They have figured out the distribution and
deployment angle though.
I've also done some C# native binding previously and although on paper
all that support for native interfacing looks great ... it's actually a
huge pain if you're doing more than a couple of simple functions (funny
that: pretty much any microsoft technology in a nutshell, great for rad
prototyping, but that is all). Once you add structures it becomes a
maintenance headache. You end up needing a custom c to c# compiler and
buggerising around no end. And the mashalling mechanism for structures
is ... poor. This is why I think JNA also sucks - seems like a good
idea but it isn't.
Z
On 12/04/13 01:17, Edison Wang wrote:
> Thanks for taking time to write a detailed reply.
>
> I don't think it will have any of the JJ-prefixed classes but the layout
> should be similar to the layout on jjmpeg-1.0 (it will have the trunk,
> and an Android Library Project that uses it to produce the java bindings
> that can be used, which will simply build the code) but I think the
> build system should definitely better. Isolate ffmpeg into separate .so
> library files when build etc. I am not sure what will end up happen yet.
support to the head version. It works by dlopening the raw libraries
directly. I didn't commit the ffmpeg build script yet although it's
just a slight modification to the one in the v1 branch. It mostly 'just
works' but there is a bit of a pain with some detail I can't recall
right now (something configure gets wrong) but that might be due to it
being an older FFmpeg build too. IIRC there is also a pain with the way
android doesn't add the application lib directory to the ld load path
(ffs ...), so one needs to manually open the libraries in the correct
order. What is the point of a lib directory specifically intended for
shared libraries, and then not adding it to the path?
Using the stuff generated isn't too hard with other android projects,
just need to include all the shared libraries in the Android.mk and put
the jar file in libs. I don't know if there is a "shared library" way
to do it on android between separate applications, or if that is even
desirable. An extra 4mb to the download isn't much these days.
> My goal is to make so that there is an easy way for people to build the
> low level code that controls jjmpeg. The high level code will not there
> for LGPL compliance (which is the same reason your samples and
> jjmpeg-1.0, the code in jjmpeg-android and jjmpeg demos are excellent
> examples but GPL-ed).
The build system is perfect for me as in a couple of seconds I can
rebuild everything for every platform I have compilers for (gnu
x86/amd64, ms x86/amd64, gnu arm 32, android arm 32). I don't consider
any microsoft platform a viable development environment so i'll never
support it other than as a 'legacy target'.
BTW let me say i'm kind of in two minds about your fork - in some way
i'd like to influence it a bit and include stuff back into jjmpeg, but
I'm also considering that i'd rather just let it "go free" and let you
have a go with whatever you want to do and i'll keep working in
isolation as it already does what i need and I have other more
interesting stuff to play with.
> I read your blog on the project that you are working on, it looks very
> promising, and I wish you the best with it. :)
anything. Once the fun and/or learning bits are out of the way I
usually lose interest (i prefer to be paid to do boring bits!), but it's
a bit early to tell on that one. I'll eventually drop the code at some
point; finished or otherwise. It's at the point (apart from sound) it
needs a lot of fluffy ui work which I tend to find a bit boring and
time-consuming. Or frustrating if it involves fighting with the fancy
and ill-behaving widgets everyone expects.
> As for the community, I'm more or less referring to the devs that just
> want simple ffmpeg with java bindings to use (I found yours to be one of
> the most complete).
that I know of.
I rambled on a bit here with some history and thoughts on C binding to
Java ...
Many libraries seem to be over-engineered for no apparent reason other
than because they can. I'm also much more fond of pull interfaces
rather than callback/listener ones, since it's much easier to implement
callbacks ontop of that than the other way around, and often it's easier
just writing stuff to use a pull version. FFmpeg already has a mostly
good and usable api (AVDictionary though?), so wrapping it in objects
wasn't that difficult (tracking changes is more of a hassle mind you
particularly since the libav fork, which is why i don't care to very often).
I found xuggle impossible to compile even on GNU let alone a
cross-compile, and the callback interface a bit of a pain to use anyway
although all the kids seem to like that approach. The design based on a
giant hard-to-compile c++ library then wrapped in jni just seemed odd
and sub-optimal. It's memory management is crazily complex too. jjmpeg
pretty much came into existence as I needed a 64-bit microsoft version
of xuggle and really had no other practical option.
The code generator is a bit crap ... but it works and I think the
approach is sound. Leaving the C-specific stuff like address offset
calculations to a C compiler is a lot saner than trying to compile it
separately and then wrap it in Java-side accessors. JNI is simple and
sane enough that it doesn't need wrapping in some 'framework' to be
usable. The problem with frameworks is they only solve the problems
they're designed to solve - every c library has a different
convention/approach to their apis, and all you end up with is some
horrible to use tool that you end up developing and then fighting with
rather than solving the problem at hand. The jjmpeg codegen is bad but
at least it's tailor made and not cluttered with 'general support' that
is not needed.
I think JOCL is great, but it's binding is based on a gigantic compiler
and code generator framework which is a pain to configure and use and
builds very slowly, and despite all that work and effort and code it is
still too tied to the open* api conventions to be able to use it as a
general binding tool. They have figured out the distribution and
deployment angle though.
I've also done some C# native binding previously and although on paper
all that support for native interfacing looks great ... it's actually a
huge pain if you're doing more than a couple of simple functions (funny
that: pretty much any microsoft technology in a nutshell, great for rad
prototyping, but that is all). Once you add structures it becomes a
maintenance headache. You end up needing a custom c to c# compiler and
buggerising around no end. And the mashalling mechanism for structures
is ... poor. This is why I think JNA also sucks - seems like a good
idea but it isn't.
Z
Edison Wang
Apr 12, 2013, 5:12:46 PM4/12/13
to jjmpeg-...@googlegroups.com
1. Build Script:
Yea, I think that's the first thing I will start with. I got ffmpeg to work with someone else's script, but I think I will have a more bloated version with encoders since I will need to do some encoding with ffmpeg as well. (I am new to all of this. even though I have done lots of Android in the past, I just graduated with an non-software engineering degree, most of this is a learning process for me)....so it may take a while for me to have anything working at all, haha.
2. Make it simple:
I agree that some parts may be a little more "over-engineered" to fit all your needs (which is important), but I have to say I do really like the queues in there. It's very easy to follow and trace the code. I think I will do it this way too since controlling threads seem to be less error prone here than using listeners.
3. Leaving you alone or contributing:
Not sure if you will like my code since I am pretty new to the JNI stuff, but I will definitely let you know if I found something crucially wrong or something that I think will benefit those who may need it one day. And of course I am very happy to help you with anything Android at Java level. :) I really like what you are doing here and I don't think I am alone.
Cheers,
Edison
Michael Zucchi
Apr 24, 2013, 9:44:41 PM4/24/13
to jjmpeg-...@googlegroups.com
So i've had word from Edison that jjmpeg didn't serve his needs so I
suspect this fork is likewise dead.
Personally I don't think jjmpeg is really suitable for a general purpose
player, jjplayer was just an experiment.
It is more useful where the current "media" api's suck: reading raw
video/audio signals for further processing, or dealing with "in the
wild" formats: i.e. anything other than to-spec mpeg 4.
!Z
Reply all
Reply to author
Forward
0 new messages