Re: [CinCVS] Creating DVD from Cinelerra: input source
Hi, Thanks for trying to enlight me :) Johannes Sixt wrote: On Thursday 08 February 2007 13:20, Yannick Patois wrote: I tried some measurements myself, taking an original 720x576 image with some gauge grid and convered this in cinelerra according to: http://cvs.cinelerra.org/docs/split_manual_en/cinelerra_cv_manual_en_19.htm l#SEC256 What I saw, when looking at the resulting m2v file, is (roughly) a 680x480 crop of the image not 704x576. I didnt went up to the DVD but I belive that the cropped area wont reapear... Some Equipment displays only a subpart of the theoretically possible image. Live with it. That doesn't change the math, but you have to be careful that you don't put important information (like titles) too far to the borders. The problem is that the certain device is both cinelerra (in its Composer window) and xine (after rendering a m2v file according to the manual). I just looked in the cinelerra project XML and read stuff like: VIDEO INTERPOLATION_TYPE=0 INTERPOLATE_RAW=1 WHITE_BALANCE_RAW=1 COLORMODEL=RGBA-8 Bit INTERLACE_MODE=BOTTOM_FIELD_FIRST CHANNELS=1 VCHANNEL_X_0=0 VCHANNEL_Y_0=0 FRAMERATE=25 FRAMES_PER_FOOT=16 OUTPUTW=720 OUTPUTH=576 ASPECTW=4 ASPECTH=3/VIDEO VIDEO HEIGHT=576 WIDTH=720 LAYERS=1 FRAMERATE=1 VCODEC=rlea VIDEO_LENGTH=-1 INTERLACE_AUTOFIX=1 INTERLACE_MODE=UNKNOWN INTERLACE_FIXMETHOD=DO_NOTHING REEL_NAME=cin REEL_NUMBER=0 TCSTART=0 TCEND=0 TCFORMAT=0/VIDEO So it seems that I did my configuration well for 720x576... Does it seems normal? Thanks, Yannick -- _/ Yannick Patois _ Address (home) __ | irc(undernet): Garp on #france25+ | 7, rue de Brumath| | http://garp.feelingsurfer.net/| 67170 Rottelsheim| | Tel-home: +(33)(0)3 88 68 89 58 | FRANCE | | Le Portail des Copains : http://rezo.net | ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: audio sync problem on rendered output, but not when viewing in compositor
maybe it's getting off topic, but i had similar sync problems with different recording speeds between one of the camcorders and the mini-disk-recorder in a multi-track project. (i solved it by just leaving a blank frame in the camara track every now and then, to let the audio catch up. i agree this is not quite professional.) so i'd like to know how we do that syncronization? maybe start end all recordings with that classic wooden shutter? (don't know the exact term but you know, like the kino icon) thanks for a hint. georg Interesting. This drift stuff is a nightmare. Next recording, we'll sync to a clock source! :) -- dr.k.g.hooss schoepfung wandel wissenschaftliche medienberatung breite strasse 6-8, d-23617 luebeck www.schoepfung-und-wandel.de ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] mpeg decoding leak crush
Andraz,
As I have been suffering from the consequences of mpeg decoding leak, I am very
excited to test this when I get home this afternoon. Thanks!
One question: what is a crush?
scott
-- Original message --
From: Andraž Tori [EMAIL PROTECTED]
This is a fix for obvious leak when reopening mpeg from index files.
Previous fd was not released in all cases. Now it is.
This leak also caused crushes due to memory exaustion and creating extreme
number of waiting threads eventually... The way it crushed is not completely
obvious to me, but now the crush is gone.
Opening mpeg files that have index is still awfully inefficient, since every
file that already has TOC created is opened twice - first time just to read
the
number of video streams present. This could be done better...
bye
andraz
---BeginMessage---
diff -ru --exclude-from exclude hvirtual-svn/cinelerra/filempeg.C hvirtual-2.1/cinelerra/filempeg.C
--- hvirtual-svn/cinelerra/filempeg.C 2006-10-12 23:17:43.0 +0200
+++ hvirtual-2.1/cinelerra/filempeg.C 2007-02-09 13:26:29.0 +0100
@@ -523,13 +523,16 @@
sprintf(ptr, .toc);
- int need_toc = 1;
+ mpeg3_t *fd_toc;
-// Test existing copy of TOC
- if((fd = mpeg3_open(index_filename, error)))
- need_toc = 0;
- if(need_toc)
+// Test existing copy of TOC
+ mpeg3_close(fd); // Always free old fd
+ if((fd_toc = mpeg3_open(index_filename, error)))
+ {
+// Just exchange old fd
+ fd = fd_toc;
+ } else
{
// Create progress window.
// This gets around the fact that MWindowGUI is locked.
@@ -596,26 +599,10 @@
remove(index_filename);
return 1;
}
- else
-// Fix date to date of source if success
- {
- }
-
- if(fd) mpeg3_close(fd);
- fd = 0;
- }
-
-
// Reopen file from index path instead of asset path.
- if(!fd)
- {
if(!(fd = mpeg3_open(index_filename, error)))
- {
return 1;
- }
- else
- return 0;
}
return 0;
---End Message---
Re: [CinCVS] compiling from source on ubuntu error
patrick wrote: hey guys, anyone can help me with this: make[2]: Leaving directory `/home/pat/11h11/yeux/cinelerra-2.1/libsndfile-1.0.11' make -C quicktime /bin/sh: -c: line 1: syntax error: unexpected end of file /bin/sh: i686/c_flags: No such file or directory /bin/sh: i686/lame_flags: No such file or directory /bin/sh: i686/objs: No such file or directory make[2]: Entering directory `/home/pat/11h11/yeux/cinelerra-2.1/quicktime' make[2]: *** No rule to make target `i686', needed by `all'. Stop. make[2]: Leaving directory `/home/pat/11h11/yeux/cinelerra-2.1/quicktime' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/pat/11h11/yeux/cinelerra-2.1' make: *** [all] Error 2 what should i do? pat ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra Pat, This looks a lot like one of the problems I had when I tried to compile on my Debian system using the source code from the Heroine Virtual Ltd web page at: http://heroinewarrior.com/ The problem has to do (I think) with versions of the make program itself. The one in Debian does not handle the form of shell access being used. So I'd first suggest that you get the source from cvs.cinelerra.org. But, if you've already got that source, you could take a look in the Makefile at the line involved to see what it's trying to do. I believe it's making a directory called 'i686', and because the 'mkdir' failed, later access to that location also fails. If this is true, just make the directory by hand and comment out the offending line in the Makefile, and see if that fixes the issue. Be aware that I found this problem with almost every Makefile in the Heroine Virtual source package. And, if the source you're using is from cvs.cinelerra.org, I'd suggest also filing a bug (but *only* in that case - the source from Heroine Virtual works OK with the make used Red Hat/Fedora, so it's not a bug in that environment). Bob smime.p7s Description: S/MIME Cryptographic Signature
Re: [CinCVS] mpeg decoding leak crush
please try out new builds so we will know if this fixes your problems or not... report back please. bye andraz On Fri, 2007-02-09 at 15:00 +, [EMAIL PROTECTED] wrote: Andraz, As I have been suffering from the consequences of mpeg decoding leak, I am very excited to test this when I get home this afternoon. Thanks! One question: what is a crush? scott -- Original message -- From: Andraž Tori [EMAIL PROTECTED] This is a fix for obvious leak when reopening mpeg from index files. Previous fd was not released in all cases. Now it is. This leak also caused crushes due to memory exaustion and creating extreme number of waiting threads eventually... The way it crushed is not completely obvious to me, but now the crush is gone. Opening mpeg files that have index is still awfully inefficient, since every file that already has TOC created is opened twice - first time just to read the number of video streams present. This could be done better... bye andraz email message attachment Forwarded Message From: Andraž Tori [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: cinelerra@skolelinux.no cinelerra@skolelinux.no Subject: [CinCVS] mpeg decoding leak crush Date: Fri, 9 Feb 2007 12:44:02 + ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] mpeg decoding leak crush
Hi Andraz,
I compiled v989. I did a warm reboot of the box for a fresh start. My
computer configuration specs are here:
http://content.serveftp.net/video/qtcompatibility.ods.html
I am using my project that I had described in my audio sync problem
post. It has one 720P HDV (MPEGTS) video track with two stereo audio
tracks (one wav/one mp2) at 48kHz. You can refer to my previous post
for the exact details of the project format stats.
I monitored top while I performed a few operations in Cinelerra. I
only used Cinelerra during the test interval:
operation mem used
before starting cinelerra 297MB
after starting cinelerra500MB
open project605MB
play first 30s of vid 681MB
click and play diff 10s of vid 742MB
click and play diff 10s of vid 756MB
click and play diff 20s of vid 800MB
click and play last minute 915MB
select all in timeline 918MB
rendered audio as WAV 1036MB
click and play diff 30s of vid 1113MB
click and play diff 30s of vid 1165MB
render video using ffmpeg
(cancel after five minutes)1342MB
apply histogram and play 30s 1367MB
quit cinelerra 1139MB
* 1139MB still used after quitting cinelerra
Here is the top output after quitting cinelerra:
Tasks: 117 total, 1 running, 116 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.5% us, 1.0% sy, 0.0% ni, 96.8% id, 0.0% wa, 0.3% hi,
0.3Mem: 2070884k total, 1143208k used, 927676k free,18604k
buffersSwap:0k total,0k used,0k free, 978248k
cached
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
2695 root 15 0 42668 17m 8684 S 1.7 0.8 0:04.27 gnome-termi
2588 root 14 -1 67572 26m 8304 S 1.3 1.3 1:18.39 X
oops..just realized swap not enabled on reboot. I will fix that.
if you need a test MPEGTS file from my cam to work with, here's one:
http://content.serveftp.net/video/jvchd10u_output.m2t
27MB
scott
After starting Cinelerra, my used memory read 590K. As I clicked in the
timeline and played back (about four times), the memory used grew to
about 720K. I then selected the entire track and hit shift-R to render.
My memory usage shot up to about 1.8MB. I rendered the audio to wav.
After rendering the wav audio,
On Fri, 2007-02-09 at 22:00 +0100, Andraž Tori wrote:
please try out new builds so we will know if this fixes your problems or
not... report back please.
bye
andraz
On Fri, 2007-02-09 at 15:00 +, [EMAIL PROTECTED] wrote:
Andraz,
As I have been suffering from the consequences of mpeg decoding leak, I am
very excited to test this when I get home this afternoon. Thanks!
One question: what is a crush?
scott
-- Original message --
From: Andraž Tori [EMAIL PROTECTED]
This is a fix for obvious leak when reopening mpeg from index files.
Previous fd was not released in all cases. Now it is.
This leak also caused crushes due to memory exaustion and creating
extreme
number of waiting threads eventually... The way it crushed is not
completely
obvious to me, but now the crush is gone.
Opening mpeg files that have index is still awfully inefficient, since
every
file that already has TOC created is opened twice - first time just to
read the
number of video streams present. This could be done better...
bye
andraz
email message attachment
Forwarded Message
From: Andraž Tori [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: cinelerra@skolelinux.no cinelerra@skolelinux.no
Subject: [CinCVS] mpeg decoding leak crush
Date: Fri, 9 Feb 2007 12:44:02 +
___
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
Re: [CinCVS] mpeg decoding leak crush
I don't know wat exactly you want to tell me... btw: total memory used in top is wrong metric by any means. you should just be looking at VIRT and RES columns for each application, cinelerra in this case... if virt number goes up to a gig or more and keeps going up, then something is wrong, if not, cinelerra is working ok... yes, it needs quite some memory bye andraz On Fri, 2007-02-09 at 16:42 -0500, Scott C. Frase wrote: Hi Andraz, I compiled v989. I did a warm reboot of the box for a fresh start. My computer configuration specs are here: http://content.serveftp.net/video/qtcompatibility.ods.html I am using my project that I had described in my audio sync problem post. It has one 720P HDV (MPEGTS) video track with two stereo audio tracks (one wav/one mp2) at 48kHz. You can refer to my previous post for the exact details of the project format stats. I monitored top while I performed a few operations in Cinelerra. I only used Cinelerra during the test interval: operation mem used before starting cinelerra 297MB after starting cinelerra500MB open project605MB play first 30s of vid 681MB click and play diff 10s of vid 742MB click and play diff 10s of vid 756MB click and play diff 20s of vid 800MB click and play last minute 915MB select all in timeline 918MB rendered audio as WAV 1036MB click and play diff 30s of vid 1113MB click and play diff 30s of vid 1165MB render video using ffmpeg (cancel after five minutes)1342MB apply histogram and play 30s 1367MB quit cinelerra 1139MB * 1139MB still used after quitting cinelerra Here is the top output after quitting cinelerra: Tasks: 117 total, 1 running, 116 sleeping, 0 stopped, 0 zombie Cpu(s): 1.5% us, 1.0% sy, 0.0% ni, 96.8% id, 0.0% wa, 0.3% hi, 0.3Mem: 2070884k total, 1143208k used, 927676k free,18604k buffersSwap:0k total,0k used,0k free, 978248k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 2695 root 15 0 42668 17m 8684 S 1.7 0.8 0:04.27 gnome-termi 2588 root 14 -1 67572 26m 8304 S 1.3 1.3 1:18.39 X oops..just realized swap not enabled on reboot. I will fix that. if you need a test MPEGTS file from my cam to work with, here's one: http://content.serveftp.net/video/jvchd10u_output.m2t 27MB scott After starting Cinelerra, my used memory read 590K. As I clicked in the timeline and played back (about four times), the memory used grew to about 720K. I then selected the entire track and hit shift-R to render. My memory usage shot up to about 1.8MB. I rendered the audio to wav. After rendering the wav audio, On Fri, 2007-02-09 at 22:00 +0100, Andraž Tori wrote: please try out new builds so we will know if this fixes your problems or not... report back please. bye andraz On Fri, 2007-02-09 at 15:00 +, [EMAIL PROTECTED] wrote: Andraz, As I have been suffering from the consequences of mpeg decoding leak, I am very excited to test this when I get home this afternoon. Thanks! One question: what is a crush? scott -- Original message -- From: Andraž Tori [EMAIL PROTECTED] This is a fix for obvious leak when reopening mpeg from index files. Previous fd was not released in all cases. Now it is. This leak also caused crushes due to memory exaustion and creating extreme number of waiting threads eventually... The way it crushed is not completely obvious to me, but now the crush is gone. Opening mpeg files that have index is still awfully inefficient, since every file that already has TOC created is opened twice - first time just to read the number of video streams present. This could be done better... bye andraz email message attachment Forwarded Message From: Andraž Tori [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: cinelerra@skolelinux.no cinelerra@skolelinux.no Subject: [CinCVS] mpeg decoding leak crush Date: Fri, 9 Feb 2007 12:44:02 + ___ 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 ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] mpeg decoding leak crush
Andraz, Disregard the comments below my signature scott in the email. That text was the original version of the email that I discarded. scott On Fri, 2007-02-09 at 16:42 -0500, Scott C. Frase wrote: Hi Andraz, I compiled v989. I did a warm reboot of the box for a fresh start. My computer configuration specs are here: http://content.serveftp.net/video/qtcompatibility.ods.html I am using my project that I had described in my audio sync problem post. It has one 720P HDV (MPEGTS) video track with two stereo audio tracks (one wav/one mp2) at 48kHz. You can refer to my previous post for the exact details of the project format stats. I monitored top while I performed a few operations in Cinelerra. I only used Cinelerra during the test interval: operation mem used before starting cinelerra 297MB after starting cinelerra500MB open project605MB play first 30s of vid 681MB click and play diff 10s of vid 742MB click and play diff 10s of vid 756MB click and play diff 20s of vid 800MB click and play last minute 915MB select all in timeline 918MB rendered audio as WAV 1036MB click and play diff 30s of vid 1113MB click and play diff 30s of vid 1165MB render video using ffmpeg (cancel after five minutes)1342MB apply histogram and play 30s 1367MB quit cinelerra 1139MB * 1139MB still used after quitting cinelerra Here is the top output after quitting cinelerra: Tasks: 117 total, 1 running, 116 sleeping, 0 stopped, 0 zombie Cpu(s): 1.5% us, 1.0% sy, 0.0% ni, 96.8% id, 0.0% wa, 0.3% hi, 0.3Mem: 2070884k total, 1143208k used, 927676k free,18604k buffersSwap:0k total,0k used,0k free, 978248k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 2695 root 15 0 42668 17m 8684 S 1.7 0.8 0:04.27 gnome-termi 2588 root 14 -1 67572 26m 8304 S 1.3 1.3 1:18.39 X oops..just realized swap not enabled on reboot. I will fix that. if you need a test MPEGTS file from my cam to work with, here's one: http://content.serveftp.net/video/jvchd10u_output.m2t 27MB scott After starting Cinelerra, my used memory read 590K. As I clicked in the timeline and played back (about four times), the memory used grew to about 720K. I then selected the entire track and hit shift-R to render. My memory usage shot up to about 1.8MB. I rendered the audio to wav. After rendering the wav audio, On Fri, 2007-02-09 at 22:00 +0100, Andraž Tori wrote: please try out new builds so we will know if this fixes your problems or not... report back please. bye andraz On Fri, 2007-02-09 at 15:00 +, [EMAIL PROTECTED] wrote: Andraz, As I have been suffering from the consequences of mpeg decoding leak, I am very excited to test this when I get home this afternoon. Thanks! One question: what is a crush? scott -- Original message -- From: Andraž Tori [EMAIL PROTECTED] This is a fix for obvious leak when reopening mpeg from index files. Previous fd was not released in all cases. Now it is. This leak also caused crushes due to memory exaustion and creating extreme number of waiting threads eventually... The way it crushed is not completely obvious to me, but now the crush is gone. Opening mpeg files that have index is still awfully inefficient, since every file that already has TOC created is opened twice - first time just to read the number of video streams present. This could be done better... bye andraz email message attachment Forwarded Message From: Andraž Tori [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: cinelerra@skolelinux.no cinelerra@skolelinux.no Subject: [CinCVS] mpeg decoding leak crush Date: Fri, 9 Feb 2007 12:44:02 + ___ 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 ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] mpeg decoding leak crush
Andraz, Alright then. It just seemed odd to me that so much memory would be used. I will keep an eye on the VIRT and RES columns for Cinelerra while I work on my project and let you know if the memory keeps rising above 1GB. scott On Fri, 2007-02-09 at 22:57 +0100, Andraž Tori wrote: I don't know wat exactly you want to tell me... btw: total memory used in top is wrong metric by any means. you should just be looking at VIRT and RES columns for each application, cinelerra in this case... if virt number goes up to a gig or more and keeps going up, then something is wrong, if not, cinelerra is working ok... yes, it needs quite some memory bye andraz On Fri, 2007-02-09 at 16:42 -0500, Scott C. Frase wrote: Hi Andraz, I compiled v989. I did a warm reboot of the box for a fresh start. My computer configuration specs are here: http://content.serveftp.net/video/qtcompatibility.ods.html I am using my project that I had described in my audio sync problem post. It has one 720P HDV (MPEGTS) video track with two stereo audio tracks (one wav/one mp2) at 48kHz. You can refer to my previous post for the exact details of the project format stats. I monitored top while I performed a few operations in Cinelerra. I only used Cinelerra during the test interval: operation mem used before starting cinelerra 297MB after starting cinelerra500MB open project605MB play first 30s of vid 681MB click and play diff 10s of vid 742MB click and play diff 10s of vid 756MB click and play diff 20s of vid 800MB click and play last minute 915MB select all in timeline 918MB rendered audio as WAV 1036MB click and play diff 30s of vid 1113MB click and play diff 30s of vid 1165MB render video using ffmpeg (cancel after five minutes)1342MB apply histogram and play 30s 1367MB quit cinelerra 1139MB * 1139MB still used after quitting cinelerra Here is the top output after quitting cinelerra: Tasks: 117 total, 1 running, 116 sleeping, 0 stopped, 0 zombie Cpu(s): 1.5% us, 1.0% sy, 0.0% ni, 96.8% id, 0.0% wa, 0.3% hi, 0.3Mem: 2070884k total, 1143208k used, 927676k free,18604k buffersSwap:0k total,0k used,0k free, 978248k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 2695 root 15 0 42668 17m 8684 S 1.7 0.8 0:04.27 gnome-termi 2588 root 14 -1 67572 26m 8304 S 1.3 1.3 1:18.39 X oops..just realized swap not enabled on reboot. I will fix that. if you need a test MPEGTS file from my cam to work with, here's one: http://content.serveftp.net/video/jvchd10u_output.m2t 27MB scott After starting Cinelerra, my used memory read 590K. As I clicked in the timeline and played back (about four times), the memory used grew to about 720K. I then selected the entire track and hit shift-R to render. My memory usage shot up to about 1.8MB. I rendered the audio to wav. After rendering the wav audio, On Fri, 2007-02-09 at 22:00 +0100, Andraž Tori wrote: please try out new builds so we will know if this fixes your problems or not... report back please. bye andraz On Fri, 2007-02-09 at 15:00 +, [EMAIL PROTECTED] wrote: Andraz, As I have been suffering from the consequences of mpeg decoding leak, I am very excited to test this when I get home this afternoon. Thanks! One question: what is a crush? scott -- Original message -- From: Andraž Tori [EMAIL PROTECTED] This is a fix for obvious leak when reopening mpeg from index files. Previous fd was not released in all cases. Now it is. This leak also caused crushes due to memory exaustion and creating extreme number of waiting threads eventually... The way it crushed is not completely obvious to me, but now the crush is gone. Opening mpeg files that have index is still awfully inefficient, since every file that already has TOC created is opened twice - first time just to read the number of video streams present. This could be done better... bye andraz email message attachment Forwarded Message From: Andraž Tori [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: cinelerra@skolelinux.no cinelerra@skolelinux.no Subject: [CinCVS] mpeg decoding leak crush Date: Fri, 9 Feb 2007 12:44:02 + ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no
[CinCVS] [Bug 335] HDV MPEGTS files not recognized by Cinelerra for auto toc creation
http://bugs.cinelerra.org/show_bug.cgi?id=335 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from [EMAIL PROTECTED] 2007-02-09 22:09 +2 --- now .m2t was added and this bug is fixed detection is still done by extension.. -- Configure bugmail: http://bugs.cinelerra.org/userprefs.cgi?tab=email --- 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 400] AAC audio .mov files not compliant
http://bugs.cinelerra.org/show_bug.cgi?id=400 --- Comment #1 from [EMAIL PROTECTED] 2007-02-09 22:30 +2 --- am i getting this right: the problem is that file produced by cinelerra does not work correctly in mplayer/ffmpeg and others? -- Configure bugmail: http://bugs.cinelerra.org/userprefs.cgi?tab=email --- 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 388] [PATCH] Add interpolation to ReframeRT effect
http://bugs.cinelerra.org/show_bug.cgi?id=388 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from [EMAIL PROTECTED] 2007-02-09 21:54 +2 --- commited... -- Configure bugmail: http://bugs.cinelerra.org/userprefs.cgi?tab=email --- 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 384] core dump when trying to open the following clip
http://bugs.cinelerra.org/show_bug.cgi?id=384 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://bugs.cinelerra.org/userprefs.cgi?tab=email --- 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 384] core dump when trying to open the following clip
http://bugs.cinelerra.org/show_bug.cgi?id=384 --- Comment #4 from [EMAIL PROTECTED] 2007-02-09 22:02 +2 --- i commited a simple patch and now this file loads properly -- Configure bugmail: http://bugs.cinelerra.org/userprefs.cgi?tab=email --- 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 329] Black screen in the compositor when the dissolve effect is used
http://bugs.cinelerra.org/show_bug.cgi?id=329 --- Comment #2 from [EMAIL PROTECTED] 2007-02-09 22:15 +2 --- funny thing this is... try going to x11 video driver instead of x11-xv ... i believe the problem is just when switching between drivers when accelereated option is available and where not... -- Configure bugmail: http://bugs.cinelerra.org/userprefs.cgi?tab=email --- 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 401] New: histogram output contaminating command line output
http://bugs.cinelerra.org/show_bug.cgi?id=401 Summary: histogram output contaminating command line output Product: Cinelerra Version: 2.1 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: Effects/Transitions AssignedTo: cinelerra@skolelinux.no ReportedBy: [EMAIL PROTECTED] When using X11-OpenGL video driver and histogram effect, the terminal window in which you've started Cinelerra will be contaminated with continuous lines of this same output: HistogramMain::handle_opengl 0 0 0 5 shader=1 Reproducible: Always Steps to Reproduce: 1. start cinelerra in terminal window 2. put video on project timeline 3. apply histogram effect and enable 4. click play 5. watch terminal window fill up with repeating entries: HistogramMain::handle_opengl 0 0 0 5 shader=1 Remove this unnecessary output. -- Configure bugmail: http://bugs.cinelerra.org/userprefs.cgi?tab=email --- 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
