Posted Without Comment

john_dennis wrote on 2/18/2015, 1:07 AM
Let the videos in this playlist loop in full screen at 1920x1080 and draw your own conclusions.

Comments

dxdy wrote on 2/18/2015, 6:49 AM
Very interesting. Thank you.

What bitrates did you upload to Youtube for this demo?
PeterDuke wrote on 2/18/2015, 7:35 AM
I asked a question here so as not to hijack this thread.
http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=918778
Hulk wrote on 2/18/2015, 7:41 AM
Thank you for doing this.

I'm seeing a lot of the same artifacts I always see from these encoders. Macroblocking on really high motion like the water fountain, those "twinges" where parts of the screen pop in and out of focus, most likely more contrast than the original video (loss of detail in whites/blacks) and an overall "harder" look to edges of objects.

It's hard to know exactly without seeing the original source video how much degradation has occurred.

I always use Ripbot for encoding (frameserve from Vegas). I find it much better than anything in Vegas at a much lower bitrate. Try Ripbot on this video at 8mbps, I bet it does really well.

Or if you can upload the source somewhere I will compress using Ripbot.

Again, thanks for taking the time to do this. I've done these tests before and they can turn into real "time vampires."

Mark
JJKizak wrote on 2/18/2015, 8:44 AM
All of them blink with judder. I don't like any of them. But then again I am far from an expert.
JJK
john_dennis wrote on 2/18/2015, 8:51 AM
@dxdy

The full Mediainfo reports are in the Description panel for each video. When you take the link you'll land at a playlist. There you can select Play All or each video individually. If you go to the individual video page and "Show More" you'll see all details of the uploaded video from Mediainfo.
Hulk wrote on 2/18/2015, 9:08 AM
@JJKizak,

"Blink with judder"

That's what I mean when I wrote I see little spots blinking in and out of focus. That is the one artifact that almost never happens with Ripbot and why I like it so much. That artifact is more annoying and distracting than the others to me.

Former user wrote on 2/18/2015, 9:28 AM
The highest resolution available for playback I see listed is 720p... UPDATE: Using Chrome I can see the 1080 version.

musicvid10 wrote on 2/18/2015, 10:29 AM
[EDIT]

Got the HD playback on Chrome. Both the Sony AVC and Mainconcept AVC show degradation in high motion areas. If the Handbrake seems to stutter more, try lowering vbv-maxrate and vbv-bufsize proportionally in advanced settings. Don't know how that will actually affect the output.

No comments on mpeg-2 source, it's good as expected.
wwjd wrote on 2/18/2015, 10:41 AM
are we learning which renders are just better overall? or which renders are better FOR YOUTUBE compression?
johnmeyer wrote on 2/18/2015, 10:50 AM
1. I see all videos at 1080p, using Firefox 35.0.1 and Flash 16,0,0,305.

2. I was only able to download at 720p, so that hampers my comparison.

3. Comparing my 720p versions on the Vegas timeline, no clear winners, but two clear losers: Mainconcept MPEG 2 Blu-ray and Sony MXF HD EX 1080 24p. Both lost lots of shadow detail.

4. The ripples on the water in the pool are a torture test for encoders. I don't have the original, and without that, this whole test is rather pointless. However, making an educated guess, having see a lot of swimming pool water, nothing holds up as well as Handbrake. The two Mainconcept encoders (MPEG-2 and AVC) do the worst job keeping ripple highlights.

5. Another important check for an encoder is retaining detail in flat, almost-featureless surfaces. The brown pavement in the opening shot is a perfect example. I zoomed in, using the identical pan/crop, and saw a huge difference between the encoders.

As always we are left wondering what is causing the differences: are the differences caused by subtle differences in encoder settings; how much from the conversions performed by YouTube; how many of these YouTube conversions could be avoided by doing the proper upload (e.g., making sure the upload is set for "fast start"); how much alteration is done by the playback software (which I took out of the equation by downloading), etc.

Playback is clearly one of the biggest problems in doing comparative tests with YouTube. The difference in video quality in looking at the same video from a fast computer, connected via HDMI to my big screen, and playing that same video from an Xbox 360, also connected via HDMI, is night and day: the Xbox is much better.

Finally, all my download clips are 23.976 fps, but when viewed on YouTube via a 15 mbps connection, I found the playback far from smooth (even worse than normal 24p), no matter which clip I was viewing. I don't think my Internet connection (which is reasonably decent) has anything to do with this, but instead it has something to do with Flash or Firefox. As mentioned above, everything plays great from the XBox, but I cannot get playback that looks as smooth on any of almost ten computers that I use from time-to-time.

So, I guess this once again proves the value of the Handbrake workflow, but also points out the difficulty in measuring comparative quality because of the number of variables involved.

One thing for sure: none of us can really tell anything without access to the original clip.



john_dennis wrote on 2/18/2015, 2:15 PM

I watched a version of this on a "corporate" PC monitor and was shocked at the contrast until I went into the Intel Graphics and Media Control Panel and changed the Media Settings from this:



to this.



We don't use the word calibration around here.

farss wrote on 2/18/2015, 2:20 PM
From my experience with content on YouTube making some effort to control what the camera sees will have more impact on the final outcome than all the other factors combined.

None of us can control the lighting when shooting such events but I would think a polarizer and/or a ND filter in front of the lens would have helped.

Bob.
johnmeyer wrote on 2/18/2015, 3:41 PM
John supplied me with a "near-original" in MXF format. It is 23.976 fps 1920x1080 progressive.

I lined it up on the timeline with the 720p versions I downloaded from YouTube, and was amazed at the amount of detail that had been lost. The lifeguard in the foreground of the pool race footage has a tatoo! Who knew.

I am going to try a different way to download the videos and see if I can get 1920x1080 versions. At this point I don't know how much of the degradation is from the quality of what I downloaded.

So, the spatial quality doesn't look so good, but that may be due to how I downloaded from YouTube.

The good news is that the levels do not appear to be shifted or clipped.
johnmeyer wrote on 2/18/2015, 6:04 PM
I was able to download 1920x1080 versions. My earlier conclusions still stand.

I then used the MXF "original" and did my own encoding and upload test. I used the MeGUI workflow (similar to Handbrake) that was created in these forums several years ago. The quality of the MP4 encode, prior to upload was virtually indistinguishable from the original. I then uploaded to YouTube and compared playback to the five versions that JD uploaded. Mine might be marginally better spatially, but mine has some subtle issues with color shifts, especially in the reds.

I then downloaded what I had uploaded and looked at that compared to the versions I had downloaded from JD's work. Once again, there was a huge amount of detail lost.

So my conclusion is this: with YouTube, you get what you pay for.


[edit]Here's my version, FWIW:



As with JD's video, you have to manually change the resolution to 1080p. I don't know of any way to force YouTube to start playing in that resolution.

farss wrote on 2/18/2015, 6:32 PM
Just playing it back the default way YT presents the video, the 240p version looks slightly better than the 1080p version due to less aliasing.

Bob.
john_dennis wrote on 2/18/2015, 10:34 PM

I added John Meyer's Megui encode to the playlist so all can be watched in the same group.

I added a version encoded in Ripbot by Hulk to the playlist. He used the 35 mbps MXF source file as his input to Vegas Pro.

His comments:

"I have transcoded your clip by frameserving from Vegas Pro 12 to Ripbot. See below for link.

I let Vegas match properties of your clip and used Debugmode frame server.
Ripbot was set to 8192kpbs for video, 128kpbs for audio, two-pass, and everything else left default.
8192kpbs appears to be the max bit rate allowed in Ripbot without figuring out a way to access the encoder. Honestly it's so good I haven't really had the need to go higher. As long as the video to be encoded has enough static sections the encoder can "save" enough bits for the dynamic sections. Your example clip plays back between 4mpbs and 13mpbs in this Ripbot transcode.

You can view/download the result below. Perhaps you could upload to YouTube for a comparison?
The Ripbot example is almost half the size of the other clips but I think it holds up pretty well."