On Sat, 2004-01-03 at 00:58, Steven M. Schultz wrote: > > As the toolbox is becomes more complete the management gets simpler.
Assuming the tools are all interchangeable. It's when you have some
software that wants automake 1.4 and others than want 1.6/7 and some
software wants one version of a lib and some software wants another
version, and so on and so forth. I'd just as soon let the distro vendor
handle all the crap and work on more fun stuff myself.
If I felt I did not have list of stuff that I want to do a mile long, I
might me more inclined to manage software, but life is just too short.
> strange - given recent vintage automake/autoconf/libtool tools it
> should have been a simple matter of ./cvs_bootstrap and make.
Except that for some reason any version of automake that I have here
barfs on the indentation of variable assignments in some of mpeg4ip's
Makefile.am files. I just don't care to know enough about
autoconf/automake to know why this is a problem and fix the tool. As it
was, I took a stab and removing the indent and things moved along.
Unfortunately, mp4creator did not like trying to add an mencoder
produced divx/avi file to an mp4:
$ /usr/src/mpeg4ip/server/mp4creator/mp4creator -create=test.divx -rate=29.97 test.mp4
MP4ERROR: MP4WriteCountedString: Length is 2852: Numerical result out of range
And yields a file with the digital equivalent of white noise.
Maybe it's the issue of streams in containers vs raw streams again. I
dunno.
> Down that path lies a bit more madness than you've already encountered.
Actually, once I got the "bootstrap_cvs" madness sorted out, building
mp4creator (and it's 3 or 4 prerequisite mpeg4ip supplied libraries)
built was relatively straightforward.
>
> 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
Yeah, there was an avi lib as well as another one or two. Like I said
that part was a cakewalk compared to sorting out the
autoconf/automake/aclocal and assorted mess.
> 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.
Could be. I was looking for the path of least resistance (time included
in resistance) to see if mp4creator was even the tool I needed/wanted
before I invested time in building the whole project.
> 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.
OK then. Just as I suspected. You are merely saying that MPEG4 simply
does not exist in hardware (STB) devices (yet). Is there even a
standard (i.e. comparible to the DVD standard) on how to put MPEG4 on a
disc for STB manufacturers to even build against?
I always had the impression that MPEG4 was designed for bitrate
constrained applications (like network streaming for example) and
sacrificed some picture quality to achieve that. So much so that even
using typical MPEG2 bitrates still did not achieve the picture quality
of mpeg2. Maybe that is all folklore.
> 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.
Why use resolution as your decision point?
My main preference for MPEG2 is that I was under the impression that
MPEG4 could not do field based encoding as well as MPEG2, which for
progressive (i.e. film based) sources, who cares, but for video tape
based sources, is more important.
> 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.
Interesting point to note. Size is always of importance, especially
when it's material that I am only going to view once.
> One drawback of MPEG-4 at the present time is that at the higher
> resolutions
Resolutions? Or bitrates? If the former then I think you have just
answered my question above. :-)
> the current software decoders begin using a lot of cpu.
At what resolution do you feel the breaking point is in CPU consumption?
> 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).
Those damn nVidia guys :-) As much as I try to avoid using them due to
the whole closed source video drivers thing, there is always a reason to
look at them again.
But! Will an nVidia card do interlaced TV output as well as the Matrox
G400 with DirectFB? Can you even use an nVidia without X? Technical
issues like not being able to get vsync interrupts in userspace from X
for frameflipping aside, who really wants to run an X server just to
display video frames to a television. It's overkill.
> By the time you get up to the HDTV (1920x1080)
Wow. It will be a while before I am interested in frame sizes that
large. The way the "copyright consortium" (tm) is strangling the media
market here in North America, I doubt I will ever be able to capture
anything beyond the analog 720x640 picture size that exists today on an
Open Source platform.
> 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).
Indeed.
> Ah, ok. Digital cable can be quite a bit cleaner but it's not
> as widely available.
Certainly not in an easily capturable format here in North America. All
of the digital cable systems here are proprietary (no capture cards for
computers) and the only way to capture their signals is to buy an
additional receiver, dedicated to your PC and S-Video out to your
capture card and buy/build an IR blaster to tune the receiver.
Beyond my loathing to perpetuate the proprietary cable systems, it just
becomes even more expensive (i.e. another receiver AND capture card for
every simultaneous capture you need to do) and messy to implement.
Additionally, if you have a need to capture more than two streams at
once, you run out of serial ports to hook IR blasters to. I suppose you
could start buying USB->RS-232 adapters, but that's even more expense.
> They are also not very well documented.
Indeed.
> '-vf hqdn3d,trell' are two
> that come to mind.
As undocumented options or options to help reduce bitrate?
I am currently using:
vlelim=-4:vcelim=9:lumi_mask=0.05:dark_mask=0.01:vhq:vqmin=2:ildct
as -lavcopts to mencoder. I don't really know what they do, just that I
read them somewhere as recommended to lower bitrate/enhance picture
quality.
> The other thing that can be done is to downscale.
I already do that at source capture time, just to reduce my transient
space needs (capturing with MJPEG, transcoding to mpeg{1|2|4})
> Mplayer (perhaps
> ffplay as well) know how to deal with the coded frame size being
> different than the display size.
Indeed.
> Scale down from full to half size (CVD or 352x480),
In fact that is my capture frame size.
> put the
> '-aspect 4/3' in the mencoder line
I actually calculate the aspect to account for cropping when I record
something that is shown in letterbox. My formula is:
# default values
width=704
height=480
vbitrate=2500
if [ $1 = "--crop" ]; then
# mplayer format: w:h:x:y
crop=$2; shift
oldIFS="$IFS"
IFS=":"
crop_vals=($crop)
IFS="$oldIFS"
old_width=$width
old_height=$height
width=${crop_vals[0]}
# width passed is the decimated width, so double it
let width=$width\*2
height=${crop_vals[1]}
x=${crop_vals[2]}
y=${crop_vals[3]}
vbitrate=$(($vbitrate * (($width * $height * 100) / \
($old_width * $old_height)) / 100))
fi
...
if [ $1 = "--detc" ]; then
# inverse telecine decreases fps by 20%, decrease bitrate same
vbitrate=$(($vbitrate * 8 / 10))
fi
...
# television pixels are 10:11, so factor that into width
let width=$width\*10/11
...
mencoder ... -ovc lavc -lavcopts ...:aspect=$width/$height:vbitrate=$vbitrate
I just finished a nearly 3 hour movie (Heat) and with cropping (344x272)
and inverse telecining, my desired bitrate reduced from the default 2500
to 1060. The results are surprising good. The final file size
including an ogg encoded audio track is 1448251959 for 2 hours and 50
minutes. I could be losing detail around edges in the background, etc,
but that is not nearly so apparent behind the noise of analog cable.
I am starting to think that defaulting to 2500 kbits/s for full frame,
29.97fps capture might be too high and not yielding much more quality
for the additional space it's taking up.
I do have a note to myself that I reduced it from 3000 8 months ago. I
might try reducing it again.
> and when you play it back mplayer
> will do the right thing.
Indeed it does.
> Twice the play time, increased encoding
> speed and for causual viewing you probably won't notice the slightly
> reduced quality.
Indeed. I never have, as long as I have been decimating the horizontal
resolution to 352. It's always been quite acceptable.
I said two messages ago in this thread:
> > I should do a calculation on the amount of frame that is being cropped
> > and reduce the bitrate accordingly.
I am not convinced that a linear reduction in bitrate is appropriate for
reduced bits in the frame however. I.e. if 50% of the frame was cropped
(25% top and bottom for example) I don't know that you can simply half
the bitrate without a sacrifice. I will play with it a bit.
> 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.
I will give it a try.
> Hopefully.
Not likely, due to the result above. Maybe simply reducing my bitrate
(even if only for files that would result in >2GB) will be the easiest
solution given the required work to solve it other ways. I just don't
seem to have the time these days to get to stuff like this. ~sigh~
I said a couple of messages ago:
> > 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.
In fact I think what I am going to do is try to cap my desired bitrate
so that the resulting file will be <2GB. If it's a shorter running
program, the cap will be moot, but if it is longer, the picture quality
might have to suffer a bit. If my supposition above that I am already
using too high a bitrate is correct, maybe this will not be an issue at
all.
Thanks for all of your help and feedback Steven. As always it has been
absolutely invaluable!
b.
--
My other computer is your Microsoft Windows server.
Brian J. Murrell
signature.asc
Description: This is a digitally signed message part
