Luke 37132 Posted March 29, 2018 Share Posted March 29, 2018 Yes that's correct. Link to comment Share on other sites More sharing options...
snake98 10 Posted March 29, 2018 Author Share Posted March 29, 2018 I'll test it. What version of emby do you run, stable, beta or dev. I"ll try to get it built today or tomorrow. Link to comment Share on other sites More sharing options...
Luke 37132 Posted March 29, 2018 Share Posted March 29, 2018 @@Luke If this is acceptable, i'll write the code and ask for some beta tester in another thread. I"ll map it as following slow, slower, veryslow = slow medium = medium All other = fast so the gpu method only has slow, medium,f ast? Link to comment Share on other sites More sharing options...
Carlo 4330 Posted March 29, 2018 Share Posted March 29, 2018 (edited) Depends on the GPU type. For nvenc it's: slow hq 2 passes medium hq 1 pass fast hp 1 pass hp high performance hq high quality bd blue ray disk ll low latency llhq low latency hq llhp low latency hp lossless lossless losslesshp lossless high performance However, I think it's a bad idea to try and map these so it's only one setting used for both hardware and CPU. I know I'd want to use different defaults for hardware and when it has to revert to using CPU it has a different set of defaults. For example since the consumer nvenc only supports 2 streams it's sort of dumb to not run it in slow mode since it can produce files roughly half the size. I can only HW transcode 2 streams at once so why not make the most use of those 2 streams? Anything over 2 streams will fall back to using CPU and there I probably want to use FAST or MEDIUM but not slow. So I'd highly recommend not "mapping" the values but to save both a CPU setting and a HW setting and to use the REAL VALUES in the table above so people actually know what setting is used without having to test and look at log files. Carlo Edited March 29, 2018 by cayars 1 Link to comment Share on other sites More sharing options...
snake98 10 Posted March 29, 2018 Author Share Posted March 29, 2018 Why would you map it? The idea would be to show what is supported by the hardware. Not to try and translate it back to CPU nomenclature. So for NVENC just show the options exactly as they are here. So basically these options will translate exactly to what we see in the ffmpeg options. 1.To keep it simple. 2. get something implement in a more timely fashion 3. keep support request down, I've spent hours reading nvenc, and it can get confusing. 4. beyond what i can do. I do a bit of coding and can map it easily. 5. Luke and other would rather put there time into something that more people would use, very few people would probably spend the time to find the best possible combination of commands. Mapping makes it easy to understand. Link to comment Share on other sites More sharing options...
roberto188 33 Posted March 29, 2018 Share Posted March 29, 2018 What version of emby do you run, stable, beta or dev. I"ll try to get it built today or tomorrow. Latest Beta for Windows. Link to comment Share on other sites More sharing options...
snake98 10 Posted March 29, 2018 Author Share Posted March 29, 2018 so the gpu method only has slow, medium,f ast? In simple terms yes, of what i can understand. There is one more Lossless, I can put it in the slowest option, but it may override bit rate control. We can try it, and doesn't work I"ll pull it out. I"ll open a new topic for nvenc testing with the info and instructions. Link to comment Share on other sites More sharing options...
roberto188 33 Posted March 29, 2018 Share Posted March 29, 2018 In simple terms yes, of what i can understand. There is one more Lossless, I can put it in the slowest option, but it may override bit rate control. We can try it, and doesn't work I"ll pull it out. I"ll open a new topic for nvenc testing with the info and instructions. Ok keep me posted. Link to comment Share on other sites More sharing options...
Carlo 4330 Posted March 29, 2018 Share Posted March 29, 2018 (edited) 1.To keep it simple. 2. get something implement in a more timely fashion 3. keep support request down, I've spent hours reading nvenc, and it can get confusing. 4. beyond what i can do. I do a bit of coding and can map it easily. 5. Luke and other would rather put there time into something that more people would use, very few people would probably spend the time to find the best possible combination of commands. Mapping makes it easy to understand. I respectfully disagree on trying to "map" these settings as that's going to open a can of worms and more bugs. It makes working with source code/variables much harder when a setting doesn't really mean what it says. This isn't really going to "keep it simple" but will make understanding settings quite confusing potentially. How are you going to try to come up with a set of mappings that work across: CPU AMD AMF qsv - Intel Quick Sync MediaCodec Android OpenMAX OMX Nvidia NVENC Video Acceleration API (VA API) Exynos V4L2 MFC Encoder That's an exercise full of potential bugs. What if an option isn't supported? Do you still show it but ignore it for that HW choice? That type of thing is confusing for users as they could spend huge amounts of time trying to test settings that make zero change which makes them think something is broke or not working. That also means they need to come up with settings that work OK for both CPU and HW but may not be ideal for either use specifically (hybid settings). Do you envision only allowing the least common set of options that fit everyone of the HW platforms currently supported? What if one of the encoders doesn't support a option you are trying to map or does it differently? CRF vs bitrate limits comes to mind. This will only get worse as more/different HW decoders/encoders and/or options are introduced. What we really need is one set of options specific to the CPU and one set of options specific to the choosen GPU technology being used. Otherwise the use of the settings can become quite confusing to the user trying to change the setting who does understand what settings should be there or be used. Yes this does add a couple additional additional options to set and store specific to the HW encoder chosen but the options can be VERY SPECIFIC to the hardware. It then requires a check of the encoding type (cpu or other type above) to know what set of options to use when building the command line used to create the ffmpeg command but this is already being done. It's not hard at all to pull the value from PresetCPU (example) when inserting this into the ffmpeg command line when using a CPU vs PresetGPU (example) when using the GPU. I tried to use a mapped common approach on my ffmpeg conversion scripts when I first started supporting GPUs and it got out of hand. I found it best to allow specific settings for each GPU card which ended up making the code much easier to read as well. No guessing what "medium" preset means to the GPU, no guessing how CRF translates to the GPU, etc The deinterlacing setting should be moved from it's present place to this set of options as well because these to may need to be set differently depending on CPU vs GPU use. A user may only want to use Bob for CPU but will want to use Bob & Weeve (if possible) for HW. <- Much easier in HW but can put a hurting on some CPUs especially if they need to support a couple of streams. Does any of this make sense? Edited March 29, 2018 by cayars 1 Link to comment Share on other sites More sharing options...
roberto188 33 Posted March 29, 2018 Share Posted March 29, 2018 I don't disagree with you on any of this. I do think however this is a large undertaking and I doubt they will dedicate the time to this. A "mapping" is quick and dirty. I wish I could code because I'd definitely do this. I also agree on the deinterlace option. Link to comment Share on other sites More sharing options...
Carlo 4330 Posted March 29, 2018 Share Posted March 29, 2018 I don't see it as "large" at all, but mostly trivial in nature. As an example we could add one new option to the config screen that enables specific profile to be set for HW use. The drop down would have the appropriate choices shown for the HW type selected above. These setting are nothing but html in a drop down. When building the ffmpeg string you would then choose the saved value for PresetCPU if we're building the string for (CPU) or we would use the value stored in PresetGPU if we are using any of the HW options. This type of check is already being done in order to know which encoder to use such as h264 or h264_nvenc. That's basically it. You would just do that for any specific option you want to expose. For CPU the main ones are CRF and PRESET. Just having the exposed PRESET available if nothing else adds lots of power since these are a whole set of defaults the encoder users. 1 Link to comment Share on other sites More sharing options...
snake98 10 Posted March 29, 2018 Author Share Posted March 29, 2018 Latest Beta for Windows. link to new thread and testing for nvenc https://emby.media/community/index.php?/topic/57528-testing-nvenc-for-encoding-options/ Please let me know if they work, and respond in the new thread. Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now