green blocking between keyframes on encode

[legoman666]

I guess they're called keyframes? not too sure of the terminology. Anyway, they definately aren't there in the source, and they're here now.

http://img124.imageshack.us/img124/6150/greenblockingph8.jpg

any ideas? It's not too annoying, but I'm going to be doing ~13 or so more encodes just like this and I don't really want those green blocks in every one.

[shon3i]

What is resolution of video?

[Dark Shikari]

Whoa, its like tetris!

[imcold]

You could post some more info... like what encoding options you used, what apps, on what system (overclocked? check hardware errors...), post sample file, etc.

[AGDenton]

It's happened to me when I "split-&-stitch"-ed a video to process it in parallel over a cluster. It happens at some, but not all, of the stitch points... To this day, I haven't identified the precise cause.

Is this video the result of x264farm ?

[morph166955]

the only way to know if its x264farm is by encoding it straight through w/o using x264farm and comparing the two. if one does it and the other doesnt...then it is possible that x264farm isnt stitching the video together properly but seeing as many others havent been screaming about this I doubt its that.

[foxyshadis]

VLC's MPEG muxers also cause artifacts like this (but usually much worse). So does this come directly from x264 w/o additional muxing?

[legoman666]

What is resolution of video?

the source is 1080i, i downsized it to 720p.

You could post some more info... like what encoding options you used, what apps, on what system (overclocked? check hardware errors...), post sample file, etc.

My system is overclocked, its a 3800+ AMD X2 (2.0ghz default) running at 2.6ghz. However, since the artifacting only occurs at keyframes, and the fact that it was encoded using x264farm (meaning that my computer isn't even most likely the computer that encoded that frame) I'm doubtful that the artifacting is the result of too much overclock.

I used x264farm to do the encoding, and muxed the audio/video with mkvmerge. Here's the command line options I used for the x264farm controller:
controller.exe -B 3097kbps --first "--bframes 3 --b-pyramid --direct auto --filter -2,-1 --subme 1 --analyse none --vbv-maxrate 25000 --me dia --progress --no-psnr --no-ssim" --second "--mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-1 --subme 6 --trellis 1 --analyse all --8x8dct --vbv-maxrate 25000 --me umh --progress --no-psnr --no-ssim" --avs "C:\firefly ep1+2.avs" -o "C:\Firefly ep1+2.mkv"

VLC's MPEG muxers also cause artifacts like this (but usually much worse). So does this come directly from x264 w/o additional muxing?
The original mkv made by x264farm has the green blocks as well as the final mkv with the sound muxed in. I tried the video in VLC, megui (the screenshot I took is from the preview pane), and MPC. Green blocking occured in all 3 apps.

running a test now to see if the green blocking occurs when encoding megui...

[legoman666]

well apparently, the green blocks are being introduced by x264farm's encoding, because when I used megui to do the same frame, the green blocking disappeared.

http://img372.imageshack.us/img372/9979/nogreenblockingpi9.jpg

[AGDenton]

Can you get the frame pattern (I/P/B) right before/after one of these blockfests occurs ? Also, are you sure the blocking occurs on an I frame ?

AG

[legoman666]

Can you get the frame pattern (I/P/B) right before/after one of these blockfests occurs ? Also, are you sure the blocking occurs on an I frame ?

AG

not 100% sure they occur on keyframes, but it seems that they do. How would I find that information?

[AGDenton]

You should demux the h264 stream from whatever it's in (probably a mkv, since it's from x264farm -> mkvextract), then use the h264_parse utility which is part of the mpeg4ip package.

My hypothesis is that these blocks at the frame right before the split-point (so before an I-frame that has been produced by a different run in the encoder).

AG

[foxyshadis]

ffdshow's OSD will show that, as the value "Frame Type".

Or yes, h264_parse will work, but it's probably more work (especially matching the slice up to the time).

[legoman666]

You should demux the h264 stream from whatever it's in (probably a mkv, since it's from x264farm -> mkvextract), then use the h264_parse utility which is part of the mpeg4ip package.

My hypothesis is that these blocks at the frame right before the split-point (so before an I-frame that has been produced by a different run in the encoder).

AG

the mpeg4ip package only has the source available no binaries, could you upload that h264_parse program to me? :D

ffdshow's OSD will show that, as the value "Frame Type".
I have ffdshow installed, but i havn't the faintest idea on how to do that.

[AGDenton]

celtic_druid has binaries of the mpeg4ip tools :

http://celticdruid.no-ip.com/xvid/

There's a mpeg4ip section there...

I'm advising h264_parse because the title bar on the screenshots above contains the number of the displayed frame :-).

AG

[legoman666]

hehe, how do i tell h264_parse what frames to analyse? its "help" isn't exactly helpful

[AGDenton]

I think you don't have a choice, it will process the whole stream... I would pipe its output to grep and select the "slice_type:" lines : I'd get a text file with 124575 lines, where the line number will be the frame number.

Is that possible under Windows?

AG

[legoman666]

Hm, I dont think so, the windows command line only has ~300 lines and then it just scrolls off the top.

[AGDenton]

What about redirecting the output to a file ?

[legoman666]

What about redirecting the output to a file ?

im downloading the source now to see if i can edit it and have it output to a txt file. hopefully this wont be too difficult....

edit: bah no idea what im doing. I've only done simple things in c++, i don't know how to compile just the h264_parse project. I can add the code that outputs to a txt file, but don't know how to compile :(

[imcold]

for redirecting in cmd use: h264_parse file.264 > log.txt

[omion]

Actually, the easiest way to check for if an I frame or not is to look at the x264farm temp files. All the second pass parts are 1 GOP long. If the blocks happen at the beginning of each temp file it's an I frame. This will also help in determining if the problem is in the encoder or the muxer.

It's fairly likely that the temp files have already been deleted, though. If you rerun the encode with the same settings, x264farm will start at the beginning of the second pass. However, in order to keep the temp files you must kill the controller before it finishes. (I made a --keeptemp option for this, but it doesn't work :rolleyes: )

Does this happen every few seconds, or is it once or twice per episode?

PS. I love Firefly :cool:

[legoman666]

hehe, i made a lil c++ parser for the output of h264_parse,

I'm guessing the frame numbering is off by 1, (either my numbring is off, megui's numbering is off, or the file im parsing form h264_parse isn't complete). if it is its a P frame. Anyway here it is:

26225 slice_type: 6 (B)
26226 slice_type: 5 (P)
26227 slice_type: 6 (B)
26228 slice_type: 5 (P)
26229 slice_type: 7 (I)
26230 slice_type: 5 (P)
26231 slice_type: 6 (B)
26232 slice_type: 6 (B)
the frame in question is 26227

omion: either i'm really tired from studying (probably the case, stupid physics exam today at 5, who the hell shedules exams at 5 on a friday?) or I'm not noticing it as much, but I'd say it happened about 7 times during the 2 minutes of an episode of firefly I watched, not very evenly spaced apart. And you are correcting in assuming the temp files were already deleted :D

[omion]

I'd say it happened about 7 times during the 2 minutes of an episode of firefly I watched, not very evenly spaced apart.

That makes it sound like one of the computers is giving wonky results... You can figure out which computers encoded which parts of the movie by wandering through the out-dump.txt file and comparing them to the temp file names. (it ain't easy, though...)

If/when you have the time, it would be helpful if you sent me the out-dump.txt file and a list of the names of temp files which have the problem (Everything has to be from the same encode). My e-mail is at the top of x264farm.html (don't want to post it here due to spammage).

[legoman666]

Looking through the one of them temp files that wasn't deleted by the controller, I found this:

in:26224 out:26223 type:P q:26.00 itex:25076 ptex:123395 mv:27189 misc:2060 imb:526 pmb:2451 smb:623 d:s;
in:26223 out:26224 type:b q:28.00 itex:151 ptex:22411 mv:11490 misc:3316 imb:14 pmb:1571 smb:2015 d:s;
in:26226 out:26225 type:P q:26.00 itex:76849 ptex:136176 mv:32634 misc:1453 imb:1183 pmb:2058 smb:359 d:s;
in:26225 out:26226 type:b q:28.00 itex:5337 ptex:56480 mv:27401 misc:3134 imb:131 pmb:1976 smb:1493 d:s;
in:26227 out:26227 type:P q:26.00 itex:2031 ptex:56745 mv:11803 misc:3133 imb:141 pmb:2175 smb:1284 d:s;
in:26228 out:26228 type:I q:23.00 itex:389087 ptex:0 mv:118568 misc:401 imb:3600 pmb:0 smb:0 d:s;
in:26232 out:26229 type:P q:26.00 itex:40029 ptex:97459 mv:21184 misc:2344 imb:412 pmb:2349 smb:839 d:s;
in:26230 out:26230 type:B q:27.00 itex:3791 ptex:48049 mv:15829 misc:3043 imb:47 pmb:1661 smb:1892 d:s;
in:26229 out:26231 type:b q:28.00 itex:1017 ptex:21804 mv:9803 misc:2600 imb:7 pmb:1058 smb:2535 d:s;

So 26227 is indeed a P frame before an I frame.

The agent running on this computer (the controller) processed frame 26227 during the first pass. If I could find a list of the gop's and which frames they include, I could look through the out-dump.txt and figure out which computer did that gop. But I'm looking through the .d2v file, the output of h264_parse, the 1-3CC448D4D2454F2A85AACD5F1755BC76.txt file from the controller, and out-dump.txt and I'm not finding it. I'm guessing the .d2v file contains the info I want, but I don't know how to interpret the data in it.

800 1 0 299778596 0 0 0 73 d0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0
800 1 0 300823124 0 0 0 71 d2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2
800 1 0 301743384 0 0 0 73 d0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0
800 1 0 302841492 0 0 0 71 d2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2
800 1 0 303806308 0 0 0 73 d0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0
800 1 0 304763040 0 0 0 71 d2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2
800 1 0 305808320 0 0 0 73 d0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0
800 1 0 306856044 0 0 0 71 d2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2

Whats that long number after the 800 1 0?

[legoman666]

I made a quick program that that runs through the h264_parse output. It updates a counter whenever it finds an i frame. Hopefully, my numbering isn't off.


frame gop
26223 216 slice_type: 5 (P)
26224 216 slice_type: 6 (B)
26225 216 slice_type: 5 (P)
26226 216 slice_type: 6 (B)
26227 216 slice_type: 5 (P)
26228 217 slice_type: 7 (I)
26229 217 slice_type: 5 (P)
26230 217 slice_type: 6 (B)
26231 217 slice_type: 6 (B)

according to this, frame 26227 is from gop 216, which was processed by.... the computer in my basement:
2007-04-20~04:31:55.43 basemnet 1 check_out_job got GOP #216 from 0.00, with 61759576.8 optimal bits

Another frame with the green blocking is 25948. Frame 25948 is a B frame before an I frame from GOP 214. GOP 214 was processed by local 2.

Another frame with the green blocking is 26487. Frame 26487 is a P frame before an I frame from GOP 218. GOP 218 was processed by my sister's computer.

Another frame with the green blocking is 26847. Frame 26847 is a B frame before an I frame from GOP 220. GOP 220 was processed by my mom's laptop.

However, after examing this video frame by frame, it leads me to believe that its the I frame itself that has the corruption. Here is example that leads me to believe this:
frame 26846:
http://img341.imageshack.us/img341/6258/frame26846uq5.jpg
frame 26847:
http://img341.imageshack.us/img341/6120/frame26847hh5.jpg

however, assuming this, it would mean my frame numbering is off by 1 which would move the GOP's by 1 as well. This would mean:
frame 25948 is an I frame in GOP 215, GOP 215 was processed by my mom's laptop.
frame 26487 is an I frame in GOP 219, GOP 219 was processed by my brother's computer.
frame 26847 is an I frame in GOP 221, GOP 221 was processed by my brother's computer.
frame 27638 is an I frame in GOP 225, GOP 225 was processed by my brother's computer.
frame 27896 is an I frame in GOP 229, GOP 229 was processed by local 2.
frame 28702 is an I frame in GOP 237, GOP 237 was processed by my sister's computer.

either way, it's not the same computer every time creating the messed up frames, its all of the computers. Which leads me to believe its a problem in x264farm or splitter because the green blocking doesn't occur when using megui.

[AGDenton]

A question to omnion :

Does x264farm always process everything at least twice ? In other words , is everything in the output the result of separate gop processing?

AG

[legoman666]

A question to omnion :

Does x264farm always process everything at least twice ? In other words , is everything in the output the result of separate gop processing?

AG

the first pass is sent out in chunks of 5250 frames. The second pass jobs are sent out per GOP (max 250).

[omion]

A question to omnion :

Does x264farm always process everything at least twice ? In other words , is everything in the output the result of separate gop processing?

AG

It does most frames once during the first pass (frames at each split point are encoded twice, though), and then once more during the second pass (some frames twice if the bitrate for that scene was way off)

But yes, the output is stitched together from individual GOPs, which are calculated separately.

[legoman666]

up! still having this problem, using megui in the meantime.

[SpAwN_gUy]

up! still having this problem, using megui in the meantime.i assume you are encoding VC-1 content ;) .... i did that also.. last week..
and you are using Graphedit's (Haali Media Splitter(MKV with Timecodes)-> WMVideo Decoder DMO)..
i also had that issue.. it is because of WMVideo Decoder..
when Searched(as x264farm does always) through .avs this decoder produces few Green frames(i think those.. i haven't seen the pics.. no traffic for now..) at the beginning..
so, to get rid of those ADD to Controller CmdPath "--preseek 5" or more... i think it will skip those green frames from the encoding (i havent done the whole encode.. 'cause i found free E6400 for my needs..)