While I answered your more general question about runout sensors here, I can try to add more details in this answer specific to the design of encoders.

As stated in the linked answer, yes, the (Marlin) firmware has to compare the encoder movement with the expected extruder movement. This is exactly what you gleaned from the YouTube video since the controller has both piece of information. From my perspective as a hardware engineer, I would highly prefer this function reside in firmware instead of any other part of the print chain such as Octoprint. This comes down to detection speed and latency.

Rotary encoders rely on a light source that is energizing a photodiode. The wheel either makes or breaks the light so the output signal toggles on-off as the wheel spins. Right off the bat, we can assume a few behaviors:

1. The signal toggle rate is dependent on the speed of the wheel
2. The wheel can stop at either state (on or off)
3. The design of the wheel gaps will affect the toggle rate
4. The encoder can't tell which direction the wheel is moving

The encoder output has limits, if the wheel is moving too fast the output signal might not be able to keep up. This is not because light is slow, but the photodiode has a finite response time. On top of that, the printer controller might also not be able to read the changes fast enough to be accurate. On the flip side, a very slow movement might stay in one state for a long time if the wheel gaps are very large. In both cases, the result is a less than ideal representation of the actual movement. But filament sensing is generally about detecting fault and not measuring exactly what the filament is doing, so a "good enough" design is the goal.

In Marlin, the intent is to detect some filament movement within a specified amount of extruder movement. In effect, the specified amount of extruder movement is the minimum needed to see at least one toggle of the encoder. I believe that is what happened between the BTT smart sensor V1 and V2. The smaller the gaps on the wheel (or larger the wheel), the higher resolution when sensing movement and the sooner the firmware can detect a change. As long as the controller and firmware can keep up with the more frequent toggle rate this is an improvement. The idea that it can act as a "correction wheel" is IMO asking a runout sensor to be more than it needs.

When the extruder moves and the encoder returns some sign of change, the firmware can assume things are moving along regardless if forwards or backwards, fast or slow. This also means the firmware will ignore a still encoder if it hasn't asked the extruder to move. The need to correlate extruder to filament movement also means a delay when detecting a fault. This delay might be acceptable in most cases but it does add some risk of a clogged extruder wheel that has to be cleaned for a full recovery. It is also where we see people getting false positives and needing to debug the sensor.

I think as people push the print speed ever higher, the encoders themselves can likely keep up. The controllers might set some limits to encoder performance depending if the firmware can keep up with every toggle it generates and how much processing is consumed in keeping up with the encoder. Or the encoder will get even smarter and divorce itself from the controller. If the encoder had it's own microcontroller and it can snoop the extruder control signals, then it can go back to just being a simple on-off signal back to the controller.

While I answered your more general question about runout sensors at Which detection mechanisms can a filament sensor use?, I can try to add more details in this answer specific to the design of encoders.

As stated in the linked answer, yes, the (Marlin) firmware has to compare the encoder movement with the expected extruder movement. This is exactly what you gleaned from the YouTube video since the controller has both pieces of information. From my perspective as a hardware engineer, I would highly prefer this function to reside in firmware instead of any other part of the print chain such as Octoprint. This comes down to detection speed and latency.

Rotary encoders rely on a light source that is energizing a photodiode. The wheel either makes or breaks the light so the output signal toggles on-off as the wheel spins. Right off the bat, we can assume a few behaviors:

1. The signal toggle rate is dependent on the speed of the wheel
2. The wheel can stop at either state (on or off)
3. The design of the wheel gaps will affect the toggle rate
4. The encoder can't tell which direction the wheel is moving

The encoder output has limits, if the wheel is moving too fast the output signal might not be able to keep up. This is not because light is slow, but the photodiode has a finite response time. On top of that, the printer controller might also not be able to read the changes fast enough to be accurate. On the flip side, a very slow movement might stay in one state for a long time if the wheel gaps are very large. In both cases, the result is a less than ideal representation of the actual movement. But filament sensing is generally about detecting fault and not measuring exactly what the filament is doing, so a "good enough" design is the goal.

In Marlin, the intent is to detect some filament movement within a specified amount of extruder movement. In effect, the specified amount of extruder movement is the minimum needed to see at least one toggle of the encoder. I believe that is what happened between the BTT smart sensor V1 and V2. The smaller the gaps on the wheel (or larger the wheel), the higher the resolution when sensing movement and the sooner the firmware can detect a change. As long as the controller and firmware can keep up with the more frequent toggle rate this is an improvement. The idea that it can act as a "correction wheel" is IMO asking a runout sensor to be more than it needs.

When the extruder moves and the encoder returns some sign of change, the firmware can assume things are moving along regardless of forwards or backward, fast or slow. This also means the firmware will ignore a still encoder if it hasn't asked the extruder to move. The need to correlate the extruder to filament movement also means a delay when detecting a fault. This delay might be acceptable in most cases but it does add some risk of a clogged extruder wheel that has to be cleaned for a full recovery. It is also where we see people getting false positives and needing to debug the sensor.

I think as people push the print speed ever higher, the encoders themselves can likely keep up. The controllers might set some limits to encoder performance depending if the firmware can keep up with every toggle it generates and how much processing is consumed in keeping up with the encoder. Or the encoder will get even smarter and divorce itself from the controller. If the encoder had its own microcontroller and could snoop the extruder control signals, then it could go back to just being a simple on-off signal back to the controller.