MeGUI x264 encoding problem. Video stutters/flickers.

[EasyDrama]

Hey everyone,

I use MeGUI and x264 to encode video and subtitles created by fansubbers for my Jdrama website and they both work great. Unfortunately though, I recently came across a problem where one of my encodes stutters/flickers at the beginning of the video which is not present in the source. I have uploaded a clip of the problem to my megaupload account so you can see exactly what is going on.

http://www.megaupload.com/?d=O3AN5EMM

I have tried multiple encodes with no programs running in the background using MeGUI and the latest build of x264 (rev.1400 as well as rev.1391 and rev.1376) but they all have the same problem at the same location. I normally use the default DXVA-HD-HQ profile in MeGUI to encode with but I have also tried a few of the other DXVA encoding profiles all with the same result.

I am not a guru when it comes to video encoding but I do understand some settings and their purposes and any suggestion on fixing this problem would be greatly appreciated. Thanks in advance!

[poisondeathray]

It looks like some frames are out of order.

Post your .avs script.

When you preview the .avs script in a media player (e.g. MPC) does it have the same issue?

[manono]

Now how about the same scene from your source? And don't use MegaUpload. Not only do you have to type in stuff, but you then have to wait 45 seconds before you can begin the download. Try Sendspace or MediaFire.

[poisondeathray]

Since your sample was <6MB you can actually upload it here (or at least you used to be able to before the forum switch)

Looks like it works. I think the new limits are 30MB now

[EasyDrama]

@manono

As I have already stated in the first paragraph, this error "is not present in the source".

I don't see anything wrong with using megaupload as oppose to another file hosting service. They give you plenty of storage space for people with free accounts and they keep your files online for at least 90 days. If you're a premium member, your files are online indefinitely regardless if anyone clicks on it (which is important for running my site) and you don't have to wait or type in anything at all.

Free megaupload accounts get a few free downloads per day without waiting at all also. It's only 45 seconds for unregistered people and it's only 45 seconds for crying out loud. You could have just clicked "view on megavideo" and you wouldn't have to type in anything either.

@poisondeathray

The script is pretty simple actually and I'm not sure it reallly affects it much. Besides the default, I just changed the audio field to true and trimmed the first 2 green frames.

AVISource("F:\Bloody Monday\Original\Bloody Monday ep11 Finale.avi", audio=true)
#deinterlace
#crop
#resize
#denoise
Trim(1,0)
Trim(2,0)

Not sure if I'm using the trim command properly but the green frames from the output video are gone. I have already tried re-encoding the video without using trim and the video still stutters in MPC and a few other media players that I have tried. Thanks for letting me know about videohelp's upload limit.

[poisondeathray]

You could use Trim(2,0) , to get rid of original frames 0 and 1. I think the way you have it would get rid of 0,1,2 from the original frame numbering

Anyways, please answer the original question: when you preview the .avs script, are the frames out of order ?

It could be a decoder issue with b-frames. I've seen this happen with certain xvid builds for example. If the frames are fed out of order, it's not the fault of the encoder. When you view the native video, it's not using VFW system, it's using the directshow system to decode (so it could be using a different decoder). When you use AVISource() it uses the VFW system to decode.

You could switch source filters, eg. FFMpegSource2() if your VFW filters on your system are buggy

One reason to post the original, is to try to eliminate other possible factors and narrow down the problem. (e.g. If someone else can replicate your issues, or is it something specific to your system)

[EasyDrama]

Sorry poisondeathray but I'm still pretty new with video encoding and I'm not sure what I should use to preview the .avs script to see if the frames are out of order. Can you explain to me how to do this?

To be honest, I'm also not very familiar with writing scripts either . After loading the original video into MeGUI's AVS script creator AVISource is selected and the rest of the script is generated automatically except for the bit that I added. Should I try substituting "AVISource" with "FFMpegSource2" in the script and try re-encoding it?

I haven't tried encoding the video with any other system besides the one I'm currently using so it could be that it's specific to my system. Besides the files that MeGUI downloads and install, all I use is ffdshow tryouts with MPC and VLC media player, no codec packages. I still have the original and can upload you a copy if you would like to try encode it. It's about ~1GB so it'll take awhile though. Please let me know.

[poisondeathray]

Save the .avs script that megui made for you; just like the one your posted above. Open that .avs file in vdub for example and use the cursor key to "scrub" through and look to see if the frames are in proper order. You could also preview the .avs in MPC, but navigating to individual frames is more difficult (i.e. it can only play it)

When people ask to upload a sample of the source, they usually mean the smallest possible section that can still replicate your issues. So you would cut it (stream copy) to a few seconds including that point where all the frames are out of order. Since the original was an .avi file, you could use vdub to do this (set video to direct stream copy, and mark your in/out points) . You don't have to do this yet, preview the script first.

[EasyDrama]

It was exactly as you suspected. When I load the .avs script into vdub it also stutters. What should I do to correct this?

[poisondeathray]

Is your video xvid? Use mediainfo (view=>text)

You have several options, one is to switch the decoder. You could use ffdshow vfw to decode xvid (it's the yellow icon, not the red icon for the configuration). If you're already using ffdshow, then switch it to xvidvfw.dll. To do this you would disable ffdshow vfw xvid decoding, and install the normal xvid download

Another is to use DirectShow instead of AVISource, but DirectShow has it;s own issues, like possible issues with frame accuracy and exposure to directshow filters

DirectShowSource("Bloody Monday ep11 Finale.avi")

Another is to use different source filter, like ffmpegsource2() - you have to download the package and put in the avisynth plugins folder (including the .dll and .avsi), I don't think it's bundled with MeGUI . It has full documentation and instructions included

It's a good idea to get into the habit of creating your own scripts and previewing them before encoding, because the auto script creator can (and often does) makes mistakes. This way you don't waste too much time encoding

If none of these suggestions work on your preview, then there might be another issue with your source, and then it's time to upload a sample for farther investigation

[EasyDrama]

Thank you for all of your help poisondeathray. After following your suggestion I was finally able to fix the problem. According to mediainfo the video is DivX5 and after changing the DivX5 vfw configuration in fddshow the script no longer stutters in vdub =)

I have another question though. In the original source, the green frames are not present in the beginning of the video, but after the encode it appears in the MKV file if I don't add the trim command. Why are the green frames created? To save some time in the future, is there anyway to trim those frames without re-encoding the video. I know that this can be done with vdub for .avi files by moving the cursor and deleting the unwanted frames but how about MKV files?

[poisondeathray]

You shouldn't have green frames with the new script / decoder configuration , and you shouldn't have that in the newly encoded file either if you are encoding to a mkv container, for example. Again , preview your scripts before encoding.

The green frames are usually due to a decoder issue, and it has to do with b-frames and avi container. When an avi file has "packed bitstream" it is supposed to help this, but not always - it also depends on the decoder you use as you just experienced. VFW is an old system that relies on 1frame in 1frame out. It doesn't handle b-frames very well, which can reference both foward and backwards (and if you use x264, it can reference multiple frames out) . As a result you can get b-frame decoder lag and sync issues as well upon playback, that accumulate the more b-frames are encountered. AVI is not a very good container if you use b-frames.

If you've made a "bad" mkv in the past, and want to cut the green frames out without re-encoding, it might be possible with avidemux. The frame after the green frames (the 1st "good" frame) has to be an I-frame, other wise it won't work

[EasyDrama]

Oh I see, so that's why the frames appear. I'm glad that they shouldn't appear from now on since the correct decoder is being used. I have created a few bad MKVs in the past but unfortunately the only solution I found to this after searching google was to add Trim(1,0) and re-encoding the video =( Next time I'll be sure to give avidemux a try.

I have heard somewhere that it can be done with vdubMOD but what is your opinion on this. I know vdubMOD is pretty outdated and is no longer worked on but is it possible? I've tried loading the affected MKV into vdubMOD before but it gave me this message:

[!] MKV: Subtitle stream (3) contains overlapping subtitles. Some of them may
not be kept when editing.

[!] Couldn't locate decompressor for format 'ÿÿÿÿ' (unknown).
VirtualDub requires a Video for Windows (VFW) compatible codec to
decompress video. DirectShow codecs, such as those used by Windows Media
Player, are not suitable. Only 'Direct stream copy' is available for this
video.

Where can I find the specific codec to be able to preview the video since fddshow doesn't seem to be accepted? Overlapping subtitles? As far as I know I only muxed one subtitle file with the video.

Sorry for all of the questions. I've been trying to fix the video stuttering problem this past whole week and I really do appreciate all of your help in solving this.

[poisondeathray]

vdubmod won't support the new mkv spec , only ones that had been made many years ago

cutting with avidemux won't save all the subtitles and multiple tracks. only 1 video an (possibly) 2 audio

mkvtoolnix using the split function might work to save the extra streams, but again only on I-frames, and there is no visible preview window (cut by timecodes)

So you could try extract the subs (e.g. mkvextract) , so only 1 video, 1 audio remain, cut in avidemux, then put the subs back in with mkvtoolnix. It might be out of sync those 1 or 2 frames (either the subs and /or audio) , you might have to edit them

It would be a better idea IMO, to make a proper video without errors in the first place, but feel free to experiment

[EasyDrama]

I agree that making a proper video the first time without errors is definitely the best way to go also. I was just curious of what were my options if I ever had to correct a video and didn't want to go through the whole process of re-encoding. Once again, thank you for all of the help and advice =)

[manono]

I'm glad poisondeathray was able to help you with this, but to clear up a few loose ends:

As I have already stated in the first paragraph, this error "is not present in the source"..

Yes, but having the source can be helpful in trying to replicate the problem before then trying to solve it.

I don't see anything wrong with using megaupload as oppose to another file hosting service.

I, on the other hand, see a lot wrong. I have no intention of registering with an inferior service. If you want people to help, you should make it as easy as possible for them to do so. This means, among other things, not having them jump through hoops to get a sample. And you're seriously suggesting I pay them some money so I can get samples without waiting? No thanks.

[SaizenXVII]

You shouldn't have green frames with the new script / decoder configuration , and you shouldn't have that in the newly encoded file either if you are encoding to a mkv container, for example. Again , preview your scripts before encoding.

The green frames are usually due to a decoder issue, and it has to do with b-frames and avi container. When an avi file has "packed bitstream" it is supposed to help this, but not always - it also depends on the decoder you use as you just experienced. VFW is an old system that relies on 1frame in 1frame out. It doesn't handle b-frames very well, which can reference both foward and backwards (and if you use x264, it can reference multiple frames out) . As a result you can get b-frame decoder lag and sync issues as well upon playback, that accumulate the more b-frames are encountered. AVI is not a very good container if you use b-frames.

If you've made a "bad" mkv in the past, and want to cut the green frames out without re-encoding, it might be possible with avidemux. The frame after the green frames (the 1st "good" frame) has to be an I-frame, other wise it won't work

hello! i would like to re-open this issue since i'm having the same problem (if it's okay with you guys)

My problem is only with the green frames (around 4-7 when i checked in VDUB) at the beginning of the video.
The green frames is not found in the source video. It actually appears after making the avisynth script (viewed with VDUB)

I did the same steps as the TS in loading the video into the Avisynth Script Creator...
here is what's inside the script

# Set DAR in encoder to 175 : 96. The following line is for automatic signalling
global MeGUI_darx = 175
global MeGUI_dary = 96
global MeGUI_darx = 16
global MeGUI_dary = 9
AVISource("D:\...\video.avi", audio=false).AssumeFPS(24000,1001)
#deinterlace
#crop
Spline36Resize(1280,720) # Spline36 (Neutral)
LoadPlugin("D:....\avisynth_plugin\UnDot.dll")
Undot() # Minimal Noise

I also noticed that only those XVID, DIVX 4, DIVX 5 videos are giving me the green frames at the start....
DIVX 3 Low does not give me those green frames though (if that helps)


I'd like to try out the "using of different source filters" but i have 0 knowledge about this
I'm also using MeGUI... I have ffdshow tryouts installed too... also Madvr and direct vobsub(if that has any relation to the issue)

and really appreciate your help

[hello_hello]

The moral of the story is don't use AVISource. Well it's fine a lot of the time but when it isn't, use something else. Chances are if you index the AVI with ffmsindex (FFMpegSource2 or however you use it) the problem will go away, although ffmsindex can sometimes have AVI related issues. If so, open the AVI with MKVMergeGUI and remux it as an MKV and use the new MKV for indexing/encoding.