4 ms·

That makes little sense. When decoding to fullscreen canvas, on a retina display, the 1080p video needs to be rescaled from 1920x1080 to the retina resolution,

That makes little sense. When decoding to fullscreen canvas, on a retina display, the 1080p video needs to be rescaled from 1920x1080 to the retina resolution, whereas in windowed, it is 1:1 pixel mapped (in the case of QuickTime X).

taeric 9y ago
I was expecting they optimised there. I was also just throwing up ideas. :) I assumed convenient sized windows for the viewer, not native res ones.
- Matthias247 9y ago
  Actually the size does not really matter, since the scaling will be done in hardware on the GPU if possible, and scaling in hardware (or shaders) is not a very intense task. For video playback you have a first step on the GPU, which is decoding the video (e.g. from h.264 into uncompressed video). You can from there go several ways, e.g. read the video back into main memory, do post-processing on the CPU and somewhere blit it back on a surface. This is not really what one wants for good performance. Instead of that all necessary post-processing (including scaling and other things like color-space conversion) can also be directly done on the GPU after decompression. Again, after that step the output can be read back or it can be directly forwarded towards the video output. For the best performance you go all-the-way on the GPU. This works in fullscreen mode as well as in windowed mode (you can instruct the GPU to use only a part of the screen for the video). I had some task in the last year where I had to use gstreamer for video rendering, and using various configurations I could see their impact quite good. E.g. CPU-based postprocessing (through the videoconvert pipeline plugin) was very slow compared to the GPU hardware-based one (vaapi) on the Intel Atom box.
  - taeric 9y ago
    Again, I was mainly throwing ideas out. But you are also conflating "does not" with "should not." Clearly something is different. What?
    - LeoNatan25 9y ago
      Desktop composition.
    - Matthias247 9y ago
      There are many possible reasons for the the lower power consumption. E.g. the OS could schedule processes other than the foreground window less often in fullscreen mode. Or it even detects that the user watches video and puts the CPU in a very low power (low frequency) mode. Or it's the overhead of the desktop environment and compositor. I have no idea. I justed wanted to give an explanation why I don't think that the video scaling makes a huge difference.
      - taeric 9y ago
        And that makes perfect sense. These are all hypotheses to be ruled out, at this point though. Indeed, your "schedule processes" one is essentially the other idea I threw at the beginning. My hunch is more likely that is the deal. I'd have to eliminate both through testing, not reasoning, though. Reason can not and will not ever eliminate why something behaves against expectations.

taeric 9y ago

I was expecting they optimised there. I was also just throwing up ideas. :) I assumed convenient sized windows for the viewer, not native res ones.

Matthias247 9y ago
Actually the size does not really matter, since the scaling will be done in hardware on the GPU if possible, and scaling in hardware (or shaders) is not a very intense task. For video playback you have a first step on the GPU, which is decoding the video (e.g. from h.264 into uncompressed video). You can from there go several ways, e.g. read the video back into main memory, do post-processing on the CPU and somewhere blit it back on a surface. This is not really what one wants for good performance. Instead of that all necessary post-processing (including scaling and other things like color-space conversion) can also be directly done on the GPU after decompression. Again, after that step the output can be read back or it can be directly forwarded towards the video output. For the best performance you go all-the-way on the GPU. This works in fullscreen mode as well as in windowed mode (you can instruct the GPU to use only a part of the screen for the video). I had some task in the last year where I had to use gstreamer for video rendering, and using various configurations I could see their impact quite good. E.g. CPU-based postprocessing (through the videoconvert pipeline plugin) was very slow compared to the GPU hardware-based one (vaapi) on the Intel Atom box.
- taeric 9y ago
  Again, I was mainly throwing ideas out. But you are also conflating "does not" with "should not." Clearly something is different. What?
  - LeoNatan25 9y ago
    Desktop composition.
  - Matthias247 9y ago
    There are many possible reasons for the the lower power consumption. E.g. the OS could schedule processes other than the foreground window less often in fullscreen mode. Or it even detects that the user watches video and puts the CPU in a very low power (low frequency) mode. Or it's the overhead of the desktop environment and compositor. I have no idea. I justed wanted to give an explanation why I don't think that the video scaling makes a huge difference.
    - taeric 9y ago
      And that makes perfect sense. These are all hypotheses to be ruled out, at this point though. Indeed, your "schedule processes" one is essentially the other idea I threw at the beginning. My hunch is more likely that is the deal. I'd have to eliminate both through testing, not reasoning, though. Reason can not and will not ever eliminate why something behaves against expectations.