Am Donnerstag 24 Juni 2004 19.59 schrieben Sie: > Hallo > > > I did inlude a new effect into Linux Video Studio: Fade in/out to/from black > > or white. This includes a filter for the yuv stream and one for the sound > > stream. The patch can be found at > > > > http://www.nada.kth.se/~hanke/files/lvs.patch.gz > Wow, that a huge patch (800kb) Ooops, I was too much in a hurry.
> > Would you be so kind an make the patch a second time ? > And remove files which are generated by the configure and autogen > process, in both directorys ? It would be enought if you do a "make > distclean". If you are unsoure which files you need to remove take a > look a the .cvsignore file in each directory. > Do we also need the *save* files and the *.c~ and *.h~ files ? Did as you said. I did not find any .cvsignore files in my source trees. Consequently, some of the derived files are present (configure, Makefile.in etc.) Since I do not know anything about automake&Co, I do not know which files to remove. Note that I am not using the cvs but the distributed LVS source. So the diff remains *huge*. How can I checkout the *old* 0.1.7 version from cvs? > > That will make the patch more human readable. > I will merge your changes into the CVS. > > > Remarks: > > - The patch is against LVS 0.1.7, *not* against the CVS version for the > > following reasons: > > . I am using the enhanced scale widget which is still not ported. > When have you tried it the last time ? > I got a mail from Ronald at the 3.March where he wrote me that is should > work. If it still does not work. Tell me what goes wrong an I try to fix > it. Downloaded the cvs version right now. The code related to gtkenhancedscale in lavedit_effects.c is commented out. > > > . The CVS version uses GTK 2 which is too slow for me. As an example, if I > > play a stream in the edit window, it takes up to 30 seconds until the > > programme reacts to a button event (pause/stop) or a redraw event. (I have an > > Athlon 1.2GHz) So it is unusable. > Strange. It should not be that slow. On my macine it takes about 1-2 sec > max. > > Which GTK version did you use. I have 2.2.4 It is a stock SuSE 9.0 which provides 2.2.3. I observed a similar behavior with the mjpeg tools. The binary package provided was very slow. Only after recompilation, it was really usable. May it be possible that SuSE used some strange (conservative) compile flags which makes the toolkit slow?? > > > - The sound filter is only tested on a little-endian machine because I do not > > have access to a big-endian one. It provides access to PCM-coded WAV files in > > little-andian (RIFF) and big-endian (RIFX) format. > If you want to fix it yourselve take a look at lav2yuv program I have > solved the problem there. You can see it in the mjpeg cvs easy when you I wrote a header file (wave_io.h/c) which uses a lot of #ifdef WORDS_BIGENDIAN for invoking/not invoking byte swapping. I would be grateful if somebody else could test it (on a Mac?) > do a diff to the last version. I still have to test LVS on a Big Endian > (like my MAC). > > > - I would need a program similar to lavpipe for the sound channel (WAV). In > > that case, the transition filter could be complemented by a respective sound > > filter. This is an important wish for making editing much more convenient. > > Right now I am using audacity for that purpose. > That "should not" be that hard to write. Probably :-) My hope is that somebody else whió knows more about lavepipe could do it. For me, it would require much time to reinvent the wheel. > > > - Some small bug fixes are incorporated. > That's nice :) > Michael ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
