On Sat, 3 Jan 2004, Brian J. Murrell wrote: > 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
Hmmm, which automake do you have? I'd been using 1.7.3 for a long
time with good results. A couple weeks ago decided to install
1.7.9 and didn't have any problems.
> 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
>
> Maybe it's the issue of streams in containers vs raw streams again. I dunno.
Yes, that's what it is. mencoder adamantly insists on putting things
into a container - sigh. I think it's possible to use ffmpeg to
create a 'raw' m4v file - haven't tried it.
What I do with the output of mencoder is use another utility from
the mpeg4ip project: avi2raw
mencoder ... -o foo.avi
avi2raw --video foo.avi foo.m4v
mp4creator -c foo.m4v -rate=XX.YY foo.mp4
mp4creator -c foo.aac foo.mp4
where XX.YY is usually 29.97 but may need to be 23.976 if you've
done a 3:2 pulldown from telecined source. Adding the audio track
is the second mp4creator command, in the example it was AAC audio, but
.mp3 is also valid.
mp4creator also has the "--use64bits" option but the usage summary
suggests it's not QuickTime player compatible - i.e. won't play on
an Apple).
> 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
Yep - that about sums it up. Which effectively means that MPEG4
is only interchangeable (i.e. I could create a video and send it to
someone) between computers (not send 'em a DVD).
> standard (i.e. comparible to the DVD standard) on how to put MPEG4 on a
> disc for STB manufacturers to even build against?
Sort of. The MP4 container format was one idea that was brought up
for the next generation DVD format The AVI container is used by
the one portable player I saw (but who wants to watch a movie on a 1.5"
LCD? ;)).
> 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
True - that is one of the intended applications. The low picture
quality isn't MPEG-4's fault of course but of the low rates.
Most of MPEG-4 isn't used/realized yet - the concepts of multiple
layers and objects for example. For something like a football game
the static background would be one object and compressed, the players
and the 'ball' would be separate objects and compressed handled
separately, etc. At the moment the MPEG-4 encoders are very simple
(the lower profiles/capabilities)
> > For DVD sized data I use MPEG-2, for the smaller resolutions I might
> > use MPEG-4.
>
> Why use resolution as your decision point?
Because software playback of DVD sized MPEG-4 files is marginal on
all but the fastest computers at the moment. That's one reason. The
other is that once at the DVD size I'll put it on a DVD+R disc and
play it on my portable DVD player, or the one hooked up to the TV ;)
Then too at smaller sizes and lower bitrates MPEG4 is great for
encoding up a cartoon and making it availble for FTP (email's not
practical since a lot folks have quotas or similar on mail).
> > 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. :-)
Same thing, or rather related. With similar quality a larger
resolution will require a higher bitrate. Yes, you could create
a 1Mb/s DVD sized movie but I don't think you'd want to watch it ;)
> At what resolution do you feel the breaking point is in CPU consumption?
1280x768p was the point at which the systems/players didn't have
trouble. As far as I know, in Southern California, only 1 TV station
is broadcasting in the 1280 HDTV format - the others are using the
1920x1080i
http://www.pchdtv.com
I'm going to order one up before the new FCC regulation about the
'broadcast copy' flag goes into effect - grrrrs.
> 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.
They may be closed source but they're extremely responsive and
supportive. You can get *any* of their video cards from the cheapest
$80 one up to the $500 top of the line model and use them on your
linux system (hardware assisted OpenGL support is preesnt in their
included libraries).
> But! Will an nVidia card do interlaced TV output as well as the Matrox
I've never configured TVout but yes, it will their cards will do it
(the FX5200 I bought came with an S-Video output as well as a DVI
and analog VGA connectors - and 128MB of memory, all for $80 or so).
> > 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
It's also the reason I got the nVidia card - I have a ~15-20 clip
(the transport stream example from www.pchdtv.com's download area)
that the matrox card choked on. I'm a long time fan of the Matrox
products but everything up thru the G550 has a dinky Xv (overlay)
of 1024x1024 - so when I tried to play 1280x768 or 1920x1080 clips
it didn't work. The nVidia card has a 2048x2048 Xv capability.
> 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
720x480? I don't know of any 720x640 formats.
> Certainly not in an easily capturable format here in North America. All
> of the digital cable systems here are proprietary (no capture cards for
I get my HDTV off the air - in fact I'm encoding the New Years from
Vienna concert now (taped it on Digital8 camcorder off the HDTV tuner,
alas only 480i format though). That's why I'm thinking about the
pchdtv card - pretty reasonably priced too.
> > '-vf hqdn3d,trell' are two
> > that come to mind.
>
> As undocumented options or options to help reduce bitrate?
Improve quality - that means higher quality at the same bitrate or
you can lower the bitrate and maintain the quality level.
> I am currently using:
>
> vlelim=-4:vcelim=9:lumi_mask=0.05:dark_mask=0.01:vhq:vqmin=2:ildct
'vhq' has been deprecated as I understand it. it is equivalent to
'mbd=1' and the current advice is to use 'mbd=2'
> > Scale down from full to half size (CVD or 352x480),
>
> In fact that is my capture frame size.
Ah, ok - so at that size I'd think 1500 to 2000 kbits/sec would be
more than sufficient for good quality.
> 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.
Agreed. At 352x480 MPEG-4 should give very good results at 2000.
> Thanks for all of your help and feedback Steven. As always it has been
> absolutely invaluable!
You're welcome. Good to know the verbosity wasn't excessive ;)
Cheers,
Steven Schultz
signature.asc
Description: This is a digitally signed message part
