Stephen wrote:
> On 23 Aug 2008 13:24:35 -0400, Warp <war### [at] tagpovrayorg> wrote:
> 
>>  (Another issue is that creating an mpeg video (regardless of the mpeg
>> version) is not an unambiguous process. Some mpeg codecs are able to
>> create noticeably better image quality at the exact same file sizes
>> than other, lower-quality codecs.)
> 
> Would you expand on this, Warp?

The MPEG standard specifies *exactly* how to decode an MPEG file into 
something that can be displayed. However, it leaves several parts of the 
*encoding* process open to interpretation.

At least, that is my understanding of it.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Stephen <mcavoysAT@aoldotcom> wrote:
> >  (Another issue is that creating an mpeg video (regardless of the mpeg
> >version) is not an unambiguous process. Some mpeg codecs are able to
> >create noticeably better image quality at the exact same file sizes
> >than other, lower-quality codecs.)

> Would you expand on this, Warp?

  Let me present a closely related example:

  A compressed zip file format is very well specified, and thus there are
tons of programs which can read zip files. However, *creating* the zip
file is far from unambiguous. There is no one single definitive perfect
algorithm to create an optimally minimal zip file for any given data.
For this reason there exist zip optimizer programs (such as for example
advzip) which do a better job than the basic zip compressor programs
(such as WinZip or Windows Explorer).

  Creating an mpeg file is similarly ambiguous. There is no one single
optimal algorithm to do so, and thus some codecs do a better job than
others.

-- 
                                                          - Warp

Post a reply to this message

On 23 Aug 2008 15:06:31 -0400, Warp <war### [at] tagpovrayorg> wrote:

>
>  Creating an mpeg file is similarly ambiguous. There is no one single
>optimal algorithm to do so, and thus some codecs do a better job than
>others.

Sorry, I expressed myself badly. I was wondering which codices are the better
ones and which ones to avoid, for the windows platform.
-- 

Regards
     Stephen

Post a reply to this message

On Sat, 23 Aug 2008 19:42:04 +0100, Orchid XP v8 <voi### [at] devnull> wrote:

>
>The MPEG standard specifies *exactly* how to decode an MPEG file into 
>something that can be displayed. However, it leaves several parts of the 
>*encoding* process open to interpretation.
>
>At least, that is my understanding of it.

Thanks Andrew but ... (see below :)
-- 

Regards
     Stephen

Post a reply to this message

Orchid XP v8 wrote:
> The MPEG standard specifies *exactly* how to decode an MPEG file into 
> something that can be displayed. However, it leaves several parts of the 
> *encoding* process open to interpretation.

Yep. And the parts that are left open are difficult to implement. For 
example, one of the decoding commands is "take the block of pixels from 
X1,Y1 in the previous frame and draw them at X2,Y2 in this frame." 
(Called something like "motion compensation".) Which means you have to 
look all over the current frame to try to find a block of pixels that 
matches the previous frame somewhere. Works well for fast-moving 
objects, like a car driving past, but computationally expensive.

Plus, there's I frames, P frames, and B frames. Normally it's encoded 
something like
   IbbPbbPbbIbbPbbPbbI....
where the I frames are basically jpeg, the P frames are differences from 
the I frames, and the B frames are differences from both the previous 
frame and the following frame.  Lots and lots of encoders only go one 
direction, so they don't even generate B frames, which are usually far 
smaller than the other two types of frames.  (The I frames are the ones 
you can seek to, and the P frames are the ones you can show when you 
"fast forward" basically. Usually, I frames are twice a second or so.)

You can check pretty easily by trying to compress some video that's 
flattish (like, looking into cloudy water, say) and some that's moving 
fast in lots of directions (like explosions) and see if you see artifacts.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New wrote:
> where the I frames are basically jpeg, the P frames are differences from 
> the I frames, 

Differences from the previous I frame only, that is... :-)


-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

> Sorry, I expressed myself badly. I was wondering which codices are the 
> better
> ones and which ones to avoid, for the windows platform.

I use the h264 codec for high qualitiy high resolution videos from POV:

http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC

For Windows (and other OSs I guess) you can use a free program called x264 
to make them.

http://en.wikipedia.org/wiki/X264

Or, if you don't like fiddling around with command line options (and there 
are *a lot* for encoders like this) there are plenty of GUIs around.  I 
often use xvid4psp as it contains built-in profiles for making h264 videos 
compatible with things like the PS3, xbox, PSP etc (it can be fiddly trying 
to find out exactly which command line options are needed to make a video 
file compatible with these devices).

Post a reply to this message

>  It's not a question of how difficult it would be to implement. It's a
> question of whether you want povray to support creating lossy output or
> not. Nothing would be more aggravating than starting your final render,
> waiting 50 hours for it to finish, and then notice that you used the
> wrong compression settings and your video looks like absolute crap.
> At least if you have the lossless original frames, you can re-encode
> easily without having to re-render.
>
>  (Another issue is that creating an mpeg video (regardless of the mpeg
> version) is not an unambiguous process. Some mpeg codecs are able to
> create noticeably better image quality at the exact same file sizes
> than other, lower-quality codecs.)

Sure, but of course the option of outputting individual frames shouldn't be 
removed, it could just be another option.  Would be useful, especially for 
short quick-to-render animations.  FOr the Windows version POV could just 
give you a choice to use any currently installed codec (like most other 
video compression programs do), I guess there is a similar thing for other 
platforms.

Post a reply to this message

On Mon, 25 Aug 2008 08:53:55 +0200, "scott" <sco### [at] scottcom> wrote:

>For Windows (and other OSs I guess)

Thanks Scot, you have made me rethink what I meant :)
What I really want is a good codec that almost everyone will have on their
machines. So that I can post small animations here without complaints that the
file cannot be opened. I know that I'm not asking much ;) This is too "on topic"
for this group, I think. 
Having said that I realise that I've not posted in p.b.a for ages as most of my
files are too large to be accepted.
Again thanks.
-- 

Regards
     Stephen

Post a reply to this message

> Having said that I realise that I've not posted in p.b.a for ages as most 
> of my
> files are too large to be accepted.

You can always upload to a website like YouTube and post the link, the 
latest "high quality" setting on YouTube doesn't seem to be that bad.  IMO a 
much better option than crippling your POV work down to 700KB with an old 
codec to ensure compatibility.

Post a reply to this message