Re: [CinCVS] HDV workflow questions

[Dan Streetman]

On Nov 12, 2007 1:28 PM, flavio <[EMAIL PROTECTED]> wrote:
> Hi there,
> 1. Capturing
>
> As far as I've researched on the web there are few ways of capturing HDV
> material into a computer. The three process I found were via dvgrab3.0 (that
> would require a debian unstable system package), test-mpeg2 and mpg1394grab.
>
> I haven't installed dvgrab3.0 because I like to work on stable systems and I
> thought it would be nice if there was a way that wouldn't require an update
> on the whole machine. So I first tried test-mpeg2. The ./configure and make
> steps went fine, but I couldn't actually make it work. I can send the exact
> error then, but firstly I'd like to know if someone knows of a manual or
> something like that on the web. Mainly, I did a "test-mpeg2 > archive.ts"
> and it said it started receiving or something, and it did create the .ts
> file but wouldn't write anything on it. I plan to do future tests yet.

You should be able to build and install dvgrab 3.0.  I would not
recommend test-mpeg2 as it does not buffer at all and the chances of
dropping packets is high.

>
> mpg1394 worked nicely, no real efforts in capturing whatsoever, I'm happy
> with it even though it does not split files or control the camera, as dvgrab
> most likely would...

I haven't tried mpeg1394grab myself, so I don't know how it is.  If it
works for you, then it sounds good :)

> So the main question here would be about the funcionality of test-mpeg2
> really.

Don't use test-mpeg2.

> 2. exporting to camera
>
> This one relates to the previous question. As far as I've seen, it seems
> that only test-mpeg2 would export the HDV material back to the camera. And I
> would like to know if my computer would handle that (p4 ht 3.2), so I'd like
> to test it. But I couldn't make it work =(  And I also haven't found any
> nice tutorial on this particular step, so I'm a bit lost in this one. I
> guess so far it would be my main aim at this moment. Any hints? Even on
> other programs that would do the job?

I am almost certain that dvgrab does not currently export hdv back to
the camera, but adding this actually should not be too hard.  I'll add
it to my todo list unless someone gets to it before me :-)

I haven't looked at either other tool as far as hdv export, so I can't
comment on that.  But the same applies as for capture, the lack of
buffering in test-mpeg2 will probably cause dropped packets (i.e.
corrupted video).

>
> 3. editing
>
> I am following the steps in the cin manual. I have seen that my computer
> (cinelerra with no OpenGL) is not able to handle HDV footage by itself -
> that meaning: capturing, creating the .TOC files and opening them on
> cinelerra (1440x1080i) to edit. But I have also seen that for some people
> having OpenGL has not made an amazing difference.   So far it doesn't matter,
> because I plan to do the proxy editing, creating the Mjpeg + Wav = DV or MOV
> files and use the script to "reconvert" them back to HDV at rendering. My
> only question here would be: is it very worthy for me to change my cin to an
> OpenGL-able version? With DV it has been working tremendously fine under
> XV-X11...
>

OpenGL has made no difference for me; keep in mind that the OpenGL
acceleration only helps certain effects, it does not help mpeg
decoding (as far as I know).  I personally would not bother with
trying to get OpenGL to work if you are only doing basic editing
without effects.

I am also assuming that you are doing editing entirely in HDV, i.e.
your final edited project will be in HDV also, not downconverted to
standard def (e.g. for DVD or something like that).  If you have to
downconvert in cinelerra, it's not straightforward.

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

Re: [CinCVS] High Definition Input

[Dan Streetman]

sweet, maybe those special transport stream A1 packets are a standard
part of the HDV spec (if there is one...).  In any case seems to work
right :)

Thanks!

On 6/20/07, Aaron Newcomb <[EMAIL PROTECTED]> wrote:

Just a follow up. Here is an example of what I get for each frame when
I use --showstatus ...

"dvgrab-001.m2t":   386.73 MB 3593 frames timecode 00:08:46.07 date
2007.06.07 20:03:26

On 6/11/07, Aaron Newcomb <[EMAIL PROTECTED]> wrote:
> Using HDMI it should be possible to get close to raw uncompressed
> sensor data instead of what you get out of the firewire port which is
> already compressed. At least that is my understanding. Of course if
> you record to tape first instead of capturing direct from the camera
> it won't matter anyway since the compression is done when it writes to
> the tape.
>
> I will try to do another capture today and see if I am getting both
> timestamp and recording date.
>
> On 6/11/07, Marcin Kostur <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > What do you need HDMI for?
> >
> > Marcin
> >
> > ___
> > Cinelerra mailing list
> > Cinelerra@skolelinux.no
> > https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
> >
>
>
> --
> Thanks,
> Aaron Newcomb
> http://www.thesourceshow.org
> http://www.opennewsshow.org
>


--
Thanks,
Aaron Newcomb
http://www.thesourceshow.org
http://www.opennewsshow.org

___
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: [CinCVS] Re: A better MPEG-2 encoding than HDV

[Dan Streetman]

On 6/12/07, Terje J. Hanssen <[EMAIL PROTECTED]> wrote:

Q3) dvgrab with "hdv patch" for 422 mpeg-2/-4
Is the mentioned "hdv patch" for dvgrab limited to capture HDV mpeg2 of
[EMAIL PROTECTED] (4:2:0) only, or can it capture all types of mpeg2, also 
higher
HD of [EMAIL PROTECTED] and [EMAIL PROTECTED]


The hdv patch for dvgrab does only iec13818-1 (transport
stream/container) and partial iec13818-2 (mpeg video)
decoding/parsing, specifically it does not parse into any slices or
macroblocks.  Further, it does not do any stream modifications, the
data is simply passed through to a file with parsing needed only to
internally delineate frames and get stream/video metadata.

Given all that, I've only seen cameras that transfer HDV mpeg2 (4:2:0)
over firewire, do you have one that does something else?

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

Re: [CinCVS] High Definition Input

[Dan Streetman]

excellent!  Did it happen to show both timestamp and recording date?
The patch currently is getting the recording date from an undocumented
(at least, not in the mpeg2 spec) packet in the mpeg2 stream, so I
wonder if Canon uses the same thing or has some other way to encode
the recording date in the stream.

Thanks!

On 6/7/07, Aaron Newcomb <[EMAIL PROTECTED]> wrote:

Well, I finally got my camera and gave the patch a try. It worked
flawless on my Canon HV20. I ran it with the --showstatus option and
all I saw was my frames coming in like clockwork. Let me know if you
want me to test anything else and I will be happy to give it a try.

On 4/21/07, Aaron Newcomb <[EMAIL PROTECTED]> wrote:
> I am getting very serious about getting a new camera and I am leaning
> toward the Canon HV20. If I get one in the next few weeks I will
> definitely give this a try and let you know. Now if we could just get
> the blackmagic HDMI card working in Linux ...
>
> On 4/19/07, Dan Streetman <[EMAIL PROTECTED]> wrote:
> > Hmm, looks like adding the patch made the email too big for the
> > mailing list.  So, the patch is on the sourceforge kino patches page.
> > See email below for details.
> > 
http://sourceforge.net/tracker/index.php?func=detail&aid=1703694&group_id=14103&atid=314103
> >
> >
> > On 4/19/07, Dan Streetman <[EMAIL PROTECTED]> wrote:
> > > I just sent an updated dvgrab patch to the kino-dev mailing list,
> > > which is much improved.  Since there is interest on this list too,
> > > I'll attach a (bzip'ed) version here since everyone may not be on the
> > > kino-dev list.  Apply the same as before of course.  See --help for
> > > new options, specifically --hdv and --format mpeg2 are of interest.
> > > Also I added --showstatus because I like seeing exactly what's going
> > > on during capture...
> > >
> > > If anyone tries this with a non-Sony camera, please let me know if it
> > > does or doesn't work...and, if I could get some non-Sony HD sample
> > > clips, I would appreciate it...I pull the timecode, recording date,
> > > and scene change info out of a non-standard mpeg2 extension (i.e. Sony
> > > extension) so I'd like to see how other manufacturers put that info
> > > in.
> > >
> > > Thanks!
> > >
> > > On 4/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > >
> > > >  I'm using the hdv patch from kdenlive
> > > >  http://kdenlive.org/hdv.php
> > > >  To apply the patch Download cvs dvgrab 2.x copy the patch to that 
directory
> > > > and do:
> > > >  patch -i  > > >  then build as normal.
> > > >  To use the patch if you type dvgrab --help you will notice there is a 
new
> > > > option mpeg2 . Thats the hdv patch.
> > > >  capture by using dvgrab --mpeg2
> > > >  I'm using a sony hcr3
> > > >
> > > >  Using   test-mpeg2 I did not get avc control and got it working by 
running:
> > > >  test-mpeg2 | dvcont play
> > > >
> > > >  Alas current cinelerra-cvs still has playback bug unresolved rendering 
2
> > > > fps playback.
> > > >
> > > >  Kind Regards
> > > >  Daniel Jircik
> > > >
> > > >
> > > >
> > > >  -Original Message-
> > > >  From: [EMAIL PROTECTED]
> > > >  To: cinelerra@skolelinux.no
> > > >  Sent: Sun, 15 Apr 2007 4:24 PM
> > > >  Subject: Re: [CinCVS] High Definition Input
> > > >
> > > >
> > > >  On Sun, 2007-15-04 at 22:56 +0200, Herman Robak wrote:
> > > > > On Sun, 2007-04-15 at 14:48 -0400, Fred Williams wrote:
> > > > > > On Sun, 2007-15-04 at 14:50 +0200, Herman Robak wrote:
> > > > > >
> > > > > > > There are three ways:
> > > > > > >
> > > > > > > 1) mpg1394grab, which is distributed as a single file of C source
> > > > code.
> > > > > >
> > > > > > No idea how to install this, unfortunately
> > > > >
> > > > > It's rather obscure, and quite deprecated since libiec61883 came
> > > > > around. I have mirrored the single C source file here:
> > > > > http://www.nuug.no/pub/herman/mpg1394grab.c
> > > > >
> > > > > It must be linked with libraw1394
> > > > >
> > > >  That's the part I don't know how to do.
> >

Re: [CinCVS] Re: Down converting HDV to DV in camcorder

[Dan Streetman]

On 5/21/07, Terje J. Hanssen <[EMAIL PROTECTED]> wrote:

Dan Streetman wrote on Thu, 17 May 2007

> On 5/15/07, Terje J. Hanssen <[EMAIL PROTECTED]> wrote:
>> > Sony FX7E (i.LINK CONV ON) features a built-in hardware down convert
>> > from HDV on tape to DV output via the i.LINK cable, as so-called wide
>> > screen (anamorphic) DV.
>> >
>> > 1) Is this DV format useful to edit DV in Cinelerra as a base for
>> > creating DVD?
>
> Yes - since DVD is not HD.  The DV your camera produces is just normal DV.
>

What I merely thought of was the fact that HDV is 16:9 wide while I
think downconvert output using iLink becomes a DV 4:3 squeezed format.
That is a HDV circle becomes a vertical positioned elipse.

Can this anamorphic DV geometri be corrected in Cinelerra or possibly
using ffmpeg?


If a circle looks like an ellipse then you are viewing with the wrong
aspect and it sounds like you are correctly capturing 16:9 DV.  In
Cinelerra just change the project aspect to 16:9 and it will look
right.



- corrected to DV 16:9 wide
- corrected to DV 4:3 letterbox

>> > 2) Is this useful as DV draft or intermediate codec to edit in
>> > Cinelerra, before re-capturing full HDV using timecode to create a final
>> > BD/HDVD?
>
> No.  If you downconvert the video, you cannot convert back to HD.  The
> conversion reduces the resolution to normal DV resolution (i.e.
> NTSC/720x480 or PAL/720x576).
>

See my second reply

>> > 3) Or is native HDV capturing and editing in Cinelerra the prefered way
>> > to make maximum BD/HDVD quality video?
>
> If you want the final product to be HD, the source material has to be HD also.
>

See my second reply


Thanks,
Terje J. Hanssen


___
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: [CinCVS] HDV 1080i to 720p, Cinelerra doesn't like it

[Dan Streetman]

Aha!  So I think what you want is "proxy" editing, which has been
discussed some on this list in the past...you might want to search
back in the list archive to see how people have done it.  You will
probably have faster editing and a better end result if you use proxy
editing instead of just decreasing the video resolution a bit.

I think the basic idea is something like this before editing:
mv myvideo.mpg original-myvideo.mpg
ffmpeg -i original-myvideo.mpg [use some video/audio codecs] proxy-myvideo.mpg
ln -s proxy-myvideo.mpg myvideo.mpg

then open "myvideo.mpg" in cinelerra, do your editing, and when ready
to render close cinelerra and do:
rm myvideo.mpg
ln -s original-myvideo.mpg myvideo.mpg

then open cinelerra and it will load up the original video instead of
the proxy, and you can render at full quality.  As far as what
video/audio codecs to use to create the proxy, I don't know, as I
haven't done it myself.  Maybe mpeg2video at a low bitrate?

And to nit-pick (for no good reason), mpeg uses both interframe and
intraframe compression ;-)

On 5/17/07, Bas Alphenaar <[EMAIL PROTECTED]> wrote:

I want to do this because my computer and Cinelerra can't handle the raw
1080i MPEG-TS stream very well, it's just too slow. This is because MPEG
uses interframe compression of course. Because of this I want to
re-encode the MPEG-TS to a codec that uses intraframe compression.

Dan Streetman wrote:
> Not at all, you can do that.  For example you could load up the
> original 1080i in cinelerra, add "deinterlace" and "translate" effects
> (to convert from i to p and 1080 to 720), and then render the file.
> There are many render formats that cinelerra can read back, I would
> probably stick with mpeg2 (which unfortunately in cinelerra means you
> have to render video and audio separately and mplex them back together
> before re-loading into cinelerra).
>
> But again, why do you want to do this?  If you are just going to load
> the 720p file back into cinelerra, why not just use the 1080i file
> directly instead?
>
> On 5/6/07, Bas Alphenaar <[EMAIL PROTECTED]> wrote:
>> I'm not sure I understand the YUV story. Thanks for the help though!
>> But does this mean that it is impossible to convert 1080i HDV to 720p in
>> a format that Cinelerra understands?
>>
>> Dan Streetman wrote:
>> > Yes, cinelerra is currently rather limited in what files it can read
>> > (in my opinion, at least).  What I (used to) do is open the m2t file
>> > directly in cinelerra and use the (now removed) 1080to480 effect (only
>> > works if you are outputting NTSC) and the translate effect to change
>> > from 1080 to 720.  You can find the 1080to480 effect in the svn
>> > history, it was removed (changed) for some reason quite a while back.
>> > It's almost the same as 1080to540 but obviously the vert resolution is
>> > different.
>> >
>> > What I do now however is fix the quicktime colormodel translation
>> > because it incorrectly converts the interlaced YUV420 from the input
>> > file to the YUV888 (or RBG888, or any of the working formats), so the
>> > chroma channels are incorrectly interlaced - zoom in on any area of
>> > high motion with high color contrast and you'll see what I am talking
>> > about.  Unfortunately the quicktime lib doesn't check the input
>> > interlacing so I have to hack/hardcode the conversion, which means I
>> > can't use it to edit any progressive input that is in YUV420.  Note
>> > that the output also has to be fixed if you are using YUV4MPEGPIPE
>> > output since it (incorrectly) converts back to YUV420 before piping it
>> > out.
>> >
>> > Then, I use frames->fields then translate to resize each field then
>> > fields->frames to change back to interlaced 720x480.  Of course I had
>> > to also change the frames<->fields effects to correctly convert
>> > between frames/fields as the default effects double (or half) the
>> > vertical resolution for some reason.
>> >
>> > On 5/2/07, Bas Alphenaar <[EMAIL PROTECTED]> wrote:
>> >> Hello,
>> >>
>> >> A few days ago I posted a message on this mailinglist about the
>> >> Cinelerra viewer that crashed. This problem is solved, but I still
>> can't
>> >>  use Cinelerra properly because of another problem.
>> >>
>> >> I am running Cinelerra r1008 on Gentoo (amd64), I compiled with the
>> >> following options:
>> >>
>> >> ./configure --prefix=/usr --with-buildinfo=s

Re: [CinCVS] Rendering with blackbars for 16:9 on 4:3

[Dan Streetman]

You didn't mention if your video is interlaced or not, but if it is
then the translate effect will not correctly account for interlacing.
Hopefully your video is progressive :)

On 5/16/07, replicant <[EMAIL PROTECTED]> wrote:

> Set your ratio to 4:3 - that is the ratio you want in the rendered
> track.  Not sure why it would resize your input track...So to correct this:
>
> Drag the translation effect over your track.  You then have all the
> parameters you need.  I'm guessing you mainly need to set 'Out H'
> (reduce it until the ratio is correct again) and possibly Y (to move the
> letterbox opening down the screen).

that did it .. thanks!

___
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: [CinCVS] Down converting HDV to DV in camcorder

[Dan Streetman]

On 5/15/07, Terje J. Hanssen <[EMAIL PROTECTED]> wrote:

Sony FX7E (i.LINK CONV ON) features a built-in hardware down convert
from HDV on tape to DV output via the i.LINK cable, as so-called wide
screen (anamorphic) DV.

1) Is this DV format useful to edit DV in Cinelerra as a base for
creating DVD?


Yes - since DVD is not HD.  The DV your camera produces is just normal DV.


2) Is this useful as DV draft or intermediate codec to edit in
Cinelerra, before re-capturing full HDV using timecode to create a final
BD/HDVD?


No.  If you downconvert the video, you cannot convert back to HD.  The
conversion reduces the resolution to normal DV resolution (i.e.
NTSC/720x480 or PAL/720x576).


3) Or is native HDV capturing and editing in Cinelerra the prefered way
to make maximum BD/HDVD quality video?


If you want the final product to be HD, the source material has to be HD also.

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

Re: [CinCVS] HDV 1080i to 720p, Cinelerra doesn't like it

[Dan Streetman]

I would check these things:

-project video size
open "Settings->Format" (or Shift-F) and check that the video
width/height matches PAL (or use the PAL Preset).  Make sure
interlacing is marked as progressive.

-track video size
On your HD video track right-click and select "Resize track".  It
needs to match your actual HD video size, so 1024x768 in your case.
This unfortunately defaults to the project size in my case, so this
might be your problem.

-translate effect settings
You need to translate both the size (width/height) and the location
onscreen.  The "InX" and "InY" settings should 0.  The "OutX" and
"OutY" settings need to place the final image in the center of the HD
resolution.  You can either just adjust these settings until it looks
right in the compositor, or use this formula to figure the right
numbers.
OutX = (InW - OutW) / 2
OutY = (InH - OutH) / 2


You do not need to adjust the camera or projector automation at all.

On 5/10/07, Edouard Chalaron <[EMAIL PROTECTED]> wrote:


 Hi there
 I have somehow the same issue here. I tried to "translate" from a 1024x768
progressive frames to PAL mpeg2 as a final rendering and it gives a small
video in a corner of a big frame...
 Did I miss anything ?
 Thanks
 E



 On Wed, 2007-05-09 at 18:06 -0400, Dan Streetman wrote:
 Not at all, you can do that. For example you could load up the
original 1080i in cinelerra, add "deinterlace" and "translate" effects
(to convert from i to p and 1080 to 720), and then render the file.
There are many render formats that cinelerra can read back, I would
probably stick with mpeg2 (which unfortunately in cinelerra means you
have to render video and audio separately and mplex them back together
before re-loading into cinelerra).

But again, why do you want to do this? If you are just going to load
the 720p file back into cinelerra, why not just use the 1080i file
directly instead?

On 5/6/07, Bas Alphenaar <[EMAIL PROTECTED]> wrote:
> I'm not sure I understand the YUV story. Thanks for the help though!
> But does this mean that it is impossible to convert 1080i HDV to 720p in
> a format that Cinelerra understands?
>
> Dan Streetman wrote:
> > Yes, cinelerra is currently rather limited in what files it can read
> > (in my opinion, at least). What I (used to) do is open the m2t file
> > directly in cinelerra and use the (now removed) 1080to480 effect (only
> > works if you are outputting NTSC) and the translate effect to change
> > from 1080 to 720. You can find the 1080to480 effect in the svn
> > history, it was removed (changed) for some reason quite a while back.
> > It's almost the same as 1080to540 but obviously the vert resolution is
> > different.
> >
> > What I do now however is fix the quicktime colormodel translation
> > because it incorrectly converts the interlaced YUV420 from the input
> > file to the YUV888 (or RBG888, or any of the working formats), so the
> > chroma channels are incorrectly interlaced - zoom in on any area of
> > high motion with high color contrast and you'll see what I am talking
> > about. Unfortunately the quicktime lib doesn't check the input
> > interlacing so I have to hack/hardcode the conversion, which means I
> > can't use it to edit any progressive input that is in YUV420. Note
> > that the output also has to be fixed if you are using YUV4MPEGPIPE
> > output since it (incorrectly) converts back to YUV420 before piping it
> > out.
> >
> > Then, I use frames->fields then translate to resize each field then
> > fields->frames to change back to interlaced 720x480. Of course I had
> > to also change the frames<->fields effects to correctly convert
> > between frames/fields as the default effects double (or half) the
> > vertical resolution for some reason.
> >
> > On 5/2/07, Bas Alphenaar <[EMAIL PROTECTED]> wrote:
> >> Hello,
> >>
> >> A few days ago I posted a message on this mailinglist about the
> >> Cinelerra viewer that crashed. This problem is solved, but I still
can't
> >> use Cinelerra properly because of another problem.
> >>
> >> I am running Cinelerra r1008 on Gentoo (amd64), I compiled with the
> >> following options:
> >>
> >> ./configure --prefix=/usr --with-buildinfo=svn/recompile --enable-mmx
> >> --enable-3dnow --with-external-ffmpeg
> >>
> >> Quote from my other post:
> >>
> >> > I have an HDV camcorder (Sony HDR-HC1) and I capture the MPEG-TS
stream
> >> > via Firewire using dvgrab with the HDV patch.
> >>
> >> When the capturing is done, I have a fresh *.m2t file

Re: [CinCVS] HDV 1080i to 720p, Cinelerra doesn't like it

[Dan Streetman]

Not at all, you can do that.  For example you could load up the
original 1080i in cinelerra, add "deinterlace" and "translate" effects
(to convert from i to p and 1080 to 720), and then render the file.
There are many render formats that cinelerra can read back, I would
probably stick with mpeg2 (which unfortunately in cinelerra means you
have to render video and audio separately and mplex them back together
before re-loading into cinelerra).

But again, why do you want to do this?  If you are just going to load
the 720p file back into cinelerra, why not just use the 1080i file
directly instead?

On 5/6/07, Bas Alphenaar <[EMAIL PROTECTED]> wrote:

I'm not sure I understand the YUV story. Thanks for the help though!
But does this mean that it is impossible to convert 1080i HDV to 720p in
a format that Cinelerra understands?

Dan Streetman wrote:
> Yes, cinelerra is currently rather limited in what files it can read
> (in my opinion, at least).  What I (used to) do is open the m2t file
> directly in cinelerra and use the (now removed) 1080to480 effect (only
> works if you are outputting NTSC) and the translate effect to change
> from 1080 to 720.  You can find the 1080to480 effect in the svn
> history, it was removed (changed) for some reason quite a while back.
> It's almost the same as 1080to540 but obviously the vert resolution is
> different.
>
> What I do now however is fix the quicktime colormodel translation
> because it incorrectly converts the interlaced YUV420 from the input
> file to the YUV888 (or RBG888, or any of the working formats), so the
> chroma channels are incorrectly interlaced - zoom in on any area of
> high motion with high color contrast and you'll see what I am talking
> about.  Unfortunately the quicktime lib doesn't check the input
> interlacing so I have to hack/hardcode the conversion, which means I
> can't use it to edit any progressive input that is in YUV420.  Note
> that the output also has to be fixed if you are using YUV4MPEGPIPE
> output since it (incorrectly) converts back to YUV420 before piping it
> out.
>
> Then, I use frames->fields then translate to resize each field then
> fields->frames to change back to interlaced 720x480.  Of course I had
> to also change the frames<->fields effects to correctly convert
> between frames/fields as the default effects double (or half) the
> vertical resolution for some reason.
>
> On 5/2/07, Bas Alphenaar <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> A few days ago I posted a message on this mailinglist about the
>> Cinelerra viewer that crashed. This problem is solved, but I still can't
>>  use Cinelerra properly because of another problem.
>>
>> I am running Cinelerra r1008 on Gentoo (amd64), I compiled with the
>> following options:
>>
>> ./configure --prefix=/usr --with-buildinfo=svn/recompile --enable-mmx
>> --enable-3dnow --with-external-ffmpeg
>>
>> Quote from my other post:
>>
>> > I have an HDV camcorder (Sony HDR-HC1) and I capture the MPEG-TS stream
>> > via Firewire using dvgrab with the HDV patch.
>>
>> When the capturing is done, I have a fresh *.m2t file in 1080i. I tried
>> to convert this file to 720p in several ways but none of them works.
>>
>> These are the things I tried, at every point I give the command that I
>> used to create the 720p video and how Cinelerra handled the video:
>>
>> --
>>
>> 1. ffmpeg H.264 with AVI container
>>
>> ffmpeg -i dvgrab-001.m2t -deinterlace -s 1280x720 -vcodec h264 -qmin 10
>> -qmax 15 -acodec mp3 -ab 256k 1.avi
>>
>> The Viewer shows nothing, no sound, the commandline says this:
>>
>> new_acodec: couldn't find codec for "
"
>> new_vcodec: couldn't find codec for "h264"
>> new_acodec: couldn't find codec for "
"
>> new_vcodec: couldn't find codec for "h264"
>>
>> (Yes, it is outputted twice)
>>
>> --
>>
>> 2. ffmpeg H.264 with MOV container
>>
>> ffmpeg -i dvgrab-001.m2t -deinterlace -s 1280x720 -vcodec h264 -qmin 10
>> -qmax 15 -acodec mp3 -ab 256k 2.mov
>>
>> The video works and sometimes the sound also works (?), but the sound is
>> not in sync when it works (I am using ALSA). Cinelerra also throws this
>> error in an error window randomly while navigating through the video
>> with the Viewer:
>>
>> virtual int FileMOV::read_frame(VFrame*):
>> quicktime_read_frame/quicktime_decode_video failed, result:
>>
>> (http://bugs.cinelerra.org/buglist.cgi?quicksearch=quick

Re: [CinCVS] HDV 1080i to 720p, Cinelerra doesn't like it

[Dan Streetman]

Yes, cinelerra is currently rather limited in what files it can read
(in my opinion, at least).  What I (used to) do is open the m2t file
directly in cinelerra and use the (now removed) 1080to480 effect (only
works if you are outputting NTSC) and the translate effect to change
from 1080 to 720.  You can find the 1080to480 effect in the svn
history, it was removed (changed) for some reason quite a while back.
It's almost the same as 1080to540 but obviously the vert resolution is
different.

What I do now however is fix the quicktime colormodel translation
because it incorrectly converts the interlaced YUV420 from the input
file to the YUV888 (or RBG888, or any of the working formats), so the
chroma channels are incorrectly interlaced - zoom in on any area of
high motion with high color contrast and you'll see what I am talking
about.  Unfortunately the quicktime lib doesn't check the input
interlacing so I have to hack/hardcode the conversion, which means I
can't use it to edit any progressive input that is in YUV420.  Note
that the output also has to be fixed if you are using YUV4MPEGPIPE
output since it (incorrectly) converts back to YUV420 before piping it
out.

Then, I use frames->fields then translate to resize each field then
fields->frames to change back to interlaced 720x480.  Of course I had
to also change the frames<->fields effects to correctly convert
between frames/fields as the default effects double (or half) the
vertical resolution for some reason.

On 5/2/07, Bas Alphenaar <[EMAIL PROTECTED]> wrote:

Hello,

A few days ago I posted a message on this mailinglist about the
Cinelerra viewer that crashed. This problem is solved, but I still can't
 use Cinelerra properly because of another problem.

I am running Cinelerra r1008 on Gentoo (amd64), I compiled with the
following options:

./configure --prefix=/usr --with-buildinfo=svn/recompile --enable-mmx
--enable-3dnow --with-external-ffmpeg

Quote from my other post:

> I have an HDV camcorder (Sony HDR-HC1) and I capture the MPEG-TS stream
> via Firewire using dvgrab with the HDV patch.

When the capturing is done, I have a fresh *.m2t file in 1080i. I tried
to convert this file to 720p in several ways but none of them works.

These are the things I tried, at every point I give the command that I
used to create the 720p video and how Cinelerra handled the video:

--

1. ffmpeg H.264 with AVI container

ffmpeg -i dvgrab-001.m2t -deinterlace -s 1280x720 -vcodec h264 -qmin 10
-qmax 15 -acodec mp3 -ab 256k 1.avi

The Viewer shows nothing, no sound, the commandline says this:

new_acodec: couldn't find codec for "
"
new_vcodec: couldn't find codec for "h264"
new_acodec: couldn't find codec for "
"
new_vcodec: couldn't find codec for "h264"

(Yes, it is outputted twice)

--

2. ffmpeg H.264 with MOV container

ffmpeg -i dvgrab-001.m2t -deinterlace -s 1280x720 -vcodec h264 -qmin 10
-qmax 15 -acodec mp3 -ab 256k 2.mov

The video works and sometimes the sound also works (?), but the sound is
not in sync when it works (I am using ALSA). Cinelerra also throws this
error in an error window randomly while navigating through the video
with the Viewer:

virtual int FileMOV::read_frame(VFrame*):
quicktime_read_frame/quicktime_decode_video failed, result:

(http://bugs.cinelerra.org/buglist.cgi?quicksearch=quicktime_read_frame
shows 2 bugs about this problem, so I don't think it can be solved
without somebody who can program)

--

3. ffmpeg H.264 with MOV container (but with AC3 codec)

ffmpeg -i dvgrab-001.m2t -deinterlace -s 1280x720 -vcodec h264 -qmin 10
-qmax 15 -acodec ac3 ac3.mov

The video plays in the Viewer, the sound doesn't. The commandline shows
this:

new_acodec: couldn't find codec for "ms "
new_acodec: couldn't find codec for "ms "
new_acodec: couldn't find codec for "ms "
new_acodec: couldn't find codec for "ms "

--

4. mencoder H.264 with AVI container

mencoder dvgrab-001.m2t -ovc x264 -oac mp3lame -vf pp=ci,scale=1280:720
-o 4.avi

The Viewer shows nothing and there is no sound, the commandline outputs
this:

new_vcodec: couldn't find codec for "h264"
new_vcodec: couldn't find codec for "h264"

--

5. ffmpeg MJPEG with AVI container

ffmpeg -i dvgrab-001.m2t -deinterlace -s 1280x720 -vcodec mjpeg -acodec
mp3 -ab 256k 5.avi

No video or sound in the Viewer, can't even move the navigation button.
The commandline shows this:

new_acodec: couldn't find codec for "
"
new_acodec: couldn't find codec for "
"
new_acodec: couldn't find codec for "
"

--

Is Cinelerra very picky on the video files it can use or am I making a
mistake here?

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



___
Cinelerra mailing list
Cinelerra@skolel

Re: [CinCVS] High Definition Input

[Dan Streetman]

Hmm, looks like adding the patch made the email too big for the
mailing list.  So, the patch is on the sourceforge kino patches page.
See email below for details.
http://sourceforge.net/tracker/index.php?func=detail&aid=1703694&group_id=14103&atid=314103


On 4/19/07, Dan Streetman <[EMAIL PROTECTED]> wrote:

I just sent an updated dvgrab patch to the kino-dev mailing list,
which is much improved.  Since there is interest on this list too,
I'll attach a (bzip'ed) version here since everyone may not be on the
kino-dev list.  Apply the same as before of course.  See --help for
new options, specifically --hdv and --format mpeg2 are of interest.
Also I added --showstatus because I like seeing exactly what's going
on during capture...

If anyone tries this with a non-Sony camera, please let me know if it
does or doesn't work...and, if I could get some non-Sony HD sample
clips, I would appreciate it...I pull the timecode, recording date,
and scene change info out of a non-standard mpeg2 extension (i.e. Sony
extension) so I'd like to see how other manufacturers put that info
in.

Thanks!

On 4/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>  I'm using the hdv patch from kdenlive
>  http://kdenlive.org/hdv.php
>  To apply the patch Download cvs dvgrab 2.x copy the patch to that directory
> and do:
>  patch -i   then build as normal.
>  To use the patch if you type dvgrab --help you will notice there is a new
> option mpeg2 . Thats the hdv patch.
>  capture by using dvgrab --mpeg2
>  I'm using a sony hcr3
>
>  Using   test-mpeg2 I did not get avc control and got it working by running:
>  test-mpeg2 | dvcont play
>
>  Alas current cinelerra-cvs still has playback bug unresolved rendering 2
> fps playback.
>
>  Kind Regards
>  Daniel Jircik
>
>
>
>  -Original Message-
>  From: [EMAIL PROTECTED]
>  To: cinelerra@skolelinux.no
>  Sent: Sun, 15 Apr 2007 4:24 PM
>  Subject: Re: [CinCVS] High Definition Input
>
>
>  On Sun, 2007-15-04 at 22:56 +0200, Herman Robak wrote:
> > On Sun, 2007-04-15 at 14:48 -0400, Fred Williams wrote:
> > > On Sun, 2007-15-04 at 14:50 +0200, Herman Robak wrote:
> > >
> > > > There are three ways:
> > > >
> > > > 1) mpg1394grab, which is distributed as a single file of C source
> code.
> > >
> > > No idea how to install this, unfortunately
> >
> > It's rather obscure, and quite deprecated since libiec61883 came
> > around. I have mirrored the single C source file here:
> > http://www.nuug.no/pub/herman/mpg1394grab.c
> >
> > It must be linked with libraw1394
> >
>  That's the part I don't know how to do.
>
> >
> > > > 2) test-mpeg2, which is found in the _source_ package for libiec61883
> > > > (available in Ubuntu's repositories)
> > >
> > > Synaptic says the libiec61883 library is installed, but I presume this
> > > is terminal stuff. When I type "test-mpeg2 -h" in, it's an
> > > unrecognizable command.
> >
> > Not part of the binary package. It's one of the "examples" in the
> > source package. You can install and build that. Not much to it. :-)
> >
>  If you know how. (;-)) I used to work in computers, but it was a long
> time ago and in FORTRAN IV.
>
> >
> > > > 3) A patched version of dvgrab. This is apparently the most robust
> > > > alternative, as it does proper buffering.
> > > >
> > > I found the patch online, but have no idea how to install it.
> >
> > Nor do I. About time to suggest the patch to the developers of
> > dvgrab, or create a hdvgrab "fork".
> >
>  Good idea. Or, an upgrade to Kino, or the Cinelerra poeple could add
> it with the DV capability when they get around to it.
>
>
> ___
> Cinelerra mailing list
> Cinelerra@skolelinux.no
> https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
>
>
>  
>  Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading
> spam and email virus protection.
>




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

Re: [CinCVS] my cinelerra involvement

[Dan Streetman]

I've just finished writing a patch to add full HDV read support to
dvgrab and am about to send that off to their mailing list, so my next
project was going to be working some more on cinelerra, since I use it
exclusively for video editing...so, I'll be glad to help as much as I
can.  Probably not at a super fast pace, but I can provide some help.
I was planning next on adding direct support for reading files with
ffmpeg (libavcodec/libavformat).

On 4/16/07, Andraž Tori <[EMAIL PROTECTED]> wrote:


Lately i had almost no time to hack on cinelerra and it doesn't seem
that situation will improve in forseeable future.

Therefore, I'd like to point out that cinelerra is in need of new
manpower to keep it in good condition. Currently there are at least a
few grave bugs that have to be fixed, but are quite hard to track down
(freezing when moving edits when having multiple tracks being one of
them)

I believe we can be a bit more liberal with svn access, since we really
have a big problem at hand...

so please, if you have any time to work on cinelerra, stand up...

bye
andraz


___
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: Swap? (was Re: [CinCVS] constant hangs on HDV project)

[Dan Streetman]

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

On 2007-02-12 20:30, Dan Streetman wrote:
> On 2/11/07, Kevin Brosius <[EMAIL PROTECTED]> wrote:
> > On 2007-02-05 20:24, Dan Streetman wrote:
> > > On 2/5/07, Nicolas Maufrais <[EMAIL PROTECTED]> wrote:
> > > > Heroine Virtual Ltd recommends disabling swap when a lot of memory is
> > > > installed.
> > >
> > > This is not a good idea under any circumstances.  Disabling swap will
> > > never help anything or improve performance, ever.  It will only cause
> > > the system to start killing processes when you use up all system
> > > memory.  Do not disable swap.
> >
> > Hi Dan,
> >
> > This will only be true for kernels with the OOM killer running, right?


It's irrelevant; whether you have it or not, if you have swap disabled
and run out of real memory, then real bad things will happen.


The only reason I know this is because I used to be able to build an
xfree86 source tree, and a second compile could sometimes run without
disk access.  That tree was on the order of 100M at the time.  I could
imagine that disk cache might have been weighted poorly in the paging
algorithm at some point.  If that was half the mem, then the swap
comments above might be related to that.  Remember, we are talking about
Cin usage, which would be disk intensive for render writes/reads, along
with page hungry for effects processing.  The mix may be different for
single app usage than the test case you suggest below.

The disk caching is interesting, because with the advent of reiser, and
slightly newer kernels, I noticed that disk caching was nothing like
ext2.  It would not cache an entire 100M source code true when accessed
with reiser, although that may have been an artifact of slightly newer
kernels.  I do not recall if I tested that or not.

So, you think disk caching has no impact?  Possible, I haven't tried
testing on a 4G machine.


Disc caching is irrelevant to swapping.  Linux will use _all_ "free"
(real) memory for disc caching, and reduce the cache as programs
request more and more memory to actually use.  When the actual memory
used by system programs approaches real memory limits, the cached
memory will approach 0.

How much sense does it make to swap out disc cache?  ;-)

Maybe you would like to try it yourself like I suggested?  I'll make
it easy, I've attached a very small trivial program that will quickly
eat up all your system memory.  Run it first with swap enabled and
then without.  Compile with "gcc -o memory-eater memory-eater.c"

If you want to bring disc caching into it, do:
dd if=/dev/zero of=/tmp/big-file bs=1024k count=4k ; memory-eater

note the "4k" is 4G of ram, if you have less just use a smaller
number, as the disc cache obviously can't exceed real system memory :)

I also attached 4 images from when I did this on my system, which
hopefully will show you that what I am saying is true; swapping does
not happen until real system memory is used up, and disc caching is
completely irrelevant to swapping. (#1 is after disc cache reaches
real system memory - no swap used, #2 is when real used memory
reaches/slightly exceeds real system memory - no cache, small swap, #3
is showing continued swap usage - no cache, #4 is after killing the
program)

And a final note, when you run that program with swap disabled, the
kernel's OOM killer will probably kill only that program.  You can
disable the OOM killer (at least, "man malloc" says you can...) by
doing "echo 2 > /proc/sys/vm/overcommit_memory", so if you want you
can try it without swap _and_ without the OOM killer I'd be interested
to hear what happens there! ;-)


memory-eater.c
Description: Binary data


memory-eater1.gif
Description: GIF image


memory-eater2.gif
Description: GIF image


memory-eater3.gif
Description: GIF image


memory-eater4.gif
Description: GIF image

Re: Swap? (was Re: [CinCVS] constant hangs on HDV project)

[Dan Streetman]

On 2/11/07, Kevin Brosius <[EMAIL PROTECTED]> wrote:

On 2007-02-05 20:24, Dan Streetman wrote:
> On 2/5/07, Nicolas Maufrais <[EMAIL PROTECTED]> wrote:
> > Heroine Virtual Ltd recommends disabling swap when a lot of memory is
> > installed.
>
> This is not a good idea under any circumstances.  Disabling swap will
> never help anything or improve performance, ever.  It will only cause
> the system to start killing processes when you use up all system
> memory.  Do not disable swap.

Hi Dan,

This will only be true for kernels with the OOM killer running, right?


Is "running" the right adjective?  I think the OOM killer is part of
the memory allocation subsystem, not a kernel process, right?  So ever
since it was added to the kernel it is there.  I don't think you can
build a kernel without it these days, can you?  But if you mean
kernels before the OOM killer was added, sure...that was a looong time
ago tho.

But that's beside the point.  If you run out of memory, either the
kernel kills picks a single program to kill and let everything else in
the system live (i.e. with OOM killer), or _everything_ on the system
dies a slow and painful death (i.e. without OOM killer).


Here's the link to comments from Cinelerra's author about swap usage:
http://cvs.cinelerra.org/docs/wiki/doku.php?id=english_manual:cinelerra_cv_en_20#disabling_swap_space

I've seen system behavior that makes me believe his comments about disk
caching using system memory (back in ext2 days.)  Maybe this is no
longer true for newer kernels.  But I suspect your 'never help' comment
might be overzealous.  ;)  Would you say newer kernels with current
versions of filesystems no longer exhibit this behavior?  Or is
something else going on here?


Ok, maybe "never help" is a bit extreme... ;-)

Recent kernels do not start swapping pages out when memory is 1/2 full
(as stated in that FAQ).  I'm typing this from a system with 1G of
memory, 900M of which is in use right now, and swap is 588K.  I've
been using Linux (Slackware) since 1997, and I don't ever remember
that behavior.  But hey, I can't say for sure that it has never been
true.  There very well may be some very old kernels that swap
overzealously like that...I can only say I've never seen it in ~10
years of Linux use.

I would recommend 2 things, first get a program that constantly
monitors system stats (I run xosview 100% of the time and have for
many years...xosview.sf.net).  Then second, (with swap enabled) start
up cinelerra and/or some other large programs and start eating up
memory.  See at what point swapping starts and how much memory is
swapped.  See what happens when program memory requirements exceed
system memory, i.e. used system memory + swap used exceed total system
memory.  Then shut everything down and disable swap, and start up
those programs again and eat up more than system memory and see what
happens (hint: don't be doing anything important when you try this
:-).  Until system memory ran out, was the no-swap case any better
than the swap case?  Was swap significantly used before system memory
usage run up to near 100%?  What happened when you ran out of memory
and had no swap?

I suspect everyone will find that the system behaves identically until
memory usage gets very close to total available system memory, and
when memory usage exceeds available system memory the swap/no-swap
cases are very different.  But if the test shows no-swap is better for
you, by all means don't use swap...

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

Re: [CinCVS] constant hangs on HDV project

[Dan Streetman]

On 2/5/07, Nicolas Maufrais <[EMAIL PROTECTED]> wrote:

Heroine Virtual Ltd recommends disabling swap when a lot of memory is
installed.


This is not a good idea under any circumstances.  Disabling swap will
never help anything or improve performance, ever.  It will only cause
the system to start killing processes when you use up all system
memory.  Do not disable swap.

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

Re: [CinCVS] HDV to DVD (interlaced and PAL)

[Dan Streetman]

Ick, it's the 4:2:0 chroma sampling, I believe.  Why oh why doesn't
HDV use 4:1:1 or 4:2:2?  Does anyone know if there is any good way to
handle this?  The 1080to540 effect, as far as I can tell, does 4-row
field averaging to overcome this which doesn't sound to me to be the
best method.  Is it?

For anyone who isn't familiar with 4:2:0 chroma subsampling and interested:
http://en.wikipedia.org/wiki/4:2:0

On 2/1/07, Dan Streetman <[EMAIL PROTECTED]> wrote:

Ok, don't use that yet! :)

The color interlacing is wrong, in my tests at least.

On 1/31/07, Dan Streetman <[EMAIL PROTECTED]> wrote:
> Ok try the attached patch (i.e. apply and rebuild cinelerra) and then:
>
> 1) load HDV track (make sure track size matches HDV size, e.g. 1440x1080)
> 2) add "Frames to Fields" effect, disable "Double Fields to original height"
> 3) add "Translate" effect, use 0x0, 1440x1080 input; 360x126, 720x576 output
> 4) add "Fields to Frames" effect, disable "Fields Doubled to orginal height"
>
> that will do all the resizing/scaling in the "field domain" i.e., it
> will resize each field independently to really whatever size you want,
> and recombine them to a new interlaced frame.  The numbers in the
> translate example are what my quick calculations show for 1440x1080
> HDV and normal PAL.  This should work just as well for NTSC but with
> adjusted "Translate" Y numbers (i.e. 126->150 and 576->480).
>
> I haven't tested it yet, have to stop for the night but I'll check it
> tomorrow.  Let me know if it works for you.  I want to recheck the
> field ordering for each effect, although I think at first check they
> are right.  I also should "blank" out the unused half when not
> doubling fields.
>
> Thanks.
>
> On 1/31/07, Dan Streetman <[EMAIL PROTECTED]> wrote:
> > Oops, since I use only NTSC (480 H) I mis-spoke on the PAL dimensions.
> >  PAL is apparently actually 576!  So as far as I know you are right,
> > without a "1080 to 576" effect there is no way to convert 1080i to
> > 576i (PAL) inside cinelerra.  Either another "1080 to" effect is
> > needed or the other solution I mentioned needs to be added.  The
> > second solution I mentioned should actually be a very easy change and
> > should be generic, i.e. will accomplish 1080 to anything interlaced
> > scaling.  I will see if I can code something up today...
> >
> > As far as the "1080 to 540" effect, as I said I assumed this was for
> > PAL.  If it isn't, I have no idea what the use for this effect
> > is...the original "1080 to 480" was at least useful for people
> > converting to NTSC.
> >
> > And I agree on scripting...it can be very useful!  Sometimes though,
> > it is much harder to debug with a lot of scripting.
> >
> > On 1/31/07, Marcin Kostur <[EMAIL PROTECTED]> wrote:
> > > Dear Dan,
> > >
> > > Thanks for tips. I will try them. If they work i will make
> > > somthing like bg-render template for HDV file.
> > >
> > > [OT]
> > > Your description is also a good example how nice skripting is.
> > > If cin would be 100% scriptable, then you would just copy me you line
> > > which i would pasted in my xterm. ;-) Recenly i got involved in stupid
> > > disscussion in slashcam.de, were a guy said that because all those
> > > "long commands" linux is unacceptable. In my opinion it is windows GUI
> > > unacceptable for me because of "cliking only habit".
> > >
> > >
> > > The best
> > >
> > >   Marcin
> > >
> > > ___
> > > 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: [CinCVS] HDV to DVD (interlaced and PAL)

[Dan Streetman]

Ok, don't use that yet! :)

The color interlacing is wrong, in my tests at least.

On 1/31/07, Dan Streetman <[EMAIL PROTECTED]> wrote:

Ok try the attached patch (i.e. apply and rebuild cinelerra) and then:

1) load HDV track (make sure track size matches HDV size, e.g. 1440x1080)
2) add "Frames to Fields" effect, disable "Double Fields to original height"
3) add "Translate" effect, use 0x0, 1440x1080 input; 360x126, 720x576 output
4) add "Fields to Frames" effect, disable "Fields Doubled to orginal height"

that will do all the resizing/scaling in the "field domain" i.e., it
will resize each field independently to really whatever size you want,
and recombine them to a new interlaced frame.  The numbers in the
translate example are what my quick calculations show for 1440x1080
HDV and normal PAL.  This should work just as well for NTSC but with
adjusted "Translate" Y numbers (i.e. 126->150 and 576->480).

I haven't tested it yet, have to stop for the night but I'll check it
tomorrow.  Let me know if it works for you.  I want to recheck the
field ordering for each effect, although I think at first check they
are right.  I also should "blank" out the unused half when not
doubling fields.

Thanks.

On 1/31/07, Dan Streetman <[EMAIL PROTECTED]> wrote:
> Oops, since I use only NTSC (480 H) I mis-spoke on the PAL dimensions.
>  PAL is apparently actually 576!  So as far as I know you are right,
> without a "1080 to 576" effect there is no way to convert 1080i to
> 576i (PAL) inside cinelerra.  Either another "1080 to" effect is
> needed or the other solution I mentioned needs to be added.  The
> second solution I mentioned should actually be a very easy change and
> should be generic, i.e. will accomplish 1080 to anything interlaced
> scaling.  I will see if I can code something up today...
>
> As far as the "1080 to 540" effect, as I said I assumed this was for
> PAL.  If it isn't, I have no idea what the use for this effect
> is...the original "1080 to 480" was at least useful for people
> converting to NTSC.
>
> And I agree on scripting...it can be very useful!  Sometimes though,
> it is much harder to debug with a lot of scripting.
>
> On 1/31/07, Marcin Kostur <[EMAIL PROTECTED]> wrote:
> > Dear Dan,
> >
> > Thanks for tips. I will try them. If they work i will make
> > somthing like bg-render template for HDV file.
> >
> > [OT]
> > Your description is also a good example how nice skripting is.
> > If cin would be 100% scriptable, then you would just copy me you line
> > which i would pasted in my xterm. ;-) Recenly i got involved in stupid
> > disscussion in slashcam.de, were a guy said that because all those
> > "long commands" linux is unacceptable. In my opinion it is windows GUI
> > unacceptable for me because of "cliking only habit".
> >
> >
> > The best
> >
> >   Marcin
> >
> > ___
> > 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: [CinCVS] HDV to DVD (interlaced and PAL)

[Dan Streetman]

Ok try the attached patch (i.e. apply and rebuild cinelerra) and then:

1) load HDV track (make sure track size matches HDV size, e.g. 1440x1080)
2) add "Frames to Fields" effect, disable "Double Fields to original height"
3) add "Translate" effect, use 0x0, 1440x1080 input; 360x126, 720x576 output
4) add "Fields to Frames" effect, disable "Fields Doubled to orginal height"

that will do all the resizing/scaling in the "field domain" i.e., it
will resize each field independently to really whatever size you want,
and recombine them to a new interlaced frame.  The numbers in the
translate example are what my quick calculations show for 1440x1080
HDV and normal PAL.  This should work just as well for NTSC but with
adjusted "Translate" Y numbers (i.e. 126->150 and 576->480).

I haven't tested it yet, have to stop for the night but I'll check it
tomorrow.  Let me know if it works for you.  I want to recheck the
field ordering for each effect, although I think at first check they
are right.  I also should "blank" out the unused half when not
doubling fields.

Thanks.

On 1/31/07, Dan Streetman <[EMAIL PROTECTED]> wrote:

Oops, since I use only NTSC (480 H) I mis-spoke on the PAL dimensions.
 PAL is apparently actually 576!  So as far as I know you are right,
without a "1080 to 576" effect there is no way to convert 1080i to
576i (PAL) inside cinelerra.  Either another "1080 to" effect is
needed or the other solution I mentioned needs to be added.  The
second solution I mentioned should actually be a very easy change and
should be generic, i.e. will accomplish 1080 to anything interlaced
scaling.  I will see if I can code something up today...

As far as the "1080 to 540" effect, as I said I assumed this was for
PAL.  If it isn't, I have no idea what the use for this effect
is...the original "1080 to 480" was at least useful for people
converting to NTSC.

And I agree on scripting...it can be very useful!  Sometimes though,
it is much harder to debug with a lot of scripting.

On 1/31/07, Marcin Kostur <[EMAIL PROTECTED]> wrote:
> Dear Dan,
>
> Thanks for tips. I will try them. If they work i will make
> somthing like bg-render template for HDV file.
>
> [OT]
> Your description is also a good example how nice skripting is.
> If cin would be 100% scriptable, then you would just copy me you line
> which i would pasted in my xterm. ;-) Recenly i got involved in stupid
> disscussion in slashcam.de, were a guy said that because all those
> "long commands" linux is unacceptable. In my opinion it is windows GUI
> unacceptable for me because of "cliking only habit".
>
>
> The best
>
>   Marcin
>
> ___
> Cinelerra mailing list
> Cinelerra@skolelinux.no
> https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
>



patch-framesfields
Description: Binary data

Re: [CinCVS] HDV to DVD (interlaced and PAL)

[Dan Streetman]

Oops, since I use only NTSC (480 H) I mis-spoke on the PAL dimensions.
PAL is apparently actually 576!  So as far as I know you are right,
without a "1080 to 576" effect there is no way to convert 1080i to
576i (PAL) inside cinelerra.  Either another "1080 to" effect is
needed or the other solution I mentioned needs to be added.  The
second solution I mentioned should actually be a very easy change and
should be generic, i.e. will accomplish 1080 to anything interlaced
scaling.  I will see if I can code something up today...

As far as the "1080 to 540" effect, as I said I assumed this was for
PAL.  If it isn't, I have no idea what the use for this effect
is...the original "1080 to 480" was at least useful for people
converting to NTSC.

And I agree on scripting...it can be very useful!  Sometimes though,
it is much harder to debug with a lot of scripting.

On 1/31/07, Marcin Kostur <[EMAIL PROTECTED]> wrote:

Dear Dan,

Thanks for tips. I will try them. If they work i will make
somthing like bg-render template for HDV file.

[OT]
Your description is also a good example how nice skripting is.
If cin would be 100% scriptable, then you would just copy me you line
which i would pasted in my xterm. ;-) Recenly i got involved in stupid
disscussion in slashcam.de, were a guy said that because all those
"long commands" linux is unacceptable. In my opinion it is windows GUI
unacceptable for me because of "cliking only habit".


The best

  Marcin

___
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: [CinCVS] HDV to DVD (interlaced and PAL)

[Dan Streetman]

It can be done with 2 effects.  Note if you are converting to NTSC
(720x480) you cannot do this unless you add back in the "1080 to 480"
effect that was removed or "changed" to 1080x540 some time ago.  I
have no idea why it was removed/changed.

- load HDV file, do "resize track" and make sure it's 1440x1080
- add "1080 to 540" effect, select the right ?-fields-first mode (top or bottom)
 (you have to add back in the "1080 to 480" effect if converting to NTSC)
- add "translate" effect:
 "In X" and "In Y" : both 0
 "In W" and "In H" : 1440 x 1080
 "Out X" : 360  (i.e. this is ((1440 - 720) / 2) so if original is
1920 wide use 635)
 "Out Y" : 270  (i.e. this is ((1080 - 540) / 2) so if target is NTSC use 300)
 "Out W" : 720
 "Out H" : 1080  (the "1080 to 540" effect does height conversion)
- make sure the project is 720x540 (for PAL, 720x480 for NTSC)

that's it.

There is an alternate possibility using "frames->fields", "translate",
and "fields->frames" but the field/frame effects need to be changed
first to have an option to not double the lines, so that the translate
effect can work correctly on each field.

On 1/30/07, Marcin Kostur <[EMAIL PROTECTED]> wrote:

Hi,

I still do not have any good prescription how to optimally
  make nice interlaced DVD from HDV 1080i material.

Anybody had  "one liner"?

Marcin

___
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: [CinCVS] DV and HDV 1080i Import/Export tools

[Dan Streetman]

On 1/19/07, Nicolas Maufrais <[EMAIL PROTECTED]> wrote:

On Fri, Jan 19, 2007 at 04:14:59PM -0500, Dan Streetman wrote:
> On 1/19/07, Nicolas Maufrais <[EMAIL PROTECTED]> wrote:
> >On Fri, Jan 19, 2007 at 03:18:29PM -0500, Dan Streetman wrote:
> >> If you want to try the experimental HDV patch for dvgrab it's here:
> >> http://kdenlive.sourceforge.net/hdv.php
> >>
> >> you should thouroughly check any files you create with test-mpeg2, as
> >> it (last I checked) does not use any buffering at all so whenever i
> >> used it, it silently dropped frames.  Didn't realize it until well
> >> into the editing process when I found random dropouts in the
> >> video/audio.
> >
> >Hello,
> >
> >Did you try using a buffer, as recommended in that page?
> >I had some dropouts while grabbing DV under heavy CPU load. I then used
> >the buffer option, and I never got those dropouts again.
> >Perhaps does that work with HDV?
>
> Not sure what you mean...I don't think test-mpeg2 has any buffering
> options.  Are you talking about where I suggest using the --buffer
> option to the HDV-modified dvgrab program?

Yes, that's it. Using --buffer as an option for the HDV-modified dvgrab
program.


I think you misread my emails, I said anyone using TEST-MPEG2 should
be careful because it doesn't use buffering.  I know that DVGRAB uses
buffers, especially the HDV version, since I wrote the experimental
HDV patch for it.  In case it isn't clear, test-mpeg2 and dvgrab are
_completely_ different programs.

So I should repeat, anyone using test-mpeg2 should be careful to
review ALL the footage they capture or export with it, since its lack
of buffering will most likely drop frames.



Nicolas.

--
~~
~ BOYCOTT SUSE & NOVELL (C)(TM)(R) MICRO$OFT ~
~~
~I DO LIKE AND SUPPORT GPL VERSION 3 ~
~~

___
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: [CinCVS] DV and HDV 1080i Import/Export tools

[Dan Streetman]

On 1/19/07, Nicolas Maufrais <[EMAIL PROTECTED]> wrote:

On Fri, Jan 19, 2007 at 03:18:29PM -0500, Dan Streetman wrote:
> If you want to try the experimental HDV patch for dvgrab it's here:
> http://kdenlive.sourceforge.net/hdv.php
>
> you should thouroughly check any files you create with test-mpeg2, as
> it (last I checked) does not use any buffering at all so whenever i
> used it, it silently dropped frames.  Didn't realize it until well
> into the editing process when I found random dropouts in the
> video/audio.

Hello,

Did you try using a buffer, as recommended in that page?
I had some dropouts while grabbing DV under heavy CPU load. I then used
the buffer option, and I never got those dropouts again.
Perhaps does that work with HDV?


Not sure what you mean...I don't think test-mpeg2 has any buffering
options.  Are you talking about where I suggest using the --buffer
option to the HDV-modified dvgrab program?

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

Re: [CinCVS] DV and HDV 1080i Import/Export tools

[Dan Streetman]

If you want to try the experimental HDV patch for dvgrab it's here:
http://kdenlive.sourceforge.net/hdv.php

you should thouroughly check any files you create with test-mpeg2, as
it (last I checked) does not use any buffering at all so whenever i
used it, it silently dropped frames.  Didn't realize it until well
into the editing process when I found random dropouts in the
video/audio.

On 1/18/07, Terje J. Hanssen <[EMAIL PROTECTED]> wrote:


Hi Marcin,


Marcin wrote:

> I use test-mpeg2 for import, also Scott:
> http://crazedmuleproductions.blogspot.com
> managed to export mpeg2 to cam over DV with this utility.
>

Yes, saw test-mpeg2 was mentioned also at
http://www.braindead.nu/wordpress/index.php?page_id=32

For one of another reason the Examples/test-mpeg2 isn't included on my
openSUSE 10.2

 # rpm -ql  libiec61883
/usr/bin/plugctl
/usr/bin/plugreport
/usr/lib/libiec61883.so.0
/usr/lib/libiec61883.so.0.1.0
/usr/share/doc/packages/libiec61883
/usr/share/doc/packages/libiec61883/AUTHORS
/usr/share/doc/packages/libiec61883/COPYING
/usr/share/doc/packages/libiec61883/NEWS
/usr/share/doc/packages/libiec61883/README
/usr/share/man/man1/plugctl.1.gz
/usr/share/man/man1/plugreport.1.gz

Is test-mpeg available as a separate addon rpm package from somewhere,
i.e at

http://www.linux1394.org/

> Since you want to "backup" on tapes - forgive me stupid question: WHY
> tapes?
>
> [EMAIL PROTECTED] ext. usb-hdd =  0.3E/GB
> cheapest [EMAIL PROTECTED] = 0.15 E/GB (in $ should be the same number  ;-)
>
> So it is less than 2x more expensive to use HDD instead miniDV as backup.
>

Well, regarding Hi8 tapes, I just wanted to first convert to a new tape
master with DV.

Edited DV or HDV on backup tapes don't exclude everything practical kept
together on one large online harddisk or even on another removeable
harddisk in a datasafe.

In general, as for other computer data or information, I just cannot
trust on just harddisk only. I think it is too risky to have so much
data consentrated on just a unit or two that can crash tomorrow due to a
electro-mechanical failure. Then everything may be gone in worst case.

On "primitive mecanical" or manual tapes the data and risk also become
spread over several units. This doesn't need to be miniDV tapes, but
also larger capacity backup streemer tapes on computers. Next BluRay or
HD-DVD also become alternatives beside.

Terje




___
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: [CinCVS] Annoyance: changing media type changes file name

[Dan Streetman]

I'll throw my "me too" in and agree with everyone else, it's difficult
to use as-is and would be much better if there was a common history of
rendered filenames, with just the extension changing based on render
type.  It would be most useful I think if there was a box where the
extension was changable, but defaulted to something - would be best if
that box was directly to the right of the filename (so it would be
obvious).  It probably would be even better if the directory and
filename were seperate also.

I guess my preference would be something like

directory: [directory entry]
filename base: [filename base entry] ext: [.ext]

e.g.

directory:  [/home/ddstreet/myproject]
filename base:  [my-video   ] ext:  [.mov ]

with this setup, if users didn't like the seperate ext, they could
remove the ext completely and just fill it in themselves for each
filename (the ext should be remembered by the render type).

e.g.

directory:  [/home/ddstreet/myproject]
filename base:  [my-video.mov] ext:  []


Just my $0.02


On 12/24/06, Andraž Tori <[EMAIL PROTECTED]> wrote:

On Thu, 2006-12-21 at 22:48 +0100, Johannes Sixt wrote:
> In the Render dialogs the media type (.mov, .avi, RAW DV etc) can of course be
> changed. Cinelerra CV remembers a different file name for each media format.
>
> I find it most annoying that changing the media type also switches the file
> name, in particular, because when you work through the dialog top to bottom,
> the first thing to choose is the file name, then comes the media - but when
> you change it, it kills the file name that you have just selected.
>
> I'd like to kill the feature. Nate? You've added this 2 years ago.
>
> Has someone else been annoyed by this behavior?
> Has someone found this feature extremely useful?

It would be extremely useful if just the extension would change, but not
the full filename.

bye
andraž


___
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: [CinCVS] Bug 364

[Dan Streetman]

The x264 lib changed from using b_cbr to i_rc_method, and that file
has #defines that check the x264 level on your system and should pick
the right one, at least in the latest SVN code.  I would suggest to
try updating your svn code to the latest (or, look at the file from
the latest code and hand-edit your copy so it works :)

On 12/23/06, Miha Kitič <[EMAIL PROTECTED]> wrote:


> > I'll be very rateful for any quick advice.
>
> If you decide to build 2.0, it looks to me like r836 is the last svn
> version prior to the start of the merge.
>

While trying to compile r836 under Ubuntu I got the following error

../../hvirtual/quicktime/qth264.c:472: error: 'struct ' has
no member named 'b_cbr'

Looks like b_cbr is a member of a fuction/structure which determines
whether constant bitrate is to be used, but I got no further than this.

I found though one manual on the net which suggests me to compile x264
and not use the Ubuntu package. But this was for 64bit processors (I use
32 bit - manual says 32bit ubuntu should work with no problem).

Does anyone know/remembers how to solve this?

I could on the other hand also comment out the parts of the code in
question, but...  I'd rather not do that.

All the best!

Miha


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

Re: [CinCVS] use of internal quicktime code instead of external libquicktime

[Dan Streetman]

I ask because I couldn't get a quicktime rendered in 16:9, it rendered
only in 4:3.  I checked the code and cinelerra never calls
quicktime_set_aspect().  I added the call to cinelerra and then found
that the internal quicktime lib doesn't implement the call :)
The external libquicktime lib does have lqt_set_pixel_aspect() and it
appears they implement it for at least some codecs

Anyway I will take a look, maybe it could be set up like the "external
ffmpeg" configuration option...

On 11/29/06, Andraž Tori <[EMAIL PROTECTED]> wrote:

it is questionable if they provide the same level of functionality... if
you can do the research, you are welcomed ...

bye
andraz

On Wed, 2006-11-29 at 15:57 -0500, Dan Streetman wrote:
> I'm wondering, it seems that the internal quicktime code is quite a
> bit older than the external libquicktime project.  Is there a reason
> why cinelerra is maintaining an internal quicktime codebase (still)?
> I realize cinelerra originally created the codebase, but wouldn't it
> be better to change to using the external library now?
>
> My point is, I can create a patch to use the external quicktime,
> unless there is some reason not to.
>
> ___
> 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

[CinCVS] use of internal quicktime code instead of external libquicktime

[Dan Streetman]

I'm wondering, it seems that the internal quicktime code is quite a
bit older than the external libquicktime project.  Is there a reason
why cinelerra is maintaining an internal quicktime codebase (still)?
I realize cinelerra originally created the codebase, but wouldn't it
be better to change to using the external library now?

My point is, I can create a patch to use the external quicktime,
unless there is some reason not to.

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

[CinCVS] 1080 -> 480 removed/replaced?

[Dan Streetman]

Hi all,

I just upgraded to the 955 SVN version, and I've found that the
1080->480 plugin has been removed or replaced by 1080->540?  Why was
this done?  I want to convert my 1080i into 480i and I was using the
old plugin quite well...why was it removed?  Do I have to do it all
myself now with a chain of conversion plugins?

Sorry if I missed somethingit just seemed like a very useful
plugin was removed.

Thanks.

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

Re: [CinCVS] Mpeg2 encoding

[Dan Streetman]

To calculate video and audio bitrates when trying to fit material onto
DVD, I created this _very simple_ script.  Its input is the total
number of seconds of footage.  It prints out the video rates with
several common audio bitrates.  Note that you should go at least
slightly under the rate shown, as you still have to account for the
basic DVD structure.  Don't forget to include the menu footage seconds
too (if you have a menu)!  A more complicated script is possible if
you want to do different video bitrates for different parts of the
DVD, etc. but since it's all just basic math I usually just do that by
hand if I need to :-)

Also note that DVD MPEG2 video bitrate is technically max 9800 kbps
and the total (including audio/subpicture) bitrate is max 10080 kbps:
http://www.videohelp.com/dvd
but ffmpeg and mpeg2enc might enforce lower maxes...


#!/bin/bash

SEC=$1

TOTAL_SPACE=47

BYTES_PER_SEC=$[ $TOTAL_SPACE / $SEC ]

BPS=$[ $BYTES_PER_SEC * 8 ]

KBPS=$[ $BPS / 1024 ]

echo $KBPS kbps total

for n in 384 256 128 64 32 ; do
 echo $[ $KBPS - $n ] kbps video / $n kbps audio
done



On 8/7/06, Graham Evans <[EMAIL PROTECTED]> wrote:

jim scott wrote:

> I think the spec is around 1 for video + audio. If you're using
> AC3 audio at 128 kbps, you should be able to go 9800 kbps for video.
>
> On 8/7/06, *Dimitrios * <[EMAIL PROTECTED] >
> wrote:
>
> On Tue, 08 Aug 2006 00:17:46 +0800 Graham Evans <
> [EMAIL PROTECTED] > wrote:
>
> > 1 fixed bitrate
>
> wasn't the maximum bitrate at 8000 (official dvd spec)? i could be
> wrong...
>
...All of which explains why 50 minutes of footage ended up only just
fitting on a single layer dvd.  My dvd player did play the footage but I
obviously got lucky.  I will tone down those settings - thanks for the
info dimitrios and jim.

Vaughan I have never had success with the YUV4MPEG pipe commands despite
many months of wrestling with them and seeking assistance.  Yet my
system (Fc4_64 bit) seems to function well with all the other aspects
of cinelerra cv.  On the other hand MPEN2ENC works as described.
Obviously most users here have lots of success with the pipe commands
but I just thought I would let you know in case you suffer further
problems...

Graham

___
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: [CinCVS] Effects order.

[Dan Streetman]

I've had the same problem, but my opinion is all the transitions
should be also added as effects.  To me, it makes more sense to have
effects than transitions.  They do the same thing, but transitions do
not (to me) do what I expect - they pull data from past the end of the
previous edit, i.e. they pull data from a part of the edit which is no
longer shown!  Plus, they aren't usable with effects - they always do
their thing before the effect.  To me, using a (for example) flash
effect is much easier and more intuitive than a flash transtion.  I
also think copying the transitions into effects would be much easier
than trying to change the transition model...

On 8/3/06, Hermann Vosseler <[EMAIL PROTECTED]> wrote:

Marcin Kostur wrote:
> Suppose i have two video tracks which i would like to join with a transition. 
Additionally i need
> to corret colors (e.g. histogram) on those tracks,
...
> If i apply effect to each track, then the transition will use uncorrected 
part  in overlapping
> moment (is it a bug?).
...
> The way i did  it was "correct a track and render" but it introduced 
unecessary DV-reencoding.

Andraž Tori wrote:
> you probably want to say that two edits overlap. just render them first with 
all the corrections
> you want and then use the new media files.

Hello Andraž,
Hello Marcin,

quite often, I got struck by this behaviour. I consider it -- not quite
a bug, but rather a shortcomming of the design, i.e. the way transitions
are implemented and controlled in cinelerra.
Basicalliy, it forces me to render the parts withl plugins to a lossles format
before setting up the transitions. (Rendering to dv or mjpeg of course is
not an option because of the quality loss introduced by re-encoding).
This approach works, but really can't be called a "solution":

  - it is destructive, wheras all editing should be non-destructive
  - it forces me into using a huge amount of disk space (which can
get a nightmare in large projects)
  - it's against the natural workflow: normally, we first select the
takes and try to cut, and later on, if all cuts are OK and the
whole "flow" of the movie is working, we do the fine tuning.
With this problem we either can't use transitions while cutting
(if we need the effects, e.g. slow motion), or we can't use a
preliminary version of the effects later on to be enhanced.

So I think, we should open a enhancement ticket on this. What's
your oppinion?

Cheers,
Hermann







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

Re: [CinCVS] Video Switching in Cinelerra

[Dan Streetman]

That seems good for live switching, where you do need a queued/next
shot, but for non-linear editing there isn't really a "next" shot is
there?  Just stop at the exact frame and switch the video source...

On 7/25/06, Jordan Nash <[EMAIL PROTECTED]> wrote:

How about a macro, you go through it once, and it does the changes that
you would normally do be hand.

The interface would be reminiscent of a traditional video switcher.

This is a sample interface layout that I designed:
http://i7.tinypic.com/20z73me.png.

The right side looks rough, because I started with the traditional "A/B"
switch. I changed to a "queued" concept.

The idea is that the operator would choose the next source to switch to,
and would have the desired transition and transition length selected.
When the "Go" button is pushed, the transition is added.

The VCR "Rewind" and "Fast Forward"  buttons would go to the beginning
of the previous transition and forward to the next transition,
respectively.

The macro would simply make it easier to put in and tweak the transition
effects  and transparency keyframes.

- Jordan
On Tue, 2006-07-25 at 02:15 -0400, Dan Streetman wrote:
> I do the same thing (edit multi-angle live events) and I have thought
> for some time about doing exactly that, a video effect to facilitate
> easy editing...
>
> What I do now is change the project size to twice the camera size
> (i.e. to 1400x960) and use each track's projector automation to fake a
> live switching setup, i.e. each video track in its part of the 2x2
> layout.  Then I can see all all camera angles (up to 4), and as I
> playback I decide which angle to use.  Unfortunately to actually pick
> an angle I have to use the track's mute keyframes to show it or let
> the track underneath show.  It's certainly a pain but it's the best
> Cinelerra can offer at the moment for synchronized multi-angle video
> editing, as far as I know.
>
> What I planned for the video effect was a set of radio buttons "edit"
> and "render" where "edit" lets you set up each track in a 2x2 (or more
> maybe) pattern (i.e. one track in top left, another top right, etc),
> with a set of "current" radio buttons for the tracks.  Then, using
> keyframes, you could easily pick which track should be displayed, and
> still view all the tracks.  When the "render" button is selected, the
> "current" track is displayed full screen (and the keyframes change the
> "current" track as the video progresses).
>
> I should try to find some time to do that...it would save me time in
> the long run for sure...
>
> On 7/23/06, Jordan Nash <[EMAIL PROTECTED]> wrote:
> > What is the current best way to do live event footage in Cinelerra?
> >
> > <--- Stop reading here --->
> >
> > Here is the theoretical situation.
> >
> > A low-budget production of a live event is to take place. Perhaps it is
> > a church service, and a couple of members have contributed MiniDV
> > cameras and tripods.
> >
> >
> >
> > The footage consists of:
> > - Audio track
> > - Camera 1
> > - Camera 2
> > - Camera 3
> > - Images from slide presentations (JPG or PNG)
> >
> > Camera 1: Fixed crowd shot, rear of the building. Sound mix is fed
> > directly into it.
> > Camera 2: Mostly wide shots.
> > Camera 3: Mostly telephoto shots of individual people, such as
> > vocalists, drummers, et cetera.
> >
> > The camera are using MiniDV tape, which only hold about an hour of
> > video. This means they must be changed while the event is unfolding.
> > This means sync problems.
> >
> > Also, this is an amateur operation, so the producer must make do with
> > the footage that he is given.
> >
> > The end results will be distributed on DVD and via the Internet, using a
> > variety of formats.
> >
> > The procedure would look something like this:
> > 1) Import the audio into a WAV file (the audio may be recorded directly
> > onto Camera 1 from the mixing board)
> > 2) Import all video footage from all tapes (long and annoying process).
> > This is where digital will really shine in a couple of years when it is
> > cheap and affordable enough to compete with MiniDV.
> > 3) Import the video and audio into a the video editing program. In this
> > case, the program is Cinelerra. Each camera has its own track.
> > 4) Ensure that all video and audio tracks are synced.
> > 5) Cross-fade between tracks. This requires the user to be experienced
> > with Cinelerra's keyframe function, which is currently a bit challenging

Re: [CinCVS] Video Switching in Cinelerra

[Dan Streetman]

I do the same thing (edit multi-angle live events) and I have thought
for some time about doing exactly that, a video effect to facilitate
easy editing...

What I do now is change the project size to twice the camera size
(i.e. to 1400x960) and use each track's projector automation to fake a
live switching setup, i.e. each video track in its part of the 2x2
layout.  Then I can see all all camera angles (up to 4), and as I
playback I decide which angle to use.  Unfortunately to actually pick
an angle I have to use the track's mute keyframes to show it or let
the track underneath show.  It's certainly a pain but it's the best
Cinelerra can offer at the moment for synchronized multi-angle video
editing, as far as I know.

What I planned for the video effect was a set of radio buttons "edit"
and "render" where "edit" lets you set up each track in a 2x2 (or more
maybe) pattern (i.e. one track in top left, another top right, etc),
with a set of "current" radio buttons for the tracks.  Then, using
keyframes, you could easily pick which track should be displayed, and
still view all the tracks.  When the "render" button is selected, the
"current" track is displayed full screen (and the keyframes change the
"current" track as the video progresses).

I should try to find some time to do that...it would save me time in
the long run for sure...

On 7/23/06, Jordan Nash <[EMAIL PROTECTED]> wrote:

What is the current best way to do live event footage in Cinelerra?

<--- Stop reading here --->

Here is the theoretical situation.

A low-budget production of a live event is to take place. Perhaps it is
a church service, and a couple of members have contributed MiniDV
cameras and tripods.



The footage consists of:
- Audio track
- Camera 1
- Camera 2
- Camera 3
- Images from slide presentations (JPG or PNG)

Camera 1: Fixed crowd shot, rear of the building. Sound mix is fed
directly into it.
Camera 2: Mostly wide shots.
Camera 3: Mostly telephoto shots of individual people, such as
vocalists, drummers, et cetera.

The camera are using MiniDV tape, which only hold about an hour of
video. This means they must be changed while the event is unfolding.
This means sync problems.

Also, this is an amateur operation, so the producer must make do with
the footage that he is given.

The end results will be distributed on DVD and via the Internet, using a
variety of formats.

The procedure would look something like this:
1) Import the audio into a WAV file (the audio may be recorded directly
onto Camera 1 from the mixing board)
2) Import all video footage from all tapes (long and annoying process).
This is where digital will really shine in a couple of years when it is
cheap and affordable enough to compete with MiniDV.
3) Import the video and audio into a the video editing program. In this
case, the program is Cinelerra. Each camera has its own track.
4) Ensure that all video and audio tracks are synced.
5) Cross-fade between tracks. This requires the user to be experienced
with Cinelerra's keyframe function, which is currently a bit challenging
to use effectively.
6) Once satisfied with the switching, render the results as a single
video file.
7) Replace the project with the results from step 6.
8) Add additional layers, such as a watermark logo.
9) Final render at top resolution.
10) Use a DVD creation program to distribute step 9 results as DVD.
11) Change Step 9 render into resolutions more suitable for Internet
distribution.
12) Distribute results.

This would be made easier through live switching. Of course, with live
switching, decisions are final. The advantage of post-production editing
is the ability to make educated decisions, since you know what is about
to happen. Also, live switching equipment is expensive. Non-linear video
editing software like Cinelerra is free.

> Resume reading here <

Cinelerra, in its current form, is a bit challenging to work with for
switching.

I think a nice compromise would be a video effect or macro for Cinelerra
that would act a bit like a hardware video switcher. The results would
be treated as a video track. If, later on, the user notices that a
switch was made too early or late, he/she can go into the track's
properties and fix the timing.

Is such a macro or video effect possible?

- Jordan


___
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: [CinCVS] Rendering to pipe vs. rendering direct to dvdauthor MPEG

[Dan Streetman]

Clearly there are two very different directions and I don't think they
necessarily negate each other (although using pipes would probably stray
from what's specified by the bounty).

1. Allowing rendering to video and audio pipes (or a combined video/audio
pipe), and user-specified backgrounded command lines to process the
pipe(s) (e.g. the current yuv4mpegpipe-to-pipe rendering), is _very_
flexible, but also quite user un-friendly.

2. Completely integrated DVD rendering will be much more user-friendly, 
but will be much less flexible.


My opinion is Cinelerra would be a better tool with _both_ options.  For
advanced users, rendering to pipes can be very useful (not just for DVD
rendering); you can run video or audio through external filters that
aren't available in cinelerra (e.g.  yuvdenoise, yuvscaler, sox, etc.), 
while the integrated option would be best for all new users and would
be a quick and hassle-free way to create a DVD.



-- 
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!

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

Re: [CinCVS] New Bounty: Rendering directly to the MPEG PS container. 200 EUR

[Dan Streetman]

On Tue, 30 May 2006, Nathan Kurz wrote:

>The only problem with YUV4MPEG is that it is video only.  The easiest
>way to do this export is with a container that supports both audio and
>video.  DV is a convenient example of a format that meets this need.
>The worry about the encode/decode is valid, but if the original input
>is DV, it will be used directly without that step.

Hmm, I'd say the easiest way is with named pipes, e.g.
mkfifo /tmp/video-pre-encode
mkfifo /tmp/video-post-encode
mkfifo /tmp/audio-pre-encode
mkfifo /tmp/audio-post-encode
ffmpeg -i /tmp/video-pre-encode  -o /tmp/video-post-encode &
ffmpeg -i /tmp/audio-pre-encode  -o /tmp/audio-post-encode &
mplex /tmp/video-post-encode /tmp/audio-post-encode -o 

but with changable names and changable standard DVD options.

The generic form of this is simply to have a "named pipes" render target
(i.e. video pipe and audio pipe) and allow any command line(s) to be
background-run to process the pipes.

>The other way to approach this problem is to use YUV4MPEG (or similar
>uncompressed format), and seperately export audio the same pipe that
>it is using.  This would be a fine solution too (perhaps even a better
>one) although I think a little harder to implement.  I certainly
>wouldn't want to discourage anyone from doing it, though.

I don't think the yuv4mpegpipe format allows for audio, so I don't know 
how that would be possible...



-- 
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!

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

Re: [CinCVS] New Bounty: Rendering directly to the MPEG PS container. 200 EUR

[Dan Streetman]

On Tue, 30 May 2006, Nathan Kurz wrote:

>On Tue, May 30, 2006 at 03:36:13PM +0200, Herman Robak wrote:
>> I offer 200 Euro to the one who adds MPEG Program Stream as one
>> of Cinelerra's output formats, with a DVD compability setting.
>> 
>> Cinelerra already supports rendering raw MPEG video and audio streams,
>> but not simultaneously, and no multiplexing.  This means Cinelerra
>> can not render DVD-ready MPEG2 files directly.
>
>That's a great bounty, Herman!  
>
>In case anyone is thinking about this, one way to accomplish this
>would be changing the DV output so it can be written to a pipe.
>Currently, it uses fseek's that can only be done on files.  Once it
>can be piped out, one can use the ffmpeg toolchain to convert to from
>piped DV to the finished DVD-ready output on the fly. 

I agree it's a great bounty (and motivation to do it, as I have been
thinking about doing it for a while - all my cinelerra use is to make
DVDs).  I agree that using pipes with mplex is the way to go, but doesn't
it make more sense to use yuv4mpeg excoding (or other uncompressed format
that ffmpeg recognizes) out of cinelerra (i.e. into ffmpeg) instead of DV?  
Encoding to DV would just waste CPU cycles, as that would then have to be
re-encoded into MPEG-2...



-- 
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!

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

Re: [CinCVS] exporting a 720x320 project to quicktime/dv/twos

[Dan Streetman]

I'd just use masks to crop the top and bottom out, have you tried using 
masks (the "Edit Mask" button on the left side of the compositor window)?

On Mon, 29 May 2006, Alec Robertson wrote:

>Hi Andraz,
>
>> > 720x320 frame. When I render this to a quicktime/dv/twos file the
>> > video fills the top 320 lines and the bottom 160 are green.
>> 
>> DV does not support any other resolution but 720x576 and 720x480 which
>> are PAL and NTSC. This is not a problem of cinelerra - except that a
>> check to prevent you doing that is missing. Use some other codec.
>
>Understood. The Raw DV output will not let me render a 720x320 frame
>however Quicktime with DV video does and it opens fine in kino 
>(for eventual transfer back to my camcorder). Hence the need for
>DV. I get the same effect when I set the video driver to dv1394. 
>
>I could render to yuv4mpeg, pad the top and the bottom with y4mscaler 
>and then encode to dv with ffmpeg, but I was hoping to do it all 
>directly from cinelerra. 
>
>/Alec
>
>___
>Cinelerra mailing list
>Cinelerra@skolelinux.no
>https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
>

-- 
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!

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

Re: [CinCVS] quicktime movies "portrait" orientation

[Dan Streetman]

This page has a lot of technical info about DVD and related standards, 
like supported resolutions and bitrates.

http://www.videohelp.com/dvd


On Sat, 29 Apr 2006, jim scott wrote:

>720x576 means 720 pixels across and 576 pixels vertically. I think that's
>the PAL DVD standard. I'm NTSC, which is 720x480.
>
>On 4/29/06, Heather Buch <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> My cinelerra projects have a frame size of 720x576, with an aspect ratio
>> of 4:3. Does this mean 720 length x 576 width? The finished quicktime films
>> (and the compositor previews) appear tall and narrow, a "portrait"
>> orientation. I would like them to have a "landscape" orientation (wider and
>> shorter) instead. So far, I  have found no way of doing this in the "format"
>> panel. I looked around the "secrets" document (and read much of it) but
>> could not find an answer.
>>
>> Maybe it's relevant to mention that I am working with DVD's burned from an
>> analog video camera, so I'm using TOC files.
>>
>> Thanks in advance!
>>
>> Heather Buch
>>
>> --
>> Yahoo! Mail goes everywhere you do. Get it on your 
>> phone<http://us.rd.yahoo.com/evt=31132/*http://mobile.yahoo.com/services?promote=mail>.
>>
>>
>>
>
>
>--
>http://ThreeWayNews.blogspot.com
>Your source. For everything. Really.
>

-- 
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!

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

Re: [CinCVS] Jerky picture in compositor window

[Dan Streetman]

This may not be what you're seeing, but I found that if cinelerra had to
resample one or more of my audio tracks on-the-fly (because their sampling
rates didn't match each other or match the project audio sampling rate),
it took too much CPU time and caused "jerky" playback.  Does your video
play smooth if you turn off audio playback?


On Sat, 15 Apr 2006, Nicolas wrote:

>Hello,
>
>In order to edit a footage I shot on today, I have to cut some parts of that 
>video. I preview the video in the compositor window.
>
>I've noticed the video plays smoothly for approximately 1 second and
>then it's jerky for a few frames. That's almost as if there was a drop
>on my video. The interval happens regularly. There's no problem at all
>on my material (I checked on the DV files).
>
>The material is PAL progressive (not interlaced ) 720x576 DV, bottom
>field first and 25fps. That's what is set in the format window. The
>framerate achieved is 19.43 fps.
>
>Do you know what causes that problem? Is it a bug? I understand my
>computer can't play the video at the "normal" fps (25), but is there no
>way to preview the video without those annoying drops?
>
>Thanks.
>Nicolas.
>
>_______
>Cinelerra mailing list
>Cinelerra@skolelinux.no
>https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
>

-- 
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!

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

[CinCVS] missed "no keyframes" case in reframert...

[Dan Streetman]

oops, I missed the "no keyframes" case...where the keyframe->position is 
always 0, instead of the effect start.  So many special cases when 
dealing with keyframes...my mistake!

Attached is a small patch to make reframert work again with no keyframes 
(i.e. default keyframe with position == 0)

-- 
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!Index: plugins/reframert/reframert.C
===
--- plugins/reframert/reframert.C   (revision 777)
+++ plugins/reframert/reframert.C   (working copy)
@@ -311,16 +311,13 @@
double input_rate = frame_rate;
int is_current_keyframe;
 
-   // the first keyframe can be unique -
-   // it doesn't have to be at the effect start and it controls settings 
before it
-   // so, if needed, let's calculate using a fake keyframe with the same 
settings but position == effect start
+   // if there are no keyframes, the default keyframe is used, and its 
position is always 0;
+   // if there are keyframes, the first keyframe can be after the effect 
start (and it controls settings before it)
+   // so let's calculate using a fake keyframe with the same settings but 
position == effect start
KeyFrame *fake_keyframe = new KeyFrame();
-   if (get_source_start() < edl_to_local(next_keyframe->position))
-   {
-   fake_keyframe->copy_from(next_keyframe);
-   fake_keyframe->position = local_to_edl(get_source_start());
-   next_keyframe = fake_keyframe;
-   }
+   fake_keyframe->copy_from(next_keyframe);
+   fake_keyframe->position = local_to_edl(get_source_start());
+   next_keyframe = fake_keyframe;
 
// calculate input_frame accounting for all previous keyframes
do
@@ -333,7 +330,10 @@
 
read_data(tmp_keyframe);
 
-   is_current_keyframe = next_position > start_position || 
next_keyframe->position == tmp_keyframe->position;
+   is_current_keyframe =
+   next_position > start_position // the next keyframe is 
after the current position
+   || next_keyframe->position == tmp_keyframe->position // 
there are no more keyframes
+   || !next_keyframe->position; // there are no keyframes 
at all
 
if (is_current_keyframe)
next_position = start_position;

Re: [CinCVS] award and interlacing with linux = H.E.L.P.

[Dan Streetman]

Your problem very well could be ffmpeg, until the very latest version
(maybe the CVS version) it completely ignored the interlacing setting and
whatever it produced was marked as progressive.  Maybe try re-rendering
with the very latest ffmpeg from CVS.  Or, render with mpeg2enc instead,
which does correctly set the interlacing flag.  There was an email on this
mailing list a while ago linking to the ffmpeg interlacing bug that was
recently fixed.

Cinelerra also had (or maybe still has) a bug where batch rendering to
YUV4MPEG incorrectly set the interlacing flag to progressive, you can
correct that by adding "yuvcorrect -v 0 -T INTERLACED_BOTTOM_FIRST" (or
top first) to the pipe.

Also you should make sure the framerate is correct (I think 25 for PAL?) -
you can check your final rendered file with "mplayer -identify".


On Wed, 12 Apr 2006, Marcin Kostur wrote:

>Hi Everyone,
>
>My short movie "a dream" was awarded during Free -Flight in
>  Garmisch (Germany) in cathegory "best short movie 2006". ;-)
>
>In the award ceremony i was considering to say a word that it has been
>done with free software. I did not... and it was really lucky...
>
>I made - in the night before deadline, and DVD-video with dvdauthor. Of 
>course dvdauthor
>is not a much usable software - and i just copied a xml from the net - 
>no menus -
>one track etc. It played ok on my DVD-player. But it turned out that in 
>"big" screen my movie
>is shown with "wrong field order" - UGLY!. Again this shit. I suspect 
>that there must be some
>flag in DVD which was not set by default and some "profi" player 
>considered it to be e.g. NTSC...
>Of course my fault... but what a shame
>
>But there is something more. I am not able to produce PAL intelaced 
>video under linux
>which is clean-interlaced. It is not that bad as "wrong time order" but 
>it is "a bit jerky".
>I have no idea how to debug it and where does it come from. There where 
>some hints that libdv is
>buggy  - (and crappy) - but also is i export from cinelerra directly to 
>ffmpeg pipe - DVD
>is on TV the same jerky.
>I stress - it is not "time order" - because i saw wrong time order on TV 
>and it is much much
>worse.
>
>PLEASE HELP - how can I make clean PAL interlaced DVD with Linux 
>How can i even debug the problem? =See the difference on PC
>I can see on TV a difference if i record back do DV original .mov/DV file,
>and recommpressed .mon/DV file. (=it is not pure DVD problem).
>
>The best
>
>Marcin
>
>BTW:
>Movie is on: http://marcin.glidingcontest.org
>
>
>
>
>
>___
>Cinelerra mailing list
>Cinelerra@skolelinux.no
>https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
>

-- 
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!

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

Re: [CinCVS] Re: Cinelerra generating files that ffmpeg can't read

[Dan Streetman]

Ah, sorry, I was referring to the "YUV4MPEG Stream" render format
(technically the YUV4MPEG2 format, but it's referred to without the "2"  
usually).  The format is YUV 4:2:0.  This format is used/provided by the
"mjpegtools" package, which contains lots of stuff to manipulate the
stream: yuvdenoise, yuvcorrect, yuvdeinterlace, yuvscaler, etc., which you
can pipe the stream through.

The "YUV4MPEG Stream" video render options has a check box to use a pipe,
and then you manually enter the command line to receive the pipe.  There
are some defaults in drop-down boxes, or you can enter your own.  For
example to correct the interlacing setting (when using batch rendering)
and filter with yuvdenoise and render to DV I use:

yuvcorrect -v 0 -T INTERLACED_BOTTOM_FIRST | yuvdenoise -g 1,2,2 -s 2,4,4 -t 
4,8,8 | ffmpeg -f yuv4mpegpipe -i - -y -target dv -f dv -vcodec dvvideo %

of course you can pipe directly into ffmpeg if you don't want the other 
filtering.  Note you don't need a leading pipe (|).  As you probably 
know, ffmpeg can transform into almost any format and codec.


On Tue, 11 Apr 2006, Geoff Kuenning wrote:

>Dan Streetman writes:
>
>> ffmpeg can read yuv4mpeg, so if you really want a lossless file to feed to
>
>Not to sound ignorant, but would that be the "YUV 4:2:0 Planar" option
>in the video compression menu?
>
>> ffmpeg, there you go...although you can instead pipe directly into ffmpeg,
>
>That would be very nice.  Not to be ignorant again, but how do I get
>rendering to write to a pipe?  I tried prefixing the filename with |
>and !, and searched Secrets of Cinelerra, but couldn't find a winning
>formula.
>

-- 
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!

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

[CinCVS] Re: Cinelerra generating files that ffmpeg can't read

[Dan Streetman]

my measurments (with 720x480 29.96 fps footage) put YUV (via yuv4mpeg) at
about 120Mb/sec (=15MB/sec).  DV is always 25Mb/sec (=3.125MB/sec).

ffmpeg can read yuv4mpeg, so if you really want a lossless file to feed to
ffmpeg, there you go...although you can instead pipe directly into ffmpeg,
instead of saving the intermediate file to disc, which saves a lot of disc
space!  In my experience, the compression (i.e. ffmpeg) takes way longer 
than just cinelerra's rendering of the YUV frames.



-- 
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!

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

Re: [CinCVS] null plugin keyframes (how to unexplode your xml files!)

[Dan Streetman]

Yep, I had (have...) the same problem.  I don't think it's tweaking while 
playing back tho, as it's happened many times to me and I always stop 
playback before tweaking.  I don't really know what's causing it.  
It's certainly annoying as hell.  

What I did to fix the "broken" xml file was create a sed script-file 
containing:
s,,,g

and run the xml file through it:
cat file.xml | tr -d '\n' | sed -f sedscriptfile > fixed.xml

although using perl should work fine too.


On Tue, 7 Mar 2006, Brendan Conoboy wrote:

>Hi everyone,
>
>As a novice cinelerra user, I've run into a heinous problem every now 
>and again.  After doing some work on a video, I'll save, do some more, 
>save for a day or two.  Normally when I start up again, the xml file 
>is a few dozen to a few hundred k.  Every now and again, it's 5 
>megabytes large, fails to load, and makes me weep in an unmanly way 
>(tm).  The physical characteristic of the problem appears to be null 
>keyframes being inserted into the xml file, like this:
>
>
>
>
>
>
>Thousands of them.  Tens of thousands.  Hundreds of thousands of them.
>
>As to where they come from, it appears to be the result of tweaking 
>plugin parameters *while* cinelerra is doing playback.  I've not 
>investigated this problem, but I do have a bandaid of a solution, 
>written in perl:
>
>#!/usr/bin/perl
>while($_=)
>   {
>   if ( $_ =~ /PLUGIN LENGTH="0"/ )
> {
> $skipped=0;
> while($skipped==0)
>   {
>   $_=;
>   if ( $_ =~ /\/PLUGIN/ )  { $skipped=1; }
> }
>   }
>   print $_;
>}
>
>To use it, just save it as 'unexplode', make it executable and use 
>"unexplode < bloated.xml > lean.xml" to strip out all plugins of length 
>0.  Hopefully there aren't any desirable plugins of length 0!
>
>-Brendan
>
>___
>Cinelerra mailing list
>Cinelerra@skolelinux.no
>https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
>

-- 
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!

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

Re: [CinCVS] defect #30 (transitions are start-of-edit only)

[Dan Streetman]

On Thu, 2 Mar 2006, Johannes Sixt wrote:

>On Mittwoch 01 März 2006 23:36, Dan Streetman wrote:
>> On Wed, 1 Mar 2006, Johannes Sixt wrote:
>> >On Mittwoch 01 März 2006 22:44, Dan Streetman wrote:
>> >> Say I have 2 video tracks, one main track and one overlay track.  The
>> >> main track has all my video data and the overlay track has short bits. 
>> >> I want to transition into each of the short bits.  No problem
>> >> transitioning into them, but I can't transition out of them since
>> >> transitions can't be attached to the end of an edit.
>> >
>> >A transition doesn't help here. Fade in and out the main track to achieve
>> > the effect.
>>
>> I don't want to fade, I want to flash.  Why do you think a transition
>> won't work?  I certainly works at the start of the edit (which has nothing
>> before it in its video track).
>
>I've briefly tested this. I put the short bits on the topmost track, with some 
>effect below one of them. The main track is the second track. Now, you have 
>to put the transitions on the edits of the short bits. The effect must extend 
>past the end of the short bit so that it lasts until the transition is over. 
>In order to put a transition on the end of the last short bit, you have to 
>put some footage to the right of it. If you mute it (turn on Mute in the View 
>menu), it won't appear.

Hmm, maybe I'm misunderstanding you but it doesn't seem to work for me, 
the mute cuts out the flash, edit, everything.  Also extending the 
ReframeRT effect overlays the flash effect from the next (fake) edit.

What I wound up doing is creating a fake transparent png of the length of 
my transition, added the transition (flash) to it, and rendered it as a 
PNG Sequence (then re-loaded that and saved it as a XML).  I then added a 
whole new video track just for the transitions, and I can now place them 
whereever I want.  Kinda kludgey but it works...

It seems to me that it would be a lot easier if the transitions weren't 
associated with each edit, if they were effects it would make them much 
more flexible (and, IMHO more intuitive; it's not obvious at all that 
transitions will pull data from the previous edit _past_ the end of the 
edit!).


-- 
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!

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

Re: [CinCVS] defect #30 (transitions are start-of-edit only)

[Dan Streetman]

On Wed, 1 Mar 2006, Johannes Sixt wrote:

>On Mittwoch 01 März 2006 22:44, Dan Streetman wrote:
>> Say I have 2 video tracks, one main track and one overlay track.  The main
>> track has all my video data and the overlay track has short bits.  I want
>> to transition into each of the short bits.  No problem transitioning into
>> them, but I can't transition out of them since transitions can't be
>> attached to the end of an edit.
>
>A transition doesn't help here. Fade in and out the main track to achieve the 
>effect.

I don't want to fade, I want to flash.  Why do you think a transition 
won't work?  I certainly works at the start of the edit (which has nothing 
before it in its video track).

>> >You can always append a still PNG to the track to make the transition
>> > work.
>>
>> A PNG is one frame.  A transition that lasts 1 frame isn't that useful to
>> me...anyway, a "fake" secondary edit won't work because the transition
>> depends on the last edit's data still being available past the end of the
>> edit.
>
>You can extend a PNG to any number of frames you need. I haven't done this 
>yet, but I think a PNG that is entirely transparent will suit your purposes.

The ReframeRT effect I'm using overrides the flash in the next track.  I
would have to render to disc all of the video shorts and re-load them
instead of just using ReframeRT.  Although, that might be easier than
fixing the transition problem.  Or maybe I could try to fix the ReframeRT 
overriding the next (fake) edit's transition.

-- 
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!

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

Re: [CinCVS] defect #30 (transitions are start-of-edit only)

[Dan Streetman]

On Wed, 1 Mar 2006, Brendan Conoboy wrote:

>Dan Streetman wrote:
>> Say I have 2 video tracks, one main track and one overlay track.  The main 
>> track has all my video data and the overlay track has short bits.  I want 
>> to transition into each of the short bits.  No problem transitioning into 
>> them, but I can't transition out of them since transitions can't be 
>> attached to the end of an edit.
>> 
>> That make sense?
>
>Why not simply fade in and out the main track so that the overlay track 
>shows through?  Am I misunderstanding what you're doing?

For fades that's great, but I want to use a flash transition (or, any of 
the other transitions...)

>
>I just finished up working on a performance done with two cameras- After 
>lining up the frames, the first video stream could be faded out so the 
>second stream was displayed.  This worked great and seems like what 
>you're describing.  I've always thought of the transition as being for 
>splicing video in the same track.
>
>-Brendan
>
>___
>Cinelerra mailing list
>Cinelerra@skolelinux.no
>https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
>

-- 
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!

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

Re: [CinCVS] defect #30 (transitions are start-of-edit only)

[Dan Streetman]

On Wed, 1 Mar 2006, Johannes Sixt wrote:

>On Mittwoch 01 März 2006 20:50, Dan Streetman wrote:
>> Unfortunately I need to do what this defect describes, I want to put a
>> transition at the end of an edit.  It is quite a bit of work, any way you
>> look at it.  I think the easiest approach may be to allow placing
>> transitions either at the beginning or end of an edit (i.e. leave the
>> beginning transition, and add a ending transition).  This should be an
>> easier change than placing transitions anywhere.  Does this sound
>> appropriate?  Is anyone already working on this?
>>
>> Thanks.
>
>As the name says, it's a *transition*, hence it needs something to transit to. 
>So, pray tell us, what does your ending transition transit to? (And which 
>transition that you need?)

I'll "pray tell you" that it's a transition to a different video track 
(i.e. transition to no video in that track).

Say I have 2 video tracks, one main track and one overlay track.  The main 
track has all my video data and the overlay track has short bits.  I want 
to transition into each of the short bits.  No problem transitioning into 
them, but I can't transition out of them since transitions can't be 
attached to the end of an edit.

That make sense?

>
>You can always append a still PNG to the track to make the transition work.

A PNG is one frame.  A transition that lasts 1 frame isn't that useful to
me...anyway, a "fake" secondary edit won't work because the transition
depends on the last edit's data still being available past the end of the
edit.  In my case it isn't since I use a reframe effect that isn't
extended into the next track (if I do extend it into the next track, it
overlays the effect).  I really don't want to have to render all these 
short video edits to disk just because I can't put a transition at the end 
of an edit...


-- 
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!

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

[CinCVS] defect #30 (transitions are start-of-edit only)

[Dan Streetman]

Unfortunately I need to do what this defect describes, I want to put a 
transition at the end of an edit.  It is quite a bit of work, any way you 
look at it.  I think the easiest approach may be to allow placing 
transitions either at the beginning or end of an edit (i.e. leave the 
beginning transition, and add a ending transition).  This should be an 
easier change than placing transitions anywhere.  Does this sound 
appropriate?  Is anyone already working on this?

Thanks.

-- 
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!

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

Re: [CinCVS] how to do slo-motion with interlaced video?

[Dan Streetman]

Doesn't work very well except at 0.5 speed, in which case there is no 
interlacing.  slower or faster gives some highly interlaced frames and 
some not interlaced frames...

Have you used that yourself to create interlaced slow motion shots?


On Mon, 27 Feb 2006, Andraz Tori wrote:

>First use frames to fields, than reframe effect, than fields to frames.
>
>bye
>andraž
>
>On ned, 2006-02-26 at 22:24 -0500, Dan Streetman wrote:
>> I'm trying to figure out how to do slo-motion with an interlaced video 
>> source, but I can't seem to figure it out...
>> 
>> I have a interlaced video source I'm working with, and at certain points I 
>> want to slo-mo the video.  Since it's all going to be rendered as an 
>> interlaced video, the slo-mo needs to be interlaced also, but I can't use 
>> the interlacing from the fullspeed video, as the interlacing wouldn't be 
>> right at a slower speed.
>> 
>> So is there any way to do this?  Surely there must be some (hopefully 
>> easy) way...
>> 
>> 
>
>
>_______
>Cinelerra mailing list
>Cinelerra@skolelinux.no
>https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
>

-- 
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!

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

[CinCVS] how to do slo-motion with interlaced video?

[Dan Streetman]

I'm trying to figure out how to do slo-motion with an interlaced video 
source, but I can't seem to figure it out...

I have a interlaced video source I'm working with, and at certain points I 
want to slo-mo the video.  Since it's all going to be rendered as an 
interlaced video, the slo-mo needs to be interlaced also, but I can't use 
the interlacing from the fullspeed video, as the interlacing wouldn't be 
right at a slower speed.

So is there any way to do this?  Surely there must be some (hopefully 
easy) way...


-- 
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!

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

Re: [CinCVS] patch to add titler timecode functionality (new patch to correct text_to_seconds)

[Dan Streetman]

Hmm, that adds complications for 2 reasons, fromtext() (and
text_to_seconds) isn't frame-accurate since it rounds to "samples" which
can't be frames since "samplerate" is an int, and h:m:s:f can't be
negative so a "reverse" checkbox is needed to make the timecode count
backwards.  The reverse checkbox is probably more intuitive anyway.

Ok, so here is a patch to correct text_to_seconds (and add 
text_to_frames).  The fromtext() function should remain just as accurate 
as before.  Does this look ok?  If so, I'll send an updated patch for the 
titler...

Thanks.



On Fri, 24 Feb 2006, Andraz Tori wrote:

>I believe that offset should be entered in h:m:s:f format... can you fix
>that?
>
>
>And inlined attachments are not good, they get screwed by email
>readers... Attachments are much better as you have correctly guessed.
>
>bye
>andra?
>
>On ?et, 2006-02-23 at 22:30 -0500, Dan Streetman wrote:
>> Hi,
>> 
>> I needed to improve the titler timecode to generate a working clock so I 
>> added 2 fields, an offset (in frames) and a format.  The offset allows you 
>> to set the timecode value to any time (frame) you want (although without a 
>> multiplier it's still fixed to playback time of course).  The format 
>> displays the timecode in various formats from units.C.
>> 
>> Is the preference on the list to attach patches?  I usually like inline 
>> patches, but I'll do whatever :)  I've attached the patch this time.
>
>
>_______
>Cinelerra mailing list
>Cinelerra@skolelinux.no
>https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
>

-- 
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!Index: guicast/units.h
===
--- guicast/units.h (revision 746)
+++ guicast/units.h (working copy)
@@ -138,6 +138,12 @@
int time_format, 
float frame_rate, 
float frames_per_foot);   
+// Convert text to frames
+   static int64_t text_to_frames(char *text, 
+   int samplerate, 
+   int time_format, 
+   float frame_rate, 
+   float frames_per_foot);   
 
static char* print_time_format(int time_format, char *string);
 
Index: guicast/units.C
===
--- guicast/units.C (revision 746)
+++ guicast/units.C (working copy)
@@ -276,7 +276,7 @@
return totext(text, (double)samples / samplerate, time_format, 
samplerate, frame_rate, frames_per_foot);
 }
 
-int64_t Units::fromtext(char *text, 
+double Units::text_to_seconds(char *text, 
int samplerate, 
int time_format, 
float frame_rate,
@@ -286,13 +286,11 @@
int64_t feet;
double seconds;
char string[BCTEXTLEN];
-   
+
switch(time_format)
{
case TIME_SECONDS:
-   seconds = atof(text);
-   return (int64_t)(seconds * samplerate);
-   break;
+   return atof(text);
 
case TIME_HMS:
case TIME_HMS2:
@@ -319,9 +317,7 @@
string[j] = 0;
seconds = atof(string);
 
-   total_samples = (uint64_t)(((double)seconds + minutes * 
60 + hours * 3600) * samplerate);
-   return total_samples;
-   break;
+   return (seconds + minutes*60 + hours*3600);
 
case TIME_HMSF:
 // get hours
@@ -355,21 +351,17 @@
string[j] = 0;
frames = atol(string);

-   total_samples = (int64_t)(((float)frames / frame_rate + 
seconds + minutes*60 + hours*3600) * samplerate);
-   return total_samples;
-   break;
+   return (frames / frame_rate) + (seconds + minutes*60 + 
hours*3600);
 
case TIME_SAMPLES:
-   return atol(text);
-   break;
+   return atol(text) / samplerate;

case TIME_SAMPLES_HEX:
sscanf(text, "%x", &total_samples);
-   return total_samples;
+   return total_samples / samplerate;

case TIME_FRAMES:
-   return (int64_t)(atof(text) / frame_rate * samplerate);
-   bre

[CinCVS] patch to add titler timecode functionality

[Dan Streetman]

Hi,

I needed to improve the titler timecode to generate a working clock so I 
added 2 fields, an offset (in frames) and a format.  The offset allows you 
to set the timecode value to any time (frame) you want (although without a 
multiplier it's still fixed to playback time of course).  The format 
displays the timecode in various formats from units.C.

Is the preference on the list to attach patches?  I usually like inline 
patches, but I'll do whatever :)  I've attached the patch this time.
Index: plugins/titler/titlewindow.h
===
--- plugins/titler/titlewindow.h(revision 746)
+++ plugins/titler/titlewindow.h(working copy)
@@ -43,6 +43,8 @@
 class TitleColorStrokeThread;
 class TitleSpeed;
 class TitleTimecode;
+class TitleTimecodeOffset;
+class TitleTimecodeFormat;
 
 class TitleWindow : public BC_Window
 {
@@ -109,11 +111,16 @@
BC_Title *speed_title;
TitleSpeed *speed;
TitleTimecode *timecode;
+   BC_Title *timecode_offset_title;
+   TitleTimecodeOffset *timecode_offset;
+   BC_Title *timecode_format_title;
+   TitleTimecodeFormat *timecode_format;
 
 // Color preview
ArrayList sizes;
ArrayList encodings;
ArrayList paths;
+   ArrayList tc_formats;
ArrayList fonts;
 };
 
@@ -216,6 +223,21 @@
TitleMain *client;
TitleWindow *window;
 };
+class TitleTimecodeOffset : public BC_TumbleTextBox
+{
+public:
+   TitleTimecodeOffset(TitleMain *client, TitleWindow *window, int x, int 
y);
+   int handle_event();
+   TitleMain *client;
+};
+class TitleTimecodeFormat : public BC_PopupTextBox
+{
+public:
+   TitleTimecodeFormat(TitleMain *client, TitleWindow *window, int x, int 
y);
+   int handle_event();
+   TitleMain *client;
+   TitleWindow *window;
+};
 class TitleFade : public BC_TextBox
 {
 public:
Index: plugins/titler/title.C
===
--- plugins/titler/title.C  (revision 746)
+++ plugins/titler/title.C  (working copy)
@@ -62,6 +62,8 @@
sprintf(encoding, DEFAULT_ENCODING);
pixels_per_second = 1.0;
timecode = 0;
+   timecode_offset = 0;
+   timecode_format = TIME_HMS;
stroke_width = 1.0;
 }
 
@@ -75,6 +77,8 @@
color_stroke == that.color_stroke &&
stroke_width == that.stroke_width &&
timecode == that.timecode && 
+   timecode_offset == that.timecode_offset && 
+   timecode_format == that.timecode_format && 
hjustification == that.hjustification &&
vjustification == that.vjustification &&
EQUIV(pixels_per_second, that.pixels_per_second) &&
@@ -102,6 +106,8 @@
y = that.y;
dropshadow = that.dropshadow;
timecode = that.timecode;
+   timecode_offset = that.timecode_offset;
+   timecode_format = that.timecode_format;
strcpy(text, that.text);
strcpy(encoding, that.encoding);
 }
@@ -137,6 +143,8 @@
this->x = prev.x;
this->y = prev.y;
timecode = prev.timecode;
+   timecode_offset = prev.timecode_offset;
+   timecode_format = prev.timecode_format;
 // this->dropshadow = (int)(prev.dropshadow * prev_scale + next.dropshadow 
* next_scale);
this->dropshadow = prev.dropshadow;
 }
@@ -1935,7 +1943,28 @@
 }
 
 
+char* TitleMain::timecode_format_to_text(int format)
+{
+   switch(format)
+   {
+   case TIME_SECONDS: return _("Seconds"); break;
+   case TIME_HMS: return _("HH:MM:SS:TTT"); break;
+   case TIME_HMS2: return _("H:MM:SS"); break;
+   case TIME_HMS3: return _("HH:MM:SS"); break;
+   case TIME_HMSF: return _("H:MM:SS:FF"); break;
+   case TIME_FRAMES: return _("Frames"); break;
+   }
+   return _("?");
+}
 
+int TitleMain::text_to_timecode_format(char *text)
+{
+   for(int i = 0; i < 9; i++)
+   {
+   if(!strcasecmp(timecode_format_to_text(i), text)) return i;
+   }
+   return 0;
+}
 
 
 
@@ -1955,9 +1984,10 @@
int64_t rendered_frame = get_source_position();
if (get_direction() == PLAY_REVERSE)
rendered_frame -= 1;
+   rendered_frame += config.timecode_offset;
Units::totext(config.text, 
(double)rendered_frame / 
PluginVClient::project_frame_rate, 
-   TIME_HMSF, 
+   config.timecode_format, 
0,
PluginVClient::project_frame_rate, 
0);
@@ -2119,6 +2149,8 @@
config.y = defaults->get("TITLE_Y", config.y);
config.dropshadow = defaults->get("DROPSHADOW", config.dropshadow);
config.timecode = defaults->get("TIMECOD