In-Progress Transcode in H265

[WGB123 8]

https://go.bitmovin.com/hubfs/Bitmovin-Video-Developer-Report-2018.pdf?submissionGuid=f41efe3c-7a1b-465e-8a1e-8eab839e4ad1

[daedalus 430]

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.

adding options to please more than one group is nothing emby showed to be interested in

 

 

because they will never add a feature that would benefit some and affect some.

just look around a bit, they are constantly doing this, mostly because their enforced repulsion on options

[Happy2Play 9388]

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.

 

Well HWA itself is exactly that.

[shorthand 5]

I will toss in my hat and say I would be a big fan for H265 encoding. Seeing as AMD AMF now supports h265 encoding quite well, and most 4k devices have no issue with it either!

[byakuya32 24]

When can I expect to get the option to convert to h.265 within emby?

[Luke 39785]

We're working as hard and as fast as we can to bring you the features you want as soon as possible. Thanks.

[shorthand 5]

We're working as hard and as fast as we can to bring you the features you want as soon as possible. Thanks.

Sounds good to me .

[wiwolavida 4]

do you have a rough estimation on when we can expect the feature to release?
Is it a priority in your development?

 

You would make a lot of people with low upload very happy =) E.g. in Germany you rarely have over 40mbit upload unless you are one of the lucky few with ftth. Transcoding 4k files to a manageable 15-30 mbit bitrate would be a blessing.

[Luke 39785]

I'm hoping to be able to look at this soon. Thanks.

[daedalus 430]

just to forge a bridge, after more than 2 years, devs are hoping to look at something soon, that should have been part of the initial design process

Edited August 20, 2019 by daedalus

[wiwolavida 4]

I agree.

I and assumably many others here were under the impression, that this feature was actively worked on. It wasn't even looked at yet >.<

Ever since 4k came around h265 is basically the standard. Imo this feature should have been very high priority 3 years ago.

[Deathsquirrel 744]

I agree.

I and assumably many others here were under the impression, that this feature was actively worked on. It wasn't even looked at yet >.<

Ever since 4k came around h265 is basically the standard. Imo this feature should have been very high priority 3 years ago.

 

No one reading this thread should have come to that conclusion.  Most of the posts from the team focused on the reasons not to do this from the server strain to lack of native client support.  I don't have an opinion on the FR really, but they've been pretty clear IMO.

[wiwolavida 4]

I'm planning to look at this for the download/sync/convert features after the upcoming 4.1 release. 

 

We're working as hard and as fast as we can to bring you the features you want as soon as possible. Thanks.

 

Latest stable is 4.2.1.0

It's not quite clear, but I assumed work on the FR had started :/

[Happy2Play 9388]

Not yet.  To me this will add so many more troubleshooting topics.  

 

I can see it now.  "Your system is not powerful enough for this operation".

[wiwolavida 4]

I can see it now.  "Your system is not powerful enough for this operation".

 

Is that a problem? Emby doesn't complain when it's tasked to transcode a 4k hevc file to h264 with a gt720. That gpu is clearly not powerful enough xD

 

I mean why worry about that, if the same thing happens with h264 transcoding?

[Happy2Play 9388]

Is that a problem? Emby doesn't complain when it's tasked to transcode a 4k hevc file to h264 with a gt720. That gpu is clearly not powerful enough xD

 

I mean why worry about that, if the same thing happens with h264 transcoding?

 

No just the users they don't understand the required resources for the operation.  So they will see the option and expect it to work.  But in reality it will/may work at 0.001% and complain they can't uses their system and it is taking forever.  But hey we will just say post your logs and oh your system is not powerful enough for this operation.   

 

Sure the h265 codec has been out for awhile but there are still a lot of questions out there on whether it will be the standard.

[wiwolavida 4]

That's true. For the mean time you could limit h265 transcode to hardware accelerated hardware. That way people can't even try to do that on cpu's.

[otispresley 104]

It should probably be developed in such a way that Emby can decide whether to transcode in H.264 or H.265 based on the system resources available to it.

[speechles 2004]

It should probably be developed in such a way that Emby can decide whether to transcode in H.264 or H.265 based on the system resources available to it.

 

It would need a test sample to encode say you download from Emby website. In that way it is a standard video file that everyone encodes. It takes too long to encode at real time it disregards H.265 as viable for encoding on-the-fly. That would be possible. The same way the app checks for bitrate and downloads some bits. Have the H.265 encoding test download a file. Then encode it and see what the frames-per-second is on that encode. Pass the test (fast enough fps during h265 encode) and the h265 encoder becomes available for on-the-fly transcoding. Fail the test and it stays off. 

 

The only variable is.. multiple encodes.. as in h265 that will drag a server to its knees. We could conversely use vp9 to encode with. Why isn't vp9 being discussed as an alternative to h265?

[ebr 15604]

 

H265 instead of H264 in the Transcode option.

It will be smaller for all bad bandwidth (2

 

 

Hi.  If you read this discussion, you will understand why it isn't quite that simple.

 

We will be implementing this but it has to be done very carefully to avoid a huge support nightmare for us.  You guys may think that it is just the user's problem if they enable something like this and it doesn't work but that isn't the case.  It becomes our problem and we end up spending time troubleshooting and explaining it and all of that takes away time for things like actually developing these types of features.

[speechles 2004]

Vp9 vs h265

 

A subset of the organizations that have declared to hold HEVC essential patents. Conversely, the VP9 standard is an open source, royalty free format that was developed by Google. Google originally developed VP9 mainly for YouTube content. In fact if you want to utilize YouTube in 4K, you have no choice but to use VP9.

 

 

Also web browsers support vp9. I know the Roku does. Android does. Does Apple TV? VP9 support would seem better suited to compatibility.

[nayr 36]

What HW Encoders support VP9? Cuz my Quadro P2000 does not.. without HW acceleration, you can forget about transcoding anything 4k.. it'll bring my 24 core threadripper to its knees using just software.

Edited August 22, 2019 by nayr

[KarlDag 25]

 

Vp9 vs h265

 

A subset of the organizations that have declared to hold HEVC essential patents. Conversely, the VP9 standard is an open source, royalty free format that was developed by Google. Google originally developed VP9 mainly for YouTube content. In fact if you want to utilize YouTube in 4K, you have no choice but to use VP9.

 

 

Also web browsers support vp9. I know the Roku does. Android does. Does Apple TV? VP9 support would seem better suited to compatibility.

APPLE TV does not, ofdicially. Potentially a software decoder in the client app might be able to do it.

[speechles 2004]

What HW Encoders support VP9? Cuz my Quadro P2000 does not.. without HW acceleration, you can forget about transcoding anything 4k.. it'll bring my 24 core threadripper to its knees using just software.

 

yeah HEVC is faster to adopt because at first it had the competitive edge. Now that they are pretty much even playfield it is customers that push for VP9 support. Roku has it because YouTube must exist on Roku and those videos are 4K VP9 on there. Same reason Android has it YouTube 4K VP9 has to work there. That is why I was unsure if Apple had it. That is why YouTube videos play so poorly for Apple devices in 4K when they lack that codec. That must be the reason for the slow VP9 adoption is content.

[nayr 36]

until hardware encoding and decoding become more widespread for VP9, then HEVC still has the edge... 

 

I think the big argument for HEVC output from Emby right now is that with proper hardware, people would still be hitting upload limitations far before they exhaust resources.. with a few hundred dollars in hardware you can encode HEVC in realtime at bitrates that exceed even a large residential upload speed.. along with widespread HEVC client support on market (Fire4k, Roku4k, AppleTV4k, Shield/MiBox/etc) all the pieces are already in place as far as hardware is concerned.. just need Emby to get embrace it already since there is almost nothing any of us can do to get better upload performance and it would relieve alot of bandwidth pressure server admins are contending with, along with data caps users have to contend with.

 

VP9 on the other hand, is still trying to get widespread hardware decoding support and has yet to make really any presence on the encoding side, so until that happens the resource requirements needed to support VP9 put it out of the reach of pretty much the entire user base, without a whole lot of obvious advantage to HEVC.

 

I'm all for abstracting output formats to take advantage of multiple possible codecs depending on the circumstances, I think the work done to support HEVC should be implemented in such a way that supporting whatever's new down the line will be easier and happen faster.. so things like 4k through the browser can come sooner than later, but right now I dont see any gains to be had by implementing VP9 output as it stands currently.

 

I understand why some in this thread are getting agitated by the lack of response on this issue, my parents just cut the cable.. and not 75% through the month they used over 80% of their datacap, looks like its gonna cost them $50/mo extra.. even though I have HEVC encoding hardware and they have HEVC decoding hardware, we are unable to take advantage of it.

Edited August 23, 2019 by nayr