Why do I keep getting junk psychedelic frames?

[shlap]

I'm using the x264_x86_r859_progress_techouse x264 build and I keep getting a few frames puking thoughout the movie; not many, but still annoying. Is there anything in peticular I could be doing wrong to cause this, or could it be anything? Would surfing or playing videos during encoding cause this? Here's what I'm talking about...

http://warpreality.com/compare/crap/shit0.jpg
http://warpreality.com/compare/crap/shit04.jpg
http://warpreality.com/compare/crap/shit05.jpg
http://warpreality.com/compare/crap/shit2.jpg

[Mr VacBob]

Is threading on? I've seen chroma errors with threads on recently, especially with FGO, but couldn't find what was doing it. (along the way I did fix --nr, though)

[microcosmos]

the video could be badly muxed in the mp4 container, I don't know the specifics behind it but it looks familiar. Try extracting the raw stream and mux into mp4(or mkv) again...

[akupenguin]

Try extracting the raw stream
If the media player can't demux it correctly, why would a remuxer work?

[microcosmos]

If the media player can't demux it correctly, why would a remuxer work?

maybe it's this issue:
(from http://gpac.sourceforge.net/doc_mp4box.php )

"Some existing MP4 files may use MPEG-4 Visual tracks with B-Frames in an improper way. There is currently no automatic cleaning of such files in MP4Box, but reimporting the track will solve the problem."

[shlap]

Thanks for all of the responses. I actually had x264 mux into an mkv container (and I am using FGO so maybe that's got something to do with it), then muxed in the ac3 track. I'll try extracting the raw h264 stream and see how it looks to see if it's a container issue.

[bob0r]

You may try x264.exe --no-xtc :D

Joking aside, does it happen with an x264.nl .exe too?

[shlap]

You may try x264.exe --no-xtc :D

Joking aside, does it happen with an x264.nl .exe too?

Not sure, I just tried Jarod's latest build. If that doesn't work, I'll give this build a try. Thanks.

[nm]

Not sure, I just tried Jarod's latest build. If that doesn't work, I'll give this build a try.
Jarod=bob0r=x264.nl :)

[shlap]

Jarod=bob0r=x264.nl :)

Doh! Thanks for setting me straight. I tried playing the raw h264 file extracted from the mkv but the crappy frames are still there. Maybe FGO is just too buggy to use ATM. Has anyone else used FGO without bad frames slipping in here and there? I'll try again without FGO tonight.

[desta]

I've had some encodes that suffered chroma issues when using FGO, but found that for those particular encodes the problems seemed to occur when either encoding with crf, or doing a 2pass encode with fgo only in the 2nd pass. They weren't nearly as severe as the artifacts in your screens though.

When I added fgo to the first pass (and therefore subme 6, brdo, i8x8 and 8x8dct) the problems disappeared. Using the same merange for both passes seemed to help slightly too.

I'm not basing that on any indepth knowledge of x264's mechanisms, just through trial and error.

As I said though, those chroma problems only occured on certain encodes, not all.

[Mr VacBob]

I get it without threads now, but it's hard to reproduce.

This clip only had it with threads:
http://astrange.ithinksw.net/ffmpeg/hr1-threaded.mkv
vs
http://astrange.ithinksw.net/ffmpeg/hr1-unthreaded.mkv

http://img50.imageshack.us/img50/5266/hrchromaerrormd7.png (http://imageshack.us)

[saint-francis]

Is your source HD and did you demux it with eac3to? I have similar issues with MPEG2 HD sources demuxed with eac3to and certain AVISynth filters. Does the issue appear if you play the .avs or only after encoding? That probably should have been my first question.

[Mr VacBob]

The source is fine. I'm encoding from huffyuv, not an avs.

[gizzin]

I get garbage frames too. When I do encodes with megui.

[Dark Shikari]

OK, nevermind that explananation. In one of the blocks there are luma coefficients, DC coefficients, in all 4 8x8 DCT blocks; these end up fine, while the chroma ends up distorted. This sounds like a mistake with chroma QP, or a mistake in chroma transform of some sort.

It only occurs with chroma DC transform, nothing else.

If anyone here has a repeatable case of this bug, run a test with --no-asm.

[ect5150]

I think my case may be this problem as well. It is a repeatable case across a few frames.

Using megui, x264 "859-3 Jarod's patched build" using the folloing command line

--crf 21.5 --level 4.1 --keyint 14 --min-keyint 1 --ref 5
--mixed-refs --no-fast-pskip --bframes 2 --b-pyramid --b-rdo
--bime --weightb --direct auto --filter -2,-1 --subme 7 --trellis 2
--partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1
--pbratio 1.1 --vbv-bufsize 14475 --vbv-maxrate 25000
--qcomp 0.5 --me umh --thread-input --progress
--no-dct-decimate --no-psnr --no-ssim --output "output"
"input" --mvrange 511 --aud --nal-hrd --sar 4320:4739 --fgo 10

This is the result:

http://i119.photobucket.com/albums/o150/ect5150/misc/snapshot20080610204028.jpg

Also, tried it with --no-asm, still get errors.

[Dark Shikari]

Post the .h264 file please?

Since you have a repeatable case, I'd like the following:

1. Your source.
2. A commandline (already done).
3. The specific executable file.

If you don't have webhosting space, upload to Mediafire or similar.

If possible, get the smallest possible frame range that can be encoded from the source that results in the problem. The smaller the better, since obviously the less I have to encode, the faster debugging will go.

I'll throw in some debugging statements and see what I can do.

[ect5150]

No problem, I'm using a range of 400 frames, but its an avs script thru a vob file and its rather large. Suggestions on how to just grab the relevant frames? Once I do that everything else is doable.

I'll just edit this post as I upload.

h.264 in an mp4 file : [UPDATED] http://www.mediafire.com/?lywdmddfcmk
exe file: http://www.mediafire.com/?9bcxzgzgtj9
Source: http://www.mediafire.com/?ygk9ydcxzmg compressed with HuffYUV ~41 Megs

Need anything else?

[Dark Shikari]

No problem, I'm using a range of 400 frames, but its an avs script thru a vob file and its rather large. Suggestions on how to just grab the relevant frames? Once I do that everything else is doable.You could just compress them to FFV1 or something similarly high-compression but lossless; that should easily drop it to a small enough size to upload it to Mediafire.Need anything else?Not for now, I'll start testing and see if I can replicate it with my own build so that I can add debug statements.

[ect5150]

Files listed in the post above.

[Dark Shikari]

Now that was fun tracking that one down, eh? :p

Bug fixed (http://git.videolan.org/?p=x264.git;a=commit;h=2389de25ff7fe6f84c9c885578c0fbaa6b656f4a).

[ect5150]

Now that was fun tracking that one down, eh? :p

Bug fixed (http://git.videolan.org/?p=x264.git;a=commit;h=2389de25ff7fe6f84c9c885578c0fbaa6b656f4a).

Of course! Its always fun fixing good stuff, making it even better. Thanks! :thanks: