Closed rurounijones closed 4 years ago
@rurounijones
Unfortunately, I think this would be virtually impossible with our current infrastructure. None of the SVG libraries available to us (QtSvg, librsvg, or the one we've migrated to, resvg) support animation, nor do any of them have any plans to. In fact, I'm having no luck finding even a single library that DOES support animation. AFAICT animating SVG basically requires a web browser, full stop.
I'll leave this open, but... if anyone has any suggestions for how it could be done, don't be shy. So far I'm not seeing a path.
AFAICT animating SVG basically requires a web browser, full stop.
That seemed to be the results of my research. Either a browser or some commercial packages but I was hoping I had missed something.
However following your link to resvg
(which is new to me) It looks like the underlying backend, skia, does support animation using https://skia.org/user/modules/skottie but that is an abstraction layer below what you want to be using I guess although skia can apparently be used directly as a library.
I was also wondering if there was a way to fake it by using a QtWebView to display the animation or something along those lines (although I know it would be a hack).
I just realise that what I though was referring to svg in https://skia.org/user/modules/skottie was not, in-fact svg, and something completely different, oh well.
It does give the ability to convert SVG to their lottie file format which could then be played by Skia but I am not sure if the abstraction issues mentioned befoew already kill this option.
After more browsing it appears that Qt directly supports this lottie file format ( https://www.qt.io/blog/2019/03/08/announcing-qtlottie ) so if Openshot were able to incorporate that then I think that would be a good alternative.
I would then convert my svg to this lottie file format and everyone is happy(?)
It seems like supporting Lottie would be a big feature for Openshot anyway but if this requires a more involved enhancement request I am happy if a different process needs to be followed.
@rurounijones
Unfortunately, I think this would be virtually impossible with our current infrastructure. None of the SVG libraries available to us (QtSvg, librsvg, or the one we've migrated to, resvg) support animation, nor do any of them have any plans to. In fact, I'm having no luck finding even a single library that DOES support animation. AFAICT animating SVG basically requires a web browser, full stop.
I'll leave this open, but... if anyone has any suggestions for how it could be done, don't be shy. So far I'm not seeing a path.
Aren't OpenShot's Transitions already creating animations? There is even a tutorial about it Animate a Title Card with Inkscape/Openshot From what I understood of it, animated SVG's are just a zip of images with a script of their start point, traject and time. Could that script not be translated to the Transition engine that OpenShot uses, or are SVG's more complex?
I am closing this issue as I do not believe it is feasible and was always a bit of a moonshot request. I think using lottie files is the better alternative (raised in https://github.com/OpenShot/openshot-qt/issues/3831 ).
@MBB232
Aren't OpenShot's Transitions already creating animations?
Not... as such, no. Transitions animate how two video sources are composited together by using a static grayscale image as a mask. The brightness of the image can then be altered over time to "bias" the mask towards one end of the brightness spectrum or the other. (Full white representing one of the two sources, full black representing the other source. It's keyframe animated, but not any form of sprite animation in the sense of what SVG animation is able to achieve.
There is even a tutorial about it Animate a Title Card with Inkscape/Openshot
Using OpenShot's own built-in keyframe animation tools (positioning, image transformation, etc.), yes, and a lot is possible that way, but only by recreating the animation using OpenShot's internal tools. Any pre-made animations wouldn't be importable as such, which was the goal of @rurounijones' original request.
From what I understood of it, animated SVG's are just a zip of images with a script of their start point, traject and time. Could that script not be translated to the Transition engine that OpenShot uses, or are SVG's more complex?
SVGs are potentially able to be made near-infinitely complex, these days. Originally SVG animation was done using a special-purpose language, SMIL. But SMIL sort of began to fall out of favor, then caught a bit of a resurgence, and these days it's sort of holding on, but support has simultaneously grown for doing SVG animation via embedded CSS (including CSS animation) and JavaScript, not requiring SMIL (but instead requiring a full HTML/CSS/SVG rendering engine plus JS runtime). Nothing supports that featureset in a way that's really accessible to us.
The SVG libraries don't have JS runtimes, don't support animation features, and have no interest in going down that road (understandably). The web rendering engines don't really support frame-by-frame extraction of the animation, they can display it but only on their own output canvases which doesn't particularly help us. I'm sure FFmpeg could be convinced to convert SVG animation into video, because FFmpeg can do anything with the right components compiled in, but... well, if it's going to be converted to video, it might as well just be converted to video and imported that way. The only reason built-in support for SVG animation would be useful would be if it could avoid the step of pre-rendering to a raster video format.)
Describe the new feature: Add support for displaying, and animating, SVGs that use CSS for animation (JS optional for my use-case).
Describe the solution you'd like: The ability to add an animated SVG to a timeline and have that clip play the animation using native support. Length of the clip in the timeline is based on the length of the SVG animation properties.
Describe alternatives you have considered: Converting animated SVGs to other formats is rife with issues. Existing options do not offer smooth playback and are generally hacks such as converting to gif via screen recorders points at browsers, they almost always result in degraded visual quality as well.
Screenshots: (Optional) N/A