There is a readable white paper explaining h264 High Profile and its implications for streaming delivery here. Since there are a lot of urban myths about what High Profile is and does, it is recommended reading for anyone making such decisions for their own video.
Ah, it seems that just as we finally get computers powerful enough to process H.264 Baseline Profile with reasonable performance, someone raises the bar again. Do we need the extra complexity of High Profile just for the sake of a 2:1 compression advantage?
"Do we need the extra complexity of High Profile just for the sake of a 2:1 compression advantage?"
Polycom sells the hardware/software/services for the endpoints. They see the improvement in the throughput of the "pipes" as a sales opportunity.
The paper was instructional. I read it at lunch.
The thought occurred to me on the drive home that one animated video conference member with a hound's tooth coat could negate all the benefits of high profile.
Just as a touchpoint; I (and Jerry and a few others) like a dumbed-down Main profile for almost everything, even High Def.
Meaning dumb enough to play smoothly on anything, and dumb enough to open and preview reasonably in Vegas! No 8x8 DCT, No weight-p, No b-pyramid, or other resource-sucking decoding hindrances. About the only thing dumber would be to give up CABAC and go Baseline, but even I'm not willing to give up that compression advantage.
Going "dumb" means a huge advantage in encoding times (up to a 30% reduction over High profile, and 50% over Vegas), and the extra 2-5% in file size isn't an issue, and won't be until I begin large scale internet deployment (ha!). (Our tests were run in Handbrake using Kimberly's "Ducks" to challenge the ME). * High - default 4:49 100% 32.0MB
Point being, most people see the words "High Profile" and instantly think it means higher quality, and maybe a free kitty, but that just isn't the case.
AlenK,
I think you are missing musicvid's primary area of interest...
"There is a readable white paper explaining h264 "
Certainly, the High Profile is used to advantage where the front-end processing equipment is up to the task, the transport pipe is big, reliable and the delivery hardware is quite standard as in Blu-ray players. I suspect musicvid is concerned with software encoders and decoders running on various hardware which may or may not be up to the task. Add to the mix network connections with varying bandwidth and latency. It's in that dismal, murky quagmire that he and Jerry are trying to optimize processing time, throughput and picture quality...
...as well as have a little fun while they are doing it.
There seems to be a lot of information on this subject in the security industry. Here is another link that is a fair primer for those who might want to know more.
I have a security system with eighty-four analog cameras and two DVRs. This article has sparked my interest in IP cameras and other means of routing and storing security video. Someday that old system will have to be replaced...
"I suspect musicvid is concerned with software encoders and decoders running on various hardware which may or may not be up to the task. Add to the mix network connections with varying bandwidth and latency. It's in that dismal, murky quagmire that he and Jerry are trying to optimize processing time, throughput and picture quality."
John Dennis wins the free kitty.
Because it was (regrettably) named "High" Profile, people instantly think it is "better," rather than just "harder to play." As such, they will cling to their ridiculously contrived encoding settings instead of considering the down-to-earth advice that those same settings may be the cause of their playback problems, on local and network PCs, media servers, and in some cases, from their own internet servers.
"...as well as have a little fun while they are doing it. "
+1
High profile would certainly cause hardware that's not up to the task to stutter or even not decode optimally.
On the other hand high profile will reduce the amount of bandwidth required to deliver content at the same quality.
What's not clear is if for the same bandwidth high profile delivers higher quality. The article makes no mention of this which is understandable as the focus is on video conferencing.
There is a point of radically diminishing returns, beyond which raising the bitrate further will not increase the detectable quality. Adding High Profile may reduce the bitrate at which the point of optimal quality in motion areas is reached, but it will not increase the quality beyond that point.
On the other hand, at a given bitrate that is suboptimal, invoking High Profile parameters while maintaining that bitrate will have the effect of better quality, up to the point where optimal quality is approached.
I think it is the latter ambiguity that contributes to the misapplication of High Profile by many in the belief that it will somehow improve h264 quality. That only holds up at lower bitrates, where size/bandwidth considerations have already trumped quality from the outset.
Unfortunately, having better compression at lower bitrates is not an option for most pre-2010 portable devices and phones, which barely support Main and in some cases only Baseline; the latter plays well but takes up a lot more space.
The point about maintaining quality in motion areas is particularly important, as Jerry demonstrated in his "talking head" tests. In fact, High, Main, and Baseline all play at perfect optimal quality at around 160 Kbps at 720p if the material is a slideshow. That is the nature of intraframe compression. On the other hand, high motion / high detail scenes may require 21-25 Mbps to maintain optimal quality. The extra few percent compression advantage of High Profile in that case is important for streaming content delivery, or fitting as much material as possible on a card or optical disc, but not as much for home PC and LAN delivery, especially if it stutters on playback as a result of unraveling the extra compression.
I certainly agree with the thrust of what you're saying. In general all the work that goes into the MPEG encoding systems is focussed on delivery the same quality at lower bandwidth. This was pointed out to me many years ago by one of the Canopus engineers who said if you want the best quality and have bandwidth to burn MPEG-1 is the best.
There's another aspect to this worthy of consideration. What if the media is not being directly streamed but will be re-encoded e.g. by YouTube. In this scenario I'd really suggest high profile could be past the point of diminishing returns and into negative returns.
I have no science to back this up however I'm pretty certain that the smaller block sizes used by high profile can create a problem when the content is encoded again by an encoder that doesn't / cannot use the same block size. I've noticed this a lot from various post over recent years when less than ideal H.264 is encoded to MPEG-2. It can really start to fall apart quite badly and I have no reason to imagine the same might not happen when sending high profile to YouTube. It probably gets worse with YT's VP8 codec if I correctly read comments by one of the X.264 developers.
That's entirely correct in theory, Bob.
The problems we noticed during a year of testing is that Youtube is more inclined to reject, garble, or go out of sync if it is given a lot of High Profile stuff. And variable frame rate (another little trick used to squeeze more bandwidth) was really a problem. Motion estimation also seems to improve when we stuck with a dumbed-down Main profile as suggested in the tutorial. I have an unsupported theory that b-pyramid degrades motion detail in successive generations. cabac=1 / ref=2 / deblock=1:-2:-1 / analyse=0x1:0x111 / me=hex / subme=6 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=2 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=0 / keyint=300 / keyint_min=30 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=3 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00