Long movies on 1CD

[maormini]

Hi!

I have searced the forum up and down but I still did'nt find a thorough answer.

I am encoding 180-200 min video files, and I MUST get them on 1CD with the best quality possible. The video is of lectures so I believe that it is classed as mainly low motion, but at the beggining of the movie there is usually a 5min fast motion video clip. The Res I use is usually around 500.

The audio I am using is usually compressed to a 50-60MB Mono Mp3 file so that leaves me with 600MB for the video file (as I have more stuff on the CD.

Is there any pro here who is willing to help me and give me the best settings for such a project? (such as using which VHQ, quant, Qpel GMC B-Frames... and which Xvid codec is best suited for my needs)

I will really appreciate any help!

[jkwarras]

USe C3d (convolution3d) avisynth denoiser with MovieLQ preset, and a soft resizer (maybe Simpleresixze or bilinear) and XviD with 2-3 bframes (defaults settings), VHQ1 (4 if you have a powerfull PC and patiente), GMC, lumamasking (optional some will say it doesn't give good results but it works fine for me), Croma motion, ULtraHIgh search, H263 quant, trellis, and see if ti works for you. The rest, just experiment.

For the avisynth part, if you don't know nothing about it and don't want to know, just use Gknot to encode your movie and check the denoisers option (high noise) and resizer.

BTW there's a lot of guides to encode to Xvid over the net, read them as this will help you a lot.

[Alxemi]

First of all the audio. If you are not using MP3 to keep compatibility with something i recommend you to use an OGG-Vorbis mono sound track; you will have more quality with the same size or the same qualituy in less size.
More things: Use OGM as a container and Koepi´s OGMCalc to calculate the desired size. the frame-overhead in OGM gives you more space than the normal AVI one. Also OGM is necessary if you used a vorbis audio track.

In the avs i would try:



Lumafilter() -always
Undot() -always
Billinearresize

and c3d+fluxsmooth combo depending of the source

Convolution3d("moviehq")
FluxSmooth(12,12)
if the source is clean or

Convolution3d("movielq")
FluxSmooth(7,7)
if the source is noisy

Then you will have a very compresible frame, especially if the movie is full of low motion.

For the XviD codec use
Motion Search Ultra High
Quant H.263
The higher VHQ your system can afford (always at least 1)
chroma motion and QPEL ON.
i´ve never used lumimasking, it´s reported that it doesn´t work fine for now, but you can try. Maybe the lumafilter() helps this setting to avoid blocky dark zones
chroma motion and trellis ON in the debug tab+
Remember to restart quantization to 2-31 (just in the case you had them limited to 2-4 2-8 as many people does)
Use the credits tab if the credits are dispensable for your encode and use heavy settings for them like greyscale and q 26

And finally the mother of all settings: the bframe configuration is, IMHO the most determinant setting for the final size/quality.

You can try first VERY HEAVY settings (3/100/200/90) or (3/100/200/60)
Take notice that (3/100/200/90) will give you only very compressed bad quality b-frames. Try that and if you get an undersize (yes, it IS possible) go lower and lower, for example
1-(3/100/200/90)
2-(3/100/200/60)
3-(3/100/200/0)
4-(3/100/125/20)
5-(3/125/100/0)
6-(3/150/100/20)
7-(3/150/100/0)

Make the first pass with these settings and before the second take a look to the stats file with Koepi´s Statsreader, if the max size is less than the disired size, go to a lower bframe configuration and try again till the max size is a little higher or equal than the desired (the codec will have to cut away some bits). Then make the second pass with the same settings.

If you don´t have a good result with all this (don´t expect too much), use more smoothers/noise removers in the avs script or go to a lower resolution.

OK i wrote this post in a hurry and it will be full of gramar errors and misunderstandings, if you don´t understand anything, please ask! :)
Also take notice that i´m everything but an encoding expert like the ones we have in this forum, so don´t think this post is sacred-word.
You all guys out there what are you waiting for! correct me!

Best Regards and good luck

[Tuning]

I think it will be difficult for this lengthy video to be compressed to 1 CD.i.e
as you are having 180-200min video,lets find what will be approximate bitrate.Take lenght to be 180 min =3 hrs.

600MB=600*1000*8kb=4800000KiloBits(approx)
And you have 180 min video,
for i min 4800Mbits/180=26.6~~27Megabits per minute
So for 1 second you will be having 27*1000/60=450kb per second.(approx)

That is 450 kbps will be your average bitrate.Which I think is very low and produce terrible looking MPEG-4 files.As you have mentioned the source video is some lecture ,I think it will be full of light making even difficult to encode to 600MB.

But otherwise if your source is dark(i.e like "The Matrix" movie),this bitrate can be employed. So my sugesstion is to do a compressibility test and verify what bits/pixel value is obtained and perform a two pass-encoding method.

:) -Tuning

[vinkes]

Hi maormini,

I've read the two other replies which had some very good tips, though you might want to look into using other quantization matrices in order to increase compression. I did some testing with it some 6 months ago, you can find it here.

http://forum.doom9.org/showthread.php?threadid=53594

Alxemi said that it might wise turn on qpel, but it thought it increases your first pass size (thus decreasing compressibility).
But I might be wrong on this one (correct me if I am).

Good luck!

[Alxemi]

Alxemi said that it might wise turn on qpel, but it thought it increases your first pass size (thus decreasing compressibility).
You are right about this. It´s only that I always use qpel (even with low-bitrates encodes) because IMHO it deserves the bits-waste when combinig with bframes.
But in this case maybe it doesn´t... it´s just a matter of testing :rolleyes:

anyway i think that bframes configuration is the decisive matter. As tuning said, do some compresibility tests (maybe 10% for a more trusting result).

Can i ask what movie is it? maybe somebody has some previous experience with it.

[sysKin]

Hi,
jkwarras said GMC, don't do that in dev-api-3 (ie the builds you can currently get) - it doesn't work there.

You might try getting newest dev-api-4 instead, at least to use GMC.

Radek

[maormini]

Thanks guys for all your replies

I am going to do some testing and post my results, who knows maybe someone else can use them! :)

Thanks again, and I am always open to more suggestions! ;)

[Joe Fenton]

An idea... say you use GordianKnot - set it up to encode the initial high-motion clip at a decent rate (~1000k), then use the Credits setting of GordianKnot to make it encode the rest of the video at a much lower setting - say 50% to 60%. Instead of encoding the last ~5 minutes at a lower rate, you're encoding the last ~115 minutes at a lower rate.

Play around with the initial rate to make the high-motion start look good, then play around with the credits reduction value to make the rest fit on one CD at the best possible rate.

[mrlipring]

that is, of course, if your university lectures have credits. ;)

[ominte]

Just because no one has yet mentioned it but...
if you are encoding at a rate of approximately 450kb/s and compatibility isn't a problem then I think you should try RV9-EHQ. In this bitrate range it is definitely the king. Almost no MPEG-4 codec is successful at bitrates under 500kb/s.