3 ms·

> Bonus conversation: Due to x264 being much less complex, presets can pretty much maintain only a slight loss in quality as you encode faster. This gives an il

> Bonus conversation: Due to x264 being much less complex, presets can pretty much maintain only a slight loss in quality as you encode faster. This gives an illusion that slower presets are slower due to spending more time compressing. The more correct way to see this is that slower presets are slower due to doing more motion calculations and finding the best scheme that best describes the frame, which in x264 just so happens benefits compression too. However, x265 is waaay more complex with motion algorithms, meaning that accurately describing motion actually increases bitrate. This is totally confusing me. If the scheme that best describes the frame actually uses more data, and the user is targeting a lower bitrate/quality, shouldn't the encoder realize that the less accurate description is a more efficient choice, and select that?

astrange 5y ago
It only targets a bitrate if you tell it to. Constant quality/crf mode doesn't care about bitrate, it just applies a quality level to whatever makes it to intra prediction (which is the stage after inter prediction, where all the motion compensation is).
- prvc 5y ago
  Lower crf will lead to higher bitrates, everything else being equal. It makes no sense to compare this figure between different presets.
brigade 5y ago
The author is pretty confused. x264’s slower presets enable searching more points in ME and a more accurate RDO (among other things), just like x265’s. But in all cases for any modern encoder, all mode decisions are done baed on the estimated bitcost relative to distortion, so the slower presets are just evaluating more options. (kinda) That said, it is the case across all codecs that more accurate motion vector fields (e.g. using optical flow) are not generally optimal. A simple way of reasoning about that is that one block reusing the same motion vector as a neighboring block is much cheaper than encoding a marginal difference, which often more expensive than the bits saved in the residual. Anyway, CRF was never designed to map to the same quality across different encoder settings, which having actually read the article, is what I think they’re actually complaining about.
- lmm 5y ago
  So what is designed for that? Generally as an encoder you want to target a certain (perceptual) quality level and when testing different settings you're aiming to hold that constant and see whether you achieve a lower bitrate. There should be a way to do that.
  - brigade 5y ago
    You plot two RD curves with whatever quality metric you care about, then calculate the distance between them. Also known as the Bjontegaard metric.
    - slhck 5y ago
      And the issue with that is that they're using PSNR and SSIM as quality metrics, which are useful for images, but haven't been designed for video, so they cannot take into account temporal factors and how motion masks distortion, etc. I think for AV1 they're using VMAF too, which is an actual video quality metric (https://github.com/Netflix/vmaf https://github.com/Netflix/vmaf).
      - brigade 5y ago
        Sure you can use VMAF as the quality metric for BD-rate, that’s what BD-VMAF is
    - lmm 5y ago
      But even after choosing a method, I want to be able to set target quality in a meaningful way. Having a parameter that I can set to specify quality on a method-agnostic scale seems like a basic usability feature.

astrange 5y ago

It only targets a bitrate if you tell it to. Constant quality/crf mode doesn't care about bitrate, it just applies a quality level to whatever makes it to intra prediction (which is the stage after inter prediction, where all the motion compensation is).

prvc 5y ago
Lower crf will lead to higher bitrates, everything else being equal. It makes no sense to compare this figure between different presets.

brigade 5y ago

The author is pretty confused. x264’s slower presets enable searching more points in ME and a more accurate RDO (among other things), just like x265’s. But in all cases for any modern encoder, all mode decisions are done baed on the estimated bitcost relative to distortion, so the slower presets are just evaluating more options. (kinda) That said, it is the case across all codecs that more accurate motion vector fields (e.g. using optical flow) are not generally optimal. A simple way of reasoning about that is that one block reusing the same motion vector as a neighboring block is much cheaper than encoding a marginal difference, which often more expensive than the bits saved in the residual. Anyway, CRF was never designed to map to the same quality across different encoder settings, which having actually read the article, is what I think they’re actually complaining about.

lmm 5y ago
So what is designed for that? Generally as an encoder you want to target a certain (perceptual) quality level and when testing different settings you're aiming to hold that constant and see whether you achieve a lower bitrate. There should be a way to do that.
- brigade 5y ago
  You plot two RD curves with whatever quality metric you care about, then calculate the distance between them. Also known as the Bjontegaard metric.
  - slhck 5y ago
    And the issue with that is that they're using PSNR and SSIM as quality metrics, which are useful for images, but haven't been designed for video, so they cannot take into account temporal factors and how motion masks distortion, etc. I think for AV1 they're using VMAF too, which is an actual video quality metric (https://github.com/Netflix/vmaf https://github.com/Netflix/vmaf).
    - brigade 5y ago
      Sure you can use VMAF as the quality metric for BD-rate, that’s what BD-VMAF is
  - lmm 5y ago
    But even after choosing a method, I want to be able to set target quality in a meaningful way. Having a parameter that I can set to specify quality on a method-agnostic scale seems like a basic usability feature.