The MPEG2 encodes of my VHS-C captures need more than 10000 of max bitrate ! ! ! ! !

[crespo80]

I capture VHS-C tapes with my lifeview prime30 (Philips SAA7130) at the resolution of 704x576 (cropped from 720x576) with fly2000tv 2.36 software and HuffyUV codec (YUY2).
I want to preserve the maximum possible quality so I mantain the interlaced video and compress to MPEG2 with the same capture size and no filtering (the source is quite good). I add 16 pix of black borders to left/right/bottom side to hide some tape noise and increase encoder compression. I tried CCE 2.67.00.27, Procoder 2.0 and TMPGenc Plus 2.521.
CCE and procoder alter brightness and/or saturation of the video, so my choice is TMPGenc which preserves the source intact.

For all the encoders i set a Costant Quality factor (30 for CCE, 80 for TMPGenc and 97 for procoder), leave all the filters off and set the min/max bitrate to 1000/9656 (audio is Mp2 mono 48KHz 192Kbps).
All the other settings are common (Top Field First, 15frames GOP, no preprocessing, default matrix, ecc.)

With these settings, all encoders output same sized videos.

The problem is:
In quite static scenes the medium bitrate is around 5000, with peaks of 6000/7000 and it is mantained a constant quantization of 5 (analyzed with bitrate viewer).
In high motion scenes (generally due to the the camera that moves too fast) the medium bitrate grows up to 8000/8200 with peaks of 9800/10000!!! The medium quantization also gros up to 7 and, in those peaks, can reach 10/12 and the video gets blocky.
With CCE and Procoder the video never becomes blocky in those scenes, but i prefer TMPGenc because it mantains the correct luminance/saturation level (I posted this in CCE section).

If I set the maximum bitrate to 15000, then the quantization of 5/6 is mantained, but the medium bitrate is around 9000 and the peaks are of 12000/13000 and it's not DVD compliant.
This means that the encoder, to mantain the CQ setting, need very high bitrate.

Is it normal such a high bitrate to achieve best quality video?
To analyze the video I open it in VirtualDubMOD and BitrateViewer.

[Kika]

CCE and procoder alter brightness and/or saturation of the video, so my choice is TMPGenc which preserves the source intact.

Sound's like you have trouble with the Lumarange. If that's the case, that's the reason why TMPGEnc-Encodings become more blocky in High-Motion Scenes - the Encoder has a lot of more Details to encode.

If you are using CQ-Mode, i suggest you to set B-Picture Spoilage to 0.

In quite static scenes the medium bitrate is around 5000, with peaks of 6000/7000 and it is mantained a constant quantization of 5 (analyzed with bitrate viewer).

Wow, that's much too much... Guess your Video is noisy and a bit shacking (also shaking Lines, that's an VCR-Effect).
Without a TBC or a Noise-Filter, there's nothing you can do.
Do a research on the Capture-Guide here in the Board, you will find some usefull hints.

[crespo80]

get a look to this thread, and tell me is my source is noisy or not (the images are just copied from VirtualDubMode and jpg compressed with a factor of 15).
http://forum.doom9.org/showthread.php?s=&threadid=82834

I tried playing with luminance level in CCE but with no results. It's a problem of CCE itself.
With Procoder i didn't find a setting to correct that, and the result is worse even than CCE, because it alters also the saturation and smooth the video.

I also tried some filters with avisynth 2 (PixieDust and GoldDust) and some of avisynth 2.5 (PeachSmooth, Convolution3D, TemporalSoften) but the size of the video decreases only a little and the video is too much soften).

Note, however, that the blockiness is only noticeable in VirtualDubMOD with 2x zoom in still image and in very few frames of those points, but is annoyng because the required bitrate is so high.

The blocky frames are the B frames, of course.
But I think B-picture Spoilage set to 0 cannot solve the problem, because the problem is the lack of bitrate...

Or not? What is the error?

[crespo80]

i just tried mainconcept mpegencoder 1.4.2 (last version) but the constant quantization setting is ridicolus.
Just for curiosity, it also alters the brightness, just as CCE (but less than procoder).
It mantais the constant quantization with no care for the maximum bitrate (that meand that BitrateViewer shows a flat curve for Q facor). So I had a video with an average bitrate of 8450 and peaks of 15000 !!!

I ask you to try my settings to see if it's common.


But, thinking a moment, isn't the DV standard derived from MPEG2? Even if it doesn't uses B frames, its bitrate is det to 25000 to mantain maximum quality.
So I think 8000 of average bitrate isn't too high if I want the maximum possible quality.

Or not?



HELP ME!!!!!!!!!!!!!!!!!!!!!!!

[rfmmars]

If VHS-C is your source,you can use a fairly low bit rate 4500 - 6000. Your only dealing with 230 lines (Max) of resolution anyway.

I capture 8000 bps VBR I frames only with a ATI 9000 card MEPG2 format, and I never run into any prolems like you are discribing.

However with camcoder footage nothing is standard, and problems vary within brands and between brands, and formats.....VHS,VHS-C, 8MM, and DV.

Some help may be found at www.100fps.com

richard
www.photorecall.net

[crespo80]

At which resolution do you capture and encode?
Do you leave interlaced frames or deinterlace?
What program do you use to encode and which settings?
Please make this test:
open you encoded file in VirtualDubMOD and go to a fast motion scene.
Then go to a B frame and see if there is any blockyness (at that so low bitrate you should see a loto of blocky images).
Copy the source frame to clipboard and paste it to Paint Shop Pro.
Save to Tiff format and post the image on the forum so i can compare with my encodes.





P.S.
I'm making a test with a VHS-C capture, encoding with these encoders:
TMPGenc Plus 2.521.58.169
CCE-SP 2.67.00.27
MainConcept 1.04.02.00
Procoder 2.01.30.0

I use a 2-pass VBR encode (0/6000/9656) and the results are similar. All the encoders produce blockness at this low medium bitrate of 6000, i'll post the test results this evening.

When you analyze the encoded video, you only see it in a player or also compare frame-to-frame with VirtualDubMOM?

[rfmmars]

Capture at 720 x 480 29.97fps interlaced.

Since I capture I FRAMES ONLY, there are no B FRAMES. This is most likey why I don't have these problems.

Capture program is ATI's bundled MPEG2 software, many settings.

richard

[fccHandler]

Originally posted by crespo80
CCE and procoder alter brightness and/or saturation of the video

Did you say you use VirtualDubMod to judge the result? If so, you may be seeing the effect of MPEG-2 "matrix coefficients." There was a discussion about it here.

[crespo80]

Originally posted by fccHandler
Did you say you use VirtualDubMod to judge the result? If so, you may be seeing the effect of MPEG-2 "matrix coefficients." There was a discussion about it here.

thanks for the link, but I think that the problems isn't with the "matrix coefficients".
Otherwise, how do you explain that TMPGenc outputs a file identical to the source?

[Wilbert]

thanks for the link, but I think that the problems isn't with the "matrix coefficients".
Otherwise, how do you explain that TMPGenc outputs a file identical to the source?

Maybe you are right here. But, perhaps you can check it.
Get the latest GSspot which gives the matrix coefficients.

btw, you opened your capped mpeg2 directly in the encoder right (so, no avs)?

The point is here the TMPGEnc adds FCC (almost the same as MPEG-1) coefficients to the header, while CCE adds MPEG-2 coefficients.

I think, but you should test it by opening the mpeg2's in the latest GSpot:

1) open your capped mpeg2 in GSpot and post the coefficients.

2) open your TMPGEnc-mpeg2 in GSpot and post the coefficients.

3) open your CCE-mpeg2 in GSpot and post the coefficients.

One of the two is "wrong" (either CCE or TMPGEnc). Which one depends on how the source is created. But we don't know, because it's stuff from tv. But in this case it appears it is made (RGB->YUV) by using MPEG-1 coefficients because TMPGEnc has it right.

Of course you can't see that by looking at the header of your cap, because your capture device doesn't know that.

It is possible to modify ColorMatrix() to do MPEG-1 coefficients -> MPEG-2 coefficients (instead of the other way around), but I don't have time before next week to look at that.

Now, I don't know how (and if) CCE does the RGB->YUY2 conversion if you feed it with RGB. You could check that by making

mpeg2source("***.d2v")
converttorgb32()

and feed it in CCE, and post the same screenshot as in the other thread.

[fccHandler]

According to the samples Wilbert sent me, TMPGEnc was using the value 4, which is so close to the MPEG-1 values that you probably can't see the difference. It's possible that CCE doesn't define "matrix coefficients" at all, in which case VirtualDubMod selects the default for MPEG-2, which is quite different (brighter?) than MPEG-1.

There is a way to test if "matrix coefficients" is causing you grief: Convert the MPEG-2 to AVI format using "fast recompress" mode and Xvid (or DivX) codec. This will avoid the "matrix coefficients" entirely, because there is no conversion to RGB involved.


EDIT: Same time post as Wilbert!

[crespo80]

Originally posted by fccHandler

There is a way to test if "matrix coefficients" is causing you grief: Convert the MPEG-2 to AVI format using "fast recompress" mode and Xvid (or DivX) codec. This will avoid the "matrix coefficients" entirely, because there is no conversion to RGB involved.


EDIT: Same time post as Wilbert!

I just made this test compressing to XviD an MPEG2 video from CCE (fast processing in virtualdubMOD).
The luminance of the result video was diffent from that of the original CCE file and near to the source, but not exactly the same as the source and TMPGenc.
But, in this case, took place two compressions, so it's possible that a part of the information has been lost.
Though I used a very high quality XviD:
I choosed the quality based encode, with a quantization factor of 3 (or 2, I do not remember, I'll do another test) and the result video had an average bitrate of 10000!

[fccHandler]

Originally posted by crespo80
The luminance of the result video was diffent from that of the CCE file and near to the source, but not the same as TMPGenc.

To be 100% sure, do the same recompression in "full processing mode." If the result appears brighter than your previous Xvid, then "matrix coefficients" is surely the source of your problem.

I don't know a fix, because the proper setting of this value is the encoder's responsibility. However, I really think VirtualDubMod may be one of few decoders which actually uses this value. I doubt very much that any DirectShow applications do.

[crespo80]

Originally posted by fccHandler
To be 100% sure, do the same recompression in "full processing mode." If the result appears brighter than your previous Xvid, then "matrix coefficients" is surely the source of your problem.

But, in this case, the "matrix coefficients" are not applyed because there's no MPEG1/2 source....
Or I'm missing something?

[fccHandler]

What I mean is, do the same recompression from your MPEG-2 source to Xvid, but this time use "full processing" mode, and compare that to your previous result (which used "fast recompress" mode).

The matrix coefficients are applied in VirtualDubMod only if the source is MPEG-2 and it is being converted to RGB during processing.

[crespo80]

I made other test, opening in VirtualDubMOD the MPEG2 file encoded by CCE and recompressing in many formats:


COMPRESSION MADE IN FULL PROCESSING MODE

- Conversion to uncompressed RGB24 AVI:
the video is perfectly identical to the MPEG2 created by CCE, so the luminance error is still present.

- Conversion to HuffyUV (same settings of the capture):
the video is perfectly identical to the MPEG2 created by CCE, so the luminance error is still present

- Conversion to XviD with best quality options (target quantization=2, max I frame interval=25, motion search precision=6, VHQ=3):
the video luminance is almost identical to the MPEG2 created by CCE, so the luminance error is still present.


COMPRESSION MADE IN FAST PROCESSING MODE:

- Conversion to uncompressed RGB24 AVI:
the uncompressed video is perfectly identical to the MPEG2 created by CCE, so the luminance error is still present.

- Conversion to HuffyUV (same settings of the capture):
the video luminance is different from the MPEG2 created by CCE, and now its luminance is almost identical to the source video!!!

- Conversion to XviD with best quality options (target quantization=2, max I frame interval=25, motion search precision=6, VHQ=3):
the video luminance is different from the MPEG2 created by CCE, the luminance is almost identical to the source (even if a bit influenced by the XviD compression).




Take your conclusions!
I had the perception that isn't a brightness error, but a gamma error!

So it seems that there's not an error of CCE, but an error of VirtualDubMOD with its preview mode and FULL PROCESSING MODE!

If you read the encoders test I made, you'll see that also procoder and mainconcept show a different luminance level in VirtualDubMOD, so we can adfirm that the problem is VirtualDubMOD!

[Wilbert]

If you read the encoders test I made, you'll see that also procoder and mainconcept show a different luminance level in VirtualDubMOD, so we can adfirm that the problem is VirtualDubMOD!

No, wrong.

Please can you open all mpeg2 streams (source, CCE and TMPGEnc) and post those coefficients, then we can explain you what's going on?

The whole problem is that in VDubMod (or any other player) the mpeg2 is converted (from YUV) to RGB when being displayed. In order to do this, you need to know *how* this should be done (meaning which set of coefficients should be used).

Usually this info is present in the header of the mpeg2 file. This info ia added by the encoder (like CCE and TMPGEnc) when encoding the mpeg2 file. CCE adds mpeg2 coefficients and TMPGEnc adds fcc coefficients (which are appr. equal to the mpeg1 coefficients). Which one is correct depends entirely on the source, ie how the mpeg2 (your source) is created in the first place.

Your capture device has nothing to do with this, because it gets the yuv data from your tv. So, you have to know how the broadcasts are created.

Let's look at the specs of pal/ntsc where this conversion is prescribed. In table 2 of ITU-R_BT.470-6, you will see for example

Y = 0.299 * R + 0.587 * G + 0.114 * B

which are precisely the mpeg-1 coefficients.

conclusion 1) mpeg-1 coefficients should be used when displaying.

conclusion 2 ?) your capture software should add those coefficients to the header of the mpeg-2 stream. Apperently it does that. To check this you should open your capture in (latest) GSpot. Please do that, and post it.

conclusion 3) If conclusion 2 is true, then at least CCE does something wrong. If you open the mpeg-2 file in CCE it should keep the coefficients as given in the header of the mpeg-2 file.

Of course if you used AviSynth, the header is lost, and *no* encoder can know what the correct coefficients are.

conclusion 4) Apperently TMPGEnc also doesn't keep the coefficients, since it replaces them with fcc coefficients. In this particular case, it doesn't matter because they are approximately equal.

But if you feed TMPGEnc a dvd-mpeg2 file, it will be TMPGEnc which adds the wrong coefficients, and CCE adds the correct ones.

I hope it's a bit clear.

But, I really hope you can open all those mpeg2s in GSpot and post those coefficients.

[crespo80]

- I dowloaded Gspot but I can't see any info about the matrix coefficients of the files.
All the informations about the matrix coefficients are greyed (both for the HuffyUV source and CCE MPEG2 encoded file).

- Since my card captures in YUY2 format and the capture software directly compresses in HuffyUV YUY2 format, no color space conversion takes place during capture, so no matrix coefficients are written in the avi header. So, the only coefficients involved are those written by the encoding softwares like CCE or TMPGenc.

- Since we are talking about matrix coefficients and color space conversions, I think that the problem involves the gamma rather than the brightness.
You said maybe the matrix coefficients were lost in avisynth.
But tell me why, if I open the CCE MPEG2 file in VirtualDubMOD and recompress it in FAST RECOMPRESS MODE to HuffyUV or XviD, than the new encoded files look identical to the source in relation to the gamma (not the same could be said about the quality)?
And why, in FULL RECOMPRESS MODE, the gamma of the encoded file is still incorrect?
I think the problem is with VirtualDubMOD, since there shouldn't be any difference between FAST and FULL RECOMPRESS MODE.
Or I'm wrong again?

[Wilbert]

1) This coefficient box in GSpot is only used for mpeg2 files.

2) I thought your cap was mpeg-2. Sorry about that

But tell me why, if I open the CCE MPEG2 file in VirtualDubMOD and recompress it in FAST RECOMPRESS MODE to HuffyUV or XviD, than the new encoded files look identical to the source in relation to the gamma (not the same could be said about the quality)?

That's because the source (ie broadcast) is created using mpeg-1 coefficients. The huffyuv and XviD (also DivX) decoders assume mpeg-1 coefficients when decoding.

And why, in FULL RECOMPRESS MODE, the gamma of the encoded file is still incorrect?

fcchandler can answer this probably. The YUY2 -> RGB conversion is done by VirtualDubMod itself (thus not by huffyuv). Apperently it is doing the conversion by assuming mpeg-2 coefficients. But fcchandler should comment on this.

I think the problem is with VirtualDubMOD, since there shouldn't be any difference between FAST and FULL RECOMPRESS MODE.
Or I'm wrong again?

Summarizing. In the first case the used end codec is decoding the stream (xvid or huffyuv) using mpeg-1 coefficients, and the second case VDubMod itself is doing the color conversion using mpeg-2 coefficients. Which one is correct, depends on how the source is created.

In this case the first one is correct, because the broadcast is created using mpeg-1 coefficients. Just coincedence.

[Kika]

@crespo80
Just open your Video with AVISynth, force it to RGB24 and encode the AVS-File.

avisource("video.avi", true, rgb24)

Try both Lumarange-Settings (0-255, 16-235). One of them MUST give you correct colors.
And don't judge the colors on the PC, use a DVD-Player. Some PCs do have problems with MPEG-Video an Luma/Chroma.