smart encoding

[alberto fuentes]

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.lover at 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 <evorster at 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 <pajaro at 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
>>
>