Out-of-alignment strip of video (x264 colour issues)

[koberulz]

I have an AVI. It looks fine. I framserved it from Premiere to MeGUI via Advanced Frameserver, then created a .264 file. It has the occasional (but not rare) frame that looks like this:



The AVI:

General
Format                           : AVI
Format/Info                      : Audio Video Interleave
Format profile                   : OpenDML
File size                        : 90.3 GiB
Duration                         : 2h 1mn
Overall bit rate                 : 106 Mbps

Video
ID                               : 0
Format                           : JPEG
Codec ID                         : MJPG
Duration                         : 2h 1mn
Bit rate                         : 104 Mbps
Width                            : 1 920 pixels
Height                           : 1 080 pixels
Display aspect ratio             : 16:9
Frame rate                       : 25.000 fps
Color space                      : YUV
Chroma subsampling               : 4:2:2
Bit depth                        : 8 bits
Scan type                        : Interlaced
Scan order                       : Top Field First
Compression mode                 : Lossy
Bits/(Pixel*Frame)               : 2.003
Stream size                      : 88.3 GiB (98%)

Audio
ID                               : 1
Format                           : PCM
Format settings, Endianness      : Little
Format settings, Sign            : Signed
Codec ID                         : 00001000-0000-0100-8000-00AA00389B71
Codec ID/Hint                    : Microsoft
Duration                         : 2h 1mn
Bit rate mode                    : Constant
Bit rate                         : 2 304 Kbps
Channel(s)                       : 2 channels
Sampling rate                    : 48.0 KHz
Bit depth                        : 24 bits
Stream size                      : 1.96 GiB (2%)
Interleave, duration             : 1000 ms (25.00 video frames)

The .264:

General
Format                           : AVC
Format/Info                      : Advanced Video Codec
File size                        : 21.2 GiB

Video
Format                           : AVC
Format/Info                      : Advanced Video Codec
Format profile                   : High@L4.1
Format settings, CABAC           : Yes
Format settings, ReFrames        : 3 frames
Bit rate mode                    : Variable
Bit rate                         : 27.4 Mbps
Maximum bit rate                 : 40.0 Mbps
Width                            : 1 920 pixels
Height                           : 1 080 pixels
Display aspect ratio             : 16:9
Frame rate                       : 25.000 fps
Color space                      : YUV
Chroma subsampling               : 4:2:0
Bit depth                        : 8 bits
Scan type                        : MBAFF
Bits/(Pixel*Frame)               : 0.529
Writing library                  : x264 core 148 r2638 7599210
Encoding settings                : cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / slices=4 / nr=0 / decimate=1 / interlaced=tff / bluray_compat=1 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=1 / weightp=0 / keyint=25 / keyint_min=1 / scenecut=0 / intra_refresh=0 / rc_lookahead=25 / rc=2pass / mbtree=1 / bitrate=27413 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=40000 / vbv_bufsize=30000 / nal_hrd=vbr / filler=0 / ip_ratio=1.40 / aq=1:1.00
Color primaries                  : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics         : BT.709-5, BT.1361
Matrix coefficients              : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

[johns0]

Not sure what you mean,is it the checkerboard pattern in the sky?

[KarMa]

There is a 100-200 pixel strip of the image out of aliment near the bottom. Look at the guy in the lower left.

Seems to be a decoder problem somewhere. Either the image being fed to x264 was damaged like this, or the video player decoding the encoded x264 video is being overwhelmed with this 27.4 Mbps bitrate and can't decode it in real time.

[koberulz]

I authored a Blu-Ray disc with the .264 file, noticed the problem playing that back. Found the same frame in the Premiere project in which I edited the AVI, and it was fine. Imported the .264 file into that project, dropped it into the timeline, and it showed the wrong frame, which doesn't make sense. Went forward a frame, and that's what it looked like.

The next frame looks almost identical, except for another patch that's gone out of alignment, starting at the top of the screen and going about halfway down the orange/blue logo on the top right. The frame after that, the two out-of-alignment strips stay the same and the rest of the picture aligns with them.

Everything's flagged as interlaced, but it shows exactly the same thing whether I set Premiere to display the first field, the second field, or both fields, and there doesn't appear to be combing when I play it in VLC. Could that be related?

[jagabo]

Tearing like that normally happens during playback -- when the graphics card switches frame buffers in the middle of displaying the frame rather than during vertical retrace (ie, the top part of the frame comes from one frame of the source, the bottom part from another). It sometimes happens during video capture where the capture device loses sync and you get a frame that's a composite of two source frames. I've never seen it happen, and it makes no sense for it to happen, during video processing like this.

[pandy]

All above valid but it can be sign that decoder can't deal correctly with es syntax - some weird error resilience/concealment used.

[koberulz]

But it's not even a half-frame, just a tiny strip of it. Here's the full three-frame sequence, exported from Premiere, displaying both fields (not, as I said, that that actually makes a difference as to what shows), first from the .264 file and then from the original AVI:

[koberulz]

So I tried just re-encoding it, and now it works fine, except...
Original AVI:


.264:



That effect comes and goes. Seems to only be a problem when there's movement against a blue background; everything else looks fine. Not sure what's going on with the colours, either.

[jagabo]

The chroma has blurred and shifted to the left by about six pixels. You've also used the wrong color matrix, rec.601 vs. rec.709.

[koberulz]

I don't know what the 'color matrix' thing means.

The chroma shift isn't permanent, though. Here's two frames later:


It seems motion-blur related.

[jagabo]

Instead of frame serving, try creating a lossless intermediate file, then encoding that with MeGUI. Check the lossless file and the final encoded video for problems.

[koberulz]

Not sure if I have the hard drive space for that, but I'll give it a shot.

Could you explain the colour matrices thing? There is a setting for it in MeGUI, although none of the options seem like either of the things you mentioned.

[jagabo]

The colormatrix controls how RGB video is converted to YUV, and vice versa. Notice how the colors have changed from red to orange in post #8. That's because the wrong colormatrix was used somewhere along the line. Your original rec.709 video was converted to rec.601 colors. That might be from the way you produced the still images rather than the actual video. VirtualDub, for example, always uses rec.601. So if the colors in the video were rec.709 a snapshot made with VirtualDub will show the wrong colors.

The best practice is to use rec.709 for HD, and rec.601 for SD, and flagging the colormatrix in the video.

[koberulz]

I exported frames from Premiere to get the stills. How can you tell which color matrix is being used? There's something about matrixes in the MediaInfo output for the .264, but not for the .AVI.

The color matrix options in MeGUI are:
bt709
fcc
bt470bg
smpte170m
smpte240m
GBR
YCgCo

Not seeing any in Premiere at all.

[jagabo]

MediaInfo may tell you what colorspace was used in your source. If it doesn't you can usually assume rec.709 for HD, rec.601 for SD. Assuming the source is rec.709... Is Premiere putting out RGB? If so, you need to make sure it converts from YUV to RGB with a rec.709 matrix. Then you need to make sure it gets converted back to YUV with a rec.709 matrix in AviSynth with ConvertToYV12(matrix="rec709"). Then you should set the encoder to flag the video as rec.709. If MeGUI doesn't give specific control over that you and use the x264 extra options field to specify --colormatrix=bt709.

[koberulz]

Premiere is outputting YUY2, both for the signpost and for the Lagarith AVI I encoded overnight, which looks identical to the MJPEG AVI. So the problem is MeGUI, presumably.

MeGUI always offers to automatically add a 'ConvertToYV12()' to the end. So I should be adding the matrix thing there, presumably.

EDIT: Nope, I'm getting this:
---------------------------
Error parsing avs file
---------------------------
ConvertToYV12: invalid "matrix" parameter (RGB data only)
([filename].avs, line 3)
---------------------------
OK
---------------------------

[koberulz]

Additionally, I've never noticed the chroma alignment problem on games from any other venue, and went back and watched one of them today and it's definitely not a problem there. Which doesn't make much sense.

[jagabo]

The matrix argument only makes sense when converting YUV to RGB or vice versa. Converting from one form of YUV (YUY2) to another (YV12) involves no RGB conversion.

[koberulz]

Well then.

I guess I'll give the x264 encode a whirl, from the actual existing AVI rather than a signpost, and see how that goes. I've got three of these on the go at the moment, I'm running out of hard drive space, and it's almost Christmas. My problems are so inconsiderately timed.

[jagabo]

Why don't you work with short test video? Then time and space aren't a problem.

[koberulz]

The encode was interrupted by a BSOD - something about a clock interrupt not being received. I found the other day that it'd rebooted itself mid-encode, which I assume was the same thing.

EDIT: But it got far enough to allow the same frame comparison from above, and the colours are still wrong, and slightly to the side of where they should be.

[jagabo]

Was that encoding to a lossless intermediate? This is important because when you are encoding with an out of order codec like x264, especially when using a complex AviSynth script, frames can be requested from the server out of order. Many source decoders get confused with that and deliver the wrong frames or corrupt frames. Lossless codecs don't request frames out of order so there is less chance of confusion.

[koberulz]

That was encoding to x264 from the aforementioned Lagarith AVI via MeGUI. The Lagarith AVI was exported from Premiere.

[jagabo]

So the lagarith avi exported from premiere had no problems?

By the way, there's something obviously wrong with your computer (probably overheating) since you can't complete and encoding without a BSOD or reboot. You need to fix that first. This may be the source of all your encoding problems.

Try encoding with x264 set to a single thread (less CPU usage, less heat) and see if that crashes.

[koberulz]

It was overheating a while back, but I took it in and had it looked at. And it was actually saying it was overheating, whereas now it's something about clock interrupts.

[jagabo]

Run a CPU temperature monitor, like coretemp, while you're encoding. I think you'll see your temperatures are skyrocketing. The error message may indicate clock interrupt problem but that's most likely a symptom, not the root cause.

[koberulz]

Screenshot:

[jagabo]

100 degrees C?! You're overheating. I get about 55 while encoding and that's a bit high since I optimize for quiet running, not low temperatures. Check all your fans. Clean all the dust out of the fins of your CPU cooler. If that doesn't get your temps down to 60 or less you need a better CPU cooler. Is this a laptop? If so, your only option may be to run x264 with fewer threads.

[koberulz]

It's a desktop. It was all cleaned out not that long ago after suffering overheating issues. Is permanent damage a consideration?

[jagabo]

Permanent damage is a possibility. Though not a certainty.