Thanks a lot Fred! That's very helpful

"Now here is the YouTube version of my MainConcept AVC render from Sony Vegas 10.0c. I'm calling this "Test 2"."

Your x264 version appears quite a bit sharper, but I see almost no difference in color. I tend to be more suspect of bicubic and interpolate as the culprits, rather than Mainconcept itself at that healthy bitrate.

Apart from Jerry's blocky frame and slopey grass frame, I've been making judgements using the following frame in particular, which shows differences in detail, deinterlacing/decombing (and also a loss of orange in the car's indicator light in x264):



I was going to post a bunch of stills from different versions but really the only way to judge these is to get them all lined up on the timeline at best/full/unscaled and compare by muting tracks.

Round-Up So Far

I'll be off the forum from tomorrow until next weekend, so, for anyone still awake, here's a round-up of my observations so far. Note that my testing has been all about uploading to 3rd-party video hosts, not rendering finished files for self-hosting. Note also that I tweaked each method to be as near as possible to 8 Mbps video stream and 320 Kbps audio stream in order to make meaningful comparisons.

1. Uploaded videos should conform to Studio RGB, 16-235, because their luma will be expanded to Computer RGB 0-255 on playback.
2. Vegas 10.0c does not expand the luma of an AVC video it decodes, whereas 8.0c does.
3. In Vegas 10.0c, Sony AVC 8 Mbps (as per internet template) is actually only 5.8 Mbps. You need to ask for 11 Mbps to get 8 Mbps. It's fast (14 mins) and actually pretty good. My feeling (based on memory) is it's better than the old version in Vegas 7/8 but I haven't tested them side-by-side.
4. Quality comparisons in files downloaded from YouTube are extremely difficult. The framerate is variable so the frames don't quantize on the timeline. Plus, the quality is just too woolly to make precise judgements.
5. In Vegas 10.0c, MainConcept AVC 2-pass VBR is no better to my eyes than Sony AVC (very possibly worse), and much slower (52 mins). May as well use Sony AVC. From memory, the same applied to Vegas 7/8
6. TDeint/Lanczos3/x264/CQ19.6 done in AviSynth/MeGUI gives more detail and very slightly smoother deinterlacing than the Vegas AVC encoders with "Interpolate Fields" deinterlacing. Medium render speed (34 mins). Worth using ahead of Sony AVC for better quality if you have the time and patience.
7. Decomb/Lanczos3/x264/CQ20.5 done in Handbrake gives similar detail to the MeGUI method and very slightly smoother deinterlacing/decombing again. Render is pretty fast (14 mins) but the preceding DNxHD render would likely be around 30 mins on my machine, so the total workflow is relatively slow. Probably just has the edge over MeGUI for quality-critical material.
8. "Uneven Multi-Hexagon" motion estimation in Handbrake is little different from "Hexagon" and not really sharper. I did a like-for-like test.
9. Facebook gives marginally my favourite quality, but can only be embedded at low res, and without a facebook account, that's all you can watch. Good for private videos.
10. Vimeo gives the next nicest quality (it's close) and in my experience, fast download, but slight stuttering for some viewers.
11. YouTube gives poorest quality. Every YouTube version so far is horribly blocky in transitions. It seems there's no avoiding this.

Copies of my UPloaded files (available for a while):

Test 1 (MeGUI TDeint x264) -
(info from Mediainfo and AviNaptic).

Online (lots of details about the render method in the online video descriptions):

Test 1 (MeGUI TDeint x264):
Facebook - [url=http://www.facebook.com/video/video.php?v=497394492745]
Vimeo - [url=http://vimeo.com/19356182]
YouTube -

Test 2 (Vegas 10 MainConcept AVC):
Vimeo - [url=http://vimeo.com/19388499]
YouTube -

Test 3 (Vegas 10 Sony AVC):
Vimeo - [url=http://vimeo.com/19411685]
YouTube -

Test 4 (Handbrake x264):
Vimeo - [url=http://vimeo.com/19413015]
YouTube -

Still to do:

1. Get tests 3 and 4 up on Vimeo.
2. Try Vegas/Framserver/VirtualDub/Smart Deinterlace (edge-directed interpolate)/Lanczos3/x264VFW.
3. See if CBR can help the blockiness in YouTube transitions (but only MC seems to have a CBR option).
4. Maybe try the Mike Crash smart deinterlacer inside Vegas with Sony AVC.
5. Maybe try Lanczos4 instead of Lanczos3 in AviSynth script.
6. Maybe experiment with x264 deblocking values.
7. Attempt to match Handbrake's decomb in an AviSynth script for MeGUI (Tough! Mr Meyer Sir, are you around?).
8. Publish my MeGUI tutorial.

OK, I need a break now.

By the way, the guitar player deinterlace shootout is a great idea! But we need to squeeze my underwater CC challenge in somewhere too!

p.s. I suggest no more linked YouTube vids in this thread, to keep it usable. I may go back and unlink mine.

Nick, I will post tests 3 and 4 to Vimeo tonight. Thanks again for what you are doing.

I will edit this post to give the Vimeo URLs.

Edit:

Vimeo Render test 3:
http://vimeo.com/19411685

Vimeo Render test 4:
http://vimeo.com/19413015

Fred

Thanks again Fred. I edited my post to add those links.

Anyone agree, disagree, or add to my observations? I don't have the best monitoring situation here at the moment, so my judgements might not be as clear as others'.

"Anyone agree, disagree, or add to my observations? I don't have the best monitoring situation here at the moment, so my judgements might not be as clear as others'."Nick, first let me compliment you on the excellent job of analysis you've done on this project (worthy of comparison to a JohnMeyer analysis!!).

Now, to answer your question. You make the following statement: "5. In Vegas 10.0c, MainConcept AVC 2-pass VBR is no better to my eyes than Sony AVC (very possibly worse), and much slower (52 mins)." I'm sure this is a true statement at the high bitrates you've used when rendering, however, my tests indicate that the MainConcept encoder wins hands-down at low bitrates. Here's a screencapture.



...Jerry

Nick, Let me be the second to congratulate you on a scholarly look at this. You have taken the discussion to the next level, and those who care to dig below the surface will benefit immensely.

8. "Uneven Multi-Hexagon" motion estimation in Handbrake is little different from "Hexagon" and not really sharper.

Having used my original 8Mbs Handbrake settings, the differences in motion detail (not static detail) are noticeable to me, moreso during actual playback. As I mentioned a couple of times, sharper is not necessarily better, and some people prefer the smoother motion that hex ME offers. Personally, I prefer the sharper motion detail that umh offers, at least for web delivery. Look at the grass in the upper corners, as well as the bird's back.
NOTE: Although both are the same frame, the bird on the right actually appears "fatter" because of greater lateral motion blur.

1:1, no sharpen added. Right-click and "View Image"

Somebody straighten me out! Two posts above I compared the MainConcept and Sony AVC encoders at 1Mbps. I made an assumption with the Sony AVC encoder: since I was not able to specify VBR and I was able to specify a single bitrate, that my render would a Constant bitrate (CBR). However, the following is what MediaInfo reports:

Video

"What gives with the variable bitrate?"

...Jerry

"7. Decomb/Lanczos3/x264/CQ20.5 done in Handbrake gives similar detail to the MeGUI method and very slightly smoother deinterlacing/decombing again. Probably just has the edge over MeGUI for quality-critical material."

That -- is a remarkable statement.

The Handbrake devs are going to post their preset numbers for 0.9.5 in the wiki soon; I will be sure to post them here. They use three different deinterlace methods (mod yadif, EED12, and McDeint) in combination and in a specific order, but not TDeint yet.

Just a note to those who may tend to interchange the terms "luma" and "luminance".

Luma is gamma weighted. Luminance is not.
Vegas reports Luminance in its scopes because it converts everything to linear RGB.
That's the best of my understanding at this time.
Still waiting for a Glenn Chan visitation . . .

FWIW, here is the current Handbrake default decomb parameter string.
If you click "Custom" a box comes up where you can input your own number string.
But you'd best know what you're doing first (I don't).

    -5, --decomb            Selectively deinterlaces when it detects combing

          <MO:ME:MT:ST:BT:BX:BY:MG:VA:LA:DI:ER:NO:MD:PP:FD>

          (default: 7:2:6:9:80:16:16:10:20:20:4:2:50:24:1:-1)

12	/*****

13	Parameters:

14	    Mode : Spatial metric : Motion thresh : Spatial thresh : Block thresh :

15	    Block width : Block height

16	

17	Appended for EEDI2:

18	    Magnitude thresh : Variance thresh : Laplacian thresh : Dilation thresh :

19	    Erosion thresh : Noise thresh : Max search distance : Post-processing

20	

21	Plus:

22	    Parity

23	   

24	Defaults:

25	    7:2:6:9:80:16:16:10:20:20:4:2:50:24:1:-1

26	*****/

27	

28	#define MODE_YADIF       1 // Use yadif

29	#define MODE_BLEND       2 // Use blending interpolation

30	#define MODE_CUBIC       4 // Use cubic interpolation

31	#define MODE_EEDI2       8 // Use EEDI2 interpolation

32	#define MODE_MCDEINT    16 // Post-process with mcdeint

33	#define MODE_MASK       32 // Output combing masks instead of pictures

34	

35	/*****

36	These modes can be layered. For example, Yadif (1) + EEDI2 (8) = 9,

37	which will feed EEDI2 interpolations to yadif.

38	

39	** Working combos:

40	 1: Just yadif

41	 2: Just blend

42	 3: Switch between yadif and blend

43	 4: Just cubic interpolate

44	 5: Cubic->yadif

45	 6: Switch between cubic and blend

46	 7: Switch between cubic->yadif and blend

47	 8: Just EEDI2 interpolate

48	 9: EEDI2->yadif

49	10: Switch between EEDI2 and blend

50	11: Switch between EEDI2->yadif and blend

51	17: Yadif->mcdeint

52	18: Blend->mcdeint

53	19: Switch between blending and yadif -> mcdeint

54	20: Cubic->mdeint

55	21: Cubic->yadif->mcdeint

56	22: Cubic or blend -> mcdeint

57	23: Cubic->yadif or blend -> mcdeint

58	24: EEDI2->mcdeint

59	25: EEDI2->yadif->mcdeint

60	...okay I'm getting bored now listing all these different modes

61	32: Passes through the combing mask for every combed frame (white for combed pixels, otherwise black)

62	33+: Overlay the combing mask for every combed frame on top of the filtered output (white for combed pixels)

63	

64	12-15: EEDI2 will override cubic interpolation

65	16: DOES NOT WORK BY ITSELF-- mcdeint needs to be fed by another deinterlacer

66	*****/

Guys, I'm totally snowed under with other stuff at the moment. Will try and get back on this topic in a few days when things calm down. Cheers

Snowed under in Thailand?

Here is the view from my front door this morning. Car hasn't started in two days.


Will look forward to your return to the forum.
;?)

Hi all,
Source footage : 1440 x 1080, 50i, 25 mbps
I want to prepare some them for my future website!

Which one to chose??
mp4, 720p
mp4, 1920 x 1080, 25p
mpeg2, 1440 x 1080 but low bitrate??
maybe divx?

or any other advice please:)

"or any other advice please"First, if the following response results in several questions, I would suggest creating a new thread (as much as I'd like to see the post count get to 200!!).

That said, the first thing I'd suggest is to (eventually) get your from interlaced to progressive for web broadcast. As a general rule, I'd try to keep the framerate the same as your source (25fps?).

That said, there several questions you should ask your self. Want to take the easy way out? Upload the video to YouTube or Vimeo or ?? and embed the video in your website. Seems like consensus is that Vimeo produces better quality. Suggest you go to their websites for recommended render params.

If you want to host your own videos, then you should ask yourself some further questions. What is the framesize you will display your video? Will users want to view the clips in high quality fullscreen? What about the bandwidth of your user community?

Once you've answered those questions, I've found that rendering your Vegas Project to an interlaced format with same rez as the source, then downrezing & deinterlacing (while retaining the framerate) using HandBrake does a great job of minimizing filesize while retaining quality. You'll want to trial-and-error the bitrate/CQ depending upon how you answer the questions above.

Just my experience and my humble opinion,
...Jerry

I've started using a paid-for video streaming service called "Bits On The Run" that is run by the developers of the JW Player. I upload MP4's created using Handbrake. BOTR will re-encode the video into multiple resolutions that will be offered up based on the viewer browser limitations. But, they also offer the option of just streaming the original video file as uploaded, with no additional encoding.

The only thing that became evident, if streaming the original MP4, is that by default the original MP4 produced by Handbrake isn't optimized for web streaming in that the frame index (moov atom) is at the end of the file, so that the entire file has to download before it starts to play. Just check the "web optimized" option and you should be good to go.

If you have an MP4 file that has already been encoded, but has the index at the end of the file, you can use a free AIR application called "QTIndexSwapper 2" to move the index to the beginning of the MP4.

Thanks for the heads up, will be checking out that service in coming weeks.

RE: The "web-optimized" checkbox in Handbrake: That is highlighted in the original tutorial we put up a while back.
A look at those settings may offer other useful hints as well.
http://www.jazzythedog.com/testing/dnxhd/getvideo.aspx

@Ogul,
The first post in this thread shares my thoughts about your questions.
If you are going to host the video on your own server space, follow Vimeo and Youtube's lead and encode at 2Mbs.
Jerry has had success all the way down to 1Mbs.
Settings for my compression-optimized 2Mbs 720p version are below (at CQ RF 28, but yours will vary).
Very closely matches Vimeo quality.

Hey guys,
A clarification question regarding the Handbrake settings. From the screenshots, it says that an 8MBps is optimal. Is this the bitrate or the final size? If it's the bitrate, shouldn't I just use the Avg Bitrate to 8000 Kbps?

Clarification:

8Mbs (average) bitrate is optimal for 1080i AVCHD or HDV source rendered to 720p for Vimeo or Youtube. It's just math.

Constant Quality RF was designed to give you the same quality in about half the time.
The disadvantage is that the final average bitrate cannot be calculated, only approximated.

Using 8Mbs 2-pass VBR to render is just fine if the considerable extra time spent rendering it is of no issue to you . . .

Thanks for your prompt response. So, if I render at CRF: 20 and end up with a file that's 12Mbs bitrate, should I decrease the CRF until it's closer to 8? I'm reading that you're recommending 8 Mbs as the best size/performance ratio for 720P.

No, this is where it is confusing (at first)..
Increasing the RF increases the compression.
So you would raise the RF (maybe to 22) in order to lower the bitrate.