Jump to content

Transcode in H265


Snaaaake

Recommended Posts

schamane

I know how this work, but as an example, I want to use is this feature mainly on Live-TV, but dont need it on Movies or tv-shows. So I would love to have an option to force Transcoding to h265 on live-tv, but not on Movies etc.

I have to deinterlace TV anyways on clients  like fire-tv Sticks, cause they suck in TV, so i even can force this client to h265 would be a nice option

Link to comment
Share on other sites

EricGRIT09

I know how this work, but as an example, I want to use is this feature mainly on Live-TV, but dont need it on Movies or tv-shows. So I would love to have an option to force Transcoding to h265 on live-tv, but not on Movies etc.

I have to deinterlace TV anyways on clients  like fire-tv Sticks, cause they suck in TV, so i even can force this client to h265 would be a nice option

 

Maybe I'm missing something here but why be selective in the codec?  Wouldn't being selective in transcoding or not be more applicable here?  Meaning, if you need/want to transcode live TV because you have to de-interlace on the server anyways then go ahead and use h265.  Similarly, if you don't need to de-interlace movies/TV then it shouldn't transcode and simply direct play.  There's no situation there where you need to transcode to h264 for Movies/TV, right?  And if you were to transcode for Movies/TV then why not use the more efficient codec, being h265?  

Link to comment
Share on other sites

And if you were to transcode for Movies/TV then why not use the more efficient codec, being h265?  

 

Because that codec is only "more efficient" from the perspective of the consumer.  From the perspective of creating the output (encoding into x265) it is WAY less efficient.  Most people's  hardware would not be able to handle it.  So, it is something that has to be done very selectively at this point.

Link to comment
Share on other sites

Charlie117

Because that codec is only "more efficient" from the perspective of the consumer.  From the perspective of creating the output (encoding into x265) it is WAY less efficient.  Most people's  hardware would not be able to handle it.  So, it is something that has to be done very selectively at this point.

 

True for software encoding to H.265 but hardware transcoding to H.265 would not be any different from H.264 in terms of efficiency. Support for H.265 hardware transcoding has been available on CPUs and GPUs for quite some time now.

 

I'd think allowing software encoding to H.265 for real time playback would probably result in a lot of confused people reporting issues. So perhaps that should be disabled altogether? 

Link to comment
Share on other sites

wiwolavida

There is an option for "normal view" and "expert view". Just show it for expert and you're good.

many devices can handle h265 1080p very well. Maybe not some little prebuild nas, but many others.

For me the main usage of this feature would be transcoding 4k hevc to less bitrate 4k hevc. I only have around 40mbit upload. I'd like to scale down 4k movies to around 15-20mbit.

Also support for hdr would be nice.

Link to comment
Share on other sites

EricGRIT09

Because that codec is only "more efficient" from the perspective of the consumer.  From the perspective of creating the output (encoding into x265) it is WAY less efficient.  Most people's  hardware would not be able to handle it.  So, it is something that has to be done very selectively at this point.

 

Understood I wasn't clear in that - it is more efficient from a bitrate perspective.  I totally agree that it should be an option, 100%, but selectivity between *media types* is what I'm struggling with.  If you have the horsepower to utilize h265 encoding then, if you enable it, it can simply be enabled for all encoding to supported devices.  If it's a question about limiting the amount of h265 encodes due to horsepower concerns then maybe have an option to limit total # of h265 encodes regardless of media type, once you hit the limit then it switches over to h264 encoding perhaps.  Although, that now complicates things just like having selectivity based on media type.  

Link to comment
Share on other sites

  • 2 weeks later...
WGB123

I use Emby as most others do here – to distribute media throughout the house.  Most clients are on wired Ethernet, so bitrate/bandwidth is not really a concern.  But, the PRIMARY reason for my use of Emby is to view live TV (news & sports) while overseas.  I spend several days every month in hotels overseas.  The download rate in these hotels is almost never a problem.  My upload rate at home is 10 Mbps.  This is fast enough to get a fairly decent looking picture.  But, at certain times of the day, the trans-Pacific cables are saturated and my available bandwidth across the ocean drops to a fraction of my home's upload speed.  I think that, in this situation, having live TV transcoded to H.265 would be helpful.

 

My machine was purpose-built to be used as an Emby server.  I have a Kaby Lake (i5-7600T) CPU running Windows 10 Pro, so it supports H.265 HW encoding.  Every TV in the house either supports or has an attached client that supports H.265:  LG webOS, Samsung Tizen OS, Roku TV (4K), Nvidia Shield, Chromecast Ultra.  For hotels, I have been using a Roku Streaming Stick, but I just purchased a Streaming Stick+ to replace it — specifically because of its H.265 capability.  I just installed MCEBuddy to automatically remove ads and convert all my DVR recordings to H.265.  I haven't viewed these recordings from overseas yet, but I will next month.  The only piece of this puzzle that is now missing is H.265 transcode of live TV.  ;)

 

I'm not certain that my machine is fast enough to transcode the live MPEG2 1080i60 streams to HEVC without dropping frames or buffering, but based on MCEBuddy's speed of conversion (using HW acceleration), it would appear to be.

Edited by WGB123
Link to comment
Share on other sites

Because that codec is only "more efficient" from the perspective of the consumer.  From the perspective of creating the output (encoding into x265) it is WAY less efficient.  Most people's  hardware would not be able to handle it.  So, it is something that has to be done very selectively at this point.

I wouldn't say that.  I think for many of us it would be more efficient for the server side.  I know of no one who has lower receiving bandwidth than transmitting bandwidth.  It's the server UPLOAD bandwidth that for most instances makes the differences.  When you only have 5, 10 or 20 Mb upload on the server side the more efficient the codec used the better.

 

There are of course other reasons as well.  Anyone on mobile or using a metered connection would benefit as well as less bits are required for same quality.  It of course could also benefit the client side if it's limited like hotel or international connections.

 

Let bits is less bits is less bits. :)

Of course this all depends if the client and the server support H.265 and I'd go as far as say have HW support.

 

 

I'm not certain that my machine is fast enough to transcode the live MPEG2 1080i60 streams to HEVC without dropping frames or buffering, but based on MCEBuddy's speed of conversion (using HW acceleration), it would appear to be.

If you have HW encoding of H.265, it will be fast enough. I say that with 99% confidence. :)

  • Like 1
Link to comment
Share on other sites

I wouldn't say that.  I think for many of us it would be more efficient for the server side.  I know of no one who has lower receiving bandwidth than transmitting bandwidth.  It's the server UPLOAD bandwidth that for most instances makes the differences.  When you only have 5, 10 or 20 Mb upload on the server side the more efficient the codec used the better.

 

I was talking about efficiency of actually creating an h.265 encode vs h.264... 

Link to comment
Share on other sites

I wouldn't say that.  I think for many of us it would be more efficient for the server side.  I know of no one who has lower receiving bandwidth than transmitting bandwidth.  It's the server UPLOAD bandwidth that for most instances makes the differences.  When you only have 5, 10 or 20 Mb upload on the server side the more efficient the codec used the better.

 

There are of course other reasons as well.  Anyone on mobile or using a metered connection would benefit as well as less bits are required for same quality.  It of course could also benefit the client side if it's limited like hotel or international connections.

 

Let bits is less bits is less bits. :)

Of course this all depends if the client and the server support H.265 and I'd go as far as say have HW support.

 

If you have HW encoding of H.265, it will be fast enough. I say that with 99% confidence. :)

 

It will cost you more money to use h.265 than h.264. It will use more clock cycles and more of the GPU TDP. It will draw more power to do the conversion. This will raise the cost of your electricity. Now it might just raise it a dollar or two per month to do this. In some countries that equates to a deal breaker. In some countries such as Brazil. They pay by what they consume ahead of time. Sort of like is done in the UK. You run out of credit poof your power is gone. So keep that in the equation too. More taxing on the CPU/GPU = more money you pay your power company.

Link to comment
Share on other sites

mrfragger

Also it’ll saves me about $1,000 for not having to buy as many SSDs by converting most of my videos to x265 so there’s that argument too. I agree though when Emby does decide to roll out this transcoding feature there will be many moans and groans. Initially though just having it do conversions would be ideal.

  • Like 1
Link to comment
Share on other sites

wiwolavida

Most people don't mind that h265 puts harder strain on the server. Many GPUs can transcode h265 easily.

The main concern is the bandwidth. E.g. I have 40k Mbit Upload. That's not enough for 4k movie.

I would like to transcode the 4k movie into 18 Mbit 4k. It would still look pretty good and I can have 2 streams at a time.

18mbit h264 is not that great...

Another scenario is streaming to my parents. They can only have 3mbit download.

H265 1080p would look good. H264 not at all.

 

The hard and software is ready for h265 transcode. Many people would greatly benefit from that.

  • Like 1
Link to comment
Share on other sites

WGB123

HEVC (H.265) encoding in hardware has been available in Intel CPUs from Skylake (6th generation Core) going forward.  That CPU was introduced in August 2015.  It is now almost four years later and we are on the 9th generation of Intel Core CPUs.  H.265 decoding is widely available in the most popular TV OS’s and client hardware that can be had for as little as $40 (Fire TV Stick 4K & Roku Streaming Stick Plus).  So, this is not bleeding edge stuff.

 

When my 7th generation Core i5 CPU simultaneously converts four MPEG2 1080i60 recordings to H.265 using hardware decode/encode (Intel Quick Sync Video), the fan only slightly increases in speed — indicating that it’s not putting much strain on the CPU at all.  Now, if I were to try even one conversion using software only — the fan would very quickly increase to its maximum speed.

Edited by WGB123
  • Like 1
Link to comment
Share on other sites

sluggo45

It will cost you more money to use h.265 than h.264. It will use more clock cycles and more of the GPU TDP. It will draw more power to do the conversion. This will raise the cost of your electricity. Now it might just raise it a dollar or two per month to do this. In some countries that equates to a deal breaker. In some countries such as Brazil. They pay by what they consume ahead of time. Sort of like is done in the UK. You run out of credit poof your power is gone. So keep that in the equation too. More taxing on the CPU/GPU = more money you pay your power company.

 

 

 

If, as you describe, you are so close to the edge of your power budget that "a dollar or two per month" is a "deal breaker" then you shouldn't be running a media server at all. Particularly if doing so means you run out of credit and "poof, your power is gone".

 

I am all for power-saving strategies and implement many myself, but this kind of edge-case whataboutism doesn't fit the context of this thread/request.

  • Like 1
Link to comment
Share on other sites

Charlie117

It will cost you more money to use h.265 than h.264. It will use more clock cycles and more of the GPU TDP. It will draw more power to do the conversion. This will raise the cost of your electricity. Now it might just raise it a dollar or two per month to do this. In some countries that equates to a deal breaker. In some countries such as Brazil. They pay by what they consume ahead of time. Sort of like is done in the UK. You run out of credit poof your power is gone. So keep that in the equation too. More taxing on the CPU/GPU = more money you pay your power company.

 

Would hardware transcoding to H.265 really require more power than H.264? I am fairly certain the ASIC/VPU gets stressed equally really for both codecs.

 

I am assuming you are therefore referring to software transcoding to H.265 requiring more power than H.264, which is likely true. However, is software transcoding to H.265 really relevant in this discussion? It is most certainly too slow for real time transcoding for the majority of servers and conversions will likely take days at somewhat decent settings to make it an improvement over H.264 software or even hardware transcoding. 

Edited by Charlie117
Link to comment
Share on other sites

abescalamis

I don't understand how some are so eager to use or jump into the h.265 so soon, it is just a compression that makes the size of the video smaller in exchange it uses more hardware or software power to decompress.

 

Remember guys that H.265 will become the standard in a few years, when the hardware eventually gets more powerful, even emby then will make h.265 the default compression standard, its all about waiting.

 

Even with the hardware, If you would stream h.265 to multiple client (5-10) at the same time then you will understand why is not such a great idea at this present time.

 

 

There is also a huge possibility that h.265 never gets to the pointe of becoming the standard compression format and gets replaced by AV1.

Edited by abescalamis
Link to comment
Share on other sites

Charlie117

I don't understand how some are so eager to use or jump into the h.265 so soon, it is just a compression that makes the size of the video smaller in exchange it uses more hardware or software power to decompress.

 

Why not be eager? You can now get higher quality transcodes with h.265 at equal bitrates compared to h.264. How is that not a major improvement for everyone? Also, it does not necessarily take more power to decompress if you have a CPU/GPU that can hardware decode it, which you really should anyway. Basically everything from my phone to TV is capable of hardware decoding H.265 4K.

 

Remember guys that H.265 will become the standard in a few years, when the hardware eventually gets more powerful, even emby then will make h.265 the default compression standard, its all about waiting.

 

H.265 is already the standard for 4K on Blu-ray, Netflix, Amazon Prime etc. We already have hardware capable of hardware transcoding and decoding since 2015. The time for waiting is over and postponing H.265 transcoding is not logical at all.

 

Even with the hardware, If you would stream h.265 to multiple client (5-10) at the same time then you will understand why is not such a great idea at this present time.

 

This really isn't much different from h.264, both for software transcoding as for hardware transcoding. Additionally, I imagine the number of Emby users that would require 5-10 simultaneous real time transcodes is close to zero.

 

There is also a huge possibility that h.265 never gets to the pointe of becoming the standard compression format and gets replaced by AV1.

 

As mentioned before, it is already the standard for 4K right now. Waiting for another codec to replace it if ever (remember how VP9 was supposed to replace H.264?) again makes no sense to me. The hardware is widely available for it and we can benefit from it now. 

Edited by Charlie117
  • Like 1
Link to comment
Share on other sites

abescalamis

@@charlie, I understand your point of view and the excitement over it, but even after your explanation, those reasons lack of fundamental basics that developers use, to make it a reality.

 

As an example of what I mean:

 

Just for what you said I can tell that you have some serious bucks on equipment, Emby has users with low, medium and high budget, If emby was to enforce it right now it will create issues to others "not you", also some users don't have the same knowledge you do, and they will go crazy trying to figure out how to fix the issues that it will create to them, as developer I wouldn't do it "yet", I would wait like I said.

 

All I'm saying is that the timing is not the best, maybe in a year or two.

Edited by abescalamis
Link to comment
Share on other sites

WGB123

I don't understand how some are so eager to use or jump into the h.265 so soon, it is just a compression that makes the size of the video smaller in exchange it uses more hardware or software power to decompress.

 

It has been explained previously in this thread who would benefit and how:

  • People with low upload bandwidth on the server side
  • People with low download bandwidth on the client side
  • People with data caps
  • People using cellular on the move (e.g., kids in the car) where bandwidth is variable

 

The possible reasons for the low bandwidth are many and varied:

  • Low download speed in hotels, motels, cottages, cabins, AirBnBs, etc.
  • Rural areas that are only served by satellite
  • Areas that only have DSL available
  • Limited transoceanic and/or intercontinental bandwidth
  • Some people to whom you wish to give access to your server may not be able to afford anything but the slowest speeds offered by their ISP.

It has also been pointed out previously that H.265 decoding is very widely available:

  • AFAIK, all 4K TVs have it
  • My 2015 Samsung 1080p (not 4K) TV has it
  • It can be added to any TV that doesn't have it by purchasing a $40 "stick" (at least two brands)
Edited by WGB123
  • Like 1
Link to comment
Share on other sites

VirgilFox

 

It has been explained previously in this thread who would benefit and how:

  • People with low upload bandwidth on the server side
  • People with low download bandwidth on the client side
  • People with data caps
  • People using cellular on the move (e.g., kids in the car) where bandwidth is variable

 

The possible reasons for the low bandwidth are many and varied:

  • Low download speed in hotels, motels, cottages, cabins, AirBnBs, etc.
  • Rural areas that are only served by satellite
  • Areas that only have DSL available
  • Limited transoceanic and/or intercontinental bandwidth
  • Some people to whom you wish to give access to your server may not be able to afford anything but the slowest speeds offered by their ISP.

 

 

My upload bandwidth at home is 1.5 Mbps, so in order to get decent video quality when I'm away from home (at work, etc.) I have to use HandBrake to create separate HEVC/H265 versions of every video specifying a vbv:maxrate of 1 Mbps. It would be great if Emby would support HEVC/H265 conversion (and transcoding) to allow me to make best use of my limited upload bandwidth.

  • Like 2
Link to comment
Share on other sites

Charlie117

@abescalamis I believe you are misunderstanding two critical points about this suggestion.

 

1) Adding an option to transcode to H.265 does not mean it would or should replace the existing option to transcode to H.264. Those people with older hardware that cannot transcode or decode H.265 can simply stick to using H.264 instead. I do agree with you however that it is currently too early to allow software transcoding to H.265, so I think that shouldn't be added as an option at all. Honestly, I doubt even in 2 years it will be viable to software transcode to H.265 given the current pace of CPU processing power improvements. 

 

2) Entry level CPUs and GPUs nowadays have support for H.265 hardware transcoding and decoding. This really has nothing to do with being privileged with having 'high budget' equipement. You could argue that users with older equipment would have problems with this addition, but again this option would simply not be available to them if their hardware does not support it. That's already how it works for hardware transcoding to H.264 right now, the options simply does not show up in the server settings if the server hardware does not support it.

 

I really think you're anticipating problems that are very unlikely to happen. 

Edited by Charlie117
  • Like 2
Link to comment
Share on other sites

WGB123

...Emby has users with low, medium and high budget, If emby was to enforce it right now it will create issues to others "not you", also some users don't have the same knowledge you do, and they will go crazy trying to figure out how to fix the issues that it will create to them, as developer I wouldn't do it "yet", I would wait like I said.

 

I think that we are just asking for the option.  Could be implemented with an "expert settings" slider toggle and accompanied by a warning that it is only for those with hardware encoding capability.

  • Like 2
Link to comment
Share on other sites

abescalamis

I think that we are just asking for the option. Could be implemented with an "expert settings" slider toggle and accompanied by a warning that it is only for those with hardware encoding capability.

That would be a good way, you guys needs to give an idea like that for developers to do it, because they will never add a feature that would benefit some and affect some.

Link to comment
Share on other sites

abescalamis

@abescalamis I believe you are misunderstanding two critical points about this suggestion.

 

1) Adding an option to transcode to H.265 does not mean it would or should replace the existing option to transcode to H.264. Those people with older hardware that cannot transcode or decode H.265 can simply stick to using H.264 instead. I do agree with you however that it is currently too early to allow software transcoding to H.265, so I think that shouldn't be added as an option at all. Honestly, I doubt even in 2 years it will be viable to software transcode to H.265 given the current pace of CPU processing power improvements. 

 

2) Entry level CPUs and GPUs nowadays have support for H.265 hardware transcoding and decoding. This really has nothing to do with being privileged with having 'high budget' equipement. You could argue that users with older equipment would have problems with this addition, but again this option would simply not be available to them if their hardware does not support it. That's already how it works for hardware transcoding to H.264 right now, the options simply does not show up in the server settings if the server hardware does not support it.

 

I really think you're anticipating problems that are very unlikely to happen. 

 

You are right, I never said that any of you is wrong, the whole idea behind my opinion is that you guys need to come up for a way or idea that can make it happen, because from the developer point of view is not viable yet, and all you will get from them is: "Thank you, is possible for the future".

 

remember that for them is a product.

 

The way the see it: (but they will never tell you guys, because it will make the discussion last forever).

 

Its a good idea, but if we add it now it will be more work as if I added later, and it will be easier to implement later.

 

They have huge to do lists, and even if the idea is good they won't do it for the amount of work it will take them.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...