Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Goatshade]

You know how there are client options in Media Network for converting video content to a certain format and resolution, and how there is an entire H.264 TS segment with options from 240p to 1080p, with or without AutoFPS?

Could we perchance get the H.265 equivalent?

[Hendrik]

H.265 encoding is way too slow for that to be feasible.

[Goatshade]

Slow for consumers with slower machines, or slower all around?

[Hendrik]

Basically, for everyone. Real-time encoding H.265 would require a massive beast of a machine, if even that works. Its an order of magnitude slower then H.264.
We could think about allowing it for offline encoding, but until we have the ability to actually define custom presets for encoding, that might not be the best idea either.

[DeaneG]

I'd like to be able to convert JTV files to h.265. My 5-year-old PC transcodes h.264 into h.265 at about 1/4 to 1/8 real time rates. Sometimes the reduced space for mobile is more important than the added time.

[RD James]

I'm sure that I've asked this before, but: are hardware encoders a possibility for this?
The quality is not as good as CPU-based encoders, but I think any current dedicated video card should be able to transcode to H.265 faster than realtime.

[Neco]

Wouldn't GPU assisted encoding be worth a look at?   Maybe as a Beta feature?   Even the low end consumer cards these days are coming with dedicated encoders baked in

[Hendrik]

GPU encoding really only has one purpose, for streaming at high bitrates. For archival, the quality of the GPU encoders is too bad.

[RD James]

GPU encoding really only has one purpose, for streaming at high bitrates. For archival, the quality of the GPU encoders is too bad.

I realize that my post may not have been clear, but the reason I brought them up would be for temporary transcodes for streaming to remote devices, rather than local conversions.

[Neco]

yeah that is what I thought his post was about too.  Streaming to a mobile / remote device.

That being said the response about archival quality video makes no sense, in relation to the previous response about real-time encoding speed  ?


These are mutually exclusive situations..

If the question is supporting  HEVC encoding for archiving / storing a media file in the library then I don't see why that shouldn't be an option for those of us with powerful enough CPUs to choose when we rip.  (personally I'd like to see full support for exposing all encoder AVC/HEVC encoder flags to the user as well)


If the question is supporting HEVC via GPU encoding for real-time streaming from your library server to a mobile platform or some such, then again I'm not really sure where the resistance is coming from.

[Hendrik]

We're looking into GPU encoding for streaming, but unless you stream in 4K, using GPU HEVC encoders is likely not going to be advantageous quality-wise over the GPU H.264 encoders, which are far more mature and better featured.

[Goatshade]

If it's worth noting, I've been ripping H.264 and MPEG2—FHD and below—content to H.265 for the greater space efficiency. 4K is not the only use case.

[Neco]

Honestly my only reason to use H.265 for mobile streaming at this point wouldn't be for any image quality concerns, it would be for bandwidth concerns.

I haven't done any tests, but I'd go with my gut and say even if H.264 GPU encoders are more mature,  H.265 may still match or edge them out in quality at extremely low bitrates.

[Hendrik]

Honestly my only reason to use H.265 for mobile streaming at this point wouldn't be for any image quality concerns, it would be for bandwidth concerns.

Bandwidth and quality are different sides of the same coin. If you have higher quality, you could in turn reduce the bandwidth to get the same quality as another encoder.

Low bitrate streaming is not what GPU encoders are optimized for, though. HEVC hardware encoding lack a lot of features compared to H.264 or software encoders.
Although I guess it may result in similar results given similar bandwidth, since they are pretty constrained as it is.

The only thing they are good for is being fast, and at low resolution the x264 software encoder is also fast, at higher quality to boot. But I guess if you're severly starved for CPU..

There is really no point for theoretical arguments about this though when one could just make test encodes to see how it would look. So I'll take some test footage and make low bitrate encodings with x264 (software) and NVIDIA H.264 and H.265 when its time to work on this.

[muzicman0]

I use FFMPEG enabled with NVENC to archive my recorded TV to h.264 854x480, at the source FPS (and de-interlaced if applicable).  It is decent quality.  more than adequate for me.  The benefit is that I am not killing my CPU every night during the encode processes, and it takes a significantly less amount of time to encode.  In my case, I watch the original broadcast in FHD, then once the file is marked as watched, it will encode during the night. I experimented with h.265, and couldn't get great results, however, I believe as the technology matures it will be better.

[JustinChase]

If it's worth noting, I've been ripping H.264 and MPEG2—FHD and below—content to H.265 for the greater space efficiency. 4K is not the only use case.

May I ask what software you're using to do these conversions?

Thanks

[Goatshade]

May I ask what software you're using to do these conversions?

Thanks

Usually, Handbrake in conjunction with AnyDVD HD. The former works very well as a ripper in conjunction with the latter.

Some very specific sources occasionally rip with strange issues, such as hangs during audio track conversions or erroneous A/V sync in the output. In those cases, I disable AnyDVD HD, rip the content with MakeMKV first, separate the audio tracks with MKVToolNix, convert them with MC, mux them back in to the source rip, and then hit said source rip with Handbrake. It's worked every time, so far.