 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Andrew Coppin <orp### [at] btinternet com> wrote:
> What's an MPEG-4 codec when it's at home? I thought a codec is a codec...
That's like saying that an image format is an image format... You certainly
can tell the difference between, for example, an image in BMP format and
in JPEG format?
And you probably can tell the difference between a WAV file and an MP3
file?
An MPEG-4 codec is a codec which implements (all or part of) the MPEG-4
standard.
The version 4 of the MPEG standard is more developed and then the
version 2 (which eg. DVDs use), which is more developed than the
version 1 (which is what most .mpg files are).
Typically MPEG-4 compresses video to something like 1/4 or 1/8 of the
size of the equivalent MPEG-1 video (with the same visual quality).
Another advantage of MPEG-4 is that the compression quality is not
highly dependant of the image resolution (unlike in MPEG-1 where
doubling the resolution invariably doubles the size of the file).
(In fact, increasing the resolution increases the quality of the video
at the same bitrate. I know this from experience.)
> I was under the (mistaken?) impression that there are legal restrictions on
> the use of DivX...
What legal restrictions?
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> In article <3F715D07.7AEFED32@onwijs.com> , Remco de Korte
> <rem### [at] onwijscom> wrote:
>
> >> Interestingly, Windows XP SP1 happens to be what I've got... so where the
> >> heck did I get these codecs from? Hmm... weird!
> >
> > I have access to two XP systems, one did have the codec (the older one)
> > the other didn't. This is a developer's nightmare, especially if you try
> > to avoid installing codecs along with your application. It seems that it
> > that last thing is unrealistic to hope for...
>
> If you have software (aka games) that use these ancient codecs, chances are
> the software also accesses hardware directly. Hence, it wouldn't run
> anyway. Or do you really want your operating system to get more bloated
> with useless outdated junk codecs than it already is?
>
> Thorsten
>
This isn't really about MY operating system. I'm just looking for a way
to make sure that a movie file will play on as many (windows) systems as
possible, preferrable all that haven't be tampered with too much.
Besides, I don't think current OS's will get bloated much more by a
couple of old codecs. These codecs are miniscule compared to all the
redundant functionality that comes with XP for instance. But that's
beside the point :)
Remco
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3f71da21@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> Typically MPEG-4 compresses video to something like 1/4 or 1/8 of the
> size of the equivalent MPEG-1 video (with the same visual quality).
Here is what three of the ISO committee members who developed H.264 (aka
MPEG-4 AVC) reported (get the report on http://bs.hhi.de/~wiegand/JVT.html)
as the "Average bit-rate savings compared with various prior "decoding
schemes", which is about equivalent to the size reduction of the result
video stream, but not taking into account the audio stream:
Codec MPEG-4 ASP H.263 HLP MPEG-2
H.264/AVC 38.62% 48.80% 64.46%
MPEG-4 ASP - 16.65% 42.95%
H.263 HLP - - 30.61%
And this is summarized by them as "Although not discussed in this article,
the bit-rates for TV or HD video (at broadcast and DVD quality) are reduced
by a factor of between 2.25 and 2.5 - when using H.264/AVC coding."
For reference, notice that MEPG-2 at CIF (352*288 pixels) size results in
about the same datarate as an MPEG-1 datastream. Or in short, MEPG-2 does
not offer much of an advantage over MPEG-1 at the *same* resolution. This
is not really surprising as the MPEG-2 encoding is a superset of the MEPG-1
encoding. The main advantage of MPEG-2 is that it specifies much higher
resolutions of up to 1920*1152 at 30 non-interlaced (aka progressive) frames
per second, which then yield a datastream of about 80 MBit/s!
On the other hand, the original intend of MEPG-4 (without AVC) was to
provide a lower-resolution way of transmitting high-quality video data over
low-bandwidth connections. hence, it is not absolutely correct to say
MEPG-4 is "more developed" than MEPG-2, it is simply better targeted for a
different application domain.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3F72C11E.A02E1940@onwijs.com> , Remco de Korte
<rem### [at] onwijscom> wrote:
> This isn't really about MY operating system. I'm just looking for a way
> to make sure that a movie file will play on as many (windows) systems as
> possible, preferrable all that haven't be tampered with too much.
I understand, but I would suggest to simply not use codecs that old for
anything new even if they are most likely on many systems. In five years
they will be gone for sure once M$ has once again changed all its APIs...
> Besides, I don't think current OS's will get bloated much more by a
> couple of old codecs. These codecs are miniscule compared to all the
> redundant functionality that comes with XP for instance. But that's
> beside the point :)
True :-)
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> hence, it is not absolutely correct to say
> MEPG-4 is "more developed" than MEPG-2, it is simply better targeted for a
> different application domain.
I see.
I have to admit I don't know too much about MPEG-2 and how it differs
from MPEG-1.
However, from my experience I can say that MPEG-4 differs from MPEG-1
by an enormous amount. Some important differences I know of:
- In MPEG-1 the types of frames are fixed to a certain pattern
(eg. IBBBPBBBPBBB) regardless of the movie contents. In MPEG-4
keyframes can be located anywhere (and are usually located at
places where they are most needed, ie. where the image changes
a lot).
- In MPEG-1 the image is divided into fixed-sizes squares which are
compressed in a similar way as JPEG. In MPEG-4 the image is divided
into completely free-shaped parts.
- The MPEG-1 format supports only a very limited amount of frame rates
(I really don't understand why). In MPEG-4 it's completely free.
- AFAIK the quality of MPEG-1 is highly dependant on the resolution
of the video. That is, a larger resolution needs a larger bitrate
to preserve the same image quality. In MPEG-4, however, image
resolution is irrelevant: Video resolution doesn't matter, you
can always compress to the same bitrate and get about the same
image quality. In fact, if you use a larger resolution, the image
quality will increase, not decrease, at the same bitrate (this is
from empirical experience; I don't have any technical proof of this).
- A 200 Megs MPEG-1 will compress to something like 50 Megs MPEG-4
with no important decrease in image quality. (Again, by empirical
experience.)
In the same way, if you try to make an MPEG-1 with the same file size
as the MPEG-4, the image (and sound) quality will be highly degraded.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Andrew Coppin" <orp### [at] btinternetcom> wrote in
news:3f6f4b76$1@news.povray.org:
>> - Get the png vfapi plugin from p.b.u
>
> Erm... huh???
>
This is a must have for every pov animator.
http://news.povray.org/povray.binaries.utilities/15796/
>
> Didn't know TMPGEnc can work on single frames... I thought it only
> encodes AVIs?
>
>
It works wonderfully with stills. You choose which frame to start at
instead of an avi file.
--
Tom
_________________________________
The Internet Movie Project
http://www.imp.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > Didn't know TMPGEnc can work on single frames... I thought it only
> > encodes AVIs?
>
> It works wonderfully with stills. You choose which frame to start at
> instead of an avi file.
Oh right... will have to try that then!
> >> - Get the png vfapi plugin from p.b.u
> >
> > Erm... huh???
>
> This is a must have for every pov animator.
>
> http://news.povray.org/povray.binaries.utilities/15796/
Doesn't seem to have the binary... Looks useful though! Tell me, without
this pluggin, what file types can TMPGEnc already read?
Thanks.
Andrew.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3f731503@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> I see.
> I have to admit I don't know too much about MPEG-2 and how it differs
> from MPEG-1.
Every MPEG-2 decoder is also a fully functional MPEG-1 decoder.
> However, from my experience I can say that MPEG-4 differs from MPEG-1
> by an enormous amount. Some important differences I know of:
>
> - In MPEG-1 the types of frames are fixed to a certain pattern
> (eg. IBBBPBBBPBBB) regardless of the movie contents. In MPEG-4
> keyframes can be located anywhere (and are usually located at
> places where they are most needed, ie. where the image changes
> a lot).
>
> - In MPEG-1 the image is divided into fixed-sizes squares which are
> compressed in a similar way as JPEG. In MPEG-4 the image is divided
> into completely free-shaped parts.
Which doesn't mean it isn't turned into squares again. Almost every
compression based on the DCT uses the 8*8 DCT (the DV standard allows a
special variation of the 8*8 DCT to produce better results with interlaced
input data). This common DCT size is also why transcoding, especially from
DV to MPEG-2 (and back) is so fast. The DCT step can be completely skipped.
> - The MPEG-1 format supports only a very limited amount of frame rates
> (I really don't understand why). In MPEG-4 it's completely free.
>
> - AFAIK the quality of MPEG-1 is highly dependant on the resolution
> of the video. That is, a larger resolution needs a larger bitrate
> to preserve the same image quality.
The codec algorithms simply don't depend on the frame dimensions, thus one
can of course mess around with this, but if the codec at the same time
restricts the MEPG-1 bitrate, you of course the low quality results.
One interesting side-note here should be how both MPEG-2 as well as DV (you
know the format you find on all digital video cameras as of last year, Sony
is now pushing I-frame only MPEG-2 to sell new gear, the least in the
semiprofessional product range above about US$2K) handle the aspect ratio.
If you buy a "widescreen" DVD, you don't somehow get more data, all you get
is a differently scaled image. On a DVD the frame resolution is always the
MEPG-2 main profile, which is 720*480 for NTSC and 720*576 for PAL. To make
a 16:9 aspect ratio out of this, the frames are simply scaled. Due to the
"interpolation"-like nature of the DCT one doesn't notice. Much like one
doesn't notice a VHS tape only can store about 240 pixels horizantal
resolution (the thing you find as "240 lines" or something similar in your
VCRs datasheet).
Anyway, knowing that the resolution is only 720*480 for NTSC and 720*576 for
PAL is important when making a backup copy of a DVD as for optimal results
one wants to use ie.e 240 for NTSC or 288 for PAL, especially when making
the backup copy with MPEG-4.
> In MPEG-4, however, image
> resolution is irrelevant: Video resolution doesn't matter, you
> can always compress to the same bitrate and get about the same
> image quality. In fact, if you use a larger resolution, the image
> quality will increase, not decrease, at the same bitrate (this is
> from empirical experience; I don't have any technical proof of this).
The main benefit of MPEG-2 and MPEG-4 is that they offer good support for
varioable bitrate encoding. How effective the variable bitrate encoding is
can be seen whenever you have a film with a long flight over a diverse
ground, i.e. a city or diverse landscape. These scenes also make a great
test case for codec capabilities.
> - A 200 Megs MPEG-1 will compress to something like 50 Megs MPEG-4
> with no important decrease in image quality. (Again, by empirical
> experience.)
Notice that this also to a major part depends on the MPEG-1 codec you use.
There are really *serious* differences between MPEG codecs (regardless if
this is MPEG 1, 2, 4 etc, also ture for i.e. JPEG and DV). All these
compression standards have one thing in common: They do *not* define the
details of the algorithms to be used. They only define a format of the
encoded data and how to interpret it. That is why a simply software MEPG-2
relatime encoder will probably produce low quality, high bitrate video while
an advanced, hardware accelerated reatime encoder will produce a muss lower
bitrate and a much higher quality. At the same resolution! On the other
hand, a "slow" multipass software encoder can usually produce significantly
better results but taking a lot more time (than realtime).
> In the same way, if you try to make an MPEG-1 with the same file size
> as the MPEG-4, the image (and sound) quality will be highly degraded.
Of course. For good summary about all this, also try
<http://bmrc.berkeley.edu/research/mpeg/faq/mpeg2-v38/faq_v38.html#tag54>
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> In article <3F72C11E.A02E1940@onwijs.com> , Remco de Korte
> <rem### [at] onwijscom> wrote:
>
> > This isn't really about MY operating system. I'm just looking for a way
> > to make sure that a movie file will play on as many (windows) systems as
> > possible, preferrable all that haven't be tampered with too much.
>
> I understand, but I would suggest to simply not use codecs that old for
> anything new even if they are most likely on many systems. In five years
> they will be gone for sure once M$ has once again changed all its APIs...
>
You seem to know a lot about this :)
(more then me, but that doesn't say much)
What I wonder is: with all the different codecs around and the trouble
that is causing, is the size of the codec really such a big problem?
Wouldn't it for instance be ideal if the codec was incorporated in the
moviefile itself? Would this be at all possible? Is it possible to use a
codec if it isn't already installed?
Cheers!
Remco
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> What I wonder is: with all the different codecs around and the trouble
> that is causing, is the size of the codec really such a big problem?
> Wouldn't it for instance be ideal if the codec was incorporated in the
> moviefile itself? Would this be at all possible? Is it possible to use a
> codec if it isn't already installed?
Mmm... that sounds good... until you start to think about the fact that you
would need a different implementation of the program for each type of
hardware / operating system, etc...
(There's alwaysd JAVA I suppose ;-)
((I'm JOKING by the way!))
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
