Re: [CinCVS] figuring out the ppc dv problem

[rafael2k]

> In sum: is cinelerra using libdv for decoding raw dv files? If so, can
> I alter it to use ffmpeg's dv codec so that it will work on ppc? Would
> it make sense for cinelerra to use ffmpeg's codec anyway, given that
> some people think it provides better quality?

This is a ubuntu/debian problem.
Why don't you just recompile your libdv and other important libraries to see 
if the problem persist?
Or, try a chroot w/ slackintosh installed and my packages.

bye,
rafael diniz

-- 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Eng. da Computação @  Unicamp
Rádio Muda, radiolivre.org, TV Piolho, tvlivre.org, www.midiaindependente.org
Chave PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2FF86098
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-



pgpsL9rFsn06N.pgp
Description: PGP signature

Re: [CinCVS] Re: Cinelerra sound system?

[rafael2k]

hi all,

> > I was looking into writing support for the JACK sound system in
> > CinelerraCVS. This is for me or for the whole community (if I'll ever
> > get it working). I did find a message that said it's possible to use
> > oss2jack, I havent't tried that, but off cause it would be nicer to have
> > a native system.
>
> This would be _really_ cool. It would open a lot of new possibilities to
> the Cinelerra workflow!

I wrote that email about oss2jack.
With jack support, MacOS X[1] port could get accepted (since sound is the only 
important thing lacking, afaik) and Windows port would be easy too, as there 
is a jack version for windows[2] and X for windows and macosx.

[1] - jack for macosx: http://www.jackosx.com/
[2] - jack for windows: http://www.grame.fr/~letz/jackdmp.html

bye,
rafael diniz

-- 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Eng. da Computação @  Unicamp
Rádio Muda, radiolivre.org, TV Piolho, tvlivre.org, www.midiaindependente.org
Chave PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2FF86098
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-



pgpWVrJjii5QP.pgp
Description: PGP signature

Re: [CinCVS] Re: Patch for cinelerra/fileyuv.C -- what am I doing wrong?

[Jim Scott]

On 3/13/07, Kevin Brosius <[EMAIL PROTECTED]> wrote:


You don't mention if you tested this patch with the in-tree version of
ffmpeg?  I suspect anyone who takes a look at the patch will need to
test that case, unless you have already.  Please let us know if you
considered this case.



I'm resending the patch as an attachment. I'll also put it here:

--- fileyuv.C.original  2007-03-10 17:53:56.0 -0600
+++ fileyuv.C   2007-03-10 17:54:31.0 -0600
@@ -415,8 +415,8 @@ int YUVConfigVideo::create_objects()

   x += 180;
   add_subwindow(ffmpeg = new PipePreset(x, y, "ffmpeg", pipe_textbox,
pipe_checkbox));
-   ffmpeg->add_item(new BC_MenuItem("(DVD) | ffmpeg -f yuv4mpegpipe -i
- -y -target dvd -ilme -ildct -hq -f mpeg2video %"));
-   ffmpeg->add_item(new BC_MenuItem("(VCD) | ffmpeg -f yuv4mpegpipe -i
- -y -target vcd -hq -f mpeg2video %"));
+   ffmpeg->add_item(new BC_MenuItem("(DVD) | ffmpeg -f yuv4mpegpipe -i
- -y -target dvd -ilme -ildct -f mpeg2video %"));
+   ffmpeg->add_item(new BC_MenuItem("(VCD) | ffmpeg -f yuv4mpegpipe -i
- -y -target vcd -f mpeg2video %"));

   add_subwindow(new BC_OKButton(this));
   add_subwindow(new BC_CancelButton(this));

I'm not sure how to test this against the in tree version of ffmpeg. The
patch only affects the presets on the yuv4mpeg drop down. I did not think
this change would affect any other ffmpeg calls.

Hannes was concerned about older versions of ffmpeg. The way the preset is
now, anyone using a recent version of ffmpeg has to change the preset. The
change shifts the responsibility to someone using an older version of ffmpeg
to add the -hq option if that is what they want.

Thank you both for your replies.
Thanks for your
--- fileyuv.C.original	2007-03-10 17:53:56.0 -0600
+++ fileyuv.C	2007-03-10 17:54:31.0 -0600
@@ -415,8 +415,8 @@ int YUVConfigVideo::create_objects()
 
 	x += 180;
 	add_subwindow(ffmpeg = new PipePreset(x, y, "ffmpeg", pipe_textbox, pipe_checkbox));
-	ffmpeg->add_item(new BC_MenuItem("(DVD) | ffmpeg -f yuv4mpegpipe -i - -y -target dvd -ilme -ildct -hq -f mpeg2video %"));
-	ffmpeg->add_item(new BC_MenuItem("(VCD) | ffmpeg -f yuv4mpegpipe -i - -y -target vcd -hq -f mpeg2video %"));
+	ffmpeg->add_item(new BC_MenuItem("(DVD) | ffmpeg -f yuv4mpegpipe -i - -y -target dvd -ilme -ildct -f mpeg2video %"));
+	ffmpeg->add_item(new BC_MenuItem("(VCD) | ffmpeg -f yuv4mpegpipe -i - -y -target vcd -f mpeg2video %"));
 
 	add_subwindow(new BC_OKButton(this));
 	add_subwindow(new BC_CancelButton(this));

Re: [CinCVS] Re: Patch for cinelerra/fileyuv.C -- what am I doing wrong?

[Kevin Brosius]

On 2007-03-13 19:27, Johannes Sixt wrote:
> On Tuesday 13 March 2007 13:21, Jim Scott wrote:
> > On 3/10/07, Jim Scott <[EMAIL PROTECTED]> wrote:
> > > I've never submitted a patch before and I'm not sure if this is the right
> > > spot. This patch removes the -hq setting from the default yuv4mpeg ffmpeg
> > > settings in  cinelerra/fileyuv.C I don't think the -hq switch is
> > > supported by current versions of ffmpeg, so I think it makes sense to
> > > remove the setting.
> >
> > Could someone please let me know whether this is the wrong place to suggest
> > a patch or whether the change is not acceptable?
> 
> This is the right place to submit a patch.
> 
> -- Hannes

Jim,

You don't mention if you tested this patch with the in-tree version of
ffmpeg?  I suspect anyone who takes a look at the patch will need to
test that case, unless you have already.  Please let us know if you
considered this case.

Thanks,
-- 
Kevin

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] Re: Patch for cinelerra/fileyuv.C -- what am I doing wrong?

[Johannes Sixt]

On Tuesday 13 March 2007 13:21, Jim Scott wrote:
> On 3/10/07, Jim Scott <[EMAIL PROTECTED]> wrote:
> > I've never submitted a patch before and I'm not sure if this is the right
> > spot. This patch removes the -hq setting from the default yuv4mpeg ffmpeg
> > settings in  cinelerra/fileyuv.C I don't think the -hq switch is
> > supported by current versions of ffmpeg, so I think it makes sense to
> > remove the setting.
>
> Could someone please let me know whether this is the wrong place to suggest
> a patch or whether the change is not acceptable?

This is the right place to submit a patch.

-- Hannes

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] Why OpenGL does not affect rendering, It just accelerates playback?

[Johannes Sixt]

> May I ask why OpenGL does not affect rendering, It just accelerates
> playback? What is the reason?

The reason is that by the time rendering takes place there is no guarantee 
that a connection to an X server is available. Think of renderfarms.

-- Hannes

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] figuring out the ppc dv problem

[Stefan de Konink]

I wonder;

Libquicktime has an ffmpeg plug-in, can't that be used?


Stefan

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

[CinCVS] figuring out the ppc dv problem

[Griffith Rees]

Right. So I was asked a while ago to check out the color problem in
cinelerra with raw dv files.
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400919=) I do indeed
have the problem, and I think I've found the solution, though I don't
quite know how to implement it.

The problem is: libdv just doesn't work for ppc, at least video wise
(it may work for audio, but I'll come to that in a minute). I realized
this because the ubuntu edgy ppc package of kino  (version 8.6) also
uses libdv, and has the same problem. Interestingly, this doesn't
happen on every raw dv file: the pond.dv test file that was posted on
the libdv website works fine in the kino 8.6, but won't open in my
recent build of cinelerra-cvs. I got similar problems from edgy ppc
builds of mplayer and vlc, and as far as I can tell, both were using
libdv.

The solution (as I can see): ffmpeg has its own dv decoder, and the
most recent builds of kino use it for video (not audio, again coming
to that). After some frustration with building the recent kino, I
managed to open my captured dv test file with it, sans color problems.
I fixed vlc the same way (more recent build, using ffmpeg instead of
libdv), and I think I can do the same for mplayer. Obviously I'm
wondering: is cinelerra using libdv (which is definitely a dependency)
and if so, is there a way I can get it to use ffmpeg's dv codec
instead so I won't have color problems on dv files?

Arguments: A fairly interesting thread on the mjpeg list
(http://www.mail-archive.com/mjpeg-users@lists.sourceforge.net/msg07079.html)
seems to suggest that ffmpeg's dv codec is superior to libdv in terms
of video quality. The problem is that it doesn't conform to the
quicktime requirements with regards to audio (see the bottom of the
post in the link). This might explain why it seems the newest version
of kino requires both libdv and ffmpeg: they use ffmpeg for dv video,
and libdv for dv audio. VLC seems to handle the audio playback with
ffmpeg's s16le decoder, which I haven't found much info on (haven't
looked very hard yet...).

In sum: is cinelerra using libdv for decoding raw dv files? If so, can
I alter it to use ffmpeg's dv codec so that it will work on ppc? Would
it make sense for cinelerra to use ffmpeg's codec anyway, given that
some people think it provides better quality?

hope this helps...

-griff

p.s. After checking the link at the top (debian bug), I realize they
corroborate my conclusion.

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

[CinCVS] Re: Patch for cinelerra/fileyuv.C -- what am I doing wrong?

[Jim Scott]

On 3/10/07, Jim Scott <[EMAIL PROTECTED]> wrote:



I've never submitted a patch before and I'm not sure if this is the right
spot. This patch removes the -hq setting from the default yuv4mpeg ffmpeg
settings in  cinelerra/fileyuv.C I don't think the -hq switch is supported
by current versions of ffmpeg, so I think it makes sense to remove the
setting.



Could someone please let me know whether this is the wrong place to suggest
a patch or whether the change is not acceptable?

Re: Re: [CinCVS] Why OpenGL does not affect rendering, It just accelerates playback?

[toby]

Craig,

I think it should be possible to get rendered output without the use of
proprietary toolkits. Plain OpenGL should do as well by rendering into a
(hidden)
texture and calling something like glGetTexImage() to access the
rendered output.
I'm not an OGL programmer, but I've read about this kind of techniques
many times. glReadPixels() provides basic access to the
actual "frame buffer" of the rendered screen content. But since
the output window might not be at full resolution,  this is not a solution.

In general,  it should be possible to make use of OpenGL for rendering, too.
Just look at all the OGL based hardware-acceleration stuff they're
working on
for vector libraries like cairo/glitz.

Toby



> Hi Craig,
>
> I don't understand what you said. I thought that nvidia cg offers frame
> buffer object to read data back from graphics card.
>
> Regards
> Leigh
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Craig Lawson
> Sent: Monday, 12 March 2007 8:29 p.m.
> To: cinelerra@skolelinux.no
> Subject: Re: [CinCVS] Why OpenGL does not affect rendering, It just
> accelerates playback?
>
>
> The graphics processor on the video card is not designed to send
> rendered output back to the main processor. OpenGL instructions come in
> one end, and rendered output goes out the other end ... to the monitor.
>
> It's unfortunate we can't intercept this data. Solid modelers such as
> Blender could probably use it, too. Maybe someday there will be enough
> market demand for the hardware to change.
>
> Craig.
>
>
> Leigh Wanstead wrote:
> > Hello everyone,
> >
> > I read this url.
> >
>
http://cvs.cinelerra.org/docs/split_manual_en/cinelerra_cv_manual_en_3.html#
> SEC41
> >
> > May I ask why OpenGL does not affect rendering, It just accelerates
> > playback? What is the reason?
> >
> > TIA
> >
> > Regards
> > Leigh
> > www.smootharm.com 
>
> ___
> 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