 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
When i play South Park The Movie on my PC's DVD (Sony 24" 1920x1200)
it just gets me all hot and bothered, encoder wise.
I want to make mpegs that good. (i drool over the paper cutouts, not the
CG stuff)
So i discovered VirtualDub.
I run my 3500 720x512 PNG frames through mpeg_encode at the highest
quality.
This yields a pretty unplayable, yet correct mpeg.
I then pass that through VirtualDub using the Microsoft MPEG-4 Video
Codec V2
which gives me decent avi file. Actually, it looks like crap next to
the
aforementioned South Park DVD, but it is getting there. (slow movement
is bad
and gets that avi blocky look)
I'm going to try Flask MPEG next.
--
dik _,--"
`-._ ________-_______ "----
_----'--'--------------------------------'--'----_
//_| | \ dic### [at] buckosoft com / | |_\\
(_____|_|__= Guilford CT +1.203.458.0389 =__|_|_____)
_\_____=___ http://www.buckosoft.com ___=_____/_
\/-(o)-~~-(o)-~~-(o)-`------'-(o)-~~-(o)-~~-(o)-\/
Early Net Poetry:
Wustl, Wustl, ERR RIP MIT BOOT, BIND Wustl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dick Balaska <dic### [at] buckosoftcom> wrote:
: So i discovered VirtualDub.
: I run my 3500 720x512 PNG frames through mpeg_encode at the highest
: quality.
: This yields a pretty unplayable, yet correct mpeg.
: I then pass that through VirtualDub using the Microsoft MPEG-4 Video
: Codec V2
: which gives me decent avi file. Actually, it looks like crap next to
: the
: aforementioned South Park DVD, but it is getting there. (slow movement
: is bad
: and gets that avi blocky look)
: I'm going to try Flask MPEG next.
Eh, I think that you confuse a couple of things here.
Firstly, it's not VirtualDub which encodes the video/audio stream. VirtualDub
just let's you choose a video/audio codec installed in your system and then
let's that codec to do the job. VirtualDub is merely a user interface for
using the installed codecs (VirtualDub doesn't actually care which codecs you
have installed; it just looks at what you have and then lets you choose among
them).
So if you have any concern about the quality of a video, don't blame
VirtualDub, but blame the codec and settings you are using (it's not VirtualDub
which generates the quality you are seeing, but the codec, which has nothing
to do with it).
Secondly, encoding frames first to MPEG-1 and then from that to MPEG-4 is
a *REALLY BAD IDEA*.
When you encode to MPEG-1 you lose the most. After this what was lost, is
lost; you can't get it back. Thus converting it to MPEG-4 can't give you any
more quality. MPEG-1 does a really bad job in encoding, so don't use it.
What you should do is to convert your frames directly to an AVI with raw
video (there are tools for that in the net; they just take the frames and
put them in a raw format in the AVI and that's it). Then you can open this
AVI in VirtualDub and encode it to another AVI using MPEG-4 (I suggest using
the latest DivX codec as it has lots of quality fine-tuning options and
optimizations; http://divx.com).
What a DVD uses is the MPEG-2 format. MPEG-4 can reach the same image
quality with smaller file sizes. It's just a question of encoding it in
the right way (ie. *don't* use MPEG-1 as an intermediate format) and choosing
the proper quality settings.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Dick Balaska <dic### [at] buckosoftcom> wrote:
> : So i discovered VirtualDub.
> : I run my 3500 720x512 PNG frames through mpeg_encode at the highest
> : quality.
> : This yields a pretty unplayable, yet correct mpeg.
> : I then pass that through VirtualDub using the Microsoft MPEG-4 Video
> : Codec V2
> : which gives me decent avi file. Actually, it looks like crap next to
> : the
> : aforementioned South Park DVD, but it is getting there. (slow movement
> : is bad
> : and gets that avi blocky look)
>
>
> Eh, I think that you confuse a couple of things here.
No, not really. [1]
>
> Firstly, it's not VirtualDub which encodes the video/audio stream. VirtualDub
> just let's you choose a video/audio codec installed in your system and then
> let's that codec to do the job. VirtualDub is merely a user interface for
> using the installed codecs (VirtualDub doesn't actually care which codecs you
> have installed; it just looks at what you have and then lets you choose among
> them).
"I then pass that through VirtualDub using the Microsoft MPEG-4 Video Codec V2"
Maybe that sentence was unclear. I did mean "through the VirtualDub stream filter
system". To be combatant about it ;O it *is* VirtualDub which encodes the stream.
The codecs just supply a filter specific to a type of stream.
> So if you have any concern about the quality of a video, don't blame
> VirtualDub, but blame the codec and settings you are using (it's not VirtualDub
> which generates the quality you are seeing, but the codec, which has nothing
> to do with it).
>
> Secondly, encoding frames first to MPEG-1 and then from that to MPEG-4 is
> a *REALLY BAD IDEA*.
> When you encode to MPEG-1 you lose the most. After this what was lost, is
> lost; you can't get it back. Thus converting it to MPEG-4 can't give you any
> more quality. MPEG-1 does a really bad job in encoding, so don't use it.
Actually, as i said, i have a top quality MPEG-1. It is unplayable because
the bitrate is way too high. But i can look at individual frames and they
are pretty dang close to the original PNGs.
In fact, if i select RGB uncompressed as the output of VirtualDub, i get a
beautiful AVI file that weighs in at 3.5GB for 1:57 of video. Also unplayable,
but again, the individual frames look mahvalous.
Here i think *you* are mistaken. There is nothing in the MPEG-1 spec that
sez it has to look crappy. If i encode a GOP of 1 (all I frames) with
ISCALE = 1, i am going to get pretty close to the source output. Of course,
there is no M$ software that is going to deal with such a bitrate that this
MPEG would require.
(Someday, i'd like to measure SCSI 160's actual transfer rate under Win2K.)
Is it not true that MPEG-2 is son of MPEG-1 with some new fangled compression
algorithms? I believe it was one of the Berkeley boys that said something to
the effect of "When we were researching codecs for the new HDTV format, we were
surprised that MPEG-1 was designed robust enough that it just scaled up and
thus it became the basis for the new MPEG-2 format".
> What you should do is to convert your frames directly to an AVI with raw
> video (there are tools for that in the net; they just take the frames and
> put them in a raw format in the AVI and that's it). Then you can open this
> AVI in VirtualDub and encode it to another AVI using MPEG-4 (I suggest using
> the latest DivX codec as it has lots of quality fine-tuning options and
> optimizations; http://divx.com).
In my gropings, i found that MPEG-4 V2 actually gave me a better output than
DIVX-4.1 .
And neither is as good as MPEG. For example, here is a frame:
http://frank.buckosoft.com:2270/_frd?t=m&project=tteoac-512&Frame=2151
(from the 512x384 set). The spotlight on the wall is the headlamp of the locomotive.
POV-Ray makes beautiful delicate shadows on the wall which MPEG-1 preserves
pretty well. All of the AVI codecs i've tried turn that beige/white wall
and it's shadows into fractalized blocky things.
I was surfing through the porny groups (strictly as a research project)
and none of the DIVXs or MPEG-4s look as good as the few MPEG-2s that i found.
(Classic example: the "model" is being videoed and photoed at the same time.
The flash of the stills camera totally confuses the video codec into the
exact same fractal patterns that i am getting).
> What a DVD uses is the MPEG-2 format. MPEG-4 can reach the same image
> quality with smaller file sizes.
I have a Sigma MPEG-2 encoder in my PC. If i could find a way to feed it PNGs
at 30 fps, i'd be all set. Um, no i wouldn't; it wants video in. Maybe i could
print out my frames and hold them in front of a camera real fast.
> It's just a question of encoding it in
> the right way
yes.
> (ie. *don't* use MPEG-1 as an intermediate format) and choosing
> the proper quality settings.
>
> --
> #macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
> N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
> N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
[1] Last year i wrote a WindRiver [2] (some embedded system) device driver for a
Sigma Designs MPEG-2 encoder and then multicasted that data.
[2] The same OS that's in the "we don't know where it went" Mars Lander. I imagine it
is sitting on Mars with a hung TCP/IP stack, a nasty bug i fought many times
by stuffing too much MPEG-2 down it's throat.
dik
Post a reply to this message
|
|
| |
| |
|
|
From: Luke Church
Subject: Re: My quest for the holy grail of encoders.
Date: 14 Feb 2002 08:39:30
Message: <3c6bbe12@news.povray.org>
|
|
|
| |
| |
|
|
> Maybe that sentence was unclear. I did mean "through the VirtualDub
stream filter
> system". To be combatant about it ;O it *is* VirtualDub which encodes the
stream.
> The codecs just supply a filter specific to a type of stream.
I don't pretend to know much about the mecahnics of video encoding, but
surely even though VitrualDub actualy does the mathematical operations, they
are dictated by the codec, and hence it shouldn't actually matter which
encoder you use?
> Actually, as i said, i have a top quality MPEG-1. It is unplayable
because
> the bitrate is way too high. But i can look at individual frames and they
> are pretty dang close to the original PNGs.
Only to the eyes. Isn't MPEG a bit like JPEG in that it executes profiled
on what people can see and that overlaying one MPEG compression on top of
another (AKA pre-encoding, re-encoding) actually 'corrupts' the frames much
faster than single encoding.
Also MPEG-1 has brutual image size limitations.
> Here i think *you* are mistaken. There is nothing in the MPEG-1 spec that
> sez it has to look crappy. If i encode a GOP of 1 (all I frames) with
> ISCALE = 1, i am going to get pretty close to the source output.
Yup, This is like firing a series of JPEG files as all files are internal
only encoded....
>Of course,
> there is no M$ software that is going to deal with such a bitrate that
this
> MPEG would require.
Are there any under anything else that will either? What kind of bitrate
does this actually require?
> (Someday, i'd like to measure SCSI 160's actual transfer rate under
Win2K.)
>
> > What you should do is to convert your frames directly to an AVI with
raw
> > video (there are tools for that in the net; they just take the frames
and
> > put them in a raw format in the AVI and that's it). Then you can open
this
> > AVI in VirtualDub and encode it to another AVI using MPEG-4 (I suggest
using
> > the latest DivX codec as it has lots of quality fine-tuning options and
> > optimizations; http://divx.com).
Can't you use something like Fast Movie Processor to skip the raw video
phase and go directly from frames to compressed video?
> And neither is as good as MPEG. For example, here is a frame:
> http://frank.buckosoft.com:2270/_frd?t=m&project=tteoac-512&Frame=2151
> (from the 512x384 set). The spotlight on the wall is the headlamp of the
locomotive.
> POV-Ray makes beautiful delicate shadows on the wall which MPEG-1
preserves
> pretty well. All of the AVI codecs i've tried turn that beige/white wall
> and it's shadows into fractalized blocky things.
Sorry, I have to write these damn things offline, but I'll check it out
soon... What settings were you using on the AVI codecs?
> I was surfing through the porny groups (strictly as a research project)
;) - Joke
> and none of the DIVXs or MPEG-4s look as good as the few MPEG-2s that i
found.
> (Classic example: the "model" is being videoed and photoed at the same
time.
> The flash of the stills camera totally confuses the video codec into the
> exact same fractal patterns that i am getting).
>
> > What a DVD uses is the MPEG-2 format. MPEG-4 can reach the same image
> > quality with smaller file sizes.
> I have a Sigma MPEG-2 encoder in my PC. If i could find a way to feed it
PNGs
> at 30 fps, i'd be all set. Um, no i wouldn't; it wants video in. Maybe i
could
> print out my frames and hold them in front of a camera real fast.
Yeah, that would a cool thing to do! Back to the 'good old days' of
animation! Could you try using FMP with an MPEG 2 codec? Does this cause you
the same compression problems?
As for Flask, I have heard varying reports of it... Personally I found my
relationship with it a very short one...
1. Installed it
2. Ran it
3. It crashed horribly
4. Ran it
5. It did bugger all
6. Ran it
7. It crashed
8. Installed a different version
9. It half did something, and took a little while
10. It crashed
11. It was uninstalled and the install files deleted...
However I know people who swear by it, good luck and backup your data...
My 2 yen,
Regards,
Luke
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dick Balaska <dic### [at] buckosoftcom> wrote:
: "I then pass that through VirtualDub using the Microsoft MPEG-4 Video Codec V2"
: Maybe that sentence was unclear. I did mean "through the VirtualDub stream filter
: system". To be combatant about it ;O it *is* VirtualDub which encodes the stream.
: The codecs just supply a filter specific to a type of stream.
No, VirtualDub just asks the codec to encode the stream. VirtualDub does
not encode it itself (it just gives data to the codec and then stores the
data returned by the codec to a file).
: Actually, as i said, i have a top quality MPEG-1. It is unplayable because
: the bitrate is way too high. But i can look at individual frames and they
: are pretty dang close to the original PNGs.
I personally would not make the in-between MPEG-1 step, no matter how high
quality it would be. It's perfectly possible to make an AVI with the raw frames
and encode that to some MPEG4 format, so why not do that? You minimize the loss
of data.
: Is it not true that MPEG-2 is son of MPEG-1 with some new fangled compression
: algorithms? I believe it was one of the Berkeley boys that said something to
: the effect of "When we were researching codecs for the new HDTV format, we were
: surprised that MPEG-1 was designed robust enough that it just scaled up and
: thus it became the basis for the new MPEG-2 format".
MPEG-1 may be good as a streaming format, but the video compression algorithm
it uses is not very good (in today's standards). It compresses too little with
too much loss of quality.
: POV-Ray makes beautiful delicate shadows on the wall which MPEG-1 preserves
: pretty well. All of the AVI codecs i've tried turn that beige/white wall
: and it's shadows into fractalized blocky things.
What quality settings did you use? If you use some 120 kbps bitrate for
the video, no wonder why you get such an awful result.
At about 2000 kbps the MPEG4 video should be almost perfect (although it's
a bit bloated in file size; usually something like 500 kbps is a good
compromise). With DivX you can go up to something like 6000 kbps.
I have encoded lots and lots of DivX AVIs. I have some experience.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> It's perfectly possible to make an AVI with the raw frames
> and encode that to some MPEG4 format, so why not do that? You minimize the loss
> of data.
ok. What do you use to make the raw avi? The old M$ videdit thingy?
>
> What quality settings did you use? If you use some 120 kbps bitrate for
> the video, no wonder why you get such an awful result.
> At about 2000 kbps the MPEG4 video should be almost perfect (although it's
> a bit bloated in file size; usually something like 500 kbps is a good
> compromise). With DivX you can go up to something like 6000 kbps.
Well, i cranked up both the "Compression Control" to 100 and the data rate
to 6000 kbps. Maybe i should try backing them off a little.
> I have encoded lots and lots of DivX AVIs. I have some experience.
Cool. What do you typically use for keyframe options? 1 per second?
Do you use the Divx "fast motion" or "slow motion" encoder?
dik
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dick Balaska <dic### [at] buckosoftcom> wrote:
: ok. What do you use to make the raw avi? The old M$ videdit thingy?
http://www.bloodshed.net/avi.html
Not an amazing program (supports just BMP), but does its job.
: Cool. What do you typically use for keyframe options? 1 per second?
I have left it at its default, which seems to be each 300 frames.
: Do you use the Divx "fast motion" or "slow motion" encoder?
I use DivX 4.x which doesn't have those anymore (those are DivX 3.x codecs).
If I just want to sample something on the fly (from my tv-card) I use
the 1-pass variable bitrate mode (performance/quality: slowest). (Good thing
I have a fast computer :) )
If I want to get extra compression (about 5 to 10%) I first sample to a
very high bitrate (eg. 3000 kbps) and then I re-encode with the 2-pass mode
to the final bitrate (eg. 500) (perhaps a bit of quality is lost by doing
this, but nothing really visible).
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
