Hi -
On Thu, 19 May 2005, Matt wrote:
> We typically generate tga's and then do our conversions from there.
Ok - good to know you're not using JPG ;)
> Fair enough. They have some mighty nice tools. We do most of our work in
> blender
I've seen the Blender book on the shelf at Borders - maybe I'll pick it
up and give it a try.
> Very cheap to scale. Not so with Mac OS X and almost ALL of the major
That's ambiguous to a degree - are you saying OS/X rendering systems
don't scale (some of them do indeed scale into 'farms') or they're
not cheap (true).
> couldn't yet afford to do what we do with macs (but I do drool over
> their hardware.)
The dual G5 system I got a year ago has seen constant use - *quiet*,
fairly fast, and good looking. 23" display is ideal (the 30" is just
too big for most desktops ;)).
> See above. We have more problems with jpegs. Everybody thinks jpegs are
> great, until they see the end result. I love them for single images used
For an occasional still or menu background they're ok but I use PNG
or TIF whenever possible.
> > Prime Motion Estimation) which I find helps improve the picture when
> > not using B frames, the choice of GOP size is limited
> Is there a specific time when not using B frames is a plus? Are
> we looking at space savings?
B frames have always been controversial. There have been several
(sometimes slightly heated ;)) discussions on the mjpegtools mailing
lists. Some folks swear by B frames, others (myself) swear _at_ them.
I've seen up to a 5 or 6% increase in file size with Bframes.
Scenes with rapid motion benefit from not using B frames (which bring
no _new_ information to the party like I or P frames do).
> My recent tests show marked improvement in quality with B frames being
> used.
Hmmm, interesting - I've not seen any improvement (visually). The
main benefit of B frames comes in at very low (VCD or ~1Mb/s) data
rates. Once you get up in the 4Mb/s range or higher the benefits
aren't as great.
Also, it depends on the material being encoded. Noisy material
doesn't benefit from B frames - as was explained to me a long time
ago:
"The effect is complicated. Basically, B-frames only make sense if prediction
between P frames stays good over more than 1 frame interval and if there isn't
too much noise. If prediction decays then what you gain by the smaller B
frames you lose in bigger P frames. If noise is heavy then B frames don't
benefit all that much from the bidirectional prediction and sucks bits away
from the P frames."
You might try adding "--dualprime-mpeg2" in place of "-R 2" when you
get a chance - it's a good middle ground between the size increase
that B frames bring but gains most of the (purported) benefits of
B frames.
The thing to look at is the output of 'mplex' - it gives the
average I/P/B frame sizes. When the B frame size approaches the
size of the P frame then you're losing.
Use mplex thus:
mplex -f 8 -o /dev/null yourmpeg-2.m2v
and look at the lines:
INFO: [mplex] No. I Frames : 272 avg. size 59160 bytes
INFO: [mplex] No. P Frames : 1088 avg. size 36354 bytes
INFO: [mplex] No. B Frames : 1904 avg. size 27934 bytes
INFO: [mplex] Average bit-rate : 6396400 bits/sec
INFO: [mplex] Peak bit-rate : 8628800 bits/sec
That is from an encoding run using the mpeg2enc command:
mpeg2enc -D 10 -b 8500 -G 12 -p -c -R 2 -E -10 -f 8 -q 3 -K file=hi-tmpgenc \
-4 1 -2 1 -o foo.m2v
(the file 'hi-tmpgenc' is a custom quantization matrix file I use a lot,
Oh, another thing that Compressor doesn't allow that I can see is the
ability to specify your own quantization tables).
Anyhow - if the B and P frames are the same or similar size then the
B frames aren't really helping much. If the B frames are 1/2 or 1/3
the size of the P frames then they're useful - otherwise they're
just "sucking bits away from the P frames".
> Just did a comparison of mencoder and mpeg2enc. I am VERY pleased with
> mpeg2enc output.
You're using the cvs version, correct?
> Can you be more specific as to what you mean by
> filtering/pre-processing? Any direction toward literature would be welcome.
denoising, medianfiltering, spatial (bandwidth limiting), sharpening.
'y4mdenoise'/'yuvdenoise', 'yuvmedianfilter', 'y4mspatialfilter' and
'y4munsharp' respectively. There are other filters that can be
added in to the pipeline. Oh, and of course scaling and chroma
space conversion using 'y4mscaler'. Many of those are as cpu intensive
or more so than the encoder.
> > How long of a project is it planned to be?
> Small. Less than 10 minutes. I just wanted to understand the
Oh, ok - you don't have to worry about the bitrate then. -b 8500 or
even a little higher will be fine.
> Nearly always 30, because our clients work in 29.97. For our dvd work I will
> chop it down. That makes great sense. I forgot that dvd's can work in 24fps!
Sure - you generate 24 (well, 24000/1001) progressive, apply the 2:3
pulldown and end up with a DVD that will play at 30000/1001 as
people expect. BUT if they have a progressive scan TV and a
progressive scan DVD player (which almost all are these days) which
will undo the 2:3 pulldown they'll see the progressive movie. And
folks using a computer will be happy too - since computer displays
are progressive and most DVD player apps can do a 2:3 pulldown
revert.
> > The obvious (and it is a VFAQ - Very Frequently Asked Question ;))
> > one that comes to mind is that you can NOT append/catenate multiple
> > files seamlessly with dvdauthor ...
> At the risk of being off topic, do you mean you can't set dvdauthor to
> play #1_mpeg into #2_mpeg into #3_mpeg without flaws? That could be a
That's precisely what I mean. You can't append multiple .m2v files
end-on-end in a single track and not have (player dependent) glitches.
Some will stop at the join/splice point, others will stutter but
struggle thru, and some will play thru ok.
> Thanks for all the help! I look forward to putting some things together.
You're welcome. Have fun!
Cheers,
Steven Schultz
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Mjpeg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
