3/17/04 Richard Baverstock: render Quicktime DV files with an offsettable timecode. The start of the timecode is set in Settings->Preferences->Playback. quicktime_set_frame_start 1394realtimefix.diff - Disables realtime thread initially, then re-enables if the user is root. Thread cannot be set as realtime for non-root users, which it previously was. buzrealtimefix.diff - same as above, but for buz devices. *** Implemented in thread.C avc1394controls-1.1.9.diff - Adds four new files, avc1394control.{C,h} and avc1394transport.{C,h}. A transport is added to the top of the record monitor window when a firewire device is detected AND firewire is the selected recording input. The current device timecode is also displayed. Modified recordmonitor.{C,h} to add these. plugins/defaulttheme/defaulttheme.C has been changed to include a pause image for pause_data (pause.png -- needs to be put in plugins/defaulttheme/data). Makefile additions were made appropriately. When trying to run a patched original 1.1.9, pause.png could not be loaded for some reason -- why, I don't know (it's included in the "../i686/guicast/bootstrap" command for defaulttheme.plugin). Other than that, it works fine. pause.png - Gets put in plugins/defaulttheme/data *** Move theme coordinates to theme.C 3/29/04 Andraz Tori Simple patch for showing transition length in context menu Ideally would be if it would actually be directly editable inside the menu (without needing to open another window just for it), but this would need an overhaul of guicast probably... transition_menu_length.diff This is a patch for very simple visual indication of transitions' lenghts... can be very helpful, but probably, the image choosen to represent it (the same as plugin strip) isn't the best possible. To be wished for are also a drag behaviour of transition end and context sensitivity of the whole strip. bye andraz transition_lenght_strip.diff *** Try using the status bar or tooltip for length. Make options on preferences to disable some of the visual representations. Finish the graphics. Ok here's the new cache patch. It should apply cleanly to mainline 1.1.9 Changes comparing to previous one: - File works without preferences (the size is only set when needed - in CICache) - one crush fix - better way of dealing with temporary images in some places in vrender.C and vmodule.C - cache takes care of their lifespan - this means playback cache is not any slower anymore The thing that was not done: - still in preferences there are separate options for number of cached items and size of every cache, this is necessary due to different machine configurations fast machines that are memory starved should only have large number of cached items, but small cache size per item slow machines with a lot of memory should have on the other hand large cache per item notice: cache item means a media file that is cached (it's header read and ready for imediate decoding) while size per cache item means total size of memory spent for frame cache Overall result: - thumbnail caching speeds up the drawing of canvas - caching while playing/rendering can greatly speed up: - tunning of masks, plugins, etc. at a single frame (no need to decode all frames at given position again and agian and again) - playback/rendering speedup when you have two tracks at the same position - (this is used when you have mask and effects attached to one of them to achieve effect only on part of the image) bye andraz cache_patch_new.diff *** rejected. Same problems as before. Simple fix for histogram plugin... Obviously it was a typo. accum[4] wasn't initialized in constructor and in destructor it was accessed and possibly deleted bye andraz histogram_fix.diff *** done This is quite obvious/trivial slide plugin speedup. Not only it speeds it up - The code and the final slide.so are both made smaller. Bye Andraz slide_plugin_speedup.diff *** done There is a serious bug of translations propagation to .xml which caused for saved .xml to be incompatibile between different locales... At the end this leads to cinelerra not working properly and crushes. This is a fix for it. It basically does two things: 1. plugin_title() reports the title in english again 2. GUI functions are responsible for translating the name when it is displayed (fixes are in two dialogs and in trackcanvas) another minor change is normalisation of the code of plugins ... so now after plugin_title, there are always is_... functions, so the coder can get quick impression what kind of plugin is he dealing with - readability is a bit improved. bye andraz gettext_plugins_fix.diff *** done 3/30/04 Andraz Tori This patch adds a popup menu when clicking with the right mouse button over keyframe inside plugin strip. It gives options: show, delete and copy This kind of behaviour would ideally be available for all autos and at the end the deleting of autos when crossing previous or next one should be abandoned (this is very counter-intuitive). warning: copy actually copies all keyframes at given frame, which is not the best behaviour, but consistent with copy keyframes as used everywhere else. Ideally it should be possible to copy exactly one keyframe from specific plugin and paste it at any place inside any other plugin of the same kind. bye andraz keyframe_popup.diff *** done 4/5/04 One more oneliner, this time for seemingly non-important thing... In optimize function, not all pluginsets were evaluated. But this actually exhibits wrong behaviour at the end, so fix is more than just cosmetical. Bye andraz track_optimizing.diff *** done One liner fix to for localisation of plugin names in asset window... the problem is caused with restructuring of translating of plugin names in one of the previous patches... bye andraz i18n_awindowgui.diff *** done Two fixes for trackcanvas: 1. call cursor_motion_event when button_press_event changes the trackcanvas... so cursor gets correctly changed when over something... 2. double click on plugin selects the region of the plugin bye andraz two_trackcanvas_fixes.diff *** done fixes for a crush of vertical scroll in asset window basically a scroll was deleted while recieving an button press event and then cinelerra crushed. this happened because vertical size of the scrolling area was miscalculated and depent on the placement of the scroll... now height is correctly calculated, because yposition is added to y coordinates (it is substracted before in get_item_y in get_icon_mask inside get_items_height). so now yposition does not impact the calculation of the height of the listbox content. this also fixes an erratical behaviour of dissapearing scrollbar when scrolling... thanks to cobra for reporiting and helping on this one... bye listbox_hscroll_crush.diff *** done fixes... 1) when dragging from assets and then putting the object back to asset window, trackcanvas is insensitive for next drag (awindowgui.C, we need to set operation to NO_OPERATION after 'unsuccesseful' drag) 2) when dragging plugin (that is taken from trackcanvas, not from assets) and dropping it in trackcanvas onto non-compatible track, drag does not work afterwards (trackcanvas.C: 563 and other fixes to drag_stop(), so after 'unsuccesseful' drag, operation is set to NO_OPERATION) 3) on stop of dragging plugin or edit handles, immediate mouse button press and drag won't drag again (as one would be expecting, since you just dragged it to the point of mouse, dragging again should continue the drag of the same handle)... this needed two fixes in two places: one is calling cursor_motion_event inside button_release_event (so cursor is correctly setup after stop of the drag) the other is having the edit virtually one pixel longer ... test_edit_handles() and test_plugin_handles() needed to use <= instead < for determing if the cursor is inside the handle range 4) fix dragging from asset window to main window, so when they overlap, they do not both answer to dragging event... this needed a cunning solution to make cursor_over_window() work when dragging around a pixmap of the asset... :) the solution is to have a one pixel hole in the pixmap, so XQueryPointer correctly returns window in which cursor is currently in... this needed changes in guicast also to allow digging a hole into dragging picture, and also some minor adjustments in awindowgui.C, so original vframe of the asset's picture is kept arround ... all this four fixes make editing by drag'n'drop much easier, because cinelerra now does what is intuitively expected of her... but there are still many bugs in drag'n'drop area... bye andraz drag_n_drop_fix.diff *** done Some time ago i've sent a patch for caching of frames during playback and rendering... Well... i haven't notice but at the time there was a severe leak that especially manifestated itself when rendering by consuming great amouts of memory... Ironically this is one line fix. Missing delete. I hope that caching now works for everyone nicely. (It is already commited in CVS, new debs should be ready today for anyone that experienced problems.) bye andraz cache_severe_leak.diff *** done 4/6/04 Pretty obvious fix for overlay plugin on non-smp computers bye andraz overlay_nosmp_fix.diff *** done 4/8/04 Andraz Tori Links: How to setup Cinelerra renderfarm: http://www.kerklied.com/adrie/presentatiedvdmakeneng.html Cinelerra tutorial in french: http://www.funix.org/fr/linux/cinelerra.htm Cinelerra at MIT: http://www.blu.org/cgi-bin/calendar/2004-mar Cinelerra in gentoo: http://gentoo.kems.net/gentoo-x86-portage/media-video/cinelerra/ And Cinelerra also has Wikipedia topic about it: http://en.wikipedia.org/wiki/Cinelerra 4/12/04 Richard Baverstock 1394-output-2.6-fix.diff * determines when the firewire device is opened what kernel version is being used, and sets the values for the ioctls appropriately (users can switch between kernel 2.4 and 2.6/2.4.23 and above). The recent version of the ieee1394 API uses completely different IOCTLs, so just updating the source for 2.6 would result in lost compatibility for 2.4 kernels (pre 2.4.23). dv1394-output-fix.diff * fixes crash due to a dv1394_init being used in an ioctl call instead of a dv1394_status * fixes general output bug with undesirable "picture in picture" * meant to be applied after 1394-output-2.6-fix.diff, but I can provide one for before if you would like it. Rich 1394-output-2.6-fix.diff dv1394-output-fix.diff *** done Kevin Brosius Summary: When scrolling the asset window of video plugins, the scroll bar does not resize after being created. If a small scroll region is initially created, then the window is shrunk again, you will not be able to scroll to the lower items anymore. Patch: The patch causes the scroll handle to resize on every scrollbar update. This solves most of the problem, although it looks like the handle position isn't updated either. There just seems to be some missing code here for the window resize handling related to scroll bar drawing. -- Kevin Index: guicast/bclistbox.C =================================================================== RCS file: /var/lib/cvs/external/cinelerra/hvirtual/guicast/bclistbox.C,v retrieving revision 1.6 diff -u -r1.6 bclistbox.C --- guicast/bclistbox.C 4 Apr 2004 19:25:38 -0000 1.6 +++ guicast/bclistbox.C 11 Apr 2004 16:02:08 -0000 @@ -1874,9 +1874,12 @@ yscrollbar->bound_to = this; } else + { + yscrollbar->update_length(h_needed, yposition, view_h); yscrollbar->reposition_window(get_yscroll_x(), get_yscroll_y(), get_yscroll_height()); + } } else { *** done Richard Baverstock Back To [INBOX] Speed up based on conversations with Andraz and his overlay patch. - instead of using 64 bit integers, 16/32-bit ints are used depending on the source. - transparency * chroma_zero is calculated outside of the loop, since it is constant within the loop. - the out_row and in_row pointers are increased by components each loop, removing the j * components calculation. - in 4-component video, if the Alpha of in_row[3] is equal to the max, out_row[3] is equal to the opacity. Rich fadeengine-speedup-int.2.diff *** done > This is minimal test case for a strange bug, you'll also need a > test.mov which can be any file with one video and two audio channels > more than a few seconds long... > > The bug goes as follows: > a) switch to drag'n'drop editing mode > b) try to drag left edit of audio 1 over to the right side of > second edit in audio 1 > c) audio 2 edit disappears ... > > i tried to hount it down, but it was too much for me... > > bye > andraz *** Not reproducible 4/25/04 Subject: Re: [CinCVS] [PATCH] vscroll size fixup From: Andraz Tori To: "cinelerra@skolelinux.no" Date: Sat, 17 Apr 2004 10:28:59 +0200 Reply-To: cinelerra@skolelinux.no Commited. The same is needed for horizontal scroller... Here's the full patch, would you mind taking time and sending it to Heroines on 27th... (since patches till that date will be discarded) bye andraz diff -uN --exclude-from exclude hvirtual-cvs/guicast/bclistbox.C hvirtual-1.1.9/guicast/bclistbox.C --- hvirtual-cvs/guicast/bclistbox.C 2004-04-17 10:26:04.000000000 +0200 +++ hvirtual-1.1.9/guicast/bclistbox.C 2004-04-17 10:24:29.000000000 +0200 @@ -1851,9 +1851,12 @@ xscrollbar->bound_to = this; } else + { + xscrollbar->update_length(w_needed, xposition, view_w); xscrollbar->reposition_window(get_xscroll_x(), get_xscroll_y(), get_xscroll_width()); + } } else { @@ -1874,9 +1877,12 @@ yscrollbar->bound_to = this; } else + { + yscrollbar->update_length(h_needed, yposition, view_h); yscrollbar->reposition_window(get_yscroll_x(), get_yscroll_y(), get_yscroll_height()); + } } else { *** done 4/27/04 Speedup for YUVA8888 -> BGR8888 conversion. This is often needed when displaying video when working with internal YUVA8888 colorspace. On my P4 machine, with -O1 setting when compiling, the speedup is approx 1.5ms per DV frame. This means cca. 30 ms per second (when playing 25fps) or in percents 3% overall speedup. Btw: compiling without -O ... will actually reduce the speed comparing to original. Don't know why. But even -O1 can exploit all the potential of the speedup. Bye Andraz yuva8_to_bgr8.diff *** rejected. Too complicated for no speedup on modern CPUs. Small off by one bug, when setting the size of the compositor Canvas. When setting the 720x576 canvas to 50% the dimensions actually set were 631x289 ... which was wrong. This is noticable on cards where Xv extension doesn't do the interpolation, when interlaced images were shown, upper half of the image was the first field and bottom half the second. ... with exact 50% scalling, exactly every second line is taken, so ... exacly only one full field is displayed. Bye Andraz zoom_off_by_one.diff *** done Aligment buttons in projector and camera automation do not work properly under following scenario: Tool is selected, and shown. Z coordinate is changed directly - by writing in the number. After that ... aligments trough buttons do not work correctly. The problem is, that they are taking center_z of camera/projector automation, rateher than the value of pzoom/czoom automation... This fixes it. There are some problems with spliiting zoom and coordinate automation. I would suggest having just one full czoom/pzoom automation internally, but having two different and when needed separate views of it. The problem is that creation of zoom keyframe does not create the projector automation and vice versa, this really annoys users (i just had a three day workshop of Cinelerra, and this was one of the nuisances) Bye Andraz aligment_buttons_fix.diff *** done 4/28/04 When moving around edits with drag'n'drop, fade (and all other) automation didn't work correctly if d'n'd was inside the same track. Here's a fix. Actually it is not as intrusive as it seems, just some code had to be moved arround and one condition added. This was a bitch to fix, because i kept trying to come up with one liner fix... so this is a fix for bug 35 http://bugs.cinelerra.org/show_bug.cgi?id=35 tnx to ga_ for reporting. bye andraz drag_n_drop_automation_fix.diff *** done Entering anything that would be zero or below in loopvideo and loopaudio basically crushes cinelerra. So this is a simple sanity check. This marks the bug 39 fixed http://bugs.cinelerra.org/show_bug.cgi?id=39 tnx to ga for reproting... ok this was a fruitfull day... now it's time for sleep, have a nice sleep everyone :) Bye andraz plugins_sanity_check.diff *** done My bad... plugin i18n fix ... was ok, but accidently it removed plugin title strings from the list of things to be translated This fixes it - now plugin titles are _Not_ translated in-place, but are anyway put to the list of things to translate and are translated in real time when gui needs them... bye andraz plugins_i18n_trivial_fix.diff *** done Cinelerra has big problem with sound resampling. Project output frequency is set to 48khz and user plays/uses mp3 or ogg which usually contain 44.1khz sound. Only playing these (without video) will take around 35% of CPU of 1.6Ghz Pentium4. Not to mention that skipping will happen due to resampling being conctentrated every four seconds approximately. I have looked into it and found out that for mp3 and ogg decoders it is natural to output float format. So what I did is creating a mechanism to allow float samples to get all the way to resampling routine, which finally turns them into doubles. This is Cinelerra total CPU usage measured in top with file playing only in viewer window: Ogg: 34% -> 17% Mp3: 36% -> 19% Among different small optimisations (mostly for loops converted to bcopy), RESAMPLE_CHUNKSIZE was also reduced to one fourth, so resampling is now more evenly distributed - which is important because it takes a lot of cpu power. btw: resampling still makes cinelerra awfully slow in this area, but is not at least a bit better. Maybe simpler and faster resampling routine should be used for realtime playback. And especially when dealing with upsampling. Maybe sampling method should be choosen the same way as image interpolation is choosen. bye andraz faster_mp3_ogg_playback.diff *** rejected. The product is advertized as having 64 bit sound processing. Too complicated with no improvement on modern CPUs. 4/29/04 This patch changes the drag behaviour of plugins when they are dragged from awindow so it maches the behaviour when they are dragged around trackcanvas (that they apply to edit and not to the whole track). But, because previous behaviour is sometimes very useful, new, more logical way to achieve this has been added: dragging plugin to the part of the patchbay, will put it all accross corresponding track. Three things were done - add new behaviour so drag target is corresponding track, when drag is over a patchbay - uncomment already present behaviour in drag_stop - uncomment already present behaviour in draw_highlights I believe this is kind of more intuitive to work with. This fixes bug number 50 reported by ga_ http://bugs.cinelerra.org/show_bug.cgi?id=50 Bye andraz drag_plugin_behaviour.diff *** rejected. Dragging over the patchbay is complicated and doesn't match the behavior when dragging from the canvas. Make this an option in preferences. 4/30/04 This patch makes - gang faders work when you are moving/creating fade points in canvas directly (till now it worked only trough patchbay) - pressing shift when moving any of the floatautos in trackcanvas, it snaps to the closest one (in value, not in a position), previously it snapped to value of the keyframe before it I think this patch is very elegant, and the patchbay should also use trackcanvas for gang fading. Bye andraz gang_faders_in_trackcanvas.diff *** doesn't work. New keyframes are not created in ganged tracks to match the edited track. Instead the ganged track takes the last keyframe adjustment. 5/3/04 The passtrough when rendering in cinelerra didn't work ok for all DV file, because DV multiple different, but equivalent fourcc codes and cinelerra was relying on direct comparison to determine wheather direct copy is possible. This resulted in some AVI files not using passtrough when being rendered... Here's simple fix for DV ... this fixes bug 54 http://bugs.cinelerra.org/show_bug.cgi?id=54 Bye andraz dv_passtrough_fix.diff *** done There are some rounding problems when displaying frame number found by herman and andyc. It seems this is seen only for 25 and 50fps rates, and not 30 and 29.97... The fix is simple, the number needs to be rounded. Bye Andraz frame_calc.diff *** done Two simple fixes: - audiooss.C ... new [] / delete problem - tracksedit.C ... there was access to already freeed piece of memory - when video edit was moved, it was deleted in optimize, but then when looking for first audio edit, the already deleted video edit was checked if it was audio edit Bye Andraz simple_fixes.diff *** done Two additional simple fixes: - rotateframe.C - new [] / delete [] - resample.C ... off by 1 error ... since index of last value accessed is [filter_l + j - filter_l/2] ... which actually equals [j + (filter_l + 1) / 2] the termination condition should match (one value after the end of array was accessed) bye andraz Bye Andraz simple_fixes_2.diff *** resample rejected since it introduced artifacts. This is straight out of libmp3lame so if there is a crash (crush) it needs to be given to www.mp3dev.org.