dick balaska <dic### [at] buckosoftcom> wrote:
> On 07/07/2018 11:56 AM, Chuck wrote:
>
> >
> > Don't know if it is good practice but, if possible, I want to maintain all of
> > the information present in the original rendered frames.
>
> I think that is every animator's goal.
>
> > The originals as
> > produced by PovRay are PNGs. Then since I use VirtualDub to produce an
> > uncompressed AVI from the frame sequence I assume that all of the original bits
> > are still present (at the cost of a huge file).
> >
> > Now I use ProShow to load in the AVI file and to add music and perhaps an
> > introductory black slide. Then there are many output options: BlueRay, DVD,
> > AVCHD, MPEG-4 (1080p (full HD), 4K UHD, and others.
> >
> > There is another box that can be checked that selects either 30fps normal, high,
> > or extreme quality. The normal quality is checked. Extreme quality doubles or
> > triples the size of the output file.
>
> I don't know "extreme", but normal and high are standard.  High gives
> better compression and better resolution at the expense of CPU power.
> These days, I see no reason to use normal.  (High was for the original
> 720p HD.)
>
> >
> > SmugMug then re-encodes the file for presentation so I don't know if selecting
> > normal quality really does any good.
> >
> > There were 1268 original frames produced. VLC shows the length of the animation
> > to be 2:06 minutes which at 30 FPS could use unique 3780 frames. I recall that
> > VirtualDub created the AVI at 10 FPS so the math seems to match up.
>
> I see. Yes, 10 FPS is definitely choppy speed.  You can go as low as 20
> FPS (23.976 is Blu-Ray speed) and look ok.
>
> >
> > An interestine experiment would be to render 3780 frames and have VirtualDub
> > create an AVI to run at 30 FPS.
>
> That would be an interesting experiment.
> My wild guess is an 80% larger file.  3x the frames but 50% is black.
>
>
> If you are comfortable with the command line, you should try ffmpeg.
> It's pretty much the standard these days.
>
> >
> > If reading between the lines above leads you to the conclusion that I am a
> > neophyte to video you would be correct.
>
> Aren't we all.
> You seem to have a good handle on what you're doing.  That puts you
> light years ahead of (100 - ℓP)% of people.
> >
> > I set the options on SmugMug to limit the res of the download to try to keep
> > pilfering down but if it is useful I could check into creating another gallery
> > and allow a download of the "fullm as created mp4 file".
>
> I would be very interested in seeing your vid with a higher frame rate. :)
>
> >
> > Chuck
> >
> >
> >
>
>
> --
> dik
> Rendered 328976 of 330000 (99%)

The program that creates the individual PovRay files is driven by a smallish
parameter file. Owing to poor "backup hygiene" the program has been modified so
that the original parameter file no longer works. I am working on a newer
version that should be able to reproduce a reasonable look alike series of
images. When it is working again I will make a 30 FPS animation that has 30
rendered frames per second.

I created a private gallery at:

www.elevenmilephotography.com

with a password of "povray" (no quotes). When the private gallery is entered it
is possible to download the original MP4 exactly as it was uploaded. The file
size is 25.1 MB. In case anyone is interested...

Since the original AVI is still available, as an experiment I will encode a new
animation with high quality set.

Using ffmpeg: No worries on using the command line. What would it replace:
VirtualDub or the ProShow encoding?

Chuck

Post a reply to this message

On 07/07/2018 03:20 PM, Chuck wrote:

>> On 07/07/2018 11:56 AM, Chuck wrote:
> The program that creates the individual PovRay files is driven by a smallish
> parameter file. Owing to poor "backup hygiene" the program has been modified so
> that the original parameter file no longer works. I am working on a newer
> version that should be able to reproduce a reasonable look alike series of
> images. When it is working again I will make a 30 FPS animation that has 30
> rendered frames per second.
> 
> I created a private gallery at:
> 
> www.elevenmilephotography.com
> 
> with a password of "povray" (no quotes). When the private gallery is entered it
> is possible to download the original MP4 exactly as it was uploaded. The file
> size is 25.1 MB. In case anyone is interested...
> 
> Since the original AVI is still available, as an experiment I will encode a new
> animation with high quality set.
> 
> Using ffmpeg: No worries on using the command line. What would it replace:
> VirtualDub or the ProShow encoding?

Minimally it would replace VirtualDub; convert *.png to x.mp4
Maybe ProShow wouldn't transcode it if it was already a palatable format 
for it.

Here's my command line for a 720p video:
ffmpeg  -y -r 30 -i ttlo%4d.png -i ttlo.wav -s hd720 -map 0:0 -map 1:0 
-crf 17 -c:v libx264 -preset slow -pix_fmt yuv420p -strict -2 ttlo.mp4

-y = overwrite existing .mp4 file
-r 30 = 30 fps
-i ttlo%4d.png = read ttlo0001.png through ttlo3280.png
           (ttlo%d.png would read ttlo1.png through ttlo3280.png)
-i ttlo.wav = audio file
-s hd720 = make a 720p video
-map 0:0 = put the video in the first stream
-map 1:0 = put the audio in the second stream
-crf 17 = video quality.  24-20 is nominal. 17 is a little better.
           higher numbers are smaller files and worse video
-c:v libx264 = use x264 encoder, i.e. standard .mp4
-preset slow = spend more time making good compression
-pix_fmt yuv420p = just because
-strict = lock the aspect ratio
-2 = because Mr. google said so.
ttlo.mp4 = output file

(My .png are rendered at 1280x720 with a 1:1 aspect ratio)

-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

dick balaska <dic### [at] buckosoftcom> wrote:
> On 07/07/2018 11:56 AM, Chuck wrote:
>
> > The originals as
> > produced by PovRay are PNGs. Then since I use VirtualDub to produce an
> > uncompressed AVI from the frame sequence I assume that all of the
> > original bits are still present (at the cost of a huge file).
> >
> > Now I use ProShow to load in the AVI file and to add music and perhaps an
> > introductory black slide. Then there are many output options: BlueRay, DVD,
> > AVCHD, MPEG-4 (1080p (full HD), 4K UHD, and others.
> > [snip]
> > SmugMug then re-encodes the file for presentation...

I still use VirtualDub as well, for certain videos (and follow a similar
two-or-three-stage final encoding process as you do-- although I presently use
Avidemux in place of your ProShow and SmugMug.) The interesting thing about
VirtualDub-- whether for a compressed file there or an uncompressed one-- is
that the video is saved as all keyframes, by default. My experience in playing
back such a 1920X1080 video as-is, is that it stutters on my own computer--
probably because that's a LOT of video information to decode on-the-fly. When I
later transcode the video in Avidemux (usually as an h.264-encoded file in am
..mp4 container format), I can 'reduce' all those individual keyframes to a
keyframe only every 25 frames (for example), which greatly-reduces the
stuttering. SO... maybe your ProShow/SmugMug transcoding process is keeping
*all* the original keyframes intact? Which might be the cause of the stuttering?
>
> If you are comfortable with the command line, you should try ffmpeg.
> It's pretty much the standard these days.

I think Avidemux makes use of ffmeg as it's 'engine' (although I'm not sure);
but I've not yet used ffmeg itself as a command-line tool. It does seem that
many folks here in the newsgroups are comfortable with it. (BTW, thanks for the
ffmeg example code you posted here.)
> >
> > If reading between the lines above leads you to the conclusion that I am a
> > neophyte to video you would be correct.
>
> Aren't we all.
> You seem to have a good handle on what you're doing.  That puts you
> light years ahead of (100 - ℓP)% of people.

Ain't it the truth! Trying to clearly understand all the different file formats,
encoding options, container formats etc. could be a full-time job! ;-)  And apps
like Avidemux-- as good as they are-- seems to have their *own* little quirks
that take some getting-used-to. (When a new version comes along, I dutifully
download it-- then I find that my workarounds for the previous version have to
be modified for the 'new' quirks. Aarggh!) It's the same with other video
encoders/transcoders that I've used-- except VirtualDub(!), which seems
rock-solid and consistent with its .avi-output files.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> dick balaska <dic### [at] buckosoftcom> wrote:
> > On 07/07/2018 11:56 AM, Chuck wrote:
> >
> > > The originals as
> > > produced by PovRay are PNGs. Then since I use VirtualDub to produce an
> > > uncompressed AVI from the frame sequence I assume that all of the
> > > original bits are still present (at the cost of a huge file).
> > >
> > > Now I use ProShow to load in the AVI file and to add music and perhaps an
> > > introductory black slide. Then there are many output options: BlueRay, DVD,
> > > AVCHD, MPEG-4 (1080p (full HD), 4K UHD, and others.
> > > [snip]
> > > SmugMug then re-encodes the file for presentation...
>
> I still use VirtualDub as well, for certain videos (and follow a similar
> two-or-three-stage final encoding process as you do-- although I presently use
> Avidemux in place of your ProShow and SmugMug.) The interesting thing about
> VirtualDub-- whether for a compressed file there or an uncompressed one-- is
> that the video is saved as all keyframes, by default. My experience in playing
> back such a 1920X1080 video as-is, is that it stutters on my own computer--
> probably because that's a LOT of video information to decode on-the-fly. When I
> later transcode the video in Avidemux (usually as an h.264-encoded file in am
> ..mp4 container format), I can 'reduce' all those individual keyframes to a
> keyframe only every 25 frames (for example), which greatly-reduces the
> stuttering. SO... maybe your ProShow/SmugMug transcoding process is keeping
> *all* the original keyframes intact? Which might be the cause of the stuttering?
> >
> > If you are comfortable with the command line, you should try ffmpeg.
> > It's pretty much the standard these days.
>
> I think Avidemux makes use of ffmeg as it's 'engine' (although I'm not sure);
> but I've not yet used ffmeg itself as a command-line tool. It does seem that
> many folks here in the newsgroups are comfortable with it. (BTW, thanks for the
> ffmeg example code you posted here.)
> > >
> > > If reading between the lines above leads you to the conclusion that I am a
> > > neophyte to video you would be correct.
> >
> > Aren't we all.
> > You seem to have a good handle on what you're doing.  That puts you
> > light years ahead of (100 - ℓP)% of people.
>
> Ain't it the truth! Trying to clearly understand all the different file formats,
> encoding options, container formats etc. could be a full-time job! ;-)  And apps
> like Avidemux-- as good as they are-- seems to have their *own* little quirks
> that take some getting-used-to. (When a new version comes along, I dutifully
> download it-- then I find that my workarounds for the previous version have to
> be modified for the 'new' quirks. Aarggh!) It's the same with other video
> encoders/transcoders that I've used-- except VirtualDub(!), which seems
> rock-solid and consistent with its .avi-output files.

Dick - thanks for the ffmpeg parms. I feel that a number of similar programs are
expert friendly. I don't mean that as negative at all. These programs just give
the user a whole lot more knobs to turn when using them. The challenge is
knowing what the knobs are supposed to do.

Key frames - I know what a keyframe is (perhaps), just not how to identify them
in a video editor. I'm not sure but don't think ProShow gold will identify them.
The prog seems to read in the large uncompressed AVIs produced with VirtualDub
with no problems.

Now rendering a new animation (much less complex than before) just to see how a
30 (or 20) FPS video will look. The previews do look much less "choppy" as
expected. The first attempts had about 30,000 objects in the image which PovRay
handled quite well but the resulting image did not look so good so reduced the
maximum number of objects to 2,000.

A year ago wrote an interface to DirectX12 and ported the code logic to the
program. Instead of waiting quite some time for a render the visuals were
instant. I went back to PovRay and quite like it. PovRay seems to be the best
system for what I want to do. Have used it for a long time. I like blender but
don't know python at all and I believe that would be necessary to do the same
sort of animation. Could be lack of knowledge talking here. The Blender physics
model is awesome though. The glass funnel animation on the web site was created
with that. I would take a closer look at progs like AvidMux but ProShow provides
copyright worry free music for slideshows and videos and that sells it for me.

Chuck

Post a reply to this message

On 09/07/2018 02:45, Chuck wrote:
>   I like blender but
> don't know python at all and I believe that would be necessary to do the same
> sort of animation. Could be lack of knowledge talking here.



You don't need to use Python to create a video using Blender. I can't 
and do. :)
Blender will create your avi or mpg4 from a series of images. It comes 
with a set of default settings for various outputs and you can manually 
adjust them.
I have been following this thread as I am not too sure what all the 
settings do and their effects.


The lowest fps I use is 25 fps but generally use 30 fps. Occasionally 60 
fps for very smooth animations.


-- 

Regards
     Stephen

Post a reply to this message

Am 08.07.2018 um 22:12 schrieb Kenneth:

> I still use VirtualDub as well, for certain videos (and follow a similar
> two-or-three-stage final encoding process as you do-- although I presently use
> Avidemux in place of your ProShow and SmugMug.) The interesting thing about
> VirtualDub-- whether for a compressed file there or an uncompressed one-- is
> that the video is saved as all keyframes, by default. My experience in playing
> back such a 1920X1080 video as-is, is that it stutters on my own computer--
> probably because that's a LOT of video information to decode on-the-fly.

My guess would be that the stuttering is not due to an excessive amount
of data to be /decoded/, but rather simply due to an excessive amount of
data to be /read/ from hard disk.

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:
> On 09/07/2018 02:45, Chuck wrote:
> >   I like blender but
> > don't know python at all and I believe that would be necessary to do the same
> > sort of animation. Could be lack of knowledge talking here.
>
>
>
> You don't need to use Python to create a video using Blender. I can't
> and do. :)
> Blender will create your avi or mpg4 from a series of images. It comes
> with a set of default settings for various outputs and you can manually
> adjust them.
> I have been following this thread as I am not too sure what all the
> settings do and their effects.
>
>
> The lowest fps I use is 25 fps but generally use 30 fps. Occasionally 60
> fps for very smooth animations.
>
>
> --
>
> Regards
>      Stephen

I wasn't very clear about python. The glass funnel animation at:
www.elevenmilephotography.com, gallery: private, PW: povray was created with
Blender's physics model. I assumed (?) that an animation like "Duet" (over 2,000
objects each moving every frame) would require the use of custom python files in
one form or another. I sincerely hope that this assumption is wrong.

Chuck

Post a reply to this message

On 10/07/2018 13:56, Chuck wrote:
> Stephen <mca### [at] aolcom> wrote:
>> On 09/07/2018 02:45, Chuck wrote:
>>>    I like blender but
>>> don't know python at all and I believe that would be necessary to do the same
>>> sort of animation. Could be lack of knowledge talking here.
>>
>>
>>
>> You don't need to use Python to create a video using Blender. I can't
>> and do. :)
>> Blender will create your avi or mpg4 from a series of images. It comes
>> with a set of default settings for various outputs and you can manually
>> adjust them.
>> I have been following this thread as I am not too sure what all the
>> settings do and their effects.
>>
>>
>> The lowest fps I use is 25 fps but generally use 30 fps. Occasionally 60
>> fps for very smooth animations.
>>
>>
>> --
>>
>> Regards
>>       Stephen
> 
> I wasn't very clear about python. The glass funnel animation at:
> www.elevenmilephotography.com, gallery: private, PW: povray was created with
> Blender's physics model. I assumed (?) that an animation like "Duet" (over 2,000
> objects each moving every frame) would require the use of custom python files in
> one form or another. I sincerely hope that this assumption is wrong.
> 
> Chuck
> 


No, you do not need python or I would not be able to use it.
In March I posted an animation in povray.binaries.animations called In 
the Meantime a diversion. Using Blender's Internal renderer. (The PovRay 
exporter cannot handle it.)

I upped the number of boids to 3000 in this animation although there are 
only 2 boids the rest are copied versions.
https://youtu.be/emAuf6o2hzM

Very rough and ready, I am afraid.

-- 

Regards
     Stephen

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 08.07.2018 um 22:12 schrieb Kenneth:
>
> > I still use VirtualDub as well, for certain videos... The interesting
> > thing about VirtualDub... is that the video is saved as all keyframes,
> > by default. My experience in playing
> > back such a 1920X1080 video as-is, is that it stutters on my own computer--
> > probably because that's a LOT of video information to decode on-the-fly.
>
> My guess would be that the stuttering is not due to an excessive amount
> of data to be /decoded/, but rather simply due to an excessive amount of
> data to be /read/ from hard disk.

That's probably the bulk of the problem, I admit, especially for a 1920X1080
video. But I've noticed 'stuttering' even in 960X520 h.264-encoded videos, when
all the frames are keyframes. (For some reason, I think it becomes more apparent
when a video is 'streamed' rather than with direct computer-playback.)

Chuck wrote:
> Key frames - I know what a keyframe is (perhaps), just not how to identify
> them in a video editor. I'm not sure but don't think ProShow gold will
> identify them.

Actually, VirtualDub itself shows which frames are keyframes ("I-frames"), in
the little info bar a the bottom of the playback window. (When a group of
POV-Ray animation images are first loaded into VD, they start off as all
keyframes.)

Essentially, video encoding is more efficient (smaller file size) when it uses
fewer actual keyframes for the final video. The 'in-between' frames (called
"P-frames" and "B-frames") are actually composed of only the *differences*
between an I-frame and its surrounding frames-- with very little quality loss.
Put very simply, those differences are made up of small 8X8- or 16X16-pixel
blocks ("macroblocks".) The encoder tries to find 'matching' macroblocks among
the adjacent frames (even if those blocks have moved during the frame changes.)
It re-uses those blocks when it can, in the adjacent P-frames and B-frames. So
the P's and B's contain much less 'new' information than would otherwise be the
case.

For an ALL-keyframe video, a crude analogy would be as if each individual frame
is encoded as an individual and separate JPEG image. While that's possible to do
(the "motion-JPEG" format does this, as far as I understand), it's not very
efficient-- the video decoder has to decode ALL the macroblocks in each
individual frame on-the-fly.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> Chuck wrote:
> > Key frames - I know what a keyframe is (perhaps), just not how to identify
> > them in a video editor. I'm not sure but don't think ProShow gold will
> > identify them.
>
> Actually, VirtualDub itself shows which frames are keyframes ("I-frames"), in
> the little info bar a the bottom of the playback window. (When a group of
> POV-Ray animation images are first loaded into VD, they start off as all
> keyframes.)
>
> Essentially, video encoding is more efficient (smaller file size) when it uses
> fewer actual keyframes for the final video. The 'in-between' frames (called
> "P-frames" and "B-frames") are actually composed of only the *differences*
> between an I-frame and its surrounding frames-- with very little quality loss.
> Put very simply, those differences are made up of small 8X8- or 16X16-pixel
> blocks ("macroblocks".) The encoder tries to find 'matching' macroblocks among
> the adjacent frames (even if those blocks have moved during the frame changes.)
> It re-uses those blocks when it can, in the adjacent P-frames and B-frames. So
> the P's and B's contain much less 'new' information than would otherwise be the
> case.
>
> For an ALL-keyframe video, a crude analogy would be as if each individual frame
> is encoded as an individual and separate JPEG image. While that's possible to do
> (the "motion-JPEG" format does this, as far as I understand), it's not very
> efficient-- the video decoder has to decode ALL the macroblocks in each
> individual frame on-the-fly.

I appreciate the key-frame info. That raises a number of questions but would
stray from PovRay related topics so will do some private reading.

Another animation was created with the idea of generating 25 frames per second.
As expected the resulting animation is MUCH more smooth. Unfortunately I cannot
reproduce the original animation which started this thread and the current
attempts, while smooth, are not very interesting. I may upload one of them to
demonstrate the improvements anyway.

Post a reply to this message