r00t61
27th October 2008, 06:07
I've been using MeGUI for about two years now, and for the most part, it's been pretty great. I have, however, run into an issue that is quite vexing.
Every so often, the video encode screws up several frames. They end up looking like a slimy mess (I like to think of it as strawberry jam being thrown on the film). These errors tend to last 3-5 seconds of video time.
My latest example:
http://i426.photobucket.com/albums/pp342/r00t61/Glitch.jpg
For comparison, here is the original, unmolested frame from the avisynth preview:
http://i426.photobucket.com/albums/pp342/r00t61/Clean.jpg
So I don't think it's an issue with the clip source, nor with avisynth.
I can make errors like this "go away," by tweaking the bit rate, number of b-frames, number of reference frames, the motion estimation algorithm, and/or subpixel refinement, but it's all really somewhat non-deterministic and frustrating. Encode settings that work perfectly fine for video "x" can cause my strawberry jam mess on video "y." The only way for me to verify that an encode has worked properly is to watch the whole clip like a hawk to confirm the absence of strawberry jam. This can get annoying, really fast.
Any help in resolving would be much appreciated.
For reference, here's my avs script:
DGDecode_mpeg2source("C:\Documents and Settings\Eugene S. Park\Desktop\Robin Hood WORKING DIRECTORY\Robin Hood (Forced Film).d2v",info=3)
# COLOUR CORRECTION
ColorMatrix(d2v="Robin Hood (Forced Film).d2v")
# CROP/RESIZE
crop( 8, 0, -8, -2)
LanczosResize(704,416)
And my mencoder settings when I originally encoded this clip:
program --pass 2 --bitrate 1925 --stats ".stats" --level 4.1 --ref 16 --mixed-refs --no-fast-pskip --bframes 5 --b-adapt 2 --b-pyramid --weightb --direct auto --filter -2:-2 --subme 9 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --merange 32 --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input"
Every so often, the video encode screws up several frames. They end up looking like a slimy mess (I like to think of it as strawberry jam being thrown on the film). These errors tend to last 3-5 seconds of video time.
My latest example:
http://i426.photobucket.com/albums/pp342/r00t61/Glitch.jpg
For comparison, here is the original, unmolested frame from the avisynth preview:
http://i426.photobucket.com/albums/pp342/r00t61/Clean.jpg
So I don't think it's an issue with the clip source, nor with avisynth.
I can make errors like this "go away," by tweaking the bit rate, number of b-frames, number of reference frames, the motion estimation algorithm, and/or subpixel refinement, but it's all really somewhat non-deterministic and frustrating. Encode settings that work perfectly fine for video "x" can cause my strawberry jam mess on video "y." The only way for me to verify that an encode has worked properly is to watch the whole clip like a hawk to confirm the absence of strawberry jam. This can get annoying, really fast.
Any help in resolving would be much appreciated.
For reference, here's my avs script:
DGDecode_mpeg2source("C:\Documents and Settings\Eugene S. Park\Desktop\Robin Hood WORKING DIRECTORY\Robin Hood (Forced Film).d2v",info=3)
# COLOUR CORRECTION
ColorMatrix(d2v="Robin Hood (Forced Film).d2v")
# CROP/RESIZE
crop( 8, 0, -8, -2)
LanczosResize(704,416)
And my mencoder settings when I originally encoded this clip:
program --pass 2 --bitrate 1925 --stats ".stats" --level 4.1 --ref 16 --mixed-refs --no-fast-pskip --bframes 5 --b-adapt 2 --b-pyramid --weightb --direct auto --filter -2:-2 --subme 9 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --merange 32 --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input"