See, I noticed that when I just tried out 450p. It was definitely less smooth for me than 360p. I personally would rather use 360p. In my opinion, I think it’s worth it to also include 360p as an option. I think having 3 options for the video (360p, 450p and 720p) is best. 
Hi @KKnBB,
If I could cheekily add my support for this proposal as well… 
Another teeny weeny suggestion I have is to change “Pick Video Path” to “Pick Video Folder” because on first use I wondered whether to point to a folder or a video file.
The quality differences between 360p and 450p are so little, keeping both of them makes no much sense.
I reverse it back to 360p then. And adding h264 deblock in encoding to improve the quality a bit.
V1.101 Update:
Cosmetic change the text from “450p” to “360p” to pleasing the users 
Some other fixes.
BTW stop using your grandparents’ computer to do the video editing.
2 Likes
Thank you.
Oh, I have a pretty modern computer. 
It’s just that Shotcut hasn’t been optimized yet to solve performance lag. I hope that’s the top priority for 2020.
Thank you again for sharing this tool with all of us and improving on it. I like the latest name of it too. “final plus max”. 
@qubodup, you made a video sometime ago about doing a manual proxy workflow to help with lag. Take a look at KKnBB’s great tool here and test it for yourself. If you like it then feel free to make a video on it so that other people out there can use it too until Shotcut gets its official proxy workflow up and running.
“360p Butter Smooth Small file”, “720p Bigger File for Bigger Dreams” - fantastic, made me smile 
. Thank you @KKnBB 
LOL- in 1986, when I was 27, I bought my first computer - an Atari 520ST. Guess what - it had no hard drive. You booted it up with floppy disks which had a capacity of 720 Kb (yes, kilobytes, not even Mb). I hooked it up (via MIDI leads) to a synth and bought C-Lab “Notator” software (which eventually became Logic, many many years later). I did some cool music sequencing with it, and had drawer-fulls of floppies with my music stuff stored on. Later, capacity of floppy discs became a massive 1.44Mb! You would need 711 of these to get up to 1Gb… 
And it got a spring-loaded metal cover! That’s nuts!
Amazing! Much needed!
I find something interesting.
I imported a mpeg2 video (normal mpg2, not I-frame only), and find it super smooth in Shotcut editing.
So I did a broad range of tests on many lossy codecs, surprisingly the winner is:
mpeg4 part2 (aka Xvid).
For videos encoded to the same quality:
-
Encoding Speed:
Mpeg2 > Xvid > H264 I-frame -
Smoothness (frame jump test, reverse play test):
Xvid > Mpeg2 = H264 I-frame -
File Size (smaller is better)
Xvid < Mpeg2 < H264 I-frame
The h264 filesize is much larger because it is i-frame-only encoded; Other codecs were using the normal profile.
I am not sure why the mpeg2/Xvid don’t require the GOP=1 to be frame-by-frame smooth;
And in theory, the mpeg2 (an older and less CPU intensive codec) should be faster than Xvid. But no, Xvid won them all regarding the smoothness.
@shotcut You may find this useful. Consider using mpeg4 part2 instead of h264 as the “edit-friendly” and “proxy” codec. It converts faster, the file uses only 1/3 size of i-frame-only H264, and it is lag-free.
I will update my proxy tool using Xvid soon.
Looks very interesting! What settings did you use for qscale and GOP in the comparison? Was this the -c:v libxvid or -c:v mpeg4 encoder?
@Austin I used the mpeg4 codec, as the true xvid/divx is not container friendly. The GOP is ffmpeg codec default setting no change, for mpeg-4 I measured it is somewhere around 12~15.
I used the qscale:8 (range 2~31) vs. h264 crf:15 (range 0~51). I picked these quality number very carefully by doing frame-by-brame zoom in visual checks and comparisons.
1 Like
Cool, thanks for the info. I got curious after your earlier post and did some playing around, which I have now repeated with the parameters you just provided. I noticed the following points and wondered if your experience was the same:
-
At 360p resolution, I found libxvid to give noticeably better visual quality (less macroblocking) than the mpeg4 encoder, especially in dark areas. My observations were on a 1440p monitor being used as a full-screen external display. I didn’t have any container problems using Matroska provided the FFmpeg version is 4.2.1 or greater.
-
By eliminating B-frames, scrubbing the timeline particularly in reverse had faster preview response and less CPU overhead than allowing B-frames, especially when stacking multiple tracks.
I wondered if you had similar observations or if this was unique to my computer. Here is the FFmpeg command I used for testing, using your parameters:
ffmpeg -i Input.mp4 -vf scale=w=-2:h=360:flags=bicubic+accurate_rnd+full_chroma_inp+full_chroma_int -colorspace bt709 -c:v libxvid -vtag xvid -g 15 -bf 0 -qscale:v 8 -c:a copy -f matroska Output.mkv
I fully agree that xvid is a much powerful encoder, but sadly it comes with speed penalty.
For me xvid is 50% slower than mpeg4, for some other peoples’ computers:
One of the purposes of this little tool is for fast editing job, meaning I recorded 1 hour long videos today, make proxy in 5 minutes, cut/edit it for 10 minutes, click “export” then go to bed.
Doubling the conversion time is not acceptable. I would prefer to drop qscale even lower for some quality, instead of waiting much longer with xvid codec.
(And this tool support mov, m4v, mp4 formats, like .mov => smaller mov etc… Mpeg-4 well fits in all those containers, but xvid is a wild kid that only mkv can tame)
mpeg4 simple profile (SP) has no b-frames, ease of mind. GOP5 is smoother than default GOP~15 when the resolutions are high (I tested in FHD), so I consider to add that to the line. But it will make still image videos(eg. animes) 3 times larger in file size.
Very interesting and useful scale flags. Will use them. Learn something new every day.
This is an important point to keep in mind for the development of Shotcut’s official proxy generator. Or maybe it’s already been factored in.
Whatever options for proxy file types are going to be made available, among them should be at least one that would be fast to crank out. Some people want higher quality proxy files which would take longer to make and they don’t mind waiting. But some others don’t really care for higher quality proxies because they figure they already know what their footage looks like. They just want there to be little to no latency during editing and they want to get to it as soon as possible.
Interesting, that’s why I checked with your experience. On my computer, xvid and mpeg4 take the exact same amount of time. If some computers don’t like xvid as well, then the rationale for mpeg4 makes total sense.
Is it possible your system has some form of hardware acceleration that xvid can use that’s missing from his? QuickSync and Cuda both jump to mind.
Possibly, in terms of instruction set coverage rather than hardware acceleration. I’ve got dual-socket Xeons, but no QuickSync. No CUDA or GPU to speak of either, and I didn’t use -hwaccels with FFmpeg so it probably wouldn’t have used them anyway.
If they’re late enough model xeon’s AVX has been used in some media encoders to great effect but has varied support on consumer chips especially older ones.
In today’s view, both mpeg4-2 and xvid are super fast codecs (comparing to h264, h265, vp9), it is easy to hit 10x~20x conversion speed, and disk reading or some other concealed things became the bottleneck.
agreed, i’ve used shotcut to measure disk performance differences before as well. but if one is twice as fast on one system but equal on the other my first hunch would be a cpu instruction or other hardware acceleration, AVX/AVX2/AVX512 all have been shown to accelerate various codecs(although h264/265 are usually the ones used to demonstrate such things)