View Full Version : Bad frames, what am I doing wrong?
shlap
8th November 2008, 19:19
This is driving me nuts. It doesn't seem to matter which build of x264 or ffdshow I use, I always manage to get junk frames in every encode.
Here's my method....
1. Rip Blu-Ray with AnyDVD
2. Demux the AC3/DTS track with TSMuxer
3. Create my AVISynth Script
DirectShowSource("E:\Movies\Rips\FANTASTIC4_2\BDMV\STREAM\00001.m2ts",audio=false).ConvertToYV12()
crop( 0, 140, 0, -140)
4. Encode with x264
--crf 20.0 --level 4.1 --ref 4 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --weightb --direct auto --filter -3:-3 --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 30000 --vbv-maxrate 38000 --ratetol 2.0 --me umh --threads auto --thread-input --sar 993:1000 --progress --no-dct-decimate --no-psnr --no-ssim --output "c:\video.264" "c:\video.avs"
5. Mux with MKVMerge.
Most of the movie looks GREAT but I always end up with 5 - 10 spots in the movie that look like crap. Could this be a cpu or memory issue? I'm using a Q6600 (not overclocked) and 2 GB Corsair DDR2 800 memory.
Please help! I'd greatlyappreciate it! Here's a screenshot of a junk frame....
http://www.warpreality.com/screens/ff-bad-frame.jpg
lexor
8th November 2008, 19:56
Well, the standard first question is: Does the avs script play through those spots without error in MPC (or other player)?
/edit: I don't know if it can have this effect, but you shouldn't touch --ratetol parameter, there is just no good reason.
shlap
8th November 2008, 20:09
Well, the standard first question is: Does the avs script play through those spots without error in MPC (or other player)?
/edit: I don't know if it can have this effect, but you shouldn't touch --ratetol parameter, there is just no good reason.
The AVS script plays through the bad spots fine.
Adub
8th November 2008, 20:42
Okay, so which version of x264 are you currently using?
And I am with lexor on this one. I never mess with --ratetol and I have never needed to. Basically, it's defaults are set at what they are for a reason, and you should only mess with it if you really know what you are doing.
shlap
8th November 2008, 21:22
Right now I'm using x264 core 65 r1019M a5ac6a5 (the latest techhouse release) I appreciate the suggestions and I'll remove ratetol but encoding settings don't seem to affect the end result. I've tried various settings and I always end up with random bad frames.
As a test, I re-encoded just the scene with bad frames again and it came out fine so the bad frames look to be random. Could this be a memory or video card?
Also, I let the encode run overnight while I was asleep so I could rule out other programs interfering.
Sagekilla
8th November 2008, 21:22
This could be also be a VBV error. Unlikely, but possible. Like Merlin and lexor said, don't touch ratetol. There's no reason to ever.
Can you post a short sample where you can consistently get this error?
kemuri-_9
8th November 2008, 21:26
lol, everyone's freaking out at ratetol again.
ratetol is basically a value allowing x264 to deviate from the given ABR.
the resulting abr x264 can generate is given abr ± ratetol
i use it for first passes to see if my desired bitrate goes well with the video (by how much it deviates from the abr value i gave it)
ratetol for this reason is effectively ignored in CQP or CRF modes.
as much as everyone is trying to help you, you still haven't stated what revision of x264 you're using...
and since the problem is seemingly sporadic to your postings, what happens if you remove vbv restrictions?
would be able to nail it down to if it is actually a vbv bug if there's no problems without vbv restrictions.
shlap
8th November 2008, 21:29
lol, everyone's freaking out at ratetol again.
ratetol is basically a value allowing x264 to deviate from the given ABR.
the resulting abr x264 can generate is given abr ± ratetol
i use it for first passes to see if my desired bitrate befits the video well (by how much it deviates from the abr value i gave it)
ratetol for this reason is effectively ignored in CQP or CRF modes.
as much as everyone is trying to help you, you still haven't stated what revision of x264 you're using...
and since the problem is seemingly sporadic to your postings, what happens if you remove vbv restrictions?
I'm using x264 core 65 r1019M a5ac6a5 (the latest techhouse release).
I'll remove --ratetol and vbv settings tonight and re-encode though I'm doubtful this will solve my issue.
LoRd_MuldeR
8th November 2008, 21:29
You could also try another build, skystrife (http://forum.doom9.org/showpost.php?p=1208798&postcount=1300) or x264.nl (http://x264.nl/). Just to make sure it's not a compiler/patch problem in techhouse's build...
kemuri-_9
8th November 2008, 21:32
sky's is a bit old, and the standard x264.nl release would be great for pinning down the problem as it is purely based on the repository (without patches) and is in gcc 3.4.x series, which is the current recommended compiler.
shlap
8th November 2008, 21:34
You could also try another build, skystrife (http://forum.doom9.org/showpost.php?p=1208798&postcount=1300) or x264.nl (http://x264.nl/). Just to make sure it's not a compiler/patch problem in techhouse's build...
Maybe I should ask what x264 and ffdshow builds you guys are using if you're never getting junk frames. I've tried various builds from various people using various encoding settings and I always end up with some junk frames. Am I just being too picky?
LoRd_MuldeR
8th November 2008, 21:42
Maybe I should ask what x264 and ffdshow builds you guys are using if you're never getting junk frames. I've tried various builds from various people using various encoding settings and I always end up with some junk frames. Am I just being too picky?
I usually build x264.exe or libx264 myself, it's really not that hard.
Also sky's latest build is still good. There were only negligible changes since r1016, unless you already have a Nehalem machine or experience an "infinite loop" with VBV.
And you definitely shouldn't get any junk frames! If you get at least one "broken" frame, then there is a significant problem somewhere...
Sagekilla
8th November 2008, 21:43
I personally use the latest builds posted on x264.nl (http://x264.nl) if that helps any. Find a short sequence where you can duplicate your bad frame problem, and try encoding again without rateto. If that doesn't help, try without the VBV.
Also, a small tip is to remove your current --partitions "..." portion from your command line. x264 already uses those partitions by default, so you don't need to specify them like that.
shlap
8th November 2008, 21:57
I personally use the latest builds posted on x264.nl (http://x264.nl) if that helps any. Find a short sequence where you can duplicate your bad frame problem, and try encoding again without rateto. If that doesn't help, try without the VBV.
Also, a small tip is to remove your current --partitions "..." portion from your command line. x264 already uses those partitions by default, so you don't need to specify them like that.
Thanks again for all the feedback. The problem is, I can never replicate the bad frames, they seem to happen randomly. I'll try the encode again tonight with an official .nl release, no VBV, and no ratetol and let you know!
Also, does anyone know a quick way to check my encode for bad frames or do I have to keep watching the movie until I see them? This takes forever!
LoRd_MuldeR
8th November 2008, 22:01
Also, does anyone know a quick way to check my encode for bad frames or do I have to keep watching the movie until I see them? This takes forever!
Unless these "bad" frames are the symptom of an error in the H.264 bytestream, there is no automated way to find them. You'll have to use your eyes...
BTW: Did you try different decoders to make sure that this isn't some sort of decoder bug ???
shlap
8th November 2008, 22:06
Unless these "bad" frames are the symptom of an error in the H.264 bytestream, there is no automated way to find them. You'll have to use your eyes...
BTW: Did you try different decoders to make sure that this isn't some sort of decoder bug ???
I've tried both ffdshow_beta5_rev2033_20080705_clsid.exe (listed as 7/5/08 stable) on SourceForge and ffdshow_rev2301_20081105_clsid.exe
LoRd_MuldeR
8th November 2008, 22:23
I've tried both ffdshow_beta5_rev2033_20080705_clsid.exe (listed as 7/5/08 stable) on SourceForge and ffdshow_rev2301_20081105_clsid.exe
Try something that doesn't use ffmpeg/libavcodec's H.264 decoder. Like CoreAVC Decoder or DivX H.264 Decoder...
akupenguin
8th November 2008, 23:19
ratetol is basically a value allowing x264 to deviate from the given ABR.
the resulting abr x264 can generate is given abr ± ratetol
Yes.
i use it for first passes to see if my desired bitrate goes well with the video (by how much it deviates from the abr value i gave it)
Fail.
The size of the deviation (as a fraction of total filesize, and holding ratetol constant) is determined by the distribution of complexity over time, i.e. how well the 1pass algorithm can predict future complexity given past data. It is unrelated to the absolute value of bitrate (at least, any mutual dependency is noise, not information about suitability of the bitrate). If you encode a movie at a target bitrate of 1000kbit and it results in 1010kbit, then (unless it runs into qpmin) a target of 2000 will probably result in 2020. And if some but not all frames run into qpmin/max, that just adds more noise, you still can't predict which way it'll modify the total bitrate once ratecontrol is done compensating for the limited frames.
ratetol for this reason is effectively ignored in CQP or CRF modes.
Ratetol for this reason is perfectly ignored in CQP and CRF. It has little effect in 2nd pass, simply because 2pass will come at least close to the target regardless of any ratetol constraints.
kemuri-_9
9th November 2008, 02:12
I guess i was looking for more out of ratetol than it was capable!
thanks for clearing that up then.
Rumbah
9th November 2008, 02:17
Try using DGAVCDec in your Avisynth script to decode the source. Using ffdshow as video input decoder with directshow can sometimes result in unexpected results.
shlap
9th November 2008, 06:22
Try using DGAVCDec in your Avisynth script to decode the source. Using ffdshow as video input decoder with directshow can sometimes result in unexpected results.
Right now I'm re-encoding without VBV and Ratetol and using CoreAVC as the decoder. If that doesn't work, I'll give DGAVCDec a shot. Thanks for the advice!
Quark.Fusion
9th November 2008, 11:09
Also, does anyone know a quick way to check my encode for bad frames or do I have to keep watching the movie until I see them? This takes forever!
Unless these "bad" frames are the symptom of an error in the H.264 bytestream, there is no automated way to find them. You'll have to use your eyes...
BTW: Did you try different decoders to make sure that this isn't some sort of decoder bug ???
I think metrics can spot this with per-frame graph.
shlap
9th November 2008, 17:53
OK guys, this time I used CoreAVC and encoded with these settings... (no VBV or ratetol)
--crf 20.0 --level 4.1 --ref 4 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --weightb --direct auto --filter -3:-3 --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --sar 993:1000 --progress --no-dct-decimate --no-psnr --no-ssim --output "output.264" "input.avs"
I'm still getting bad frames but in different spots.
http://www.warpreality.com/screens/badframe.png
I guess I'll try DGAVCDec to decode the source now.
I think metrics can spot this with per-frame graph.
Sorry, I'm new, can you send more information on this?
Snowknight26
9th November 2008, 18:23
You aren't trim()'ing the video anywhere, are you?
shlap
9th November 2008, 18:39
You aren't trim()'ing the video anywhere, are you?
No, not during the full length encode.
I did put a trim in a couple of times to see if i could replicate the bad frames in certain areas but they're completely random.
Ramir Gonzales
9th November 2008, 18:55
I would suggest trying an older version of x264, then you immediatelly know if the bug has been introduced in x264, which is what I expect, since I got a crash also with the latest revision, too bad i didn't have a logfile, but it seems x264 has some bugs in current revisions.
kemuri-_9
9th November 2008, 19:29
if you get crashes, it would help to identify what you did to get the crash in order to replicate it for correction.
just saying you got a crash doesn't help anyone.
CruNcher
9th November 2008, 19:38
it looks like something with motion these artifacts are the same visually as if you would have used bad motion adaptive deinterlacing :)
at least they look very similar tough bad motion deinterlacing is appearing @ edges this here doesn't look like it
shlap
9th November 2008, 19:42
My AviSynth script is pretty simple, have a look in the first post. Nothing fancy..
shlap
9th November 2008, 22:57
I just can't win, this time I tried using DGAVCIndex with this avisynth script
loadplugin("DGAVCDecode.dll")
AVCSource("source.dga")
crop( 0, 140, 0, -140)
and this x264 command line
--crf 20.0 --level 4.1 --ref 4 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --weightb --direct auto --filter -3:-3 --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --sar 993:1000 --progress --no-dct-decimate --no-psnr --no-ssim --output "video.264" "video.avs"
I ended up with a video that went black after 19 minutes! Here's the x264 output
avis [info]: 1920x800 @ 23.98 fps (132120 frames)
x264 [info]: using SAR=993/1000
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 4.1
x264 [info]: slice I:837 Avg QP:13.50 size:109850
x264 [info]: slice P:42801 Avg QP:21.38 size: 39853
x264 [info]: slice B:88482 Avg QP:24.28 size: 4298
x264 [info]: consecutive B-frames: 6.6% 9.5% 3.4% 80.5%
x264 [info]: mb I I16..4: 52.2% 44.1% 3.7%
x264 [info]: mb P I16..4: 0.3% 5.9% 0.2% P16..4: 14.7% 11.2% 5.9% 0.0% 0
.0% skip:61.8%
x264 [info]: mb B I16..4: 0.0% 0.1% 0.0% B16..8: 6.6% 0.2% 0.4% direct:
1.5% skip:91.2% L0:40.0% L1:43.5% BI:16.5%
x264 [info]: 8x8 transform intra:80.6% inter:54.2%
x264 [info]: direct mvs spatial:12.2% temporal:87.8%
x264 [info]: ref P L0 66.2% 18.0% 10.6% 5.2%
x264 [info]: ref B L0 75.5% 18.6% 5.9%
x264 [info]: ref B L1 96.5% 3.5%
x264 [info]: kb/s:3161.9
encoded 132120 frames, 13.52 fps, 3163.98 kb/s
Please help, I'm desperate :(
Sagekilla
9th November 2008, 23:14
Please cut a sample that you can consistently get bad results on and post it, that would help.
Also, try doing multiple encodes and check if you get the same result over and over, if not then something else is amiss.
Adub
9th November 2008, 23:19
Sagekilla, he may have a hard time of doing the first thing you asked. He has repeatedly said that the glitches are random, and he can't isolate it down to just one scene.
Atak_Snajpera
9th November 2008, 23:21
I would recommend Prime95 MT + Memtest x86
Sagekilla
9th November 2008, 23:23
Hm, it's unlikely but you could do a memtest to make sure your RAM isn't screwed up.
But, if playback of the avisynth script goes through without issue it sounds like an x264 bug and not a avisynth bug.
Atak_Snajpera
9th November 2008, 23:24
We have to be 100% sure that his PC is stable
shlap
10th November 2008, 01:03
Sagekilla, he may have a hard time of doing the first thing you asked. He has repeatedly said that the glitches are random, and he can't isolate it down to just one scene.
Exactly, I can't replicate the error on any given scene, it's random.
I would recommend Prime95 MT + Memtest x86
I'll give these a shot and post the results, thanks!
shlap
10th November 2008, 01:30
Memtest86+ is running right now on the encoding machine, it's a sea of red, hundreds of errors. I think we may have found the answer! right?
Atak_Snajpera
10th November 2008, 01:30
Leave your pc on for few hours
LoRd_MuldeR
10th November 2008, 01:37
Memtest86+ is running right now on the encoding machine, it's a sea of red, hundreds of errors. I think we may have found the answer! right?
Yes, apparently your RAM is borked. It's no surprise to get "bad" frames and other random faults with borked RAM modules!
Leave your pc on for few hours
If he already got numerous errors in Memtest86+ there is only one thing to do:
Try to identify the borked RAM modules, unplug them, bring them back to shop and get good ones :)
Atak_Snajpera
10th November 2008, 01:40
Memtest86+ is running right now on the encoding machine, it's a sea of red, hundreds of errors. I think we may have found the answer! right?
Try to raise cl values in bios and other timings. I hope you know what i say :)
LoRd_MuldeR
10th November 2008, 01:43
Try to lower cl values in bios and other timings. I hope you know what i say :)
If he doesn't know, he was obviously running with default values. And if he gets errors in that case, the RAM modules are broked.
If he lowered the RAM timings below the specs of his modules, he shouldn't be surprised to see errors :p
shlap
10th November 2008, 01:51
I set the bios back to system default settings which is auto for everything and still got memory errors.
Sagekilla
10th November 2008, 01:51
That means your RAM is faulty and needs to be replaced.
Ah, I remember getting those errors. No fun.
LoRd_MuldeR
10th November 2008, 01:53
I set the bios back to system default settings which is auto for everything and still got memory errors.
You'll have to bring the bad RAM modules back to shop and get new ones :(
I hope you still have guarantee...
shlap
10th November 2008, 01:54
You'll have to bring the bad RAM modules back to shop and get new ones :(
I hope you still have guarantee...
I got the memory from NewEgg. I already have a Corsair RMA # :-)
I've been messing with different encoders, decoders and rip methods for months! It looks like I may finally have found the answer. Hallelujah! Thanks again everyone.
Sagekilla
10th November 2008, 01:55
Even if his memory is out of warranty, he can still buy a pair of decently sized and quality RAM cheaply. IIRC, it's something ridiculous like $10 - $20/GB now.
LoRd_MuldeR
10th November 2008, 01:59
I've been messing with different encoders, decoders and rip methods for months! It looks like I may finally have found the answer. Hallelujah! Thanks again everyone.
Strange that you didn't encounter more serious problems with the bad RAM, like random application crashes and blue screens.
Bad RAM simply results in unpredictable behavior...
Even if his memory is out of warranty, he can still buy a pair of decently sized and quality RAM cheaply. IIRC, it's something ridiculous like $10 - $20/GB now.
Right. I can't believe that I had to pay 129 € for my "GeIL Ultra DIMM 2 GB Kit", which is at 34,99 € now :D
shlap
10th November 2008, 03:09
Strange that you didn't encounter more serious problems with the bad RAM, like random application crashes and blue screens.
Bad RAM simply results in unpredictable behavior...
Right, which is why I never thought of the memory being bad. I've had 0 stability issues with this system. I only let memtest86+ run for about 2 min and had 200+ memory errors!
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.