Hi
> > I no longer use an intermediate .mov file to do this - since Cinelerra 2.0
> > (and CVS somewhat earlier), Cinelerra has been able to output data to a pipe
> > in the format expected my mpeg2enc. So now I just pipe directly into
> > mpeg2enc (which gives better quality and ends up being faster in my
>
> Could you share your current workflow with us? Which commands you use
> and why is it beter than previous one?
It's nothing special really, and I must admit that for various reasons I'm
actually using Heroine's 2.0, not the CVS version. Anyway, for *video*
rendering I choose the MPEG output format and render only video - the one
which calls up the mpeg2enc plugin. However, since I prefer to have more
control over mpeg2enc than the cinelerra dialog gives me I have replaced the
plugin.mpeg2enc file with a simple shell script which sends the cinelerra
output (in yuv4mpeg2 format) into the system's mpeg2enc along with command
line options of my choosing. These options are as I described in my
previous post on this subject.
In the days before cinelerra could do pipes properly I rendered video only
to a Qt/DV (.mov) file and then encoded that with mpeg2enc as previously
described. The new workflow is superior for a number of reasons:
1) the material is not going through a lossy intermediate format. DV is
good but it's still lossy. Avoiding it results in a better overall
result - less artifacting, lower bitrate for the same quality.
2) (this is the big one) There is a bug in the libdv DV *encoder* which
results in suboptimal results for at least interlaced PAL material (and
perhaps other formats too). It is particularly noticeable when encoding
fast horizontal movement, where the relevant sections of the picture
will flicker quite badly when played back on an interlaced monitor.
Close inspection seemed to indicate that the encoder included a severe
shadow of the previous field when encoding a field.
The workflow as described above avoids the libdv bug mentioned in 2 and
results in a significantly better DVD. Not only is the flicker reduced,
but the bitrate is much improved for a given quality factor too.
This bug came to light about 12-18 months ago. Unfortunately there seems
to be little interest in the libdv camp of investigating the cause and
fixing it. I would have considered doing so, but since the pipe option
surfaced at about the same time I really had no further use of libdv's
encoder and moved on to other things.
I should also note at this point that at the time (12-18 months ago) the DV
encoder in ffmpeg was better than libdv's but it still suffered from the
same problem - just to a lesser extent. I haven't tested the ffmpeg encoder
lately simply because - as mentioned above - I don't have any need for it
now.
That's the video side of things. For audio I usually deal with outside of
Cinelerra. Ardour usually gets the gig most of the time since the mixdown
usually involves a multitrack source, and Ardour's multitract audio features
are more extensive than cinelerra's. Therefore I render the audio from
Cinelerra as a WAV file which I then import into Ardour to use as a guide
track. The mixdown happens, is rendered to WAV and finally encoded for DVD
using (up to now) toolame. I'm thinking of moving to AAC soon though, but
this will simply entail a change of encoder and isn't going to alter the
workflow all that much.
Regards
jonathan
_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
