On Sat, 3 Jan 2004, Brian J. Murrell wrote:

> The actual build, once you got everything right, yes you are right. 
> It's the management of "this depends on that, so build that, which

        As the toolbox is becomes more complete the management gets simpler.

> depends on the other so build the other" and so on and so forth (like my
> current fight with mpeg4ip -- all kinds of gripes from
> automake/autoconf, etc.).  It's just so much easier when the distro

        strange - given recent vintage automake/autoconf/libtool tools it
        should have been a simple matter of ./cvs_bootstrap and make.  The
        bundled version of the SDL is the only thing that gave me a struggle
        on one of my systems (heck, even got mpeg4ip to build on OS/X except
        for the mp4player program which the developers tell me wouldn't work
        on OS/X anyhow.  but mp4creator and other programs run ok and I find
        them easier to use than Apple's gui programs for manipulating Quicktime
        files).

> Not even to mention the mess of a system you wind up with when you can't
> track the origin of a given file (like you can for example when you do
> an "rpm -qf `which mpeg2enc`").

        I've got 600+ files in /usr/local/lib and know where everything came
        from ;)

> >     Welcome!   Uh, mpeg4ip is a big project - useful to have though.
> 
> So I am discovering.  I am going to attempt to build just mp4creator and
> see if it's useful before I try to build the whole beast.

        Down that path lies a bit more madness than you've already encountered.

        As I recall from talking to the creators of the project you'll need
        a couple of the shared libs such as libmp4v2 and libmp4av at least -
        so you can try building those first, then into the server/util 
        directory, there are some very useful utilities in that (and of
        course the mp4creator program). 
        
        Once the ./configure problem(s) are taken care of it's as easy to
        build the whole thing with 'make' than it is to pick&choose.

> Right.  I agree.  But I want to clarify if you are asserting that mpeg2
> only belongs in a (trying very hard to not use the term "STB") dedicated
> hardware device (and not on a software device) or if that is just the

        Not at all.   At the moment MPEG-2 is most useful on standalone
        hardware players simply because there are no units (not quite true -
        I think there are 2) that handle anything else.   You can't put
        MPEG-4 onto a DVD, take the disc and go into Circuit City (or wherever)
        and expect it to play on anything except a computer.

> But are you asserting that mpeg2 should not be used in a
> "computer" running software to be the equivalent of an STB (i.e.

        No.   Feel free to use whatever suits your fancy on your computer.
        For DVD sized data I use MPEG-2, for the smaller resolutions I might
        use MPEG-4.

        MPEG-4 does better at the lower bitrates (smaller files) than MPEG-2
        though so if smaller files (to get under the 2GB limit) is the goal
        then MPEG-4 is a better choice.   Once you get up around 4Mb/s there's
        nothing really to be gained with MPEG-4 - the files are just as big
        their MPEG-2 counterparts.

        One drawback of MPEG-4 at the present time is that at the higher
        resolutions the current software decoders begin using a lot of cpu.
        MPEG-2 decoders are more mature and there are hardware assists -
        some video cards have MPEG-2 decoders built in and the nVidia one
        I'm using comes with libraries that ffmpeg/mplayer use to talk to the
        hardware decoder (only works for MPEG-2 though).

        By the time you get up to the HDTV (1920x1080) size even a 3GHz cpu
        was down in the low single digit frames/sec range (at least in the 
        one test that one of the video magazines ran) when playing back MPEG-4.

        At one time there was mention of MPEG-4 being used for the HD-DVD
        format but that seems to have faded in favor of MPEG-2 and different
        lasers.   Patent issues and/or greed I think are what effectively
        relegated MPEG-4 to niche areas (and geeks).

> Agree.  It's analog cable however, and not very clean at that.

        Ah, ok.   Digital cable can be quite a bit cleaner but it's not
        as widely available.

> >     options to ffmpeg/mencoder that will allow the use of a considerably
> 
> Yeah, I know.  But unfortunately I don't understand enough about video
> encoding to understand (some of) them.

        They are also not very well documented.   '-vf hqdn3d,trell' are two
        that come to mind.

> > Mencoder can do the cropping without a speed penalty
> 
> Right.  ISTR that I lower the bitrate when I crop.  I know I do when I

        The other thing that can be done is to downscale.   Mplayer (perhaps
        ffplay as well) know how to deal with the coded frame size being
        different than the display size.

        Scale down from full to half size (CVD or 352x480), put the 
        '-aspect 4/3' in the mencoder line and when you play it back mplayer 
        will do the right thing.  Twice the play time, increased encoding 
        speed and for causual viewing you probably won't notice the slightly
        reduced quality.

> I should do a calculation on the amount of frame that is being cropped
> and reduce the bitrate accordingly.

        There's a really handy bitrate calculator in MPlayer's tools directory.

        Look in mplayer's TOOLS/ directory for the perl script called
        calcbpp.pl - follow the directions at the top of the file for adjusting
        it to NTSC instead of PAL and you're all set.   It's handy for getting
        suggested crop/scale sizes and an idea what bitrates to consider.

> Hopefully MP4 containers solve my problem.

        Hopefully.

> BTW:  The tool I needed to use to get the MPEG-ES stream out of the
> MPEG-PS file I had was tcextract.  Seemed to work just fine.

        Wasn't sure if that or tcdemux would be the right tool for the job.

> Maybe I continue to use mpeg4/avi with content that will ultimately be
> <2G and use mpeg2 with content that will be >2G.  Could be a fair

        That would be a very good solution. 

        Cheers,
        Steven Schultz



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Reply via email to