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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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
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.
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.
>> 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?
"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.
"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
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:
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.
"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.