Speed and suitability for 1-sec everyday-style videos about editly

[mifi]

My experience is also that -ss both before and after -i is fast, so I don't understand why it's so slow for @umaar

[chapmanjacobd]

Slow trimming

I think it's definitely possible to use -ss -i -ss to quickly seek to let's say 4 seconds "before" (I guess ffmpeg seeks backwards and doesn't reverse if go too far) the calculated target duration (lossless), then slowly seek with keyframe accuracy (re-encode). but I'm not sure. maybe we would need to do a fast cut for the bulk of the clip and then do a re-encode for the start and end of the clip, (then concat those parts together...) It depends on the video codec and I'm not sure how ffmpeg handles this

related to: mifi/lossless-cut#126 which is related to mifi/lossless-cut#13

[mifi]

1. The reason why editly does scale all videos to the same size is because it has to be 100% sure of the output size (width x height x channels, rgba raw video out) when processing frames, or else it will lose sync in the data stream. It is also a technical impossibility to have multiple different resolutions in one video (afaik).

2. how big is the output resolution of your project? and how slow is it? there are probably some performance optimizations that can be done in the way I handle raw frames, and in fabric.js (which is used to overlay and draw text), but I'm not sure where is the bottleneck

3. Seeking should not be very slow, because it is using a fast seek (-ss ... -i ...) which AFAIK is now also accurate and fast at the same time. How long does it take to seek before it starts producing frames? (--verbose)

Out of curiosity, are you specifying duration of your video clips? if you are, that possibly means the clips are being sped up, which can slow things down.

[chapmanjacobd]

I think most of these comments aren't about editly specifically but about how we are handling ffmpeg which would help the video-everyday project.

Fast and accurate should be possible

https://superuser.com/a/704118/76968

Edit: hmmmm

https://www.reddit.com/r/ffmpeg/comments/aq98eu/help_frame_accurate_keyframe_seek_with_stream_copy/

Looks like the behavior changed in the last few years:

When used as an input option (before -i), seeks in this input file to position. Note that in most formats it is not possible to seek exactly, so ffmpeg will seek to the closest seek point before position. When transcoding and -accurate_seek is enabled (the default), this extra segment between the seek point and position will be decoded and discarded. When doing stream copy or when -noaccurate_seek is used, it will be preserved.
When used as an output option (before an output filename), decodes but discards input until the timestamps reach position.

So moving the -ss shouldn't make any difference

Maybe accurate seeking is just not possible in actuality. "in most formats it is not possible to seek exactly"

[umaar]

Thanks for chiming in anyway! After some research it seems that a big reason is just the videos are so large, they are 4K videos for example. Other professional video editing tools use hardware acceleration which is why it appears faster when using them.