Re: [CinCVS] Cinelerra generating files that ffmpeg can't read
> I haven't looked at your output files yet. But I'm familiar with the fact > that cinelerras AVI output is causing trouble all the time. Therefore, > I'm only using MOV format (Qicktime for linux). FFmpeg doesn't > seem to have problems with it. My understanding is that MOV format involves lossy compression and AVI (with DV compression) does not. Is that true? If not, I can just switch to MOV and forget about the problem. But I hate to lose quality in my editing process. -- Geoff Kuenning [EMAIL PROTECTED] http://www.cs.hmc.edu/~geoff/ The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" (I found it!) but "That's funny ..." -- Isaac Asimov ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra generating files that ffmpeg can't read
Hi Geoff, I haven't looked at your output files yet. But I'm familiar with the fact that cinelerras AVI output is causing trouble all the time. Therefore, I'm only using MOV format (Qicktime for linux). FFmpeg doesn't seem to have problems with it. But I agree, it would be a very good idea to fix the AVI output Toby ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Cinelerra generating files that ffmpeg can't read
I'm trying to chase down a Cinelerra/ffmpeg interaction problem. The short version is that I can render two selections from the same EDL, using exactly the same parameters, and one will pass through ffmpeg without trouble while the second causes ffmpeg to refuse to process video frames. I've dug into the ffmpeg end just enough to guess (but not be certain) that ffmpeg is seeing only the audio portion of the file. My problem is that I don't know enough about video formats to even guess whether it's Cinelerra or ffmpeg that is messing up. Thus, I'm seeking hints on how I might attack this problem further. Ideally, I'd like to be able to analyze the failing file well enough to determine whether it's corrupt (indicating a Cinelerra problem) or healthy (indicating that ffmpeg is the culprit). If anybody has any suggestions on further debugging approaches, I would greatly appreciate it. If anyone wants to try to reproduce the problem on their own, here's what I did: I generated the files by selecting a portion of the timeline and then rendering it, choosing "Microsoft AVI" as the file format. For audio options, I chose 2's complement, 16-bit linear. For video, I chose DV compression. I disabled "Create new file at each label". The first file, which is available at: http://www.cs.hmc.edu/~geoff/foo_ok.avi is from the beginning of my movie. It's just 5 seconds of "Paste silence", which is 23 MB. The second file, available at: http://www.cs.hmc.edu/~geoff/foo_bad.avi is (unfortunately) 153 MB, because despite repeated attempts I couldn't generate anything shorter that fails. I created the selection by double-clicking on a short clip and rendering exactly as above. (Double-clicking on even shorter clips didn't generate a failing file.) I apologize for the sizes of these files, and I will continue trying to create smaller test cases. If I succeed, I will replace the posted versions with the smaller ones. For both clips, I then tried "ffmpeg -i foo_ok.avi -ac 2 -ar 48000 foo_ok.dv" (or the equivalent for foo_bad). Foo_ok converts without difficulty. But foo_bad stops at video frame 1. By using dd to extract prefixes of foo_bad and doing a bit of binary searching, I was able to determine that the trailer of the file is somehow involved. If I trim off 20304 or more bytes (leaving a file of size 152600834 or less), then ffmpeg doesn't hang. If I use more of the file, up to its full size of 152621138 bytes, then the hang happens. This behavior confuses me: if there is a trailer involved, why doesn't ffmpeg just choke when it's not present? Or is there something wrong with the last frame that somehow causes ffmpeg to get stuck on the first? -- Geoff Kuenning [EMAIL PROTECTED] http://www.cs.hmc.edu/~geoff/ The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair. -- Douglas Adams ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: Chromakey(HSV) math errors
Heroine Virtual Ltd. wrote: > By the way, your equations for "av" and "avm" still use "s". > Finally, you're still using 1/2 everywhere. At least in gcc, this > evaluates to 0 which works. > Actually using 0.5 breaks it. and there's a couple of other typos as well... like an as=as and so forth I've attached a patch against CVS that should fix it for good (I hope) This version looks OK on the footage I use, which is a bad test, but I didn't get around to do a synthetic test bench that could make sure of the correctness. > In 7 years of designing chromakey effects, hue keying has always > produced the coarsest results. > The reason is hue only has 1/3 the information of the color cube. > Chromakeying with 8 bit consumer > cameras doesn't work. You can spend a lot of time desigining > chromakey algorithms and learn about > software engineering that way, but you're not going to get very far. The reason why I personally like hue keying is that it's less precise :-) The other reason I like it is that it's a bit more intuitive to tweak (purely a personal opinion). Consumer-grade video uses 4:2:0 or 4:1:1 chroma subsampling, so you end up pulling keys with a color information that's 4 times less dense (spatially) than luma anyway. How about doing a bilinear/bicubic interpolation of the chroma information (UV) when importing 4:2:0 footage ? That might dramatically improve the quality of keying/color processing in general (even for 4:2:2) ... Would that be a good idea or there is something else I'm not getting ? > You need really good lighting, perfectly consistent mattes, and a 10 > bit camera to get TV > weather forecast quality. To get cinematic quality, you need a lot of > manual artifact removal > in Cinepaint. At least you only have to airbrush 25fps. If you were > American you'd have to > airbrush 30fps. For professional work I agree 100%; for toying around, this does a good enough job for me... Hey, Cinelerra is the only decent free editor/compositor out there, so the kids making Star Wars fan films might want to do chroma keying with it :-) don't you think it's worth giving them the tools ? BTW, my only complain with the existing chromakey is that I can't use it for some reason. Is there a documentation/tutorial that explains how to set it ? Cheers, and thanks again for taking the trouble of pointing out my mistakes, Jerome --- chromakey.C.orig2006-04-10 09:39:12.970449639 -0400 +++ chromakey.C 2006-04-10 15:29:08.024599732 -0400 @@ -622,7 +622,7 @@ else if ((out_slope != 0) && (ABS (h - hk) < tolerance * 180)) ah = ABS (h - hk) / tolerance / 360;/* we scale alpha between 0 and 1/2 */ else if (ABS (h - hk) < tolerance_out * 180) - ah = 1 / 2 + ABS (h - hk) / tolerance_out / 360;/* we scale alpha between 1/2 and 1 */ + ah = 0.5 + ABS (h - hk) / tolerance_out / 360; /* we scale alpha between 1/2 and 1 */ else has_match = false; @@ -634,9 +634,9 @@ else if (s - sat >= min_s_in) as = 0; else if ((out_slope != 0) && (s - sat > min_s)) - as = (s - sat - min_s / min_s) / 2; + as = (s - sat - min_s) / (min_s * 2); else if (s - sat > min_s_out) - as = 1 / 2 + (s - sat - min_s_out) / (min_s_out * 2); + as = 0.5 + (s - sat - min_s_out) / (min_s_out * 2); else has_match = false; } @@ -649,9 +649,9 @@ else if (v >= min_v_in) av = 0; else if ((out_slope != 0) && (v > min_v)) - av = (s - min_v / min_v) / 2; + av = (v - min_v ) / (min_v * 2) ; else if (v > min_v_out) - av = 1 / 2 + (v - min_v_out) / (min_v_out * 2); + av = 0.5 + (v - min_v_out) / (min_v_out * 2); else has_match = false; } @@ -664,9 +664,9 @@ else if (v <= max_v_in) avm = 0; else if ((out_slope != 0) && (v < max_v)) - avm = (s - max_v / max_v) / 2; + avm = (v - max_v) / ( max_v * 2); else if (v < max_v_out) - avm = 1 / 2 + (v - max_v_out / max_v_out) / 2; + avm = 0.5 + (v - max_v_out ) / (max_v_out *2); else has_match = false; }
Re: [CinCVS] chromakey-hsv math error
Oops, no! This will all your footage, because... On Monday 10 April 2006 15:46, Jerome Cornet wrote: > - as = (s - sat - min_s / min_s) / 2; > + as = as = (s - sat - min_s) / (min_s * 2); ... this is undefined behavior: as is modified twice! ;)) Did you mean this? > + as = (s - sat - min_s) / (min_s * 2); -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Chromakey(HSV) math errors
> And yeah, I don't know what I was thinking... when I wrote that > The lines should read: > as = (s - sat - min_s) / (min_s * 2); > av = (s - min_v ) / (min_v * 2) ; > avm = 1 / 2 + (v - max_v_out ) / (max_v_out *2); > > And here's the patch (I modified another line for consistency) > > I did a quick test and it looks obviously better. > Let me know how that works out for you ! By the way, your equations for "av" and "avm" still use "s". Finally, you're still using 1/2 everywhere. At least in gcc, this evaluates to 0 which works. Actually using 0.5 breaks it. In 7 years of designing chromakey effects, hue keying has always produced the coarsest results. The reason is hue only has 1/3 the information of the color cube. Chromakeying with 8 bit consumer cameras doesn't work. You can spend a lot of time desigining chromakey algorithms and learn about software engineering that way, but you're not going to get very far. You need really good lighting, perfectly consistent mattes, and a 10 bit camera to get TV weather forecast quality. To get cinematic quality, you need a lot of manual artifact removal in Cinepaint. At least you only have to airbrush 25fps. If you were American you'd have to airbrush 30fps. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] chromakey-hsv math error
Sorry everyone, I've been out of commission for a long while and completely missed that discussion earlier on. Thanks a lot Andraz for reminding me :-) And yeah, I don't know what I was thinking... when I wrote that The lines should read: as = (s - sat - min_s) / (min_s * 2); av = (s - min_v ) / (min_v * 2) ; avm = 1 / 2 + (v - max_v_out ) / (max_v_out *2); And here's the patch (I modified another line for consistency) I did a quick test and it looks obviously better. Let me know how that works out for you ! Jerome --- plugins/chromakey-hsv/chromakey.C.orig 2006-04-10 09:39:12.970449639 -0400 +++ plugins/chromakey-hsv/chromakey.C 2006-04-10 09:40:33.673753816 -0400 @@ -634,7 +634,7 @@ else if (s - sat >= min_s_in) as = 0; else if ((out_slope != 0) && (s - sat > min_s)) - as = (s - sat - min_s / min_s) / 2; + as = as = (s - sat - min_s) / (min_s * 2); else if (s - sat > min_s_out) as = 1 / 2 + (s - sat - min_s_out) / (min_s_out * 2); else @@ -649,7 +649,7 @@ else if (v >= min_v_in) av = 0; else if ((out_slope != 0) && (v > min_v)) - av = (s - min_v / min_v) / 2; + av = (s - min_v ) / (min_v * 2) ; else if (v > min_v_out) av = 1 / 2 + (v - min_v_out) / (min_v_out * 2); else @@ -664,9 +664,9 @@ else if (v <= max_v_in) avm = 0; else if ((out_slope != 0) && (v < max_v)) - avm = (s - max_v / max_v) / 2; + avm = (s - max_v) / ( max_v * 2); else if (v < max_v_out) - avm = 1 / 2 + (v - max_v_out / max_v_out) / 2; + avm = 1 / 2 + (v - max_v_out ) / (max_v_out *2); else has_match = false; } Graham Evans wrote: > Heroine Virtual Ltd. wrote: > >> chromakey.C has a number of lines like: >> >>as = (s - sat - min_s / min_s) / 2; >> >> Did you mean >> > I'm not sure where the fellow is that encoded that plug-in but their > seemed be a problem with the plug-in where zero did not equal zero. > This was with the spill compensation level. If you set this to zero > you still have spill compensation. You can only totally eliminate > the effect by pushing the spill threshold up. > > A maths error of the kind you mention seems a likely cause. > > Graham > >>as = (s - sat - 1.0) / 2; >> >> or >> >>as = (s - (sat - min_s) / min_s) / 2; >> >> or >> >> as = ((s - sat - min_s) / min_s) / 2; >> >> These probably need parentheses to do the intended effect. Other >> problem lines are: >> >>av = (s - min_v / min_v) / 2; >>avm = 1 / 2 + (v - max_v_out / max_v_out) / 2; >> >> ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: issue with transitions
> On sre, 2006-03-22 at 04:32 +0100, Ichthyostega wrote: >>suddenly, I am struck with a strange issue affecting my dissolve transitions. Andraz Tori wrote: > I've debugged the issue, and the fix is attached and also already > applied to the SVN, please test it and report back. > > bye > andraž Hello Andraž, just installed the debian package 2006-04-07 (rebuilt it from source package to be more precise, because I didn't find a dynamic linkable libx264). Confirm, issue seems to be resolved, transitions work as expected. Many thanks for your efforts! As a sidenote: I meanwhile found out, why this issue showed up "suddenly", while seemingly working beforehand: The problem arouse only when track-temporary-size == project size. I had some old renders laying about, where obviousely there were no problems with transitions -- but this ones were rendered to a hight of 1088 while the track height is 1080 pixel. Don't ask me why this was the case, but anyhow, at the moment I rendered to 1080 pixels height, I was biten by the now fixed problem Cheers, Hermann ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
