What type of noise can ruin even high bitrate video?

[kai0n7]

I'm having some problems encoding an analog capture I did of an anime LD, which had alot of chroma noise and grain. I eliminated most of the noise with VirtualDub's "NeatVideo" filter, and the huffy avi I created looked outstanding for the most part.

However, I still get alot of jumpy macroblocking in a few scenes which have gradients even at the highest bitrates. I've tried to reintroduce some grain into the picture in order to break them up, but to no avail. I have done test encodes with both CCE and HCenc, and neither produces very good results.

Any suggestions on what I can do here? I will provide samples if needed.

Thanks,

Kai

[Trixter]

Some samples would be good, as well as a description of what encoder you're using and what bitrate settings you've chosen.

To answer your original question, there are some types of footage that most encoders completely choke on, but sometimes it has nothing to do with noise:

http://img168.imageshack.us/img168/3708/sota25icz7.th.png (http://img168.imageshack.us/my.php?image=sota25icz7.png)

In the above example, imagine the concentric circle parts moving constantly (ie. a new image every field) and you can easily see how the MPEG-2 encoder gets completely confused by the motion and nothing has a decent motion vector. Further adding to the problem is that the majority of the changes in this sample footage are in chroma-land, not luma, and MPEG-2 allocates less bits to chroma that luma.

This example footage (in motion of course) has encoding artifacts even at the DVD maximum of 9800kbps. Thankfully, most footage is nowhere near this confusing...

[kai0n7]

Some samples would be good, as well as a description of what encoder you're using and what bitrate settings you've chosen.

To answer your original question, there are some types of footage that most encoders completely choke on, but sometimes it has nothing to do with noise:

http://img168.imageshack.us/img168/3708/sota25icz7.th.png (http://img168.imageshack.us/my.php?image=sota25icz7.png)

In the above example, imagine the concentric circle parts moving constantly (ie. a new image every field) and you can easily see how the MPEG-2 encoder gets completely confused by the motion and nothing has a decent motion vector. Further adding to the problem is that the majority of the changes in this sample footage are in chroma-land, not luma, and MPEG-2 allocates less bits to chroma that luma.

This example footage (in motion of course) has encoding artifacts even at the DVD maximum of 9800kbps. Thankfully, most footage is nowhere near this confusing...

Would you like samples of just the original and the fitered avi's that I'm feeding to the encoders?

Kai

[Mug Funky]

often i find blocking and banding to only be visible when the video is converted to RGB (usually by the display device, or windows).

usually a gradient doesn't need a high bitrate, though sometimes it can pay to increase DC precision (i just leave it on 10 bit, but that's probably not wise).

also, if possible, watch the encode on a TV (either burned to a DVD-RW and viewed on a standalone player, or simply played through TV-out using hardware overlay).

[kai0n7]

often i find blocking and banding to only be visible when the video is converted to RGB (usually by the display device, or windows).

usually a gradient doesn't need a high bitrate, though sometimes it can pay to increase DC precision (i just leave it on 10 bit, but that's probably not wise).

also, if possible, watch the encode on a TV (either burned to a DVD-RW and viewed on a standalone player, or simply played through TV-out using hardware overlay).

I figured out that its the conversion to YV12 at the end that's wrecking it, and since there's no way around having to do that, it looks like this just isn't going to work.

Sorry for bothering you.

Kai

[Mug Funky]

well, if your source is RGB, you can use CCE or TMPGenc and set DC prec to 10 bit. that'll kill the banding on the input side pretty comprehensively.

if you're still seeing banding after that, then it's probably the hardware conversion back to RGB on playback that's letting you down. in this case, just remember that it wont happen on a TV (unless it's one of those crappy plasmas that cost far more than they're worth - some of them look like gif animations, colour wise)

[kai0n7]

well, if your source is RGB, you can use CCE or TMPGenc and set DC prec to 10 bit. that'll kill the banding on the input side pretty comprehensively.

if you're still seeing banding after that, then it's probably the hardware conversion back to RGB on playback that's letting you down. in this case, just remember that it wont happen on a TV (unless it's one of those crappy plasmas that cost far more than they're worth - some of them look like gif animations, colour wise)

Well, this is the sequence I'm currently using... perhaps you can spot something I'm doing wrong and offer some advice. The video was 4:3 letterboxed, so I am converting it to 16:9 anamorphic. There are some combing artifacts blended into some of the progressive frames in the source video, and blending is the only method I've found that takes care of them all and doesn't maul the video too badly. It does blur it slightly, so I use LimitedSharpen to bring most of that lost detail back.


Input source is YUY2(), its the only color space my capture card supports.

Captured video to Huffyuv avi (RGB, I think).

Avisynth script opened in VirtualDub:
AssumeTFF()
DoubleWeave().TPRIVTC("F:\silent_mobius.tpr") *IVTCing
Trim(573,77606)
Crop(0,54,0,-54)
ConvertToYV12()
LGhost(4,3,50)

Applied NeatVideo filter in Virtualdub, saved work file to Lagarith YV12 avi.

Avisynth script fed to HCenc:
mt_convolution("1","1 2 1",chroma="process") *Cleanup of combing artifacts blended into frames.
LanczosResize(696,480)
LimitedSharpen(ss_x=2.0,ss_y=2.0,Smode=2,strength=200)
Addgrain(2,0.1,0.1)
AddBorders(12,0,12,0)


Originally, I was saving my work file to another Huffyuv RGB file, and adding converttoyv12() into the 2nd script... which really made the gradients look bad. Since I switched to Lagarith, it has been greatly reduced, but not completely eliminated. I'm assuming this is because I'm doing all the filtering in YV12, and not doing any additional color space conversions.

Kai

[kai0n7]

Test 1- Cropped and IVTC'd
http://www.megaupload.com/?d=5B1Q7OO3

Test 1f- Cropped, IVTC'd, and Filtered
http://www.megaupload.com/?d=N0SRF7JQ

Codec is Lagarith. Output is to be a 16:9 anamorphic DVD. Unless I'm just completely wrong, the final video should be 696x480, bordered on the sides to make it 720x480.

The problem area is obviously the gradient between the city and the sky.

Kai

[Audionut]

1 thing I can suggest.

Remove lanczosresize(696,480)

And adjust the limitedsharpen line to this,

LimitedSharpen(dest_x=696,dest_y=480,ss_x=2.0,ss_y=2.0,Smode=2,strength=200)

[kai0n7]

1 thing I can suggest.

Remove lanczosresize(696,480)

And adjust the limitedsharpen line to this,

LimitedSharpen(dest_x=696,dest_y=480,ss_x=2.0,ss_y=2.0,Smode=2,strength=200)

What is the benefit of this?

Kai

[Audionut]

Limitedsharpen performs resizing while doing it's thing.

Rather than resize with lanczos aswell, you might aswell just let limitedsharpen do all the resizing.

[Chainmax]

Some time ago, I made a DVD for my eldest brother from some digicam clips. The intro was composed of a few short clips from different parts of the video and then ran through MSU Cartoonizer in drawing mode. Even though it was encoded at 8000kbps, it had flickering blocks everywhere with the AVAMAT7 matrix. I then encoded it with the Ultra Low Bitrate matrix and it turned out almost perfectly. My suggestion is then to encode those difficult parts separately with the Ultra Low Bitrate matrix and then merge all the parts back.

As for the resizing, if the source was fullscreen (4:3), then FitCD says that for a 720x480 encode you have to use Resize(704,480)+AddBorders(0,8,0,8) or Resize(656,448)+AddBorders(32,16,32,16) for 2-block overscan.