Bitrates again - this time I want a straight answer

[ajmoss]

I have tried numerous times to elicit a recommendation as to the bit rate I should use in DivX 5. Each time I've been told that there is no single answer to this, and I should experiment. The thing is, I really don't have time to encode each of my files several times over, with parameters varying by 10% or less, and my powers of observation wouldn't be good enough to tell the difference anyway.

In fact it goes further than that. My computer is fast enough to capture and encode into DivX in real time, and it would be a huge waste of disk space and CPU time to perform an initial capture into the Huffy codec. This means I only get one chance to set the bit rate correctly, and furthermore I can't use two pass encoding.

In the files http://www.doom9.org/gknot-basics-divx3.htm and http://www.doom9.org/gknot-basics.htm (the latter is for DivX 4), the advice given is:

It's a bit guesswork as you cannot predict compressibility of your movie but here's some hints:

It's not a good idea to go below 0.20 bits/pixel*frame
If you go above ~0.35 yo might not be able to reach your desired filesize
If you go for 1 CD stay close to 0.20
If you go for 2 CDs stay around 0.27
If TV bits/pixel*frame is below ~0.13 you should raise your bitrate (and go for more CDs).

The recommendations in http://www.doom9.org/gknot-basics-divx5.htm are a bit lower, because of the greater compressability of B frames:

It's a bit guesswork as you cannot predict compressibility of your movie but here's some hints:

It's not a good idea to go much below 0.17 bits/pixel*frame
If you go for 1 CD stay close to 0.17
If you go for 2 CDs stay around 0.25
If TV bits/pixel*frame is below ~0.13 you should raise your bitrate (and go for more CDs).

This appears to be the Philosopher's Stone, the big secret that noone wants to divulge.

To put it simply, I'm already familiar with the notion of a range of recommended bit rates - with MPEG-1, the bit rate of VCDs is reckoned barely adequate for the job, and so a bit rate of 1.5Mbit/s is considered advisable. ATI recommends using 2.4Mbit/s, to ensure that the limiting factor is always the limitations of the codec, not that of the bit rate.

One implication of these quotes is that the recommended bit rate scales linearly with the number of pixels. When capturing a PAL TV programme, it makes some sense to do so at half PAL resolution (352x288 pixels, the same as a VCD): the colour information is stored at this lower resolution, and it decreases the workload on the CPU running the codec. It also reduces the necessary video bit rate by three quarters.

352x288 pixels is just over 100,000; this makes 2.5 million pixels per second. By this calculation, you will get a good quality picture with B frames enabled (around 0.25 bits/pixel) at 640 kbit/s. If you add to this a good quality MP3 audio at 160 kbit/s, you get a round 800kbit/s in total.

This is probably less than you would normally use for a DVD conversion, because a DVD conversion would typically be done at a higher resolution than 352x288 pixels.

The capacity of an 80 minute CD is

8 bits * 2048 bytes * 75 frames * 60 seconds * 80 minutes

= 16,384 * 360,000

One hour's recording on a CD therefore works out at 1,638,400 bit/s.
At a bit rate of 800kbit/s, you will get two hours onto a CD.

You could safely reduce the video and audio bit rates by 20%, to 500kbit/s video (0.20 bits/pixel) and 128kbit/s audio. This will give you 2.5 hours recording time on a CD. If you need to squeeze on any more than that, you really need to reduce the video resolution.

An hour-long British programme on Channel 4 (in the UK) is typically 50 minutes without the adverts. You could store this at a resolution of 800kbit/s video plus 160kbit/s audio, or if you like, 768kbit/s video plus 192kbit/s audio. At this bit rate, you get 100 minutes on a CD.

An hour-long American programme, such as Buffy or the X Files, is typically only 42-43 minutes long without the adverts. At 600kbit/s video plus 160kbit/s audio, you can get three episodes onto one CD.

[Swede]

At 600kbit/s video plus 160kbit/s audio, you can get three episodes onto one CD. Why don't you just go ahead and try this? That's the only way you're going to find out if this quality is good enough for you. And, of course, depending on the action/colors/noise of the episode, the quality will shift between episodes. I've done a copule of DVD's at higher res. than 352x288 at ~600 that has been ok, but if this is not a clean source...

And... cross-posting is *not* allowed and generally not a good idea if you want a good answer.

[DJ Bobo]

Suddenly I remembered what Bruce Lee said in the "Enter The Dragon" movie: "What was that?! an exibition?! - We need emotional content, not anger! - Now, try again!"
This applies here too, IMHO! :D

Well, let me tell you something, encoding is feeling! my feeling says to me:
* if you're encoding anime, try to stay over 0,3bit/pixel, BUT! if you have to get a given amount of episodes on one CD, no matter what, stick to this:
384x288 for 5 episodes per CD
448x336 for 4 episodes per CD
512x384 for 3 episodes per CD
And it's equal for me what bitrate comes out! it will look ok anyway!
* if you're encoding a movie, stay over 0,2bit/pixel, no matter what! and it will look ok anyway!
* 2-pass is a must, unless you're expecting the movie or episodes to get saturated and not filling the CD anyway, so use quality based 100% encoding and fill the rest with as much audio bitrate as you can... that if the highest bitrate was high enough to fill the rest ;)
* as for DivX5 parameters, bidirectional encoding and nothing else! and if you feel like even without bidir. encoding the CD won't get filled, disable it! the quality will get slightly better, even if you won't notice it ;)
* don't look for perfect quality at any price, if you get "perfect" quality, fine! if not, be happy with what you get, and you'll see, even a medium quality encoding will look fantastic with a little more post processing and a light film effect... ;)

[jggimi]

I find that some things look great at 800kbps, some things need more at 1500kbps. It's content specific.

If you don't have time to experiment over-and-over with 2 hours of content.....don't!

Experiment with a 30-second excerpt.

[theReal]

This is just like if you ask: "How much salt do I have to put in my soup to make it taste good? I don't have time to try out different amounts, so I need a clear answer, quick!"

So, if this is what you want, I'll give you an exact answer: Use a bitrate of 1523, it's perfect. ;)

[ajmoss]

Originally posted by theReal
This is just like if you ask: "How much salt do I have to put in my soup to make it taste good? I don't have time to try out different amounts, so I need a clear answer, quick!"

So, if this is what you want, I'll give you an exact answer: Use a bitrate of 1523, it's perfect. ;)

A simple, didactic answer like this is, in a sense, what I want. But the number you provide is outside the range that I would consider believable.

Someone somewhere told me to use one pass quality-based encoding, with a quality parameter of 2. I tried this, and also tried it with other parameters (3, 4, 5, 6...).

Quality=2 gave a video bit rate of about 3 Mbit/s, which is clearly excessive. Perhaps the point is that this is suitable for initial video capture (if you don't want to use Huffy), where the bit rate can be reduced subsequently, and it avoids the ugly artifacts that result from capturing to MPEG and transcoding.

Quality=4 (which turned out to give a video bit rate of about 1500 kbit/s) gave acceptable results; quality=5 (1000 kbit/s) and quality=6 (600 kbit/s) were noticeably blurred and pixellated. It seems odd that I got unacceptable results with the quality=5 setting, which works out at 0.4 bits/pixel, way above the 0.2 bits/pixel recommended by DJ Bobo, but that's probably a result of poor optimisation - two pass encoding must surely use better quality when it's needed, and worse quality when it can get away with it.

[ajmoss]

Originally posted by DJ Bobo
Well, let me tell you something, encoding is feeling! my feeling says to me:
* if you're encoding anime, try to stay over 0,3bit/pixel, BUT! if you have to get a given amount of episodes on one CD, no matter what, stick to this:
384x288 for 5 episodes per CD
448x336 for 4 episodes per CD
512x384 for 3 episodes per CD
And it's equal for me what bitrate comes out! it will look ok anyway!
* if you're encoding a movie, stay over 0,2bit/pixel, no matter what! and it will look ok anyway!

Thanks. *This* is the kind of advice I've been wanting, all this time.

By anime, you also mean cartoons, like The Simpsons, King of the Hill and South Park, right?

I'm stuck with 352x288 pixels, because that's my the resolution of my source files. Instead, I have to decide how many episodes of a TV series to fit onto one CD. This is the opposite to DVD rippers, where the length of the film is fixed but the resolution is configurable.

[ajmoss]

Originally posted by Swede
Why don't you just go ahead and try this? That's the only way you're going to find out if this quality is good enough for you. And, of course, depending on the action/colors/noise of the episode, the quality will shift between episodes. I've done a copule of DVD's at higher res. than 352x288 at ~600 that has been ok, but if this is not a clean source...

Well, I have very poor eyesight. To a certain extent I'm doing this for other people's benefit, because I want to be able to trade DivX files on CDs.

Even if this weren't the case, I can't spare the time to transcode each of my MPEG files to DivX five or more times, to determine the most appropriate bit rate in each case. I have a backlog of several hundred gigabytes of MPEGs to transcode, and I can't afford to buy any more hard disks. If I sound frantic to the point of rudeness, that's why.


And... cross-posting is *not* allowed and generally not a good idea if you want a good answer.

I can't apologise enough for that. I posted my message to the capture forum because anyone capturing direct to DivX would have to pick a single set of workable parameters, which would have to be right first time.

You also asked whether there was a question in what I wrote. I was thinking of the Usenet paradigm, where if you post incorrect advice, someone else will correct it for you. The question was, is my thinking correct?

[ajmoss]

Originally posted by jggimi
I find that some things look great at 800kbps, some things need more at 1500kbps. It's content specific.

If you don't have time to experiment over-and-over with 2 hours of content.....don't!

Experiment with a 30-second excerpt.

Presumably I'd have top experiment with a range of 30 second excerpts, randomly selected from the scenes in the video clip?

[jggimi]

Perhaps. Try starting with one. A single experiment that takes 3-5 minutes of time will give you far more information then guessing.

[brett]

I generally agree with DJ Bobo on everything, but I'll try to add something.

First, I've never really found 0.20bpp (bits per pixel) to be a good idea unless you're doing a little filtering. Generally, I'll go for 0.24bpp for a DVD rip, 2-pass encoding with normal bicubic resizing. If I need a lower bitrate without lowering the resolution, I'll go down to 0.20bpp using soft bicubic resizing and TemporalSmoother(1).

Being able to use a low bitrate depends on having a good source. You can really only get good results between 0.20 and 0.25bpp with a clean progressive source. Even after deinterlacing, you need to go for around 0.27 - 0.30bpp for video sources, and that includes interlaced DVD's, which are about as clean as you can get. That's just the nature field-based video. Even if it looks really clean, video sources have inherent noise, flicker, ghosting and moire. I've had beautiful results with 0.27bpp DivX 5 encodes of interlaced sources, but I always use 2-pass encoding with Decomb, soft bicubic resizing and TemporalSmoother(1) for video.

You're doing 1-pass encoding, so you need more bitrate. On top of that, you're talking about broadcast-quality video. There's going to be significant noise. Noise means you need even more filtering and bitrate. Add to that the fact that you're doing realtime encoding, so you can't do a lot of filtering, and AviSynth is right out, too. It's a pretty grim situation.

I'll give you a better idea of how DivX 5 works with unfiltered noise. I had a DVD of a film that I wanted to rip. Not a low-quality transfer, but the original film was just very grainy. I didn't want to do a lot of filtering, because that would change the whole look of the movie. I wanted to preserve the grain. After a lot of testing, I eventually had to use 0.40bpp (512x272) to keep from having nasty macroblocks all over the place.

I'm not saying you're an idiot for wanting to do 1-pass realtime encoding of video, but you're putting yourself in an odd situation. This forum is populated by people who go overboard to get the best quality. We're mostly hobbyists. I'm sure I'm not the only one who's spent a couple days trying to get the perfect rip of something, which certainly isn't practical when I could've spent the time working a minimum-wage job and had enough money to buy several copies of the DVD. You're going to have a hard time getting good suggestions for quick and dirty encoding.

So, the numbers that Doom9's guide quotes are for 2-pass DVD ripping, and they don't apply at all to what you're doing. If you want to fit two hours PAL TV on a disc, that's:

700.00MB
180,000 frames @ 25.000 FPS
648 kbps video
160 kbps audio
352x288 = 101,376 pixels
0.256 bits per pixel

Another problem is that the DivX 5 codec just works better at resolutions between around 480 to 640, and reducing your resolution doesn't quite reduce the bitrate you need linearly. That is, 0.26bpp at 352x288 isn't as smooth as 0.26bpp at 640x480. You seem to be more interested in numbers than explanations. You could use 648kbps, but 1-pass encoding isn't as accurate as 2-pass, so you might need to go down to 640kbps if you want to be sure you can always fit two hours on a CD.

352x288 at 640kbps will look great if you have a decent source, but you're still talking about TV, so do as much filtering at you can in realtime. If you're capturing in VDub, turn on VDub's noise reduction. If your transcoding MPEG-1, why do you need to do it in realtime? Try a light 2D cleaner and a light temporal smoother (and keep it very light -- TemporalSmoother will work wonders at level 1 or 2, but screw up your video quickly beyond that, especially for lower resolutions). If you must process things faster, just go into your DivX General Parameters and set Pre Processing Source to Strong.

[NeVeRLiFt]

http://www.lukesvideo.com/

Check out Lukes site he has some very good guides for encoding cartoons.

[brett]

Yeah, Luke has good advice for cartoons and for broadcast TV encoding in general, but he suggests tons of filtering that would never work for encoding in realtime.

[NeVeRLiFt]

Best bet is to get a understanding of how the filters effect the encode and take a small sample and do alot of test encoding trying the filters and there settings. Alot of filters will add hours to the time it takes to encode so be warned.

this should help to
http://web.syr.edu/~tjmyers/animefilters.html

[brett]

Originally posted by NeVeRLiFt
Alot of filters will add hours to the time it takes to encode so be warned.


And therefore you're completely off topic. Did you even read ajmoss's post?

[NeVeRLiFt]

Cartoons respond well to filters and Lukes guides and most everyone I know use filters on cartoons. You got a problem? I was telling the poor guy that filter slow down the encoding. But better quality and smaller size can be had using filters with cartoons.

Dont even post in a response to me ok just help the guy out and stop wasting my time.

[brett]

OK, since you still refuse to read the first two paragraphs of ajmoss's post, I'll give you a summary:

HE WANTS TO CAPTURE AND ENCODE DIVX IN REAL TIME. He wants single-pass 352x288 PAL at a relatively low bitrate.

You admitted yourself that the filtering you suggest can add hours to encoding time, which means you didn't read his post or you'd know he wanted realtime encoding suggestions.

[NeVeRLiFt]

I guess it went over your head as to the reason I sent him to Lukes site :rolleyes:

http://www.lukesvideo.com/

Maybe you head over there before making a fool of yourself anymore.

[brett]

Why do you bother replying if you're going to ignore everything everybody says? You're ignoring the topic of the thread. You're ignoring everything AJ was asking. You're ignoring my posts as to why you're totally off topic.

Luke's Video is a great site. Luke's Video tells you how to capture to HUFFY or MJPEG and then encode later with a lot of filtering.

Please feel free to explain how anything you've said relates to AJ's question about realtime DIVX encoding.

[NeVeRLiFt]

@brett

Lukes guides should help him, do you have a problem with this?
As for encoding...

Just follow these links and knock yourself out :p
If your bored and dont have nothing better to do than this LOL then maybe you go watch tv or something and leave the real encoding to the people that know how.


http://forum.doom9.org/showthread.php?s=&threadid=29134

http://forum.doom9.org/showthread.php?s=&threadid=29221

http://forum.doom9.org/showthread.php?s=&threadid=29206

[NeVeRLiFt]

Just follow these links out and then enjoy the great quality :devil:


http://63.231.44.178/board/showthread.php?s=&threadid=33603888

http://63.231.44.178/board/showthread.php?s=&threadid=33619641

ps: besure and check the dates so you can see how long I have been doing videocapture using mpeg4 and the quality is great using my settings :cool:

[brett]

I remember a year ago when you got into a big fight on this forum about how good your DivX captures looked, and we all laughed at you because you were trying to impress us with a low-quality clip of a TechTV capture (and the audio was also a full second out of sync in the second half of the clip).

So yeah, I know how long you've been at this :)

Regarding Luke's Video, you're off topic because AJ obviously already knows how to capture video, as he said he's already got several MPEG captures on his hard drive. He wants to do realtime DivX encoding, and that has nothing to do with Luke's Video. Luke's site explains how to capture and how to use filtering after you've captured to MJPEG or Huffy.

You could've just pointed him to the Rage3D thread that you just linked to, because that was a tread you started about capturing to DivX! That's exactly what he wanted! But no, you obviously didn't read his post, so it didn't even occur to you. You just happened to post a link about it when you were trying to brag :)

You crack me up... you actually wrote a little guide on capturing straight to DivX, but you're so oblivious that when a guy asked for suggestions on capturing straight to DivX, you pointed him to a cartoon filtering guide instead :) :) :)

[brett]

I can't help but wonder what your problem is. Do you read the first sentence of a thread then reply immediately? Why do you post replies to things that you lack any comprehension of?

Your signature is longer than most of your posts, so I guess you just post on to brag. That doesn't make sense, either, though, because the specs on that system aren't going to impress anybody anymore. Even if you did have an amazing computer, why would anybody want to know what sound card you have or what version of DirectX you have installed?

Anyway, I was just saying you were off topic. That's a fact, so it's not like there's anything to debate. If I wanted a debate, I could have a more relevant one with a brick wall.

[NeVeRLiFt]

@brett

Kiss my ass and I still have the techTV clip that has Kyle from www.hardocp.com in it and the quality is very good and the audio is not outa sync.

[Mac Sidewinder]

Do you guys realize that you have posted 14 times back and forth and the person you were trying to help hasn't responded since you started? Lets cool the flames and try to help others.

Mac

[theReal]

Only one more that doesn't help the original poster, sorry...

I have to speak for NeVeRLiFt here, because I have a very similar signature on the amdmb.com forums. If you discuss hardware with people, such a signature is very good because you don't want to write your system specs again in every second post. Has nothing to do with impressing people, it's just info that is helpful for understanding with what kind of system the other is working.

[NeVeRLiFt]

@theReal

You hit the nail on the head.

[NeVeRLiFt]

@Mac Sidewinder


If you read my posts and follow the links I provided you will see I have tried to help the person who started this thread.

:D

[Acaila]

The last half of this thread is not even adressing its purpose, but only about bickering back and forth.

Thread now closed.