Configure minimum/maximum chapter length - thumbnails

[toooo 8]

I have had several movie and episode files that contain very few and/or long chapters. For example, a file with 2 chapters, one of which is nearly the full length of the media.

I suggest an improvement to chapter thumbnail generation - where we can set a minimum and maximum chapter length.

Example use cases:

1. File has few (long) chapters
2. File has many (short) chapters

Fix Option 1:

Definition of LONG or SHORT comes from a custom configuration. If the average chapter length in a media file falls outside of this duration range, consider the file to NOT contain useful chapters, thus apply the already available "Thumbnail images interval" that is already set for the relevant library.

Fix Option 2 (simpler):

Configure a maximum chapter length. If a chapter is longer than the maximum (or the average chapter length in a file), have the media file use the "Thumbnail images interval" that is already set for the relevant library.

Thanks

[Luke 42077]

Hi, are you saying you want to ignore the chapters in your own files?

[brothom 177]

I'd look to hook into this as well by requesting "5 seconds" as an option in the thumbnail generation dropdown: 

10 seconds is can sometimes be too much (rounding during scrolling as describe under OP's "Fix Option 1:") and can show an image that's at the start of the current seek time chunk, causing an overshoot when seeking. It's not a breaking issue but would definitely be an addition to QoL.

[toooo 8]

7 hours ago, Luke said:

Hi, are you saying you want to ignore the chapters in your own files?

Yes. Some media has completely useless chapter markers (thus thumbnails).

I would like to have more interval options, as well. For example, I don't need to clog my server with tons of thumbnails, and would prefer just having every few (5) minutes (every couple of scenes). I only use the thumbnails to do quick validation of file quality/correctness without having to play and skip through the video.

[ebr 16169]

Hi, there's already an open request for this or something functionally equivalent. Please join in and contribute to the existing discussion at:

 

[rechigo 364]

On 1/26/2026 at 2:16 AM, brothom said:

I'd look to hook into this as well by requesting "5 seconds" as an option in the thumbnail generation dropdown: 

10 seconds is can sometimes be too much (rounding during scrolling as describe under OP's "Fix Option 1:") and can show an image that's at the start of the current seek time chunk, causing an overshoot when seeking. It's not a breaking issue but would definitely be an addition to QoL.

This actually used to be a thing back in the day... I believe it was 5, 10, and 30 second intervals you could choose. These were actually removed because of an issue I brought attention to years ago regarding preview image extraction not completing correctly. Softworkz goes into more detail if you're curious. Tldr we won't be getting those options any time soon as difficult to do both quickly and reliably.

Edited January 29 by rechigo

[brothom 177]

7 hours ago, rechigo said:

This actually used to be a thing back in the day... I believe it was 5, 10, and 30 second intervals you could choose. These were actually removed because of an issue I brought attention to years ago regarding preview image extraction not completing correctly. Softworkz goes into more detail if you're curious. Tldr we won't be getting those options any time soon as difficult to do both quickly and reliably.

Bah. This explains a lot about how inaccurate it is. I'm guessing a standard library is being used to generate the bif files.

Maybe it would be a better solution to choose a different package (i.e. let ffmpeg extract the frames and compile them into a bif manually). Using keyframes is incredibly incorrect due to framerates, that's also why ffmpeg prefers using timestamps.

[ebr 16169]

3 hours ago, brothom said:

Bah. This explains a lot about how inaccurate it is. I'm guessing a standard library is being used to generate the bif files.

No, we have our own custom methods of extracting these and @softworkzwent to great lengths to develop those.

[brothom 177]

1 hour ago, ebr said:

No, we have our own custom methods of extracting these and @softworkzwent to great lengths to develop those.

Oops, my bad. Consider my comment deleted  Regardless, is there a rework somewhere in the pipelines? 

[Luke 42077]

7 minutes ago, brothom said:

Oops, my bad. Consider my comment deleted  Regardless, is there a rework somewhere in the pipelines? 

A rework to do what?

[brothom 177]

15 minutes ago, Luke said:

A rework to do what?

To be able to configure times for the thumbnails to be generated other than "10 seconds" or "chapters".

According to this previous post the issue stems from using frames, rather than timestamp to render the previews:

Nowadays it would be better off to use time (seconds/ms) in conjunction with something like ffmpeg: https://trac.ffmpeg.org/wiki/Create a thumbnail image every X seconds of the video

Apparently `ffmpeg -i input.flv -vf fps=X out%d.png` has a ready to use command to do exactly this and I suppose these generated images could later be bundled into a bif?

 

Edited January 29 by brothom

[softworkz 5065]

@brothom

What you are saying is very well possible. Even very easily possible. In fact, that's what we had in earlier days.

The point that you are missing is the difference in required effort between these two ways. By effort, I mean a range of system resources: CPU, GPU, RAM, GPU-Memory, disk I/O etc.
Let's compare by an example. Assume a video file with these specs:  10 GB HEVC video, 60min duration, 4k, 30fps, keyframe interval 3s

• Means: 3600s length
• With a 10s image extraction interval, we need 360 images
• Average keyframe size for a file with these specs is ~1.5MB
  => The total amount of data to retrieve from the video is 360 * 1.5MB = 540 MB
• Most file container formats have a seek index
  => Our extraction requires 360 seeks and 360 reads of a total amount like 540 MB
  => Precise time extraction requires 1 seek, 1 read and a total data transfer of > 5 GB
• With 30fps and 3s keyframes, each keyframe is followed by 89 other frames 
  Decoding always needs to start at a key frame. So, decoding an arbitrary frame requires to decode from 0 to 89 additional frames
  Assuming an even distribution, the average number of additional frames to decode is  ~45
  => Keyframe extraction needs to decode 360 keyframes
  => Precise extraction needs to decode 360 + 45 * 360 = 16,560 frames

Summary

• Precise extraction
  • requires 46x more CPU or GPU processing
  • requires 18x more data to read from disk
  • takes 10-40x more time to extract images from a file

Conclusion

• Hardly anybody would accept that tradeoff