Musicvid's "Sony Vegas > YouTube Tutorial&quot

Soniclight wrote on 6/29/2012, 10:38 PM

From what I gather, Musicvid has left this forum for an undetermined period and I can find no way to contact him elsewhere -- except waiting for a comment at the below tutorial which may not produce a response (he's got a life). As many know, this tutorial is one of the best around and seems to apply to more than just platforms like YouTube.

I may put a version of my soon-to-be finished 5-6 min. video at YouTube at some point, but I wish to have as much control over it as possible, so I'm going to create a page for it at my own website using a JW/LongTail player. Since I can't ask him directly about my particular situation, perhaps someone familiar with it can respond.

Here are some...

Project Facts:

-- 1920x960 (I like more "theater" width than regular 1920x1080), progressive, square 1:1 pixel ratio.

-- Most of it is created from still images "faked" to look like video (pan-crops, etc.) so no original footage issues.

-- Those who have seen some of my stuff know I have an artsy-fartsy, almost Disney-ethereal visual style (I like bright colors). I use Particleillusion rather extensively -- sparkles, glows, etc. so I wish for their subtleties to not get lost in translation.

Output resolution:

-- Have not decided yet. Used to do 512x288 but wish it to be larger. Could do half project (960x480) but file may be too heavy too buffer on a shared hosting platform if I wish preserve image and music quality (my own music, so wish it to sound right too).*

(* Johnmeyer once told me here that one should always choose a resolution that is divisible by 8 (or better yet 16?) due to the under-the-hood mathematics of rendering; so whatever I choose between 512x288 and 960x480, I'll try to honor that ratio.)
______________________________

Musicvid's tutorial is great, and it seems to me that one could apply at least some if not all of its recommendations to a JW/LongTail player situation.

Thanks for you help.

~ Philip

Comments

ushere wrote on 6/29/2012, 11:44 PM

hi philip,

not going to be much use to you, but my general observation is....

musicvid, jerry, jc, kelly, et al., have experimented with every method, both internal and external in search of the perfect youtube output. and there's no doubt that some of their methods DO improve the quality, at the price of a more convoluted procedure than simply using the built in sony / main concept presets.

however, my main contention is simply why? if the content one is posting is interesting people will watch it. very few viewers, would appreciate the difference in quality (in general youtube viewers are NOT pixel peekers) between the default output and the better quality derived from other methods.

of course if the client is willing to pay for the extra time / steps involved then fine, but i have done some 'limited' research with some of my clients and they failed to notice any significant difference between youtube quality outputs.

i suppose i should duck now ;-)

Soniclight wrote on 6/30/2012, 12:24 AM

Thanks for reply and p.o.v., ushere. I used to use .flv for my videos hosted at my site with JW/Longtail player but thought that following the use-mp4-via-Handbrake method would be better according to most people here. I could still go that route - I'm just curious if some adaptation of this tutorial may be better.

As to the underlying in-eye-of-beholder video quality issue, I suppose I have to satisfy the itch of the person who put all the long hours, days and weeks of work into it (moi).
Call it "craftsman neurosis" :D

john_dennis wrote on 6/30/2012, 12:32 AM

Musicvid did a low fly-by as recently as a couple weeks ago. Look here. He was in another forum yesterday.

farss wrote on 6/30/2012, 1:18 AM

"i suppose i should duck now ;-)"

No. I've tried getting clients etc to watch it on Vimeo, abject failure.

We should also remember it doesn't matter how well we encode our content once YT gets hold of it all bets are off. My approach has been to use the Sony AVC encoder at high bitrates and then pray YT is having a good day. As we can now upload 2GB files I don't see any need to be lenient with bandwidth.

The only non Vegas native tool I used is the YADIF de-interfacer although more and more I find myself shooting progressive in the first place and can skip even that.

Bob.

Soniclight wrote on 6/30/2012, 3:00 AM

OK, I get the p.o.v.s on renders for YouTube upload, but the question posed is about equivalence or value (or non-equivalence/value) of the tutorial's suggestions for my priority: having my work viewed via a JW/Longtail player at my site. I.e. what settings would differ for that modality?

farss wrote on 6/30/2012, 3:59 AM

"what settings would differ for that modality?"

I'd look at what issues Musicvid's tutorial addresses:

1) De-interlacing: Unless you're stuck with interlaced footage not an issue for you.
2) Aliasing i.e. low pass filtering. Depending on your content this might be vital or irrelevant.
3) Scaling: Different algorithms can make a difference. Could be be vital or irrelevant.
4) Encoding: At low bitrates better encoders perform better. If you're paying for the bandwidth very important.

All of that said there's probably no harm going to be done by simply following the tutorial as is. You might not need de-interlacing but I doubt YADIF will do any harm if you use it when you don't need it. Same goes for every thing else really.

You are in the fortunate position of being able to easily test the outcome, so test, test and test some more. I understand that your videos are important in your life and you have time on your side with no commercial pressure so get to it.

Bob.

NickHope wrote on 6/30/2012, 4:16 AM

Sounds like you don't need the de-interlacing aspect, and it should be pretty easy to drop that from the Handbrake workflow. Can't remember exactly how, I'm afraid, as I'm not a Handbrake user.

Regarding the downscaling, you might be hard pushed to see any difference between the Lanczos in the Handbrake workflow and the bicubic in the Vegas workflow. It might well be that you'll be better off just throwing a bit more bitrate at a Sony AVC or MainConcept AVC render and using that, to keep things simple.

As for web video resolutions, mod16 is even better than mod8, but not essential. Here is a good guide.

amendegw wrote on 6/30/2012, 4:19 AM

Haven't we discussed all this before? http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=794758Playback Stutter in H264 FLV & Related Questions[/link]

...Jerry

ushere wrote on 6/30/2012, 8:18 AM

oh jerry, with the average age of the participants here i'm pretty sure we've discussed EVERYTHING under the sun, from far right politics through to the advantages of using esoteric codecs to get the pixels the other codecs leave behind.

but with age comes memory lapses, so let's start all over again.....

have a great weekend ;-)

musicvid10 wrote on 6/30/2012, 9:45 AM

Philip et al,
I'm not really in exile, just busy with other work.
You can reach me through my username at gmail.

Soniclight wrote on 6/30/2012, 10:50 AM

Thanks to all for your responses -- I'm getting a clearer picture on this, but can't respond more at this point due to other priorities. I shall return in due course.

As to "Haven't we discussed all this before? Playback Stutter in H264 FLV & Related Questions", indeed, Jerry -- that's the thread where all of you taught me to go the Handbrake route, etc. I'm simply trying to fine-tune the learnin' :)

Soniclight wrote on 6/30/2012, 12:14 PM

The above image is hopefully self-explanatory. Kind of a "double exposure" in that I illustrate how the buggy window shows up though in real life it shows up at center upper edge of monitor. Other "Configure" equivalents ("Custom") for other codecs windows work properly. I really don't want to uninstall/reinstall Vegas just to find out that it's an Apple-Vegas glitch.

On an other note, I noticed that my .MOV "Configure" defaults to 24 bpp, tutorial shows 32bpp. Important or not?

WillemT wrote on 6/30/2012, 12:30 PM

I remember that screen. If you click the slither of the drop down box seen at the bottom edge you can get the options.

Better, however, make sure you get the latest version, 2.3.7 of the DNxHD codec, which fixes the layout/sizing of the screen. That is the one shown in the tutorial.

If you place the cursor as high as it will go you can drag down the box as well (if required). Windows however does not remember the last placement/sizing.

Edit: Not being a fan of Quicktime I stopped using the DNxHD codec for processing in HandBrake. I render to the XDCam EX codec (last on the list in the Render As... options - rendering to a matching property) and use that in handbrake - it handles stereo audio correctly.

Hope that helps
Willem.

Soniclight wrote on 6/30/2012, 1:17 PM

WillemT -- Thanks for the tip. I have v.2.2.1 -- I'll go find and download the latest. I'll also consider the codec you use.

As Bob/Farss stated, trial and error testing on what will ultimately work best is the only route. But it will be nice to nail down something that I'm satisfied with for future video projects. The old .flv route I used to go on just isn't the way to go anymore.

amendegw wrote on 6/30/2012, 1:35 PM

When I start with 1080 30p and render to 1080 30p, the following Custom Template works fine for me:

...Jerry

Soniclight wrote on 6/30/2012, 2:19 PM

Well, installed the new Avid version, was able to access the drop down, but Vegas keeps crashing at 12% render on using this codec :(
The codec does allow custom frame size, so my odd 1920x960 should be accepted.

Then I thought maybe it was the number of tracks on the original .veg (lots - most rather events sparse due to much Add stuff) but even my post-production for final render project file with only 1 video (half-resolution test render WMV) + 2 Audio tracks (1 for music, 1 for background sound fx) active crashes in the exact same spot.

Ah, life, ain't it fun.
So...

Any other quality equivalent codec that would work in Handbrake? While kind of huge (77 Gb), maybe an uncompressed (of course, 8-bit) .AVI?
I can always delete the monster once I've done the final upload render.

amendegw wrote on 6/30/2012, 2:32 PM

"Any other quality equivalent codec that would work in Handbrake?Since your source is progressive, you could always render to a high bitrate MainConcept AVC/AAC (*.mp4) and then use HandBrake to resize & reduce the bitrate for progressive download (sometimes erroneously called "streaming").

...Jerry

Soniclight wrote on 6/30/2012, 3:38 PM

Thanks, Jerry, I'll try that. Slowly working through this.

On a quasi-aside: For such renders incl. intermediates, would having alpha channel rendered too seems to just pointlessly bloat the file size. True/false?

amendegw wrote on 6/30/2012, 3:42 PM

"For such renders incl. intermediates, having it include alpha is just pointlessly bloating the file size. True/false?I guess I don't understand that. If you're rendering to an intermediate only to further process with HandBrake, why would you even want alpha?

...Jerry

farss wrote on 6/30/2012, 4:05 PM

"

32bpp = 8bpc + 8 bit Alpha
24bpp = 8bpc

bpp = bits per pixel, NOT bits per channel.
As Handbreak isn't going to be using tha alpha channel and you have no need for the alpha channel then 24bpp is all you need.

Bob.

Soniclight wrote on 6/30/2012, 5:16 PM

Jerry - " If you're rendering to an intermediate only to further process with HandBrake, why would you even want alpha?" Well, that's essentially what my question implied, I just wanted to make sure I wasn't missing something.

Bob - Thanks for the bpp clarification. That said since I can't render in that .mov codec anyway (crashes mentioned above), moot.
But good to know. I keep learning stuff here, Oh Ye Great Video Yodas :D

farss wrote on 6/30/2012, 5:38 PM

"Well, that's essentially what my question implied, I just wanted to make sure I wasn't missing something."

To try my best to give you the best answer to the question:
Assuming you are using a bitrate constrained codec then forcing the encoding of redundant data is not just pointless but undesirable. That redundant data is taking up bandwidth that can be used to give less artifacts in the needed video or audio stream.

Bob.

Soniclight wrote on 7/1/2012, 12:41 AM

OK, well, partial success for now. I settled on a 720 x 368 rez - which honors the 16x scaling. I used the for-your-own-site suggestion at the end of the tutorial, uploaded the player page and it works. But I still have to fine tune the too-greyed out <> too-contrasty Levels thing.

Still got a stutter in a couple of places in the video alluded to in the my earlier thread a few months ago about FLV and stuttering that Jerry mentioned. I may have to tweak the RF factor in Handbrake too. But so far as a 51 Mb. 6 min. video playing set at RF:19 as suggested, it buffers sufficiently ahead on my mid-range DSL (1.5 to 3 Mps.)

The only puzzling thing is that Musicvid's tutorial shows access and selection of 320 bitrate for audio in Handbrake - my drop-down only goes up to 160.
Not a biggie for it sounds fine to me even as the music's composer.

Soniclight wrote on 7/15/2012, 8:35 PM

A few eons later...
An Accidental Quasi-Solution to Text Scroll Squirrel-y Stuff

First, this isn't technically for a credit scroll, but for an important part in the beginning of my video where I scroll text. But same issue.

I've done so many test renders at all kinds of resolutions but Handbrake seems to still put in the squirrel scrolling waves, etc. even when the original intermediate .avi or test .wmv don't -- locally. I applied even Johnmeyer's math-y tutorial on this with little success. Then I hit something that is not really a total fix but works for me....

I was test watching my video at its page at my site and was curious how a 720x360 rez mp4 would look like in full-screen on a 1920 x 1080 monitor.. Sure, a bit blurry in spots but... the "scroll" was smooth. So I decided to do a CTRL+ to bump up the browser window and watch a non-full screen of the same video. No scroll-y squirrel-y either.

So I applied the same "blow-up" principle to non-zoomed out page (browser window at 100%) but did it in the JW player: a 720x560 mp4 to play in a 800x400 JW player. Well, it worked. Sure, again, not the most elegant or perfect solution but it's far better than having text look like it's getting jaggy sea-sick...

Now, all I have to do is figure out what the "sweet spot" is for this so that I can created a slightly smaller resolution file for the player so as to minimize other quality degradtions which are really overall minimal. Maybe something like a 20 pixel differential between file height and player height.

I know that the purists here will kick my derrière for such an imperfect work-around, but, hey, if it works for me, it works for me :D
Part of the art of video is to fool the human eye - or maybe just the technology - lol.