Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Siderz

macrumors 6502a
Original poster
Nov 10, 2012
991
6
Not sure if what I'm asking is a worthwhile question, but I'm wondering if anyone can explain in layman's terms, how video rendering/encoding works? Or post a link to an article explaining it?

Not how to compress a video, I want to know what the software is actually doing to the video files, and what role is assigned to each hardware piece.
 

wonderspark

macrumors 68040
Feb 4, 2010
3,048
102
Oregon
Not sure if what I'm asking is a worthwhile question, but I'm wondering if anyone can explain in layman's terms, how video rendering/encoding works? Or post a link to an article explaining it?

Not how to compress a video, I want to know what the software is actually doing to the video files, and what role is assigned to each hardware piece.

To really simplify, video rendering is the final output process of taking a group of video and audio clips, and perhaps animation and special effects applied, leaving you with one neat package to watch and listen. You could say it's taking kitchen ingredients and baking it into something edible.

Whether video is shot in one format or many, it needs to be encoded into a neat package. Same with audio, which can come in many different sample rates and formats. It needs to be converted into a single, uniform stream, so that devices lesser-powered can play it smoothly.

How it works is through codecs, which is a portmanteau (term) for coder/decoder. The edit system decodes as it works with the footage, then codes (encodes) it back into that neat package when all the edits are done. That is handled by the CPU, mostly. This is why faster/more CPUs do the job faster, and handle complex (highly compressed) video sources better... because they decode faster. Some effects and work is now also being done by the GPU in some systems, but usually only during playback, not during final encoding.

The software interprets all the different codecs and sources during playback, assembly and finally the encoded output.

I found these links:
http://www.brighthub.com/multimedia/video/articles/81078.aspx
http://en.wikipedia.org/wiki/Codec

Hope that's not too messy, and answers your question. :)
 

floh

macrumors 6502
Nov 28, 2011
460
2
Stuttgart, Germany
Not sure if what I'm asking is a worthwhile question, but I'm wondering if anyone can explain in layman's terms, how video rendering/encoding works? Or post a link to an article explaining it?

Not how to compress a video, I want to know what the software is actually doing to the video files, and what role is assigned to each hardware piece.

I really am not sure what you want to know. Maybe you should try to elaborate a little more...

I have seen you around the forums for a while though, and as I recall you did not sound like a complete novice, so I'll try to go a little more into depth. If this is not what you wanted, just tell me...

You are asking two questions: How rendering works and how encoding works. They are two seperate processes. I'll try to explain both in a reasonable amount of detail:

Rendering

Rendering is the process that starts with (several) videos and motion graphics elements and ends with one final video, meaning the information of 24 frames per second, and each frame containing 1920x1080 single pixels (that is, for 1080p@24fps...). To achieve this, we have to again seperate two different things:
  • Computer generated images (CGI): These are objects you created in After Effects, Maya, Cinema4D, ... They don't start as "pixels" but as objects that you can position, manipulate and light in your scene. The rendering of these CGI objects is basically transforming them into the pixels that appear on your screen. And again, this has to be split up:
    • First, for many effects the actual 3D object is not yet present but needs to be calculated via a physical simulation. This is the case for particle systems, fluids, smoke, fire, light streaks, ... These systems will be simulated with real physics engines for the computer to know how they look like. On the hardware side, particle simulations are mostly done on the CPU (because you can't parallelize them into a huge amount of threads) whereas fluids, smoke, and stuff like that is nowadays way faster on the graphics card (since these hyperbolic differential equations are solvable locally, but this might go too far). In any case, you will need a lot of memory for this, since much information has to be stored in RAM.
    • Second, the calculated (or previously known, in case of 3D objects, text, or stuff like that) objects have to be put into your scene. The orientation of the objects and what they look like from the camera's perspective is a job perfectly suited for graphics cards shaders (that's basically what they were made for, in 3D computer games) and most software will use the GPU for it, making it rather fast. However, they also need to be lit, and here is were the trouble starts. The surface reflections, lights and shadows are usually done with raytracing, meaning light rays are randomly sent from a light source and reflected and scattered in the scene, and the computer calculated which ones end up in the camera lens and how they look by that time. But since many of those rays will not end up in the camera lens, the method is very costly and will take a long time. It can be sped up to a degree by using the GPU since it is very good at calculating sines and cosines, but not all software is capable of that, and even then it can take ages.
  • Compositing: Usually, on export, you end up with not one but many streams of visual information for your final video. These may contain several video clips, the CGI from the previous paragraph, text (subtitles). And the video clips might be composited with masks, green screen and different composition modes (soft light, darken, multiply, ...). But the process is really straight forward: The computer takes each pixel, and for each layer figures out what the layer contributes to the final video. Then the final product is shown on the screen. While this may sound a lot, it is actually a comparably "cheap" task for the computer, and while the GPU can be used for it (it parallelizes very well), it sometimes isn't even worth it since the copying of the information to the GPU memory would take too long. So usually the software decides whether the compositing is complex enough to be done on the GPU.

With these steps, you end up with one final video stream that (only) contains 1920x1080 pixels for each image, no further information. And this is where we go to

Encoding

The raw video in 10 bit color depth, 1920x1080 pixels, and 25 frames per second would use up about 30GB per minute of film. That's huge. It needs to be encoded or compressed. Video cards today are built to decode even newer video codecs like H.264 pretty efficiently and your software will most certainly make use of that when playing back videos. But for encoding, the information flow between pixels and frames is so big that the many threads of the graphics card don't really benefit enough. In addition, you can imagine that loading just 25 uncompressed frames would fill up the memory of the graphics card, and the bottleneck in GPU computation mostly is how much information needs to be transferred to the graphics card and back. So, your software will mostly use your computer's CPU processor for encoding.

If you export in ProRes or DNxHD, these are "intraframe codecs", meaning they just compress each individual frame. This is usually done with three methods:
  • Chroma subsampling: The luminosity receptors in your eyes are well resolved, while the color receptors are not as finely spread on your retina. This means that you can resolve luminosity very sharply, but colors not so much. Chroma subsampling makes use of that by, instead of saving red, green and blue values for each pixel, only saving the pixel brightness for each pixel but combining the color information of several neighbor pixels into just one value. The most common schemes (for exported, not raw video) are 4:2:2 and 4:2:0. Look it up on Wikipedia if you need more info.
  • Block pixels: If a large area in the frame has the same color, it can be saved as one big "pixel", not individual ones. Technically, this is done by Fourier transforming the pixture into frequency space and smoothing out the higher frequencies. Very similar to MP3, if you know how that works. You can see this "blockiness" in dark areas and sometimes along sharp edges, and it is the same algorithm JPEG uses for image compression.
  • Compress the file: You can, of course, just losslessly compress the final result, like you would do a ZIP file. But this is lots of computational effort and will usually not give a good reduction of file size, so it is often skipped.

If you export for Web or just want a smaller file size, practically all videos today that are not meant to be edited any further, are compressed with an "interframe codec". The idea is, in addition to everything an intraframe codec does, to make use of the fact that in a video, there are usually very few things that change between two consecutive frames. Some parts of the image (or the whole image, in a camera pan) might move, and some might change completely, but much of it stays the same. So, interframe codecs will only save one complete (compressed) frame every few seconds and in between save spline interpolations of the movements and changes made in the image. Everything that is not stored is expected to stay exactly the same. That's why, if you have a broken file that suddenly shows a messed up frame, parts of the video stay messed of for some time (until the next keyframe), while the parts in the image that move will slowly start to show correctly again.

Alright, so this reply got a little out of hand and became longer than I intended it to be. I hope you're not overwhelmed and this was kind of going in the direction you wanted to. If not, or if you want more detail on some points, please feel free to ask. As you can tell, I know most of this stuff way too well and could just write essays about it...

Greetings from Germany (so excuse the grammar and spelling mistakes, this got to long for me to proof-read again),

Floh
 
Last edited:

12dylan34

macrumors 6502a
Sep 3, 2009
884
15
The surface reflections, lights and shadows are usually done with raytracing, meaning light rays are randomly sent from a light source and reflected and scattered in the scene, and the computer calculated which ones end up in the camera lens and how they look by that time. But since many of those rays will not end up in the camera lens, the method is very costly and will take a long time. It can be sped up to a degree by using the GPU since it is very good at calculating sines and cosines, but not all software is capable of that, and even then it can take ages.

Great post; I think that I learned a bit, but as a point of clarification, the traditional method of raytracing is to cast rays randomly from the camera (eye), then test to see what surfaces they hit, then trace them back to light sources. There are certain things that use light-cast rays, notably photon casting for things like caustics, but it's not usually regarded as the "normal" method of raytracing.

From Wikipedia on Ray-tracing:

First, a ray is created at an eyepoint and traced through a pixel and into the scene, where it hits a diffuse surface. From that surface the algorithm recursively generates a reflection ray, which is traced through the scene, where it hits another diffuse surface. Finally, another reflection ray is generated and traced through the scene, where it hits the light source and is absorbed. The color of the pixel now depends on the colors of the first and second diffuse surface and the color of the light emitted from the light source. For example if the light source emitted white light and the two diffuse surfaces were blue, then the resulting color of the pixel is blue.
 

TyroneShoes2

macrumors regular
Aug 17, 2011
133
3
First we need to agree on a definition of terms, and hopefully much of what you are trying to understand can be accomplished during that process.

There is digitization (which we need to understand to understand encoding):

This is the same as analog to digital conversion, which is done by taking samples of audio or video or still pixels at regular intervals of time (video or audio) or physical distance (geographical location of pixels for video or still pictures), and storing them as binary coefficient values, which places the media into the digital domain where it is represented only by a series of numbers.

The idea is that this information will be enough to represent the entire image/sound/whathaveyou when converted back to analog (which all sounds and images are converted back to at some point, even if that happens at the level of your retina) because as humans we only have the capability of perceiving analog images or sounds.

Why digitize at all? Because it provides a lot of benefits in storage, portability, manipulation, freedom from analog artifacts, and preservation of quality that can't be eroded in a hostile transport environment the way analog signals can. In the analog domain the message is married directly to the medium, and if something happens to the medium (lightning briefly creates a change in modulation amplitude of an AM radio signal, for instance) it alters the message (perceived as static, in that case). In digital, the information is in the realm of numbers, fully divorced from the medium, and the only thing that can change it is performing a purposeful mathematical operation on it, making it invulnerable to change otherwise, and giving us complete control over it.

HD video, for instance, has a pixel map (rows of pixels extending down the raster) and each pixel is represented by at least one binary coefficient. Each luminance pixel gets assigned a particular value, and each group of 4 pixels (two in one line and the two below them) get a chrominance value for R-Y and for B-Y (for 4:2:0). For video, the digital words created are usually 8, 10, or 12 bits in depth.

Audio is sampled typically at either 48k times per second or 44.1k, and binary coefficients with a bit depth of 16 to 24 (sometimes higher and more often) are created.

Digitization then basically turns an analog sound or image into a series of binary numbers, either to facilitate transportation, further manipulation, or for quality preservation, or all three.

Then there is encoding:

That usually means either formatting the digital information into a particular protocol, such as the 188-byte packet structure of digital TV, but it also usually means that there is some sort of compression involved. Compression, whether it be JPEG or H.265, uses intelligence to figure out what parts of the digitized file can be discarded or thrown away without us noticing, which makes the file size smaller without hopefully creating visual or aural artifacts. It uses perceptually-based encoding, meaning that it discards only the parts of the file that human perception is not sensitive to. Of course that is done with varying levels of success.

Most compression schemes are based on a DCT transform. MPEG2 is a common codec for video, and it uses some 30-odd different algorithms in its toolbox chained together to often achieve compression ratios of 100:1 or better, meaning that 99% of the image is discarded forever and completely (and hopefully later reapproximated properly in the decoder). Newer codecs are even more sophisticated and more complex.

Note that "encoding" can also refer to digitization, because that process "encodes" analog information into the digital domain of binary-coded words. But in practice that usually implies encoding by protocol and also by compression as well, so the meaning of the word then becomes a little grey and fuzzy, and usually the definition depends on the frame of reference.

And there is rendering:

Rendering may have a wide definition, but in professional video editing and in graphics programs like Photoshop it usually refers to creating a new simpler or single version of a complex file or set of files that combine to make an image, or flattening a complex file, or copying disparate elements of the editing or effects used to make a photo, video sequence, (or rarely an audio mix) and creating a single file that holds all of those relevant aspects.

For instance, in non-linear editing in Final Cut Pro you can create a sequence that will play back, but there is no true physical editing involved; the sequence is based on a set of pointers in an edit decision list that can be accessed instantly, so when you play the edited sequence in the editor it is simply jumping from pointer location to pointer location referencing the original video clips in storage. It appears to be a coherent whole in a serial sequence, but until it is rendered it actually is not.

Rendering copies the sequence into a new single file, so that it can be easily moved or transported from system to system, or stored economically and simply, or played by simpler playback systems or systems where it would be impractical to reference all of those separate files or parts. In Avid editing this is referred to as consolidation, which is probably a more-accurate term. It is also analogous to an audio mixdown where a large number of tracks are rendered down into a smaller number of tracks.

In PhotoShop you may have an image that you are editing that is based on multiple separate layers. Once created each edited layer exists in only RAM, and only the original source image exists as a separate stored file; a copy of the original source image as well as the new layers and adjustments exist as separate entities in RAM, and there is no separate file that represents the edited file. Even after you save it as a psd document the various aspects of it are separate entities existing as separate layers and individual adjustments.

But if you have edited the image to a point where you are sure you do not to make further changes that would involve serious backtracking, you can render that image into a separate single file, or flatten it, to use the vernacular. That has the advantage of freeing up RAM and application resources for other work, and gives the new finished image portability (and typically reduces the file size as an economic advantage). It also locks it into the current edited format.

The psd file is a single file if you merely save it, but it only makes sense in a PhotoShop environment, where loading that file loads all of those still-separate parameters and layers separately into RAM once again. Render or flatten it, and you have a smaller (file size), fixed, single-layer document that can be read in other programs as a single entity and can no longer be reverted to earlier versions (which is why we save copies when rendering).

Rendering mostly got its name from the days of slower computers, when to even get the full image it might take days of hours to create a single image. Think of the CSI techs spending hours trying to render the information from a fuzzy pic of a license plate into something sharp as a tack (OK, not really all that possible in real life). But once rendered into a new, usually smaller, separate file, that file can be manipulated in real time outside of the PhotoShop environment, locked into its current format, copied and pasted, and transported.

These days most of what would have been considered rendering back in the day can now happen so fast that it approaches or exceeds real time, so it may still technically be rendering, but that may be totally transparent to the user. So the faster our computers become, the closer to extinction the term "rendering" becomes.
 
Last edited:

thekev

macrumors 604
Aug 5, 2010
7,005
3,343
Great post; I think that I learned a bit, but as a point of clarification, the traditional method of raytracing is to cast rays randomly from the camera (eye), then test to see what surfaces they hit, then trace them back to light sources. There are certain things that use light-cast rays, notably photon casting for things like caustics, but it's not usually regarded as the "normal" method of raytracing.

From Wikipedia on Ray-tracing:

He basically described photon mapping, which isn't even the only type of GI. Photon mapping is still used in some things.
 

TyroneShoes2

macrumors regular
Aug 17, 2011
133
3
I think we've gone far beyond the definition of "layman's terms."
But we are trying.

You can't answer the question "Why is the sky blue?" without understanding beyond a layman level.

So if a complex question is asked, you are going to get complex answers. And understanding a complex issue from a lay point of view is typically just not possible, so we are trying to bridge that gap as best we can. The only way to understand a complex issue is to ask a series of questions, with each question based on what you learned from the answer to the previous question. Eventually you get to the place where you can ask really intelligent pointed questions and get really good answers, but you can not leapfrog to the end of the line of understanding a complex issue by simply posing the first lay-based question alone.

In Outliers it is said that it takes 10,000 hours to become an expert at something, and most of that 10,000 hours is spent finding the answers to that series of questions. It's a long journey; you can't get a really good or credible idea of how a heart transplant should be done by spending a couple hours on WebMD, either.

Your "baking" analogy is a good one. But is that enough to answer the question? If I explain the basics of compression, that may answer part of the question from a little higher level, but is it an answer that can be understood from a lay point of view?

The beauty of a forum is that the OP can get a variety of answers at a variety of levels, and then can take from each of them whatever makes sense to him/her. What can be learned all depends on the level of motivation.
 
Last edited:

wonderspark

macrumors 68040
Feb 4, 2010
3,048
102
Oregon
I'm not rolling my eyes or complaining, but rather making the statement in light of the fact the guy has not returned to the thread, and it's progressively gone quite deep.

I find it amusing, and look forward to seeing where it goes. :)
 

TyroneShoes2

macrumors regular
Aug 17, 2011
133
3
Sure, I get that. But raising that point makes us wonder just what you are getting at and whether that is helpful. No real worries, tho. Peace and all that. :)

I can't speak for others, but trying to answer questions is also a way of better understanding the issues myself, so I guess it is not completely altruistic of me, probably also not of others. But hopefully everybody wins.
 

wonderspark

macrumors 68040
Feb 4, 2010
3,048
102
Oregon
Lately I've noticed my girlfriend shutting down as soon as I get too technical with some explanation to her, so I might be overly sensitive to it for now. :p
 

floh

macrumors 6502
Nov 28, 2011
460
2
Stuttgart, Germany
But hopefully everybody wins.

Well, I kind of won. I was reminded of the original raytracing technique, which obviously I would have gotten wrong if asked. I also wrote down some knowledge, which usually helps it stay in my horrible memory a little longer.

It would be nice now if the OP showed up again in this thread and wrote something to the extent "This actually helped me". At least two people took a significant amount of time to write a short essay on the subject, but it seems like the original question was not driven by that much interest after all...

Oh, by the way: Yes, this is pretty extensive. But it was hopefully not too technical. I am a computational physicist by profession, so I really, really held back on the algorithmic details. :) And I hope that it remained readable for the interested enthusiast. If not, I hope the not so enthusiastic will tell us soon in this thread. The answers are long, yes, but the question was very general, and he specifically asked for

Not how to compress a video, I want to know what the software is actually doing to the video files, and what role is assigned to each hardware piece.

which implies a certain amount of technicality. Even in layman's terms.

Have a good one,
Floh
 

LethalWolfe

macrumors G3
Jan 11, 2002
9,370
124
Los Angeles
Not sure if what I'm asking is a worthwhile question, but I'm wondering if anyone can explain in layman's terms, how video rendering/encoding works? Or post a link to an article explaining it?

Not how to compress a video, I want to know what the software is actually doing to the video files, and what role is assigned to each hardware piece.

Rendering is basically a computer program creating an image. For example, let's say you have video of a barn in FCP. You apply a filter to make the video black and white. That black and white video of the barn doesn't actually exist anywhere so FCP has to take your source video, combine the effects of the filter with it and then generate (or render) the final image on your screen for you to see which in this case is a barn in black and white.

If the computer is powerful enough it will do this in real time so all you have to do is apply the filter, hit play and you'll see the results instantly. If the computer is not powerful enough to do all this in real time then you will have to render the effect. Rendering the effect basically means the software will create a new piece of video that it will playback since it is not powerful enough generate the results of the effect in real time.

Typically in editing software the CPU is used to do the rendering though it is becoming more common for the GPU to be used to do the rendering. Some specialized hardware, such as hardware Avid sells, provides hardware acceleration when rendering some effects but specialized hardware has become less common as normal CPUs and GPUs have become faster and less expensive.


First we need to agree on a definition of terms, and hopefully much of what you are trying to understand can be accomplished during that process.
There in lies part of the problem as differences in nomenclature even exist between software. For example, 'render' in Apple Color performs a function that in most other software (even Apple's other software) would be called an 'export'.

Rendering copies the sequence into a new single file, so that it can be easily moved or transported from system to system, or stored economically and simply, or played by simpler playback systems or systems where it would be impractical to reference all of those separate files or parts. In Avid editing this is referred to as consolidation, which is probably a more-accurate term. It is also analogous to an audio mixdown where a large number of tracks are rendered down into a smaller number of tracks.
This paragraph is flawed on a number of levels. Rendering does not inherently create a copy of the sequence in a single file. If no media in the timeline requires rendering then no render files will be created when you tell the program to render. Render files are normally considered transient and would never be used as source files to move/transfer between systems unless there was a catastrophic loss of media and the render files were the only copies remaining.

A mixdown is also not similar to rendering. A mixdown (the closest FCP proximity would be creating a self-contained QT movie) combines all of the selected audio or video content into a single file regardless of whether or not said content needs to be rendered. Mixdowns and self-contained QT movies can be use as stand alone piece of media to pass between users.

A consolidation in Avid is also very different from a render. Consolidation moves or copies media from one drive to another. For example, if I wanted to send another editor a copy of all the footage from day 2 of a shoot I would use the consolidate function to copy only the media from day 2 from my storage onto an external drive that could be sent to the other editor.


You can't answer the question "Why is the sky blue?" without understanding beyond a layman level.
The question can certainly be answered in layman's terms though follow up questions will certainly require progressively deeper understandings of science.

Short answer, the sky is blue during the day because when sun light hits Earth's atmosphere the light scatters in such a fashion that predominantly blue light reaches the Earth's surface.
 

floh

macrumors 6502
Nov 28, 2011
460
2
Stuttgart, Germany
Short answer, the sky is blue during the day because when sun light hits Earth's atmosphere the light scatters in such a fashion that predominantly blue light reaches the Earth's surface.

See, this is where you are already wrong! ;) Actually, a little more light from the red spectrum reaches the earth. But the blue light is scattered within the atmosphere and is therefore seen seperately, whereas all the rest of the sun's light is seen as the well-known yellow-white mix that filmmakers love so dearly. :)

And that's the problem with physicists trying to explain something. It hurts us physically to go for the shallow explanation even if it is ever so slightly incorrect. So we start rambling. (see my first contribution here...)

Besides that, your answer (on rendering) is very correct. We have now given three different answer types to the OP's question. Would be nice if he could stop by and tell us what he was actually looking for.
 

LethalWolfe

macrumors G3
Jan 11, 2002
9,370
124
Los Angeles
See, this is where you are already wrong! ;) Actually, a little more light from the red spectrum reaches the earth. But the blue light is scattered within the atmosphere and is therefore seen seperately, whereas all the rest of the sun's light is seen as the well-known yellow-white mix that filmmakers love so dearly. :)
Even though I was wrong, your simple correction goes to prove my point that a concise answer can be given in laymen's terms. :)

And that's the problem with physicists trying to explain something. It hurts us physically to go for the shallow explanation even if it is ever so slightly incorrect. So we start rambling. (see my first contribution here...)
I think it can be difficult for anyone with in-depth knowledge to learn how to give laymen explanations because they fear that too little information will be detrimental when in fact the opposite is true. I've worked with and/or trained a number of other editors over the years and few of them are as tech geeky as I am so I've learned how to adjust my 'geek level' based on who I'm talking with.

There is an adage in the movie industry that basically goes, if you can't describe what your movie is about in one sentence you don't know what your movie is about. I'm keep that in the back of my head and actually practice coming up with simplified answers or analogies to help explain complex problems. If someone comes to me for help and leaves more confused than when they arrived I've done something wrong.
 

Siderz

macrumors 6502a
Original poster
Nov 10, 2012
991
6
the guy has not returned to the thread, and it's progressively gone quite deep.

Sorry about that!

I read the first reply, then went to bed. Next morning I've got a new reply which looks really good, so I've basically left that tab open on my computer until I find the time to read it properly. It's been a few days now, sorry about that! Been quite busy with College.

Gonna try and read it now, it looks like I've received some excellent responses.
 

wonderspark

macrumors 68040
Feb 4, 2010
3,048
102
Oregon
Sorry about that!

I read the first reply, then went to bed. Next morning I've got a new reply which looks really good, so I've basically left that tab open on my computer until I find the time to read it properly. It's been a few days now, sorry about that! Been quite busy with College.

Gonna try and read it now, it looks like I've received some excellent responses.
No worries! Glad you're getting good info!
 

Siderz

macrumors 6502a
Original poster
Nov 10, 2012
991
6
Finally I've been able to actually read everything! Sorry again that I've left it a while, I've been pretty busy with College, and I knew that if I read it with College on my mind then I wouldn't be able to take it in properly.

Firstly, I appreciate all the messages here, it's been a good discussion, but floh and TyroneShoes2 made the better answers I think, nearly answering everything, could have possibly gone into a bit more depth on things though, and I'm wondering if someone can explain what the 'exact' process is? Like, is there a sequence the software will go through to get the final outputted frames? For instance, does it go: HDD/file > RAM > CPU > GPU [If enabled] > Render > Encode > RAM > HDD/final file?

And, I know floh suggested looking it up on Wikipedia, but I've spent some time on it in the past and couldn't quite get my head around it, so can someone elaborate more on chroma subsampling? Perhaps this could be tied in with answering whether or not there's a 'sequence' the software goes through.

Sorry if people think this thread is just dead boring now since it's been a while :(

In the analog domain the message is married directly to the medium, and if something happens to the medium (lightning briefly creates a change in modulation amplitude of an AM radio signal, for instance) it alters the message (perceived as static, in that case). In digital, the information is in the realm of numbers, fully divorced from the medium, and the only thing that can change it is performing a purposeful mathematical operation on it, making it invulnerable to change otherwise, and giving us complete control over it.

Also I found this really intriguing.

Lastly, for anyone wondering what made me bring this up: A couple of friends were mentioning how the iMacs have laptop GPUs, and I told them it's not a big deal for me, since the CPU does most video rendering/encoding, they argued that the CPU is there to tell what the hardware pieces must do, and the GPU handles all video operations, and that if the CPU were to try and render/encode video, it would take years. Funnily enough, I spent about 10 minutes arguing before deciding to just do the Google work for them, not sure why they were reluctant to Google it themselves...but it did shut them up. They're more knowledgable regarding computers in gaming than video editing.
 

floh

macrumors 6502
Nov 28, 2011
460
2
Stuttgart, Germany
Like, is there a sequence the software will go through to get the final outputted frames? For instance, does it go: HDD/file > RAM > CPU > GPU [If enabled] > Render > Encode > RAM > HDD/final file?

Well, I can't describe what happens EXACTLY without this thread getting way to technical.

Because, roughly: There is a programmer who writes code in Objective-C, CUDA or OpenCL. He will give instructions on what the software needs at what time and how it should be calculated. The exact order in which this is done however is usually determined by (a) the compiler that translates the code and optimizes it and (b) the system at runtime that looks what's coming and uses free ressources to work ahead.

So, the problem is, there is no exact sequence since it is usually all happening kind of at the same time and it's a little different every time depending on what your computer is doing, how much RAM and VRAM you have, ...

Video is my hobby, but for a job, I actually program physics software on CPU and GPU, so I could go very deep here, but just trust me on this one: There is nothing like the simple "sequence" you are looking for. Nowadays, computers don't work as straight forward anymore. Programming "sequentially" would actually mean not using the parallelizing capabilities of your multi-core CPU and GPU, so it is usually not done anymore.

so can someone elaborate more on chroma subsampling?

I saw this video ages ago and just searched for it again. It explaines many aspects of video encoding in a technical yet understandable manner, including chroma subsampling.


Maybe that helps. If not, I would rather explain this via a Skype call or something, because it's a long and complicated text to write. :) So, you can PM me if you want to talk about it some time.
 

Siderz

macrumors 6502a
Original poster
Nov 10, 2012
991
6
I saw this video ages ago and just searched for it again. It explaines many aspects of video encoding in a technical yet understandable manner, including chroma subsampling.

YouTube: video

That video actually clears up a lot of stuff! Thanks a lot for sharing that. I think my questions have pretty much been answered now (But if anyone else wants to pitch in, feel free to do so, I'll read it).
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.