Thumbnail generation for Video files.

[Rayraz]

Hello,

I was thinking it might be a nice idea to generate thumbnails for video files.

At a cursory glance of the codebase I imagine the complexity of such a feature lies more in the integration with file storage, cacheing, etc. than the thumbnail-generation itself (which seems like shouldn't be too difficult with the availability of something like https://github.com/PHP-FFMpeg/PHP-FFMpeg).

If this strikes you as a feature worth including in the bundle, what would be a good broad strokes direction with regards to where to to store and cache the generated thumbnails and associated metadata?

I'm not terribly familiar with that ecosystem yet, nor do I feel like I've got a solid grasp on the architectural choices that guide this bundle's implementation.

I suppose it could be possible to do something like this:

Given video file: <storage>/media/original/my-folder/my-video.mp4
Generate thumbnail: <storage>/media/cache/joli-media-easy-admin-small/my-folder/my-video.mp4.jpg

The changes to _as_image.html.twig would be trivial for both EA and Sonata bridges, so that's nice.

It'd probably take some changes to the code that resolves variations to pull in a variation with a subtly different filename to the original though? Any opinions on what would be a sane approach there?

[xavierlacot]

Hi Rayraz,

It is true, video thumbnail generation is not natively supported in the bundle at this time, but it is indeed a valuable feature to consider. The main challenge, I think, is to define what we want to achieve in terms of functionality and how it fits within the existing architecture.

There are multiple possible approaches to handle videos in the mediabundle:

• nothing special for videos, just treat them as files without thumbnails (current behavior)
• generate a single thumbnail for each video and store it alongside other variations. The Variation of a video would be the thumbnail image, while the original video remains unchanged. This is the minimal integration, which allows to display a thumbnail in the admin interfaces (and possibily a cover image in frontends) without much complexity.
• introduce a more complex model where videos can have multiple thumbnails at different timestamps, sizes, etc. This would require significant changes to the bundle's architecture and API, as well as careful consideration of how to store and retrieve these thumbnails.
• consider that the Variation of a video must be a video as well, and thumbnails are a separate concept altogether. This would mean that the bundle would need to support both video variations and thumbnail generation as distinct features. It would also mean that the bundle configuration should support video variations config parameters (resolution, bitrate, codec, etc.) and also thumbnail generation parameters (timestamp, size, format, etc.).

Each approach has its pros and cons, and the best choice depends on the specific needs of your application and how you envision using video media. Therefore, I think that there is no one-size-fits-all solution - the bundle could provide minimal video thumbnail support out of the box, and it should be up to the developer to implement more advanced features as needed in their own application.

Here is what I propose:

• For the time being, we could implement the second approach, generating a single thumbnail for each video and storing it alongside other variations. This would provide a basic level of support for video thumbnails without overcomplicating the bundle. We could:
  • display thumbnails in the admin bridges
  • add a Video twig component that displays the video along with its cover image
• More adavanced video integrations (transcoding / multiple thumbnails / etc.) could be implemented by developers in their own applications using the event system. We should provide an example in the documentation showing how to generate multiple thumbnails for a video in a PostCreateMediaEvent listener, using PHP-FFMpeg or another tool.

The detailed plan:

• add ffmpeg as a suggested dependency
• add a Processor class that supports video files to generates a single thumbnail image using ffmpeg
• add a Video Twig component that displays the video with its cover image
• update the admin bridges
• document the event-based approach for more advanced use cases:
  • provide an example listener for PostCreateMediaEvent that generates multiple thumbnails at different timestamps and sizes
  • explain how to store these thumbnails as separate original media if needed

What do you think of this plan?

[Rayraz]

Yeah that all sounds very sensible. In my personal case, I came at it from the perspective of providing a small UX improvement for content management. For example browsing through a grid of 250 video icons it's not nearly as easy to pick the one you need than if there were a hopefully more visually recognizable thumbnail. You bring up some good points though about what should and shouldn't be part of the project and when you start to cross over into different territory. I feel like this bundle is about asset management rather than content management. So once we start talking about 'supporting images' from the perspective of front-end UI like lets say covers in an OTT app, to me that's content management rather than asset management. Likewise, video transcoding can easily turn into a rabbit hole and doing that well is arguably a different project entirely. There is some gray area though, where it's not directly clear what side of the asset/content line things fall. A set of thumbnails extracted from a video for preview purposes or such is possibly still within the asset management realm. The same applies for things like subtitles (which I will need to find a solution for as well). I like the plan you laid out, although I think we might want to carefully limit the scope of a video component. For proper front-end integration people should really be looking towards things like video-js, jw player, radiant media player, etc. Do you have suggestions on how to deal with filenames? I noticed so far everything is filesystem-based so there is potential to use naming conventions for automatically associating single-thumbnail, thumbnail-sets, subtitle files, etc. with video files.