Processing power for H.264... YoutubeHD vs Vimeo vs ???

[poisondeathray]

I'm talking about "studdering" in this post, not "tearing" as jagabo addressed above:

quad desktop - ok
dual core laptop - ok
single core laptop - ok except fullscreen, some sequences studder

I can't reproduce the studdering except on fullscreen mode on my old single core athlon laptop

I can't explain why it only occurs sometimes for you, but yes the explanation for general studdering is the combination of settings, bitrate, resolution is too much for that CPU to decode. In this case you might (a) lower the settings as discussed (I would drop the ref frames first), or (b) try VBV buffer to cap the max bitrate.

If you use a bitrate viewer or stream analyzer, you will see these periods of studdering on old pc's correlate exactly to bitrate peaks, such as I frames



These are you actual min/max
real max : 3 912 643
real avg : 2 068 649
real min : 11 508

So if you cap the bitrate you may smooth over playback for older PC's, at the expense of quality degredation of those scenes that actually require high bitrate (e.g. action seqences, explosions, lots of visual noise). To cap the bitrate using VBV, you would use --vbv-maxrate and --vbv-bufsize . I may sound like a broken record but again, this is all about tradeoffs

[The111]

You need a player that supports video overlay to avoid tearing. Web based players do not support this.

Tearing occurs when the frame buffer is updated by the player while the graphics card is displaying it. You end up seeing part of two different frames in one redraw cycle. The solution is to change the frame buffer only during the vertical blanking interval. This is usually done by double or triple buffering and changing the video overlay's frame buffer pointer during vertical blanking.

You lost me in that last part about the "solution." Is that a description of something I can do to the media render to fix the problem, or is that a description of how non-web players fix it during playback?

I don't see nearly as much tearing on YoutubeHD and Vimeo as I do on my own videos... even the 480p 1200kbps ones seem to tear quite a bit.

[lordsmurf]

MainConcept Reference is better than x264, simply in how much better the playback seems to be, the encode speed, and by all means the stability of the software. The freeware H.264 encoders are simply lacking in quality. I'm sure enough screwing around with settings will get you some nice results, but that's best left to hobby folks that love to tinker. There are already enough things to tinker and tweak with, both in MC Reference, and in the other steps you often need to take before converting to the stream.

Do I have problems loading Vimeo, Hulu or YoutubeHD? No, not at all, nor do I have issues loading the videos I create for other large sites.

Drop your bitrate to about 1000k, use VBR, and allow for up to 2000-3000k max. Consider 640x360 for your widescreen, and scale it up to a larger viewing window. Trying to display 1280x720 in a web browser is like pissing into the wind and trying to not get wet -- it doesn't work too well. If you really need such sizes (and most people do not, even when they think they do), allow it for download only, and then give links to VLC and GOM Player. Keep the display version smaller.

You also need to increase the length between reference frames, 33 is the standard, but can be tweaked more or less based on content.

Video needs to be pre-processed, optimized for web streaming. If you get noise on your encodes, your source video often isn't clean enough. That's a whole 'nother conversation there.

[jagabo]

This is usually done by double or triple buffering and changing the video overlay's frame buffer pointer during vertical blanking.

You lost me in that last part about the "solution." Is that a description of something I can do to the media render to fix the problem, or is that a description of how non-web players fix it during playback?

That solution has to be built into the media player software -- Adobe Flash Player in this case. There's nothing you, as a user of the software, can do about it (except sometimes the software has an option to enable/disable the feature).

[The111]

Trying to display 1280x720 in a web browser is like pissing into the wind and trying to not get wet -- it doesn't work too well.

The most common display these days (if I had to guess) is 1280x1024. All of my flash videos have a fullscreen option.

[poisondeathray]

MainConcept Reference is better than x264, simply in how much better the playback seems to be, the encode speed, and by all means the stability of the software. The freeware H.264 encoders are simply lacking in quality.

x264 encoder and Mainconcept AVC encoder both comply with the MPEG-4 Part 10 ISO 14496-10 standard, and the playback will be similar using similar settings with the Adobe Flash Player - I can prove this by posting encodes. If the video was redone with MCR instead - with similar settings - it won't "magically" improve playback LOL. The troubles "The111" has had with streaming playback are due to the frame size, bitrate, settings, and end user system configuration, not the choice of encoder. If you use the same settings as YoutubeHD (many of their HD encodes are using x264 encoder now, just lower quality settings), guess what - surprise, surprise - it will playback the same and will look just as crappy!

I strongly disagree with the statement that "freeware h.264 encoders are simply lacking in quality". If that blanketed statment refers to something like Super, then I agree, but you can't lump x264 encoder into the same league. Many people actually choose to render to lossless or frameserve out so they can utilize x264 and avoid using Mainconcept AVC. This very question gets asked at least a several times a month on the various forums.

I'm not making unsupported assertions here - I'm providing examples , screenshots, tests. I've extensively tested both, and several iterations of Mainconcept encoder including Mainconcept Reference 1.6.1 which is based on the SDK 7.5.0.35746. The SDK version actually has more options inaccessible by MCR, and is "unlocked". While "quality" is a subjective attribute, and you should examine more than 1 frame, etc, etc.. - and I have - but just for simplicity and display purposes I've posted comparisons, and posted a link earlier in this thread https://forum.videohelp.com/topic358132.html (scroll down),and here are some more done by Dark Shikari: http://mirror05.x264.nl/Dark/website/compare.html , note this comparison is outdated and x264 has significantly improved since this comparison. These aren't observations based on 1 or 2 unique cases, I've literally done 100's of tests with different types source material., different settings, across different scenarios. These comparisons are conducted transparently, with freely available sources, so you can repeat these tests if you want. There is no hidden agenda here; I'm just sharing my observations, and I claim that the free x264 encoder does a better job than Mainconcept AVC most of the time.

-x264 is free, frequently updated and improved.
-Mainconcept AVC is more efficient and better at MBAFF / Interlaced encoding and encoding slices than x264
-Both are good , but x264 generally retains more detail and produces a sharper image; Mainconcept AVC produces a smoother image
-Default x264 psy settings can ruin the image by adding too much noise and "haloing" artifacts, this is intensified at low bitrate scenarios
-Mainconcept AVC lacks several important options: zones, psy opts, lumininace / complexity masking (it actually has a rudimentary version in the sdk version). If you don't think this matters, have a look at the "forest" example. Even HCEnc (a fricking MPEG2 encoder!) does better than Mainconcept AVC both at ~2000kbps because it has AQ . Conversely, x264 only requires 1/2 the bitrate to achieve similar quality when using AQ (x264 looks just as bad as MCR, when useing low AQ values). Hopefully the SDK 8.0 will address these deficiencies.
-x264 is highly configurable, you need at least the MCR or the SDK version to access some important options for Mainconcept AVC. e.g. the bundled version with Vegas is severely lacking which actually prompted the inital thread. Having options is better than not having them.
-I have had no issues with stability with the x264cli encoder, or MCR, but I keep a clean system. However, the unsupported x264vfw encoder does have potential stability problems in my experience.
-Speed of encoding is similar with both, using settings that yield similar quality. Actually if you lower the quality settings of x264 to match Mainconcept AVC's , x264 is slightly faster. While PSNR is a poor measure of quality, it at least gives an objective measure:

FPS:
Mainconcept: 26fps (average over both passes)
x264: 27.5fps (average over both passes)

Mean Luma PSNR:
Mainconcept: 30.87819
x264: 32.87380

x264: blue
Mainconcept: red

I'm sure enough screwing around with settings will get you some nice results, but that's best left to hobby folks that love to tinker. There are already enough things to tinker and tweak with, both in MC Reference, and in the other steps you often need to take before converting to the stream.

While I'm all for simplicity and the KISS rule, the settings used can make or break your video. In fact, the original thread that preceded this one was started because of the poor quality from Mainconcept AVC, and questioning of the settings. If someone is content with mediocrity, then they should feel free to refrain from adjusting the settings. But most of the professionals I know like to produce the best quality for their clients - and most of the hobby folk I know want the same. This is even more important in streaming scenarios, where bandwith is a limitation and you are forced to use the most efficient methods. Even a simple change - for example - the difference between using 1 vs. 3 reference frames provides a massive quality improvement under low bitrate scenarios.

You also need to increase the length between reference frames, 33 is the standard, but can be tweaked more or less based on content.

Incorrect, you don't need to. 33 is the default setting for MC, not the standard. For example, Adobe recommends 300 for streming flash. Ateme uses 50. The only time you need to use a set value is for device compliance, eg. Blu-ray decoding or devices that use the Sigma Designs chip for decoding. I agree the value should be tweaked according to content

Video needs to be pre-processed, optimized for web streaming. If you get noise on your encodes, your source video often isn't clean enough. That's a whole 'nother conversation there.

Completely agree! We addressed this earlier, both in this thread and the initial thread. If you're going bother to optimize your video by pre-processing in the first place, why not go the whole way and optimize the encoding settings as well?

Cheers

[The111]

While I'm all for simplicity and the KISS rule, the settings used can make or break your video. In fact, the original thread that preceded this one was started because of the poor quality from Mainconcept AVC, and questioning of the settings.

Truth. And once again I thank you for guiding me through the x264 jungle to a solution that I'm pretty damn happy with. When I get some free time I'm going to add some lower-res lower-bitrate options (all other encoding settings the same as the 720p 2M renders) to give my viewers a choice.

[ronnylov]

Very nice quality videos there The111!
Looks like you have found a balance between processing power and quality.

I am intersted in this subject too. I am trying to encode x264 with MeGUI to get a good compromise for web streaming but either the quality is bad or the playback is stuttering even if the clip is preloaded. So any hints regarding good x264 settings are welcome. Maybe trying one of the templates for a standalone playback device could be an idea to try?

For instance what is good values on --vbv-maxrate and --vbv-bufsize if streaming a bitrate around 1000 kbit/s and aiming for playback on a 2Mbit/s internet connection (maxrate=2000 maybe)? I think I will stay with 640x360 resolution and 25 fps.

[DarrellS]

Plays great for me. The main issue with streaming media is bandwidth. I have no problem since I have cable internet and your server seems to be pretty fast.

[ronnylov]

I did some experimenting and --vbv-maxrate=1800 and --vbv-bufsize=1800 with average bitrate of 1350 kbit/s video and 128 kbit/s audio seems like good values when streaming over a 2 Mbit/s internet connection. Maybe also decreasing ref to 3 from 8 did help a bit to make it more playable. As usual do some tests and experimenting with settings ofthen helps...