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

Comments

NickHope wrote on 1/27/2011, 12:52 AM
Planning to do my MeGUI test tomorrow. Hopefully up on YouTube and Vimeo within 48 hours.
musicvid10 wrote on 1/27/2011, 7:30 AM
This is what Vimeo gives us back from HD uploads:

"General

Based on that pretty limited information, I am trying to match Vimeo playback quality using high profile settings in Handbrake. Goal being to get as good a results at 2Mbs for local delivery. Results are pretty encouraging, but not quite there yet. Will send it up to Jerry's server along with settings when I am satisfied.
amendegw wrote on 1/27/2011, 7:51 AM
Hmmm... My 2Mbps render produced the following from MediaInfo:

Bit rate mode : Variable
Bit rate : 2 000 Kbps

Wonder why it doesn't tell me the max bitrate?

Also, musicvid, we've had some discussion on this before. My testing indicates changing the Deblocking from -2/-1 seems to make very little difference. The only thing that seems to really help the blocking is upping the bitrate.

Good Luck with your testing!
...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

musicvid10 wrote on 1/27/2011, 7:55 AM
My high profile tests are showing less overall blocking and perhaps more response from the deblock setting, than did our main profile settings used for the 8Mbs version. Still in the beginning stages, more to come. About all I have to go on from Vimeo is

> High@L3.1, 4 ref frames, 2Mbs VBR.

Apparently, they're leaving a lot of information out of the tags for proprietrary reasons. If Youtube was going to figure out what Vimeo is doing with blocking, they would have done it by now. But like I say, I'm getting close.
musicvid10 wrote on 1/27/2011, 8:03 AM
Jerry, an afterthought:

If you render using CQ, and a finished bitrate around 2Mbs, what does the blocking look like? Better or worse than VBR?

Higher RF = Lower bitrate.
amendegw wrote on 1/27/2011, 8:16 AM
Give me an hour or two to test this. I will have to do trial and error to get CQ/RF to match my VBR bitrate.

In the meantime, did you ever visit my updated MediaPlayer testing page: http://www.jazzythedog.com/testing/dnxhd/Mediaplayers.aspx ?

I see almost no blocking the the 2Mbps encodes.

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

musicvid10 wrote on 1/27/2011, 8:35 AM
Yes, I have your 2Mbs encode and Vimeo's 2Mbs encode as benchmarks.
Using high profile settings at this bitrate as Vimeo's version suggests gives some improvement, but one needs to look for it.

At higher bitrates, high profile settings offer little or no advantage, and result in longer render times, so I left the 8Mbs version at main profile, also for playability reasons.

amendegw wrote on 1/27/2011, 9:31 AM
Okay, I got a result I did not expect. I did my testing at 1Mbps because I could see almost no blocking at 2Mbps. And it turns out (to my old eyes) there doesn't seem to be a nickel's worth of difference between the VBR & CQ renders. I would have thought the VBR would be far superior. Edit: Turns out this IS expected. I confused CQ with CBR. See the comments a couple of posts down. I'm changing all references to CBR to CQ in this post - to reflect reality.

Because the blocking is most visible in transitions, the following screenprints are rather dark, illustrate the results of the test.

First the 1Mbps VBR:


Next the 1Mbps CQ:


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

musicvid10 wrote on 1/27/2011, 10:11 AM
That is interesting. Did you also do a test using CQ (which is a form of VBR)?
If not, I can slip one into my tests. If it is at least equal to VBR at low bitrate it would make a much faster render.

Jerry - Quick note on the demo page. The Youtube-processed version is 2Mbs. The upload was 8Mbs.
amendegw wrote on 1/27/2011, 10:27 AM
musicvid,

What a dummy I am!! I've always done my renders using VBR/two pass and targeting a bitrate. When I saw the "CQ" (Constant Quality)setting, my mind registered "CBR" (Constant Bit Rate). My references above to CBR are incorrect. I'll change them after this post.

And now that I understand that we're taking Constant Quality, not Constant Bit Rate, my test results make perfect sense.

Incidentally, after some trial-and-error an RF=32.5 gave a video bitrate of 1035Kbps.

Is this the first sign of Alzheimer's?? {grin}

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

musicvid10 wrote on 1/27/2011, 10:29 AM
No, but we've both definitely got Halfheimers.
amendegw wrote on 1/27/2011, 4:37 PM
So... I've made another render at 1.5Mbps and can only see very, very minimal blocking. I've swapped out the 2Mbps video with this new 1.5Mbps video, here: http://www.jazzythedog.com/testing/DNxHD/Mediaplayers.aspx

What I'm really interested in is how does this play on for users with lower bandwidth connections. Does the playback start/stop waiting for the download to catch up with the playback?

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

musicvid10 wrote on 1/27/2011, 8:36 PM
Jerry.
In my attempt to replicate Vimeo quality for local delivery, I have uploaded my current "best" 2Mbs effort along with advanced Handbrake settings to your server. Note that I used Constant Quality @ RF 28 (YMWV) and High Profile to the best of my ability to emulate Vimeo processing.

As a fellow old fart, I anxiously await your comparison with your own recent work
(and Vimeo's).

;?)
NickHope wrote on 1/28/2011, 12:02 AM
Working on my MeGUI test right now.

Any thoughts on Lanczos4 versus Lanczos3? I'm tempted to try Lanczos4 first, which is supposed to be sharper. But going too high can cause "ringing". Perhaps it is slower too, but I don't know. There is maths that can help you work out which is better depending on the resize ratio but it fried my brain. The AviSynth default is Lanczos3.

Another thing. If you were thinking of trying the Mike Crash smart deinterlacer Vegas plugin as we discussed further up the thread, I remembered that later versions of the standalone smart deinterlacer Virtualdub filter include an edge-directed interpolation option, which is allegedly better. Therefore in theory a better result would be obtained by framserving to Virtualdub and doing the deinterlacing and resizing in there. But if one is doing that then perhaps one may as well just go the MeGUI route. Would be cool if someone updated the Mike Crash plugin to include the latest smart deinterlacer.
amendegw wrote on 1/28/2011, 3:25 AM
"As a fellow old fart, I anxiously await your comparison with your own recent work Okay, I've moved your render up to the demo webpage: www.jazzythedog.com/testing/DNxHD/Mediaplayers.aspx

I've done a comparison and your clip looks very, very good. However, I think we've reached a point where we're trying to count the angels on the head of a pin. My favorite place to look for blocking is at frame 1453 (about 47.5 secs in). Your render looks very slightly better here, but the slight difference could well be because your video bitrate turned out to be 2,118 Kbps vs. my targeted 2,000 Kbps.

So, now that I've said that, let me open another "can of worms". Look at the white car at the 36 sec mark. Both JW Player (for that matter, all the other webpage based players) show a stutter in the motion. To my eyes (please confirm this), the Vimeo clip shows some stutter, but less. When I play the clip, locally on my laptop (WMP), all clips play smooth-as-silk.

I think this is the same issue I raised in the following thread: http://www.sonycreativesoftware.com/forums/ShowMessage.asp?Forum=4&MessageID=745366 Unfortunately, no answers (or even replies!)

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

musicvid10 wrote on 1/28/2011, 8:10 AM
The only versions that don't drop frames in high-motion areas on my lowly laptop are your 1Mbs version and the non-HD Vimeo version (600Kbs). I've learned to live with it until I get something a little spiffier. VLC occasionally drops frames on local playback, but it is not repeatable at the same spot.

I think when everything is finally on HTML5 protocol, we may see some improvement in browser based playback (and we may have to redo the tests)
;?O
NickHope wrote on 1/28/2011, 8:34 AM
Been doing MeGUI stuff today, but before I share any of that I've made some interesting discoveries based mostly on what you guys have already done...

1. Musicvid's original Vegas project
2. you guys' DNxHD intermediate
3. the x264 video I made today in MeGUI
4. you guys' files downloaded from YouTube and Vimeo
5. Jerry's Flash/JW Player 2Mbps file

All the above files return this (more or less):



However .png screengrabs of the video playing in Vimeo or in Jerry's JW Player in Firefox with Flash Player version WIN 10,1,85,3 (1920x1200 Nvidia Quadro FX 1600M) return this (video scopes set to 16-235 Studio RGB, ):



This leads me to the conclusion that Vimeo is doing nothing to the levels on their servers, but that the 16-235 Studio RGB > 0-255 Computer RGB conversion is taking place in our browsers' Flash player. I don't know if this is default behaviour or if Vimeo are sending instructions to the Flash player to do this. From previous discussion I had assumed that the conversion was happening on YouTube and Vimeo's servers as they re-rendered our file, but that now seems to be an incorrect assumption.

Is this news to anyone, or am I just the last to work it out? (or am I talking codswallop?)

Should have known better than to expect the same result from YouTube... Again the levels are expanded to 0-255 on playback, but a screengrab of the video playing at full screen in Firefox returns a bent-up curve:



However a screengrab of the video playing in YouTube at 480p in IE8 returns a bent-down curve!!!:



So YouTube in conjunction with the Flash Player is messing with the gamma, but it's anyone's guess how or why.
musicvid10 wrote on 1/28/2011, 8:45 AM
Nick, I noticed a similar situation with downloaded files from Youtube. Gamma was bumped up. All I did was a straight remux so I could open the file in Vegas. I even came up with a preset to correct it locally. Here is a link to the original discussion Bob and I had about this:
http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=742114



But a screen grab right off the Youtube Player (fullscreen, 720p) gives me a straight line. So I decided to stick with that because that is what most people do -- view online rather than download.



Your thoughts? I'm definitely going to check this on Vimeo too, and see if it is the upload postprocessing server, the Vimeo Flash Player, or both contributing to the shifts.
"(video scopes set to 16-235 Studio RGB, ):"
I made that mistake also until I researched it. That checkbox is only for mapping MS DV. For all our HD 709 work, both boxes should be unchecked, giving the correct gamut endpoints. I checked this with about 30 YUV codec options, including HDV and AVC (and DNxHD), and they all came back the same.




NickHope wrote on 1/28/2011, 10:36 AM
>> Your thoughts? Your conclusion that it is not the upload server postprocessing but the Flash Players themselves doing the shift makes sense, and is causing me to rethink some previous assumptions I made. <<

My findings in that brief test indicate that the YouTube gamma shift is dependent on the browser model and/or the playback resolution of the file. It was the same 720p file and same Flash Player version in use but the gamma was bumped in opposite directions. Lots of variables involved here: Graphics card model and settings, Browser model and settings, Flash Player version and settings, Resolution of the YouTube file (240p, 360p, 480p, 720p), Playback resolution (360, 480, full screen at various resolutions). More testing required, methinks.

>> I made that mistake also until I researched it. That checkbox is only for badly mapped MS DV. For all our HD 709 work, both boxes should be unchecked, giving the correct gamut endpoints. <<

It seems to me it's more straightforward than that. The results are just scaled differently, so you can work with whichever settings suit your target levels or the workflow you're used to (disclaimer: I'm extremely inexperienced with scopes and have never used anything but a Vegas scope so I approach this with no preconceptions but I might be talking rubbish).

Anyway the conclusions are the same, re the Studio RGB to Computer RGB is happening in the browser and not in YouTube or Vimeo's encoder. Basically, if our target is Flash playback on the web then we have to behave just like we did with broadcast, and keep the levels legal.

.... HOWEVER, I'm thrown by this, that indicates the exact opposite of what I'm saying, since it looks like you've got the downloaded mp4 file in there and not a screengrab. Hmmm...

On another tack, quick question re Handbrake settings... Any particular reason why you've chosen "Uneven Multi-Hexagon" ME method rather than the default hexagon?
NickHope wrote on 1/28/2011, 11:05 AM
Another question, Mark... What version of Vegas did you do your MainConcept AVC encode in, and do you know what version of the MC codec was used?

I've just noticed that there's been a quantum leap in the version since Vegas 8...

Vegas 8.0c:
C:\Program Files\Sony\Vegas Pro 8.0\FileIO Plug-Ins\mcmp4plug\mch264vout.dll
Version 2.0.1889.0, copyright 2006

Vegas 10.0c:
C:\Program Files\Sony\Vegas Pro 10.0\FileIO Plug-Ins\mcmp4plug2\mc_enc_avc.dll
Version 8.5.0.14265, copyright 2010

So I'll add a Vegas 10.0 / Mainconcept AVC encode into my testing, unless you used the exact same version.
musicvid10 wrote on 1/28/2011, 11:24 AM
"What version of Vegas did you do your MainConcept AVC encode in"
8.0c. A comparison rendered in the newer MC would be most welcome.

"Any particular reason why you've chosen "Uneven Multi-Hexagon" ME method"
I like the motion detail in the peacock's back better with UMH. Purely subjective, and I recently noticed that setting is very slightly "blockier" at low bitrates and takes a bit longer to render. At 2Mbs, UMH with 0,0 Deblock is about the equivalent of HEX at -1,0 Deblock. Entirely a personal choice.

I'll dig deeper into the levels / gamma / player question when I get back home later in the day. I always like having my assumptions questioned.
amendegw wrote on 1/28/2011, 12:39 PM
"I think when everything is finally on HTML5 protocol, we may see some improvement in browser based playback (and we may have to redo the tests)"Got a Google Chrome Browser? Watch the Peacock, Ducks and Octopus via HTML5 here: http://www.jazzythedog.com/testing/dnxhd/html5.aspx

It actually looks pretty good.

...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 1/28/2011, 12:49 PM
The MC codec version in Vegas 10 is even newer than the version in the 2010 Russian AVC codec comparison, in which it came 2nd to x264. Quite excited that SCS have finally updated it as I've been wittering on for years about how out of date it has been. Rendering a test file with it right now.

I did some other testing today and made some more interesting observations...

1. YouTube downloaded 720p files are substantially larger file-size than the Vimeo files, with higher bitrates in the video stream. Considering the quality is poorer than Vimeo, I was surprised by this.

YouTube:
Video: VBR, Average 3171 Kbps, High 7876 Kbps
Audio: VBR, 127 Kbps - 182 Kbps.

Vimeo:
Video VBR, Average 2017 Kbps, High 6156 Kbps
Audio VBR, 156 Kbps - 215 Kbps.

2. Believe it or not, YouTube is creating a file with a variable framerate. I remember noticing this in the past. From Mediainfo:

Frame rate mode: Variable
Frame rate: 29.970 fps
Minimum frame rate: 29.412 fps

I have absolutely no idea on how or why they might do this, and what might be gained from doing it. Does anyone know? In addition it makes comparison of files on the timeline difficult because the frames don't line up.

3. Your DNxHD render reduced the volume of the audio. Was that deliberate?

It's unlikely I'm going to get any of my tests online before Sunday. I did some encodes and uploads today but if I published them I think I would cause confusion. I made some small mistakes and I need more time to reduce the variables in order to make some meaningful comparisons. Watch this space.
amendegw wrote on 1/28/2011, 1:09 PM
"Your DNxHD render reduced the volume of the audio. Was that deliberate?"Nick, are you speaking of the 2Mbps render I made? If so, the clip was speced at 48kHz/96kbps. I reduced the bitrate from the high quality musicvid recommended - just to help with buffering on web playback.

That said, I wouldn't have thought that would have any effect on volume.

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