Stabilization - Export doesn't match player

Bug
1

What is your operating system?
Intel(R) Core™ i7-2820QM CPU @ 2.30GHz 2.30 GHz
16.0 GB (15.9 GB usable)
Windows 10 Pro
64-bit operating system, x64-based processor

What is your Shotcut version (see Help > About Shotcut)?
Both 22.06.23 and 22.12.21

Can you repeat the problem? If so, what are the steps?
(Please be specific and use the names as seen in Shotcut, preferably English. Include a screenshot or screen recording if you can. Also, you can attach logs from either View > Application Log or right-click a job and choose View Log.)
I’m having an issue exporting a stabilized GoPro video from Shotcut. The video properties are 2704x1520, 29.97 fps, type MP4.

Steps:
Add video to timeline (it’s only video in the timeline)
Add stabilize filter
Analyze
Export

The strange thing is…the video looks great in the player but always exports with very little to no stabilization. I’ve doubled (triple and quadruple) checked the export resolution and fps match the source) I make zero modifications to the timeline between analyzing and exporting. I’ve tried exporting from the timeline, playlist, and source (I know the source would not have stabilization but I did it anyways).

I understand the player, timeline, and source are all different sources of the video. I see no way to select the player as the source of the export in the versions of Shotcut I’ve tried…the only options I see are timeline, source, and playlist (if I have it visible).

Any help would be greatly appreciated. Again…the stabilized video in the player looks great but every method I try to export results in an unstabilized video.

2

I am using the normal stabilize filter with following settings:
Shakiness 6, you have to lower and reanalyze this if the output video start vibrating
Accuracy 15, needs more analyze time
Smoothing zoom / crop to compensate the shaking, I also set this in the beginning to 100% and if the crop is too much, I reducing it!
My method takes a lot of time but it pays off!

3

Thanks for the reply. I tried your settings…as well as many, many more combinations of settings. Unfortunately the result is always the same.

The motion in the original Gopro video is not normal motion. The motion is a high rate of jerkiness or sputtering. I think the original file is corrupt in some manner. Converterlite tells me the codec is h265, while Shotcut tells me it’s h264.

The issue I have is: after adding the stabilize filter and analyzing the file, the player seems to have corrected the jerky motion as desired. Shotcut was able to figure out a way to remove the undesirable sputtering and produce a smooth video in the player. The problem I have is I have not found a way to export a video that matches the player. Everything I try produces the same results…the sputtering returns in the exported video.

At this point it’s become very frustrating.

4

The stabilization is working fine for me even with GoPro videos, even though all my cameras include stabilization.

That suggests to me that you turned on proxy mode in Shotcut. You should try turning that off to see if it makes a difference. However, Shotcut does automatically revert to using the source media file when doing stabilization. I do not know what your problem is, but if proxy (and preview scaling?) is on the player is naturally going to look a lot different when viewing through those different lenses. You cannot reliably compare.

5

Right click the export job and view the log. Somewhere in the middle (or near end before the job finishes) it should show something like

[filter vidstab] Load results from /home/ddennedy/Videos/tests/test.stab
[filter vidstab] Successfully loaded 993 motions
[vidstab] Final zoom: 2.821625
6

Thank you very much for the reply!!!

First, I can confirm that proxy was turned OFF. I did have preview scaling turned on and set to 720p. However, when I turn preview scaling off I get the same results: the player shows a very stable, non-jittery video. With preview scaling turned OFF I re-exported the file and again got the same results: the exported file is nothing like the player and displays extreme jitteryness (if that is a word :smile:

Per your request, the log file (from the last export with preview scaling OFF) shows:

[filter vidstab] Load results from C:/Users/JPI-PC/Data/GoPro/Temp-Fishing/Temp/2023_Weekend_1_July/Short_Stab_Bass.stab

[filter vidstab] Successfully loaded 5208 motions

[vidstab] Final zoom: 11.353381

Ugh.

7

P.S. Yes…Shotcut handles all other GoPro videos I’ve used (and there have been hundreds) great. I’m running three Hero9 cameras…all have hypersmooth turned on and all have the Max Lens Mod attached. Normally with this configuration I have no need to have Shotcut stabilize a video. But in this particular case, one of the GoPro videos seems to have been corrupted during recording. Motion is stop / start to the extreme. Originally I thought using that particular file was a lost cause…but then I tried using the Stabilize filter in Shotcut and it seemed to work (in the player). I thought it was a miracle. The problem (for me) is I can’t get Shotcut to export a video with the stabilization results that match the player.

8

If it helps…here is the entire log of the last export attempt (with preview scaling OFF):

[libx264 @ 0000018dea5ad780] using SAR=1/1
[libx264 @ 0000018dea5ad780] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
[h264 @ 0000018dea5aca00] Reinit context to 2704x1520, pix_fmt: yuv420p
[libx264 @ 0000018dea5ad780] profile High, level 5.0, 4:2:0, 8-bit
[libx264 @ 0000018dea5ad780] 264 - core 164 r3094M bfc87b7 - H.264/MPEG-4 AVC codec - Copyleft 2003-2022 - x264, the best H.264/AVC encoder - VideoLAN - options: cabac=1 ref=2 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=6 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=1 keyint=150 keyint_min=15 scenecut=40 intra_refresh=0 rc_lookahead=30 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
[h264 @ 0000018d8aa901c0] Reinit context to 2704x1520, pix_fmt: yuv420p
[h264 @ 0000018deaae8f40] Reinit context to 2704x1520, pix_fmt: yuv420p
[producer avformat] audio: total_streams 1 max_stream 1 total_channels 2 max_channels 2
[AVIOContext @ 0000018dea549740] Statistics: 583796 bytes read, 0 seeks
[chain avformat-novalidate] C:/Users/JPI-PC/Data/GoPro/Temp-Fishing/Temp/2023_Weekend_1_July/ShortBass_Unstable.mp4
checking VFR: pkt.duration 1001
[h264 @ 0000018dea5adb80] Reinit context to 2704x1520, pix_fmt: yuv420p
[filter vidstab] Load results from C:/Users/JPI-PC/Data/GoPro/Temp-Fishing/Temp/2023_Weekend_1_July/Short_Stab_Bass.stab
[filter vidstab] Successfully loaded 5208 motions
[vidstab] Final zoom: 11.353381
[chain avformat-novalidate] C:/Users/JPI-PC/Data/GoPro/Temp-Fishing/Temp/2023_Weekend_1_July/ShortBass_Unstable.mp4
WILD TIMESTAMP: pkt.pts=[-9223372036854775808], pkt.dts=[-9223372036854775808], req_position=[5197], current_position=[5196], int_position=[0], pts=[-9223372036854775808]
[chain avformat-novalidate] C:/Users/JPI-PC/Data/GoPro/Temp-Fishing/Temp/2023_Weekend_1_July/ShortBass_Unstable.mp4
WILD TIMESTAMP: pkt.pts=[-9223372036854775808], pkt.dts=[-9223372036854775808], req_position=[5198], current_position=[5197], int_position=[0], pts=[-9223372036854775808]
[chain avformat-novalidate] C:/Users/JPI-PC/Data/GoPro/Temp-Fishing/Temp/2023_Weekend_1_July/ShortBass_Unstable.mp4
WILD TIMESTAMP: pkt.pts=[-9223372036854775808], pkt.dts=[-9223372036854775808], req_position=[5199], current_position=[5198], int_position=[0], pts=[-9223372036854775808]
[chain avformat-novalidate] C:/Users/JPI-PC/Data/GoPro/Temp-Fishing/Temp/2023_Weekend_1_July/ShortBass_Unstable.mp4
WILD TIMESTAMP: pkt.pts=[-9223372036854775808], pkt.dts=[-9223372036854775808], req_position=[5200], current_position=[5199], int_position=[0], pts=[-9223372036854775808]
[chain avformat-novalidate] C:/Users/JPI-PC/Data/GoPro/Temp-Fishing/Temp/2023_Weekend_1_July/ShortBass_Unstable.mp4
WILD TIMESTAMP: pkt.pts=[-9223372036854775808], pkt.dts=[-9223372036854775808], req_position=[5201], current_position=[5200], int_position=[0], pts=[-9223372036854775808]
[chain avformat-novalidate] C:/Users/JPI-PC/Data/GoPro/Temp-Fishing/Temp/2023_Weekend_1_July/ShortBass_Unstable.mp4
WILD TIMESTAMP: pkt.pts=[-9223372036854775808], pkt.dts=[-9223372036854775808], req_position=[5202], current_position=[5201], int_position=[0], pts=[-9223372036854775808]
[chain avformat-novalidate] C:/Users/JPI-PC/Data/GoPro/Temp-Fishing/Temp/2023_Weekend_1_July/ShortBass_Unstable.mp4
WILD TIMESTAMP: pkt.pts=[-9223372036854775808], pkt.dts=[-9223372036854775808], req_position=[5203], current_position=[5202], int_position=[0], pts=[-9223372036854775808]
[chain avformat-novalidate] C:/Users/JPI-PC/Data/GoPro/Temp-Fishing/Temp/2023_Weekend_1_July/ShortBass_Unstable.mp4
WILD TIMESTAMP: pkt.pts=[-9223372036854775808], pkt.dts=[-9223372036854775808], req_position=[5204], current_position=[5203], int_position=[0], pts=[-9223372036854775808]
[chain avformat-novalidate] C:/Users/JPI-PC/Data/GoPro/Temp-Fishing/Temp/2023_Weekend_1_July/ShortBass_Unstable.mp4
WILD TIMESTAMP: pkt.pts=[-9223372036854775808], pkt.dts=[-9223372036854775808], req_position=[5205], current_position=[5204], int_position=[0], pts=[-9223372036854775808]
[chain avformat-novalidate] C:/Users/JPI-PC/Data/GoPro/Temp-Fishing/Temp/2023_Weekend_1_July/ShortBass_Unstable.mp4
WILD TIMESTAMP: pkt.pts=[-9223372036854775808], pkt.dts=[-9223372036854775808], req_position=[5206], current_position=[5205], int_position=[0], pts=[-9223372036854775808]
[chain avformat-novalidate] C:/Users/JPI-PC/Data/GoPro/Temp-Fishing/Temp/2023_Weekend_1_July/ShortBass_Unstable.mp4
WILD TIMESTAMP: pkt.pts=[-9223372036854775808], pkt.dts=[-9223372036854775808], req_position=[5207], current_position=[5206], int_position=[0], pts=[-9223372036854775808]

[mp4 @ 0000018dea5ac2c0] Timestamps are unset in a packet for stream 1. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[mp4 @ 0000018dea5ac2c0] Encoder did not produce proper pts, making some up.
[mp4 @ 0000018dea5ac2c0] Starting second pass: moving the moov atom to the beginning of the file
[AVIOContext @ 0000018d99f2bdc0] Statistics: 295103678 bytes read, 0 seeks
[libx264 @ 0000018dea5ad780] frame I:39 Avg QP:20.69 size:223926
[libx264 @ 0000018dea5ad780] frame P:1378 Avg QP:23.55 size: 88821
[libx264 @ 0000018dea5ad780] frame B:3791 Avg QP:25.16 size: 41435
[libx264 @ 0000018dea5ad780] consecutive B-frames: 1.1% 3.1% 7.4% 88.4%
[libx264 @ 0000018dea5ad780] mb I I16…4: 17.0% 67.5% 15.5%
[libx264 @ 0000018dea5ad780] mb P I16…4: 10.4% 17.8% 1.8% P16…4: 39.1% 15.2% 6.5% 0.0% 0.0% skip: 9.2%
[libx264 @ 0000018dea5ad780] mb B I16…4: 9.7% 7.5% 1.2% B16…8: 32.5% 9.5% 0.5% direct:14.8% skip:24.2% L0:43.4% L1:51.7% BI: 4.9%
[libx264 @ 0000018dea5ad780] 8x8 transform intra:48.4% inter:57.8%
[libx264 @ 0000018dea5ad780] coded y,uvDC,uvAC intra: 29.8% 41.4% 4.2% inter: 16.7% 32.1% 0.2%
[libx264 @ 0000018dea5ad780] i16 v,h,dc,p: 31% 35% 16% 18%
[libx264 @ 0000018dea5ad780] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 22% 29% 5% 5% 5% 6% 4% 5%
[libx264 @ 0000018dea5ad780] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 18% 16% 7% 9% 9% 9% 7% 7%
[libx264 @ 0000018dea5ad780] i8c dc,h,v,p: 65% 17% 16% 2%
[libx264 @ 0000018dea5ad780] Weighted P-Frames: Y:6.3% UV:2.8%
[libx264 @ 0000018dea5ad780] ref P L0: 64.5% 35.5%
[libx264 @ 0000018dea5ad780] ref B L0: 75.2% 24.8%
[libx264 @ 0000018dea5ad780] ref B L1: 91.8% 8.2%
[libx264 @ 0000018dea5ad780] kb/s:13268.24
[aac @ 0000018dea5af440] Qavg: 60768.590
[AVIOContext @ 0000018d8aa8fa40] Statistics: 590283154 bytes written, 4 seeks, 2255 writeouts
Completed successfully in 00:19:40

9

turn the b-frames to 0 in export advanced settings

10

Thanks for the response!

I will give that a try.

Also…I found something that might provide a clue. If I turn “Realtime (frame dropping)” OFF in the Player settings then the playback in the Player again shows the extreme jitters (I leave the Stabilize filter turned on with a stabilization file in use).

If I turn the “Realtime (frame dropping)” back ON then the playback in the Player again eliminates the extreme jitters and shows a very stable video (again with the Stabilize filter turned on with a stabilization file in use).

11

Unfortunately…setting b-frames to 0 did not change the outcome. The exported video still exhibits the extreme jitters.

12

That also turns on parallel processing at the video frame level. Therefore, try turning off Export > Advanced > Video > Parallel Processing.

13

Throughout this entire process, every time I export a video the Export > Advanced > Video > Parallel Processing option has been disabled (not selected).

:disappointed:

I just noted that selecting or deselecting the Realtime option seems to effect the Player playback. Realtime On is a stable video in the player. Realtime OFF is a non-stable video in the player.

Nothing I’ve done so far has been able to export a stable video that matches the stable video I can watch in the player.

14

Just for the sake of being thorough, I turned Parallel Processing ON in the Export > Advanced > Video option (something I haven’t tested yet) and the results didn’t change. The exported video is still extremely jittery.

15

Maybe because of the reduced viewing settings you cannot see the shakiness in Shotcut. If the shakiness is in a high frequency and has very persistent an low altitude the shakiness factor need to be reduced and the hole needs to be reanalysed.

16

Try this test:

  • Export a non-stabilized and non-edited version of the video, putting all the clips in sequence with your “cuts”. Export parameter: “youtube” , mp4, resolution 4K (select it from the dropdown a resolution even greater to your clips) and codec libx264 (default), with “Quality” 45 (is enough).
  • if you get a video…
  • Now that you have a standard video file, do every editing you want, including stabilization. This is just to avoid any corruption of any clip.
  • Re-export again the video file (of course there is some data-loss due to double export, but insignificant in my opinion on actual gopro resolutions).
  • stabilization: first 2 bar to the bottom. no zoom. use smoothness.
    stab

ciao

17

Thanks for the reply and suggestion.

The shakiness is blatantly obvious while viewing the video within Shotcut. The undesirable motion is not what one would consider normal camera shakiness where the entire frame moves around. The undesirable motion appears due to a file corruption. It’s difficult to explain, but I’ll try:

The frame of video is not moving around but any motion within the frame is sputtering. Imagine a camera mounted on a fixed tripod and a video of a car driving from frame-left to frame-right. The video looks like the car drives 2 feet right, 1 foot left, 2 feet right, 1 foot left, etc…across the entire frame.

I’ve tried a great many Stabilize setting combinations and they all produce the same result: a video that is obviously greatly improved in the player but exhibits the original sputtering when exported.

18

Thanks for the suggestion.

Exporting a non-stabilized, non-edited version of the video in a standard resolution (4k, 1080p, etc.) and then stabilizing the exported results later is something I tried very early in the process. Unfortunately doing that did not change the results.

The player is displaying the video in some fashion that is different to the export. If I could export the player results I’d be very happy…but that seems impossible at the moment.

19

very strange things yours…

  • download a portable version of shotcut
  • update your graphic video card driver from the constructor website
  • try again

if your pc is new, update all driver audio/video before trying any test.

another OFF TOPIC suggestion (entirely external to shotcut):
Gopro degrade the stabilization in order to sell new version of gopro. Be sure you check , for your hero9, to verify if stabilization works. I had very heavy problem of stabilization with my gopro hero 8 black, and solved like this: Gopro Hero 8 Black - Firmware 1.50 vs 2.50 (Stabilization Test and Errors) - YouTube
Be sure to understand the risk of updating firmwares, but I’ve never seen anything that gopro with hypersmooth high couldn’t stabilize
be careful but check - I think that Gopro 9 firmware 1.50 is better than the rest (I’ve seen video on youtube about this), but I have an 8 and I don’t remember so well…

20

Thanks for the suggestions.

I normally have zero problems with Shotcut or my GoPros. I record and process 600gb of video every weekend. It’s just that something strange happened to 1 of my 3 cameras on this particular day.

After a lot more investigation I think I know better what is going on…and a semi-workable workaround. A friend extracted the frames from the suspect gopro vid. When paging thru the frames in a photo viewer it appeared frames were out of order (i.e. straight motion was interrupted…frames would start the motion, go backwards for a frame, go forwards again, and repeat this cycle until the end of the motion).

About the same time I noticed the player would skip frames during playback (like after I ran a stabilize analysis)…displaying every 9th (or so) frame. The player was essentially skipping many of the frames during playback that caused the jerky motion. Once I saw the skipping of frames during playback I stopped the playback and stepped the player frame by frame. At that point I was able to see the frames causing jerky motion still existed. So the stabilization really didn’t fix the problem…and exported videos were just playing at a higher frame rate then the player.

The only workaround that seems to work for me is to export the video with an extremely low frame rate. 10fps per second results in an exported video that eliminates the jerky motion while still preserving the HD quality of the gopro (as opposed to using one of the LRV files…which by the way…do not exhibit any jerky motion).

Thanks everyone for all the help!