Hello guys!
I am trying to make the move to hevc but I have so much media that it would take so long to convert it manually that I wish there was a better way. I converted a few files with handbrake and was surprised to see the size cut in half with the quality roughly the same. Do you guys know of any software that supports hardware accel for AMD and/or software that can automate the process? Also feel free to tell me about your experiences with hevc and the move to it.
Thanks in advance.
well with handbrake you could write a shell script to fetch all .mkv inside of a directory and run the desired handbrake setup. Handbrake even has built in support for this from gui
Yeah handbrake was a fallback option for me, I just hoped there was something that supported hardware accel.
Well unless you have a cpu with build in hevc support it wont help much on speed.
ffmpeg should also help
INPUT="$1"
for i in *.mkv ; do
ffmpeg -i “$i” -bsf:v h265_mkvtoannexb -sn -map 0:0 -map 0:1 -vcodec libx265 “$i.ts”
mv “$i.ts” “$i.mpg”
sleep 3
done
I was more thinking of gpu hardware accel. Thanks for the script though, I know this will come in handy for my anime collection if I don’t find a better way.
Check this out and modify script to suit your hardware
Unless all your client devices already natively support HEVC and there will be no situation where transcoding might be required - I’d advise against using HEVC with Plex just now.
With the computing power of today’s CPUs, you won’t be happy.
Most of my remote clients transcode anyways so its not something I am too concerned about. I have a fx8350 and it does a okay job I think.
@Rsslone said:
Most of my remote clients transcode anyways so its not something I am too concerned about. I have a fx8350 and it does a okay job I think.
It is not your clients, which do the transcoding, it is your server. And HEVC (H.265) requires a LOT more cpu power, just for decoding it. So your server’s cpu will probably overload if 2 clients are trying to transcode at the same time.
The fx8350 has just 8945 passmarks. This may suffice for one transcoded HEVC stream (whereas it is about enough for 4 transcoded AVC [H.264] streams).
I should have used better wording. My clients have it set to transcode the media. I am aware my server does the actual processing. Personally I have not went out of my way to stress test it but I have not noticed problems with concurrent transcodes yet. I didn’t really imagine it would be a big deal so I guess I should test before I make the move. Thanks.
I did tests with hevc on an i7 haswell. I could do about 3 streams with the cpu at 100% and obviously the cpu can get ahead and throttle. After 4th it really stressed and 5th killed it.
Very interesting! I’m sure my CPU is a little weaker than yours but I’ve never had more than 3 concurrent streams. I’m thinking about just converting my anime since most of my clients only watching TV shows and movies.
I would stick to x264, for some more times. I have a handful x265, I do notice a lot higher cpu usages. How ever not so much unpack network utilisation as one would think.
@hackztor@gmail.com said:
I did tests with hevc on an i7 haswell. I could do about 3 streams with the cpu at 100% and obviously the cpu can get ahead and throttle. After 4th it really stressed and 5th killed it.
i7 Haswell is a very broad description. Depends also if that cpu is built into a desktop type box or a tablet/laptop. The latter are commonly ‘throttled’ by the manufacturer to prevent overheating.
But most of all: the h.265 encoded files themselves can be wildly different regarding the cpu resources needed to decode them. In these early days we won’t see many files which make use of all features of the h.265 codec to save space/enhance the quality. But these will come, once the encoder software gets more optimized and people who do the encodes devote more cpu time to their encodes.
So the results you cite could be very different with a different set of test files.
Besides the actual “can it do it” performance-wise, last time I checked the end result in terms of picture quality was subpar on a Plex live-transcoded HEVC session. Slight jitter and artifacts was visible. Not something I’d personally recommend.
@Peter_W said:
Besides the actual “can it do it” performance-wise, last time I checked the end result in terms of picture quality was subpar on a Plex live-transcoded HEVC session. Slight jitter and artifacts was visible. Not something I’d personally recommend.
I didn’t know this was a thing. Is this a known issue?
Generally speaking, the transcoding part of Plex aims for speed not quality. You will never get equal end result if you optimize the files beforehand as oppose to the live transcoding. It might be doable on a smaller screen such as a tablet or mobile phone (where quality might not be applicable), but I’d strongly suggest to try and avoid transcoding when using it in other more demanding settings. In terms of HEVC, I’m not sure it’s anything “wrong” or an “issue” as such. It’s just that it takes a lot of CPU power to do and it isn’t optimized yet as Otto described in detail which creates a downside to it.
A update on what I decided to do, since the lack of gpu acceleration and some of the conversions not coming out how I hoped, I am going to just grab releases in HEVC going forward. I hope h.265 gets mainstream support soon.
Desktop quad core with hyperthreading.
@OttoKerner said:
@hackztor@gmail.com said:
I did tests with hevc on an i7 haswell. I could do about 3 streams with the cpu at 100% and obviously the cpu can get ahead and throttle. After 4th it really stressed and 5th killed it.i7 Haswell is a very broad description. Depends also if that cpu is built into a desktop type box or a tablet/laptop. The latter are commonly ‘throttled’ by the manufacturer to prevent overheating.
But most of all: the h.265 encoded files themselves can be wildly different regarding the cpu resources needed to decode them. In these early days we won’t see many files which make use of all features of the h.265 codec to save space/enhance the quality. But these will come, once the encoder software gets more optimized and people who do the encodes devote more cpu time to their encodes.
So the results you cite could be very different with a different set of test files.
Another problem with h265 is the encoding time of the movie. I use medium and great quality and it took I think 12+ hours per movie. (45GB rip 1:1). Size ended up being 15GB (h2565) versus 20GB (h264). I have been following x265 project and started testing back in version 1.4 they are now on 1.9. I would say it still has some ways to go. I would say h265 will become more mainstream in about 1-2 years. It takes time for devices to get the chips that can direct play h265 and then for people to actually get the newer devices. Roku 4 and Nvidia Shield TV can direct play. In addition, newer video cards support h265 encoding if you use hardware acceleration (I just use cpu as it gives better quality). If anything tv shows would benefit now since they are smaller and the cpu would not have to run as much that a movie.
