Adding support for AMD Hardware encoding #697
Comments
|
Hello While I personally cannot answer those questions, I'll just say that I'm happy for your eagerness and appreciate it, I hope you succeed in your cause. Infact this niche* is in so much of need of HW support. However I have a few questions myself to clear something out, if possible:
|
It really depends on the GPU in the System. AMDs HW isn't exactly standardized when it comes to VCE since it is technology that was first introduced in TeraScale (remember ATI?) cards and has just been slightly updated since then. An RX 480 (Polaris) can real-time encode 4k at 35 FPS, a R9 285 (Tonga) can encode 4k at 83 FPS. I've listed all the possible real time encoding frame rates here with the help of users:
AMD AMF can take over conversion from different color formats, resizing, encoding, decoding and probably more I don't remember at the moment.
H264/AVC, H264/SVC are supported by TeraScale, GCN1, GCN2, GCN3 and GCN4. H265/HEVC is supported by GCN4. There is supposedly support for VP9 decoding on GCN4, but accessing it has been difficult.
This replaces the CPU encoding completely. It is a hardware encoder after all. The quality of the encode largely depends on user settings (default hovers between x264 superfast and x264 veryfast) but users of the plugin have discovered ways to push it to quality levels of x264 fast and higher. |
|
Understood, so it depends on VCE version. Wow, the speeds that you have presented that would be achievable ... I kinda don't want to celebrate too early just in case, and rather leave room for others to comment on that. Personally I woudln't mind about no VP9 support (it's more meant for streaming and some people say it's missing some stuff older codecs had) for the past few months I used to do 1080p into H265 and it goes around 20 FPS under my quality settings with a Core i7 3820 at 4.0 GHz (turbo) I have an RX480 ... and it's sitting there doing nothing in this case. Unfotunately, I cannot say anything definitely, I'm just an observer around here, I now recall and think that Handbrake is actually only a GUI ontop of other open-source underlying projects, encoders, decoders and etc. I think it may be called "libav.."something"". I hope that wouldn't mean some big setback for this cause, or your further interest. Fingers crossed.
|
We use really good tape. But seriously, there's a lot more to it than that. HandBrake has a lot going on under the hood. |
|
@Xaymar Thanks very much for your consideration. It's important to the project that people don't simply drop code and drop out (see: our OpenCL implementation). If you're willing to support your contributions with bug fixes and other considerations down the line, this should be a nice addition. I'll let the other developers chime in with specifics. |
A CPU will most likely bottle-neck any dedicated HW on the GPU, most of the time it already does in the plugin for OBS Studio. I implemented OpenCL Transfer (OpenCL DMA frame copy) to reduce and stabilise latency issues on CPU->GPU transfers as otherwise 4k real time encoding is next to impossible. This is obviously different per CPU, but so far no Intel CPU and no AMD CPU on Bulldozer or earlier has managed this. Ryzen seems to be completely unfazed by the amount of data that needs to be pushed to the GPU, which is why Host transfer on Ryzen works better than OpenCL transfer.
The plan is to use either the same or a similar backend to the one I use in the obs-studio plugin, so that fixes for bugs appear in both at the same time. The 2.0.0 backend has received a big makeover that makes supporting it much easier as it uses an inheritance model instead of duplicating logic. There's still places to make it better, but this is at least a pretty good start to work off of. Doubt there's any reason for me to do this hit & run style, it actively benefits me too.
I'll be waiting then. |
|
I was praying to be wrong but I honestly didn't expect it. Obviosuly I'm happy now, but at that moment, I felt like I should crawl into a corner and shut up. lol. Allright, so I shouldn't expect a general purpose CPU to be able to help anything, in this case it's all good, we would actually be able to freely do other things while it's encoding in background (web, desktop misc, etc) as it's taking the weight off the CPU. 2 flies with 1 stone. This brings me to another thing, not that I'm so hungry and I wouldn't be satisfied with just this, but what about combining GPUs together, including the integrated ones on APUs, or I'm just mixing that with DirectX12 and such capability is not possible in AMF ? Sorry that I keep asking things that may be obvious to actual developers, it may however clear things out for a better overview for other readers as well. |
If you want to write a patch, we are defiantly open to it if it's done properly.
Our general preference would be for this to be supported in libav as we already have a wrapper for some of their encoders that we don't already hook directly.
Low maintenance is key here. We the HandBrake developers don't make heavy use of hw encoders. Partly due to a lack of supported hardware and partly due to trade offs
From what I understand, MediaSDK isn't being maintained by AMD anymore which would cross that off the list. Leaving AMF. As long as the license is GPL compatible and the library is compatible with our infrastructure I don't really have an issue. It looks like AMF may be a visual studio project without a way of building it on linux out the box. (We cross-compile from linux using MinGW-w64) so that may be an issue? As far as the AMD patch went. Our requirements for that was it made it into libav so we could easily hook it. However it seems have fallen apart there and never made it into their code base and they appear to have disappeared. I think before moving forward and you spending a lot of time, maybe a good idea to put together a rough plan we can sign off on. |
Supporting it in ffmpeg or libav should be easy-ish. I much prefer working with ffmpeg as I already have set up a complete development environment for it, but seeing that apparently libav treats ffmpeg (bad blood between developers? Dunno, don't care) as if it didn't exist and that most distros are switching back to ffmpeg makes it seem that ffmpeg would be a better choice or including it through a third-party library (the backend i spoke of).
AMD Media SDK is the old, dated version that supported ancient cards but was riddled with bugs and unexpected behaviour, which could partially be solved by installing the AMD Media Package that added an even large Library overhead. This is the SDK I started off working with in the plugin (and this later was credited as one of the reasons why AMD Encoding is back on their Roadmap again, which resulted in AMD AMF SDK). AMD AMF SDK is the newer version which fixes many of the inconsistencies in the library and actually moves the support from the application to the driver itself. Thanks to this distributing and building applications that use the API are massively smaller and easier to code too. The new SDK is also licensed under MIT/X11 which should be compatible with GPL, so there should be no issues there.
The examples are indeed Visual Studio projects, but the library headers itself are pure C/C++, so there should be no issues unless MinGW does not support stdcall, no-vtable attributes and similar. It is important to remember that AMF support is currently Windows only, Linux has VAAPI and VDPAU for this. Support may be coming in the future, but it is uncertain currently.
Yes that would be great. My initial plan was:
This plan however requires adding support directly to Handbrake instead of adding it to ffmpeg or libav. |
|
https://github.com/HandBrake/HandBrake/blob/master/libhb/encx265.c is an example of us hooking libx265 Outside of this, the encoder is simply registered in a number of places so that the UI's can query libhb for the available encoders and required information to setup the GUI's ( Line 228 in bd22891 Linux, Mac GUI's and CLI will automatically pick them up whilst the WinGUI will need some minor tweaks to register it. Given it's platform specific, we'll probably need an is_available function to allow the UI's to detect when it's not and not show it. We already have that for quicksync. Following the same kind of pattern is preferable. (There are a few encoders there enc*.c). I'd have a dig around to see how it all hangs together. Using this approach allows all the existing filters and a/v sync code etc to all work as it does today. |
|
Sorry for the delay, it was a busy week.
That should be entirely possible. I have something similar in the obs-studio plugin which tests if any GPU even supports it and if not disables itself again.
I think it would be possible to do this, though I'd much prefer the amf.c, amf_h264.c and amf_h265.c names - that would immediately tell a person working on it that these files work together. However I'll adjust it to whatever is requested. Anyway, there has been some progress on the AMF end. There is now a C API (or at least something that looks like one) which potentially could help reducing the necessary libraries if we do decide to use it. As for the backend, it is practically done. There are some design choices which could have been done better, but there is no point changing that now. I've spent a little bit squashing remaining bugs and adding the last requested features, which essentially makes it feature complete for now. Not bug free, but at least feature complete. |
|
You'll see for QSV we have enc_qsv.c followed by qsv_* for various bits and pieces it needs. I wasn't suggesting they all be enc_* Basically enc_ is the libhb interface wrapper to qsv* |
|
Awesome! I'd be willing to test & debug any versions as necessary, I have a 6670, RX 470, RX460, Fury (Non-X) and I happen to be a C/C++ low level software developer! |
|
A bit of an update on the situation here: I've prioritized integration into ffmpeg so that it can be done in H2 of 2017, essentially also giving access to Handbrake to it through ffmpegs libraries. |
|
Awesome! Can't wait to have this!
…On Jun 9, 2017 11:55 PM, "Michael Fabian Dirks" ***@***.***> wrote:
A bit of an update on the situation here: I've prioritized integration
into ffmpeg so that it can be done in H2 of 2017, essentially also giving
access to Handbrake to it through ffmpegs libraries.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#697 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADWd2NXeR_fZiImatEBCudXID8UiNAL1ks5sChPLgaJpZM4NFOnN>
.
|
|
Information Update: ffmpeg integration is technically done for H264 and H265. For sources including build information and more take a look at: https://github.com/Xaymar/ffmpeg-amf . What's left now is:
A PR to ffmpeg should happen within this month. |
ghost
mentioned this issue
|
Hi, I have an R9 290 and would like to know if there is anything new that we should know? |
|
Not on AMD cards yet. If you have an Intel CPU that's modern (i.e a 4th gen or later), then you can use QuickSync if you enable the onboard GPU as well)| |
|
Okay thank you anyway. I have an Ivy Bridge CPU (3rd gen) which supports intel QSV for H264 but i would like to compare it to native AMD encoding. |
|
Quicksync is there since SB tbh. |
|
It was but you it's best if you have newer (preferably 4th gen or later) CPU with it. They were making substantial leaps back in improvements. |
|
As a MacBook Pro with dedicated graphics card user, it's difficult to access the intergrated Intel graphics in Boot Camp, and HandBrake doesn't support hardware encoding on macOS. So AMD Hardward encoding is my only hope. Looking forward to AMD VCE support in HandBrake |
|
On a side note, pretty sure constant quality isn't working properly. Will need to look into that. |
|
I believe you mistaken when you say the use case is mostly going to be limited to lower end hardware, especially one who does youtube videos. You going to need Radeon Pro version or Vega for constant quality to work properly. It's not about FPS, it's about time at least for me. You have GCN1 where the VCE is quite poor. VCE 3.1 I have is much better (I believe it's 3.1 or 3). RX480 |
|
yes I have a Vega and I will be testing it this week.
…On Mon, Jun 11, 2018 at 3:00 AM, Horace ***@***.***> wrote:
@sr55 <https://github.com/sr55>
I believe you mistaken when you say the use case is mostly going to be
limited to lower end hardware, especially one who does youtube videos.
You going to need Radeon Pro version or Vega for constant quality to work
properly. It's not about FPS, it's about time at least for me. You have
GCN1 where the VCE is quite poor. VCE 3.1 I have is much better (I believe
it's 3.1 or 3).
RX480
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#697 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADWd2H5WjiM6rFQSYvZHu30tAe4A1r3Nks5t7hV5gaJpZM4NFOnN>
.
--
Jimster480
Owner: 0v1.org & LeagueCheats.com and Affiliates
|
|
I tested it with R9 390, which is GCN 2, and I got double the framerate (30's to 70's) for typical H.264 encode compared with i7-4790K x264 encoding. Of course, what I really want is H.265 encoding :( |
|
Tested with a Phenom II X4 945 and RX 550. (Yes I know this is a huge bottleneck!) Using H.264 (x.264), it would encode at about 1:1 speed, 5% GPU utilization, maintaining approximately 20 FPS. Using H.264 (AMD VCE), it encodes at about 10:1 speed, 75% GPU utilization, maintaining approximately 60 FPS. The RX 550 being only entry level is still GCN 4 & VCE 3.4. The bottleneck in my CPU probably inflates the difference in my results. For now I'll take a hit in video quality for solid FPS, speed, and less energy consumed! Thank you so much for all of your work! |
|
@MathewCNichols Your 550 can also encode H265, you may want to try it out. AMD's H264 encoding is quite poor compared to nvidia's hardware NVENC encoder's offerings. The H265 from AMD/Nvidia is much closer in bitrate:quality however. Also, RX 400/500 and vega VCE encodes H265 much faster than it can do H264. Your CPU shouldn't be a bottleneck if you're also hardware decoding and hardware processing (such as downsampling). I don't know if handbrake can do this but it's possible to do the entire process in hardware with "A's Video Converter". |
|
@lhorace read my post again ;) I tested with a Radeon Pro 460 4GB. That's a Polaris GCN 4, VCE 3.4 part. Updated post above to make it clearer. Also added some numbers from a 4770K for comparison. So Any Desktop with Ryzen 5, 7, Intel Quad Core Haswell or newer is going to be close to, or output perform VCE on the their most common Polaris based cards. Gets a little more dicey on laptops with low TDP quads etc. Makes more sense there, or lower end hardware in general. So I don't think I'm being unfair. Based on the numbers i'm seeing, my guess is the design goals for the hardware was: at least: In real time. @kroppt and others -> Remember, HandBrake by default users slower x264 settings to prefer quality / filesize over raw speed. You need to adjust the preset on the video tab to "superfast" for roughly equivalent results. @MathewCNichols Try removing decomb if it's turned on. If your source doesn't need it, it'll remove some of the bottleneck. I need to confirm, but I would expect VCE 3.4 to perform the same on all cards within the family if it's a true ASIC. I don't unfortunately have any Vega hardware to test. I'll do a bit more digging into H.265. Initial impressions is it's a substantially better implementation than their H.264 encoder. (Not the quickest but the quality is substantially better (And I suspect not all of that is codec improvement)) |
|
I am only interested in x265 encoding so this is what I will be testing.
I'll try to see if I can test encode something tonight.
…On Mon, Jun 11, 2018, 12:45 PM Scott ***@***.***> wrote:
@lhorace <https://github.com/lhorace> read my post again ;)
I tested with a Radeon Pro 460 4GB. That's a Polaris GCN 4, VCE 3.4 part.
I also compared that against a much older GCN 1 7850 2GB.
Updated post above to make it clearer. Also added some numbers from a
4770K for comparison.
So Any Desktop with Ryzen 5, 7, Intel Quad Core Haswell or newer is going
to be close to, or output perform VCE on the their most common Polaris
based cards.
Gets a little more dicey on laptops with low TDP quads etc. Makes more
sense there, or lower end hardware in general. So I don't think I'm being
unfair.
Based on the numbers i'm seeing, my guess is the design goals for the
hardware was:
at least:
1080p120
4Kp60
In real time.
@kroppt <https://github.com/kroppt> and others -> Remember, HandBrake by
default users slower x264 settings to prefer quality / filesize over raw
speed. You need to adjust the preset on the video tab to "superfast" for
roughly equivalent results.
@MathewCNichols <https://github.com/MathewCNichols> Try removing decomb
if it's turned on. If your source doesn't need it, it'll remove some of the
bottleneck.
I need to confirm, but I would expect VCE 3.4 to perform the same on all
cards within the family if it's a true ASIC.
I don't unfortunately have any Vega hardware to test.
I'll do a bit more digging into H.265. Initial impressions is it's a
substantially better implementation than their H.264 encoder. (Not the
quickest but the quality is substantially better (And I suspect not all of
that is codec improvement))
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#697 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADWd2KIFKDaNJ5T5z-Wbzd3RM7fHk_peks5t7p67gaJpZM4NFOnN>
.
|
|
If you have VEGA, I'm interested in numbers from it for balanced and quality, no filters. |
|
Vega has much higher throughput over polaris (fps for a given resolution/quality), though iirc, quality:bitrate is the same. |
|
Any settings you specifically want to try? If you send me a list /
screenshot I can run it with exactly those settings and tell you.
I also have an OC'd Ryzen 1700x w/ 32GB 3200Mhz 14/14/14/38 ram.
…On Mon, Jun 11, 2018 at 2:01 PM, Scott ***@***.***> wrote:
If you have VEGA, I'm interested in numbers from it for balanced and
quality, no filters.
I expect they'll be the same as Polaris but it'd be nice if I was wrong.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#697 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADWd2FcAmw0F2hA55EPujWjSKqlqvHqlks5t7rCXgaJpZM4NFOnN>
.
--
Jimster480
Owner: 0v1.org & LeagueCheats.com and Affiliates
|
|
How can I enable this? When I just loaded up the new Handbrake its encoding
on the CPU only.
I'm using x265 3k avg bitrate on preset Slower with no Encoder Tune and
Profile is Auto.
…On Mon, Jun 11, 2018 at 2:38 PM, Jimster480 ***@***.***> wrote:
Any settings you specifically want to try? If you send me a list /
screenshot I can run it with exactly those settings and tell you.
I also have an OC'd Ryzen 1700x w/ 32GB 3200Mhz 14/14/14/38 ram.
On Mon, Jun 11, 2018 at 2:01 PM, Scott ***@***.***> wrote:
> If you have VEGA, I'm interested in numbers from it for balanced and
> quality, no filters.
> I expect they'll be the same as Polaris but it'd be nice if I was wrong.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#697 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ADWd2FcAmw0F2hA55EPujWjSKqlqvHqlks5t7rCXgaJpZM4NFOnN>
> .
>
--
Jimster480
Owner: 0v1.org & LeagueCheats.com and Affiliates
--
Jimster480
Owner: 0v1.org & LeagueCheats.com and Affiliates
|
|
You’ll need to select the appropriate encoder instead of x265 on the video tab. |
|
Usually start with the Fast 1080p30, 1080p source such as "big buck bunny" |
|
Ah alright,
That's why it didn't work since I just used my old preset.
…On Mon, Jun 11, 2018, 3:53 PM Scott ***@***.***> wrote:
[image: image]
<https://user-images.githubusercontent.com/628593/41253812-695dffaa-6db9-11e8-9ddf-ce67daeaaaa7.png>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#697 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADWd2P5ub4AD66DwsM2r9i6t6D_5yVJQks5t7sqdgaJpZM4NFOnN>
.
|
|
I had to grab the nightly build in order to enable it.
I have set 1080p (1920x1036) h265 VCE, Avg KB 3000, Encoder: Balanced,
Profile: Main, Level: Auto, Constant Framerate: Same as source, Decomb:
Off, Audio: Auto Passthrough
I am getting ~205fps @ a power draw of 24-28W from the Vega56 with a 15C
increase in temp (34c to 49c).
…On Mon, Jun 11, 2018 at 3:56 PM, Jimster480 ***@***.***> wrote:
Ah alright,
That's why it didn't work since I just used my old preset.
On Mon, Jun 11, 2018, 3:53 PM Scott ***@***.***> wrote:
> [image: image]
> <https://user-images.githubusercontent.com/628593/41253812-695dffaa-6db9-11e8-9ddf-ce67daeaaaa7.png>
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#697 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ADWd2P5ub4AD66DwsM2r9i6t6D_5yVJQks5t7sqdgaJpZM4NFOnN>
> .
>
--
Jimster480
Owner: 0v1.org & LeagueCheats.com and Affiliates
|
|
I have queued a bunch of movies now to transcode, and will check them out
when they are done.
Using the "quality" setting now I am getting 190-208FPS (it fluctuates alot
more) w/ avg around 201.8. However the temp of the GPU has risen to 58C and
its using 25-30W now.
…On Mon, Jun 11, 2018 at 6:18 PM, Jimster480 ***@***.***> wrote:
I had to grab the nightly build in order to enable it.
I have set 1080p (1920x1036) h265 VCE, Avg KB 3000, Encoder: Balanced,
Profile: Main, Level: Auto, Constant Framerate: Same as source, Decomb:
Off, Audio: Auto Passthrough
I am getting ~205fps @ a power draw of 24-28W from the Vega56 with a 15C
increase in temp (34c to 49c).
On Mon, Jun 11, 2018 at 3:56 PM, Jimster480 ***@***.***> wrote:
> Ah alright,
> That's why it didn't work since I just used my old preset.
>
> On Mon, Jun 11, 2018, 3:53 PM Scott ***@***.***> wrote:
>
>> [image: image]
>> <https://user-images.githubusercontent.com/628593/41253812-695dffaa-6db9-11e8-9ddf-ce67daeaaaa7.png>
>>
>> —
>> You are receiving this because you commented.
>> Reply to this email directly, view it on GitHub
>> <#697 (comment)>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/ADWd2P5ub4AD66DwsM2r9i6t6D_5yVJQks5t7sqdgaJpZM4NFOnN>
>> .
>>
>
--
Jimster480
Owner: 0v1.org & LeagueCheats.com and Affiliates
--
Jimster480
Owner: 0v1.org & LeagueCheats.com and Affiliates
|
|
@sr55 I encode with VCE, 30000 bit rate, 1 hour video, no quality lost visually at 30 minutes I have AMD because I only use AMD hardware and I haven't tested Ryzen Chips. AMD FX-8320E Eight-Core Processor, 5 hours at superfast, 3.5 hours at very fast. |
|
Using x265?
I haven't lost quality that I can perceive from a 10.7mbps AVC to a
~3000kbps H265 VCE, although its 1/6th the file size.
I just checked through various parts of the movie and compared on my Dell
professional 4k monitors and I cannot tell any difference in 99% of the
scenes.
There is one scene with a ton of peoples faces where the 3000kbps version
has just a bit of quality loss around the eyes but otherwise this wouldn't
be discernable when watching this movie on a phone, tablet or even on a TV
at a normal viewing distance.
Also I can say that changing from "balanced" to "quality" has no change in
file size whatsoever.
…On Mon, Jun 11, 2018 at 9:35 PM, Horace ***@***.***> wrote:
@sr55 <https://github.com/sr55> I encode with VCE, 30000 bit rate, 1 hour
video, no quality lost visually at 30 minutes
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#697 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADWd2NyK7z7oKlmx1wOq4Evkxuw6ydfCks5t7xrtgaJpZM4NFOnN>
.
--
Jimster480
Owner: 0v1.org & LeagueCheats.com and Affiliates
|
|
Because I am recording video for Youtube, it's always been H.264 at 30000 bit rate. As I've said, with CPU transcoding, 1080P or 1440p, it's from 3.5 to 5 hours (CPU) versus 30 minutes hardware encoding |
|
Well I am encoding full length movies from x264 into x265 in around 20
minutes.
…On Mon, Jun 11, 2018 at 9:45 PM, Horace ***@***.***> wrote:
Because I am recording video for Youtube, it's always been H.264 at 30000
bit rate. As I've said, with CPU transcoding, 1080P or 1440p, it's from 3.5
to 5 hours (CPU) versus 30 minutes hardware encoding
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#697 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADWd2Iv4sXbgJaYxuSJkfak7bCh6mLcBks5t7x0kgaJpZM4NFOnN>
.
--
Jimster480
Owner: 0v1.org & LeagueCheats.com and Affiliates
|
|
I record at that higher bit rate because when you upload to youtube, youtube also transcode and if you don't give youtube the best. It will look ugly |
|
@jimster480 You transcode H.264 to HEVC via CPU. 1 hour video, 1080P or 1440P @ 20 minutes? @ 10000 bit rate? |
|
Is this 4,000 Intel i9 cpu? |
|
Just a heads up to all, there are 16 participants on this issue. It's easy to write Tweet-length comments on GitHub, but please keep in mind you're likely sending 15 emails every time you do. |
|
I personally been following this issues for the last 6 months, every E-Mail, is how I track. Is just as important to me. With that said, it seems to me people, after 6 months of effort, how useful this feature is. I like to make sure that this feature is very important to me. |
|
No I'm using amd vce on my vega56. These are 1080p movie rips. The quality
varies from 8000 to 14000 kbps x264. I am ripping it to x265 at an average
of 3000 kbps. So far the highest FPS I have seen is 272 FPS with the second
pass encoding holding steady around 250 FPS in some movie titles.
…On Mon, Jun 11, 2018, 9:49 PM Horace ***@***.***> wrote:
@jimster480 <https://github.com/jimster480> You transcode H.264 to HEVC
via CPU. 1 hour video, 1080P or 1440P @ 20 minutes?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#697 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADWd2CaUAj_TTFG6pnrXF1bPNtapCx3Cks5t7x4zgaJpZM4NFOnN>
.
|
|
Yes this feature is incredibly important! There are a lot of us AMD users
out there who have had to encode using CPU only over all of these last
years. I literally had an i7 Haswell that just sat and did x264 to x265
encoding all day every single day for months to encode my movie Library.
That chip ran at 3 gigahertz and it would get around 14 FPS in this same
encoding scenario.
Never mind that it also drew around 70 watts of power vs the 25 to 30 Watts
that I am currently seeing. With encoding speeds so high I could literally
offer a free service online to encode videos for people because a full
length movie in only 20 minutes is pretty much Godspeed.
…On Mon, Jun 11, 2018, 9:55 PM Horace ***@***.***> wrote:
I personally been following this issues for the last 6 months, every
E-Mail, is how I track. Is just as important to me. With that said, it
seems to me people, after 6 months of effort, how useful this feature is. I
like to make sure that this feature is very important to me.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#697 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADWd2BkNsXMVIIVdgsuad2qU51LE-Kb-ks5t7x-kgaJpZM4NFOnN>
.
|
|
Indeed, the feature is welcome and important, which is why I fixed and merged it. Perhaps I should have been more specific: In the future, consider condensing multiple one-liners into single posts so those of us who get emails for all issues and pull requests don't have to unsubscribe from the entire thread to limit noise. Thanks for the benchmarks as requested. Let's move further benchmarks and discussions to the HandBrake Community Forums. |
Hi I'm the developer of theAMD Encoder Plugin for OBS Studio here. Since there is always a comment about Handbrake AMF support anywhere the plugin gets mentioned, I wanted to know if there were plans on adding it or if someone could point me at the correct point to start adding support for it. I found a PR for it but it was based on the Media SDK as far as I can tell and rejected,
I have a few questions:
The text was updated successfully, but these errors were encountered: