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
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
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
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
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,
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
On Tue, Jan 15, 2013 at 8:27 PM, Arvind R arvin...@gmail.com 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
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
Let's all chime in with a round of 'TESTING!
:-)
Monty
On Fri, Jan 11, 2013 at 2:25 PM, Herman Robak herman.ro...@gmail.com 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...
On Sat, Jan 12, 2013 at 4:56 PM, Michal Fapso michal.fa...@gmail.com 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:
On Mon, Dec 24, 2012 at 5:48 AM, Einar Rünkaru eina...@smail.ee 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
On Sun, Jan 13, 2013 at 10:03 AM, MGV-AV Linux i...@bandshed.net 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
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
class:
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 expecting
On Thu, Jan 10, 2013 at 6:54 AM, Rebecca beccato...@hotmail.com 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
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
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
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
(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
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-room.
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 didn't
... 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 bias is
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 may
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=2714pp=10page=310
That was all somewhat confusing... need equations :-) But it's clear
they're talking about something not broadcast and not nonlinear
(gamma)
On Sun, Nov 4, 2012 at 2:10 PM, Tim Copeland t...@criteriondigital.net 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
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
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
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
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
On Sat, Feb 5, 2011 at 5:51 AM, Haimanti Kar mouriph...@yahoo.com 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
On Mon, Jan 31, 2011 at 5:18 PM, Sean M. Pappalardo
pega...@renegadetech.com 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.
gnome color console lets you do full LUT color calibration. This sort of
thing is not nVidia-centric...
Monty
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?
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 of
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
On Sat, Nov 13, 2010 at 8:36 AM, Eli Billauer e...@billauer.co.il 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
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)
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
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
On Wed, Oct 27, 2010 at 4:17 PM, Johannes Sixt j...@kdbg.org 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
- 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
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
On Fri, Sep 17, 2010 at 5:51 AM, matm...@t-online.de
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
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
On Thu, Jul 29, 2010 at 7:48 PM, E Chalaron e.chala...@xtra.co.nz 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
On Mon, Jul 26, 2010 at 8:30 PM, E Chalaron e.chala...@xtra.co.nz 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
On Mon, Jul 26, 2010 at 5:42 PM, E Chalaron e.chala...@xtra.co.nz 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
Thanks; change applied to my GIT repo.
Monty
On Wed, Jul 21, 2010 at 1:42 PM, Einar Rünkaru eina...@smail.ee wrote:
Hi.
I read in IRC log about compile error in edits.C at line 50:
ListEdit::ListEdit();
This line can be removed.
Einar
___
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 is
On Fri, Jul 16, 2010 at 5:46 PM, Stefan de Konink ste...@konink.de 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
53 matches
Mail list logo
