CBR/VBR bitrates

[Brian Ellis]

I've been doing some research on ideal bitrates for DV

To do this, I imported 4 good quality DV clips from a 3-CCD largish
semi-pro camera and put extracts into a 17 second DV file with 4 shots:
1) ststic camera and moving traffic in foreground
2) panning camera with moving traffic in both directions in foreground
3) panning camera following a fast flying Yellow-billed Stork
4) more or less static scene with stork in water in foreground

I have the original file and copied it to a deinterlaced version. I have
derived uncompressed bmp files of a specific critical frame in each of
the 4 shots. I've viewed the 4 bmps from the deint avi. Obviously rapid
motion is blurred at 100%, but the pix look good on the screen and at
300% some artefacts are visible, especially on shot 3, where the panning
was fast.

I then made 2 mpg files of the deint file. The first was at 7.5 min, 8.0
av, 8.5 max VBR (15.2 Mb) and the second was at 6.0 CBR (13.3 Mb), both
DVD compliant. Critical viewing at 300% showed a small increase of
artefacting, with respect to the AVI file in both cases, on all 4
stills. As I write this, I have three images of the stork from shot 3 at
300% (the most highly artefacted), tiled on the screen. I can see
practically no difference between the 6000 CBR and the 8000 VBR (there
is one small square with the bird's yellow bill on a dark olive
background running diagonally through it, where the colour bleed MAY be
very marginally higher in the 8.0 VBR than the CBR, compared to the
original which had no colour bleed, but the difference, if any, is
extremely small). Viewed very carefully at 100%, this area of the pix
shows no visible difference between the original and the two mpg images.

Playing back the two mpg clips side by side full screen and at 1:1
(identical 18.1" TFT monitors at 1280 x 1024) from 2 computers shows
identical quality with absolutely nothing to choose between them.

This confirms what I have said in the past from a less scientific study:
with an input of DV quality, there is absolutely nothing to be gained by
encoding for DVDs at 8.0 Mbit/s VBR over 6.0 Mbit/s CBR even for shots
where there are rapid movements. Note that I am not saying that there is
nothing to be gained for inputs of higher quality than DV, for example
RGB capturing from studio standard cameras: that is a different kettle
of fish. I am saying this only for DV (or poorer) quality signals.

In due course, I'll publish the results on the 'Net, with the images. In
the meanwhile, I'm continuing my research. If anyone has anything
related they would like me to do, please let me know and I'll see what I
can do (no promises).

[cDynamics]

Interesting...

Thanks for posting your findings. I have a few questions (no particular order):

1) what encoder are you using?
2) do all encoders use the same encoding algorithm (i.e. it's not possible encoder-x can do a better job than encoder-y)?
3) 15.2mb -- was the 8mbps avg maintained?
4) would it be possible a multi-pass VBR can produce better results than a one-pass VBR?
5) was any temporal and/or spatial filtering applied?
6) is 17-seconds enough time for the encoder to "get going"?
7) would it be possible to see different results using a larger screen for playback? (i.e. I bet if I use a 5-inch monitor, I might "see" the same quality between two different encodes, but play them back on a 60" screen, and I might start to notice more differences)
8) using a bitrate viewer, can you determine if the scene you are looking at actually utilized more bits than the CBR encode? Perhaps another way to do it is to select a scene that used the 8.5 bitrate to compare to the same scene on the 6.0 encode (instead of looking at the most highly artefacted)

Regards,
George

[junkmalle]

I would be wary of drawing generalized conclusions from 17 seconds of video.

You didn't say which encoder you were using but it sounds like maybe Ulead Media Studio Pro. I tried a similar experiment, 1 minute of progressive, 30 fps, DV video to MSP's 6000 kbps constant bitrate vs 8000 kbps variable bitrate MPEG 2. I used VirtualDub to view still frames from the two MPEG files. Macro blocks in the 6000 kbps file were visibly worse than the 8000 kbps file. (The blocks were not in the original DV footage.) They were hard to see when watching the video, but if you were looking for them and looked carfully you could see them.

This was video of one of my husky dogs with a mixture of black and white fur (individual strands of black and white). Lots of small detail, lots of motion.

[Brian Ellis]

I can assure you that I chose the 17 seconds very carefully to illustrate the worst that could happen, the same as I chose the 4 key frames likewise.

The encoder was the MainConcept version, as used in MSP7, which is very different from that used in MSP6.5 and a completely different make (Ligos) to that used in MSP6.n (where n < 5) and earlier. I hope to extend to the trials to the latest MC 2 pass encoder, in due course. I cannot try TMPGEnc, as the version I have of this is quite old (I dropped using it >18 months ago because the MSP7 one appeared at least as good, if not better and it avoided a lot of hassle).

There is, perhaps, one qualification point that I omitted. All my trials are in PAL DV, which is different from NTSC (the colourspace is 4.2.0, compared with 4.1.1). It is conceivable that the finer horizontal colour resolution in PAL may make a difference. There should be no difference vertically, as PAL, as the name implies, has its colour coding embedded in alternate lines.

Very early days yet for publishing, but you can see a foretaste at http://www.bnellis.com/mpgcomp/

[Brian Ellis]

I've now added 4000 CBR and VBR to the above site and added more info.

[junkmalle]

Brian, try a moderately detailed scene with a quick fade-to-black. You'll see clear differences between 6000 CBR and 8000 VBR. MPEG has no special handling of intensity change so it has to encode the change for every pixel.

[Brian Ellis]

JM

I might try that later if I find the time. It's a good point. However, my aim was to find how ordinary video behaved, not the rather artificial case you suggest. Incidentally, the pan in scenes 2 and 3 of my test do require much pixel change. I admit not every pixel. I'll bear this in mind. Thanks.

[junkmalle]

Originally posted by Brian Ellis
JM

I might try that later if I find the time. It's a good point. However, my aim was to find how ordinary video behaved, not the rather artificial case you suggest. Incidentally, the pan in scenes 2 and 3 of my test do require much pixel change. I admit not every pixel. I'll bear this in mind. Thanks.

I wouldn't bring this up if you had said "there is little difference between 6000 kbps CBR and 8000 kpbs VBR for most DV footage" but you said "with an input of DV quality, there is absolutely nothing to be gained by encoding for DVDs at 8.0 Mbit/s VBR over 6.0 Mbit/s CBR" (emphasis mine). I used the fade-to-black example because it was an obvious case, albeit "somewhat artificial". (I see this problem all the time when I watch digital cable stations. Even the analog stations are often digital transmissions converted to analog.) How about a scene shot under flickering candle light (maybe impossible with most DV cameras)? Fast strobe lighting at a disco? Rotation of the camera around the view axis (accidental or intentional)? High motion 3D transitions that can't be compressed via MPEG motion vectors?

I looked at the samples you posted in your ealier link. It's a bit hard to tell for sure because you enlarged a single frame with a bilinear or biclubic filter, but it looks like you were following the bird in flight resulting in a lot of motion blur of the background. Most people think blurry stuff is hard to compress -- but that is a misconception caused by the fact that much blurry video is a result of high motion, especially camera motion. Try this experiment. Take a nice clear still picture, save it as a JPG at a quality setting of 75 (something akin to a video I frame). Now run the picture through a gaussian blur with an aperture of 5 to make it really blurry. Save it again as a JPG with the same quality setting. The second file will be much smaller, probably less than half the size!

Again, if you were following the bird in flight there may have been little change in the background aside form it panning across the frame. Clear or motion blurred, this could be compressed very well by motion vectors in MPEG.

You apparently started with interlaced video and deinterlaced it. I'm not sure if you are aware of this, but MSP's deinterace option (via Media Source Options, Deinterlace) simply throws out one field and replaces it with pixels interpolated from the line above and below. Once again, this produces a blurry (on a small scale) picture that can be compressed more easily. Leaving the footage interlaced, or starting with progressive footage would be better choices. Or maybe you could deinterlace after MPEG compression for display purposes.

Your sample images are enlarged with a bilinear or bicubic filter and then saved as JPEG files. This makes it hard to tell exactly what the original looked like. I think it would be more instructive to see them enlarged with a "nearest neighbor" filter so you can see the actual pixels of the source image. It would be nice to be able to view (as an option) uncompressed crops too.

I don't really disagree with your premise that there isn't a lot of difference between 6000 CBR and 8000 VBR for most DV footage. Certainly, the differences will be hard to see while watching on a television. I'm just pointing out exceptions to that rule, possible flaws in your methodology, and objecting to the use of the phrase "absolutely nothing to be gained".

[Brian Ellis]

OK, I've done a quick test with fading in and out. The subject I chose was a zoom-in of a bunch of grapes, with lots of subtle colours on each berry, with its yeast bloom, and the surrounding vine and trellis.

I faded it to black, rapidly, as you suggest, over 1/5 sec, and then faded it back to the same clip again. From that, I created a DV AVI "master" file. From that master file, I created two DVD-compliant MPEG-2 files at 720 x 576 using the best quality settings. The first was at 6000 CBR and was 10.7 Mb and the second was at 8000 VBR and was slightly smaller at 10.5 Mb. Comparative playing the two files side-by-side gave no visible difference. I then viewed each transition frame-by-frame and could see no difference at 1:1. I then captured two transition frames each to uncompressed BMP and examined them side-by-side. At 1,000 times size, I compared each pixel from several of the more critical parts of the images. The pixels were absolutely and rigourously identical in all cases.

I rest my case.

I have the files/images available if you want.

[junkmalle]

Brian,

Clearly your experiments differ from mine. Maybe there's a difference between PAL and NTSC (my experiments were all NTSC) handling in MSP7? Or maybe it's a matter of versions. Help --> About Video Editor says version 7.01.0000, all default installation options, no updates. I don't really use MSP7 much so I haven't bothered to check for updates.

I also tried an experiment where I took two MPEG results, used the invert filter on one (color/intensity inverted), did a cross fade with both the starting and ending "transition degree" setting set to 50 percent, and rendered the result. This gives you the average of one file with the "negative" of the other. If the two files were identical the result would be a flat gray picture.

When I used the same file for both (to verify that the procedure did exactly what I expected) the output was a flat gray picture with no visible detail. when I used a 6000 CBR file and a 8000 VBR file(obviously both created from the same DV source) I could see visible "noise" in the gray picture. In some frames I could even detect the outline of high contrast objects.

[Brian Ellis]

I admit that my version of msp7 is not the same as yours, but I don't really know whether there are any major differences in the mpeg encoding, but there could be. I can't tell you more just now (NDA).

I did try a different technique, using overlays to cancel out to see just the difference but it gave me a deep black picture. Move one of the tracks just one frame and it showed a difference, but in synch, they showed nothing, even between 4000 CBR and 8000 VBR!!! I'll try your idea tomorrow (dinner calls!)

[Brian Ellis]

OK, I've tried your technique, which sounded promising, but it's no better than mine was. The grey was absolutely uniform between 6kcbr and 8kvbr without even a shimmer over all 4 clips. I then tried between 4 kcbr and 8 kvbr, where there are visible differences during playback. Still a uniform grey, although I may have detected a very slight moiré effect over a second but I'm not even sure of that.

I then tried to see how sensitive the test was. On one of tracks I applied the Brightness and Contrast filter to 1 (start and finish), keeping the contrast at 0 and the gamma at 1. Uniform grey. So I upped it to 3, then to 5 then to 10, same result. I just started to see images at 20! Well, even at 5, the difference is very visible to the eye, so I conclude that this exercise is not very gainful, because it lacks sensitivity. Sorry.

Out of curiosity, I tried moving the inverted track to V1, without the crossfade, of course, and added it to the other track with the image inverted. This gave a uniform white screen, bit the very vague moiré effect between 4 kcbr and 8 kvbr is confirmed but it is impossible to correlate it with the image: it is just slight noise, apparently random and even then you have to look hard to see it.

[junkmalle]

Originally posted by Brian Ellis
so I conclude that this exercise is not very gainful, because it lacks sensitivity. Sorry.

Increasing the intensity of one of the sources would only change the shade of gray of the entire output image, except for those portions of the picuture that were near full intensity to start with. Being and average it's a little less sensitive than a straight subtraction of the original two images -- it require a 2 unit change in order to see a 1 unit difference. Changing contrast does show up as visible "noise" in the result but, again, it takes at least a two unit difference in one source for the output noise to be visible.

On the other hand, subtracting one image from the other may show differences of only one unit, but it also loses "half" the differences. Anywhere where the result is less than zero will become zero in an 8 bit RGB system. If you subtract image B from image A you will only see results where image A is brighter than image B.

I chose the first, (A + ~B) / 2, of these two methods because it leaves a gray result. The gamma curve of my Trinitron monitor makes it easier to see a difference in middle grays than in blacks. That is, I can see a difference between intensity 128 and 129, but I can't see the difference between 0 an 1. The first method also shows differences whether a pixel from image A is brighter or darker than the corresponding pixel from image B. Your method, A - B, only shows differences when a pixel from image B is darker than the corresponding pixel in image A.

In any case, both methods will show if any differences exist between two MPEG files. On my system I'm seeing differences between CBR 6000 and VBR 8000 MPEGs generated from my DV sources. You, apparently, are not seeing differences with your system/source. The problem is, you are trying to prove the non-existence of differences between CBR 6000 and VBR 8000. This can't be done with a fixed number of cases. You can't go to Africa, look in 3 places one expects to find elephants, not see any, then claim there are absolutely (your word) no elephants in Africa.

[smitty]

Just out of curiousity , as I don't see 6000 vbr ,and I have been using this setting ,why not?
smitty

[Patrick]

On the other hand...

I looked in three different places in my basement, and I can confidently say there are absolutely no elephants in my basement.