Issue with trickplay

[TheDreadPirate]

Mine grew from 4.5GB to 17GB.

Almost the same here. My config folder went from 400MB to 17GB after my BIF files were converted to trickplay files. Do you have other things enabled on your libraries like chapter image extraction?

Yep.  Chapter image extraction is enable and has been.  That takes much less time than trickplay, but didn't have to worry about that with the 10.9 upgrade since they were already done.

[lionking102]

Other question about Trickplay:
Does anyone know, what the "Fmpeg threads" setting exactly means?
Is it the the amount of CPU cores or threads, that my server uses to generate the trickplay-images?
Thanks for your help

[Efficient_Good_5784]

Yes, it's the amount of CPU threads you allow it to use. You can set it to 0 if you want it to use as much threads as it can request from your system.

[lionking102]

Yes, it's the amount of CPU threads you allow it to use. You can set it to 0 if you want it to use as much threads as it can request from your system.

Thank you, awesome!

[bitmap]

I'm at about 60 hours, 32.6%. Enabled HWA and it hasn't made much difference. At 56.x GB...

[TheDreadPirate]

I got an explanation from one of the devs. The way, I'm assuming, ffmpeg works is that it needs to process EVERY frame of the video when it is generating the trickplays.

Every

Frame

[Iskelderon]

I got an explanation from one of the devs.  The way, I'm assuming, ffmpeg works is that it needs to process EVERY frame of the video when it is generating the trickplays.

Every

Frame

It's honestly impressive how the old plugin managed to do the same job with a fraction of the resources this takes up. 
On my collection across several drives, it seems like the new Trickplay feature achieves about TEN PERCENT per day, where the plugin was done with everything in about 6-7 hours.

[Dzvon2]

Does anyone know what the difference between "JPEG quality" and "Qscale" is? If I also increase Qscale, will that decrease the file size of the images? Also, using JPEG was an interesting choice of image format... I thought JPEGs had a reputation for being overly large for the compression quality you get out of them. Using something like webp that is a really small file size makes more sense to me, but I am not sure if there were reasons why JPEG had to be what was used.

[gnattu]

Does anyone know what the difference between "JPEG quality" and "Qscale" is? If I also increase Qscale, will that decrease the file size of the images? Also, using JPEG was an interesting choice of image format... I thought JPEGs had a reputation for being overly large for the compression quality you get out of them. Using something like webp that is a really small file size makes more sense to me, but I am not sure if there were reasons why JPEG had to be what was used.

Does anyone know what the difference between "JPEG quality" and "Qscale" is?

"JPEG quality" affects the quality that the final tile picture that will be used and stored on your filesystem.

"Qscale" affects the ffmpeg's encoder's direct quality and is used as the intermediate image as temp files.

If I also increase Qscale, will that decrease the file size of the images?

For the intermediate temp images, yes, but it makes less sense as such temp files will get removed during automatic cleanups anyway.

Also, using JPEG was an interesting choice of image format... I thought JPEGs had a reputation for being overly large for the compression quality you get out of them. Using something like webp that is a really small file size makes more sense to me, but I am not sure if there were reasons why JPEG had to be what was used.

Because MJPEG is a valid video format that is widely supported and can have hardware encoders implemented, and is also a very fast format for CPU(modern CPUs can outperform common hardware encoders in Intel GPUs). Also, for pictures this small (320px width), compression efficiency does not mean that much because it is just too small and you will get probably less than 1kb per frame size saving by using a format with "better compression". MJPEG is picked mainly for compatibility and performance reasons, file size is sacrificed because of this, but current default settings generates less than 5M file for 1hr video, which is good enough to me.

[Efficient_Good_5784]

...and is also a very fast format for CPU(modern CPUs can outperform common hardware encoders in Intel GPUs).

I decided to see how much time I would save with encoding a trickplay file by switching to HWA, so I used the logs to see how much time it took to generate one for a single 24min long 1080p video.
My Jellyfin server is using a Ryzen 7 5750G, so my server doesn't support the 2nd option for HWA in the settings where it accelerates MJPEG encoding. Only the hardware decode option works on it.

The results:

• CPU: ~55 seconds
  
• Hardware Decode Only: ~2.3 minutes
  

I'm surprised using the GPU in this case took a bit more than twice as long as the CPU.

The GPU-generated trickplay file was a few hundred KBs larger, and the picture quality for it was worse too when I compared the thumbnails produced by both it and the CPU using the same settings. I think the bad quality could just be me using an AMD gpu which are known to not be good encoders in terms of quality as compared to Intel or Nvidia GPUs.
I didn't save any time, rather, I lost time with the 1st HWA option.
The only thing that I gained was lower CPU utilization throughout the creation and a lower server wattage usage.