-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jerking video when smoothing with pan #88
Comments
Can it be that these shaky bits near the boundaries come from the lens distortion? Fisheye lenses and other wide-angle lenses create a non-linear transformation that becomes strongly visible when translating the image. Can you tell me what you did on the manual/external manipulation of the transforms to get better results. Because from what I understand this should not really help. |
Thank you for the your quick reply!
Indeed the camera has quite a wide angle. I did some test with higher smoothing, but it appears that smoothing is actually the cause. Here are the videos (and the original transforms) and the parameters for a short clip in which jerking is clearly visible due to a 'panning' movement, when the city landscape is framed. But a little it is also visible on the sides, when going forward (e.g. the bus shelter on the right in the first second), and also when camera is moved quickier. Actually in general, for regular forward movement, less shaky sections are worst in the stabilized that the original due to this effect (I could give an example for this also).
I will surely try that. Should I use
I just did a moving average on dx and dy of the .trf file. The improvement in jerking is anyway not so much (and I guess also the detection is somehow limited in that old transcode version so overall it is not so improved) and I would say it is actually a non-go. Anyway it seemed like at regular intervals the transform values for dx and dy regularly drop to zero every few frames. I do not now if that is intended and if it occurs in the (newer version) trf file of the clip above. |
The results are indeed not satisfying. I think it is really the detection that does not work well. You can also run the transform step with debug=1, then you get the original transform file, see https://ffmpeg.org/ffmpeg-filters.html#vidstabtransform-1. |
I added a new folder There is also an image with the plot of dx and dy. Indeed every 6 frames (or 0.1 seconds) all the global transforms drop to zero. Actually having a closer look at the original "local motions" As a test I opened and modified (with some external piece of code) the global tranforms so that each time they are zero they are replaced by the average values of the previous and the next frame. The resulting transform is |
Indeed a very good observation and a good fix. I need to add this postprocessing in the transform phase to check for those "missing" frame information. The video does not look so complicated to me, so I need to check why these frames are not detected. |
I do not think either it is a problem of the particular movie 'appearance'. Indeed the 'missing' frames are regularly distributed as if it would be some glitch in the computation (in this case every 6 frames, or 100 ms as the movie is 60fps). |
The original video repeats each 5th frame(each 6th frame is identical to 5th). Or it could be an internal bug of the camera. Both 50 and 60 FPS standards exist historically due to two main TV standards in the world: PAL(50) and NTSC(60, USA and some others). Old TV boxes depended on power grid frequency of a country, that's why the difference. Another strange thing about the video - too dark shades. But that's completely different story. People around the world often have no idea that their original videos from cameras may contain additional details in dark and bright colors, but they are not shown even in videoplayers. It also was caused by some earlier legacy TV standard requirements, to narrow color signal levels. |
Main fatal mistake is to use *.mov format. Best format for per-frame editing and transcoding without quality loss is h264.
-crf 16 is an option for libx264 codec, "constant rate factor", at 16 it gives visually "lossless" quality of transcoding.
It has dropped several starting frames to align the video for the select filter that drops each 6th duplicate frame. Video becomes 50fps again so the output's framerate must be adjusted by
Libvidstab still can't handle that panning part perfectly. Because it's a perspective panning, when objects at different distances move with different speeds. To deal with "perspective panning", some user interface must be developed where user would click on boxes to disable them or to edit some parameters. That would be a different software by definition. |
Hi Georg,
firstly thank you for this great library!
I am trying to best stabilize cycling videos, similarly to what you reported in here, with the latest version of vidstab+ffmpeg (and also tried with the older transcode version).
Without smoothing during transform, the overall stabilization is clearly a little poor. With smoothing, on the other hand, the overall stabilization is great, but I got a jerking effect on the fast moving parts of the frame near the edges (where there is more 'pan' than 'forward' movement), so that in these regions the less shaked parts of the original are actually better.
I partly overcame this effect by using older vidstab in transcode (in which .trf are in the older, more comprehensible format) and then smoothing the trajectory in the .trf file (with an external piece of code) before applying the transform. The overall result is better concerning jerking, but not much concerning stabilization. I guess the new version of vidstab, which uses the new transform file format (with local motions lists), is better in detecting shakiness, but, on the other hand, I am not able not understand the new .trf file and thus perform some stuff on it.
I wanted to know if I am doing something wrong and also which parameters did you use to best deshake the movie above (as in that video you do not have any jerking even in the panning part)?
Thanks!
The text was updated successfully, but these errors were encountered: