I recently got a 1080p projector for home use, so now movies / TV series in my home are viewed on a 100" screen. Content is mostly from Netflix and Amazon Prime Video.
Netflix does a really good job with encoding. I cannot say the same for Amazon Prime Video; even with their exclusive (in UK) offerings, like American Gods or Mr Robot, the quality of the encode is quite poor when viewed on a big screen. Banding, shimmering blocky artifacts on subtle gradients, insufficient bit budget for dimly lit scenes - once you become aware of the issues, it becomes really distracting.
OTOH a really big screen is a fantastic ad for high quality high bitrate content. Anything less than 2GB/hour is noticeably poor.
Say I sit down at a switcher and push the Black button. You'd think nothing would come out, right? Not quite: that switcher will almost always emit broadcast black, not "null," whether it's analog or digital. Sure, you can probably get Photoshop to spit out 0% then encode in some codec that lets you keep 0% and successfully display it on a modern digital television, but the more equipment and encodes you add to a video production the more likely the signal will be pulled up to broadcast black, so it's better to just think of that as black.
There's a similar exercise with white on the upper end. Remember when analog TVs would buzz when you wired up your computer and put RGB white on the screen? That's superwhite.
In MPC there's an option Render Settings > Output Range > 0-255 or 16-235. When set to 0-255 (default) my videos play with full black.
To wit: HDMI does allow for 0-255 (or 1023, etc) "full range" quantization instead of the default "limited range" of 16-235 for most CEA-861 formats, if the sink's EDID allows a selectable YCC quantization range and the source sends AVI YQ=1.
Or even getting to the "plain black image full #000" remark that prompted this thread, images are basically always full range where black is 0 and there is no "superblack" concept. If it's being transmitted over HDMI, it's up to the GPU to do range conversion and RGB/YCbCr conversion as necessary, and up to the OS to do ICC colorspace conversion as necessary.
Sigh. Another unique pleasure of HN.
Sometimes there's a difference between practical and possible. I did not say it was not possible. While you're technically correct, the worst kind of correct, very little content and few delivery systems actually utilize that capability -- look how much you had to type just to get there. Then how are you going to deliver that alternate colorspace content? To wit: I note you've overlooked ATSC and other delivery mechanisms, as well as HDMI being a specification designed to handle all cases including non-NTSC-legacy regions which had a different colorspace all along (notably PAL, which defined "blanking" and "black" as equivalent).
Practically speaking, pretty much no content you'll ever play makes use of wide gamut in North American contexts. If you're cooking a file for yourself, that's one thing, but once you're producing something that's mass consumed there's a lot of compatibility issues to worry about. We still have fractional frame rates and picture safe zones, for crying out loud, despite drop frames being pointless for decades and overscan being a word nobody under 30 has heard. What's the point of leveraging wide gamut in HDMI if all your capture equipment, editing tech, broadcast delivery, playback equipment, and displays cannot handle it? For the general case you're counting on Vizio adding that ability into a $200 TV and Comcast handling it in their CPE. Good luck.
Why does that matter? When producing video content handling a wide array of distribution media matters. Except for circumstances where you control the entire system end to end, such as a planetarium or some other kind of venue, you always have to plan for your content potentially being sent over lame, legacy-style HDTV broadcasting. That's the floor. Sometimes you even have to think about SDTV transmission; God help you, and have fun with chyrons...
Not even Rec. 2020, which is designed for UHD and is way better, changed this. It's not a concept that's in dispute, despite whatever HDMI -- one standard of several hundred that are involved in delivering you a single TV broadcast -- can do.
1. You asserted that 0/0% in image codecs was superblack. The most common codec for which that is actually true is WebP, which I'll bet no one in this thread actually cares about.
2. In digital colorimetry, gamut and range are orthogonal. Gamut is the space of real colors a given colorspace encompasses, range is whether the digital signal is quantized to 85% of the theoretical bitdepth and is what we've been talking about. Rec 2020 very much does increase gamut, as mentioned in your link.
3. Studios are actually starting to master in full-range 48-bit RGB (or XYZ technically, I think...) But yeah, that's irrelevant to end-users and this discussion.
4. Yes, everyone has been talking about PCs and how they render / output to TVs. That's why images and MPC were mentioned; broadcast doesn't deal with images. Computers deal with full-range RGB; that's literally the framebuffer format everyone renders everything to. As such, they convert video's YCbCr to full-range RGB before HDMI or TVs come into the picture; MPC's setting mentioned earlier is to ignore what the file says about its YCbCr range when it performs that conversion. Because while there are video files on the internet that set the wrong range, there are also internet video files that are legitimately full-range. And I'm not even talking about ancient codecs using palettes or VQ.
And since computers have traditionally outputted full-range digital RGB signals (over DVI, DisplayPort, LVDS, etc), they do indeed negotiate full-range RGB over HDMI when possible. And yes, even $200 TVs generally support that nowadays.
Heck, if you created a full-range H.264 file, tossed it on a thumb drive, and stuck it in your TV, I'd be willing to bet most if not all modern TVs play it correctly.
I did not assert that 0% in image codecs was superblack. I specifically mentioned Photoshop to avoid pedantry with someone coming along and saying "but nonlinear editors won't emit superblack unless you force them to!", not to talk about image codecs. You did that, and I ended up with more pedantry than I had bargained for in this entire thread, so that was a pointless exercise. As was sharing my perspective at all, honestly; I'm a professional video editor with credits (where "gamut" is a common term to discuss this phenomenon, despite your doctorate in colorimetry), not a video engineer. I apologize for speaking out of turn, and will defer to your expertise in the future.
The irony is that you responded to someone making a joke about the exact thing that you're doing. Please, just stop.
You are the reason I hate this community. "Oh, neat, a thread I know something about. Let me try contributing. Oh, look, now I'm in a slapfight with a guy who develops codecs for a living who completely missed the point of what I was saying and the context thereof, and wants to correct my usage of an incorrect term because it's his area of expertise. Let me rush to contribute more."
HN: The Game of Being More Right Than Everyone Else. Congratulations on winning. I'll go play something productive.
Edit: This was left when the parent comment said "Sorry, I only develop video codecs for a living," and it has now been rewritten. I'm leaving mine and I'd rather my whole subthread just be detached and deleted at this point
But if a video cannot play with the black in the video being the darkest black my monitor is capable of, there is a problem there. Maybe it's some inherent problem with standards or formats or something. But if a video wants to show black, it should display on my monitor as dark as the monitor supports.
A good broadband connection is limited to a sustained rate around 13-18 Mbps.
Banding (which I think is the root cause of all your complaints) is effectively due to overly coarse quantization. This is amplified in H.264 (which Netflix and Amazon generally use) since the signal has multiple 8bit -> 10+bit -> 8bit trips, with each 8bit reduction contributing additional errors that can effectively result in small changes between blocks in the input signal amplified into noticeable differences in the output. And it's more noticeable in low-light scenes since current standards' gamma transfer functions compress a bit too much on the lower end (maybe my personal opinion there...)
The easiest solution is to have more discrete steps at each intermediate point. But for that to really help you'd need to change codecs from 8-bit H.264, which means not being playable on many devices. I mean, you could get 15% finer quantization with full-range 0-255 over video-range 16-235, but that doesn't help that much; you really need the 4x that 10bit gives you to be noticeable.
The second easiest solution is to have a debanding postfilter. But between the wide variety of platforms Netflix/Amazon have to run on, and modern DRM requirements, that's also not really an option.
So ultimately, you're left with developing prefilters to try to shape where bits are needed for given scenes, and careful tuning of your encoder. Which Netflix (presumably) has a several year head start over Amazon on.
When did we decide that 24/25/30fps was good enough? Now we have a Blu-Ray standard that cannot handle greater than 30fps, and media corporations that are unwilling to release content via any other medium.
Put that together with ever-increasing resolutions, and the amount of pixels something moves across from one frame to the next becomes greater, and video looks more and more choppy.
Franky, this is a much bigger problem than NTSC ever was. Even with content (The Hobbit, Billy Lynn's Halftime Walk) being created at higher framerates, users have no way to get the content outside of a specialized theater because the Blu-Ray standard cannot handle it, and because people seem to honestly believe that higher framerates look bad.
I suppose we can only hope that creators take better advantage of digital mediums that do not have such moronic, and frankly harmful, arbitrary limitations.
Yes, but it all depends on what you are seeing. Games look fantastic, VR probably looks great.
For movies, I'd stick with 24 fps, as it keeps the "style" of film. Subtle things like the motion blur produced at that framerate and how we see/expect the movement in the screen are altered when the framerate changes.
As with a lot of things, it depends on what you want to achieve!
If what you wash my to achieve involved a lower framerates, go for it. The problem is that 24fps is considered the "standard", and film producers receive a ridiculous amount of backlash for creating any HFR content. There are 2 major films I know about (4 if you count the other two Hobbit films) that use higher framerates. Since I didn't go watch them in theaters, I have no way to see them in their original framerates.
> Subtle things like the motion blur produced at that framerate...
We expect 24fps quirks like motion blur because we have spent the entire history of film conditioning ourselves to prefer it. There are even expensive ways to render what appears to be motion blur so that we can simulate 24fps film in CG.
To contrast with the entire history of film (until recently), many people, like me, have UHD panels to watch film. At such a high resolution, the amount of pixels that motion blurs over has increased significantly. To make a clearer picture, most major studios record at a higher framerate to minimise motion blur, even if they intend to show every other frame. That means that most motion looks very choppy, as it jumps hundreds of pixels each frame. These films would be beautiful at higher framerates, but practically no one is willing to fight the "industry standard".
Broadcasters seem way less inflexible as the were back then, with television devices no longer costing multi-month salaries in most regions and whole standards like analog transmission and DVB-T 1 being already phased out and the current replacement rates being somewhere significantly under 10 years. Breaking legacy standards is no longer a no-go.
BluRay is not the problem, the display devices which support only older HDMI standards are, then again their whole hardware capabilities rarely exceed them either.
I doubt to see another consumer standard gaining any widespread adoption for physical distribution, when YouTube does already stuff like 8k@60fps and beyond. The expensive part now are the +4k display systems, not their media boxes (fire sticks, chromecast, set-top boxes, gaming consoles), which are cheap and can handle almost anything they have compatible hardware decoders for.
There are UHD BluRay players for less than USD 200, it's up to the studios to release content
I wasn't aware until now that UHD Blu-Ray supports up to 60fps. At least they have that going for them.
Everything looks weird at 48/60fps
Similarly footage shot with digital cameras is often modified to look more like film. There's no objective reason for it most of the time, people are just used to the artifacts of film. Anything else "looks weird". Now stuff like lens flare, shaky cameras, etc, are added to shots made entirely in CG!
I can get past that stuff because it doesn't make the quality that much worse, but low fps definitely does. What's the point of having super high resolution 4k display, if the scenes displayed on it are incredibly blurry from a low frame rate?
> Everything looks weird at 48/60fps
Everything looks jarringly different in 48/60fps. That does not make it bad. For several technical reasons, higher framerates look better. If you really want 24/30fps, you can always get it. Just like you can have grayscale on a color display.
I use Smooth Video Project to interpolate frames when I can (anything without DRM), but that still leaves me with a blurry picture, and artifacts. Even so, it's a more comfortable experience, especially with camera panning.
I'll fix these attributions but also feel free to point me more or even PR.
This is a very well written introduction
Even in still-image compression, the difference is noticeable --- I have some high-resolution PDFs containing JPEG2000 scanned images, and they take significantly longer to render than the equivalent containing JPEG images.
Similar techniques as the ones used to optimise DCTs
could be used for wavelets.
There has just not been a demand.
The standardisation effort tends to swamp out all alternatives
once the decision to choose the algorithm has been made.
There's a huge amount of momentum behind the standard
which makes alternatives very hard to pitch.
This is part of the reason why the same basic technique has been in prevalent use for 20 odd years and nothing else has come into play
It truly was the dark ages of digital video with low frame rates and postage stamp sized windows.
a) multiple types of media data are encoded independently and then bundled together in what essentially looks like an endless file (called a stream file). So when given a chunk of such a file, the decoder needs to quickly identify the nearest offset in it where it can begin decoding simultaneously all the individual media it needs. This is called "access point". Decoding cannot be started at any random place in the stream, as it generally requires context (so an access point allows to start decoding with the context being empty for all required media -- audio, video, graphics, subtitles etc). Stream file formats (called containers) are designed to solve this, provide access points to the decoder, as easily and frequently as possible.
b) a decoder, when driven by a running presentation device -- video screen, audio amplifier etc -- is essentially a pump. The encoder can be looked at like a pump too, when they are separated by network. If decoder runs faster than the source feeds it, it will drain the pipe and will make the presentation device run idle (which will be noticeable to the consumer). If it runs slower, at some point it will be drowned in data from the source. So the pumping rhythm needs to be maintained identical between both ends. The most practical way to synchronize the "piping clocksource" is via the stream file itself (which has to carry time sample data for that). Again, different containers solve this differently (some not at all).
EDIT: I didn't mention (should go into b)) the effort to make constant the throughput of the pumping -- "constant bit rate", as I believe with the advent of transport schemes which require point-to-point connections (as opposed to multicast streaming), the importance of this goes lower now.
Machine learning becoming more and more popular will probably help :)