 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmail com> 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
|
|
| |
| |
|
|
|
|
| |
|
|
