[Running v3.8.0 beta 1 in Windows 10]
This is my first uploaded animation from my Windows 10 computer that I purchased
in early 2021.

Scattering media plus two light_sources, using two warp{turbulences...} -- one
moves in y, the other is static.

This is really more of a test of my animation encoding scheme, to see if the
file plays back for everyone. (Of course, in the newsgroups' web-portal, there
is always an extra suffix appended to the end of an animation file name, which
causes problems for playback in certain apps).

I am certainly no expert on the subject of video compression, but I keep trying
to learn. There are so *many* so-called 'standards' that have accumulated over
the years.  It was all much simple in the days of AVI video-making!

I used an old but still-available app called 'VirtualDub2 MOD' to assemble this
animation from .png renders. On my system, the resulting animation plays in all
of the video apps I have: Windows Media Player, Irfanview, avidemux (another
*old* one), VirtualDub2 MOD, and VLC Media Player.

VirtualDub2 MOD has lots of compression/encoding choices-- many of which I don't
understand, so I leave them at their defaults. But I've been experimenting with
the simpler choices. This is how I encoded the file; the stats as seen in the
app itself are copied verbatim:

COMPRESSION:
x264 8 bit - H.264/MPEG-4 AVC codec
YUV 4:2:0
MPEG 'profile' and 'Level' on 'Auto'
pixel format: 4:2:0 planar YCbCr (YV12)
YCbCr properties:  color space: Rec 709 HD
component range: Limited (Y: 16 - 235)
Source: RGBA32
Actual output: YUV420-709

CONTAINER FORMAT:
MP4 (MPEG-4 Part 14) (*.mp4)

Yeah, a lot of this stuff looks like technical gibberish and is not easily
understood. But some research on Wikipedia about 'Rec 709' as well as 'chroma
subsampling' was quite useful-- regarding the 4:2:0 and YCbCr stuff in
particular.

4:2:0 is one of the standards used for chroma subsampling for compression; but
there are others, like 4:2:2. According to what I have read, that one should
also work with the Rec 709 standard (and at a higher quality)-- but such a test
animation does not play in Windows Media Player; I get
a black screen. And it *crashes* Irfanview, so badly that the app is broken for
my entire work session-- I have to reboot Windows to bring it back to working
status. Yet, other apps I have like VLC Media Player play it back OK. I have no
idea why, so far.

The most interesting statistic IMO is the 'component range' of Y: 16 - 235.
Y itself is the luminance of the colors -- think grayscale brightness levels.
(Actually it's not luminance but 'luma', which AFAIK is the gamma-corrected
version of luminance.)  It would *seem* that a 'full' range of 0-255 brightness
levels would the ideal choice-- and VirtualDub does allow that choice as 'Rec
709 HD FR' ("full range").  But in my encoding tests, the 'limited' 16-235 range
actually reproduces the POV-ray renders far more accurately.  0 - 255 produces
higher contrast and does not match the original render. That seems strange, but
I guess it involves some deeper technical stuff.

I'm still learning  ;-)

Post a reply to this message

Attachments:
Download 'media_smoke_2_18_22__4_2_0_rec709_16_to_235.mp4.dat' (2293 KB)

Op 20/02/2022 om 00:34 schreef Kenneth:
> [Running v3.8.0 beta 1 in Windows 10]
> This is my first uploaded animation from my Windows 10 computer that I purchased
> in early 2021.
> 
> Scattering media plus two light_sources, using two warp{turbulences...} -- one
> moves in y, the other is static.
> 
[snip]

Tonga!

That is pretty good, Kenneth. Impressive smoke column.

-- 
Thomas

Post a reply to this message

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> [Running v3.8.0 beta 1 in Windows 10]
> This is my first uploaded animation from my Windows 10 computer that I purchased
> in early 2021.

agree with TdG, impressive.  (any darker and I'd suspect burning car tires :-))


> ...
> This is really more of a test of my animation encoding scheme, to see if the
> file plays back for everyone. ...

works here, using 'ffplay' (part of 'ffmpeg') on Slackware Linux, and on Android
using VLC, the Chromebook too plays it.


> I am certainly no expert on the subject of video compression, but I keep trying
> to learn. There are so *many* so-called 'standards' that have accumulated over
> the years.  It was all much simple in the days of AVI video-making!

may David Buck can chip in.  I was (seriously) impressed by his recent coding
demo which came in at only ~1.2M.  (wouldn't mind knowing the "magic" settings)


regards, jr.

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
>
> Tonga!
>
> That is pretty good, Kenneth. Impressive smoke column.
>

Thanks. I am glad it played OK for you!

My original idea was to create translucent wispy smoke or steam; but with higher
media density and a higher extinction value, the result looks like dense smoke,
which I like. Actually, this particular test reminds me of those undersea
'smoker' vents on the sea floor, where the pressure is so great that the 'smoke'
does not spread out or dissipate very much.

The test code at the beginning of the animation is good for experimenting with
the various values.

----
That Tonga volcanic explosion was quite awesome to see, especially the
time-lapse animations from space. I can imagine it being x-number of times more
powerful, as an indication of the asteroid event that wiped out the dinosaurs!

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
>
> agree with TdG, impressive.  (any darker and I'd suspect burning car tires :-))

Ha! Yes, that can easily be done too; one of my tests looked like that.

> works here, using 'ffplay' (part of 'ffmpeg') on Slackware Linux, and on Android
> using VLC, the Chromebook too plays it.

Good to know! Thanks for the feedback.

> may David Buck can chip in.  I was (seriously) impressed by his recent coding
> demo which came in at only ~1.2M.  (wouldn't mind knowing the "magic" settings)

ANY help would be useful ;-) Trying to fathom the intricacies of this
compression stuff-- AND container formats -- is like reading 'Moby Dick' in
Sanscrit. In fact, the more I read about all of it, the more confusing it gets.
There are HD video transmission standards, rgb vs. Rec 709 (and 601) standards,
DVD standards, Blu_Ray standards, etc etc...

:-O

Post a reply to this message

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

> > may David Buck can chip in.  I was (seriously) impressed by his recent coding
> > demo which came in at only ~1.2M.  (wouldn't mind knowing the "magic" settings)
>
> ANY help would be useful ;-) Trying to fathom the intricacies of this
> compression stuff-- AND container formats -- is like reading 'Moby Dick' in
> Sanscrit. In fact, the more I read about all of it, the more confusing it gets.
> There are HD video transmission standards, rgb vs. Rec 709 (and 601) standards,
> DVD standards, Blu_Ray standards, etc etc...
>
> :-O

I had to resize a video for a friend a while back, and as far as I can remember,
I used ffmpeg, or convert in order to resize and maybe decrease the frame rate
to make the file size smaller.

For the Secret Passage entry, I remember that all I did was open the image in
some image viewer and the re-save it using some settings that brought the file
size down.

I'd say that this is one of those areas where you should really just jettison
understanding how any of it works, and just start trying out different utilities
and software packages.   Fly by the seat of your pants.   Because when that
waters are this deep, and you're not planning to start a new PhD level career in
graphics formats and data compression algorithms, then you're not going to get
anything done, and you're still not going to understand how it all works.   Just
watch a single video on jpg compression and you'll see what I mean.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> I had to resize a video for a friend a while back, and as far as I can remember,
> I used ffmpeg, or convert in order to resize and maybe decrease the frame rate
> to make the file size smaller.

AFAIK(?) both VLC Media Player and VirtualDub2 MOD make use of ffmpeg-- hidden
under their Windows GUI's. I confess that I have never been any good at using
ffmpeg's command-line tools; trying to remember which code settings to use makes
my brain hurt. (Translation: I'm lazy ;-) ]
>
> I'd say that this is one of those areas where you should really just jettison
> understanding how any of it works...
> Because when that waters are this deep, and you're not planning to start a
> new PhD level career in graphics formats and data compression algorithms,
> then you're not going to get anything done, and you're still not going
> to understand how it all works.

Yeah, I agree! Well-said. Although, it nags me that I don't fully understand all
of it-- just enough to be dangerous! It's fascinating to read about...until my
eyes glaze over.

But I *want* to be a PhD genius in graphics formats and data compression
algorithms!

And an astronaut. And a James Bond 007 spy. And...

Post a reply to this message