win32 built

[Nick Scheithauer]

Is there already a jjmpeg win32 prebuilt or a tutorial explaining how
to built it? I want to use jjmpeg but i've just worked with java yet
and i dont understand how all this "built" stuff works :(

[Michael Zucchi]

Hi Nick,

It only compiles using GNU/Linux; the READMEs should have enough info,
but it's really only for people who know what they're doing.

It also needs a microsoft compatible build of ffmpeg's libraries which
may be hard to get - i.e. even if i build it, it will be against a
version I downloaded from zeranoe.com, which changes often - and I don't
want to distribute one of these myself as then I would have to
distribute all the source archives as well. There are other deployment
issues as well: you're on your own there.

FWIW I don't think i've even seen a 32-bit microsoft machine for over 5
years myself, so it does seem a bit legacy as far as i'm concerned.

It just so happens I intend to look at doing some packaging at some
point soon (maybe even this afternoon, too hung-over to do much else)
... and I just found the 32-bit microsoft build tools in Fedora, so you
may be in luck as it was trivial to compile a version - so I will
probably do a 32-bit microsoft build as well since it isn't costing me
any time.

Once I do a release, I will be removing the existing .dll/.so files as
they should never have been checked in in the first place.

Regards,
Michael

[Nick Scheithauer]

thank you so much :)
i got it all working and all works quite well an fast.
you're the best!

[Nick Scheithauer]

btw is there a method for decoding audio backward?

[Michael Zucchi]

On 21/03/12 22:34, Nick Scheithauer wrote:
> btw is there a method for decoding audio backward?
>

This doesn't make any sense, the encoded bit streams only decode one way
(that is what 'streaming' means).

But to reverse the playback or re-encoding, decode it forward first and
then reverse the samples (somewhat obviously).

!Z

[Nick Scheithauer]

but what if i want to decode and playback in realtime?
i thought about seeking backward one frame, then decoding forward one
frame and so on..
but it seems not to work quit well and it seems that the
AVCodecContext doesn't flush its buffers correctly so seeking also
doesn't work quite smooth :´(

[Michael Zucchi]

On 22/03/12 20:42, Nick Scheithauer wrote:
> but what if i want to decode and playback in realtime?
> i thought about seeking backward one frame, then decoding forward one
> frame and so on..

It's not something i would even think of trying, and tbh just getting
seeking to work reliably on any old file is enough of a headache.

Try asking here:
https://lists.ffmpeg.org/mailman/listinfo/libav-user/

> but it seems not to work quit well and it seems that the
> AVCodecContext doesn't flush its buffers correctly so seeking also
> doesn't work quite smooth :�(

You have to flush yourself. See the jjmediareader seek() code.

[Nick Scheithauer]

> It's not something i would even think of trying, and tbh just getting
> seeking to work reliably on any old file is enough of a headache.
>
> Try asking here:https://lists.ffmpeg.org/mailman/listinfo/libav-user/

Ok i'll try that. I hope someone there can help me :/

> You have to flush yourself.  See the jjmediareader seek() code.

I implemented my seek methode similar to your's but if i seek to pos 0
in the stream it decodes the previous frame befor starting to decode
from the beginning of the mp3 file.

[marktrue]

Is there any tutorial about compile this in mswin-i386 ? And i found there is no proper jjmpeg*.dll for me……

在 2012年3月27日星期二UTC+8上午6时15分43秒，Nick Scheithauer写道：

[marktrue]

And I tried to compile the native source code in cygWin then found some errors such as:

./jjmpeg-jni.c:40:54: Error: expected declaration specifiers or '...' before 'AVFormatParameters'

is it head file problem? and how to solve it?

在 2012年9月14日星期五UTC+8上午10时55分50秒，marktrue写道：

[Michael Zucchi]

I'm sorry I only compile it on GNU/linux and the microsoft build is
created via a cross compiler. And that uses mingwin for the runtime.

ffmpeg's libraries and "public" api's change quite rapidly (particularly
since the stupid libav fork), so if you're trying to compile it for a
different version than the one specified, it wont work without porting
first. All sorts of things change from the names of structs to fields
to function calls.

Regards,
Michael

[marktrue]

I see. Thank you very much.O(∩_∩)O~

在 2012年9月14日星期五UTC+8下午4时05分23秒，NotZed写道：

[Nick Scheithauer]

there is already a mswin-i386 build of jjmpeg-0.0
if you succesfully build a i386 of a later version let me know

regards nick

[marktrue]

I just used mingw32 to cross compile mswin-i386 on Ubuntu.

But in order to get work finished, I used the ffmpeg-0.8-win32-dev.7z .

And now I get a problem that jvm shows it cannot open avutil-51.dll. like these:

load jjmpeg

cannot open avutil-51.dll

Exception in thread "main" java.lang.UnsatisfiedLinkError: Unable to open jjmpeg

at au.notzed.jjmpeg.AVNative.<clinit>(AVNative.java:58)

at au.notzed.jjmpeg.AVFormatContext.<init>(AVFormatContext.java:35)

at au.notzed.jjmpeg.AVFormatContext.open(AVFormatContext.java:52)

I'm trying to solve it.

在 2012年9月14日星期五UTC+8下午5时47分53秒，Nick Scheithauer写道：

[卢晓]

I just finished compiling mswin-i386 on windows.
And I use cygwin & mingw to compile the jjmpeg.
As the problem that "cannot open avutil-51.dll", I found these dll files shoud be put into project root directory not with jjmpeg011.dll……
But now I have another problem (  ),and I can't find the source of exception:
Exception in thread "main" java.lang.UnsatisfiedLinkError: au.notzed.jjmpeg.AVFormatContextNativeAbstract.network_init()I
at au.notzed.jjmpeg.AVFormatContextNativeAbstract.network_init(Native Method)
at au.notzed.jjmpeg.AVFormatContextAbstract.networkInit(AVAbstract.java:418)
at au.notzed.jjmpeg.AVNative.<clinit>(AVNative.java:64)

at au.notzed.jjmpeg.AVFormatContext.<init>(AVFormatContext.java:35)
at au.notzed.jjmpeg.AVFormatContext.open(AVFormatContext.java:52)  

2012/9/14 marktrue <ahu.ma...@gmail.com>

--
Regards Mark

[Michael Zucchi]

Oh, it looks like you're trying to build the 0.11 branch, I didn't think
that's the one you were using since it's pretty experimental and GPL3+.
That is supposed to run against ffmpeg 0.11.x. I don't think it will
work against 0.8 as it uses some new apis.

Actually now i remember it includes the full source-code to ffmpeg
anyway as it's required for the android stuff - which is mostly why that
branch exists. The amd64 microsoft build process creates it's own
ffmpeg dll's as well.

On microsoft, all the dll files need to be in the path I think. I just
copy them all to the project root directory because the path is so hard
to change. This also means the jjmpeg011.dll must be there - which is
possibly the cause of the Unsatisfied link error below.

Actually, ... if you have a version mismatch and it can't find the
symbols for missing functions, i think it will also do the same thing.

Michael

On 14/09/12 22:56, 卢锟斤拷 wrote:
> I just finished compiling mswin-i386 on windows.
> And I use cygwin & mingw to compile the jjmpeg.
> As the problem that "cannot open avutil-51.dll", I found these dll files

> shoud be put into project root directory not with jjmpeg011.dll锟斤拷锟斤拷
> But now I have another problem ( ),and I can't find the source of exception:

> Exception in thread "main" java.lang.UnsatisfiedLinkError:
> au.notzed.jjmpeg.AVFormatContextNativeAbstract.network_init()I
> at au.notzed.jjmpeg.AVFormatContextNativeAbstract.network_init(Native
> Method)
> at au.notzed.jjmpeg.AVFormatContextAbstract.networkInit(AVAbstract.java:418)
> at au.notzed.jjmpeg.AVNative.<clinit>(AVNative.java:64)
> at au.notzed.jjmpeg.AVFormatContext.<init>(AVFormatContext.java:35)
> at au.notzed.jjmpeg.AVFormatContext.open(AVFormatContext.java:52)
>

> 2012/9/14 marktrue <ahu.ma...@gmail.com <mailto:ahu.ma...@gmail.com>>

>
> I just used mingw32 to cross compile mswin-i386 on Ubuntu.
> But in order to get work finished, I used the
> ffmpeg-0.8-win32-dev.7z

> <http://ffmpeg.zeranoe.com/builds/win32/dev/ffmpeg-0.8-win32-dev.7z> .

> And now I get a problem that jvm shows it cannot open avutil-51.dll.
> like these:
> load jjmpeg
> cannot open avutil-51.dll
> Exception in thread "main" java.lang.UnsatisfiedLinkError: Unable to
> open jjmpeg
> at au.notzed.jjmpeg.AVNative.<clinit>(AVNative.java:58)
> at au.notzed.jjmpeg.AVFormatContext.<init>(AVFormatContext.java:35)
> at au.notzed.jjmpeg.AVFormatContext.open(AVFormatContext.java:52)
>
> I'm trying to solve it.
>

> 锟斤拷 2012锟斤拷9锟斤拷14锟斤拷锟斤拷锟斤拷锟斤拷UTC+8锟斤拷锟斤拷5时47锟斤拷53锟诫，Nick Scheithauer写锟斤拷锟斤拷

[marktrue]

Thanks a lot for your reply. I find I have made a stupid mistake. T^T

I used jjmpeg-0.11.1a1.jar which I downloaded from code.google.com for referenced library,

rather than the jjmpeg.jar that I compiled. 

And jjmpeg-0.11.1a1.jar mismatch the dll files.

Regards,

           Lu Xiao

在 2012年9月15日星期六UTC+8下午1时10分58秒，NotZed写道：

[marktrue]

Hello Michael,

I have some new problems about jjmpeg.

I find I can not get PTS of AVFrame, such as:

while((jvr = (JJReaderVideo) mMediaReader.readFrame()) != null)

{

System.out.println("pts :" + jvr.getFrame().getPTS());

}

It always shows pts :-9223372036854775808

If pts of does not work in AVFrame, how could I know when the AVFrame should be presented ?

And another problem is that I called function decodeVideo(AVFrame,AVPacket), but it always throw AVEncodingError.

code:
complete = mCodec.decodeVideo(mFrame, packet);

That means avcodec_decode_video2 returns -1 and decode failed.

At first I guess the reason could be the AVFrame does not initialized.

So I use this AVFrame.allocFrame() to alloc the AVFrame, but still do not work.

And I copy the C++ code of project https://github.com/havlenapetr/FFMpeg and translate it to java.

But I can't find how to override AVCodecContext.get_buffer and  AVCodecContext.release_buffer.

May the AVFrame initialized in avcodec_decode_video2 which called get_buffer, I guess.

Should I add this to jjmpeg.c or you have already added?

Could I send my codes to you?

Regards,

            Lu Xiao

在 2012年9月15日星期六UTC+8下午1时10分58秒，NotZed写道：

[Michael Zucchi]

Hi again,

On 17/09/12 15:47, marktrue wrote:
> Hello Michael,
> I have some new problems about jjmpeg.
> I find I can not get PTS of AVFrame, such as:

> *while((jvr = (JJReaderVideo) mMediaReader.readFrame()) != null)*
> *{*
> *System.out.println("pts :" + jvr.getFrame().getPTS());*
> *}*

> It always shows pts :-9223372036854775808
> If pts of does not work in AVFrame, how could I know when the AVFrame
> should be presented ?

You use dts if that is AV_NOPTS_VALUE. I have no idea why, but this is
what the ffmpeg examples use. See JJMediaReader.readFrame().

If you're using JJMediaReader it already has the pts for you, just use
that via:

long pts = jvr.convertPTS(mediaReader.getPTS());

which converts it to a usable millisecond value.

This always just uses dts, which seems to be good enough for my
requirements but may not be correct if audio is important (I think it
might depend on the codec anyway and some never set it).

> And another problem is that I called function
> decodeVideo(AVFrame,AVPacket), but it always throw AVEncodingError.

> *code:
> complete = mCodec.decodeVideo(mFrame, packet);*

>
> That means avcodec_decode_video2 returns -1 and decode failed.
> At first I guess the reason could be the AVFrame does not initialized.
> So I use this AVFrame.allocFrame() to alloc the AVFrame, but still do
> not work.

I'm afraid there isn't enough there for me to help with why it isn't
working.

ffmpeg is a complicated API, your best bet is to look at the example
code in jjmpeg and/or the stuff from ffmpeg: i.e. ffmpeg.c, ffplay.c,
and doc/examples/*.c and search the libav archives. ffmpeg.c would be
the most useful if you're working on a transcoder - it isn't a trivial
task to do it properly.

But if you're using jjmediareader it already does the decoding for you,
so maybe start with that and see how that does it.

> And I copy the C++ code of project https://github.com/havlenapetr/FFMpeg
> and translate it to java.
> But I can't find how to override AVCodecContext.get_buffer and
> AVCodecContext.release_buffer.

Next time it would help if you let me know what file it was used in,
took a while to find it.

I don't know why they're tracking the global pts that way, I don't see
ffmpeg.c doing that. TBH it seems a little strange because you always
get the frames decoded in correct order anyway so you can do the same
thing then.

ffmpeg.c is replacing it for some codecs, my best guess at the
no-comment source seems to suggest it's a way to avoid copying frame
data for certain codecs as they might re-use the buffers, but that just
seems like a performance optimisation to me.

> May the AVFrame initialized in avcodec_decode_video2 which called
> get_buffer, I guess.

Custom get_buffer is just for replacing the memory management with your
own: there's no need to do this for things to work as ffmpeg has it's
own implementation.

> Should I add this to jjmpeg.c or you have already added?

If you need this for your own application you should write your own jni
to do it separately - it's something that would have to be done in C and
would be very specific to a given application and probably not reusable.

It wouldn't really fit within jjmpeg unless something internally needed it.

> Could I send my codes to you?

Well have a go with the info above, if you get really stuck come and ask
again. (I presume it's some free software project).

As I said above ffmpeg is a pretty complex - not really public - api, so
it can take a lot of trial and error and trawling through the ffmpeg
source to find out what's going on. Pretty much all the knowledge I
have of it is stored in the jjmpeg and jjmpegdemos projects so you can
find it yourself there.

Regards,
Michael

[卢晓]

Hi Michael,

Thanks you very much for your so careful reply.

I think I have found something wrong with my codes.

Actually I want to write a movie stream server to stransmit movies to my mobile phone. (So I can use my phone to watch movie on the bed without transmitting the movie files to my phone. ^_^ )

And now I find I might not catch the means of java's object reference.

My program have three threads at first.("decodeMovie" thread reads packets, "decodeVideo" thread decodes video, "decodeAudio" thread decodes audio)

"decodeMovie" thread reads packets and puts them into two queues separately.(java.util.Queue)

"decodeVideo" & "decodeAudio" thread gets packets from the queue then decodes them to AVFrame | AVSamples.

But it didn't work.

After some trials, I find the packet can be docoded if I merge the three threads. 

Maybe there are something I haven't understand about java.

Now I decide just merge the three threads, and let the problem go.

As the function get_buffer & release_buffer, overwriting the get_buffer() is just for setting new AVFrame's pts that .
here are example:

DecoderVideo::DecoderVideo(AVStream* stream) : IDecoder(stream)
{
mStream->codec->get_buffer = getBuffer;
mStream->codec->release_buffer = releaseBuffer;
}
int DecoderVideo::getBuffer(struct AVCodecContext *c, AVFrame *pic) {
int ret = avcodec_default_get_buffer(c, pic);
uint64_t *pts = (uint64_t *)av_malloc(sizeof(uint64_t));
*pts = global_video_pkt_pts;//AV_NOPTS_VALUE
pic->opaque = pts;
return ret;
}

And I realize that it is not so important after your reply...

Thanks for your help again.

Regards,

            Lu Xiao

[Michael Zucchi]

Hi there,

Yeah it's a bit complicated. As far as i can tell, a packet content is
only valid until the next call to read_frame() - this means ffmpeg can
manage the memory and simplifies the api, but it also means you need to
duplicate the packets if you want to process them in another thread.

At least this is my conclusion after poking through the ffplay sources,
and getting JJPlayer to work.

JJPlayer does something like this, so perhaps have a look at that I did
manage to decode everything properly, using a separate thread for audio
and video and demuxing. (there are other problems with it, but i'm
pretty sure that bit works). The code is in
jjmpeg-core/src/au/notzed/jjmpeg/mediaplayer - unfortunately it's a bit
complicated to follow through the object/interface heirarchy.

e.g. see the main loop in the run() method here, the secret is the
dupPacket() thing.

http://code.google.com/p/jjmpeg/source/browse/branches/jjmpeg-0.11/jjmpeg-core/src/au/notzed/jjmpeg/mediaplayer/MediaReader.java

It's nothing to do with Java btw, it's just the FFmpeg api.

Michael

[卢晓]

Hi Michael,

Acturally I have already noticed that packet should be duplicated.

But I didn't know how to duplicate the packet,because I couldn't find this function in the source code that I downloaded.

(I downloaded the souce code from svn/truck/ .)

And I just thought the other versions cannot be compiled on win32. So I didn't try the other versions. Now I will try to compile the higher version. Thanks again.^_^

Regards,

           Lu Xiao

p.s:

in function int PacketQueue::put(AVPacket* pkt)
he used av_dup_packet(pkt)
https://github.com/havlenapetr/FFMpeg/blob/debug/jni/libmediaplayer/packetqueue.cpp

I learned to write my program referred this project. And I guessed it may referred ffplay.c cause I found there are some same places.

2012/9/19 Michael Zucchi <not...@gmail.com>

[Michael Zucchi]

Lu,

On 19/09/12 20:35, 卢锟斤拷 wrote:
> Hi Michael,
> Acturally I have already noticed that packet should be duplicated.
> But I didn't know how to duplicate the packet,because I couldn't find
> this function in the source code that I downloaded.
> (I downloaded the souce code from svn/truck/ .)

Hmm, now i'm confused - i'm sure you mentioned the api's from that
version before. No matter.

> And I just thought the other versions cannot be compiled on win32. So I
> didn't try the other versions. Now I will try to compile the higher
> version. Thanks again.^_^

I don't need the x86 microsoft binaries so i never built them. But if
you have the mingwin cross compiler setup it's easy to create them, it's
mostly changing the -m64 to -m32 in a new makefile.

> p.s:
> in function int PacketQueue::put(AVPacket* pkt)
> he used av_dup_packet(pkt)
> https://github.com/havlenapetr/FFMpeg/blob/debug/jni/libmediaplayer/packetqueue.cpp
>
> I learned to write my program referred this project. And I guessed it
> may referred ffplay.c cause I found there are some same places.

ffplay.c is the only real documentation so that isn't surprising!

Cheers,
Michael