Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The End of Video Coding?

medium.com

Post reply on HN
Print view View original

91–100 of 131 posts

Re: The End of Video Coding?

#91

Post by [deleted] »

isostatic wrote: post #57
jakobegger wrote: post #43

Earlier quoted context omitted.

There is already an 8k display on the market.

SMPTE recommend a viewing angle of 30 degrees, which matches THX (26-36). Assuming you have 20/20 vision, You won't be able to tell the distance between 4K and higher unless your screen fills more than about 40 degrees, in which case you are losing detail at the edges. An 8K monitor on your desk may make sense -- if you're say 3' away from it and it's say 60", you'll start noticing a difference between 4k and 8k, how…

[deleted]

Re: The End of Video Coding?

#92

Post by wilun »

shawn wrote: post #77
wilun wrote: post #70

Earlier quoted context omitted.

I'm not 100% sure if you tried to be ironic or if you really reported that the video was better in 8k than FHD. Because actually, it can be. Although 8k is overkill, 4k will be enough, and 1440p nearly ok on your old 1024x768 monitor. Typically video encoding does some subsampling on some color components. If you play 4k content on a FHD screen, the quality can be better because you will have no subsampling on your F…

It was a stab at irony. True, but the video is already subsampled. That's how it was able to be uploaded at 1080p at all, since the source video is 8k. So 8k vs 1080p shouldn't make any difference on monitors less than M-by-1080 resolution.

The video is typically subsampled at encoding at capture resolution, but it is also subsampled at other encoding resolutions. Because the whole point of subsampling is to be taken into account during encoding, and encoding itself needs not to vary depending on whether the source was downscaled or not.

So video codecs most of the time work with some subsampled chroma components. So your encoded 1080p might be able to render after decoding only e.g. 540 lines of those components, while with the 4k stream it might be: 2160/2 => back to 1080.

Edit: but to be clear, I'm not advocating for people to choose 2x stream and start watching 4k on FHD screens in general, that would be insane. Chroma subsampling is used because the eye is less sensitive to those colors.

Re: The End of Video Coding?

#93

Post by bubblethink »

izacus wrote: post #39
shawn wrote: post #27

Earlier quoted context omitted.

If that’s true, that’s pretty unfortunate. YouTube does 1440p@60fps now.

Yep, but YouTube doesn't require full DRM support.

It most likely does for paid offerings. I doubt you'll be able to watch a paid 4K movie on youtube/google movies unless you satisfy their highest widevine requirements. I think youtube's 1080p requirements may be more relaxed than netflix though. Regular yt has no DRM of course.

Re: The End of Video Coding?

#94

Post by ktta »

majewsky wrote: post #86
ktta wrote: post #82

Earlier quoted context omitted.

>That excess compute is essentially free. Since they host on AWS, wouldn't they just scale down during non-peak times and save money?

The AWS-hosted part is not the CDN afaik, which will probably make up the vast majority of their infrastructure.

If you're talking about OpenConnect, then I think they are really geared to just be a CDN and not much else.

Re: The End of Video Coding?

#95

Post by spenczar5 »

martincmartin wrote: post #44
lostcolony wrote: post #6

Earlier quoted context omitted.

You still care, since at some point the cost of the extra encoder-hours used is going to outpace the bandwidth savings. I'm guessing she mentally assumed 'at no bandwidth savings, how much margin do we have?', since the amount saved wasn't ever quantified.

It's not bandwidth savings. It's growing the user base. There are lots of people on low bandwidth connections. Maybe now they don't find Netflix watchable, because the video quality is to crappy. But if you can fit higher quality video into the same bandwidth, they'd become users. I agree with your overall point though, that at some point the extra cost for encode isn't worth it.

That's part of it, but I think you'd be astonished at how much IP transit can end up costing when you're distributing high-quality video. It's pretty staggering how much bandwidth can cost. I would not be surprised in the slightest if at least 1/4 of Netflix's total engineering spend is on network transit, so any savings that are per-video can have a huge impact.

Source: I work at a company that distributes a lot of high-quality video :)

Re: The End of Video Coding?

#96

Post by oldgeezr »

cc-d wrote: post #52
izacus wrote: post #39

Earlier quoted context omitted.

Yep, but YouTube doesn't require full DRM support.

Requiring protocol level DRM to be included in video/music streaming technologies has always baffled me. What's the point? Even with theoretically perfect protocol level DRM, the consumer eventually has to be able to see/hear the protected content. If the frames of the video are displayed on screen, and the audio played through the speakers, the output can be recorded and preserved, period. Do the people in charge of…

There are many answers to your question but for starters:

- There is no perfect security. There is a notion of raising the expense of piracy to a level that it effectively does not matter.

- IIRC, for instance, rooted Android loses support for... Widevine? So you can't really use Netflix on a rooted device where you could easily steal frames from the video buffer. Yeah, you can rig up a nice camera system and record analog off the display. Nothing they can do about that. They also may insert watermarks to let them know who recorded it.

Re: The End of Video Coding?

#97

Post by [deleted] »

ksec wrote: post #66
lostcolony wrote: post #6

Earlier quoted context omitted.

You still care, since at some point the cost of the extra encoder-hours used is going to outpace the bandwidth savings. I'm guessing she mentally assumed 'at no bandwidth savings, how much margin do we have?', since the amount saved wasn't ever quantified.

Exactly this. I don't know how many times this need to be repeated. If your original encoding cost were 1 Million, 5x or even 10x is only 9 million more. At 100x that is 99 million. 1000x is a billion. Are you really willing to spend a billion on a codec that saves you 50% transfer and a fee million of royalty cost? Especially when Netflix already has the Open Alliance in many ISP DC. Bandwidth cost saving are much l…

[deleted]

Re: The End of Video Coding?

#98

Post by kevin_thibedeau »

21 wrote: post #88
dingo_bat wrote: post #4

It seems to me that despite the tech, Netflix video quality is really horrible. Youtube is consistently much higher quality, even though Netflix's own "fast.com" tells me my connection is capable of 75Mbps downstream. Which should be enough for crisp 1080p. Multiple times I've been so frustrated with Netflix's quality that I've started a movie, stopped it because it looked like something out of a VCR, torrented the t…

Are you sure you have a 1080p subscription? The basic one, single device, is 720p only. You need the two device subscription for 1080p

I have the 720p subscription and Netflix will occasionally drop down to a crummy low res bit rate when playing via a 4k Roku. It isn't pleasant.

Re: The End of Video Coding?

#99

Post by shawn »

wilun wrote: post #92
shawn wrote: post #77

Earlier quoted context omitted.

It was a stab at irony. True, but the video is already subsampled. That's how it was able to be uploaded at 1080p at all, since the source video is 8k. So 8k vs 1080p shouldn't make any difference on monitors less than M-by-1080 resolution.

The video is typically subsampled at encoding at capture resolution, but it is also subsampled at other encoding resolutions. Because the whole point of subsampling is to be taken into account during encoding, and encoding itself needs not to vary depending on whether the source was downscaled or not. So video codecs most of the time work with some subsampled chroma components. So your encoded 1080p might be able to…

I would be interested in a double blind experiment confirming that their specific implementation of chroma subsampling is even detectable. The eye is much less sensitive to colors than intensity, as you point out. If it were perceptible, I think the codec designers wouldn't feel it was an acceptable tradeoff.

So your encoded 1080p might be able to render after decoding only e.g. 540 lines of those components, while with the 4k stream it might be: 2160/2 => back to 1080.

I'm not sure that's accurate -- whatever downscaling process was used to convert from 8k to 1080p on Google's servers is probably the same process to convert from 8k to 1080p in the youtube player, isn't it? At least perceptually.

I would agree that if they convert from 8k (compressed) to 4k (compressed), then 4k to 1080p (compressed), then that would introduce perceptible differences. But in general reencoding video multiple times is fail, so that would be a bug in the encoding process server side. They should be going from the source material directly to 1080p, which would give the encoder a chance to employ precisely the situation you mention.

Either way, you should totes email me or shoot me a keybase message. It's not every day that I find someone to debate human perceptual differences caused by esoteric encoding minutiae.

Re: The End of Video Coding?

#100

Post by MayeulC »

Are there transmission schemes that can transfer multiple independent streams that add up for better quality?

It could be streams containing information about smaller subblocs, etc.

If you take a fourrier transform, the more coefficients you include, the more faithful the reproduction is.

Splitting the quality level into multiple independent streams could have multiple advantages :

- better use of Multicast, as viewers for different quality settings get the same data, so you use approximately the bandwidth for one full quality video instead of full quality + medium + low...

- save on storage space for the same reason - save on transcoding time, as only one pass is needed

- better suited for distributed storage/transmission, on a platform like PeerTube, where every p2p client could contribute back instead of clustering by quality.

I am not working in this field, but I know a fair bit about compression, and this seems a no-brainer to me. Is it already done? Where? Or did I oversaw some issues?

Post reply on HN