It is a common use case. Ive done a lot of screen capturing (think of 10+ of final video a week), where the only editorial work was to remove the idle time and rerecord faulty parts and replace them in-place
Also, the link to the guy on reddit asking for a linux editor with this feature, and also the commercial software offering it as a killer feature :) I started doing this editorial work until I noticed that it took about 2h rendering per 1h of rendered video. Just too much to be worth my time. I just left most of the videos unedited in the end because often I needed the videos soon after I didnt know about creating render scripts to be launched at night, so I dont know if I would had done it in the end The guy in the reddit link is also more concern about final quality (no reencoding) than speed. So I dont know I could chose the encoding, so I would had used a codec with this feature, if its not possible to do it with all of them :) That said, kdenlive have lots of other things to be worked on, so I just mentioned in the mailing list. Maybe its very easy to implement and it can become a distinctive feature for kdenlive :) On Fri, Sep 29, 2017 at 12:14 AM, alcinos <french.ebook.lo...@gmail.com> wrote: > Hi, > > So in theory that should indeed be possible but this is quite tricky to do > it properly IMHO. Firstly, the method depends on the codec of the stream. As > Evert mentionned, for a h264 stream we have to re-encode up to the next > i-frame, that could be far away. For Codec where frames all depend on the > previous one, we have to basically reencode everything. Anyways, dealing > with all the codec is a lot of work. > Besides, it requires a very low level access to the stream that we don't > have easily from kdenlive, since we rely on several layers of abstraction. > > Finally, I'd be curious to know if this is actually a common usecase. It > seems a bit unlikely that someone don't want to apply any > transition/effects/reencoding at all. > > > 2017-09-28 13:38 GMT+02:00 Evert Vorster <evors...@gmail.com>: >> >> Hi there... >> >> Hmm, only re-encoding the frames that change? >> So, re-encode only up to the next I-frame on a transition, and then just >> copy the stream until the next change.... >> sounds awesome, especially if you are not adding overlays and messing with >> the colors of the footage. >> This could really speed up some workflows. >> >> -Evert- >> >> >> >> On 28 September 2017 at 12:57, alberto fuentes <paj...@gmail.com> wrote: >>> >>> I know, I know >>> >>> Double the features and half the crashes! Im not even opening a >>> wishlist bug for this one, just a random idea! >>> >>> Heres a guy asking for smart encoding. It could be one of those >>> features for amateur users that sets you apart ;) >>> >>> >>> https://www.reddit.com/r/linux4noobs/comments/72xrw4/trimjoin_videos_while_preserving_full_quality/ >>> >>> My first reaction was that you always have to reencode always >>> >>> But they claim in their web that they can do it >>> >>> http://www.solveigmm.com/en/products/video-splitter/ >>> "For all media files smart editing, frame-accurate appoach is used. >>> SolveigMM advanced know-how technology keeps 99% of data and only >>> transcodes a few frames at the beginning and end of the video >>> segments, so files are processed fast and lossless" >>> >>> Cheers! >> >> >> >> >> -- >> Evert Vorster >> Isometrix Acquistion Superchief >> >