Which codec for low bitrate, low motion?

[Atamido]

I'm going to be encoding some DVDs that are mostly just shots of somebody standing still and talking. Almost no music, a couple of pans, and a few very slow zooms. I'm looking at no resize from the full DVD res and fitting 4 hours on a 700MB CD. If it does well enough, I might try for 6 hours in a 700MB CD.

For the audio I think I will use Vorbis. Speex would be the best pick if there were a good codec set for it, but it isn't an option right now. However, I'm not sure what video codec to use.

The last time I tried something like this, WV9 actually did the best job of spending more bitrate on keyframe for less bitrate on very similar P frames. But that was less than a year ago, and it wasn't a lot of testing. I'm not sure if RV10 is an option as I was never able to get RV9 to work for encoding.

So what codecs would work best for this situation?

[Manao]

I'd say h264 / AVC. If it's really static, perhaps give XviD a chance, but I doubt it.

[PatchWorKs]

Why not Theora ?

[pernas]

..or VP62 (available from link below)
I crunched "Jesus of Nazareth" (371min) to one CD a while ago.

Regards,
Per

Edited: ;)

[Sharktooth]

It IS free for personal use. It's just no longer distribuited on the On2 website.
If you want you can download it from here: http://ebola.gamersrevolt.it/vp6/VP6.4.2.rar

[Sirber]

If you don't care about the container, why not RV10? It should be better than VP6 at low bitrate.

For audio, HE-AAC at 32kbps.

[Sharktooth]

VP6 retains more details than RV10.
But it's your choice.

[Atamido]

The material can be freely distributed, but I don't know about hosting the VP6 codec. If someone gets the video from edonkey, I don't want them to be SOL on trying to find a way to play it back.

Some of the same worries go for h.264.

Alternately, I am a little nervous about fiddling with Real again. Last time (a year ago) it was a fruitless endevor that resulted in many lost hours.

Maybe I should just try them all and do a "codec comparison" of my own?

[Sirber]

Originally posted by Pamel
Maybe I should just try them all and do a "codec comparison" of my own? :D

[Manao]

FFDshow / ffmpeg can play h264 ( and witht the great work of akupenguin, it can now even play h264 with b-frames and weighted prediction ), so your friends won't have any issues for playbacking them ( it's now more portable than vp6 and wmv9, and perhaps rv10 )

But of course, if you've got some time to afford, testing all the codecs would be the best alternative ( all the codec means : nero's h264, vp6 / vp7, rv10 and xvid, i've got doubts about wmv9, and divx & theora are too inefficient ). I'd also try snow, because it is said to be very efficient at low bitrates.

[708145]

I'd love to have snow tested in a codec shootout :D

But please make sure to enable the enhanced search there. Something along these (but not limited to) settings would be nice.
pred=0:cmp=1:subcmp=1:mbcmp=1:qpel

bis besser,
Tobias

[Tommy Carrot]

Snow doesn't even have rate-control, so testing it against other codecs is a bit difficult. Of course it's not impossible, but you gotta have strong patience to keep adjusting the quality slider until the encoding reaches the requested size. :D

[708145]

Originally posted by Tommy Carrot
Snow doesn't even have rate-control, so testing it against other codecs is a bit difficult. Of course it's not impossible, but you gotta have strong patience to keep adjusting the quality slider until the encoding reaches the requested size. :D

the best setting after 3 iterations of interpolation search should suffice ;D
That's 4 encodes => double effort compared to 2pass encodes of the other contestants.

bis besser,
Tobias

[akupenguin]

Originally posted by 708145
the best setting after 3 iterations of interpolation search should suffice
That's 4 encodes => double effort compared to 2pass encodes of the other contestants.
The difference in speed between fastest and best settings in Snow is small, so it's not worth a separate pass.

My test (5000 frames):
1st pass (quant = half the average quant of an mpeg4 encode): +20% off target bitrate
2nd pass (multiplied the 1st quant by 1.20): +1.0% off
3rd pass (multiplied the 2nd quant by 1.01): +0.9% off
(3rd pass didn't help due to the fact that quantizer isn't continuous.)

In short: 2 passes is probably as good as you're going to get.
(Which is not to say that Snow wouldn't benefit from ratecontrol: There's more to it than just meeting the target size.)

[708145]

Originally posted by akupenguin

My test (5000 frames):
1st pass (quant = half the average quant of an mpeg4 encode): +20% off target bitrate
2nd pass (multiplied the 1st quant by 1.20): +1.0% off
3rd pass (multiplied the 2nd quant by 1.01): +0.9% off
(3rd pass didn't help due to the fact that quantizer isn't continuous.)


Let me explain what I meant by 3 iterations of interpolation search:
* Select 2 quant estimates QA and QB which make "sense".
* 1st iteration: encode with QA and QB
* compute QC linearly to reach target size
* 2nd iteration: encode with QC
* compute QD taking into account the non-linear-ness of the estimate QC and the error in size.
* 3rd iteration: encode with QD
* use the encode that best fits your constraints (should be QD of course)

If the quant vs. size curve is known better estimates QC and QD could be made. I assume here it is unknown!


In short: 2 passes is probably as good as you're going to get.
(Which is not to say that Snow wouldn't benefit from ratecontrol: There's more to it than just meeting the target size.)


Sure a good rate control would be even better!

bis besser,
Tobias

[akupenguin]

Originally posted by 708145
If the quant vs. size curve is known better estimates QC and QD could be made. I assume here it is unknown! While it's not perfectly linear, bitrate is very close to proportional to 1/qscale. So there's no need to interpolate:

select QA that makes "sense"
1st iteration: encode with QA
select QB = QA * (1st size) / (target size)
2nd iteration: encode with QB
maybe stop here
select QC = QB * (2nd size) / (target size)
3rd iteration: encode with QC
you're not going to get better than the 3rd.

[708145]

:D Good to know!

Thanks for this info.

bis besser,
Tobias