[CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
On Fri, Nov 5, 2010 at 8:55 PM, Johannes Sixt wrote: > On Freitag, 5. November 2010, Einar Rünkaru wrote: > >> Meanwhile I found some more simple bugfixes in my tree: >> >> commit:7f217eaa516881840a9d80549d6aedce5e012da3 >> Tue, 1 Jun 2010 13:19:29 + (16:19 +0300) >> Changed return type of Thread:get_tid() > > Good. > >> commit:443a5c8c3565304ea542430a6eba9f76c619bc96 >> Tue, 9 Mar 2010 20:53:17 + (22:53 +0200) >> Fix mmap errorcode > > I have this one already. > Sorry - didn't check what you have >> commit:c59748bc756686d5bd9f51e2374c108e9ef28d8e >> Thu, 11 Mar 2010 19:03:07 + (21:03 +0200) >> Fixed v4l2 detetection > > This removes #include from the test. What's wrong with it? This > #include was introduced because the test failed due to a missing typedef or > something. It may not today, but does it hurt? > On my system (Ubuntu 9.04) v4l2 check failed because of missing something required by As on my system includes , so removing '#include ' fixed compilation of the test. If there is any distribution which needs expllict inclusion time stuff, it is better to include sys/time.h - this must define all what is needed. Einar ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
On Freitag, 5. November 2010, Einar Rünkaru wrote: > On Thu, Nov 4, 2010 at 11:49 PM, Simeon Völkel wrote: > > Personally speaking I would prefer a release rather soon for the > > following reasons: > > > > 1. a "new version" should encourage distributions to build new packages > > which should decrease the time that has to be spend for answering "where > > can i get (the latest) packages for XY" > > > > 2. a "new version" should encourage users to look for "new (old) bugs", > > hopefully resulting in new tickets on bugs.cinelerra.org. Adding a new > > version there makes it easier to keep track of what is still an issue. > > (I'm aware that many old bugs aren't fixed yet, but we won't fix them all > > in finite time, so waiting for all bugs being fixed would prohibit the > > release of > 2.1 forever ;-)) > > > > 3. a "new version" might encourage someone to contribute again some > > patches, as he/she sees that something is going on with cinelerra. (e.g. > > gentoo's patches weren't forwarded to our ML at some point as nothing > > happened) > > > > 4. releasing other bugfix releases (e.g. 2.1.6) should become "easier" to > > do when a first step is done. > > > > Hannes, Monty, Einar, what do you think? (as you've contributed most of > > the new patches) > > I agree with all your points. I agree as well. > Meanwhile I found some more simple bugfixes in my tree: > > commit:7f217eaa516881840a9d80549d6aedce5e012da3 > Tue, 1 Jun 2010 13:19:29 + (16:19 +0300) > Changed return type of Thread:get_tid() Good. > commit:443a5c8c3565304ea542430a6eba9f76c619bc96 > Tue, 9 Mar 2010 20:53:17 + (22:53 +0200) > Fix mmap errorcode I have this one already. > commit:c59748bc756686d5bd9f51e2374c108e9ef28d8e > Thu, 11 Mar 2010 19:03:07 + (21:03 +0200) > Fixed v4l2 detetection This removes #include from the test. What's wrong with it? This #include was introduced because the test failed due to a missing typedef or something. It may not today, but does it hurt? -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
On Thu, Nov 4, 2010 at 11:49 PM, Simeon Völkel wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello Hannes, > > thanks for pushing out the latest changes. > > If i remember correctly we have now merged nearly everything that was > intended to be merged, except for one of Monty's alsa fixes, that caused > serious playback problems for Hannes. > > So what do we still want to merge before releasing Cin2.1.5CV? (except for > an update of the about page / version variable ;)) > > Personally speaking I would prefer a release rather soon for the following > reasons: > > 1. a "new version" should encourage distributions to build new packages > which should decrease the time that has to be spend for answering "where > can i get (the latest) packages for XY" > > 2. a "new version" should encourage users to look for "new (old) bugs", > hopefully resulting in new tickets on bugs.cinelerra.org. Adding a new > version there makes it easier to keep track of what is still an issue. > (I'm aware that many old bugs aren't fixed yet, but we won't fix them all > in finite time, so waiting for all bugs being fixed would prohibit the > release of > 2.1 forever ;-)) > > 3. a "new version" might encourage someone to contribute again some > patches, as he/she sees that something is going on with cinelerra. (e.g. > gentoo's patches weren't forwarded to our ML at some point as nothing > happened) > > 4. releasing other bugfix releases (e.g. 2.1.6) should become "easier" to > do when a first step is done. > > Hannes, Monty, Einar, what do you think? (as you've contributed most of the > new patches) > I agree with all your points. Meanwhile I found some more simple bugfixes in my tree: commit:7f217eaa516881840a9d80549d6aedce5e012da3 Tue, 1 Jun 2010 13:19:29 + (16:19 +0300) Changed return type of Thread:get_tid() commit:443a5c8c3565304ea542430a6eba9f76c619bc96 Tue, 9 Mar 2010 20:53:17 + (22:53 +0200) Fix mmap errorcode commit:c59748bc756686d5bd9f51e2374c108e9ef28d8e Thu, 11 Mar 2010 19:03:07 + (21:03 +0200) Fixed v4l2 detetection These may be included too. Quite formal fixes. Einar ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Hannes, thanks for pushing out the latest changes. If i remember correctly we have now merged nearly everything that was intended to be merged, except for one of Monty's alsa fixes, that caused serious playback problems for Hannes. So what do we still want to merge before releasing Cin2.1.5CV? (except for an update of the about page / version variable ;)) Personally speaking I would prefer a release rather soon for the following reasons: 1. a "new version" should encourage distributions to build new packages which should decrease the time that has to be spend for answering "where can i get (the latest) packages for XY" 2. a "new version" should encourage users to look for "new (old) bugs", hopefully resulting in new tickets on bugs.cinelerra.org. Adding a new version there makes it easier to keep track of what is still an issue. (I'm aware that many old bugs aren't fixed yet, but we won't fix them all in finite time, so waiting for all bugs being fixed would prohibit the release of > 2.1 forever ;-)) 3. a "new version" might encourage someone to contribute again some patches, as he/she sees that something is going on with cinelerra. (e.g. gentoo's patches weren't forwarded to our ML at some point as nothing happened) 4. releasing other bugfix releases (e.g. 2.1.6) should become "easier" to do when a first step is done. Hannes, Monty, Einar, what do you think? (as you've contributed most of the new patches) With best regards, Simeon On 11/04/10 21:08, Johannes Sixt wrote: > On Mittwoch, 3. November 2010, Simeon Völkel wrote: >> I've just reformatted Monty's three patches you hadn't committed yet due to >> their formatting. They are now available in my git repo, together with an >> extended commit message written my Monty. I hope you can merge them now >> into your repo, so that we get a step closer to the release of Cin2.1.5CV. > > Thanks, I appreciate it. > > I pushed out these patches, but I substituted Monty as author. (I hope you > don't mind.) nope, just wasn't aware of how to do that :) > > -- Hannes -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzTKmEACgkQph/voQkhF7wnswCgiMqOwHb4qG8q3Q0Tktqx46AK NcoAn35VTNpfweWfTefdsB8Gup9Vpkao =027Z -END PGP SIGNATURE- ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
On Mittwoch, 3. November 2010, Simeon Völkel wrote: > I've just reformatted Monty's three patches you hadn't committed yet due to > their formatting. They are now available in my git repo, together with an > extended commit message written my Monty. I hope you can merge them now > into your repo, so that we get a step closer to the release of Cin2.1.5CV. Thanks, I appreciate it. I pushed out these patches, but I substituted Monty as author. (I hope you don't mind.) -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Hannes, I've just reformatted Monty's three patches you hadn't committed yet due to their formatting. They are now available in my git repo, together with an extended commit message written my Monty. I hope you can merge them now into your repo, so that we get a step closer to the release of Cin2.1.5CV. With best regards, Simeon -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzRxeQACgkQph/voQkhF7wHvACgmlcOMPDtMQ8n/PcRp2OnHGms 9FIAn2ero6ya+KrWl4L84Jyn6xEOxrj8 =GYWq -END PGP SIGNATURE- ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
On Sonntag, 31. Oktober 2010, Simeon Völkel wrote: > #define PIX_FMT_RGB32 PIX_FMT_NE(ARGB, BGRA) > #define PIX_FMT_RGB32_1 PIX_FMT_NE(RGBA, ABGR) > #define PIX_FMT_BGR32 PIX_FMT_NE(ABGR, RGBA) > #define PIX_FMT_BGR32_1 PIX_FMT_NE(BGRA, ARGB) > > > so at least the remark of it being destructive is wrong > > iirc the only thing this patch changed is the name: the two pixel formats > were #defined one onto the other but with libavutil 50, the one cinelerra > was using was gone. You'll have to check libavutil/pixfmt.h svn history in > ffmpeg svn if you want a 100% accurate answer there I'm afraid. I am worried that this regresses on big-endian machines because the new name expands to a different PIX_FMT code depending on the endianness whereas the old name indicated a particular byte order. But it might just be that this actually *fixes* a problem on big-endian. Since I can't tell which it is, I'll just take the patch and see what happens. > 9 +#if X264_BUILD >= 76 > 10+ int size = nals[i].i_payload; > 11+ memcpy(codec->work_buffer + codec->buffer_size, nals[i].p_payload, > nals[i].i_payload); > 12+#else > > > I guess you can infer the obvious answer :) Again, don't ask me to explain > more: it's been so long that I forgot. This API change in x264 was well > documented though: > http://mailman.videolan.org/pipermail/x264-devel/2009-September/006337.html > http://mailman.videolan.org/pipermail/x264-devel/2009-September/006353.html Ok, I'm clueless what this is all about. I'll trust your expertise and take the patch. Thanks. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
On Sonntag, 31. Oktober 2010, Simeon Völkel wrote: > So what is currently still pending / not merged yet (that should be > included in Cin2.1.5CV)? Branch sv/gentoo-fixes shows what I have queed so far, but I think I'm not sure whether the tip one (the gentoo ffmpeg fix) is good. More tomorrow... -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Hannes, I've received the following answer from aballier, explaining the libavutil50 and x264 patches by gentoo. In my opinion both changes are fully justified, and _now_ as well sufficiently explained. So what is currently still pending / not merged yet (that should be included in Cin2.1.5CV)? With best regards, Simeon - Original Message Subject: Re: gentoo's cinelerra patches Date: Thu, 28 Oct 2010 11:00:43 -0300 From: Alexis Ballier Organization: Gentoo To: Simeon Völkel Hi, > we are currently working on Cin2.1.5CV and now collecting patches from > distributions to be included in the next release. However, only very few > have any explanation with them, but for the git repos we would like to > have a at least somewhat expressive commit message. > > When asking today in #gentoo-media about gentoo's patches for cinelerra > ssuominen told me to ask you for the following two patches: Glad to hear cinelerra is moving again :) I was bored of sending patches that were lost in the abysses of the cincv ml so I stopped forwarding them at some point... Anyway, about these two patches, its been so long that I don't remember but let's try. in any case, you can see the cvs log here: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media- video/cinelerra/files/ > > cinelerra-libavutil50.patch > > This patch seems to be quite destructive, as it replaces RGBA with RGB > color models. Is that really a proper solution or just a workaround that > does not mind loosing the alpha channel? Could you please explain this > patch? cvs log says: Fix build with libavutil 50 by not using pixel formats that have been deprecated for years. libavutil/pixfmt.h says: * PIX_FMT_RGB32 is handled in an endian-specific manner. An RGBA * color is put together as: * (A << 24) | (R << 16) | (G << 8) | B * This is stored as BGRA on little-endian CPU architectures and ARGB on * big-endian CPUs. #define PIX_FMT_RGB32 PIX_FMT_NE(ARGB, BGRA) #define PIX_FMT_RGB32_1 PIX_FMT_NE(RGBA, ABGR) #define PIX_FMT_BGR32 PIX_FMT_NE(ABGR, RGBA) #define PIX_FMT_BGR32_1 PIX_FMT_NE(BGRA, ARGB) so at least the remark of it being destructive is wrong iirc the only thing this patch changed is the name: the two pixel formats were #defined one onto the other but with libavutil 50, the one cinelerra was using was gone. You'll have to check libavutil/pixfmt.h svn history in ffmpeg svn if you want a 100% accurate answer there I'm afraid. > > cinelerra-x264.patch > > What does this patch solve? 9 +#if X264_BUILD >= 76 10 + int size = nals[i].i_payload; 11 + memcpy(codec->work_buffer + codec->buffer_size, nals[i].p_payload, nals[i].i_payload); 12 +#else I guess you can infer the obvious answer :) Again, don't ask me to explain more: it's been so long that I forgot. This API change in x264 was well documented though: http://mailman.videolan.org/pipermail/x264-devel/2009-September/006337.html http://mailman.videolan.org/pipermail/x264-devel/2009-September/006353.html Regards, Alexis. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzNvxEACgkQph/voQkhF7yzqwCbBqAWlMPkHqo8mmJ63iljdA+r u1QAnRwKjuwYmAMWR/HYf1G3SirDbmTM =Leyp -END PGP SIGNATURE- ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
Sorry to be a pain but I completely lost the track on which git I should get for all the work that has been done recently Thanks E. mbarassed On 29/10/10 08:35, Johannes Sixt wrote: > On Donnerstag, 28. Oktober 2010, Monty Montgomery wrote: > >> I assume you have a camera that works well with Cinelerra can you >> take a video of the problem in progress and send it to me? :-) That >> will end alot of guessing and hard-to-describe nature of the behavior. >> > I sent a video and hardware information in a private mail. > > >>> The playback cursor does jump around while the video lags behind. >>> >> Forward and backwards or only forward? jumping backwards is very >> unusual unless the audio is also skipping. >> > The cursor jumps back and forth, but audio goes forward smoothly. Video is > jerky for a few seconds and finally catches up with audio. > > -- Hannes > > ___ > 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: [CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
On Donnerstag, 28. Oktober 2010, Monty Montgomery wrote: > I assume you have a camera that works well with Cinelerra can you > take a video of the problem in progress and send it to me? :-) That > will end alot of guessing and hard-to-describe nature of the behavior. I sent a video and hardware information in a private mail. > > The playback cursor does jump around while the video lags behind. > > Forward and backwards or only forward? jumping backwards is very > unusual unless the audio is also skipping. The cursor jumps back and forth, but audio goes forward smoothly. Video is jerky for a few seconds and finally catches up with audio. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
> 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio > Controller (rev 02) > > The driver is obviously snd_hda_intel. Yes. This is a well behaved driver (even if some people don;t like the hw interface much :-) and I have examples of it here. >> The change to ALSA, BTW, was simply to move the latency calculation to >> where it actually reflected the buffer fill; the old code was always >> one fragment off because it calculated latency not accounting for the >> fragment it was about to write. Does the old code have proper sync >> for you if you set the fragment size to something large? > > Audio is not well synchronized. With a "Playback buffer size" of 16384 it is > awful, and much better with 4096, but not perfect. With your patch > and "Disable hardware synch" switched off, synchronization is very good, > regardless of the buffer size. But there is this jerky video that catches up > with the audio only after a few seconds. Hm, this does potentially sound like 'now that sync is working, it has broken something else'... What specific format is the input you're testing with? What is the relative power of the hardware and is it multicore? What kind of disk subsystem? In all versions of Cinelerra, I've seen very bad behavior on the beginning of playback depending on the input format and project specifics. For example, before I made the YUV4MPEG fixes, I would regularly have the beginning of playback place so much instantaneous load on the machine that it would render the UI fully unresponsive until it had finished building indexes and fill the cache (all the time juttering and stuttering as it tried to play back under the massive work-ahead). And upon every track transition, the same thing would happen again as it would OMG NEW TRACK! and hose the machine into the ground again filling caches. In short, Cinelerra has a 'stampede' problem, made much worse by the massive multithreading. I do not know if this is underlying your problem, but it might be (eg, it's trying to load an index on demand while playback proceeds). The working sync may simply be giving enough accurate timing information that it is suddenly trying to hold sync through the load spike where it wasn't before (causing it to shed lots of frames). I'm not at all convinced this is the case, I'm positing. Ah! I have an idea. I assume you have a camera that works well with Cinelerra can you take a video of the problem in progress and send it to me? :-) That will end alot of guessing and hard-to-describe nature of the behavior. > The playback cursor does jump around while the video lags behind. Forward and backwards or only forward? jumping backwards is very unusual unless the audio is also skipping. Monty ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
On Mittwoch, 27. Oktober 2010, Monty Montgomery wrote: > On Wed, Oct 27, 2010 at 4:17 PM, Johannes Sixt wrote: > > When I back out the "Correct timing bug in the alsa driver" > > patch, things work well again. That is, I do not have to turn on "Disable > > hardware synchronization" to have fluent playback from the beginning. > > > > I'm on OpenSUSE 11.1. This is some 2.6.27.48 kernel flavor. > > What hardware? Latency feedback is implemented per-driver. If this is > happening one multiple chipsets, that's important to know. lspci says: 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02) The driver is obviously snd_hda_intel. > > The change to ALSA, BTW, was simply to move the latency calculation to > where it actually reflected the buffer fill; the old code was always > one fragment off because it calculated latency not accounting for the > fragment it was about to write. Does the old code have proper sync > for you if you set the fragment size to something large? Audio is not well synchronized. With a "Playback buffer size" of 16384 it is awful, and much better with 4096, but not perfect. With your patch and "Disable hardware synch" switched off, synchronization is very good, regardless of the buffer size. But there is this jerky video that catches up with the audio only after a few seconds. > I also wonder if this is not actually something directly to do with > the audio driver, but is tickling some other timing issue; eg, if the > audio was always late/early before, then it changes the timing of when > video frames need to arrive relative to decode time. If the playback > cursor is *also* jumping around or jerky... then it's definitely the > sound driver. If the cursor is smooth, that implicates other things. The playback cursor does jump around while the video lags behind. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
On Wed, Oct 27, 2010 at 4:17 PM, Johannes Sixt wrote: > On Mittwoch, 27. Oktober 2010, Monty Montgomery wrote: >> > Speaking of sync: With the patches applied, I get acceptable playback >> > only when I "Disable hardware synchronization". >> >> Ah, that part of the patch got cherrypicked too, OK. I renamed the >> option in my own tree so that it says what it actually does. >> >> > Otherwise, although audio output >> > is continuous, video is jerky at the beginning, and then catches up with >> > the audio. This happens at every playback change (forward, reverse, >> > half-speed, normal-speed, double-speed). >> >> With OSS? > > No. With ALSA. Oh! That's considerably more interesting then. > When I back out the "Correct timing bug in the alsa driver" > patch, things work well again. That is, I do not have to turn on "Disable > hardware synchronization" to have fluent playback from the beginning. > > I'm on OpenSUSE 11.1. This is some 2.6.27.48 kernel flavor. What hardware? Latency feedback is implemented per-driver. If this is happening one multiple chipsets, that's important to know. The change to ALSA, BTW, was simply to move the latency calculation to where it actually reflected the buffer fill; the old code was always one fragment off because it calculated latency not accounting for the fragment it was about to write. Does the old code have proper sync for you if you set the fragment size to something large? [collecting more information so that I can better target some debugging code addition. Obviously, there's more debugging to do here.] I also wonder if this is not actually something directly to do with the audio driver, but is tickling some other timing issue; eg, if the audio was always late/early before, then it changes the timing of when video frames need to arrive relative to decode time. If the playback cursor is *also* jumping around or jerky... then it's definitely the sound driver. If the cursor is smooth, that implicates other things. Monty ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
On Mittwoch, 27. Oktober 2010, Simeon Völkel wrote: > On 10/26/10 22:12, Johannes Sixt wrote: > > - b789d4ff fix background rendering crash on >=jpeg-7 > > This doesn't compile here. It needs version checks around uses of > > do_fancy_upsampling. > > I've added these checks and extended the commit message, see branch > cin2.1sv_reworked or [1]. Thanks. This works. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
On Mittwoch, 27. Oktober 2010, Monty Montgomery wrote: > > Speaking of sync: With the patches applied, I get acceptable playback > > only when I "Disable hardware synchronization". > > Ah, that part of the patch got cherrypicked too, OK. I renamed the > option in my own tree so that it says what it actually does. > > > Otherwise, although audio output > > is continuous, video is jerky at the beginning, and then catches up with > > the audio. This happens at every playback change (forward, reverse, > > half-speed, normal-speed, double-speed). > > With OSS? No. With ALSA. When I back out the "Correct timing bug in the alsa driver" patch, things work well again. That is, I do not have to turn on "Disable hardware synchronization" to have fluent playback from the beginning. I'm on OpenSUSE 11.1. This is some 2.6.27.48 kernel flavor. > If you have a prepackaged mode you can point me to that I can turn on > and off easily per-buffer, I'll use it (eg, what the Linux kernel > offers). The Linux kernel style would be suitable for the Cinelerra code base as well. I don't know how to set a style in Emacs, though. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
Yes it's all fine.. thx! Vale git://git.cinelerra.org/j6t/cinelerra.git sv/gentoo-fixes This state doesn't work for me (it crashes on the first playback of DV), hence, I didn't push it to master right away. I'll investigate. No, it doesn't crash. It's all fine. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra This message was sent using IMP, the Internet Messaging Program. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
>> People are, in general, used to sync always being broken. :-) > > OK. > > Speaking of sync: With the patches applied, I get acceptable playback only > when I "Disable hardware synchronization". Ah, that part of the patch got cherrypicked too, OK. I renamed the option in my own tree so that it says what it actually does. > Otherwise, although audio output > is continuous, video is jerky at the beginning, and then catches up with the > audio. This happens at every playback change (forward, reverse, half-speed, > normal-speed, double-speed). With OSS? Well, that's obviously not good. FTR, this is the behavior I got in the old source before patches. Are you on a Linux kernel? If so, which one? If not... which one? :-) The problem with the old code was not that it had any logic faults that I saw, but that the ioctl set it was calling simply didn't work according to spec or any other reasonable behavior I could discern (and in my memory never has, at least on Linux). I switched to the ioctl set that does work, at least on Linux, and that I'd previously always used in my own code. Or maybe it's some other bug entirely. If it doesn't work, it obviously needs to be fixed. Shall I re-add the debugging output to see what's going on? > Actually, it is about both. > > What if I have to fix your code? My formating is different from yours again. > It's going to make a an unacceptable mess. It doesn't really ever seem to be a problem elsewhere. The norm, at least in projects I work with, is not to enforce a rigid style. > Please find out how to set the style for Emacs. It's certainly possible. I don't mean to be impolite, but no, I don't plan to do this. If this is unacceptable, I will not press the point, but I will also use the style I prefer in my own tree. If you have a prepackaged mode you can point me to that I can turn on and off easily per-buffer, I'll use it (eg, what the Linux kernel offers). Strict reformatting can also be done as a commit hook. > Thanks, it's appreciated. One *important* piece of information is that this is > about YUV4MPEG2 loader, not about any sort of YUV-like frames. This restricts > the scope of the patch quite a lot and makes it less critical. Yes, correct. The code internally simply calls this loader 'yuv' and so I called it the same. Monty ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
On Dienstag, 26. Oktober 2010, Johannes Sixt wrote: > I pushed out my state to > > git://git.cinelerra.org/j6t/cinelerra.git sv/gentoo-fixes > > This state doesn't work for me (it crashes on the first playback of DV), > hence, I didn't push it to master right away. I'll investigate. No, it doesn't crash. It's all fine. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
On Dienstag, 26. Oktober 2010, Monty Montgomery wrote: > > - 8aa33e3e Rwrite the latency timing/calculation for the OSS backend > > There is parctically no explanation why the change is good and why > > a new mutex is needed. It looks dangerous. How extensively has the > > code been excercised? Why is a change needed at all? I am not aware > > of people complaining that the OSS driver does not work. But I > > might be missing something. > > The OSS latency calculation in 2.1CV is completely nonfunctional on > the native OSS, OSS-via-ALSA-emu and OSS-via-ALSA-emu-via-Pulse emu > machines here. The OSS driver only 'works' when the driver-based > latency calculation is disabled (the 'enable software sync' > preferences box, which doesn't enable anything-- it disables driver > latency polling and has playback 'fly blind'). > > People are, in general, used to sync always being broken. :-) OK. Speaking of sync: With the patches applied, I get acceptable playback only when I "Disable hardware synchronization". Otherwise, although audio output is continuous, video is jerky at the beginning, and then catches up with the audio. This happens at every playback change (forward, reverse, half-speed, normal-speed, double-speed). > > - e0569663 Actually check for error return codes in OSS > > This does not adhere to the coding standard that is used in surrounding > > code. Fixing that would take too much of my time. Remember that it is > > good tone to copy the coding style that you find rather than to force > > your own style onto existing code. This includes white-space style. > > (IOW, please use tabs, not 8 spaces.) > > My emacsen here are actually forced to use spaces and two-space > indent. Not sure how tabs ended up in it. > > As for stylistic 'forcing' in most projects here at least, we've long > since abandoned the formatting war over here. He who writes the code > gets to format it, and for the most part we loosely follow the > surrounding style. But insisting on whitespace-perfect style > emulation... urk. Or is this about braces? :-) Actually, it is about both. What if I have to fix your code? My formating is different from yours again. It's going to make a an unacceptable mess. Please find out how to set the style for Emacs. It's certainly possible. There are lots of projects out there where Emacs is used to edit code that is not two-space indented. > > - 64e8022f Eliminate the YUV file loader's wont > > Before I merge this change, I'd like to know why the patch solves a > > problem (and what the problem exactly is). "It happens more often > > than you think" is a bit too much hand-waving. Can I easily reproduce > > the bug? (Oh, and the commant about coding style applies, too.) > > The YUV4MPEG2 loader was building a from-scratch transient index that > required reading every byte in the raw file on every call to open. > Open is called *often*, not just when the project is loaded. If the > loader already had an index, it threw it away. It was all in memory, > nothing was saved. This means that, for example, every undo required > every y4m file in the project to rebuild indexes from scratch. On the > movie I was working on, that was 20 minutes as it re-read just short > of a terabyte of video... > > ...for no reason. The index was useless, every frame is the same > size. The y4m spec doesn't allow frame size deviation (that includes > frame headers). > > I realize this is all still to terse; I'll elaborate in more detail on > each point once I've gotten some sleep. Thanks, it's appreciated. One *important* piece of information is that this is about YUV4MPEG2 loader, not about any sort of YUV-like frames. This restricts the scope of the patch quite a lot and makes it less critical. BTW, when you formulate a commit message, please begin it with a single summary line (max 76 characters), followed by a blank line, followed by the justification. The justification should be written with an audience in mind that is at most half-aware of what is going on in the subsystem that you are changing. You should explain what the subsystem _should_ do, what it actually does (i.e. the reason of the bug), and how to reproduce the problem. If the way how you fix a bug is non-obvious, it should be explained as well. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 oh, forgot cinelerra ML :-/ - Original Message Subject: Re: Cinelerra CinCV merge request / Cin2.1.5CV Date: Tue, 26 Oct 2010 22:39:57 +0200 From: Simeon Völkel To: Johannes Sixt CC: Monty Montgomery On 10/26/10 22:12, Johannes Sixt wrote: > On Sonntag, 24. Oktober 2010, Simeon Völkel wrote: >> today Monty and I worked out which of his changes are independent from his >> ffmpeg loader project and fix bugs of CinCV. >> >> I've merged these commits over into my repo[1] and would like to ask you to >> pull these changes (everything from october, starting with [2], except for >> the one commit[3] which states that it is not for CinCV) over into the >> official CinCV repo. > > I didn't take these: > > - f4b7d222 apply gentoo libavutil50 patch > This substitutes RGBA* by RGB color codes. How can this be good? > Please explain. I just took over the patch which is applied by gentoo when compiling cin using emerge, as otherwise it does not compile here. If i've got some time tomorrow, I'll have a look at what actually changed in libavutil and whether RGBA color codes are still supported. > > - b789d4ff fix background rendering crash on >=jpeg-7 > This doesn't compile here. It needs version checks around uses of > do_fancy_upsampling. I'll add them. Didn't recognize that as background rendering was broken for almost one year on my boxes, however not on others, obviously due to jpeg-7/8. Haven't tested it on a not-jpeg-7/8 installation. > > - 8aa33e3e Rwrite the latency timing/calculation for the OSS backend > There is parctically no explanation why the change is good and why > a new mutex is needed. It looks dangerous. How extensively has the > code been excercised? Why is a change needed at all? I am not aware > of people complaining that the OSS driver does not work. But I > might be missing something. > > - e0569663 Actually check for error return codes in OSS > This does not adhere to the coding standard that is used in surrounding > code. Fixing that would take too much of my time. Remember that it is > good tone to copy the coding style that you find rather than to force > your own style onto existing code. This includes white-space style. > (IOW, please use tabs, not 8 spaces.) > Monty will explain the need and purpose of the two OSS changes in more detail. > - 48e292ec Add ArchLinux x264-quicktime build patch > This does in no way explain what the patch solves. I cannot judge why > the change would be good. > This was taken over from Monty's repo, however it seems to be applied as well by gentoo without explanation. I'll try to figure out where this patch comes from. > - 64e8022f Eliminate the YUV file loader's wont > Before I merge this change, I'd like to know why the patch solves a > problem (and what the problem exactly is). "It happens more often > than you think" is a bit too much hand-waving. Can I easily reproduce > the bug? (Oh, and the commant about coding style applies, too.) Monty will explain in detail; It seems as if YUV frames can't differ in size, thus creating an index is wasting resources. > > - e40c03ad remove hardcoded cinelerra/versioninfo.h and add README.Cin2.1SV > What is this about? I'm sorry, didn't recognize that commit when writing the mail, that commit does not apply to CinCV, just to my repo (CinSV). It was not intended to be merged into CinCV :D > > I pushed out my state to > > git://git.cinelerra.org/j6t/cinelerra.git sv/gentoo-fixes > Thanks! > This state doesn't work for me (it crashes on the first playback of DV), > hence, I didn't push it to master right away. I'll investigate. Ok, i haven't used DV yet in my latest version, but edited and rendered already a small test project in HDV. Maybe you could paste a backtrace to bugs.cinelerra.org or so. With best regards, Simeon -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzHPocACgkQph/voQkhF7yzagCgyBaGTeHyqpF9W4jno7nbIzxY tpsAoKwBAYOvzydXKbz2GwxSFfyDMKjX =PwyK -END PGP SIGNATURE- ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
> - 8aa33e3e Rwrite the latency timing/calculation for the OSS backend > There is parctically no explanation why the change is good and why > a new mutex is needed. It looks dangerous. How extensively has the > code been excercised? Why is a change needed at all? I am not aware > of people complaining that the OSS driver does not work. But I > might be missing something. The OSS latency calculation in 2.1CV is completely nonfunctional on the native OSS, OSS-via-ALSA-emu and OSS-via-ALSA-emu-via-Pulse emu machines here. The OSS driver only 'works' when the driver-based latency calculation is disabled (the 'enable software sync' preferences box, which doesn't enable anything-- it disables driver latency polling and has playback 'fly blind'). People are, in general, used to sync always being broken. :-) > - e0569663 Actually check for error return codes in OSS > This does not adhere to the coding standard that is used in surrounding > code. Fixing that would take too much of my time. Remember that it is > good tone to copy the coding style that you find rather than to force > your own style onto existing code. This includes white-space style. > (IOW, please use tabs, not 8 spaces.) My emacsen here are actually forced to use spaces and two-space indent. Not sure how tabs ended up in it. As for stylistic 'forcing' in most projects here at least, we've long since abandoned the formatting war over here. He who writes the code gets to format it, and for the most part we loosely follow the surrounding style. But insisting on whitespace-perfect style emulation... urk. Or is this about braces? :-) > - 64e8022f Eliminate the YUV file loader's wont > Before I merge this change, I'd like to know why the patch solves a > problem (and what the problem exactly is). "It happens more often > than you think" is a bit too much hand-waving. Can I easily reproduce > the bug? (Oh, and the commant about coding style applies, too.) The YUV4MPEG2 loader was building a from-scratch transient index that required reading every byte in the raw file on every call to open. Open is called *often*, not just when the project is loaded. If the loader already had an index, it threw it away. It was all in memory, nothing was saved. This means that, for example, every undo required every y4m file in the project to rebuild indexes from scratch. On the movie I was working on, that was 20 minutes as it re-read just short of a terabyte of video... ...for no reason. The index was useless, every frame is the same size. The y4m spec doesn't allow frame size deviation (that includes frame headers). I realize this is all still to terse; I'll elaborate in more detail on each point once I've gotten some sleep. Cheers! Monty ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
On Sonntag, 24. Oktober 2010, Simeon Völkel wrote: > today Monty and I worked out which of his changes are independent from his > ffmpeg loader project and fix bugs of CinCV. > > I've merged these commits over into my repo[1] and would like to ask you to > pull these changes (everything from october, starting with [2], except for > the one commit[3] which states that it is not for CinCV) over into the > official CinCV repo. I didn't take these: - f4b7d222 apply gentoo libavutil50 patch This substitutes RGBA* by RGB color codes. How can this be good? Please explain. - b789d4ff fix background rendering crash on >=jpeg-7 This doesn't compile here. It needs version checks around uses of do_fancy_upsampling. - 8aa33e3e Rwrite the latency timing/calculation for the OSS backend There is parctically no explanation why the change is good and why a new mutex is needed. It looks dangerous. How extensively has the code been excercised? Why is a change needed at all? I am not aware of people complaining that the OSS driver does not work. But I might be missing something. - e0569663 Actually check for error return codes in OSS This does not adhere to the coding standard that is used in surrounding code. Fixing that would take too much of my time. Remember that it is good tone to copy the coding style that you find rather than to force your own style onto existing code. This includes white-space style. (IOW, please use tabs, not 8 spaces.) - 48e292ec Add ArchLinux x264-quicktime build patch This does in no way explain what the patch solves. I cannot judge why the change would be good. - 64e8022f Eliminate the YUV file loader's wont Before I merge this change, I'd like to know why the patch solves a problem (and what the problem exactly is). "It happens more often than you think" is a bit too much hand-waving. Can I easily reproduce the bug? (Oh, and the commant about coding style applies, too.) - e40c03ad remove hardcoded cinelerra/versioninfo.h and add README.Cin2.1SV What is this about? I pushed out my state to git://git.cinelerra.org/j6t/cinelerra.git sv/gentoo-fixes This state doesn't work for me (it crashes on the first playback of DV), hence, I didn't push it to master right away. I'll investigate. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Re: Cinelerra CinCV merge request / Cin2.1.5CV
Am 24.10.2010 18:06, schrieb Simeon Völkel: I've merged these commits over into my repo[1] and would like to ask you to pull these changes (everything from october, starting with [2], except for the one commit[3] which states that it is not for CinCV) over into the official CinCV repo. Thanks, will review and merge the commits, but on Tuesday at the earliest because I'm away from my regular workplace ATM. Furthermore, we (Monty and I) would like to increase CinelerraCV's version counter to 2.1.5 to reflect these sometimes very fundamental bugfixes (mainly audio- and rounding-related). As soon as we can merge Monty's ffmpeg-loader, something from Cin4.xHV or any change that goes beyond pure bugfixing the version number shall be increased to 2.2 (as long as nobody demurs ;-)). Sounds reasonable! -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
