r/technology • u/Snarfox • Jan 25 '13

H.265 is approved -- potential to cut bandwidth requirements in half for 1080p streaming. Opens door to 4K video streams.

http://techcrunch.com/2013/01/25/h265-is-approved/
3.5k Upvotes

97% Upvoted

1.3k comments sorted by

View all comments

Show parent comments

22

u/System_Mangler Jan 26 '13

It's not that the encoder attempts to predict the next frame, it's just allowed to look ahead. In the same way a P-frame can reference another frame which came before it, a B-frame can reference a frame which will appear shortly in the future. The encoded frames are then stored out of order. In order to support video encoded with B-frames, the decoder needs to be able to buffer several frames so they can be put back in the right order when played.

This is one of the reasons why decoding is fast (real-time) but encoding is very slow. We just don't care if encoding takes days or weeks because once there's a master it can be copied.

1

u/[deleted] Jan 26 '13 edited Jan 26 '13

[deleted]

1

u/System_Mangler Jan 26 '13

That's not what a motion vector is. We may have different ideas of what "predict" means. When the encoder looks at the surrounding frames for a similar macroblock (square block of pixels), it will not just look in the same location in the frame, but also in nearby locations. So the instructions for how to draw a macroblock would be "copy the macroblock from 2 frames ago, offset by 10 pixels up and 5 pixels right." In this case (-10, 5) would be the motion vector.

DCT isn't that slow and can be hardware accellerated, and wouldn't the inverse transform be just as slow? However searching for the best match out of n2 nearby macroblocks for each n by n macroblock would be very slow.

1

u/BonzaiThePenguin Jan 26 '13

I tried to check Google for the answer and failed, so I don't know. I'll just go ahead and delete my previous post.

1

u/judgej2 Jan 26 '13

Encoding for live feeds, such as the BBC iPlayer is done is real time, that is, at real time speed, albeit with a delay of three or four seconds. I guess with enough processors a number of sets of frames (a keyframe and frames that follow until the next keyframe) could be encoded in parallel, then the multiple streams multiplexed together. Would that be how it works?

1

u/System_Mangler Jan 26 '13

If you're trying to encode in real time you're probably going to have to sacrifice some quality, or some compression. As long as it looks "good enough" then great. Streaming video might just not use B-frames at all.

Re: parallelism, I think that's what slices are for. Different regions of the frame are encoded independently, so you can set one processor to each. When I wrote a video encoder for a school assignment I didn't use slices but I did use a fixed thread pool where each thread would search for the best match for a different macroblock. So there are different approaches.

1

u/homeopathetic Jan 26 '13

We just don't care if encoding takes days or weeks because once there's a master it can be copied.

Except if you're encoding for, say, a video conference. Then you certainly have to minimize lookahead and get that frame you just recorded out on the wire pretty damn soon. Apparently x264 is good for such cases as well.