3/22/04 Richard Baverstock I just committed a change to one of the color model routines for libquicktime; you may or may not notice a difference. In short, before the patch, the lines were computing a floating point value, and then truncating it to an integer. Now, lrintf rounds it, and produces more optimized assembler code. I didn't write the lines in assembly, since they wouldn't be portable to any other architecture than i386, while lrintf is. (lrintf is part of the 1999 ISO C standard -- see http://mega-nerd.com/FPcast/ for some benchmarks and more information (paper written by libsndfile author about floating point to integer conversions)). With lrintf, the transfer_RGBA888_to_YUV422 function (according to oprofile) halved in the % of samples compared to the rest of the functions in libquicktimehv.so. cmodel_default takes ~40% of the samples taken (in comparison, the transfer_RGBA888_to_YUV422 function took the same % before, and now takes ~ 16%). This was consistent over four tests I ran. Richard Baverstock A fade engine patch was just commited to the CVS that increases the number of fps while using the "fade bar" (opacity or transparency might be better words; the bar on the left hand side of a video track). Previously, I acheived 4 fps, now I get 9-12 fps. This was mostly due to unneeded floating point and repeated calculations. 4/25/04 From: Volker Christian Organization: Sourceforge To: cinelerra@skolelinux.no Date: Fri, 16 Apr 2004 15:20:32 +0200 Subject: [CinCVS] ARTS soundserver support for cinelerra Reply-To: cinelerra@skolelinux.no Hello! I have implemented ARTS support (playback and recording) for the current cinelerra 1.1.9. The patch is enclosed in the attachment. It works similar as the esound support. For each, playback and recording, a stream to the arts soundserver is created inside the open_(output|input) methods. Also parameters of the streams are set and read to inform cinelerra about the buffersize and to keep the latency of arts small. During the (read|write)_buffer methods the audiodata are simply read/written from/to the stream. Arts doesn't support - position information - flushing and - interrupting Requested additional informations: As i am not completely sure about the influence of "device->device_buffer" on the audio-video synchronization a some what detailed description about that would be requested. best regards voc arts.diff *** not finished 5/3/04 Johannes Sixt To: , CC: Subject: [PATCH] PNGs: avoid bootstraping Date: Fri, 30 Apr 2004 21:34:41 +0200 Show Full Headers Back To [INBOX] The attached patch (against vanilla cinelerra 1.1.9) gets rid of the bootstrap step after the compilation. The PNG data is "compiled" into the executable (and theme plugins) instead of being piggypacked onto the ELF binaries. The command (architecture and target format are auto-detected by the Makefile): objcopy -B i386 -I binary -O elf32-i386 x.png x.o is used to package the PNG files into object files. Then a Makefile rule constructs a header file (data/register_images.h) that contains the references to the symbols in these objects and invokes BCTheme::register_image() for each PNG. This file is conveniently #included in the constructors of BCTheme-derived classes. (Since the number of images is quite static, it is worth considering to make this file static instead of being built automatically - to reduce build problems.) A new file builds/Makefile.pngs is allocated by the patch. Due to the simplified scheme to access the linked-in PNG data a lot of code related to the path of the executable and plugin shared object is removed by the patch. It is necessary to remove plugins/defaulttheme/data/startover_hi].png or you get a syntax error (due to the ] in the file name). -- Hannes hv_pngs_as_objects.diff *** simpler implementation done V sre, 10.03.2004 ob 12:43 je Heroine Virtual Ltd. napisal(a): > In order to run on SMP it has to produce a useful level of quality. The > mask rewrite certainly utilized dual CPUs and it certainly didn't crash but > it suffered serious rendering errors. this is a fix for one rendering error in new masking code I could find on SMP... If there are more, i'd need to know more specific configuration, or EDL file of the problematic mask... I also found some papers on making faster gaussian blur (for feather), but i'd like to solve out the bare masking first. bye andraz maskengine_smp_fix.diff *** going to wait until feathering is done since there's virtually no time you want to use mask without feather. 5/10/04 From: Kevin Brosius To: cincvs Subject: [CinCVS] DelayVideo patch and Bug #52 Reply-To: cinelerra@skolelinux.no This is a multi-part message in MIME format. --------------052A0D83234F4694021473AB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, I recently committed a simpler fix for Bug #52, but wanted to wait on forwarding anything until I looked at the macros that the plugins use. Here's a uncommitted patch that moves delayvideo closer to using the plugin macros to clean it up a little. Is this a good idea? I'm not a real fan of macros myself, as I'd expect this code to be part of the base class for plugins rather than inlined with macros. What does everyone else think? -- Kevin delayvideo.diff *** done 5/23/04 Benjamin Flaming I have fixed the YUV crashes in DiffKey *** not released 6/1/04 Here is the first fix for 1.2.0, since it took us some time to merge... This is a simple fix for loading greyscale pngs. basically libpng does all the work, we just have to tell it to automatically extend greyscale to RGB this fixes bug number 64. Bye andraz png_grayscale_fix.diff *** done 6/2/04 Here's a fix for a crush introduced in 1.2 - when drag'n'droping video plugin. Obvious oneliner... bye andraz plugin_dnd_crush.diff *** done Johannes Sixt On some distributions HAVE_V4L2 is defined in . As a result some files are compile with the define, some without, which leads to unresolved symbols. The attached patch renames HAVE_V4L2 to HAVE_VIDEO4LINUX2. Additionally, it fixes the configure test: is required by . -- Hannes have_v4l2.diff *** done 6/4/04 Ok, here's the fixed patch for gang faders to work in trackcanvas. The problem with previous was that it worked only in autokeyframmed mode. Now it is tested in both modes and works well. The only problem i had was getting the proper functionality from autos functions to implement this. Finally i had to take part of one and create a new function that just returns an auto at specific position or nothing in order to know wheather to create new keyframe (creating new keyframe trough get_auto_for_editing is useless, since it aligns to frames and does not create a new one at specific position if not in autokeyframing mode, insert_auto_for_editing OTOH is useless because it cannot be known wheather keyframe was created or reused - which we need for being able to change two different faders with different starting values) bye andraz gang_faders_in_trackcanvas_v2.diff *** done 6/6/04 Small i18n fix bye andraz i18n_interpolate.diff *** done andraz Your new implementation of framecache has a multithreading race possibility... basically when anyone calls get_frame_ptr, it has to be absolutely sure that if data is returned it will not get deleted by some other thread (in delete_oldest) until it is not needed anymore (processed or copied) therefore lock has to be held after the call get_frame_ptr and unlocked when data is not needed the only current case is in resourcepixmap... framecache_race_fix.diff *** done From: ga@kutxa.homeunix.org The first time you select Buz Driver in PlayBack preferences it works, but when you want to change it again to XV or anything else, or when you close the preferences dialog, it crashes. http://bugs.cinelerra.org/show_bug.cgi?id=63 Agur/Bye, Gustavo Iñiguez buz_prefs.diff *** done Hi new version of the spanish translation. Agur/Bye, Gustavo Iñiguez es.po.bz2 *** done 6/7/04 ga Btw, if someone is interested i have a new theme for cinelerra, it's=20 just the Blond theme colorized, nothing special. inverse_theme-1.2.0.tar.bz2 6/12/04 It was easy to crush cinelerra by entering a too big camera zoom factor... then cinelerra would try to allocate 20000x20000 image and fail.. this fix adds an upper bound for camera zoom to 10 (which is problematic) and projector zoom to 10000 (which is not problematic, but would still be good to have an upper bound). this fixes bug 70 bye andraz zoom_crush.diff *** done. In histogram, tumbers are limited to 255 which is a bug since the maximum values are 65535 Also in translate plugin, unfortunately it is not completely obvious what the upper bound should be in translate, so i just raised it from 100 (which is obviously too little for all practical purposes) to 1000. This fixes bug 69 bye andraz tumblers.diff *** converted to float 6/16/04 One of the problems of rapid editing was the need to go back to patchbay to rearm the needed tracks all the time... Gustavo Iñiguez fixed this elegantly... Have a keyboard shortcut that will arm the track that cursor is currently over. Now the behaviour is: TAB toggles the arming of the track that mouse cursor is currently over (the same as clicking on record button) SHIFT+TAB behaves exactly the same as the pressing Shift+ record button of the track that mouse cursor is currently over This is can greatly speed up the editing. This fixes bug number 4 in bugzilla. Bye Andraz tab_arms_under_cursor.diff *** done When right-clicking a plugin on the track, the option in the menu says "Attach", but in fact changes the plugin, not attaching a new one. This patch changes the text of the menu label to reflect the behaviour, and the plugin dialog as well. This fixes bug #9 in bugzilla. Patches cleanly to 1.2.0. -- Richard Baverstock John 11:25-26 effect_context_label_bug9.diff *** done 6/23/04 plain I18N patch for batch rendering... bye andraz batch_recording_i18n.diff *** done 6/25/04 From: Richard Baverstock Read/write support for both audio and video is now in the CVS. > bug in libdv0.99 that causes a crash when trying to read the audio filedv1.diff *** VFS not supported. 7/9/04 From: Pierre Marc Dumuid To: cinelerra@skolelinux.no Subject: [CinCVS] H263 enabling patch... Reply-To: cinelerra@skolelinux.no Hi, I had a whole heap of quicktime h263 files that I had made using my portable digital camera (Kodak DX6340) that I wanted to edit in cinelerra... After trying to convert these files (using mplayer, or transcode) to fairly unsatisfactory results, I eventually discovered that the quicktime in cinelerra only needed a few lines added, since ffmpeg could already handle these files... Anyhow, I've made a quick patch of the files I changed to get it working below... I did notice that elsewere in the hvirtual/cinelerra/ directory there were a few files that I should have probably looked at in regards on how "best" to set the decoding parameters (or something like that) but I was just really glad to see it work... (and didn't have a clue what to do in those files) Regards, Pierre Dumuid h263.diff *** done