GNOME Bugzilla – Bug 725853
Stacking frei0r video effects crashes
Last modified: 2014-03-11 16:09:55 UTC
Created attachment 271145 [details] backtrace when stacking two effects Project size is 1920x1080, and I'm trying my hardest to keep a 1280x760 clip from being scaled up automatically. I'd like to position that clip in the lower-right, offset from the bottom & right by 100px or so. So, I add frei0r-filter-c0rners to return the video to the original size, and also add videocrop to remove some black bars on the left & right which Pitivi insists on adding even though they are not in the original clip. The only thing I change on the effects is the "Right" option of videocrop, and then I get this crash: *** Error in `/usr/bin/python': free(): corrupted unsorted chunks: 0x00007fff94006c20 *** ======= Backtrace: ========= /lib64/libc.so.6[0x345ac75cff] /lib64/libc.so.6[0x345ac7cff8] /lib64/libpython2.7.so.1.0(PyThreadState_DeleteCurrent+0x26)[0x36c96fb296] /lib64/libgobject-2.0.so.0(g_object_ref+0xbf)[0x345e414cef] /lib64/libgstreamer-1.0.so.0(gst_object_ref+0x21)[0x3927829971] /lib64/libgstreamer-1.0.so.0(gst_object_get_parent+0x75)[0x392782a2d5] /lib64/libgstreamer-1.0.so.0[0x392782a406] /lib64/libgobject-2.0.so.0[0x345e414202] /lib64/libgobject-2.0.so.0(g_object_set_valist+0x31d)[0x345e417f4d] /lib64/libgobject-2.0.so.0(g_object_set+0x104)[0x345e418774] /lib64/libges-1.0.so.0(+0x4b13b)[0x7fffef31113b] /lib64/libgstreamer-1.0.so.0[0x39278600aa] /lib64/libglib-2.0.so.0(g_hook_list_marshal+0x84)[0x345d43a6d4] /lib64/libgstreamer-1.0.so.0[0x392782730a] /lib64/libgstreamer-1.0.so.0[0x392786249c] /lib64/libgstreamer-1.0.so.0(gst_proxy_pad_chain_default+0xbb)[0x3927853f9b] /lib64/libgstreamer-1.0.so.0[0x3927862138] /lib64/libgstbase-1.0.so.0[0x3927c346d7] /lib64/libgstreamer-1.0.so.0[0x3927862138] /lib64/libgstreamer-1.0.so.0(gst_proxy_pad_chain_default+0xbb)[0x3927853f9b] /lib64/libgstreamer-1.0.so.0[0x3927862138] /lib64/libgstreamer-1.0.so.0(gst_proxy_pad_chain_default+0xbb)[0x3927853f9b] /lib64/libgstreamer-1.0.so.0[0x3927862138] /lib64/libgstreamer-1.0.so.0(gst_proxy_pad_chain_default+0xbb)[0x3927853f9b] /lib64/libgstreamer-1.0.so.0[0x3927862138] /lib64/libgstreamer-1.0.so.0(gst_proxy_pad_chain_default+0xbb)[0x3927853f9b] /lib64/libgstreamer-1.0.so.0[0x3927862138] /lib64/libgstreamer-1.0.so.0(gst_proxy_pad_chain_default+0xbb)[0x3927853f9b] /lib64/libgstreamer-1.0.so.0[0x3927862138] /lib64/libgstbase-1.0.so.0[0x3927c346d7] /lib64/libgstreamer-1.0.so.0[0x3927862138] /lib64/libgstbase-1.0.so.0[0x3927c346d7] /lib64/libgstreamer-1.0.so.0[0x3927862138] /lib64/libgstbase-1.0.so.0[0x3927c346d7] /lib64/libgstreamer-1.0.so.0[0x3927862138] /lib64/libgstreamer-1.0.so.0(gst_proxy_pad_chain_default+0xbb)[0x3927853f9b] /lib64/libgstreamer-1.0.so.0[0x3927862138] /lib64/libgstreamer-1.0.so.0(gst_proxy_pad_chain_default+0xbb)[0x3927853f9b] /lib64/libgstreamer-1.0.so.0[0x3927862138] /lib64/libgstreamer-1.0.so.0(gst_proxy_pad_chain_default+0xbb)[0x3927853f9b] /lib64/libgstreamer-1.0.so.0[0x3927862138] /lib64/libgstreamer-1.0.so.0(gst_proxy_pad_chain_default+0xbb)[0x3927853f9b] /lib64/libgstreamer-1.0.so.0[0x3927862138] /lib64/libgstbase-1.0.so.0[0x3927c346d7] /lib64/libgstreamer-1.0.so.0[0x3927862138] /lib64/libgstbase-1.0.so.0[0x3927c346d7] /lib64/libgstreamer-1.0.so.0[0x3927862138] /lib64/libgstbase-1.0.so.0[0x3927c346d7] /lib64/libgstreamer-1.0.so.0[0x3927862138] /lib64/libgstreamer-1.0.so.0(gst_proxy_pad_chain_default+0xbb)[0x3927853f9b] /lib64/libgstreamer-1.0.so.0[0x3927862138] /lib64/libgstreamer-1.0.so.0(gst_proxy_pad_chain_default+0xbb)[0x3927853f9b] /lib64/libgstreamer-1.0.so.0[0x3927862138] /lib64/libgstreamer-1.0.so.0(gst_proxy_pad_chain_default+0xbb)[0x3927853f9b] /lib64/libgstreamer-1.0.so.0[0x3927862138] /lib64/libgstreamer-1.0.so.0(gst_proxy_pad_chain_default+0xbb)[0x3927853f9b] /lib64/libgstreamer-1.0.so.0[0x3927862138] /lib64/libgstbase-1.0.so.0[0x3927c346d7] /lib64/libgstreamer-1.0.so.0[0x3927862138] /usr/lib64/gstreamer-1.0/libgstvideorate.so(+0x422e)[0x7fffd81f922e] /lib64/libgstbase-1.0.so.0[0x3927c33d50] /lib64/libgstbase-1.0.so.0[0x3927c344c2] /lib64/libgstreamer-1.0.so.0[0x3927862138] I also see various valgrind issues like: ==16142== Invalid read of size 1 ==16142== at 0x345D4395F0: g_str_hash (ghash.c:1732) ==16142== by 0x345D43843B: g_hash_table_remove_internal (ghash.c:365) ==16142== by 0xEC0DB56: _free_pending_clip.isra.2 (ges-base-xml-formatter.c:532) ==16142== by 0xEC0E801: new_asset_cb (ges-base-xml-formatter.c:649) ==16142== by 0x3011A6F786: g_simple_async_result_complete (gsimpleasyncresult.c:777) ==16142== by 0x3011A6F7E8: complete_in_idle_cb (gsimpleasyncresult.c:789) ==16142== by 0x345D4492A5: g_main_context_dispatch (gmain.c:3066) ==16142== by 0x345D449627: g_main_context_iterate.isra.24 (gmain.c:3713) ==16142== by 0x345D449A39: g_main_loop_run (gmain.c:3907) ==16142== by 0x345DC05D8B: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.1) ==16142== by 0x345DC056BB: ffi_call (in /usr/lib64/libffi.so.6.0.1) ==16142== by 0x301B609E48: g_callable_info_invoke (in /usr/lib64/libgirepository-1.0.so.1.0.0) ==16142== Address 0x14ff4550 is 0 bytes inside a block of size 2 free'd ==16142== at 0x4A07577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==16142== by 0x345D44EF7E: g_free (gmem.c:197) ==16142== by 0xEC0DB13: _free_pending_clip.isra.2 (ges-base-xml-formatter.c:525) ==16142== by 0xEC0E801: new_asset_cb (ges-base-xml-formatter.c:649) ==16142== by 0x3011A6F786: g_simple_async_result_complete (gsimpleasyncresult.c:777) ==16142== by 0x3011A6F7E8: complete_in_idle_cb (gsimpleasyncresult.c:789) ==16142== by 0x345D4492A5: g_main_context_dispatch (gmain.c:3066) ==16142== by 0x345D449627: g_main_context_iterate.isra.24 (gmain.c:3713) ==16142== by 0x345D449A39: g_main_loop_run (gmain.c:3907) ==16142== by 0x345DC05D8B: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.1) ==16142== by 0x345DC056BB: ffi_call (in /usr/lib64/libffi.so.6.0.1) ==16142== by 0x301B609E48: g_callable_info_invoke (in /usr/lib64/libgirepository-1.0.so.1.0.0) I tried my hardest to reproduce the issue under valgrind, but I cannot because Pitivi won't allow me to drag clips to the timeline, printing this message instead: Traceback (most recent call last):
+ Trace 233281
self.timeline.convertGhostClips()
if ghostclip.shouldCreateLayer:
So unfortunately I can't get a better valgrind log about why the memory corruptuion happens when I stack the two effects.
Hi, thanks for your feedback! Can you share the project thanks to the export to tar functionality? We are going to reimplement the "transformation box" soon, which will allow you to do these scaling and positioning without having to use frei0r effects. With your project, this issue should be quite straightforward to fix.
So using thiblahute's latest pitivi package, I can get a backtrace.
Actually, the backtrace with the latest bundle is pretty much the same as the original backtrace:
+ Trace 233285
Exported project is at http://people.redhat.com/dcbw/nmcli.xges_tar.bz2 Open the clip, click on the video clip in the timeline (top one), then select Effects, click on videocrop, and then just try to increment any option. Note that the only reason I'm trying to use videocrop is that the Pitivi puts black bars on the left + right sides of the video clip, which aren't there in the source video.
AFAICT, the black bars are because you have not set your project resolution settings to match those of the footage you're using. The video resolution and aspect ratio will affect the appearance of the previewer. If you do not set the resolution and aspect ratio to match those of your footage, the video may look squished or letterboxed.
(In reply to comment #5) > AFAICT, the black bars are because you have not set your project resolution > settings to match those of the footage you're using. > > The video resolution and aspect ratio will affect the appearance of the > previewer. If you do not set the resolution and aspect ratio to match those of > your footage, the video may look squished or letterboxed. My project is targeted at 1920x1080. The clip I'm using is 1280x800, but this clip should *not* be scaled up to 1920x1080, it should remain 1280x800 and be positioned in the lower-left corner. It should not matter what the aspect ratio of the clip is, because it should not be scaled to match the project size, just embedded at a specific location at its normal size.
Created attachment 271262 [details] screenshot of what I want to do This is a screenshot of what I want to do. I don't really understand why the clip must be rescaled to match the entire project size when it's just going to be embedded in the overall video. The black bars on the sides of the clip require me to add a 'videoclip' effect to remove the bars, and that's what gets me into this segfault issue in GES, when I stack the videoclip (to remove the black bars) on top of the CORners plugin (to move the clip where I want it). If there was an option on the clip (like OpenShot has when you right-click on a clip in the timeline) to not scale the clip, but use it at native resolution (eg, smaller than the project), that would be great. I've tried to replicate that with the CORners effect, which sorta works, but requires a lot of fiddling to use. A simple "move and/or scale" effect would be awesome, because then I could simply leave the scaling at 1.0, and just offset the clip into the project where I want it. It's also confusing and imprecise with the current 0.0 - 1.0 positioning, because it's really hard to get pixel-perfect positioning on effects like I'm trying to do to crop the bars off; I always end up cropping out small parts of the video too.
Created attachment 271263 [details] Screenshot of what it should look like in my perfect world This is what I'd like the end result to look like. No black bars on either side of the embedded clip, and positioned at native resolution in the lower-right, inset from the bottom and right by a small amount of space.
Created attachment 271285 [details] CORners valgrind issues Probably not the cause of the crash (though it may be silently overwriting memory and thus causing it) but here's a valgrind log of stacking CORners and videocrop showing a problem in interpBL_b32().
Hey Dan, just replying to assert the fact that in 90 % of the cases, up / down scaling to match the project output properties is what people want, and that's why it's a default. The thing that should be reimplemented, and is actually quite straightforward to reimplement, is the transformation box, which lets you resize / position / crop individual clips. I've got a proof of concept commit here, which lets you reposition, but for the time it arbitrarily resizes the video (proof of concept I told you :) I can produce a beta patch quite fast, and it's quite fun to do so I'll do it ASAP and post the patch here. The thing to note is that we now do things the clever and correct way, not using any frei0r effects but instead relying on our videoscales in individual clips, and the "xposition" "yposition" properties of videomixer's pads. I got a demo screencast from some time ago here: https://www.youtube.com/watch?v=Rs7DwPmb534
We should also have an "original resolution" check box in the transformation box menu, thanks for making me think about that. I will also have a look at how professional video editors expose that feature before committing myself further than a beta patch :)
https://www.youtube.com/watch?v=pA-LbUXmDVA#t=85 this is how final cut handles that, quite similar to what we had previously (but better :) https://www.youtube.com/watch?v=yxTcSdRgdOI#t=469 Adobe premiere is similar too, so I think we kind of know what to aim for :)
Thanks for the follow-ups, I look forward to these changes!
Hi Dan, first things first I fixed the crash, I'll mark that bug as depending on the relevant report. Regarding the transformation box, I'll link the bug report for it once I'll have opened it. Have a nice day and thanks again for your detailed feedback!
For the record, the fix for the crasher was in the gst plugins bad's wrappers for frei0r: commit 09989e7c71bb10977a94e5279980d8d2e1512514 Author: Mathieu Duponchelle <mduponchelle1@gmail.com> Date: Mon Mar 10 22:48:04 2014 +0100 frei0rfilter: fix memory corruption on sink caps changes. When the input size changed, the frei0r filters didn't take it into account and ended up corrupting memory. Fixes #726069