Update Suggestions For 2 Export Presets

[pdr]

@Austin

ffmpeg itself is the only convenient tool I have for testing this. I lifted a section of video from the 50 minute MKV transcode I made earlier:

ffmpeg -ss 00:45:00.000 -i BigHugeVideo.mkv -t 10 -c copy [output file stuff here]

The ffmpeg command acted just like the Shotcut preview player… a very long pause (40+ seconds) before transcoding began. So ffmpeg appears to be the bulk of the problem.

Was the original 50min MKV a “fresh”, non cut MKV ?

FFmpeg can have various issues when cutting, especially with a non zero start time. The timestamps can get messed up . You might have to reset the PTS

-ss before the -i as an input option is supposed to be slower, because it’s starting from the beginning, decoding frame linearly in order . It’s supposed to be more accurate (but it’s not always accurate either.) The cut points depend on where IDR frames are placed. (But in the case of huffyuv or ut, every frame is a keyframe, so a non issue in this specific scenario) . If you use -ss after the -i it should be faster, because it jumps right to the the nearest recovery point .

But ffmpeg stream copying is not necessarily indicative of performance in a ffmpeg based editing framework. I’m wondering if other ffmpeg based software experience similar issues here - such as kdenlive, cinelerra, blender etc… What about non MLT based NLE’s ?

@Austin

I further think it is specific to MOV in MKV. As a total last ditch resort, I transcoded the 50 minute video to VP8 in WebM in Matroska. The VP8 file loaded instantly and seeks instantly. So apparently the Matroska format works fine with WebM. But DNxHR, HuffYUV, and Ut Video do not work in Matroska, and the MOV container is the common thread.

I took the 50 minute DNxHR-in-MOV transcode I made earlier and -c copy-ied it into Matroska. The original MOV worked brilliantly, so maybe slipping it pre-built into Matroska would retain its performance. Nope. It was right back to slowness once in the MKV. I wonder if the Matroska muxer is trying to read/write the MOV itself, or if it’s doing a handoff to the “real” MOV muxer in ffmpeg and the handoff is slow.

You would expect VP8/9 to act ok in MKV, because that’s it’s native container (WEBM is essentially MKV)

Similarly, you would expect DNxHR to act ok in native MOV or MXF, because those are it’s native containers - but not necessarily MKV, or some MOV in MKV hybrid . Same idea with huffyuv and utvideo - they were originally VFW based codecs, so operated in the AVI container

There might be specific compatibility issues with codec/container combinations at play here

@Austin

I’m familiar with mkvmerge in concept, but not enough to do serious work. This would be a brief science project for me that I’d have to attempt a little later. The difficult part is that small MKV files load and play just fine. The performance drop-off increases drastically as a function of video length, meaning it takes a 30+ minute video to really notice there’s a problem in the first place. Once the video gets to 50+ minutes, the performance dramatically gets worse. So every change of settings requires a 30+ minute transcode to really know if there was an improvement or not.

You can use mkvtoolnix (GUI for mkvmerge) just to remux one of your earlier test files as a quick test

Those are important testing observations that probably need to be eventually be passed to Moritz Bunkus (mkv author) , especially the 30 vs. 50 min.

Is something else going on, for example is shotcut or some process caching frames ?

@pdr

If shotcut could implement ffmpeg/libav GPU’s decoding

Dan has outlined what it would take to make this happen. It sounds complicated.

General question -- playback quality

Aren’t we all? Windows’ media player uses hardware-accelerated decoding but Shotcut does not. Hardware-accelerated decoding only makes sense when you can keep the entire processing pipeline in the GPU memory including all scaling, filters, and track blending and do the processing using GPU. Shotcut is not there yet because editing is so much more sophisticated that simple playback. It has some GPU Effects mode, but that is hidden due to bugs. Actually, FFmpeg and VLC does support hardware-acc…

Have you heard about the Cinegy GPU accelerated daniel2 codec? It’s available natively in Adobe PP . Native 8Kp60 editing at full resolution, using a laptop consumer CPU and GPU (Not even a quadro). It’s much faster than cineform/prores/DNxHD , which drop frames cannot come close to getting realtime . AFAIK, Adobe does not keep everything in the GPU memory (impossible for 8K on a laptop GPU anyways) . It would be wonderful if open source community could reverse engineer something similar , even a fraction of the performance.