New patch request:

  I recently discovered that the Mac version of pov has direct support for
compiling animation's as apple quick time movies. How hard would it be to
build a mpeg encoder into one of the existing patches ? Why should the
rest of us be left out of the fun eh ?

Rebelliously yours,

-- 
Ken Tyler
  
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm

Post a reply to this message

On Fri, 23 Jul 1999 19:13:35 -0700, Ken <tyl### [at] pacbellnet> wrote:

>
>New patch request:
>
>  I recently discovered that the Mac version of pov has direct support for
>compiling animation's as apple quick time movies. How hard would it be to
>build a mpeg encoder into one of the existing patches ? Why should the
>rest of us be left out of the fun eh ?
>
>Rebelliously yours,

Direct usage of the Windows video (and audio? :) codecs shouldn't be
that hard... if DTA does it POV can do it too!

The problem is, as with jpeg output, you wouldn't want to leave a
over-the-weekend render and come back to see that the resulting
animation is dreadfully crispy, blotchy and spotted.


Peter Popov
ICQ: 15002700

Post a reply to this message

Peter Popov wrote:
> 
> On Fri, 23 Jul 1999 19:13:35 -0700, Ken <tyl### [at] pacbellnet> wrote:
> 
> >
> >New patch request:
> >
> >  I recently discovered that the Mac version of pov has direct support for
> >compiling animation's as apple quick time movies. How hard would it be to
> >build a mpeg encoder into one of the existing patches ? Why should the
> >rest of us be left out of the fun eh ?
> >
> >Rebelliously yours,
> 
> Direct usage of the Windows video (and audio? :) codecs shouldn't be
> that hard... if DTA does it POV can do it too!
> 
> The problem is, as with jpeg output, you wouldn't want to leave a
> over-the-weekend render and come back to see that the resulting
> animation is dreadfully crispy, blotchy and spotted.
> 
> Peter Popov
> ICQ: 15002700

  What if... there were an option to render the image and store the frame into
the animation. That way if you need to recompile it the images are still present
to work with without the need to render the thing over agian. Can't do that with
the jpeg output but I think you can with this.


-- 
Ken Tyler
  
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm

Post a reply to this message

In article <3799214E.E8D83E9E@pacbell.net> , Ken <tyl### [at] pacbellnet>  
wrote:

> New patch request:
>
>   I recently discovered that the Mac version of pov has direct support for
> compiling animation's as apple quick time movies. How hard would it be to
> build a mpeg encoder into one of the existing patches ? Why should the
> rest of us be left out of the fun eh ?

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).


     Thorsten



> Rebelliously yours,
> Ken Tyler

:-)


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:

> 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).
> 
>      Thorsten

With most of the code already written it sounds like an even more compelling
reason to get it integrated into an exsisting patch. Were it that I had the
ability I would...

Thank you for the input Thorsten,

-- 
Ken Tyler
  
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm

Post a reply to this message

On Sat, 24 Jul 1999 00:54:48 -0700, Ken <tyl### [at] pacbellnet> wrote:

>  What if... there were an option to render the image and store the frame into
>the animation. That way if you need to recompile it the images are still present
>to work with without the need to render the thing over agian. Can't do that with
>the jpeg output but I think you can with this.

This seems reasonable to me. Strangely enough, I've never given this
particular solution any thought because I thought the main concern was
disk space and not speed. Probably because I have a pretty good MPEG
encoder/preset and all it takes is a couple of minutes (if I can't
wait that long, I view the anim as a slideshow in a DOS picture).

You can set up a post-animation shellout and use DTA to make an
animation with any windows codec you happen to have (may I recommend
Intel Indeo 5.21?)


Peter Popov
ICQ: 15002700

Post a reply to this message

Peter Popov wrote:
> 
> On Sat, 24 Jul 1999 00:54:48 -0700, Ken <tyl### [at] pacbellnet> wrote:
> 
> >  What if... there were an option to render the image and store the frame into
> >the animation. That way if you need to recompile it the images are still present
> >to work with without the need to render the thing over agian. Can't do that with
> >the jpeg output but I think you can with this.
> 
> This seems reasonable to me. Strangely enough, I've never given this
> particular solution any thought because I thought the main concern was
> disk space and not speed. Probably because I have a pretty good MPEG
> encoder/preset and all it takes is a couple of minutes (if I can't
> wait that long, I view the anim as a slideshow in a DOS picture).
> 
> You can set up a post-animation shellout and use DTA to make an
> animation with any windows codec you happen to have (may I recommend
> Intel Indeo 5.21?)
> 
> Peter Popov
> ICQ: 15002700

  Yeah I have a sh_t load of codecs installed on my system. I have the DTA
shellout already set up but it only compiles avi's not mpeg's. Additionaly
it would be nice if it were an internal process as opposed to running
secondary software. As Thorsten mentioned there are numereous third party
encoders available though I understand the quality of these can vary greatly
while the commercial jobbies are considered more reliable and of higher
qaulity.
  I haven't a clue about what's involved with implementing this and am
throwing this stuff out as I think of it. Therefore my think may very
well be flawed but that is nothing new so bear with me people.

-- 
Ken Tyler
  
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm

Post a reply to this message

Ken wrote:
> 
> Peter Popov wrote:
> >
> > On Fri, 23 Jul 1999 19:13:35 -0700, Ken <tyl### [at] pacbellnet> wrote:
<...>
> 
>   What if... there were an option to render the image and store the frame into
> the animation. That way if you need to recompile it the images are still present
> to work with without the need to render the thing over agian. Can't do that with
> the jpeg output but I think you can with this.
> 
> --
> Ken Tyler
> 
> mailto://tylereng@pacbell.net
> http://home.pacbell.net/tylereng/links.htm


Sorry Ken, but...
most video formats and at least mpeg have different types of frames.
With mpeg there are 'real' frames and two different types of
intermediates. One is approximated by two ends, the other just a forward
difference. Something like that. Anyway the distance between two frames
stored as such in an animation is something about 5 or 7, depending on
your options. If you change any frame in an animation, about 5 or 7
frames have to be recalculated to make up for the change. And as mpeg
(and all other) encoding is lossy, redoing single frames again and
again, would lead to a sum up of errors, getting you nowhere.

And last but not least, any solution based on the video libs of Windows
or Mac is of course nothing close to portable. I guess, only mpeg and
avi without compression are suitable for this.
OR, completely other way, there is a quicktime encoding based on png.
There are several sources available, like a pure Matlab implementation.
This could be handled quite cross-platform. May not compress good,
though.

Axel

Post a reply to this message