Vegas to Youtube, Vimeo, Web -- A New Look

Comments

amendegw wrote on 2/28/2011, 12:40 PM
musicvid, That's quite amazing!!!

This is really picking nits, but the only "thing" I see is a slight stuttering in the moving cars in the stringer clip. I'm sure that's a Vimeo / IE problem as I see the same stutter in all clips. Interesting, the stutter is substantially reduced when viewing it in Chrome.

I downloaded the mp4 and there's absolutely no stutter when viewing in WMP.

Earlier, Nick Hope saw better online performance with Facebook compared to Vimeo. With your permission, I'll upload it to my Facebook account. I think I can configure it for public view - we'll see.

Great Job!
...Jerry

PS: Here's an interesting observation, when I downloaded the clip, the source of the download was http://s3.amazonaws.com/videos.vimeo.com/413/367blah-blah-blah

System Model:     Alienware M18 R1
System:           Windows 11 Pro
Processor:        13th Gen Intel(R) Core(TM) i9-13980HX, 2200 Mhz, 24 Core(s), 32 Logical Processor(s)

Installed Memory: 64.0 GB
Display Adapter:  NVIDIA GeForce RTX 4090 Laptop GPU (16GB), Nvidia Studio Driver 566.14 Nov 2024
Overclock Off

Display:          1920x1200 240 hertz
Storage (8TB Total):
    OS Drive:       NVMe KIOXIA 4096GB
        Data Drive:     NVMe Samsung SSD 990 PRO 4TB
        Data Drive:     Glyph Blackbox Pro 14TB

Vegas Pro 22 Build 194

Cameras:
Canon R5 Mark II
Canon R3
Sony A9

musicvid10 wrote on 2/28/2011, 12:43 PM
I forgot to mention, that when I must encode for 16 macroblocks with SD NTSC widescreen, I encode to 864x480, which is actually 9:5 SAR. The slight stretch is not noticed unless there is a circle in the picture. Some older QT players may need 4x4, and not even the newer ones respect PAR flags afaik.

With modern AVC encoders, conforming to 16x16, 8x8, or 4x4 isn't nearly as important as it used to be, although purists will still say they find pixel inconsistencies at the very edge of the frame.
amendegw wrote on 2/28/2011, 12:44 PM
musicvid,

One more thing. Have you posted this to the Vimeo forums? I don't read them often, but I'd be interested to see what the Vimeo community thinks of your excellent work.

...Jerry

System Model:     Alienware M18 R1
System:           Windows 11 Pro
Processor:        13th Gen Intel(R) Core(TM) i9-13980HX, 2200 Mhz, 24 Core(s), 32 Logical Processor(s)

Installed Memory: 64.0 GB
Display Adapter:  NVIDIA GeForce RTX 4090 Laptop GPU (16GB), Nvidia Studio Driver 566.14 Nov 2024
Overclock Off

Display:          1920x1200 240 hertz
Storage (8TB Total):
    OS Drive:       NVMe KIOXIA 4096GB
        Data Drive:     NVMe Samsung SSD 990 PRO 4TB
        Data Drive:     Glyph Blackbox Pro 14TB

Vegas Pro 22 Build 194

Cameras:
Canon R5 Mark II
Canon R3
Sony A9

NickHope wrote on 2/28/2011, 12:56 PM
>> I'll upload it to my Facebook account. I think I can configure it for public view - we'll see. <<

Viewers will need a Facebook account to view it in Facebook itself. Only low resolution is allowed in embedded Facebook videos.

>> the source of the download was

That is interesting because I thought Vimeo were using Bit Gravity for their CDN, which is what I thought was the reason for the fantastic buffering speed of their videos. Maybe they just use Amazonaws for the original clips to download. Incidentally I'm using Amazon Cloudfront (the CDN add-on for Amazon S3) for a lot of the media on my website, including the last couple of old videos that I'm self-hosting in JWPlayer. Here's one.
NickHope wrote on 2/28/2011, 1:03 PM
>> With modern AVC encoders, conforming to 16x16, 8x8, or 4x4 isn't nearly as important as it used to be, although purists will still say they find pixel inconsistencies at the very edge of the frame. <<

Just been reading that you can more or less forget about mod8 and mod4 for H.264. They like mod16 and if you can't do mod16 then the important thing is for the resolution to be as few pixels below mod16 as possible. How important this is can only really be determined with some testing.
NickHope wrote on 2/28/2011, 10:09 PM
>> Are you both OK with most recent version on Vimeo (untiled4.veg)?

Sorry, I think I misunderstood. I thought you were looking for approval of the result of a new upload using that decomb custom command line, but isn't this the same one with the motion blur that I've already looked at? Or are you somehow managing to replace videos under the same Vimeo URL? Or are you looking for approval for the updated veg project? Well, the project's fine, although I must say I enjoyed the version (which, confusingly, I now can't find) with the moving shot of the model. Much as I like Kimberly's ducks, I enjoyed looking at her more :) I guess you took it out because of the framerate difference.
musicvid10 wrote on 2/28/2011, 10:52 PM
Nick, if you're still seeing blended fields, the Vimeo server you are accessing probably hasn't updated yet. I have actually replaced the video at that URL three times, and the one I uploaded last night plays decombed, not blended on this side of the planet.


As far as the model footage, I can include a smart-rendered clip in the zipped project folder if you can figure out a way to use it. I just couldn't find a satisfactory frame rate conversion. Resampled played the smoothest, but the individual frames were terrible (I'll have to try HB). The full sample video was downloaded here:
http://av.watch.impress.co.jp/video/avw/docs/408/918/sample.mpg

Anything else, as far as the color tweaks, etc.? If not, I'll consider it a go. BTW, great catch on the frame blending problem.
NickHope wrote on 3/1/2011, 1:36 AM
I didn't know that you could replace a Vimeo video at the same URL. I really really really wish you could do that on YouTube. I request it every time their partner suggestions initiative comes up.

The latest version looks fine. I prefer the tweaks you have made to the levels/colours. Looks like you're now keeping the opposite field from your previous version (http://vimeo.com/18690771) and my attempts, which makes it difficult to compare stills on the timeline, but that doesn't matter.
musicvid10 wrote on 3/1/2011, 8:11 AM
I'll upload a version of the new untitled4.veg using DNxHD.
That should sort out any lingering field issues.

I'm about resigned to just making the tutorial using DNxHD anyway.
Probably continue using I420 for my own stuff. I set out to make the tutorial relatively simple to follow, and having to load custom deinterlace settings every time one renders makes it seem counterintuitive.

In any event, I'll upload the new project with media to Jerry's server late this week. I'll include the pretty girl clip.

Since Youtube allows advertising and revenue sharing, I think that is one of the reasons they don't allow swapping videos. It could open up a whole new game for self-promoters (like Richard Heene).

Looking forward to your tutorial. I'm actually thinking about installing MeGUI on my notebook and trying again over spring break to learn it.
musicvid10 wrote on 3/1/2011, 10:24 PM

I've had a chance to preview Nick's tutorial and it is world class. Enough content to massage the inner geek for many moons. Well done Nick, and look for his forum announcement in the coming days.
NickHope wrote on 3/2/2011, 5:37 AM
Thanks a lot.

I finally published my tutorial and here is the new thread.

I made a few updates since the version you saw yesterday, so be sure to reload your page. Specifically the resizing in the AviSynth scripts was wrong.

Let's still use this thread to discuss details of the Handbrake workflow, and some of the topics that we've touched on that are not directly related to my tutorial.
JHendrix wrote on 3/11/2011, 4:54 PM
OK I am about to start testing based on you suggestions.

only thing i don't get is:

"In any case don't forget to conform your levels to Studio RGB before you upload (which can be done by adding a Sony Levels filter to the video output and choosing the "Computer RGB to Studio RGB" preset)."

so is that only if you are uploading to youtube?

because I actually use Levels on many of my clips and I use this preset to bring in needed contrast.: Studio RGB toComputer RGB
musicvid10 wrote on 3/11/2011, 6:41 PM
JHendrix,

To condense everything that has been said about levels sofar:

You must send Youtube, Vimeo, JWPlayer, SMPlayer, GOMPlayer, FLVPlayer, FlashPlayer, and all other Flash-based players 16-235 RGB levels, in order to play back at 0-255 RGB.

This is called "What You See Is What You Get." Simple enough?



robwood wrote on 3/11/2011, 7:25 PM
To condense everything that has been said about levels sofar:

this is when using H.264 codec, right?
but if an RGB codec (photo-jpeg, png) was used, wouldn't rendering to 000-255 be the correct range?

tia
musicvid10 wrote on 3/11/2011, 8:17 PM
Rob,
In my initial trials, almost a year ago, I tested over 30 codecs at various settings, and of the ones that were accepted by Youtube, all returned the same results, IOW levels were mapped [16,235]->[0,235] in every single case. See the thread:
Youtube Mangles cRGB
If any of this has changed in the meantime, or if I have missed one that does not follow this behavior, I will be interested in the results of your testing.

Now, taken in the context of this discussion, every YUV intermediate codec tested followed the exact behavior I indicated, though most threw the infamous x264 colorspace bug that has been abundantly documented in other discussions on the internet. This bug can be corrected in the AviSynth command line (refer to Nick's thread), but unfortunately cannot be compensated in Handbrake.

Please see the condensed results contained in my spreadsheet ~55 posts up.

Thanks for your question, and please read the very first post in this thread to see how I have defined this workflow as Vegas->DNxHD->Handbrake, which maintains a REC 709 / YUV space door to door. If you would like to start your own inquiry using Photo JPEG or another RGB codec as an intermediate pathway to x264, or even as an upload candidate for Youtube, feel free and encouraged to do so, maybe in its own thread.
;?)
NickHope wrote on 3/11/2011, 9:37 PM
@ Musicvid - Not sure why you are including GOM Player in the list. It's an offline media player with its own built-in codecs (which you can disable). It doesn't expand levels.

@ JHendrix & robwood - This might help. Rob, I've never heard of png as a video format.
musicvid10 wrote on 3/11/2011, 9:45 PM
Nick, GOM Player gives exactly the same behavior on my system as the others I listed. 16-235 maps to 0-255. If it doesn't technically fall into the same class as the others (VLC and SMPlayer), the output is the same.

NickHope wrote on 3/11/2011, 10:06 PM
My computer apparently has special needs. Whatever is messing with the Flash Player plugin is apparently also messing with GOM Player. The key might in overlays. Will follow up in the other thread.
musicvid10 wrote on 3/11/2011, 10:10 PM
Something in me thinks Flash doesn't use the video overlay surface. But I sure could be wrong. In any event, your computer marches to a different drummer. Do you have an older ffdshow installed at the system level by chance? I had to do a cold install to get rid of it.


(PNG is a valid MOV format. Lossless, but s-l-o-w).
musicvid10 wrote on 3/27/2011, 11:08 AM
Jerry,
Your new draft page with all the tutorials and tests is coming along nicely, and is going to be tour de force.

I have already directed one interested individual on the HB forum over to it. Although not a Vegas user, he uses both HB and MeGui for his work.

Even though I need to finish up my video Handbrake tutorial, I don't think it's too early to post a link on the Vegas forum, if you see fit. Your ability to organize all of the divergent branches of the project into one page is remarkable.

amendegw wrote on 3/27/2011, 11:24 AM
Okie Doke, Here's the link - remember this is still a work-in-progress:

http://www.jazzythedog.com/testing/DNxHD/HD-Guide.aspx

I'm interested in any and all constructive criticism. Particularly, near the bottom, I've listed contributors to this project. If anyone feels they should be included in this list, use this forum to send me a personal e-mail. I certainly don't want to slight anyone.

Enjoy!
...Jerry

System Model:     Alienware M18 R1
System:           Windows 11 Pro
Processor:        13th Gen Intel(R) Core(TM) i9-13980HX, 2200 Mhz, 24 Core(s), 32 Logical Processor(s)

Installed Memory: 64.0 GB
Display Adapter:  NVIDIA GeForce RTX 4090 Laptop GPU (16GB), Nvidia Studio Driver 566.14 Nov 2024
Overclock Off

Display:          1920x1200 240 hertz
Storage (8TB Total):
    OS Drive:       NVMe KIOXIA 4096GB
        Data Drive:     NVMe Samsung SSD 990 PRO 4TB
        Data Drive:     Glyph Blackbox Pro 14TB

Vegas Pro 22 Build 194

Cameras:
Canon R5 Mark II
Canon R3
Sony A9

SuperSet wrote on 3/28/2011, 3:38 PM
On a related note, I'm trying to use the DNxHD codec and after downloading the 2.3.2 codec and installing it, I still don't see it listed under the QuickTIme .mov selection. Has anyone else seen this problem?
I'm using Windows 7 Enterprise 64-bit version with Sony Vegas Pro 10.0c? I have a desktop that installed the codec and shows up just fine.
amendegw wrote on 3/28/2011, 3:57 PM
"I still don't see it listed under the QuickTIme .mov selection."Please excuse me if I'm stating the obvious, but you are aware you need to create your own, new custom template?


The settings for this template are on the project webpage.

Good Luck!
...Jerry

System Model:     Alienware M18 R1
System:           Windows 11 Pro
Processor:        13th Gen Intel(R) Core(TM) i9-13980HX, 2200 Mhz, 24 Core(s), 32 Logical Processor(s)

Installed Memory: 64.0 GB
Display Adapter:  NVIDIA GeForce RTX 4090 Laptop GPU (16GB), Nvidia Studio Driver 566.14 Nov 2024
Overclock Off

Display:          1920x1200 240 hertz
Storage (8TB Total):
    OS Drive:       NVMe KIOXIA 4096GB
        Data Drive:     NVMe Samsung SSD 990 PRO 4TB
        Data Drive:     Glyph Blackbox Pro 14TB

Vegas Pro 22 Build 194

Cameras:
Canon R5 Mark II
Canon R3
Sony A9

SuperSet wrote on 3/28/2011, 7:09 PM
Jerry - that's what I missing, thanks for pointing me in the right direction!