video compression

[wanderingfool2]

1 minute ago, apoyusiken said:

since when 177*3600 is 10000?

 

how does real time compression work??

 

i think streams dont need more bitrate than movies soo..

Oops sorry, I mean ~10 GiB/minute.  (177*60/1024)

 

When you are doing things like streaming (over simplification here) is that it sends out an i-frame (so like a jpeg image) of the starting frame, then when the next frame from OBS comes in it generates a P frame (which is essentially taking the i-frame and subtracting the image in the current frame as they should be pretty similar so you will get numbers close to 0)...this is essentially how compression works.  From there it looks back at the previous frame and keeps doing it.

 

It's actually why sometimes you get the weird greyness and then almost silhouettes of motion/people...it usually is because something like an i-frame was dropped so the p-frames are essentially all you have to calculate off of (until a new i-frame arrives).

 

Where things like movies come into play though is that they can calculate off of both i-frames (forward and backwards)....so they can get closer to 0.  Movies also have the benefit of being able to throw more horsepower behind it, and then just send the movie to you buffered (less worry about real time).  So in that respect streams could potentially need higher bitrates to achieve the same quality.

 

 

Nerdy example (simplified down):

Typical stream with 9 frames

12345679

ipppipppi

 

Now frames, 1, 5, 9 are i-frames...so more of the "raw" data, and p is the predicted frames

For streamers they might do, frame 2 - frame 1, and frame 3 - frame 2, frame 4 - frame 3, send frame 5, frame 6 - frame 5....etc.

The reason why they do frame 2 - frame 1 is imagine the following simplified image

Frame 1

128 0

64 255

Frame 2

130 10

64 253

 

When you do Frame 2 - Frame 1 you get

2 -10

0 -2

 

Which is a whole lot easier to compress since the numbers are closer to 0 typically.  

 

The issue becomes if you get something where the transition is large

Frame 1

0 255

255 0

Frame 2

255 0

0 255

Frame 2 - Frame 1

255 -255

-255 255

 

So as you can see now the range is actually -255 to 255 which is a lot larger...typically this doesn't happen as much in real life...but it's an extreme example...but highlights why streaming is different

 

For a movie you have 9 frames:

123456789

ipbbippbi

You have the introduction of b frames, so what b frames do is they look at lets say Frame 5 and frame 1...where a b means it's using frame 5.

 

This means in the above example of frame 2 - frame 1...instead of doing that you could do frame 5 - frame 2...which then it means instead of a range of -255 to 255, you could get back to like the -10 - 10 kind of example.

 

This is where movies  save a lot...movies can also compare different frames as well easier.

So on streaming you have frame 4 looking at frame 3, and maybe frame 2 to see which is better...but for a movie you can have frame 4 looking at frames, 1,2,3,5...so twice as many frames to look at in our simple example to reduce the complexity.  In reality this gets even better the more space you have between i-frames...e.g. you might have it once every second in a video...so streams while looking at 1 - 2 frames back...but movies can get away with looking at all 60 frames to compare against [it's a bit more complicated than that though].  So you are able to optimize for compression...but that has the drawbacks as you now have 30x more calculations to do

 

It's actually why for the exact same video, with the exact same file size you can have drastically different qualities (even if you only use p-frames).  It's because looking back 1 or 2 vs 30 - 40 can mean you optimize for the smallest file size possible with the least amount of compression issues.

 

tl;dr, video compression is a massively complicated subject, where courses in university could pretty much be dedicated to all the tricks techniques etc.  This leads to different results based on the initial settings you choose.  So that's actually why I recommend trying a few and seeing which settings you are okay with (compromise time, space, and quality)

[apoyusiken]

28 minutes ago, wanderingfool2 said:

Oops sorry, I mean ~10 GiB/minute.  (177*60/1024)

 

When you are doing things like streaming (over simplification here) is that it sends out an i-frame (so like a jpeg image) of the starting frame, then when the next frame from OBS comes in it generates a P frame (which is essentially taking the i-frame and subtracting the image in the current frame as they should be pretty similar so you will get numbers close to 0)...this is essentially how compression works.  From there it looks back at the previous frame and keeps doing it.

 

It's actually why sometimes you get the weird greyness and then almost silhouettes of motion/people...it usually is because something like an i-frame was dropped so the p-frames are essentially all you have to calculate off of (until a new i-frame arrives).

 

Where things like movies come into play though is that they can calculate off of both i-frames (forward and backwards)....so they can get closer to 0.  Movies also have the benefit of being able to throw more horsepower behind it, and then just send the movie to you buffered (less worry about real time).  So in that respect streams could potentially need higher bitrates to achieve the same quality.

 

 

Nerdy example (simplified down):

Typical stream with 9 frames

12345679

ipppipppi

 

Now frames, 1, 5, 9 are i-frames...so more of the "raw" data, and p is the predicted frames

For streamers they might do, frame 2 - frame 1, and frame 3 - frame 2, frame 4 - frame 3, send frame 5, frame 6 - frame 5....etc.

The reason why they do frame 2 - frame 1 is imagine the following simplified image

Frame 1

128 0

64 255

Frame 2

130 10

64 253

 

When you do Frame 2 - Frame 1 you get

2 -10

0 -2

 

Which is a whole lot easier to compress since the numbers are closer to 0 typically.  

 

The issue becomes if you get something where the transition is large

Frame 1

0 255

255 0

Frame 2

255 0

0 255

Frame 2 - Frame 1

255 -255

-255 255

 

So as you can see now the range is actually -255 to 255 which is a lot larger...typically this doesn't happen as much in real life...but it's an extreme example...but highlights why streaming is different

 

For a movie you have 9 frames:

123456789

ipbbippbi

You have the introduction of b frames, so what b frames do is they look at lets say Frame 5 and frame 1...where a b means it's using frame 5.

 

This means in the above example of frame 2 - frame 1...instead of doing that you could do frame 5 - frame 2...which then it means instead of a range of -255 to 255, you could get back to like the -10 - 10 kind of example.

 

This is where movies  save a lot...movies can also compare different frames as well easier.

So on streaming you have frame 4 looking at frame 3, and maybe frame 2 to see which is better...but for a movie you can have frame 4 looking at frames, 1,2,3,5...so twice as many frames to look at in our simple example to reduce the complexity.  In reality this gets even better the more space you have between i-frames...e.g. you might have it once every second in a video...so streams while looking at 1 - 2 frames back...but movies can get away with looking at all 60 frames to compare against [it's a bit more complicated than that though].  So you are able to optimize for compression...but that has the drawbacks as you now have 30x more calculations to do

 

It's actually why for the exact same video, with the exact same file size you can have drastically different qualities (even if you only use p-frames).  It's because looking back 1 or 2 vs 30 - 40 can mean you optimize for the smallest file size possible with the least amount of compression issues.

 

tl;dr, video compression is a massively complicated subject, where courses in university could pretty much be dedicated to all the tricks techniques etc.  This leads to different results based on the initial settings you choose.  So that's actually why I recommend trying a few and seeing which settings you are okay with (compromise time, space, and quality)

that was my point. i believe we can further compress live streams once they are over.

[wanderingfool2]

5 minutes ago, apoyusiken said:

that was my point. i believe we can further compress live streams once they are over.

Yes, you can compress it further...but it's all about balancing time it takes to compress, space, and quality.  Live streams could inherently be "compressed" further without any differences in apparent quality (but that will again take experimentation to see how much you can realistically do).

 

Even switching from h264, which it appears to be in to h265 you could potentially cut it by maybe even up to half without really noticing any visual differences (but again it's all about dialing in settings that you think are acceptable)

[apoyusiken]

9 minutes ago, wanderingfool2 said:

Yes, you can compress it further...but it's all about balancing time it takes to compress, space, and quality.  Live streams could inherently be "compressed" further without any differences in apparent quality (but that will again take experimentation to see how much you can realistically do).

 

Even switching from h264, which it appears to be in to h265 you could potentially cut it by maybe even up to half without really noticing any visual differences (but again it's all about dialing in settings that you think are acceptable)

yea i know bro ultimately it is all about trade offs. i study economics and computation is similar in my opinion. actually virtually everything boils down to economics. so it doesnt actually make sense to store these videos without compression and we didnt need much overanalyzing but thanks for your replies. you know it is actually easy to destroy lifelong confusion. the real question is cpu vs gpu vs youtube. normally i'd think a gpu is easily way better than a cpu but some guy said the opposite and i dont have a gpu so i will have to borrow my brother's. i will have to figure it out i guess.

[apoyusiken]

Just now, apoyusiken said:

yea i know bro ultimately it is all about trade offs. i study economics and computation is similar in my opinion. actually virtually everything boils down to economics. so it doesnt actually make sense to store these videos without compression and we didnt need much overanalyzing but thanks for your replies. you know it is actually easy to destroy lifelong confusion. the real question is cpu vs gpu vs youtube. normally i'd think a gpu is easily way better than a cpu but some guy said the opposite and i dont have a gpu so i will have to borrow my brother's. i will have to figure it out i guess.

 

[wanderingfool2]

9 minutes ago, apoyusiken said:

yea i know bro ultimately it is all about trade offs. i study economics and computation is similar in my opinion. actually virtually everything boils down to economics. so it doesnt actually make sense to store these videos without compression and we didnt need much overanalyzing but thanks for your replies. you know it is actually easy to destroy lifelong confusion. the real question is cpu vs gpu vs youtube. normally i'd think a gpu is easily way better than a cpu but some guy said the opposite and i dont have a gpu so i will have to borrow my brother's. i will have to figure it out i guess.

Again, it's the whole...it depends with CPU vs GPU.  Like in my first post, it's just best to create multiple different test files and see what you are happy with.

 

I have to go into at least a bit of detail because whether you choose forward prediction or backwards prediction is a thing that can affect the quality, but has trade offs in regards to time spent.

 

My original numbers was to express that using uncompressed is the wrong term and a term that quickly gets misused to the point that there is confusion when it's used.

 

My other example is explaining to the direct question of how real time compression works...because it's best shown as an example.

 

GPU's are more rigid in terms of the algorithms they are running etc.  CPU's you get the flexibility but you typically sacrifice the speed.

[Mark Kaine]

9 hours ago, apoyusiken said:

also how do 1080p photos exceed 6 mbs?

Bloat. Nowadays everything is bloated because no one wants to optimize their code ("just buy better hardware lol!") 

 

Also btw your screenshot doesn't show bitrate, or did I miss it?

 

Seeing the bitrate would help to figure out why the videos are rather large... And also how you even save the files... VLC? that can download videos now? (It probably can but I always found it rather ineffective for video conversions...)

 

What you could do is record with OBS at mid/low bitrates while you watch...least hassle and no "post processing" required, but the files will probably still be rather large, 8k bitrate or so is minimum for 1080p footage to look good imo, maybe you could bring it down to 6k...

[Mark Kaine]

7 hours ago, wanderingfool2 said:

GPU's are more rigid in terms of the algorithms they are running etc.  CPU's you get the flexibility but you typically sacrifice the speed.

My 5800x3D takes roughly 2 minutes to encode a ~2 minutes video with AV1... I feel it gets exponentially longer too like a 10 minute video will probably take 12-15 minutes...

 

On my ROG Strix G17 with a R9 7940HX a 2 minute video takes like 15-20 seconds to render with AV1... too fast for the fans to even spin up lol...

 

More cores *do* matter after all! (I knew it all along ofc) But I was still surprised

[apoyusiken]

8 hours ago, Mark Kaine said:

Bloat. Nowadays everything is bloated because no one wants to optimize their code ("just buy better hardware lol!") 

 

Also btw your screenshot doesn't show bitrate, or did I miss it?

 

Seeing the bitrate would help to figure out why the videos are rather large... And also how you even save the files... VLC? that can download videos now? (It probably can but I always found it rather ineffective for video conversions...)

 

What you could do is record with OBS at mid/low bitrates while you watch...least hassle and no "post processing" required, but the files will probably still be rather large, 8k bitrate or so is minimum for 1080p footage to look good imo, maybe you could bring it down to 6k...

yea it didnt but we calculated it.

 

bro i just used it to show data, not download. 

 

i wanna process files before watching. 

 

i tried handbrake at library computers and it does like 2x speed and 1/3 size.

(they dont have a gpu and a 6 core 2.5ghz cpu i guess but it says its running at 4.5 ghz)

[wanderingfool2]

6 hours ago, apoyusiken said:

yea it didnt but we calculated it.

 

bro i just used it to show data, not download. 

 

i wanna process files before watching. 

 

i tried handbrake at library computers and it does like 2x speed and 1/3 size.

(they dont have a gpu and a 6 core 2.5ghz cpu i guess but it says its running at 4.5 ghz)

Oh I should mention, intel has quick-sync which could be used to speed up encoding...not sure if you have that.

 

Another trick I didn't mention, but is a thing as well.  You can actually sometimes just "copy" the codec and audio...but just lower the bitrate.  This can sometimes have the benefit of it skipping over some steps because it knows the frames etc...just needing to change the quantization number....but this I find usually lowers the output quality a lot more than re-encoding it (as in that case you are trading quality for raw speed)