[Mjpeg-users] Re: Compiling mjpegtools on Mac OS X

[Matti Haveri]

Steven M. Schultz:
 [was: Maximum video buffer size with mpeg2enc, Mac options]
 > 
 > Is someone updating those mpeg2enc and mplex Mac OS X binaries or
 > should I bite the bullet and learn to do it myself?
 I forget when I tweeked the Makefiles to get a static linked version of
 the encoder and mplex - quite some time ago.
 The situation is quite a bit more complex now though because mpeg2enc
 _and_ mplex have been split into frontends and shared libraries - not
 sure if a simple static build is possible (it might be but that would
 end up defeating the purpose of the work done to create shared libraries
 that can be used with other programs).
 Ideally the rest of the mjpegtools (except for the V4L specific parts of
 course) would be a good thing to have - lav2yuv, yuvdenoise,
 yuvmedianfilter, yuvplay, lavplay, and all the rest. Now things get
 messy. Bundling in libdv (which I have), libSDL (for the video out, SDL
 is a breeze to build and it takes advantage of the Quartz graphics
 subsystem), possibly libglib and libgtk, libpng, and possibly others
 I've overlooked.
 Oh, probably also want y4mscaler too. Packaging bunches of stuff
 together into whatever format for binary installation isn't something
 I'm familiar with - maybe it's easier than it sounds but maybe it's
 harder.
 Creating everything as a static executables makes the files a lot bigger
 of course.
 > Are there many other Mac OS X users on this list? How do you use
 > mjpegtools? Via a GUI front-end or via the terminal?
 I don't know if I count or not ;) I've been building mjpegtools,
 mplayer, libdv, ffmpeg, smilutils, mpeg2dec, SDL, and a bunch of other
 stuff on OS/X since I got my Powerbook back in Feb/Mar of this year.
 Don't do a lot of encoding on it other than for testing though because a
 1GHz G4 gets pretty darn slow - mpeg2enc itself can get around 7
 frames/sec on preprocessed YUV4MPEG2 data. If any conversion (lav2yuv or
 smil2yuv) and scaling or filtering is done then that slows it down a lot
 (although "smilutils" built using ffmpeg's DV codec is Altivec enabled
 and is a lot faster than libdv's on a G4). Most of the encoding is done
 on dual Athlon-2800 or P4-2.2GHz systems. One of those nice dual 2GHz G5
 tower systems is on the "toy/wish list" for next year though ;)
 I use mjpegtools (not just mpeg2enc+mplex) like this:

 --
 #!/bin/sh
 smil2yuv -a foo.wav -i 2 fire-master.dv | \
 y4mscaler -v 0 -O chromass=420_MPEG2 | \
 bfr -b 10m | \
 mpeg2enc -f 8 -E -5 -M 2 -R 0 -q 4 -K tmpgenc -4 2 -2 1 -o foo.m2v
 toolame -b 192 -o foo.wav foo.mpw
 mplex -f 8 -o foo.mpg foo.m2v foo.mp2
 
Thanks for the info, I'm making slow progress but I'm not there yet 
because I'm still stuck at an old version of mjpegtools 1.6.1 without 
newer -K -N options.

(I first tried to compile everything 
 suggested myself but the 
dependencies seemed so overwhelming that I then tried Fink package 
manager with better success. I compiled many packages but then got 
stuck somewhere between libdv, JPEG-MMX, libquicktime and finally 
messed the system by mixing both Fink and Opendarwin ports which 
apparently is bad. I then reinstalled only Fink).

So far I have successfully compiled an old version of mjpegtools 1.6.1 with:

- Mac OS X 10.2 and the latest Developers Tools 
(Dec2002DevToolsCD.dmg) and the latest gcc updater 
(August2003gccUpdater.dmg).



- Fink package manager (Fink 0.6.2 Installer.dmg).



- Activated all of unstable in Fink:

Trees: local/main stable/main stable/crypto local/bootstrap 
unstable/main unstable/crypto

- Fink succesfully compiled an older version of mjpegtools 1.6.1:

fink install mjpegtools [chose xfree86]

The following package will be installed or updated:
 mjpegtools
The following 45 additional packages will be installed:
 audiofile audiofile-bin audiofile-shlibs autoconf2.5 automake
 automake1.6 dlcompat dlcompat-dev dlcompat-shlibs esound esound-bin
 esound-shlibs glib glib-shlibs gtk+ gtk+-data gtk+-shlibs libdv4
 libdv4-shlibs libgnugetopt libgnugetopt-shlibs libjpeg libjpeg-bin
 libjpeg-shlibs libmovtar libogg libogg-shlibs liboss1 liboss1-shlibs
 libpng3 libpng3-shlibs libquicktime0 libquicktime0-bin
 libquicktime0-shlibs libvorbis0 libvorbis0-shlibs m4 mjpegtools2-shlibs
 pkgconfig popt popt-shlibs sdl sdl-shlibs xfree86 xfree86-shlibs
Compiling stopped to an error message:

ld: table of contents for archive: /sw/lib/libintl.a is out of date; 
rerun ranlib(1) (can't load from it)



...read the instructions and fixed it with:

sudo ranlib /sw/lib/libintl.a

Then continued compiling:

fink install mjpegtools [chose xfree86]

The following package will be installed or updated:
 mjpegtools
The following 19 additional packages will be insta

Re: [Mjpeg-users] Re: Compiling mjpegtools on Mac OS X

[Steven M. Schultz]

On Sun, 1 Feb 2004, Matti Haveri wrote:

> Thanks for the info, I'm making slow progress but I'm not there yet 
> because I'm still stuck at an old version of mjpegtools 1.6.1 without 
> newer -K -N options.

Hmmm, not at least the latest release candidate?  It should be
ready to ./configure

> (I first tried to compile everything 
>  suggested myself but the 
> dependencies seemed so overwhelming that I then tried Fink package 

For a basic build (without libdv or quicktime) I think the (only)
dependencies are the SDL and libglib for yuvplay.

> manager with better success. I compiled many packages but then got 
> stuck somewhere between libdv, JPEG-MMX, libquicktime and finally 

Uh, jpeg-mmx is for INTEL based systems only unless the G4 chip
has suddenly grown the ability to execute MMX instructions :)

libdv is easier now to build than it used to be - should build
out of the box with the exception of 'playdv' (which is OSS audio
driver dependent - easiest workaround is to delete that program
from the Makefile)

Until recently libquicktime wouldn't build on OS/X but that has
been taken care of now.   If you want libquicktime the cvs version
should build easily (but using plugins with dlopen() means having
a good version of the 'dlcompat' library/routines installed).

> messed the system by mixing both Fink and Opendarwin ports which 
> apparently is bad. I then reinstalled only Fink).

Other than a couple items (libglib/gtk, 'gimp') from OpenDarwin
I have neither Fink or Opendwarwin installed so I have never 
experienced mixing the two environments (but I can easily believe
it is a Bad Thing ;)).

> So far I have successfully compiled an old version of mjpegtools 1.6.1 with:
> 
> - Mac OS X 10.2 and the latest Developers Tools 

Hmmm, 10.3 is *much much* better.  For one thing it comes _standard_
with libtool-1.5 integrated into the system (as 'glibtool' - I put
a symlink called 'libtool' into /usr/local/bin and then put 
/usr/local/bin first in $PATH).   The Big Thing that comes with
10.3 is the dlopen/dlsym/dlclose ("dlcompat") routines - they're
part of the system libraries now - no need to build/install them
from Fink or Opendarwin (I caused myself a night of pain by trying
to install libdl myself not knowing that 10.3 already had them...).

> Compiling stopped to an error message:
> 
> ld: table of contents for archive: /sw/lib/libintl.a is out of date; 
> rerun ranlib(1) (can't load from it)

Sigh, libintl issues - I have not seen that specific error but in
this case the fix is, as you guessed, to run ranlib.   VERY Strange
though that there's not a shared (libintl.dylib) installed though - I've
got one.

10.3 comes with the libintl stuff integrated into the system libraries
so I usually get warnings about potential conflicts between libintl
that I have in /usr/local/lib and the one in the system library - has
not hurt anything so far though.

> The following package will be installed or updated:
>   mjpegtools
> The following 19 additional packages will be installed:
>   autoconf2.5 automake automake1.6 gtk+ gtk+-data gtk+-shlibs libdv4

OS/X 10.3 comes _with_ autoconf 2.57 already installed on the system -
nothing more needs to be done.   Oh, automake 1.6 is also already
installed but since I wanted automake 1.7.x (x=9 at the moment)
I put the new version of automake-1.7.9 into /usr/local/{bin,share,...}
and put /usr/local/bin first in my path.

As you can see 10.3 is a much better/easier development environment
than 10.2 was - Apple's included a lot of stuff that needed to be
manually added/ported before...

> I then tried to follow the compile-myself FAQ entry but the 
> instructions are somewhat obscure to a newbie like me.

They're obscure to me too ;)   I've had a fairly easy time just
following my old habits of (manually) installing things into
--prefix=/usr/local as I do on all the other systems.

> I did add the setenv lines to my .cshrc but after "./configure" 
> "make" stops to an error:
> 
> [...]
> cpu_accel.c: In function `bufalloc':
> cpu_accel.c:255: error: `_SC_PAGESIZE' undeclared (first use in this function)
> cpu_accel.c:255: error: (Each undeclared identifier is reported only once
> cpu_accel.c:255: error: for each function it appears in.)
> cpu_accel.c:268: warning: int format, size_t arg (arg 2)
> cpu_accel.c:270: warning: int format, size_t arg (arg 2)
> cpu_accel.c:270: warning: int format, size_t arg (arg 3)
> make[3]: *** [cpu_accel.lo] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2

_SC_PAGESIZE is defined

Re: [Mjpeg-users] How to concatenate mp2/m2v files for multiplexing ?

[Dragon_at_work]

On Friday 23 January 2004 06:26, Steven M. Schultz wrote:
>   that are allergic to the splice point.   There's also the
I get this with mplayer. 

>   It's really not hard at all to arrange for multiple yuv4mpeg2
>   sources to feed a single mpeg2enc process.
>
>   (yuv4mpegsource1; yuv4mpegsource2; yuv4mpegsource3; ... ) | mpeg2enc
For some reason this did not work for me: The shell complained "permission 
denied". Running as root yielded same results. 

>   Just use a simple shell function to strip off the extra header from
>   all the sources except the first one.
Not sure if I follow you. I took a group of y4m files. The first was 
unchanged. And the rest were all edited to remove the first 28(hex) bytes 
that seemed to be the header information. (This far seems to work and I 
verified the edit with Khexedit). 

Then, I cat'd the lot and applied it to the mpeg2enc. 

The result was just like the former results: The first 'segment' plays, and 
then mplayer claims the end of file has been reached and exits. 

Vcdimager does this just fine, but it is limited to 98 segments/tracks (and I 
have much more --intention to make a VCD out of my photographs).




---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users