Emby not respecting H264 encoding preset setting on Hardware Encoding for Intel Quick Sync

[Luke 37065]

Yes that's correct.

[snake98 10]

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.

[Luke 37065]

 

@@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?

[Carlo 4330]

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

[snake98 10]

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.

[roberto188 33]

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.

[snake98 10]

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.

[roberto188 33]

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. 

[Carlo 4330]

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

[roberto188 33]

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.

[Carlo 4330]

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.

[snake98 10]

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.