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

[The111]

Check out my sample gallery here:

http://www.matthoover.com/gallery/skydiving-videos/

The "Watch (standard)" links take you to 568x320, 500kbps (vid) H.264 mp4.
The "Watch (HD)" links take you to 1280x720, 1.6Mbps (vid) H.264 mp4.

I am pretty happy with how the 720p version looks, but I think the 320p version looks crappy, mainly it has lots of large "blocky" artifacts. I am aware that 320p 500kbps is never going to look great, but I think this is as high bitrate (if not better) than what Youtube uses for 320p, and I don't usually see the huge blocky artifacts on Youtube. Even the 720p version I think has a little too much blockiness, compared to Vimeo or something with similar bitrate.

I am using Sony Vegas AVC render option to make my mp4 files. I choose the "use deblocking filter" option (not sure what that is, but it seems like it should help?) and also "number of reference frames" =1 (not sure what that is either).

What else can I do to make it look better at the chosen res and bitrate?

Thanks!

[jagabo]

Are you using multi-pass encoding?

[The111]

Yes, I selected "two-pass" (the only option) and also it is VBR, 500kbps avg, 1500kbps max.

How does the quality look in your opinion?

Thanks for the reply!

[jagabo]

The secrets to using low bitrates are to have as little noise and as little motion as possible. The high motion in your videos makes them hard to compress.

Make sure your h.264 decoder has deblocking enabled.

h.264 (CoreAVC) deblocking disabled:


deblocking enabled:


disabled:


enabled:

[The111]

The secrets to using low bitrates are to have as little noise and as little motion as possible. The high motion in your videos makes them hard to compress.

Yeh, I sort of thought the motion might be part of it.

But... I have put similar videos on Youtube before and they don't look so blocky.

[The111]

Make sure your h.264 decoder has deblocking enabled.

Wow, awesome find... those screenshots look much better!

Any more specific tips how to accomplish that? I'm a noob. I'm using Vegas, and I do have the "use deblocking filter" checked. What do you mean by "decoder"? Should I use something other than Vegas?

[edDV]

It is all about motion. A still looks great at 100Kb/s after it settles.

A tripod limits the number of pixels in motion at any time.

[poisondeathray]

In the options select video rendering quality: best, increase the reference frames to 3, do 2pass instead of vbr, for profile select Main instead of Baseline

Unfortunately the encoder that comes with Vegas is quite limited. It's a licensed version of Mainconcept's h.264 encoder, but limited in terms of settings and functionality. If you were to export out using lossless then used a better encoder (e.g. x264 encoder) with better settings you would get improved results.

[The111]

Unfortunately the encoder that comes with Vegas is quite limited. It's a licensed version of Mainconcept's h.264 encoder, but limited in terms of settings and functionality. If you were to export out using lossless then used a better encoder (e.g. x264 encoder) with better settings you would get improved results.

I was kind of wondering if that was the case. I will definitely try to use one of those other tools then, on a lossless m2t, because good end quality is pretty important to me. Any time I've tried other tools though, there are usually so many options that I get overwhelmed. Any basic words of advice on choosing all the output options? Any GUI to recommend for the x264?

Thanks so much for all the good replies!

[poisondeathray]

Actually on closer examination (the streaming video is downloaded to the temp internet directory) , it has to do with the way your application resizes the video and the display settings - it is using a poor quality resizer, and as jagabo pointed out, the deblocking isn't working as it should be. The combination of the 2 is making this look bad

The settings and encoder do play a role, but less so in this case. These are png lossless captures, so not from jpg compression artifacts. The blocks and artifacting are clear near the plane wing

1: This is directly from your web application viewed "as is". Every frame has resizing artifacts and poor antialiasing from the bad resize


2: This is directly from the downloaded video. This is how it should look and does look natively


3: This is resized using a decent resizer (Spline36)


There must be something on the server side/application that is not set properly.

Once you get the 1st problem solved regarding blocking/resizing upon viewing, you can look at farther improving quality at low bitrates using x264. As for GUI's for x264, there are plenty. Xvid4PSP, ripbot264, MeGUI, Handbrake, dozens more... Most of them have presets and profiles which make things easier. This way you are not limited to just "main" profile (you can use "high"), and have many more settings you can customize.

[The111]

So if I play the video on the web player at anything other than native res, I should scale first using spline36? Where do I find that?

It's a shame the video player doesn't scale very good... it's the best open source one I've found.

[poisondeathray]

I resized in avisynth, I don't know if your player has different resize functions.

JW is a good player, but I don't know how the resize functions are, or the quality of the resize.

If you display as normal (not stretched) , it looks better, but there are still artifacts there - something is seriously wrong with that application. (not just the resize, but even the normal display is screwy)

viewed in your web application, native size: (notice blocking in the trees)


viewed as it should be:


So jagabo is correct. The deblock settings in the player look like they are off, and when resized, the remaining blocky pixellation gets worse.

I would give JW Player a shot. It's free for personal use (tiny fee if you have advertising on your site)

[jagabo]

I'm not sure exactly how embeded flash players like that work. I suspect there will be some settings at the server side that control deblocking and scaling algorithms (during playback on the user's computer). These may be disabled by default to minimize CPU usage on the viewer's computer.

The sample images I posted earlier were after downloading the FLV file and using MPCHC to playback and save. From MPCHC I could control what h.264 decoder was used and it's easy to turn the deblocker off and on.

[minidv2dvd]

the jw player should be set to the actual size of the video, it shouldn't be asked to re-size at all. the 400 and 300 being the dimensions - "var s1 = new SWFObject('player.swf','player','400','300','9');" the 9 being the lowest version of adobe flash player required to play the video. the actual player is adobe flash player, jw just embeds code to display the video on your webpage. i would assume all web based players are pretty much the same.

[jagabo]

swfobject.embedSWF('http://www.matthoover.com/ovp/AkamaiFlashPlayer.swf', 'myPlayerGoesHere', '656', '407', '10.0.0'

This appears to open some front end to the default Flash Player? Right clicking on the video shows scaling options like "native" and "stretch" (not algorithm though). Viewing youtube videos at non-native resolution doesn't seem to have the same scaling problem (point resizing vs. bilinear resizing).

[The111]

There must be something on the server side/application that is not set properly.

Once you get the 1st problem solved regarding blocking/resizing upon viewing, you can look at farther improving quality at low bitrates using x264. As for GUI's for x264, there are plenty. Xvid4PSP, ripbot264, MeGUI, Handbrake, dozens more... Most of them have presets and profiles which make things easier. This way you are not limited to just "main" profile (you can use "high"), and have many more settings you can customize.

Yeh, you guys were all right about the video player scaling poorly. I've played around with JW FLV player a bit now and am much happier with it. However, I do still have to address the original encoding problem.

I tried quite a few of those x264 GUI's and was overwhelmed by most of them, and couldn't get an improvement. I used another program called "MediaCoder" and by setting de-blocking to "strong" in the x264 settings, it did a good job of getting rid of the blocking in the blue sky (see samples below). But now other parts of the video look worse (the watermark, for example, is all grainy).

6 second sample:
source: http://www.matthoover.com/block-test-source.m2t
vegas render: http://www.matthoover.com/block-test-vegas.mp4 (notice the blocking)
mediacoder render: http://www.matthoover.com/block-test-mc.mp4 (blocking reduced, but quality decreased in other ways)

[The111]

the jw player should be set to the actual size of the video, it shouldn't be asked to re-size at all. the 400 and 300 being the dimensions - "var s1 = new SWFObject('player.swf','player','400','300','9');" the 9 being the lowest version of adobe flash player required to play the video. the actual player is adobe flash player, jw just embeds code to display the video on your webpage. i would assume all web based players are pretty much the same.

I wish that were the case, but using another web player I don't get player-introduced-blocking.

[jagabo]

You need to ~double your bitrate to get decent results.

I'd also recommend using a drop field deinterlacer instead of a blend deinterlacer to go from 1080i30 to 720p30 or lower resolution. That will get rid of the double exposure look.

[The111]

You need to ~double your bitrate to get decent results.

I'd also recommend using a drop field deinterlacer instead of a blend deinterlacer to go from 1080i30 to 720p30 or lower resolution. That will get rid of the double exposure look.

Thanks for getting back to me again jagabo.

I guess I'd chosen 1600kbps because I read somewhere that's what Vimeo and YoutubeHD used. I want a reasonable bitrate for people with average internet connections to stream... 3M seems a bit high although I'm sure it would look better.

Good info about the de-interlacing, I do see the effect you're talking about. I'm using Vegas to put out the 720p30, and the only de-interlace options there are "blend" and "interpolate"... is interpolate the same as drop field? Or should I also be doing the de-interlacing in a more fully featured encoder than Vegas? I guess I could take the 1080i30 source straight into MeGUI and do the de-interlacing there.

[poisondeathray]

That isn't your original source, is it? It already has a watermark and has been processed already with a poor deinterlacing method - you can see field blends / double images. Since it has been already re-encoded, it already has 1 generation of quality loss - you want to avoid this - it gets worse each time. I would re-evaluate your process.

It would be better to do everything with 1 encode. What kind of editing are you doing in vegas (i.e. is there some type of nonlinear or special editing that requires you to use vegas? music overlay?). One option is to frameserve out losslessly with debugmode frameserver, or to export lossless (e.g lagarith). If you don't have complex edits, you can do everything in avisynth and feed directly into the encoder

For deinterlacing - bobbing would be ideal for high action/ sports footage - it will be much smoother, but it will require more bitrate with same image quality because of 2x the number of frames. What method are you currently using to generate the blends? Also a better deinterlacing method will reduce the bitrate requirement, because it leaves fewer "jaggies". This will improve the picture quality, but good deinterlacing methods are very cpu intensive . But there is no question you will get better deinterlacing results using avisynth methods rather than vegas.

Jagabo mentioned this, but for low bitrates, pre-processing with denoising filters is a must. This will reduce the bitrate requirement

Your settings used were low quality (for both vegas, and mediacoder). To get the most of low bitrate scenario, you need to use high quality settings to maximize compression. Increase the reference frames (you used only 1), increase the deblocking (I used 1,1), Turn off psy-rd (it can cause ringing , especially at low bitrates similar to the ringing around the logo), increase the b-frames to 3 or 4 (if you are using b-adapt 2), increase subme to 9. If you used mediainfo (view=>text) you can get the detailed information on the settings I used. Basically in MeGUI, it was the "unrestricted 2pass EQ" profile with the modifications I listed.

You can "cheat" by using more compressed audio. Use AAC-HE. The bitrate savings can go into improving the video quality. You can listen to the sample provided, it's lest than 1/2 of the bitrate you used, but still good quality for streaming purposes.

Maybe you can post the original source + bmp or png logo?

Here is your sample with better settings. It was also preprocessed with a simple denoising filter Deen(). I used 1700kbps video and 64kbps audio - the overall bitrate is actually less than the samples you provided. It's only 5 seconds; I cut the last few frames out, your sample had some errors in it. You can see the nasty blocking seen from the vegas sample is gone, and the ringing around the logo is mostly gone. With a better process, I'm sure you could improve it.

better%20settings.mp4

[The111]

That isn't your original source, is it? It already has a watermark and has been processed already with a poor deinterlacing method - you can see field blends / double images. Since it has been already re-encoded, it already has 1 generation of quality loss - you want to avoid this - it gets worse each time. I would re-evaluate your process.

Ok, good points. Jagabo caught me on the same thing. I'll admit I didn't know what de-interlacing option to choose so I just chose a random one in Vegas. Later on today when I get home I'll try to post up a "less re-encoded" version.

It would be better to do everything with 1 encode. What kind of editing are you doing in vegas (i.e. is there some type of nonlinear or special editing that requires you to use vegas? music overlay?). One option is to frameserve out losslessly with debugmode frameserver, or to export lossless (e.g lagarith). If you don't have complex edits, you can do everything in avisynth and feed directly into the encoder

Well, I have quite a few long (somewhat complex) editing projects already archived in Vegas, and I am pretty set on sticking with that. I have the original (HDV-1080-60i) footage still archived and sourcing the Vegas projects. I can put out a HDV-1080-60i .m2t render of the entire project, which will essentially be the same quality as the tapes I pulled the original footage off, right? And then take the 60i into Avisynth to de-interlace, de-noise, and prep for MeGUI, right?

For deinterlacing - bobbing would be ideal for high action/ sports footage - it will be much smoother, but it will require more bitrate with same image quality because of 2x the number of frames. What method are you currently using to generate the blends? Also a better deinterlacing method will reduce the bitrate requirement, because it leaves fewer "jaggies". This will improve the picture quality, but good deinterlacing methods are very cpu intensive . But there is no question you will get better deinterlacing results using avisynth methods rather than vegas.

I used "blend" which Jagabo also recommended against. I'll try again at home with bobbing if that option exists in Avisynth or MeGUI (Vegas only had two options, blend and interpolate).

Jagabo mentioned this, but for low bitrates, pre-processing with denoising filters is a must. This will reduce the bitrate requirement
Your settings used were low quality (for both vegas, and mediacoder). To get the most of low bitrate scenario, you need to use high quality settings to maximize compression. Increase the reference frames (you used only 1), increase the deblocking (I used 1,1), Turn off psy-rd (it can cause ringing , especially at low bitrates similar to the ringing around the logo), increase the b-frames to 3 or 4 (if you are using b-adapt 2), increase subme to 9. If you used mediainfo (view=>text) you can get the detailed information on the settings I used. Basically in MeGUI, it was the "unrestricted 2pass EQ" profile with the modifications I listed.

You can "cheat" by using more compressed audio. Use AAC-HE. The bitrate savings can go into improving the video quality. You can listen to the sample provided, it's lest than 1/2 of the bitrate you used, but still good quality for streaming purposes.

Thanks very very much for posting all those details, can't wait to try it out later.

Maybe you can post the original source + bmp or png logo?

Here is your sample with better settings. It was also preprocessed with a simple denoising filter Deen(). I used 1700kbps video and 64kbps audio - the overall bitrate is actually less than the samples you provided. It's only 5 seconds; I cut the last few frames out, your sample had some errors in it. You can see the nasty blocking seen from the vegas sample is gone, and the ringing around the logo is mostly gone. With a better process, I'm sure you could improve it.

better%20settings.mp4

Yeh, I'll post up a lossless 1080-60i .m2t render later if that is good enough. Can't even view your mp4 on the PC I'm on right now but can't wait to check it out. Thanks again!

[poisondeathray]

The vegas .m2t export render isn't lossless; it uses MPEG2 compression, and subject to compression artifacts

Truly lossless would be rendering as lagarith avi, or huffyuv avi, but the filesize would be huge. Thus, the recommendation for using frameserving methods out of vegas (i.e. debugmode frameserver) when you do the actual project

[The111]

The vegas .m2t export render isn't lossless; it uses MPEG2 compression, and subject to compression artifacts

When I capture my HDV from the camera tapes it's already M2T, so isn't it already MPEG2 compressed? When I render a Vegas project (comprised of many M2T clips and effects), to one long M2T, through many sections it speeds along and says "no recompression needed." It only slows down and "thinks" when it gets to sections of my timeline where I have used advanced effects.

[poisondeathray]

Yes the original footage has MPEG2 compression, but once you re-encode, the quality gets worse

OK, so Vegas might be doing "smart rendering" ( only re-encoding those sections with special effects/transitions, leaving the rest untouched) , but if you add a logo with vegas it will re-encode the entire thing, so the entire sequence will lose quality on export (you didn't mention how the logo overlay was done). For uploading sample purposes, this is the only way, but when you do the actual project you should stick with lossless methods as much as possible

If you frameserve out, it doesn't even re-encode those sections, so you don't even get quality loss in those segments or anywhere at all, only on the loss caused by the final encode. Basically this allows you to render your effects in vegas and use a better encoder with avisynth processing in between, without the big intermediate file. All you have is a "dummy avi" file that is 1 or 2 KB in size.

The other area where you will lose quality is the internal colorspace conversion done by vegas. You have YV12 input with your camera, it converts to studio RGB internally, and the final format is YV12. Each conversion will lose a tiny bit of quality. Premiere doesn't suffer from this AFAIK. I know you have archived projects in vegas, but if you were to do everything in avisynth and kept YV12, you wouldn't suffer from this either. Also, be careful on the project settings when using vegas 8; the way it handles the gamma and levels for different inputs is different than vegas 7. For Vegas 8, it changes depending on the kind of input (e.g. mpeg2 as in what you are using .m2t, vs. lagarith, etc...) and whether you use 8-bit or 32-bit project settings.

The colorspace, levels, and gamma issues are very confusing to me...I experienced this the hard way by doing some projects and noticing that the colors and brightness were off when using vegas. I have several excellent links bookmarked where edDV and jagabo explain the stuff. As edDV suggests in the link, the best way is to go thru some test samples with a belle nuit or similar chart.

http://www.glennchan.info/articles/vegas/v8color/v8color.htm
https://forum.videohelp.com/topic352511.html
https://forum.videohelp.com/topic342710.html

[The111]

That all makes some sense to me, but it is a bit more than I have the time to get into right now. I may look into all that stuff in the future, but for now I am just trying to get rid of the blockiness. I do appreciate all the info though, and I will certainly read up on all your links. I've been a still photographer for 3+ years and still haven't got around to learning all I need about color calibration and actually calibrating all my hardware. Adding that same level of attention to my videos is even further down on my list, but I do recognize the importance.

I'll see if I can get frameserv to work tonight, but if it's too much for me to figure out, then for now I'll just stick with a 1080-60i (already watermarked) m2t from Vegas before taking it into MeGUI... even if there is a slight loss in there, I can live with it I think... it's the huge losses when going to low bitrate mp4 that are really hurting me here.

[jagabo]

A tripod limits the number of pixels in motion at any time.

Not while sky diving! LOL

[The111]

A tripod limits the number of pixels in motion at any time.

Not while sky diving! LOL

Haha, good find, I was meaning to comment on that myself. Next time you think it's hard holding a camera steady with two hands while standing on the ground... try it in freefall with 10 pounds cantilevered off of your neck.

[The111]

For deinterlacing - bobbing would be ideal for high action/ sports footage - it will be much smoother, but it will require more bitrate with same image quality because of 2x the number of frames.

The options in MeGUI AviSynth script creator are:
Yadif
Yadif (with Bob)
TDeint (with Bob)
TDeint (with EDI)
TDeint (with EDI + Bob)
LeakKernelDeint
TomsMoComp
FieldDeinterlace
FieldDeinterlace (no blend)

In this thread it's been suggested that I use a drop field deinterlacer, and (by you) that I use bobbing. Not sure how to translate that to the above options...

[poisondeathray]

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...

[vhelp]

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