How to reduce blocky artifacts in low res, low bitrate video

[The111]

It will take too much bitrate to bob (2x the # frames), so for the low bitrate scenario, you probably can't use it.

On that list, TDeint with EDI is decent, an even better choice would be yadifmod + nnedi (not on that list, but you could add it in the script manually)

Note the more filters, and higher quality settings that you use, the slower and slower this will be...

Poison, you are incredible with the speed that you respond to my noob questions.

I could not get the frameserve to work right so I just used a 1080i-60 m2t via Avisynth. I chose Yadif bob for the de-interlacer (even though now I see you say bob won't do well at that bitrate, I think it turned out ok) and lanczos for the resizer, and "heavy" noise filter (just guessing here).

I tried to duplicate all the settings in the MeGUI x264 config that you described, I saved it as the "poison" preset.

I am FLOORED by the results. Oh yeah, it probably helped that I went from 1600 to 2100kbps. I did a somewhat scientifc test where I watched one of my own HD videos on Youtube and tracked my network transfers while it was loading, did some arithmetic and figured YoutubeHD is 2Mbps... if they can do it so can I.

http://www.matthoover.com/1600vegas.mp4 (same one I posted yesterday)
http://www.matthoover.com/2100megui.mp4 (the one I just made)
http://www.matthoover.com/1080.m2t ("almost lossless" watermarked render from Vegas) - feel free to see if you can do better than my render, but I am pretty damn satisfied, it looks near perfect to me (although beer is impairing my judgment probably)... hard to believe it's only 2100kbps!

Only problem now is my megui mp4 is lacking sound. Have to figure that one out. GUI's are supposed to make things easier but I am having a heckuva hard time figuring out MeGUI. Though, it would be about 20x HARDER without you guys...

[The111]

Here's a suggestion. If you cam supports progressive, then try shooting in that mode on your next sky dive. After all, you are putting so much stress on that 1080, that a smaller frame size might do a little better, plus if its progressive, it will prob do much better. And, best of all, no deinterlacing necessary. That ought-to get you better results already.

Maybe throw up your cam's specs and all and someone with cam experience can help you make impovements.

-vhelp 5075

Good suggestion, worth looking into. It's a cheap consumer HDV cam (I'm no pro... though I do have footage airing on Discovery in a few weeks) - Sony HC5... not sure if progressive is an option but I'll look into it.

[poisondeathray]

Just a note on bobbing vs. (single rate) deinterlacing - your framerate is doubled when you bob, so at a given bitrate, each frame receives 1/2 of the bitrate it would if it was only deinterlaced at single rate (i.e. each frame will be lower quality, but the footage will be smoother at a given average bitrate). I would try both or playing with a few settings and come to a compromise that you're happy with

For audio, you can just plug in your .m2t into the audio section in megui, set the profile to HE-AAC (I used 64kbps in the sample earlier), it will spit out the audio, then you go to the tools menu and use the .mp4 muxer to multiplex vid & audio. You can also use other tools like YAMB to do this. Note, if you used DGIndex or the .d2v creator, use the option to split the audio track, and it will demultiplex with the audio delay written in the name. You would just plug in that audio then, instead of the .m2t (the delay will be entered automatically)

I've never had the guts to go skydiving but sure looks fun

[jagabo]

The drop field deinterlace I was refering to simply discards one field. You then resize what is left. It's a quick and easy deinterlace. With 1080i material that's being downsized to standard def this usually looks decent but it's to jagged if you are keeping the original resolution. None of the deinterlace methods in Megui corresponds to this.

Here's a quick CRF 22 encode with x264gui at 568x320 like your earlier low res files.

dropfield.mp4

MPEG2Source("1080.d2v")
ConvertToYUY2(interlaced=true)
SeparateFields()
SelectEvery(2,0)
BilinearResize(568,320)
ConvertToYV12()

The smart deinterlacers should do a little better, even at this small size. If you want to venture into your own AviSynth scripts, TempGaussMC_beta1() is the best deinterlacer. It's very slow though.

[The111]

Well, here are two completed videos with all the new settings. I'm so stoked with how good they look:

http://www.matthoover.com/gallery/skydiving-videos/Z-Flock_4.0-HD.html
http://www.matthoover.com/gallery/skydiving-videos/Puerto_Rico_2008-HD.html

Only thing fishy about them is I noticed that spinning props look funny (ex. 0:17 on the first video).

Also, a bigger issue I am running into (still minor, but it bothers me). Notice how BOTH videos have a small static "BLIP" at the beginning of the audio? This is driving me crazy! When I put out my 1080i m2t from Vegas to bring into MeGUI/Avisynth, it kept getting this blip on it even though it wasn't really present. So after 3 Vegas encodes I finally got it to come out clean, no blip. And then when I had MeGUI create the audio file mp4 to be muxed with the mp4, the blip came right back! So in other words, if Vegas doesn't put the blip there, then MeGUI does! How in the hell can I avoid this?

Also, I am having serious problems with my MeGUI queue processing, I leave it overnight to process several videos and it pauses for no reason after the first one, and then when I come back in the morning it resumes processing as soon as I move my mouse. This shouldn't be a windows/sleep issue... because I have torrent files usually active all night long, and they don't stop!

[poisondeathray]

Regarding the audio blip, what method did you use? (the demuxed audio or .m2t input)?

When you use DGIndex or (.d2v creator) the demuxed audio will have a delay value e.g. it might look like "AD T01 2_0ch 192Kbps DELAY 72ms.ac3" . When you input that demuxed audio, the delay of 72ms is inserted. Sometimes the null audio frames are incorrect and it reads as a "blip". So you can try either zeroing out the delay (there is a delay box in megui), or entering the delay (if it didn't automatically get entered) or try using the .m2t directly as input. You can also play with the audio configuration (try checking or unchecking directshow decode in the megui audio profile option)

If you can't get it working properly by fiddling with it, the safest/most consistent way to do this is to use a script, using NicAC3Source() / NicMPG123Source() for .mp2 - or related source filter - in an .avs script to serve. You can use audiodub() with the DelayAudio() command in the script, and preview the script in mpc for example to check if the blip is there.

Regarding the pause, I have no idea, maybe it's something with your system. At least it's not a crash I've left it running overnight many times without issues. Try disabling screensaver (I have screen turned off in windows after x minutes, but screensaver disabled)

Regarding the propeller, if you used a quick bob or low quality deinterlace method, they often leave deinterlacing artifacts. Also I noticed you went back to single rate deinterlacing (29.97 fps), so 1/2 the temporal resolution is thrown out - things aren't as smooth with fast moving objects like properllers. Check out the tempgaussmc_beta1 that jagabo suggested earlier. Its about 10-15x slower than the yadif bob, but the quality is amazing). But I agree with your choice to not bob it, it would take too much bandwidth to make it look good.

You can check out the bobber comparison that soopafresh posted a while back, originally done by didee. The remenant deinterlacing artifacts (jaggies) combine to shimmer or interline twitter

https://forum.videohelp.com/images/guides/p1934885/stockholma_0-520_q3_yadif_mvbobmod_t...mca4_tdtmm.avi

[The111]

Regarding the audio blip, what method did you use? (the demuxed audio or .m2t input)?

I used m2t input with MeGUI for mp4 output. Then I muxed mp4 video and mp4 audio.

When you use DGIndex or (.d2v creator) the demuxed audio will have a delay value e.g. it might look like "AD T01 2_0ch 192Kbps DELAY 72ms.ac3" . When you input that demuxed audio, the delay of 72ms is inserted. Sometimes the null audio frames are incorrect and it reads as a "blip". So you can try either zeroing out the delay (there is a delay box in megui), or entering the delay (if it didn't automatically get entered) or try using the .m2t directly as input. You can also play with the audio configuration (try checking or unchecking directshow decode in the megui audio profile option)
If you can't get it working properly by fiddling with it, the safest/most consistent way to do this is to use a script, using NicAC3Source() / NicMPG123Source() for .mp2 - or related source filter - in an .avs script to serve. You can use audiodub() with the DelayAudio() command in the script, and preview the script in mpc for example to check if the blip is there.

Hmm, a lot of that is Greek to me. You mention AVS which I am somewhat familiar with now, I guess I could have the AVS include audio and then input that (instead of the m2t) into MeGUI?

Regarding the pause, I have no idea, maybe it's something with your system. At least it's not a crash I've left it running overnight many times without issues. Try disabling screensaver (I have screen turned off in windows after x minutes, but screensaver disabled)

Yeh, it's a puzzle. The weirdest thing is it will run for 3-4 hours fine before it pauses, and I checked all my settings and even if I did have anything set to turn off (screen, HDD, etc), it would be 60 minutes or less usually.

Regarding the propeller, if you used a quick bob or low quality deinterlace method, they often leave deinterlacing artifacts. Also I noticed you went back to single rate deinterlacing (29.97 fps), so 1/2 the temporal resolution is thrown out - things aren't as smooth with fast moving objects like properllers. Check out the tempgaussmc_beta1 that jagabo suggested earlier. Its about 10-15x slower than the yadif bob, but the quality is amazing). But I agree with your choice to not bob it, it would take too much bandwidth to make it look good.

I used TDeint with EDI as you recommended. Yeh, I chose to keep it at 30fps, I can definitely notice it's less smooth, but crisper. That tempgauss thing you mention, I didn't see it in the list so I'm not sure how to use it but I'm guessing I have to add it manually somehow? But if it takes 10x longer for the entire encode (that is insane!) I might have to skip it for now. I have like 15 different 5 minute videos I'm trying to encode and each one takes like 2 hours currently. Multiply that by 10 and I'm in for weeks of encoding! Plus it's not like I have the props in my footage that often...

[poisondeathray]

For the audio blip, the first and easiest thing I would try , is to use the .d2v creator (it's based on DGIndex), but select demux all audio tracks. Then input that demuxed audio directly into the audio section, you will note the delay will be automatically entered in the lower right corner.

If that doesn't work, try checkmarking "force directshow decode" in the audio option config, while using the original .m2t as audio input.

Can you also post the .avs script that megui generated

[The111]

Can you also post the .avs script that megui generated

Yeh, I'll post that later on tonight. I do know that it didn't include audio though. There was an "audio=false" line.

The most puzzling thing to me is that Vegas created that same blip (2 out of 3 times) when generating the m2t (video+audio combined), and it has never done that before. When I finally got it to NOT create the blip, then the blip just re-surfaced at the next step.

I am wondering if my drivers/codecs are screwed up because of how much crap I have installed in the past few days trying different things. I know for a fact that something is wrong because some old 480p avi's (NTSC DV widescreen) that I have won't display with the proper pixel aspect ratio. I was thinking of trying to wipe all my codecs and start over if I could.

[poisondeathray]

Well the blip might still be there, just hidden; check it by playing the demuxed audio in a media player. If there is no blip, then it's possible that the delay (or lack of delay) might be causing it

[jagabo]

The problem with the prop is from TDeint(). Here's a crop from a TDeint() of the M2T file you uploaded:

The smart deinterlacers often have problems like this. Yadif() did better on that particular subject:

And yes, TempGaussMC_beta1() will take 20 times longer to render.

[The111]

Well, now I am trying to de-interlace some older footage I have, NTSC DV Widescreen, 720x480.

http://www.matthoover.com/deint-test.avi

Using any of the methods available in AVIsynth, this ends up with funny "squiggles" all over the screen. It's actually part of a larger project sourced with many similar AVI's, and none of them have a problem, but this one does for some reason. It is interlaced, lower field first.

The ONE method that would work in AVS for this is called "field deinterlace" but I don't know if that is as good as the TDIeint (with EDI) one that I've been using...

[poisondeathray]

^there is horrible blending in that footage, and even the individual fields have squiggies when you use separatefields() - therefore you will not get good results with any deinterlacer. You would be better off starting with the unprocessed original footage

[The111]

Once again I must commend you on your quick responses.

As far as I know (and I could certainly be wrong), that IS unprocessed.

The Vegas project is sourced from avi's (captured from DV tape). I am having Vegas output another avi, with all settings I could find to not de-interlace at all. De-interlace on the project is set to "none." On the output it's set to lower field first (same as source). So what is this blending you refer to?

[poisondeathray]

When you separate the fields (not frames) , each should be clear & distinct. The majority of that footage is not. You have 1 or 2 fields that look semi-normal (1st pic) , the majority is not (2nd pic) it looks as if part of the previous and current frame are combined or blended. Whatever processing method was applied has destroyed the fields, and this will be next to impossible to recover.

[The111]

Well, the only thing that I can think is that when I archived my original projects, I had Vegas output time-cropped avi segments to save space. Maybe there was a de-interlace project setting since I didn't know much back then, and that's where it came from.

I can eventually dig up the ORIGINAL source footage and re-do my projects, but that's buried even deeper.

For now if I check "reduce interlace flicker" on the problematic clips, it will get rid of the squiggles... not optimal, but good enough for now.

Thanks.

[jagabo]

I suspect that frame size of that SD video was changed. That would have caused the mixed field problem. Maybe you had 4:3 DV AVI and converted it to 16:9 DV AVI by cropping it down to 720x360 and stretching it back up to 720x480?

A blend deinterlace is about the best you can do with that mangled video.

[The111]

I suspect that frame size of that SD video was changed. That would have caused the mixed field problem. Maybe you had 4:3 DV AVI and converted it to 16:9 DV AVI by cropping it down to 720x360 and stretching it back up to 720x480?

A blend deinterlace is about the best you can do with that mangled video.

Haha, I just figured this out myself 5 minutes ago and came in to post! Good thinking.

This one example that I posted is actually a 16:9 source, but cropped a bit in the original edit for framing. I have some other places though where it is actually a 4:3 source that I obtained from a different camera, as you guessed.

So in these cases my best bet it to take the crappy blend de-int out of Vegas and be happy with that?

I wonder, if in the distant future, a better long-term solution would be to find the original source footage, de-interlace it ahead of time, and THEN insert (as 480p) into the editing project to be cropped? So I'm cropping straight frames rather than interlaced fields.

[jagabo]

So in these cases my best bet it to take the crappy blend de-int out of Vegas and be happy with that?

I don't think you can do much better than that with that mangled video.

I wonder, if in the distant future, a better long-term solution would be to find the original source footage, de-interlace it ahead of time, and THEN insert (as 480p) into the editing project to be cropped? So I'm cropping straight frames rather than interlaced fields.

Yes.