5 ms·

While still waiting for Daala I've already started encoding my videos in H.265 separately from handbrake, using mplayer. It's been going very well, H.265 will b

by quink 12y ago

While still waiting for Daala I've already started encoding my videos in H.265 separately from handbrake, using mplayer. It's been going very well, H.265 will be awesome once it really starts hitting the mainstream. The bitrates are magically small and x265 is pretty fast. mkv container and Opus audio.

voltagex_ 12y ago
I realise this is subjective but how's the quality of x265? What's the encoding speed like in comparison to x264?
- kristofferR 12y ago
  It's good for bitrate starved files, but x264 is actually still more efficient for transparent encodes. x265 currently can't handle noise very well. x265 is also much slower than x264, but it's getting faster all the time.
  - gillianseed 12y ago
    >It's good for bitrate starved files, but x264 is actually still more efficient for transparent encodes. x265 currently can't handle noise very well. Yes this is my impression as well from the tests I've made. >x265 is also much slower than x264, but it's getting faster all the time. It will remain slower than x264 though, it uses more cpu consuming algorithms in order to cram out more 'quality per bit', that said it likely has a lot of performance improvements left to do.
    - xooyoozoo 12y ago
      >It will remain slower than x264 though, it uses more cpu consuming algorithms in order to cram out more 'quality per bit' At an abstract level, HEVC is AVC + refinement + new algorithms. Conforming bitstreams aren't required to use all or even most features, so in the long-term, I don't see why an HEVC encoder can't be a simple, straightforward superset of x264 (i.e. same speed for same quality).
      - gillianseed 12y ago
        Sure, but the whole point behind x265 is to provide better quality per bit than x264.
  - jzelinskie 12y ago
    By noise, do you mean something like a grain filter? If so, that blows up the size of x264 encodes as well -- enough that people will usually go out of their way to remove said grain to improve the encode.
- car 12y ago
  It's early days for H.265, but it's very promising, both in terms of file size and image quality. For encoding 4K video it seems to be an absolute necessity. This article has a paragraph about H.265 from the standpoint of a professional photographer: http://www.eoshd.com/2014/11/samsung-nx1-review-glory-technology/ http://www.eoshd.com/2014/11/samsung-nx1-review-glory-techno....
1ris 12y ago
The last time I tried x265, about half a year I was really disappointed. For what I tried (a low bitrate encode with a very slow encode, Hi10p profile for x264) x264 was only slightly worse for the same crf (witch x264 and x265 share) - less than 15% worse, but the encoding time for x264 was practical (on my machine about 2 frames per second) while x265 was simply to slow for real-world use for me (about 0.1 fps). My Computer is somewhat old, but I doubt that newer PCs would to so much better. I can't even image how long it takes to encode 8k.
- Osiris 12y ago
  I ran a test using x264 and x265 just about a month ago. The x265 encoding took about twice as long, and was half the bitrate for the same constant quality setting. However, since all my playback devices (Fire TV w/ XBMC) rely on H264 hardware decoding, I have to stick with x264.

by quink 12y ago

voltagex_ 12y ago

I realise this is subjective but how's the quality of x265? What's the encoding speed like in comparison to x264?

kristofferR 12y ago
It's good for bitrate starved files, but x264 is actually still more efficient for transparent encodes. x265 currently can't handle noise very well. x265 is also much slower than x264, but it's getting faster all the time.
- gillianseed 12y ago
  >It's good for bitrate starved files, but x264 is actually still more efficient for transparent encodes. x265 currently can't handle noise very well. Yes this is my impression as well from the tests I've made. >x265 is also much slower than x264, but it's getting faster all the time. It will remain slower than x264 though, it uses more cpu consuming algorithms in order to cram out more 'quality per bit', that said it likely has a lot of performance improvements left to do.
  - xooyoozoo 12y ago
    >It will remain slower than x264 though, it uses more cpu consuming algorithms in order to cram out more 'quality per bit' At an abstract level, HEVC is AVC + refinement + new algorithms. Conforming bitstreams aren't required to use all or even most features, so in the long-term, I don't see why an HEVC encoder can't be a simple, straightforward superset of x264 (i.e. same speed for same quality).
    - gillianseed 12y ago
      Sure, but the whole point behind x265 is to provide better quality per bit than x264.
- jzelinskie 12y ago
  By noise, do you mean something like a grain filter? If so, that blows up the size of x264 encodes as well -- enough that people will usually go out of their way to remove said grain to improve the encode.
car 12y ago
It's early days for H.265, but it's very promising, both in terms of file size and image quality. For encoding 4K video it seems to be an absolute necessity. This article has a paragraph about H.265 from the standpoint of a professional photographer: http://www.eoshd.com/2014/11/samsung-nx1-review-glory-technology/ http://www.eoshd.com/2014/11/samsung-nx1-review-glory-techno....

1ris 12y ago

The last time I tried x265, about half a year I was really disappointed. For what I tried (a low bitrate encode with a very slow encode, Hi10p profile for x264) x264 was only slightly worse for the same crf (witch x264 and x265 share) - less than 15% worse, but the encoding time for x264 was practical (on my machine about 2 frames per second) while x265 was simply to slow for real-world use for me (about 0.1 fps). My Computer is somewhat old, but I doubt that newer PCs would to so much better. I can't even image how long it takes to encode 8k.

Osiris 12y ago
I ran a test using x264 and x265 just about a month ago. The x265 encoding took about twice as long, and was half the bitrate for the same constant quality setting. However, since all my playback devices (Fire TV w/ XBMC) rely on H264 hardware decoding, I have to stick with x264.