Peter Santo <san### [at] poolinformatikrwth-aachende> wrote:
: On the other hand, I really like the fact that pov, despite all it's
: features, is not as bloated as many other render programs are. So if I
: am sort of the only one who'd like such a feature, I could try and
: program a modification of cmpeg that would do "incremental" writes. Such
: a program could then be called from the shellout command of pov's
: internal animation loop.

  Take into account that cmpeg doesn't take the frames in order. You would
have to create as many frames as cmpeg needs for the next frame before
you can call it.
  And you definitely can't make povray to create the frames in the order
cmpeg needs them (ie. by making the clock to jump back and forth) because
that will surely break some scenes (this happens when the result of the
previous frame is written to disk and then read in the next frame).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

>   Take into account that cmpeg doesn't take the frames in order. You would
> have to create as many frames as cmpeg needs for the next frame before
> you can call it.

Yep, I mentioned that in previous postings:
>>Every time an I-frame is generated, compress the last I-to-I sequence
>>..store a few uncompressed images (e.g. 10 if you use IBBPBBPBBI)

This is a drawback, but I had 1000+ frame animations in mind.

>   And you definitely can't make povray to create the frames in the order
> cmpeg needs them (ie. by making the clock to jump back and forth) because
> that will surely break some scenes (this happens when the result of the
> previous frame is written to disk and then read in the next frame).

You're right. For fully parametrified (hmm, what's the correct word in
English?) animations that have a clock going from 0 to 1, it could work,
but I don't think I would try that.

/PETER/

-- 
Peter Santo (PUMP development)
HP: http://www.exaweb.de
> Ever heard of .cshrc?
That's a city in Bosnia.  Right?

Post a reply to this message

Nieminen Juha wrote:

>   Take into account that cmpeg doesn't take the frames in order. You would
> have to create as many frames as cmpeg needs for the next frame before
> you can call it.
>   And you definitely can't make povray to create the frames in the order
> cmpeg needs them (ie. by making the clock to jump back and forth) because
> that will surely break some scenes (this happens when the result of the
> previous frame is written to disk and then read in the next frame).

I am not so sure that adding mpeg to the windows version of pov is entirely
out of the question. When I asked about it in the patches group Thorsten
offered this bit of information:

>
The Mac movie output code (which I wrote) does it using QuickTime. With just
a few minor adjustments it should be possible to compile it to work with
QuickTime for Windows (no, don't ask me to do it).   And there are (3rd
party) MPEG encoders for QuickTime (try http://guide.apple.com/usindex.html
and search for MPEG).
<





-- 
Ken Tyler -  1100+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

> >
> The Mac movie output code (which I wrote) does it using QuickTime. With just
> a few minor adjustments it should be possible to compile it to work with
> QuickTime for Windows (no, don't ask me to do it).   And there are (3rd
> party) MPEG encoders for QuickTime (try http://guide.apple.com/usindex.html
> and search for MPEG).
> <

Hmm, I personally would object to using QT as the only/default output
format for all/Win versions of povray, whether it uses an MPEG codec or
not. But that's just my opinion.

/PETER/

-- 
Peter Santo (PUMP development)
HP: http://www.exaweb.de
> Ever heard of .cshrc?
That's a city in Bosnia.  Right?

Post a reply to this message

>   We can see this in moray. Hundreds of plugins have been made to it, 
I wish. Actually only about 10 have been made.

>   The funny thing is that this kind of scripting language plugin shouldn't
> be very hard to do...
Yet no one with the ability to do it wants to... don't look at me, I
don't use scripting languages<g>.

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

Peter Santo wrote:

> > > - Every time an I-frame is generated, compress the last I-to-I sequence,
> > > append it to the mpeg file, generate a valid mpeg header and delete the
> > > uncompressed images.
> >
> > Just use QuickTime.
>
> AFAIC QT animation support is limited to Mac versions of povray. I do
> not use a Mac and do not intend to do so.
>
> > It already does all of this and renders directly to
> > MPEG without the extra steps.
>
> Doesn't QuickTime use information from preceding frames?
>
> /PETER/

QT Pro does that kind of conversions, but with the basic QT freeware I render
directly to a QT movie with POV.

Steve

Post a reply to this message

> > Doesn't QuickTime use information from preceding frames?
> 
> QT Pro does that kind of conversions, but with the basic QT freeware I render
> directly to a QT movie with POV.

What does "directly" mean? If every frame is compressed by itself
(without using information from preceding and/or following frames) the
compression rate will be comparable to jpg. That is not what I had in
mind. I aim for compression rates a magnitude higher.

/PETER/

-- 
Peter Santo (PUMP development)
HP: http://www.exaweb.de
> Ever heard of .cshrc?
That's a city in Bosnia.  Right?

Post a reply to this message

In article <38185CAE.213623AA@cantor.informatik.rwth-aachen.de> , Peter 
Santo <pet### [at] cantorinformatikrwth-aachende>  wrote:

>> QT Pro does that kind of conversions, but with the basic QT freeware I render
>> directly to a QT movie with POV.
>
> What does "directly" mean? If every frame is compressed by itself
> (without using information from preceding and/or following frames) the
> compression rate will be comparable to jpg. That is not what I had in
> mind. I aim for compression rates a magnitude higher.

Well, in theory a codec could access previous frames and optimise the
compression for a set of frames. I don't know how the available MPEG codecs
do it. however.
As for "directly", you could just use a lossless codec and do the
compression to another format later (no need for QT Pro, there are enough
tools that allow you to do a simple change of the encoder). For example a
Sorensen codec if you want very high compression. Of course you could also
use a commercial MPEG 2 encoder and create a movie out of it to be put on
DVD.


    Thorsten

Post a reply to this message