Hello,
After noticing that Cinelerra-HV 4.1 has a new FFMPEG-based file
reader (and then noticing with disappointment that it is rather
incomplete and doesn't work well), I set about writing an improved
version. Among other things, I needed something that could properly
handle odd-framerate HDV v
Oops, I had a minor miss (I blame the Makefiles. It's my story and
I'm sticking to it). Some debugging output I'd intended to remove
slipped through to the patch and because it was only partially
removed, and it caused a minor build break.
I've amended the patch, still at the same URL. I used -
An additional update to the original patch:
http://people.xiph.org/~xiphmont/0002-orrect-colorspace-handling-in-fileffmpeg.C.patch
This is in addition to 0001, not a replacment.
This strengthens pixel format handling (including adding JPEG-style
chroma sitings, used by DV, Theora, VPx and MJPEG,
I've been conyinuing debugging work on the new ffmpeg-based loader,
and have branched out into other fixes starting with the audio backend
(eg, the latency calculation in the ALSA backend was broken, etc...).
I've also needed to fix a few bugs in ffmpeg itself.
In order to disseminate the patches
> I tried both versions (included ffmpeg / external ffmpeg) with mpeg2 and
> AVCHD footage from my camcorder. With mpeg2 no problem, and I had also
> partial success loading and editing directly AVCHD files (the "original"
> cinelerra-cv crashed when I tried to load them, so your patched version
On Fri, Jul 16, 2010 at 5:46 PM, Stefan de Konink wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Dear Monty,
>
>
> I currently have the following problem /also/ in the latest available
> GIT repo from the other coders. Resulting that opening projects with
> .mov files in it don't w
On Fri, Jul 16, 2010 at 6:22 PM, wrote:
> Unfortunately I have to correct something I wrote in my earlier message. It
> seems that Monty's patched version of cinelerra has trouble with some of my
> mpeg2 files, that were correctly handled by the "original" cinelerra (from
> git://git.cinelerra
Thanks; change applied to my GIT repo.
Monty
On Wed, Jul 21, 2010 at 1:42 PM, Einar Rünkaru wrote:
> Hi.
>
> I read in IRC log about compile error in edits.C at line 50:
> List::List();
>
> This line can be removed.
>
> Einar
>
> ___
> Cinelerra maili
On Mon, Jul 26, 2010 at 5:42 PM, E Chalaron wrote:
> Hi Einar
> Thanks for that... the problem seems to be recurrent here and there
> See the following :
That's a different issue. The code was written for libpng 1.2, and
you're compiling against 1.4 in which the API has changed. Replace
the
On Mon, Jul 26, 2010 at 8:30 PM, E Chalaron wrote:
> Hi Monty
>
> Thanks a lot for the reply. My very problem is that I am not a
> developper and cant really read error messages. But got the picture now.
> I was reading your posts previsouly and from I understand your GIT
> version works with 1.4,
On Thu, Jul 29, 2010 at 7:48 PM, E Chalaron wrote:
> That's a problem.
>
> It is a serious one actually what is the point of Git if every developer
> has its own version of cinelerra ?
These changes haven't been merged because they're untested or known to
cause serious regressions in some cas
Oh, let's be nice. Cinelerra is indeed buggy as all hell. Every one
of us has vented hardcore about it in the past. So... Not great form,
but the frustration is understandable.
There really *aren't* any good FOSS vid editing tools today.
Honestly, I'm surprised he's having decent success with k
On Fri, Sep 17, 2010 at 5:51 AM, matm...@t-online.de
wrote:
> Cinelerra Bug Report: HD-Videos extremely slow.
>
> I'm using Cinelerra-CV 2.1.0-2svn20081020.1 on Debian Lenny. I need it to cut
> some HD-Video clips to short movies which are 5 till 9 minutes long. The
> source video is rawvideo, y
> - 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 comp
>> 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
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
> 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 si
Hello Jose,
Is it possible to send those two files off to me (just me, not the list)?
Thanks,
Monty
___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
On Sat, Nov 13, 2010 at 8:36 AM, Eli Billauer wrote:
> The truth is that I don't understand why people are so uptight about having
> their original footage going directly into Cinelerra. I mean, it's nice that
> Cinelerra supports several video formats, but somehow I'm only really calm
> when I fe
> So, I'm guessing the takeaways of your discussion are:
> -if at all possible, avoid converting your videos to different formats
> or try to keep the conversions to a minimum
> -if you do convert, stay in the same colorspace as the original footage
yup. or work in a floating point (non-8-bit) co
> AFAIK mjpeg can handle different colorspaces, including YCbCr, so it seems to
> me that transcoding video (footage) to mjpeg doesn't necessarily imply
> colorspace conversion, or at least a "lossy" colorspace conversion
> (independently of the loss due to the codec itself).
YCbCr is a family
> But
> how many of those who use DSLRs as their video source pay attention to the
> automatically picked ISO level, which has a huge impact on the noisiness of
> the image? (Well, I do.)
You allow your DSLR to choose automatically? I run every setting
manual *period* :-)
> So I think that the b
> Huh? I would say that anything more than having a hardly noticeable
> difference in the noise level is either a bug in the transcoder or a painful
> (but sometimes necessary) reduction in the bit rate. The latter should
> result in chunks, blocks and noise, but changes in colors and brightness?
>
On Mon, Jan 31, 2011 at 5:18 PM, Sean M. Pappalardo
wrote:
> Hello.
>
> On 01/31/2011 07:02 PM, Douglas Pollard wrote:
>>
>> Almost finished with a couple weeks work on a video and lost the sound
>> track for the left side of stereo. I was adjusting volume and poof it
>> was gone.
>
> For the reco
gnome color console lets you do full LUT color calibration. This sort of
thing is not nVidia-centric...
Monty
On Sat, Feb 5, 2011 at 5:51 AM, Haimanti Kar wrote:
>
> Hello
>
> I am facing some problems with Cinelerra.
>
> 1. While working in timeline video and audio are not synchronizing during
> playing time.
There are bugs in the current audio backends and so the sync code is
broken in both OSS and AL
ALSA would not have anythin to do with it...
When you say 'move around' do you mean L/R or appearing at different times?
Monty
___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
for hermanr_:
http://www.schleef.org/blog/2009/10/07/ycbcr-gamut-checking/
Monty
___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Cutting to the chase, A Proposal:
Implementing only a single color format for the CinCV pipeline, and
making it studio-swing RGBA float. Input and output would rely on
this assumption and handle conversion to/from sRGB/JPEG/bt601/bt709
spaces automatically. Along with that 'fixing the compositor
> Now what about formats whose white point is far below the
> max value, like some higher depth formats?
The higher-depth formats I know of (and I'm asking because I'm sure
there are ones I don't know of) still define swing in terms of the 8
bit range, and just tack on additional bits.
> What is
>> But then there are cinema-oriented formats,like Digital Intermediates and
>> such.
>
>
> http://www.reduser.net/forum/printthread.php?t=2714&pp=10&page=310
That was all somewhat confusing... need equations :-) But it's clear
they're talking about something not broadcast and not nonlinear
(gamm
On Sun, Nov 4, 2012 at 2:10 PM, Tim Copeland wrote:
> Not understanding why you would want to force a clamped output at all.
I don't; I was suggesting only an assumed internal space where we know
the intensity curve, black point and white point. I wasn't suggesting
_clipping_ to that space (alth
> Negatives need to be scan on 10 or 16 bits /pixels and no gamma. RGB 8 bits
> is just not enough.
> Of course not everyone has a HP 10 bits screen to grade negs.
Did you mean 'no gamma correction' or did you really mean full-linear?
Ahh, right, if it's a negative, you don't want to apply a posi
> ... and presenting 0.0 as black and 1.0 as white internally is
> totally out of the question?
No. :-)
> With your proposed studio swing
> mapping most compositing and filtering operations have to scale
> and bias to work right. E.g. black + black + black will be a
> shade of gray, unless a bi
> I suppose linear light is the "native" space of many (most?) common
> operations. Blurring and resampling/scaling will get funny shifts
> in brightness if they operate on non-linear samples, for example.
Yes, full agreement. But given that many [most] tools don't operate
in linear space, users
> Any reason for not using 8/16/32 bit as a fraction (0-1)? So 8 bit would
> have a resolution of 1/255, 16 bit of 1/65535 etc. All operations can
> be done with 4 byte integer math.
16 bits linear will be barely enough to capture an 8 bit nonlinear
space, and that's leaving out head- and toe-roo
>> Just an idea.
>
> Sure :-) And I think you're right in the tactical sense... but
> overall I think float is a more practical idea. It will be slower in
> the ideal case, but I don't think we'll ever be within spitting
> distance of ideal speed.
BTW, if I sounded ungrateful for the comment, I
> (Hm, if this is workable, it might be worthy a test suite...)
There's a reason for the historical "CLACK! Action!"
Monty
___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
First bug found in new engine; 8-bit modes with alpha were not
clamping alpha during blending
Patch attached
Monty
0002-New-resampling-engine-must-clamp-alpha.patch
Description: Binary data
Hello!
I spent the Christmas break writing a color grading and correction
filter for CV named Blue Banana. A few people on IRC have been trying
it out for about two weeks, and I think it's more or less ready for a
wider audience. I've put some effort into balancing the techniques
used to give in
On Thu, Jan 10, 2013 at 6:54 AM, Rebecca wrote:
> Wow, thanks Monty, this is aces - the only glitch I've encountered so far is
> when I check Mask Selected Areas (top right), it crashes.
Thanks for the report!
It looks like recent versions have added an element right smack in the
middle of the m
> A sincere thanks for all your work on this (and other stuff behind the
> scenes of course). It is appreciated that you've also provided a drop-in
> version to work with since this is a pretty sophisticated plugin.
...and eventually, I'll manage to build one that actually works right! :-)
> I am
Hello,
I just pushed a fix to Blue Banana crashing on CinCV 2.2 and master
when activating 'Mark Selected Areas'. My Git is up to date and a new
plugin build is here:
http://people.xiph.org/~xiphmont/blue_banana_builds/bluebanana-20130110.tgz
Short summary: The mwindow.h structure changed befor
> I'm using a self-compiled and packaged GIT build of Cinelerra-CV 2.2 with
> the updated overlay engine. I can't imagine why this would create an issue
> with recognizing a new plugin and all other plugins etc. work perfectly
> with this build.
My guess: The self-built version is probably expecti
On Sun, Jan 13, 2013 at 10:03 AM, MGV-AV Linux wrote:
> Hi Einar, thanks for the reply,
>
> I built and installed this version with '--prefix=/usr'
Ah, OK, so you did change the prefix. Well, hmmm
> I'll try running it from the command line and
> see if there is any meaningful output and I'
> You can disregard my previous post I discovered the problem in the
> terminal...silly me should have done that first! It would appear the
> plugin Monty uploaded is for 64bit, I am running 32bit, the error I get
> is:
>
> 'PluginServer::open_plugin: /usr/lib/cinelerra/bluebanana.so: wrong ELF
> c
Let's all chime in with a round of 'TESTING!"
:-)
Monty
On Fri, Jan 11, 2013 at 2:25 PM, Herman Robak wrote:
> The migration of the CinCV mailing list to another server
> had some ... issues. It's supposed to be back up again now,
> but there may be some glitches still...
>
> The list info has
On Sat, Jan 12, 2013 at 4:56 PM, Michal Fapso wrote:
> Hi Glen,
>
> I had a similar issue with the bluebanana.so plugin. It was compiled
> for 64bit system, but I have only 32bit. I had to compile it from
> sources. So you can try this 32bit version:
>
> http://www.fit.vutbr.cz/~ifapso/download/bl
On Mon, Dec 24, 2012 at 5:48 AM, Einar Rünkaru wrote:
> It is possible to update titler before changing overlayframe (look at my
> repo).
Ah! yes, of course.
> If you have a good reformatter, may be we should include it to cinelerra
> tools.
I don't, but I know they exist and that I need o
A patch for the second bug found in the new overlay engine.
The new overlayer was inadvertantly storing the passed in master alpha value
as an int; this bug showed up in the single-track overlapping
conversions, such as dissolves.
Patch attached; assumes previous two overlay engine patches are alr
On Tue, Jan 15, 2013 at 8:27 PM, Arvind R wrote:
> Hi all,
>
> This set of 7 patches enables the use of recent ffmpeg with the master
> of monty's branch.
Excellent! The updates are much appreciated. I'll apply the patches
here in a bit and see how well ffmpeg master works.
This also contribut
Hi Arvind,
The patches got mangled passing through the mail system. I was able
to repair them by hand but it took about half an hour-- could you send
patches as attachments in the future please?
Second issue-- although the patches apply, either recent FFMPEG is
very broken with mpeg-ts files, or
Having investigated a bit more, both ffmpeg 1.1 and libav 9.1 have the
same problem with the loader. However, both appear to work properly
on the command line (and don't seem to ahvea problem seeking either,
which is what I expect is the problem).
Monty
___
Hello Haldan,
> A canadien video maker, Pierre, from another liste (lprod/France) who had
> some issues in subscribing to our liste, security announcement scares him,
There are some ongoing issues with the mailing list; the maintainers
are aware of them.
> has a problem of synchronisation in edi
I'm sorry I took so long to reply; life has been quite hectic here...
> I still have no solutions... but I made new tests with shooting in 50i (PAL)
> DV and HDV (my camera can optionally operate 50i PAL in addition to its
> normal mode 60i NTSC) and in this case I observed no mismatches in
> Cine
The only thought I have is that I never tested any of this with DNxHD,
so it's not surprising it doesn't work. I'm not even sure if it's
being picked up by my loader, or if something esle is trying to grab
it first. The .MOV extension may well mean the the quicktime4linux
libs are trying to snag
Hi Arvind,
I have a few patches I need to get into my fork--- along with a
complete rebase :-|
I'll test the patches sometime soon to at least make sure they don't
break my own project files :-)
Monty
___
Cinelerra mailing list
Cinelerra@skolelinux.no
When I said 'I didn't mind' it was more 'doesn't really affect me'.
I haven't seen Michael do anything yet aside from grab the domain and
send mail. If he turns out to pour time and energy into Cinelerra,
then we can decide if it's good for the project or not. Or maybe
that's the last we're goi
Heh, well, now we have a pretty clear impression of what's going on
here. Good luck to Mr. Collins, as he's probably going to need it.
I still wouldn't mind if he actually succeeds in reinvigorating
Cinelerra, and I'll still believe it when I see it. In the meantime,
I don't really see how it af
59 matches
Mail list logo
