Transcode in H265

[softworkz 3335]

@cayars - very good and comprehensive explanation.

I want to add one more point that is very important: Expectations

Why do users think that they would need H265 so badly? Because they have heard that H265 provides the same quality at half of the bitrate.

They do not know or understand that this is just the maximum edge what is achievable when throwing in all possible codec features and computing resources.
Even content providers who do pre-encoding and have those resources available and no latency requirements for the process are not able to achieve that double/half target.
This is for multiple reasons: for example when streaming (no matter whether pre-transcoded or live-transcoding) you need to maintain a certain frequency of key frames (which take much more bandwidth than all the frames in-between). For HLS streaming, each segment needs to start with a key frame and segment length is typically 3s (sometimes more, Emby uses 3). Those double/half demos are using very sparse keyframes only, but that's not suitable for streaming. 

Then there are client limitations with regards to how many reference frames (frames between key-frames which need to be kept in order to decode other frames) a client device can store. This doesn't matter much for computers, but for integrated devices (like TVs), it's a different story. A content provider obviously wants to make sure that the content can play on a wide range of devices, so it's not possible to go to the limits in this regard. But only at those limits, one could approach that double/half advantage.

Then there are some codec features that have been tweaked for those double/half demos, but which can't be applied to all content equally and in general, so these won't be used in practical scenarios.

What finally gets into play is the fact that with Emby, we are performing "live-transcoding", we do not pre-encode like content providers do. That fact imposes additional restriction with regards to how much we would be able to leverage the H265 advantages in practical cases.

 

The points above are not even comprehensive but suffice to illustrate that the advantage that users are expecting or hoping for are not achievable at all.
With each of the bullet points above, you are getting another step away from that double/half promise.

At the end - there will surely remain an improvement over H264 - but it's a much smaller gain and far off from what people are thinking they would get.

Edited October 27, 2022 by softworkz

[Carlo 4330]

Yes, for bandwidth savings.  This comes into play a few different ways.  One is on the server side. Many ISPs still only give you 5 or 10Mb upload even with 1Gb download speed.  That's barely enough bandwidth to handle the ACK, NACK response to other communication on the network if downloading or streaming.  A person with 10Mb up might only have 5 or 6 that's usable for streaming.  Maximizing that little bit of bandwidth helps to get one good stream remotely.

Data Caps.  Many ISPs have 1 TB limits on home Internet use so any saving in bandwidth helps saving on overcharges which typically run $10 for 50GB blocks. Mobile networks are even worse with basic plans that make you pay for all data used. Even many of the "unlimited" plans have terms like this:

Get 50 GB of 5G Nationwide / 4G LTE premium data per month. You’ll also get high-definition 720p video streaming on 5G Nationwide / 4G LTE when you activate it in your plan settings.
In times of congestion, your smartphone and mobile hotspot data may be temporarily slower than other traffic after exceeding 50 GB/mo/line of 5G Nationwide / 4G LTE data.

They may not get charged extra but get more limited data service after passing some threshold. Any saving that could be had by Emby allowing h.265 would help here as well as it might allow streaming to still happen when you get downgraded.

From pretty extensive testing for Netflix in fact the average savings were 38% based on 10Mb and lower streams.  This gets much better ratio wise with 4K where h.265 really comes into its own compared to h.264 even surpassing 50% savings. The higher the resolution and bandwidth of the original the higher the percent of saving you will see. At 3Mb or 5Mb streams you likely find little saving if keeping quality, the same. H.265 was never designed for those types of streams so it's not surprising that would be the case.

For people in this situation a forced transcode to H.265 (even H.264) across the board, by user or by device (with specific res/bandwidth limits) would be quite helpful as that would reduce the size of many existing files as well as live streamed TV, especially mpeg2 broadcasts.

That's the general thinking from users I believe.

[softworkz 3335]

7 minutes ago, cayars said:

From pretty extensive testing for Netflix in fact the average savings were 38% based on 10Mb and lower streams.

This is pre-transcoding, though - not live transcoding.

8 minutes ago, cayars said:

At 3Mb or 5Mb streams you likely find little saving

Yes exactly. And these are the cases you are talking about:

10 minutes ago, cayars said:

A person with 10Mb up might only have 5 or 6 that's usable for streaming

There's not much improvement possible at all.

[hapylestat 3]

I'm not sure if it was discussed here already, but i guess the proper feature would be not live-encode to x265 (coz in 2 years users would like to see av1, pretty sure)...but to allow emby to:

- pre-encode videos to selected by user format(s), there could be several

- allow user to select preferred format, select space - where to store pre-encoded files

- if the video or show have pre-encoded alternative and it matches with user preferred format selection - play it directly to client instead

 

It could be some mix of "Direct Play" & "Encode for Download" features.

 

How it sounds?

[nayr 36]

1 minute ago, hapylestat said:

I'm not sure if it was discussed here already, but i guess the proper feature would be not live-encode to x265 (coz in 2 years users would like to see av1, pretty sure)...but to allow emby to:

- pre-encode videos to selected by user format(s), there could be several

- allow user to select preferred format, select space - where to store pre-encoded files

- if the video or show have pre-encoded alternative and it matches with user preferred format selection - play it directly to client instead

 

It could be some mix of "Direct Play" & "Encode for Download" features.

 

How it sounds?

thats been implemented for eons now.. 

[hapylestat 3]

11 minutes ago, nayr said:

thats been implemented for eons now.. 

Like where?  I able to see only transcoding for real time and conversion for downloads. Not even a sight for pre-encoding, selecting codec, storing it on server and stream it to client instead of real-time conversion

[softworkz 3335]

I know that some will be saying "Okay, the improvement might be a bit smaller - but give it to us anyway!" (or similar)

And there's the second big mis-assumption: That we would just need to "switch it on" with with a tiny bit of development and that it would work in the same way as H.264 then. And some bad voices would add that we would be ignorant towards user requests and instead of fulfilling, we would just be trying to find excuses.

So I'll try to explain the situation once again (I did before, also in this topic somewhere above) - this time letting any technical details aside, just focusing on how this would proceed - roughly:

• Within 1-3 days we could have an example case working: with a specific source file, a specific hardware, specific hwa, a specific transcoding configuration, and a specific client  and client settings
• After a few weeks, we might have this working in like 15-30% of cases
• After several months, we could have approached 40-50%
• And after a year maybe 60 or 70%
• The point is: the closer it gets to 100%, the harder and slower will it become to approach it

It is important to understand in this context, that 80% or 90% still means that it cannot be shipped/released. Nobody will accept a situation where playback fails in one out of five cases. It has taken years to get to the point where we are now, where Emby can play whatever you feed it on whatever device in something like between 99.9 and 99.99% percent of cases. A huge amount of experience has gone into all the detail behavioral patterns in all the different apps. Getting to the same point with H.265 would take less time, but much more than a year for sure, I'd estimate something around 2 years of intensive work on all sides: the server and all client apps. Development of other things would be slowed down and even worse: Emby users would have to suffer from decreased user experience and complain that Emby is no more like it was before (no you can't make it just optional because at some point you need the masses using it to get it free from errors - would it be optional, then it wouldn't be worth to take the effort for those few who are using it).

Finally, there's one more question to ask which is probably even more important than anything above:

Is this the future we would put all that effort into?

At the moment, it doesn't seem so. HLS is widely adopted, but Apple also created a big mess by changing the container format for HEVC. This has led to confusion, each implementation supports something different, some do MPEGTS as well but others only fmp4.
That's why we are not only talking about a codec change - it's about the streaming protocol and procedures as a whole and opposed to H264 streaming over HLS, the reality is very divergent with HEVC, which means even more edge cases, spec islands and uncertainty.
It's just the opposite of a bright future in which you would want to invest and put all your effort into.

That's the situation how I see it at the moment.

Edited October 27, 2022 by softworkz

[nayr 36]

30 minutes ago, hapylestat said:

Like where?  I able to see only transcoding for real time and conversion for downloads. Not even a sight for pre-encoding, selecting codec, storing it on server and stream it to client instead of real-time conversion

Conversions are not for just downloading, it pre-encodes it into different formats/resolutions at the codec of your choice for streaming it to the client instead of real time conversion.. you actually tried using it? 

 

Clearly Emby can Encode files in HEVC, my portable server is nothing but HEVC Conversions from my Main Emby server because it had such limited solid state storage space being portable... then it auto syncs from the main server to the portable one for viewing on the kiddos headrest TV screens on the road.. Even the cheap Aliexpress Headrest monitors play back the HEVC files Emby its self encoded just fine and dandy w/Hardware Decoders.

Edited October 27, 2022 by nayr

[SLMK 13]

10 hours ago, softworkz said:

At the end - there will surely remain an improvement over H264 - but it's a much smaller gain and far off from what people are thinking they would get.

Thanks for the detailed responses.

I definitely see very impressive gains in my own x265 encodes, but these are slow 2 pass encodes at far less than realtime.

If the low bitrate improvements for realtime hardware transcoding are as poor as you indicate I can definitely appreciate why it isn't worth the dev time.

[hapylestat 3]

hm, i'm on 4.8.0.15 and i cant see the dialog box above ......

where it could be located? 

Edited October 28, 2022 by hapylestat

[Happy2Play 8279]

@hapylestat You do it from Library card or per item and select Convert.

[hapylestat 3]

thanks, found it!   

Would be nice to have in admin panel on conversion page some hint about it or redirect to help page.   Actually i used it before for some time (as preparation for travel, when moved stuff to tab)...but after time passed completely forgot it.   Moreover, the current hint is kinda misleading (check the screenshots in previous post). 

[syadnom 24]

I'm using quicksync and NVENC and have a script to detect the available encoder.  I'm getting very similar looking results on HLS encodes on NVENC at about 60% and quicksync at 50-55%.  This is a single pass. x265 looks noticably better at 50% bitrate but it doesn't improve at less so that 50% number seems to be the wall.    This is not a small gain and this is for live video ie single pass.  I do 10 second chunks to get these results, 3 second chunks need about 10% more bitrate.

I pull 4k videos off sports cams at highschool football and basketball games (RTSP h.264 source) and encode them into HLS live with a 1080p and a 720p tier.  The i5/quicksync box can do 5 h.265 1080p encodes so handling one camera with dual encodes is easy.  I have multiple cameras at another site with multiple cameras and the i5/quicksync couldn't get the 6th encode down properly so had to move to a 3050 which handles 3 cams just fine. 

These are published to a website with resiliosync and cached with cloudflare and I have a simple android player that can be side loaded on google tv or fire tv sticks and I have a landing page that works in unmodified chrome so parents and families can watch the games.  A student at one of the schools took the android player example from the android SDK and modified it to show the HLS pages for the games and share a file for sideloading.

I'm running this in production.  We have plenty of horsepower available and great support in ffmpeg to encode on a 7 generation old CPU.  Player support is absolutely steller these days.  Every single player available on the market right now support h.265.  every one.  browsers so, mobile devices do, there is no issue with playback and no issue with encoding performance on most common hardware.  Heck, you can get 2 h.265 encodes out of an atom CPU that's a few generations old even.

Emby already plays h.265.   

A dev coming in here and saying all these impossibilities is rediculous.  I don't use Emby these days because of this and it looks like I might as well just give up on the project entirely if it's going to make excuses that are plain false and live in the past.

[japtain_cack 6]

On 10/23/2022 at 10:03 AM, visproduction said:

Is everyone aware that native browser support for h.265 or AV1 is pretty limited.  It's nice that you guys set up your systems to playback h.265 in a browser with some plug-in or hardware or mobile app and it works fine.   But 99% of the desktop user use a browser, where playback  does not work.  Have a look here for the green blocks on browsers that h.265 or Av1 can playback today.

https://caniuse.com/hevc
https://caniuse.com/?search=AV1

The question is why develop code that helps possibly less than 1% of desktop users.  What is the percentage of users on mobile where h.265 does work?  I think it makes more sense to wait until most browsers roll our updates to give playback for h.265 or AV1.  By that time, perhaps things will change and any code update you spend time on now, would also have to change again.

I don't do the code dev on this, but I would guess at AV1 and h.265 feature, setup, UI options, QA testing, UX design and bug fixing could total perhaps  200 employee / volunteer hours.  That's if you are lucky.  It's probable that you would have to come back every year to check that all the browser continue to work correctly with all new browser updates and also check any bug reports.

I would like to respectfully disagree. Most users aren't using browsers. They're using mobile devices and apple/fire/android/roku TV apps. Most of these devices, if not all, can natively decode HEVC. My 5 year old Samsung TV can do it. I have jellyfin as evidence this is in fact possible and free.

My setup for playback isn't that amazing, it's my "server" that has the capability/power to transcode in HEVC, and in fact I'm already doing this via Jellyfin/ffmpeg. My users devices consist of a Dell XPS 3-in-1, numerous firetvs, Apple devices, and native smart TV apps. Everyone that I know that runs media servers have similar user bases.

I've recently moved to jellyfin, until this issue is resolved. I don't have fiber and I have to care about my bandwidth, but want to look at something other than pixels at low bitrates. 

[hapylestat 3]

On 10/23/2022 at 7:03 PM, visproduction said:

Is everyone aware that native browser support for h.265 or AV1 is pretty limited.  It's nice that you guys set up your systems to playback h.265 in a browser with some plug-in or hardware or mobile app and it works fine.   But 99% of the desktop user use a browser, where playback  does not work.  Have a look here for the green blocks on browsers that h.265 or Av1 can playback today.

https://caniuse.com/hevc
https://caniuse.com/?search=AV1

The question is why develop code that helps possibly less than 1% of desktop users.  What is the percentage of users on mobile where h.265 does work?  I think it makes more sense to wait until most browsers roll our updates to give playback for h.265 or AV1.  By that time, perhaps things will change and any code update you spend time on now, would also have to change again.

I don't do the code dev on this, but I would guess at AV1 and h.265 feature, setup, UI options, QA testing, UX design and bug fixing could total perhaps  200 employee / volunteer hours.  That's if you are lucky.  It's probable that you would have to come back every year to check that all the browser continue to work correctly with all new browser updates and also check any bug reports.

its a total BS, tell it to Google Youtube - who is moving to AV1, and to various streaming services like HULU , Netflix, etc.- who  currently working on implementation due to same reasons mentioned in the topic.    If pair it with cheap Intel GPU's for encoding acceleration- it's ideal combination for the media server.   

And take it as granted - There's only 2 major browsers in the wield: Safari and Chromium-based, supported by Google. I'm sure, we would have no problems with implemented by same vendor AV1 codec.

 

  Just Google "Global Desktop Browser Market Share for 2022" and stop wasting time on caniuse.

 

[Carlo 4330]

12 hours ago, syadnom said:

I'm using quicksync and NVENC and have a script to detect the available encoder.  I'm getting very similar looking results on HLS encodes on NVENC at about 60% and quicksync at 50-55%.  This is a single pass. x265 looks noticably better at 50% bitrate but it doesn't improve at less so that 50% number seems to be the wall.    This is not a small gain and this is for live video ie single pass.  I do 10 second chunks to get these results, 3 second chunks need about 10% more bitrate.

I pull 4k videos off sports cams at highschool football and basketball games (RTSP h.264 source) and encode them into HLS live with a 1080p and a 720p tier.  The i5/quicksync box can do 5 h.265 1080p encodes so handling one camera with dual encodes is easy.  I have multiple cameras at another site with multiple cameras and the i5/quicksync couldn't get the 6th encode down properly so had to move to a 3050 which handles 3 cams just fine. 

These are published to a website with resiliosync and cached with cloudflare and I have a simple android player that can be side loaded on google tv or fire tv sticks and I have a landing page that works in unmodified chrome so parents and families can watch the games.  A student at one of the schools took the android player example from the android SDK and modified it to show the HLS pages for the games and share a file for sideloading.

I'm running this in production.  We have plenty of horsepower available and great support in ffmpeg to encode on a 7 generation old CPU.  Player support is absolutely steller these days.  Every single player available on the market right now support h.265.  every one.  browsers so, mobile devices do, there is no issue with playback and no issue with encoding performance on most common hardware.  Heck, you can get 2 h.265 encodes out of an atom CPU that's a few generations old even.

Emby already plays h.265.   

A dev coming in here and saying all these impossibilities is rediculous.  I don't use Emby these days because of this and it looks like I might as well just give up on the project entirely if it's going to make excuses that are plain false and live in the past.

But this isn't real-time streaming and more like the pipeline Netflix uses by your description. You essential are doing VOD not real-time streaming. You just happen to do this using a method that is one-pass in real-time from your perspective. But from an end-user standpoint this is more like VOD since what they are playing back is pre-prepared, not processed in real-time.

1. Your preparing the media before it's used (same as Netflix) so it can stream without needing real-time transcoding.
2. Your pushing it out to a CDN removing your upload link and it's latency from the playback and pushing the content closer to the user (same as Netflix).

There of course is something to be learned from this but this is more like real-time recording then real-time streaming.  Meaning when the client plays these videos back you have already removed the latency involved in the recording, the communication with the client asking for the bitrate needed, transcoding and sending it through your ISP.

Now think about a real-time broadcast in terms of Emby which would be Live TV. The client picks a channel to watch. The Emby client requests the channel from the server, server checks to see if there is already a stream available that can be shared if not it requests the channel from the tuner. It then has to waits until the tuner starts returning data. The server then sets this up so it can be shared which is similar to starting a recording. It then does an analysis of the stream to see what codecs are being used, what the container is what the bitrates are then uses information queried from the client to check is capabilities, determines if it can try a direct stream, needs to repackage the stream or transcode it for the client.

Emby actually has a few more decisions to make that you didn't have to since a typical Live-TV stream will have multiple audio track and will have Closed Captions or Subtitles that both the client and server need to agree on use which requires more communication back and forth and of course is more latency that's required before a stream can start to be processed.

Up until this point no actual streaming of data has been attempted yet but you can see there will be quite a bit of latency already involved.  None of this latency is present in your use of the camera streams you're comparing to.

Emby Server can start processing the stream for the client, so let's assume we are now taking the mpeg2 stream that it received from the tuner and sends it to the GPU (QuickSync or Nvidia most likely) transcodes it to x-second chunks, writes the m3u files for the HLS package and sends this to the client. The client responds with the stream it chooses from the client with the time range to play and sends this back to the server.  The server then sends starts sending this data to the client while continuing to process the stream. The data is sent out the network card, passed to your ISP, likely from your ISP to a backbone on it's way to the client.

It's at this point that your Emby Server has caught up to your example where the data is already present for streaming at a CDN. There is 0 latency in your example starting to stream from the CDN but how much latency is already present for the Emby Server stream? Quite a bit! I'm sure you're looking at 2,000 to 4,000 ms latency with a fast system and likely more on a slow system. Much of this is just one-time startup of a channel but will happen on every channel change so obviously lower is better.

The client is going to need to receive X packets or y seconds at z bitrate so x*y*z will be how much data needs to be received before the client can show its first frame. In your example you can probably get by with 3 segments of 6 seconds at 8Mb so 144Mb or 18 MB of data. Emby Server will be similar of course by due to the high latency already present tries to "cheat" by using 3 second segments which allows for quicker startup and quicker adjustment/reaction to client requests but has a downside of needing to process twice as much communication protocol overhead which also requires a bit of bandwidth. How long it takes to transmit (the example) 18 MB will be determined by the client side only with your CDN in place will be about 1/2 a second with a typical 300Mb Internet plan, while the Emby Server will have to push the data over the full Internet using your upload bandwidth. If you have the needed bandwidth not being used it will transfer at roughly the same 1/2 second plus amount of time from your server to a backbone (approximates CDN) but if you only had 100Mb upload speed available at the time the 18 MB of startup data is going to take 1.5 seconds to transmit before the client has enough data to display it's first frame.

So startup of stream playing for Emby is going to be much higher then having your data already processed sitting in a CDN.  What about ongoing stream playing?

Having your data sitting in the CDN is always going to be faster as it doesn't need to be transcoded and only has to travel 1/2 (or less) as far to the client.  If a user does a pause, rewind, fast forward this information is already available in the CDN as you have already prepared manifest files available.  On the other hand with true real-time processing the Emby Server would have to resend packets it already has prepared or if already deleted due to space demands would need to reprocess those packets through the transcoder again.

To me, what I would like to see to better understand the pros/cons is back to processing of a few different types of movies such as cartoon, drama and action picture using both AVC and HEVC transcoding hitting a specific bitrate.  For example, if output was using AVC, a 20Mb 1080p source to 1080p 8Mb and then to 720p 4Mb.  Then also same type of test using Live-TV with a mpeg2 OTA broadcast as well as 1080p AVC encode of a prime tuner. 

But then you should be able to reduce the bitrate of the output 1080p 8Mb file since HEVC can hold the quality using less bits.  So you test and adjust the HEVC until you arrive at a bitrate that gives you the same quality as the AVC 1080p version.  This could be in the 3 to 5 Mb range.  This to me is key to testing to see how much actual bandwidth can be saved while holding quality the same.

You also record the difference in latency.  For example, how many milliseconds does it take to get 3 chunks needed for streaming. This is recording the time it takes from feeding the GPU the first bit of data until you get out the first 3 chunks of data needed for the client.  Is there a difference at all processing real-time between AVC and HEVC? Is there a resource difference (ie how many simultaneous streams) can be processed be processed this way using AVC vs HEVC?

With the above tests done on a range of CPUs, some true analysis could be done to see real life impact. This could potentially show the transcode latency is 15-20% higher but reduces bandwidth by 30% which takes less time to transfer thus reducing overall latency. It could show Quicksync taking a latency hit on older CPUs while newest -7 with better quality output allows reduction in bitrate and saves latency and bandwidth.  Same might be true for Nvidia where older Pascal and Maxwell cards take longer to process as well as need more bit to hold quality while modern Turing cards process AVC and HEVC at the same speed but allow HEVC to get away with far less bits needed for HEVC compared to AVC holding quality which is a win win.  Obviously type of movie will make a difference as a cartoon will require far less bitrate than an action paced movie, so you see more the extremes of processing while the drama gives you a good all-around average.

Carlo

 

[softworkz 3335]

Readers should notice that I'm the only one here who never mentioned any percentages (with regards to quality/bitrate improvements from HEVC).

So - it's a bit funny to see how some are trying to disagree with my statements, throwing in some numbers based on specific cases and based on their own subjective judgement of "same quality", even though I never mentioned any figures at all...

Carlo has made some very important points: the bandwidth savings depend on many different factors and it's impossible to make any generalized statements on this. 
That means, when somebody tries to make such general claims, without differentiation, it's likely to be a little bit off the truth. 
Eventually, there's also the "same quality" claim. There are industry standard procedures and tools to measure perceptive quality differences. Any claims that are not accompanied with appropriate comparisons of measured quality, cannot be taken seriously, I'm afraid.

Also do not forget that I never said that HEVC doesn't provide any improvements. I think I've been pretty clear about that. I just said that it's not as dramatic as expected due to the given constraints within Emby needs to operate.

[syadnom 24]

There's a lot of apples to oranges comparisons here that don't make sense.  If we're comparing a 'live' stream, ie on-the-fly encoding, then we do that for both h.264 and h.265 (and AV1 if time persists...).   We're not comparing 2 pass pre-encoded streams to an Emby live stream.  

So a live h.264 vs a live h.265 is actually a bigger improvement that many are suggesting here.  h.265 reacts better to encoding to a quality metric than h.264. 

'same quality' is subjective.  You can use MOS scores by consuming the content but IMO, that's not a clear indicator either.  It's easy to refer off to major players who have spent the money to do market research though.  

should also be noted that most modern security cameras are doing on the fly h.265 encoding and with hardware encoding very similar to quicksync or nvenc.    It's a good test case for quality vs bitrate if you force some settings (fixed GOP and key frames etc)
 

[sydlexius 241]

14 minutes ago, softworkz said:

Readers should notice that I'm the only one here who never mentioned any percentages (with regards to quality/bitrate improvements from HEVC).

So - it's a bit funny to see how some are trying to disagree with my statements, throwing in some numbers based on specific cases and based on their own subjective judgement of "same quality", even though I never mentioned any figures at all...

Carlo has made some very important points: the bandwidth savings depend on many different factors and it's impossible to make any generalized statements on this. 
That means, when somebody tries to make such general claims, without differentiation, it's likely to be a little bit off the truth. 
Eventually, there's also the "same quality" claim. There are industry standard procedures and tools to measure perceptive quality differences. Any claims that are not accompanied with appropriate comparisons of measured quality, cannot be taken seriously, I'm afraid.

Also do not forget that I never said that HEVC doesn't provide any improvements. I think I've been pretty clear about that. I just said that it's not as dramatic as expected due to the given constraints within Emby needs to operate.

A generalization that can be safely made is that most anything that wasn't encoded from a very high quality source (ie: transcoding from one compressed CODEC to another) is going to suffer on these automated perceptual quality tests.  In cases where people are just trying to minimize bandwidth being consumed on their non-unlimited data plans, this might be an acceptable trade-off.  This is yet another advantage that content providers will have over home gamers like us--access to high quality sources, and more tightly compressed content that has an acceptable PQ rating...they can orchestrate tons of parallel encodes to eke out the best possible storage/data egress scenarios.

[syadnom 24]

17 minutes ago, sydlexius said:

A generalization that can be safely made is that most anything that wasn't encoded from a very high quality source (ie: transcoding from one compressed CODEC to another) is going to suffer on these automated perceptual quality tests.  In cases where people are just trying to minimize bandwidth being consumed on their non-unlimited data plans, this might be an acceptable trade-off.  This is yet another advantage that content providers will have over home gamers like us--access to high quality sources, and more tightly compressed content that has an acceptable PQ rating...they can orchestrate tons of parallel encodes to eke out the best possible storage/data egress scenarios.

A lot of people use Emby, Plex, etc to hold their blueray libraries and then way to transcode them out for remote/mobile use.  So the implication is that it actually is a high quality source.  Also note that modern hardware can encode and decode this content pretty easily.

[sydlexius 241]

6 minutes ago, syadnom said:

A lot of people use Emby, Plex, etc to hold their blueray libraries and then way to transcode them out for remote/mobile use.  So the implication is that it actually is a high quality source.  Also note that modern hardware can encode and decode this content pretty easily.

By high quality, I'm referring to bitrates that are orders of magnitude greater than what can be found on (Ultra) Blu-ray media.  Yes, are really good source materials for home users to start with...but I'd love to get my paws on the distribution sources so I can encode them to my own ends (some of the "scene" guys do have access to some of these feeds/sources).

[softworkz 3335]

 

21 minutes ago, sydlexius said:

A generalization that can be safely made is that most anything that wasn't encoded from a very high quality source (ie: transcoding from one compressed CODEC to another) is going to suffer on these automated perceptual quality tests.

I was just going to reply the same:

2 minutes ago, syadnom said:

A lot of people use Emby, Plex, etc to hold their blueray libraries and then way to transcode them out for remote/mobile use.  So the implication is that it actually is a high quality source.

Also, when you want to compare H265/H265 quality when encoding 4k to 1080, it becomes even more "high quality" due to the scale-down. Then you can compare the uncompressed scaled-down video as reference with the H264 and H265 output to assess quality of the latter two and when you have both at the same quality - then you can look at the bitrate advantage that HEVC provides. That would be solid figures.

[japtain_cack 6]

I would also like to point out something quite obvious, that many people seem to overlook. Emby/Plex/Jellyfin have one function that sets them apart from other apps like Kodi. Real time transcoding/streaming. This is essentially the only thing that makes them unique.

If I wanted to re-encode multiple versions of the same file, not only am I not benefiting from the space savings of HEVC/AV1, but I'm essentially removing the need for real time transcoding, so why do I even need emby at that point? I could just use Kodi. Kodi supports all these codecs, organizes my library, plays pretty much any media, and looks great. 

The entire reason people use emby, or the like, is for real time transcoding. So, imho, if transcoding is your niche, you should do it well, and try to be the best at it. Whoever does it best, emby vs jellyfin vs plex, is the one that will dominate the market.

I don't pay for mainstream streaming services, but instead pay/donate monthly to jellyfin, since they are the clear winner when it comes to transcoding. If emby wants to start doing it better, I may change my mind.

I highly encourage everyone to donate to the free/OSS software they consume, if possible.

[japtain_cack 6]

I also dislike HEVC quite a bit. Not because it's a terrible technology, but because you aren't allowed to distribute the binaries without paying royalties. The solution to this, is to let your users to install/compile ffmpeg with the necessary codecs themselves. The source code is open source and is actually free to use if you don't distribute the binaries. Jellyfin does this, you have to provide the path to ffmpeg as part of the configuration.

However the fact that media companies, application developers, and hardware vendors chose HEVC instead of truely free alternatives, is asinine to say the least. This is a problem of their making and its the customers that suffer. 

Edited October 28, 2022 by japtain_cack

[softworkz 3335]

1 hour ago, japtain_cack said:

but instead pay/donate monthly to jellyfin, since they are the clear winner when it comes to transcoding

LOL. Their ffmpeg customization code is copied from Emby's and Plex' ffmpeg