Log in

View Full Version : non-mod16 Red&Blue video bugs on a mod16 resolution ?


xyloy
30th April 2006, 16:21
source: DOSBox's (v0.65) .AVI capture movie (codec: Zipped Motion Block Video VFW v0.1) 640*480(640 is divisible by 16, 480 is divisible by 16 and 24, so AFAIK it's ok for x264's Width&Height limitations), 70 FPS.

AviSynth(v2.5.5) Script:
avisource("F:\tex197_000.avi")
ConvertToYV12()

x264 (http://x264.nl/)(rev516) cmd line:
E:\Program Files\x264\x264.exe --crf 22 --keyint 700 --min-keyint 70 --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --analyse all --8x8dct --me umh --cqm "jvt" --progress --no-psnr --output "F:\Tex.mp4"

Here are 5 screenshots(.PNG format) where you can spot the bugs easily
http://img225.imageshack.us/img225/1747/snapshot200604301658427hk.png (http://imageshack.us)
http://img133.imageshack.us/img133/692/snapshot200604301659022nl.png (http://imageshack.us)
http://img135.imageshack.us/img135/4078/snapshot200604301659368bn.png (http://imageshack.us)
http://img222.imageshack.us/img222/5198/snapshot200604301659559ka.png (http://imageshack.us)
http://img222.imageshack.us/img222/3629/snapshot200604301700203cx.png (http://imageshack.us)

Before, I had the very same bugs with a nonmod16 source capture of 320*200(and that time, MeGUI warned me), so I used XviD v1.2 instead. I used also XviD v1.2 with this capture and I had no bugs(so I guess my problem isn't related to ConvertToYV12).

By the way, I'm curious about this story...
Is XviD's unlimitation in Width&Height conform to the MPEG-4 ASP specs ?
And is it H.264/AVC's specs that prevents x264 to have no limitations ?

Any help would be very much appreciated.
I can also upload the source .AVI file, and/or the resulting .MKV file if asked. ;)

akupenguin
30th April 2006, 19:59
By the way, I'm curious about this story...
Is XviD's unlimitation in Width&Height conform to the MPEG-4 ASP specs ?
And is it H.264/AVC's specs that prevents x264 to have no limitations ?
x264 uses exactly the same method as xvid to allow mod2 resolution. And it is compliant in both ASP and H.264 specs.

Any help would be very much appreciated.
I can also upload the source .AVI file, and/or the resulting .MKV file if asked. ;)
Both, please.

xyloy
30th April 2006, 23:02
x264 uses exactly the same method as xvid to allow mod2 resolution. And it is compliant in both ASP and H.264 specs.
okay, so just the VFW part accepts only 16 or 24 divisible resolutions for input. MeGUI's warning about compressibility of nonmod16 resolutions and possible bugs fouled me. ^^

Both, please.
Oops! I trashed the source .avi file, but here is another capture with the same problem, altough not as much present(the problem occurs randomly - some rare times not at all - and only with DOSBox video captures converted with x264):
(same script, same rev/ver/build, same cmd line)

download input source (.avi - ZMBV + PCM) and output result (.mkv - AVC1 + AAC) in one .zip file here (http://rapidshare.de/files/19305976/Tex197_000.zip.html).

screenshots of the final .mkv file(this time, red & blue colors appear mostly and slightly in the control panel part of the image):
http://membres.lycos.fr/xcomcmdr/Screenshot(Red&Blue)1.png
http://membres.lycos.fr/xcomcmdr/Screenshot(Red&Blue)2.png
http://membres.lycos.fr/xcomcmdr/Screenshot(Red&Blue)3.png
a final screenshot with no problem:
http://membres.lycos.fr/xcomcmdr/Screenshot(withoutRed&Blue).png
Thanks ;)

akupenguin
1st May 2006, 00:19
I see the discoloration in your screenshots. But I do not see it in your mkv.

xyloy
1st May 2006, 00:32
Could the decoder be the cause ?

I tested with VLC media player's internal H.264 decoder, and the decoloration has vanished(playback is still quite fuzzy though, but it's bearable)! Thanks! ;)

The screenshots were taken with MPC(VMR9 renderless, I tried other renderers, didn't help) and Nero Digital MPEG-1/2/4 & AVC Decoder v3.2(with dynamic auto Post-Processing) wich is my usual way to play movie files.

Also with MPC the CPU charge is unusually high(hard to search in the video, choppy playback) could be because of the FPS, but I don't buy it... 640*480 should play fine. I don't think PP is jerking because of the FPS neither, it's not very used on this video, and disabling it doesn't lower the CPU charge...
Is the bistream correct ?

akupenguin
1st May 2006, 00:54
With mplayer/lavc, it looks perfect (no discoloration, no fuzz. there is some aliasing, but that was in the source too), and takes 33% cpu on my athlon-xp 2500.
Bitstream decodes correctly in the reference codec too.

xyloy
1st May 2006, 00:58
ok, I guess the heavy CPU charge is caused by the FPS.
Strange still that Nero's decoder has color problem with x264's output only when the source was a DOSBox's ZMBV video capture.

xyloy
1st May 2006, 11:49
everything is fine(only 51% cpu usage and no prob') with CoreAVC! :D