[CinCVS] Re: ogg renderfarm support
Personally think instead of adding new PackagingEngines specifically for OGG into packagedispatcher.C, the OGG specific packaging should somehow be done in FileOGG and PackageDispatcher should be calling File functions. A lot of the OGG specific code in packagedispatcher.C is dependant on the fact that FileOGG can't do multiplexing yet. Instead of supporting multiplexing in FileOGG, it's encoding the audio first and then direct copying audio using OGG specific methods in packagedispatcher.C. > No more you are left with multiple files that you have to mux yourself. If that's all you want, renderfarm should just ignore the audio setting and render the video normally. If audio is checked, the renderfarm should go back and render audio locally into the final output with direct copied video chunks. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] SMP or renderfarm?
What would be better, my Dual Dual Core Opteron (4 logical CPUs) or 4 single-cpu systems as a renderfarm? In other words, does cinelerra support proper spliting of rendering in SMP mode like it does for a renderfarm? ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Problems running Cinelerra under Ubuntu 5.10
On 5/30/06, stewart <[EMAIL PROTECTED]> wrote: Hi I just followed the guidelines for installing Cinelerra under Ubuntu 5.10 ( from the Cinelerra-cvs site, and when I try and run it I get the error message :- cinelerra Cinelerra 2.0CV Mon May 15 01:19:24 UTC 2006 (C)2005 Heroine Virtual Ltd. Cinelerra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for Cinelerra. Illegal instruction I am running a fresh install of Ubuntu 5.10 Which processor build are you running? Can you try installing i686 build and run it through gdb or strace so we get more precise error message. regards, jure cuhalev ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] New Bounty: Rendering directly to the MPEG PS container. 200 EUR
> On Tue, May 30, 2006 at 03:36:13PM +0200, Herman Robak wrote: > > I offer 200 Euro to the one who adds MPEG Program Stream as one > > of Cinelerra's output formats, with a DVD compability setting. > > > > Cinelerra already supports rendering raw MPEG video and audio streams, > > but not simultaneously, and no multiplexing. This means Cinelerra > > can not render DVD-ready MPEG2 files directly. > > That's a great bounty, Herman! > > In case anyone is thinking about this, one way to accomplish this > would be changing the DV output so it can be written to a pipe. > Currently, it uses fseek's that can only be done on files. Once it > can be piped out, one can use the ffmpeg toolchain to convert to from > piped DV to the finished DVD-ready output on the fly. There are several reasons why this is not IMHO a desirable approach. As someone has already pointed out, doing this incurs the time penalty of a DV encode/decode cycle - although admittedly if the source happens to be in DV *and* there's no video processing active the cycle will be skipped. The biggest problem is that libdv's PAL encoder is buggy (I've never tried NTSC) and introduces considerable artifacts which are particularly noticeable during moderate horizontal movement. ffmpeg is better but still (as of 6 months ago anyway) had problems. Besides this, there will be a loss of quality due to the decode/encode cycle since DV is lossy. Most videos do have at least some transisitions/overlays etc, so this issue will crop up, even if it doesn't affect a majority of a video if the source is DV. For this reason using DV as the intermediate format is not ideal. However, perhaps the DV framework could be used as the basis for something since as has been pointed out, the DV export option is one of few (perhaps the only one?) which does video and audio simultaneously. Regards jonathan ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Sodipodi -> Inkscape
thnx!
(tbh i far prefer inkscape to sodipodi)
julian
..on Sat, May 27, 2006 at 03:11:15PM -0400, Joe Stewart wrote:
> On Saturday 02 October 2004 17:27, Andraz Tori wrote:
> > So... Cinelerra now has this plugin that enables to edit SVG pictures
> > in sodipodi and then seamlessly use them in cinelerra as an overlay
> > (implemented by plugin).
> >
> > Now, since it seems that sodipodi is gone sniffing the dasies, i am
> > wondering is someone proficent enough in GTK coding to be willing to
> > port the patch from sodipodi to inkscape?
> >
> > basically it adds a GUI button 'e' when started with special command
> > line, uses a shift+cntrl+e keycombo for this button, and does the
> > shared memory passtrough of the rendered picture to cinelerra...
> >
> > anyone new who would like to get to the dark side of the pushing
> > cinelerra even further?
>
> Better late than never, right? Here's the patch, ported to the latest SVN
> build of Inkscape.
>
> -Joe
> diff -Pru inkscape-orig/src/Makefile_insert inkscape/src/Makefile_insert
> --- inkscape-orig/src/Makefile_insert 2006-05-27 11:40:53.0 -0400
> +++ inkscape/src/Makefile_insert 2006-05-27 11:43:49.0 -0400
> @@ -42,6 +42,7 @@
> attributes.cpp attributes.h \
> bad-uri-exception.h \
> brokenimage.xpm \
> + cinelerra.cpp cinelerra.h \
> color-rgba.h\
> color-profile.cpp color-profile.h \
> color-profile-fns.h \
> diff -Pru inkscape-orig/src/cinelerra.cpp inkscape/src/cinelerra.cpp
> --- inkscape-orig/src/cinelerra.cpp 1969-12-31 19:00:00.0 -0500
> +++ inkscape/src/cinelerra.cpp2006-05-27 11:45:37.0 -0400
> @@ -0,0 +1,258 @@
> +#define __CINELERRA_C__
> +
> +/* All of the code added to Inkscape for integration with Cinelerra --
> + * minus the interface stuff etc. that has to go into Inkscape's main
> + * code. All of it is tagged with "CINELERRA". */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#ifdef HAVE_CONFIG_H
> +# include "config.h"
> +#endif
> +#include "path-prefix.h"
> +
> +#include "inkscape.h"
> +#include "gc-core.h"
> +#include "sp-root.h"
> +#include "file.h"
> +#include "document.h"
> +#include "sp-object.h"
> +#include "unit-constants.h"
> +#include "xml/repr.h"
> +#include "color.h"
> +#include "svg/svg-color.h"
> +#include "svg/svg.h"
> +#include "cinelerra.h"
> +struct _Cinelerra Cinelerra;
> +
> +static gchar *sp_export_dpi = NULL;
> +static gchar *sp_export_area = NULL;
> +static gchar *sp_export_background = NULL;
> +static gboolean sp_export_use_hints = FALSE;
> +static gchar *sp_export_id = NULL;
> +static gboolean sp_export_area_drawing = FALSE;
> +static gboolean sp_export_id_only = FALSE;
> +static gboolean sp_export_area_canvas = FALSE;
> +static gboolean sp_export_area_snap = FALSE;
> +static gchar *sp_export_background_opacity = NULL;
> +static gchar *sp_export_height = NULL;
> +static gchar *sp_export_width = NULL;
> +
> +
> +void cin_export(GtkWidget *widget, GdkEvent *event, gpointer data)
> +{
> + SPDocument *doc;
> + doc = SP_ACTIVE_DOCUMENT;
> + cin_do_export_raw(doc);
> + sp_file_save(NULL, NULL);
> +}
> +
> +void
> +cin_do_export_raw(SPDocument *doc)
> +{
> + /* This entire section is the sp_do_export_png function found in
> + * main.cpp, which seems to be not for use globally. I made a few
> + * minor modifications to get rid of gcc warnings and extra
> + * pointers. */
> +
> +gdouble dpi = 0.0;
> +
> +if (sp_export_use_hints && (!sp_export_id && !sp_export_area_drawing)) {
> +g_warning ("--export-use-hints can only be used with --export-id or
> --export-area-drawing; ignored.");
> +}
> +
> +GSList *items = NULL;
> +
> +NRRect area;
> +if (sp_export_id || sp_export_area_drawing) {
> +
> +SPObject *o = NULL;
> +SPObject *o_area = NULL;
> +if (sp_export_id && sp_export_area_drawing) {
> +o = doc->getObjectById(sp_export_id);
> +o_area = SP_DOCUMENT_ROOT (doc);
> +} else if (sp_export_id) {
> +o = doc->getObjectById(sp_export_id);
> +o_area = o;
> +} else if (sp_export_area_drawing) {
> +o = SP_DOCUMENT_ROOT (doc);
> +o_area = o;
> +}
> +
> +if (o) {
> +if (!SP_IS_ITEM (o)) {
> +g_warning("Object with id=\"%s\" is not a visible item.
> Nothing exported.", sp_export_id);
> +return;
> +}
> +
> +items = g_slist_prepend (items, SP_ITEM(o));
> +
> +if (sp_export_id_only) {
> +g_print("Exporting only object with id=\"%s\"; all other
> objects hidden\n", sp_export_id);
> +}
> +
> +if (sp_export_use_hints) {
> +// retrieve export dpi hints
> +const gchar *dpi_hint =
> SP_OBJECT_REPR(o)->attribute("inkscape:export-xdpi"); // onl
[CinCVS] // mpeg processed w/mencoder crashes cinelerra //
hi list! when i load a file i've processed like so: mencoder file.mpeg -vf pp=lb -o file1.mpeg -oac copy -ovc lavc cinelerra crashes without any clues in the output. 'file.mpeg' loads into cinelerra just fine. simplifying it to a straight stream copy: mencoder file.mpeg -o file1.mpeg -oac copy -ovc copy it still crashes. is this a known problem? if it's of any use i can upload a stack trace. cheers, julian -- __ _ ___ ___| |___ __| |_ _ __ __ _ _ _| |__ ___ (_-http://selectparks.net/~julian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Problems running Cinelerra under Ubuntu 5.10
Hi I just followed the guidelines for installing Cinelerra under Ubuntu 5.10 ( from the Cinelerra-cvs site, and when I try and run it I get the error message :- cinelerra Cinelerra 2.0CV Mon May 15 01:19:24 UTC 2006 (C)2005 Heroine Virtual Ltd. Cinelerra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for Cinelerra. Illegal instruction I am running a fresh install of Ubuntu 5.10 Regards Stewart ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] ogg renderfarm support
... attaching the correct file... :)
bye
andraz
diff -ru --exclude-from exclude hvirtual-cvs/cinelerra/batchrender.C hvirtual-2/cinelerra/batchrender.C
--- hvirtual-cvs/cinelerra/batchrender.C 2005-11-12 12:12:47.0 +0100
+++ hvirtual-2/cinelerra/batchrender.C 2006-05-29 00:19:23.0 +0200
@@ -459,11 +459,7 @@
0);
// Append output paths allocated to total
- for(int j = 0; j < packages->get_total_packages(); j++)
- {
-RenderPackage *package = packages->get_package(j);
-paths->append(strdup(package->path));
- }
+ packages->get_package_paths(paths);
// Delete package harness
delete packages;
@@ -504,6 +500,8 @@
plugindb);
int result = ConfirmSave::test_files(0, &paths);
+ paths.remove_all_objects();
+
// Abort on any existing file because it's so hard to set this up.
if(result) return;
diff -ru --exclude-from exclude hvirtual-cvs/cinelerra/fileogg.C hvirtual-2/cinelerra/fileogg.C
--- hvirtual-cvs/cinelerra/fileogg.C 2006-05-30 02:04:25.0 +0200
+++ hvirtual-2/cinelerra/fileogg.C 2006-05-31 00:55:19.0 +0200
@@ -35,6 +35,7 @@
asset->format = FILE_OGG;
asset->byte_order = 0;
reset_parameters();
+ final_write = 1;
}
FileOGG::~FileOGG()
@@ -153,7 +154,8 @@
// need more data for page
if (read_buffer(in, sw, READ_SIZE) == 0)
{
-printf("FileOGG: There is no more data in the file we are reading from\n");
+// FIXME We should report that just in some situations... sometimes we go to the end
+//printf("FileOGG: There is no more data in the file we are reading from\n");
return 0; // No more data
}
}
@@ -545,7 +547,7 @@
break;
}
- if (vorbis_p == 3 && theora_p == 3)
+ if ((!vorbis_p || vorbis_p == 3) && (!theora_p || theora_p == 3))
break;
/* The header pages/packets will arrive before anything else we
care about, or the stream is not obeying spec */
@@ -919,6 +921,15 @@
return (ogg_get_next_page(sw, serialno, og));
}
+int FileOGG::ogg_seek_to_databegin(sync_window_t *sw, long serialno)
+{
+
+// printf("FileOGG:: Seeking to first page at %lli\n", filedata_begin);
+ read_buffer_at(stream, sw, READ_SIZE, filedata_begin);
+// we don't even need to sync since we _know_ it is right
+ return (0);
+}
+
int FileOGG::ogg_get_next_page(sync_window_t *sw, long serialno, ogg_page *og)
{
while (take_page_out_autoadvance(stream, sw, og) > 0)
@@ -1058,6 +1069,8 @@
current_comming_sample += vorbis_synthesis_pcmout(&tf->vd, NULL);
if (current_comming_sample > sample)
{
+ if (previous_comming_sample > sample)
+ printf("Ogg decoding error while seeking sample\n");
vorbis_synthesis_read(&tf->vd, (sample - previous_comming_sample));
// printf("WE GOT IT, samples already decoded: %li\n", vorbis_synthesis_pcmout(&tf->vd,NULL));
return 1; // YAY next sample read is going to be ours, sexy!
@@ -1267,7 +1280,7 @@
data[3] == 'S')
{
fclose(fd);
- printf("Yay, we have an ogg file\n");
+// printf("Yay, we have an ogg file\n");
return 1;
}
fclose(fd);
@@ -1280,11 +1293,13 @@
if (wr)
{
- if (asset->audio_data)
- write_samples_vorbis(0, 0, 1); // set eos
- if (asset->video_data)
- write_frames_theora(0, 1, 1); // set eos
-
+ if (final_write)
+ {
+ if (asset->audio_data)
+write_samples_vorbis(0, 0, 1); // set eos
+ if (asset->video_data)
+write_frames_theora(0, 1, 1); // set eos
+ }
flush_ogg(1); // flush all
if (asset->audio_data)
diff -ru --exclude-from exclude hvirtual-cvs/cinelerra/fileogg.h hvirtual-2/cinelerra/fileogg.h
--- hvirtual-cvs/cinelerra/fileogg.h 2006-03-27 01:56:09.0 +0200
+++ hvirtual-2/cinelerra/fileogg.h 2006-05-31 00:49:18.0 +0200
@@ -74,6 +74,7 @@
class FileOGG : public FileBase
{
+friend class PackagingEngineOgg;
public:
FileOGG(Asset *asset, File *file);
~FileOGG();
@@ -128,6 +129,7 @@
int ogg_get_page_of_frame(sync_window_t *sw, long serialno, ogg_page *og, int64_t frame);
int ogg_seek_to_keyframe(sync_window_t *sw, long serialno, int64_t frame, int64_t *keyframe_number);
+ int ogg_seek_to_databegin(sync_window_t *sw, long serialno);
int64_t start_sample; // first and last sample inside this file
@@ -152,6 +154,7 @@
int64_t ogg_frame_position;// LAST decoded frame position
int64_t next_frame_position; // what is the next sample read_frames must deliver
char theora_keyframe_granule_shift;
+ int final_write;
};
class OGGConfigAudio;
diff -ru --exclude-from exclude hvirtual-cvs/cinelerra/packagedispatcher.C hvirtual-2/cinelerra/packagedispatcher.C
--- hvirtual-cvs/cinelerra/packagedispatcher.C 2005-11-12 12:12:47.0 +0100
+++ hvirtual-2/cinelerra/packagedispatcher.C 2006-05-31 00:52:40.0 +0200
@@ -13,11 +13,15 @@
+#include "file.h"
+#include
+#include "fileogg.h"
PackageDispatcher::PackageDispatcher()
{
packages = 0;
package_lock = new Mutex("PackageDispatcher::package_lock");
+ packaging_engine = 0;
[CinCVS] ogg renderfarm support
This extensive patch implements true renderfarm rendering 'out of the box'
support for ogg vorbis+theora video.
No more you are left with multiple files that you have to mux yourself.
Basically what it does is special distribution of the workload among nodes and
then it automatically muxes the results.
- whole audio range is rendered as a single package by single node (due to
non-packetnes of audio compression, it cannot gracefully be broaken into
smaller packages)
- video range is divided in number of packages specified in renderfarm
preferences
- when all packages are finished, cinelerra automatically muxes all the files
together to get the final file (all the references in codecs are properly
updated)
- temporary files are deleted, and only final file is left
To implement this, i've needed to make a new class hirarchy to be able to
cleanly implement stuff...
Everything is done in a way to support mpeg2 TS A+V distributed rendering in
the same way in the future (as it is discussed currently on the mailing list)
As a 'colateral damage' some bugs were found in fileogg.C and are also fixed by
this patch...
I haven't completely abstracted the PackatingEngine from the
PackageDispatcher... i've just done it for single pass render farm mode, which
leaves some work for PackageDispatcher. If there is a problem with this, i can
fix it... adam?
So have fun rendering to OGG _really_fast_ :)
p.s.: this was direct need we have in Cyberpipe, since we do a lot of ogg
vorbis+theora encoding... (http://video.kiberpipa.org)
bye
andraz
Index: module.C
===
--- module.C (revision 800)
+++ module.C (working copy)
@@ -216,7 +216,6 @@
int direction)
{
SET_TRACE
- Plugin *prev_transition = transition;
transition = track->get_current_transition(current_position,
direction,
0,
@@ -226,7 +225,7 @@
// for situations where we had transition and have no more, we keep the server open:
// maybe the same transition will follow and we won't need to reinit... (happens a lot while scrubbing over transitions left and right)
// if((prev_transition && !transition) ||
- if ((transition && prev_transition && strcmp(transition->title, prev_transition->title)))
+ if ((transition && transition_server && strcmp(transition->title, transition_server->plugin->title)))
{
transition_server->close_plugin();
delete transition_server;
Re: [CinCVS] Rendering to pipe vs. rendering direct to dvdauthor MPEG
On Tue, 30 May 2006, Dan Streetman wrote: > 2. Completely integrated DVD rendering will be much more user-friendly, > but will be much less flexible. Authoring DVDs involves a lot of complexity that has little to do with video editing. I'd rather do the authoring in a separate application instead of trying to make it part of the video editor. But the video editor does need to generate output in a form that the authoring tool can conveniently use without recompression. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Rendering to pipe vs. rendering direct to dvdauthor MPEG
On Tue, May 30, 2006 at 05:49:04PM -0400, Dan Streetman wrote: > > Clearly there are two very different directions and I don't think they > necessarily negate each other (although using pipes would probably stray > from what's specified by the bounty). > > 1. Allowing rendering to video and audio pipes (or a combined video/audio > pipe), and user-specified backgrounded command lines to process the > pipe(s) (e.g. the current yuv4mpegpipe-to-pipe rendering), is _very_ > flexible, but also quite user un-friendly. > > 2. Completely integrated DVD rendering will be much more user-friendly, > but will be much less flexible. > > > My opinion is Cinelerra would be a better tool with _both_ options. For > advanced users, rendering to pipes can be very useful (not just for DVD > rendering); you can run video or audio through external filters that > aren't available in cinelerra (e.g. yuvdenoise, yuvscaler, sox, etc.), > while the integrated option would be best for all new users and would > be a quick and hassle-free way to create a DVD. Another option would be to allow so much settings when rendering that using a shell would not bring anything else compared to setting the parameters in Cinelerra. Unfortunately, there are so much parameters that the MPEG2 export settings window would look like an airplane cockpit! Nicolas, Paris. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Rendering to pipe vs. rendering direct to dvdauthor MPEG
Clearly there are two very different directions and I don't think they necessarily negate each other (although using pipes would probably stray from what's specified by the bounty). 1. Allowing rendering to video and audio pipes (or a combined video/audio pipe), and user-specified backgrounded command lines to process the pipe(s) (e.g. the current yuv4mpegpipe-to-pipe rendering), is _very_ flexible, but also quite user un-friendly. 2. Completely integrated DVD rendering will be much more user-friendly, but will be much less flexible. My opinion is Cinelerra would be a better tool with _both_ options. For advanced users, rendering to pipes can be very useful (not just for DVD rendering); you can run video or audio through external filters that aren't available in cinelerra (e.g. yuvdenoise, yuvscaler, sox, etc.), while the integrated option would be best for all new users and would be a quick and hassle-free way to create a DVD. -- Dan Streetman [EMAIL PROTECTED] - 186,272 miles per second: It isn't just a good idea, it's the law! ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] New Bounty: Rendering directly to the MPEG PS container. 200 EUR
On Tue, 30 May 2006 20:53:58 +0200, Andraz Tori <[EMAIL PROTECTED]> wrote: The only _right_way_ is using ffmpeg library from cinelerra and producing the multiplexed files directly, without any pipes, middle-encoding or anything else. And this is what I want, with a few presets. Maybe an "advanced" section for tweaking all the parameters. But first and foremost, I want something that a naive user could just pick, and be confident that dvdauthor will not barf on it. Desired features: * Just another format, with a choice of "compression", like AVI and Quicktime. * Single pass rendering, without a bunch of temporary files * No dependencies to external executables; built-in with Cinelerra. * Common settings like "DVD compliant" set by default. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] New Bounty: Rendering directly to the MPEG PS container. 200 EUR
On Tue, May 30, 2006 at 02:58:00PM -0400, Dan Streetman wrote: > >The other way to approach this problem is to use YUV4MPEG (or similar > >uncompressed format), and seperately export audio the same pipe that > >it is using. This would be a fine solution too (perhaps even a better > >one) although I think a little harder to implement. I certainly > >wouldn't want to discourage anyone from doing it, though. > > I don't think the yuv4mpegpipe format allows for audio, so I don't know > how that would be possible... It doesn't, but ffmpeg allows for multiple inputs. I was probably sloppy to call it the same pipe. The audio would be in a standard audio format, but on a separate file descriptor. The rendering process (ffmpeg) would read from that descriptor just as it reads from stdin for the YUV4MPEG video. Named pipes are one way to do this, but not necessary (at least on Linux). Andraz Tori <[EMAIL PROTECTED]> writes: > The only _right_way_ is using ffmpeg library from cinelerra and > producing the multiplexed files directly, without any pipes, > middle-encoding or anything else. I'd hesitate to call it the only way, but it would be a good way as well. I think it would be significantly harder than a piped solution to implement, and would be specific only to ffmpeg's capabilities. And the middle encoding would often need to happen, but it would be hidden inside the exporter. But this would be a fine solution, especially if one made sure the rendered product was pipe-able. Herman Robak <[EMAIL PROTECTED]> writes: > Pipes and scripts are very UNIX-y and familiar for the tinkerers > among us who are used to the command line. However, it is not a > performance winner, and it is a rather clunky gum-and-gaffa design. > They are nice as workarounds, but I wish we would take the time to > step back and look for a greater _design_. A fine idea. The nice part is that pipes are simple to implement, and flexible. But an integrated solution (as Andraz suggests) would probably be more in keeping with the Cinelerra philosophy, as well as better for users who just want something that works out of the box. --nate ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Questions from Cinelerra "Newbie"
Hi, > 1. What is the best (least lossy) output format... > 2. Is there a way to get Cinelerra to render using ffmpeg... yuv4mpeg seems to be a favorite. You can pipe it to other programs like ffmpeg or x264. > ... So far none of the output formats that I've been able > to find in Cinelerra are streamable... This post shows how to encode to qt7 compatible mp4 from a yuv4mpeg stream: https://init.linpro.no/pipermail/skolelinux.no/cinelerra/2006-May/006568.html > 3. For some reason I've been having trouble when I read in a video file > (MPEG2 format from my Hauppauge) that contains audio. No idea. > 4. ...it doesn't offer any way of seeing the audio waveform as well The timeline shows the audio and video waveforms. Arm only your audio and any edits won't affect your video (ie they will not be locked). > 5. I got very excited about the idea of having a renderfarm. No idea. /Alec ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] panning stabilization
Hi, Is it possible to stabilize panning footage? My skiing footage has either pans of mountains in the background, or skiers moving in the foreground. As the camcorder is handheld, there are jumps and shakes that make some of the footage quite shaky. I've tried the motion plugin, but it seems to be based on tracking stationary points and gets confused by moving foregrounds or backgrounds. I found this avisynth plugin: http://www.guthspot.se/video/deshaker.htm which seems to do what I'm looking for. Can Cinelerra do this already, or is it worth coding a new Stabilize plugin? /Alec ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Questions from Cinelerra "Newbie"
(My third attempt to post this with all errors being mine...) I don't want to get anyone angry at me for posting "stupid questions" so if the questions are not being posted in the right place, please tell me where to post. I am currently using the main Cinelerra (from HeroineVirtual) distribution on both Gentoo 2005.1 and Fedora Core 3. I've taken a look at it on and off since the days it was originally just the audio editor Broadcast. The current 2.0 release of Cinelerra took some getting used to due to my Mac and Windows exposure to things like Avid, Adobe and Sonic Foundry (now Sony) software. I've become accustomed to the two screen editing approach and within the past week have edited 46 projects with varying degrees of POSITIVE success. Kudos to Alex and the rest of the crew for making Cinelerra what it is today! But onto my questions: 1. What is the best (least lossy) output format that i can dump out of Cinelerra for re-encoding to my final chosen format with ffmpeg? I'm currently using Quicktime with Two's Complement for audio and H264 for video with a 200 (the default) bitrate. I just don't want to lose much quality when working with the video I capture in the editing phase. (I use a Hauppaugue PVR250 to capture MPEG2 at 960 bps) Is there anything that is the equivalent of uncompressed video that I can then use with ffmpeg to encode to my final output? 2. Is there a way to get Cinelerra to render using ffmpeg (so I can chose from the codecs available to it vs. what's available in Cinelerra) to save a step in my workflow? I have a lot of video that I want to put online for members of the family to stream on both Windows and Macintosh platforms and I'd prefer to not force them to install anything beyond the default media players in their chosen OS (and in many cases dial-up access). So far none of the output formats that I've been able to find in Cinelerra are streamable in a way that fits these requirements. So... I've been using ffmpeg to take care of that part for me. This isn't a gripe about Cinelerra, just a question as to whether the render output (uncompressed if possible) can be piped to an external encoder. 3. For some reason I've been having trouble when I read in a video file (MPEG2 format from my Hauppauge) that contains audio. The audio or the video will wind up being minutes longer than the opposing tracks in the timeline which results in HUGE sync problems. The videos themselves play fine all the way through in Xine or MPlayer so the file should be OK. The workaround for now is that I use ffmpeg to break my video file up into separate audio and video tracks and read those into Cinelerra. Then I render out to a .mov file and pull that in for two screen editing with the Viewer ([ ] v). Or, I just edit to clips from the compositor and utilize clips for the next step. Then I render my final edit out and use ffmpeg to encode to my final output format. I've seen this problem on three of my systems (both Gentoo and Fedore Core) so I've had to use the ffmpeg split approach on all of them. The first system is a P4 with Gentoo and 1 gig of RAM. It has a 2.6.14.2 Linux kernel on it and an external ALSA build since my audio interface is not supported in the main kernel ALSA. More details can be provided for this if needed. 4. The Viewer is great for using the in/out points and splice to get a nice basic edit into the timeline. But since it doesn't offer any way of seeing the audio waveform as well, it's hard to try and play tricks with syncing audio and video manually. For example if I wanted to find a specific frame and line up an audio effect to coincide with frame accuracy, how would I achieve this? I haven't found a way to do this in the timeline either since the audio tracks appear to be locked to the video track and drag and drop editing is not yet fully supported. I'm sure I'm not the only person wanting to sync audio events with video in a frame accurate way so maybe there is a method I haven't yet discovered? 5. I got very excited about the idea of having a renderfarm. So I installed Cinelerra on four of my machines at home. I started up the render clients and then set the main system to point at them for the renderfarm feature. I also made sure that my NFS setup is working flawlessly (I sill have to figure out how to resolve the 2 gig limit in NFS as a lot of my renders ar 15-20 gigs in size with Quicktime). I started the batch render and watched with amazement as the renders completed much faster than the single host could do. Something that would take four-six hours seemed to complete in only an hour and a half. I then pulled in the .mov001-.mov020 files into Cinelerra and found that only the clips on the main Cinelerra host (where the GUI was running) appeared to have rendered properly. The files rendered by the other hosts were comparable in size but Cinelerra
Re: [CinCVS] New Bounty: Rendering directly to the MPEG PS container. 200 EUR
On Tue, 30 May 2006, Nathan Kurz wrote: >The only problem with YUV4MPEG is that it is video only. The easiest >way to do this export is with a container that supports both audio and >video. DV is a convenient example of a format that meets this need. >The worry about the encode/decode is valid, but if the original input >is DV, it will be used directly without that step. Hmm, I'd say the easiest way is with named pipes, e.g. mkfifo /tmp/video-pre-encode mkfifo /tmp/video-post-encode mkfifo /tmp/audio-pre-encode mkfifo /tmp/audio-post-encode ffmpeg -i /tmp/video-pre-encode -o /tmp/video-post-encode & ffmpeg -i /tmp/audio-pre-encode -o /tmp/audio-post-encode & mplex /tmp/video-post-encode /tmp/audio-post-encode -o but with changable names and changable standard DVD options. The generic form of this is simply to have a "named pipes" render target (i.e. video pipe and audio pipe) and allow any command line(s) to be background-run to process the pipes. >The other way to approach this problem is to use YUV4MPEG (or similar >uncompressed format), and seperately export audio the same pipe that >it is using. This would be a fine solution too (perhaps even a better >one) although I think a little harder to implement. I certainly >wouldn't want to discourage anyone from doing it, though. I don't think the yuv4mpegpipe format allows for audio, so I don't know how that would be possible... -- Dan Streetman [EMAIL PROTECTED] - 186,272 miles per second: It isn't just a good idea, it's the law! ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] New Bounty: Rendering directly to the MPEG PS container. 200 EUR
On tor, 2006-05-30 at 10:49 -0600, Nathan Kurz wrote: > On Tue, May 30, 2006 at 01:39:31PM -0400, Dan Streetman wrote: > > > > On Tue, 30 May 2006, Nathan Kurz wrote: > > >In case anyone is thinking about this, one way to accomplish this > > >would be changing the DV output so it can be written to a pipe. > > >Currently, it uses fseek's that can only be done on files. Once it > > >can be piped out, one can use the ffmpeg toolchain to convert to from > > >piped DV to the finished DVD-ready output on the fly. > > > > I agree it's a great bounty (and motivation to do it, as I have been > > thinking about doing it for a while - all my cinelerra use is to make > > DVDs). I agree that using pipes with mplex is the way to go, but doesn't > > it make more sense to use yuv4mpeg excoding (or other uncompressed format > > that ffmpeg recognizes) out of cinelerra (i.e. into ffmpeg) instead of DV? > > Encoding to DV would just waste CPU cycles, as that would then have to be > > re-encoded into MPEG-2... > > The only problem with YUV4MPEG is that it is video only. The easiest > way to do this export is with a container that supports both audio and > video. DV is a convenient example of a format that meets this need. > The worry about the encode/decode is valid, but if the original input > is DV, it will be used directly without that step. > > The other way to approach this problem is to use YUV4MPEG (or similar > uncompressed format), and seperately export audio the same pipe that > it is using. This would be a fine solution too (perhaps even a better > one) although I think a little harder to implement. I certainly > wouldn't want to discourage anyone from doing it, though. > https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra The only _right_way_ is using ffmpeg library from cinelerra and producing the multiplexed files directly, without any pipes, middle-encoding or anything else. it's a week of work. not very hard actually (it is much much easier to do export support than import support for any choosen format). bye andraz ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] New Bounty: Rendering directly to the MPEG PS container. 200 EUR
On Tue, May 30, 2006 at 08:23:04PM +0200, Herman Robak wrote: > On Tue, 30 May 2006 17:07:12 +0200, Nathan Kurz <[EMAIL PROTECTED]> wrote: > > >On Tue, May 30, 2006 at 03:36:13PM +0200, Herman Robak wrote: > >>I offer 200 Euro to the one who adds MPEG Program Stream as one > >>of Cinelerra's output formats, with a DVD compability setting. > >> > >>Cinelerra already supports rendering raw MPEG video and audio streams, > >>but not simultaneously, and no multiplexing. This means Cinelerra > >>can not render DVD-ready MPEG2 files directly. > > > >That's a great bounty, Herman! > > > >In case anyone is thinking about this, one way to accomplish this > >would be changing the DV output so it can be written to a pipe. > >Currently, it uses fseek's that can only be done on files. Once it > >can be piped out, one can use the ffmpeg toolchain to convert to from > >piped DV to the finished DVD-ready output on the fly. > > This will certainly be faster, skipping decoding and display in > Cinelerra if no effects are applied. But I want generic MPEG support, > from all input formats. > > I may consider a smaller bounty for a DV pipe. > > Another challenge: Pass-through rendering of any codec, re-encoding > only those frames whose keyframe has been cut away. I would suggest > giving MPEG2 from DVD, DVB and HDV sources priority. > > Now, is there any means of money transfer, except PayPal, that is > not laden with ridiculous fees? > > -- > Herman Robak Isn't it possible to render both an m2v file with mpeg2enc, then render an ac3 file and then mplex everything? That would need to set up a folder where to put the temporary stock the files. Cinelerra would need to be adapted in order to automate the 2 rendering tasks and the mplexing. I don't see any way to mplex 2 streams which are actually being rendered... However, I think it really would be nice to be able to modify the mpeg2enc parameters. Sometimes, it's necessary to use yuvdenoise. Being able to modify the pipe command would also be nice... Nicolas, Paris. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] New Bounty: Rendering directly to the MPEG PS container. 200 EUR
On Tue, 30 May 2006 18:49:52 +0200, Nathan Kurz <[EMAIL PROTECTED]> wrote: On Tue, May 30, 2006 at 01:39:31PM -0400, Dan Streetman wrote: I agree it's a great bounty (and motivation to do it, as I have been thinking about doing it for a while - all my cinelerra use is to make DVDs). I agree that using pipes with mplex is the way to go, but doesn't it make more sense to use yuv4mpeg excoding (or other uncompressed format that ffmpeg recognizes) out of cinelerra (i.e. into ffmpeg) instead of DV? Encoding to DV would just waste CPU cycles, as that would then have to be re-encoded into MPEG-2... The only problem with YUV4MPEG is that it is video only. The easiest way to do this export is with a container that supports both audio and video. DV is a convenient example of a format that meets this need. The worry about the encode/decode is valid, but if the original input is DV, it will be used directly without that step. The other way to approach this problem is to use YUV4MPEG (or similar uncompressed format), and seperately export audio the same pipe that it is using. This would be a fine solution too (perhaps even a better one) although I think a little harder to implement. I certainly wouldn't want to discourage anyone from doing it, though. Pipes and scripts are very UNIX-y and familiar for the tinkerers among us who are used to the command line. However, it is not a performance winner, and it is a rather clunky gum-and-gaffa design. They are nice as workarounds, but I wish we would take the time to step back and look for a greater _design_. Like, could Cinelerra's rendering integrate with Gstreamer? -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] New Bounty: Rendering directly to the MPEG PS container. 200 EUR
On Tue, 30 May 2006 17:07:12 +0200, Nathan Kurz <[EMAIL PROTECTED]> wrote: On Tue, May 30, 2006 at 03:36:13PM +0200, Herman Robak wrote: I offer 200 Euro to the one who adds MPEG Program Stream as one of Cinelerra's output formats, with a DVD compability setting. Cinelerra already supports rendering raw MPEG video and audio streams, but not simultaneously, and no multiplexing. This means Cinelerra can not render DVD-ready MPEG2 files directly. That's a great bounty, Herman! In case anyone is thinking about this, one way to accomplish this would be changing the DV output so it can be written to a pipe. Currently, it uses fseek's that can only be done on files. Once it can be piped out, one can use the ffmpeg toolchain to convert to from piped DV to the finished DVD-ready output on the fly. This will certainly be faster, skipping decoding and display in Cinelerra if no effects are applied. But I want generic MPEG support, from all input formats. I may consider a smaller bounty for a DV pipe. Another challenge: Pass-through rendering of any codec, re-encoding only those frames whose keyframe has been cut away. I would suggest giving MPEG2 from DVD, DVB and HDV sources priority. Now, is there any means of money transfer, except PayPal, that is not laden with ridiculous fees? -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra & RMLL
unfortunetly not... I have a friend that could do something but dunno his level really and he want to make ardour too... but it could be good to have a very good user and that know a little bit about patching & devel of cinelerra... to have a point on the CVS activity compare to the heroine devel... you see what I mean it's very important cheers julien Did you get anyone from this list to hold a workshop? It would be really nice if someone could... bye andraz On pon, 2006-04-17 at 13:59 +0200, joke wrote: Hello Cinelerrors ;-) I am curating the audio/video programme for RMLL that will happen in Nancy this year http://www.rmll.info and I would like to have Cinelerra workshop & conf on track. I would like to know if there is people interested to come to present Cinelerra and do a workshop on how to use it? It's in Nancy from 4th to 8th of July you could send me answers offline if you want. it could a place of cinelerra users meeting also... that's an idea... :-) cheers Julkien http://www.apodio.org http://www.apo33.org http://www.rmll.info ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] New Bounty: Rendering directly to the MPEG PS container. 200 EUR
On Tue, May 30, 2006 at 01:39:31PM -0400, Dan Streetman wrote: > > On Tue, 30 May 2006, Nathan Kurz wrote: > >In case anyone is thinking about this, one way to accomplish this > >would be changing the DV output so it can be written to a pipe. > >Currently, it uses fseek's that can only be done on files. Once it > >can be piped out, one can use the ffmpeg toolchain to convert to from > >piped DV to the finished DVD-ready output on the fly. > > I agree it's a great bounty (and motivation to do it, as I have been > thinking about doing it for a while - all my cinelerra use is to make > DVDs). I agree that using pipes with mplex is the way to go, but doesn't > it make more sense to use yuv4mpeg excoding (or other uncompressed format > that ffmpeg recognizes) out of cinelerra (i.e. into ffmpeg) instead of DV? > Encoding to DV would just waste CPU cycles, as that would then have to be > re-encoded into MPEG-2... The only problem with YUV4MPEG is that it is video only. The easiest way to do this export is with a container that supports both audio and video. DV is a convenient example of a format that meets this need. The worry about the encode/decode is valid, but if the original input is DV, it will be used directly without that step. The other way to approach this problem is to use YUV4MPEG (or similar uncompressed format), and seperately export audio the same pipe that it is using. This would be a fine solution too (perhaps even a better one) although I think a little harder to implement. I certainly wouldn't want to discourage anyone from doing it, though. --nate ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] 2vuy codec -- bounty offered!
On Tue, May 30, 2006 at 07:53:03AM -0400, Joe Stewart wrote: > On Sunday 28 May 2006 15:40, Andraz Tori wrote: > > Please do it :) and don't forget to collect the bounty :) > > The bounty has been collected (thanks, Heikki!), so I guess someone > should update the web page. There are no other bounties listed anymore, > so I guess everyone now has all the features they'd like to see in > Cinelerra-CV, right? :) lol! =) Nicolas. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] [Bug 267] Mixing transition types on the same track doesn't work
http://bugs.cinelerra.org/show_bug.cgi?id=267 --- Additional Comments From [EMAIL PROTECTED] 2006-05-30 19:50 --- Sweet, sorry for the style tweaks, but I was just unable to read the code the way it was written :D --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] New Bounty: Rendering directly to the MPEG PS container. 200 EUR
On Tue, 30 May 2006, Nathan Kurz wrote: >On Tue, May 30, 2006 at 03:36:13PM +0200, Herman Robak wrote: >> I offer 200 Euro to the one who adds MPEG Program Stream as one >> of Cinelerra's output formats, with a DVD compability setting. >> >> Cinelerra already supports rendering raw MPEG video and audio streams, >> but not simultaneously, and no multiplexing. This means Cinelerra >> can not render DVD-ready MPEG2 files directly. > >That's a great bounty, Herman! > >In case anyone is thinking about this, one way to accomplish this >would be changing the DV output so it can be written to a pipe. >Currently, it uses fseek's that can only be done on files. Once it >can be piped out, one can use the ffmpeg toolchain to convert to from >piped DV to the finished DVD-ready output on the fly. I agree it's a great bounty (and motivation to do it, as I have been thinking about doing it for a while - all my cinelerra use is to make DVDs). I agree that using pipes with mplex is the way to go, but doesn't it make more sense to use yuv4mpeg excoding (or other uncompressed format that ffmpeg recognizes) out of cinelerra (i.e. into ffmpeg) instead of DV? Encoding to DV would just waste CPU cycles, as that would then have to be re-encoded into MPEG-2... -- Dan Streetman [EMAIL PROTECTED] - 186,272 miles per second: It isn't just a good idea, it's the law! ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] New Bounty: Rendering directly to the MPEG PS container. 200 EUR
On Tuesday 30 May 2006 11:07, Nathan Kurz wrote: > In case anyone is thinking about this, one way to accomplish this > would be changing the DV output so it can be written to a pipe. > Currently, it uses fseek's that can only be done on files. Once it > can be piped out, one can use the ffmpeg toolchain to convert to from > piped DV to the finished DVD-ready output on the fly. Isn't that similar to the YUV4MPEG stream encoder, pretty much? I haven't tried it, but does Eric Seigne's cinelerra_ffmpeg.sh script produce satisfactory DVD/VCD files at this time that meet the criteria of the bounty? If you didn't take a look when Eric posted, it, check out http://e.rycks.com/~erics/cinelerra_custom_exports.png If it already does a good job, I'm not sure if it's worth writing the DVD/VCD mplexing stuff into Cinelerra, as it provides that and much more. A quick addition to the script and you've got whatever encoding format you want as long as ffmpeg supports it. I'll probably be adding a video-iPod preset to it if someone doesn't beat me to it. -Joe ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] [Bug 267] Mixing transition types on the same track doesn't work
http://bugs.cinelerra.org/show_bug.cgi?id=267 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-05-30 18:20 --- Maxime: I've applied just the heart of your patch without the style changes... https://init.linpro.no/pipermail/skolelinux.no/cinelerra-commits/2006-May/001369.html --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] New Bounty: Rendering directly to the MPEG PS container. 200 EUR
On Tue, May 30, 2006 at 03:36:13PM +0200, Herman Robak wrote: > I offer 200 Euro to the one who adds MPEG Program Stream as one > of Cinelerra's output formats, with a DVD compability setting. > > Cinelerra already supports rendering raw MPEG video and audio streams, > but not simultaneously, and no multiplexing. This means Cinelerra > can not render DVD-ready MPEG2 files directly. That's a great bounty, Herman! In case anyone is thinking about this, one way to accomplish this would be changing the DV output so it can be written to a pipe. Currently, it uses fseek's that can only be done on files. Once it can be piped out, one can use the ffmpeg toolchain to convert to from piped DV to the finished DVD-ready output on the fly. --nate ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] [Bug 267] Mixing transition types on the same track doesn't work
http://bugs.cinelerra.org/show_bug.cgi?id=267 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #153 is|0 |1 obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2006-05-30 17:57 --- Created an attachment (id=154) --> (http://bugs.cinelerra.org/attachment.cgi?id=154&action=view) Fix proposal for the transition_server reinit Better fix for the transition_server reinit problem. Partial rewrite of the update_transition() function, using the transition_server's plugin info if available instead of a prev_transition thingy. Tested and working, needs reviewal. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: Bezier curve alternative?
servus hermann, ich hatte heute vorsingen bei der anke eggers, lief super und sie will mir morgen gleich eine stunde geben. ich komm also erst spät abends morgen oder übermorgen nach hause. besuch in petershausen überlebt? in berlin gibts ja medienwirksame messerstecher, von denen ich glücklicherweise nichts mitbekommen hab. bis bald gabriel -- Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] [Bug 267] Mixing transition types on the same track doesn't work
http://bugs.cinelerra.org/show_bug.cgi?id=267 --- Additional Comments From [EMAIL PROTECTED] 2006-05-30 15:54 --- You're right, it would be better to check between the current transition and the one loaded into the transition_server. Unfortunately, my Cinelerra codebase knowledge pretty much ends here. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] New Bounty: Rendering directly to the MPEG PS container. 200 EUR
I offer 200 Euro to the one who adds MPEG Program Stream as one of Cinelerra's output formats, with a DVD compability setting. Cinelerra already supports rendering raw MPEG video and audio streams, but not simultaneously, and no multiplexing. This means Cinelerra can not render DVD-ready MPEG2 files directly. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] 2vuy codec -- bounty offered!
On Sunday 28 May 2006 15:40, Andraz Tori wrote: > Please do it :) and don't forget to collect the bounty :) The bounty has been collected (thanks, Heikki!), so I guess someone should update the web page. There are no other bounties listed anymore, so I guess everyone now has all the features they'd like to see in Cinelerra-CV, right? :) -Joe ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra & RMLL
Did you get anyone from this list to hold a workshop? It would be really nice if someone could... bye andraz On pon, 2006-04-17 at 13:59 +0200, joke wrote: > Hello Cinelerrors ;-) > > I am curating the audio/video programme for RMLL that will happen in > Nancy this year http://www.rmll.info and I would like to have Cinelerra > workshop & conf on track. I would like to know if there is people > interested to come to present Cinelerra and do a workshop on how to use it? > > It's in Nancy from 4th to 8th of July > > you could send me answers offline if you want. > > it could a place of cinelerra users meeting also... that's an idea... :-) > > cheers > > Julkien > > > http://www.apodio.org > http://www.apo33.org > http://www.rmll.info > > ___ > Cinelerra mailing list > Cinelerra@skolelinux.no > https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] [Bug 267] Mixing transition types on the same track doesn't work
http://bugs.cinelerra.org/show_bug.cgi?id=267 --- Additional Comments From [EMAIL PROTECTED] 2006-05-30 13:35 --- that does not explain the last question.. shouldn't we be looking at server ? maybe there is a simpler way to simply check which plugin is loaded into server, instead of trying to do our own bookkeeping? --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] [Bug 267] Mixing transition types on the same track doesn't work
http://bugs.cinelerra.org/show_bug.cgi?id=267 --- Additional Comments From [EMAIL PROTECTED] 2006-05-30 13:07 --- Andraz : uncomment the debug messages, you'll quickly understand why I tweaked the logic. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] [Bug 267] Mixing transition types on the same track doesn't work
http://bugs.cinelerra.org/show_bug.cgi?id=267 --- Additional Comments From [EMAIL PROTECTED] 2006-05-30 12:24 --- maxime.. i understand first part of your patch: + Plugin *prev_transition = NULL; + + if (transition) + prev_transition = transition; + which is clearly "the right thing"... but what's the point of the last check ... deiniting server on: +(transition && transition_server && !prev_transition)) ... i see no point in this case...? if there is no prev_transition, why should we deinit? ... i think this problem needs a bit more thought... "prev_transition" should be associated with transition_server ... not with transition immediately before the one we are rendering... --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
