I too tried to watch the video and almost stopped just one minute in when most of what he said was wrong. I forced myself to keep watching because sometimes to teach a concept, it's easier to fib a little to get a concept across ... and then clear up the fib later. If you flood the person with too many facts up front, you'll lose them. But at about 2/3rds of the way through the video it was still wrong and nothing was being clarified. I realized that someone watching this video will probably come away knowing all the wrong stuff.
To clear a few things...
Sensors don't have "pixels"
(photos have "pixels" but sensors do not). Sensors have "photosites". The photo-site is a single light sensitive cell that reads the luminosity of light at that position. In other words, think of it as a black & white camera and not as a color camera.
To get color, the camera uses a "color filter array" (CFA). The most common type is the Bayer Mask
Bayer filter - Wikipedia
Think of this as a chess-board type filter where each square is either red or green or blue transparent tile. A photosite that happens to be located behind a "green" colored tile on the CFA is sensitive to "green" wavelength light, but not to "red" or "blue". But most light is not a pure single color... for example teal light would be partially detected by "blue" photosites as well as "green" photosites.
Still... the actual RAW data from the camera is a file which provides the light value for each photosite in single-color channel form. It's a mosaic of color tiles... no blended color. To get the blended color values, software has to "de-mosaic" the tiles.
Suppose I'm a "green" photosite. I know how "green" I'm supposed to be because that's the only color I can detect. What I could not detect was how "red" or "blue" I was supposed to be. But I have neighbors and I can borrow information from them. If I'm green, then I'll have two red neighbors and two blue neighbors. Suppose my red neighbors are above and below me and my blue neighbors are left and right. If my red neighbor above has a value of 180 and my red neighbor below has a value of 178 then that tells me that if only I could have been able to detect "red" myself, I probably would have recorded a value of 179. I can do the same with the blue.
It turns out the algorithms are a bit more involved than this simple example... there are several algorithms. But that's the basic idea. Most programs don't let you pick the algorithm (my PixInsight software that I use for astrophotography DOES let me pick from among several RAW decoding algorithms). This means if you open a RAW file in one program and save the output to a non-lossy TIFF file... then do the same using a completely different program... then compare the two TIFF files, you'll find that they may have different results when you do a pixel-by-pixel comparison.
BTW, compare the file size of your RAW to the file size of the non-lossy TIFF... you'll notice the TIFF is MUCH larger and that's because it is made up of 3-color channel "pixels" whereas as the RAW is just single-color channel data where the 3-channel color will mathematically be derived when it is processed.
As for the ISO...
Sometimes it's easier to teach a concept by simplifying it. The simplification can sometimes involve telling a fib. Hopefully someone goes back and explains that "remember when we told you X was true... well we weren't entirely honest... we skipped the details for simplicity sake, but in reality... Y is true."
So yes, it's easier to say that changing the ISO changes the sensitivity of the sensor but that's not actually what it does.
When enough photons hit a photosite, it will bump up it's recorded light level by 1.
All this happens before any ISO adjustment is applied. In other words, whatever number of photons were collected is what it it was and that's the original data.
Changing ISO really just manipulates the data values that are reported (after the fact).
There are two main ways to do this... there's an "upstream" method and a "downstream" method (and a combination of both methods). The camera manufacturer won't tell you what they do for any given sensor but there are ways to work it out via testing.
The sensor receives analog signal (not digital). The camera sensor performs an Analog-to-Digital Conversion process (ADC). That results in digital output so we call it a "digital" camera even though the light captured was analog data.
It turns out in the analog world, you can simply amplify the signal. This is referred to as "upstream" amplification if it happens prior to the ADC step.
You can also take the digital output from the ADC step (so now you just have numbers) and multiply those numbers to increase the value. If you do this, it's called "downstream" amplification.
Some cameras rely almost exclusively on "downstream" amplification and others rely on a combination of "upstream" and "downstream" amplification.
Keep in mind that digital cameras have a maximum number of bits they use for each integer that represents the amount of light they counted. An 8-bit JPEG file just has 256 values (0-255). A 16-bit integer can store 65,536 values (0-65,535). But most modern create 14-bit RAW files with 16,384 values (0-16,383).
So here's a problem: Suppose that if I shoot at ISO 100 I end up with an image and if we just pick two of the photosites, one reported a value of 500, another reported a value of 9000. This is no problem because both values are below the maximum value of 16,383.
Now I dial the camera up to ISO 200 and my camera only performs "downstream" gain. This means it will perform simple multiplication and multiply all values by 2. My photosite that reported a value of 500 will now be saved as if it reported 1000. So far so good. But my photosite that reported a value of 9000 will now have to save a value of 18,000 and this is a problem because you can't store a value of 18,000 in a 14-bit integer. That's an over-flow problem and it results in clipped data (loss of information).
This isn't just a loss of information, it's also a loss of the camera sensors dynamic range.
Some cameras have a feature to protect those highlights (e.g. "highlight tone priority"). This scales the the multiplication so that while the dark pixels are all multiplied by 2.0x, the lighter pixels are multiplied by some smaller value (say... 1.8x) so that they don't overflow and clip data... and then we linearly interpolate how much to boost each mid-range value (some are boosted by 1.81, 1.82, etc. all the way down until we reach the pixels that we multiply by the full 2.0x.) Again, a simplification... but that's the idea.
This means we protect against full data loss... but we do lose part of the information. Technically we compress the dynamic range into a smaller space to try to avoid losing data and the result looks pretty good so we're happy with it.
If you had previously believed that a change of ISO simply increased sensitivity and didn't realize the math behind what it is really doing (mathematically multiplying values) then it might have been missed that you are losing dynamic range and should take steps to protect against loss of data such as shooting bracketed images to perform an HDR merge... or enabling features such as highlight-tone-priority (which may have a different name depending on camera model).
But back to that "upstream" amplification... this results in a gain being applied BEFORE digital conversion (before ADC) and as a result it doesn't lose much in the way of dynamic range.
If you were to test the dynamic range of a camera (using a test target) what you'd probably notice is that as you boost ISO, you don't seem to be losing much dynamic range... but there's a limit to this... and then suddenly you hit an ISO where you get a linear drop off in dynamic range for each boost in ISO beyond that point.
Most cameras that do both "upstream" and "downstream" have some magic point where this trade-off occurs. If you want to protect your DR then this is the highest ISO you should use.
Noise
When you boost ISO, you boost noise right along with it. The reality is the noise was always there, you just didn't notice it. Noise happens when a photosite reports a higher value than it should have (I'll skip discussions on why this happens but will mention that some of the reasons have to do with the quantum nature of the universe... no amount of electronic wizardry will make that go away because a sensor that reports this "noise" is actually reporting what really happened.) Cameras that do try to make this problem go away are "cooking" the RAW data (quite a number of modern sensors on the market provide "cooked" RAW files.) For some interesting reading... look up the Sony "star eating" issue (you'll find lots of hits on that search). The summary for those who don't want to search is that in Sony's effort to produce sensors that have lower noise, they're averaging out data that they "think" is noise (because it seems to exhibit properties of noise) even when it's actually real data. Astrophotographers starting noticing that stars are missing from their images that area really supposed to be there. The images look cleaner than they should because the computer assumed it was noise and was "cooking" the RAW data to get rid of it (and lots of Sony owners think they have better sensors because they don't see as much noise - unaware of what the camera sensor is really doing.)
Just remember that noise is "additive" in that it always results in a photosite reporting a HIGHER numeric value than it should have reported. There is no "anti-noise" where the photosite reported a LOWER numeric value (at least if there is, I have yet to encounter it.)
This is significant because it implies you're more likely to notice the noise in darker areas of your image and less likely to notice noise in whiter areas of your image. If a pixel is nearly "white" already and there's "noisy" pixel nearby, it won't be able to be that much brighter than the pixel that is already quite bright. But when an anomalous high value pixel shows up in a "dark" area, it really stands out.
But there is an exception... suppose you shoot a photo in a very well lit "green" room. So you're near saturating the green photosites but the red and blue photosites are porting very low values. I can have noise that spikes the value of, say, a "red" photosite and this creates a bright red photosite where it should be dark. My de-mosaicing algorithm then "blends" that spiked red value and it results in my green photosite being blended with red to create a yellow or orange pixel in the output. In other words the "noise" didn't just make my pixel brighter... it shifted the color value of the pixel.
You are far more likely to notice noise in dark areas.
You are also far more likely to notice noise in regions of the image that have some relatively flat tone (non-contrasty areas).
It isn't that there is no noise in the bight or contrasty areas... it's more than your eye is much less likely to notice it because it isn't so significantly different than the neighboring pixels. (sort of a "where's waldo" problem... when the detail in an area of your image is very complicated, your eye is not likely to notice the flaw. The flaw can hide in plain sight.)
Knowing this, you can smartly deal with noise by using software that more aggressively goes after darker regions more aggressively than lighter regions.
You can also create a mask that finds edges of contrast and protect those areas against de-noising ... and more aggressively smooth out the areas that lack contrast.