The animation was rendered at high res which caused buffering pauses with slower
internets feeds. It was replaced with lower res (link below), probably not
descernable after gallery compression.

https://elevenmilephotography.smugmug.com/Experiments/i-xjk2QXx/A

Thanks for the comment Dick.

Chuck

Post a reply to this message

On 07/05/2018 05:45 PM, Chuck wrote:
> 
> The animation was rendered at high res which caused buffering pauses with slower
> internets feeds. It was replaced with lower res (link below), probably not
> descernable after gallery compression.
> 
> https://elevenmilephotography.smugmug.com/Experiments/i-xjk2QXx/A
> 
> Thanks for the comment Dick.
> 
> Chuck
> 
> 
> 

I had no issues with buffering, but I thought it was, um choppy?  Like a 
very low frame rate or odd codec.

Oh, you squeezed a 2 minute 1080p video into 60KB.  That's pretty 
impressive.  What did you use to encode that?


Name	DuetPS9StdRes.mp4
Size	1920 x 1080
File Size	60.16 KB
Advanced
Duration	0:02:18
Audio Codec	mp4a
Video Codec	avc1

-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

dick balaska <dic### [at] buckosoftcom> wrote:
> On 07/05/2018 05:45 PM, Chuck wrote:
> >
> > The animation was rendered at high res which caused buffering pauses with slower
> > internets feeds. It was replaced with lower res (link below), probably not
> > descernable after gallery compression.
> >
> > https://elevenmilephotography.smugmug.com/Experiments/i-xjk2QXx/A
> >
> > Thanks for the comment Dick.
> >
> > Chuck
> >
> >
> >
>
> I had no issues with buffering, but I thought it was, um choppy?  Like a
> very low frame rate or odd codec.

Impressive video! But I see 'choppiness' as well, in all five of the streaming
video-resolutions (even at 320 X 180-- and I have a fast broadband connection.)
>
> Oh, you squeezed a 2 minute 1080p video into 60KB.  That's pretty
> impressive.  What did you use to encode that?
>
>
> Name DuetPS9StdRes.mp4
> Size 1920 x 1080
> File Size 60.16 KB
> Advanced
> Duration 0:02:18
> Audio Codec mp4a
> Video Codec avc1
>

How did you find that info? In Firefox, I have an add-on called VideoConverter,
but the only things it shows are the various 'streaming' bitrates, not the file
size(s). (And in this case, VC can't download it as a 'file', as far as I can
tell.) If the 1920 X 1080 video is indeed only 60+ KB in size, that's...
extraordinary!! (I have my doubts-- but if true, maybe it's because the video
frames show mostly a pure black background, which is easy to encode.)

In another post, Chuck mentioned that the video was saved as an .avi file; in
your own data above, the Video Codec seems to be avc1. That would be a
variant(?) of h.264 I believe (or maybe the same thing?) I wonder if
avc1-encoded video-- but wrapped in an old-style.avi container-- might be a bad
mix? Just a conjecture-- I'm thinking about the choppiness.

Post a reply to this message

On 07/07/2018 12:10 AM, Kenneth wrote:

> How did you find that info? 

The little italic 'i' in the bottom right of the page.
Of course, it could by lying...


-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

On 07/07/2018 12:10 AM, Kenneth wrote:
>>
> 
> How did you find that info? In Firefox, I have an add-on called VideoConverter,
> but the only things it shows are the various 'streaming' bitrates, not the file
> size(s). (And in this case, VC can't download it as a 'file', as far as I can
> tell.) 

View source, line 33 gives you the video url. [1]
I downloaded the 640x360 edition.  It is 2.9 MB which seems about right.

> If the 1920 X 1080 video is indeed only 60+ KB in size, that's...
> extraordinary!! (I have my doubts-- but if true, maybe it's because the video
> frames show mostly a pure black background, which is easy to encode.)
> 
> In another post, Chuck mentioned that the video was saved as an .avi file; in
> your own data above, the Video Codec seems to be avc1. That would be a
> variant(?) of h.264 I believe (or maybe the same thing?) I wonder if
> avc1-encoded video-- but wrapped in an old-style.avi container-- might be a bad
> mix? Just a conjecture-- I'm thinking about the choppiness.

mediainfo says it was encoded with Lavf57.71.100 which is part of 
ffmpeg.  It was likely transcoded when he uploaded it.
> 
> 
> 

[1] On my video page, I scrambled the url just to keep the stupid robots 
at bay.

-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

dick balaska <dic### [at] buckosoftcom> wrote:
> On 07/07/2018 12:10 AM, Kenneth wrote:
> >>
> >
> > How did you find that info? In Firefox, I have an add-on called VideoConverter,
> > but the only things it shows are the various 'streaming' bitrates, not the file
> > size(s). (And in this case, VC can't download it as a 'file', as far as I can
> > tell.)
>
> View source, line 33 gives you the video url. [1]
> I downloaded the 640x360 edition.  It is 2.9 MB which seems about right.
>
> > If the 1920 X 1080 video is indeed only 60+ KB in size, that's...
> > extraordinary!! (I have my doubts-- but if true, maybe it's because the video
> > frames show mostly a pure black background, which is easy to encode.)
> >
> > In another post, Chuck mentioned that the video was saved as an .avi file; in
> > your own data above, the Video Codec seems to be avc1. That would be a
> > variant(?) of h.264 I believe (or maybe the same thing?) I wonder if
> > avc1-encoded video-- but wrapped in an old-style.avi container-- might be a bad
> > mix? Just a conjecture-- I'm thinking about the choppiness.
>
> mediainfo says it was encoded with Lavf57.71.100 which is part of
> ffmpeg.  It was likely transcoded when he uploaded it.
> >
> >
> >
>
> [1] On my video page, I scrambled the url just to keep the stupid robots
> at bay.
>
> --
> dik
> Rendered 328976 of 330000 (99%)

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

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.

An interestine experiment would be to render 3780 frames and have VirtualDub
create an AVI to run at 30 FPS.

If reading between the lines above leads you to the conclusion that I am a
neophyte to video you would be correct.

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

Chuck

Post a reply to this message

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

Post a reply to this message

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