Home > Archive > Compression > May 2006 > Am I wise to convert all my AVIs?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Am I wise to convert all my AVIs?
|
|
|
| I am a relative noobie when it comes to video formats.
Recently I downloaded a 700 MB AVI file.
Ass I played it I wanted to jump backwards & forwards in the movie
clip . Often when I did this there was a long pause (5 or more
seconds) and then playback resumed although sometimes it was not
smooth.
I got a converter utility and extracted the MPEG-1 file from the AVI.
The MPEG-1 is about 790 MB, so it is 14% bigger than the AVI. But I
can jump back and forth with no problem and no delay.
For the extra 14% i would say it is worth having the movie as an MPEG
rather than an AVI. Would playback quality of the MPEG-1 be less
than the AVI?
My PC is not fast and maybe I notice those awful delays more than
other people do.
My question is ... what is it about AVI which makes it so popular?
If I have the disk space (and time) then is it unwise to convert all
my AVIs to MPEG-1 or whatever native format the video clip was made
in before it went into AVI form?
There must be many others with a modest PC and who also find AVIs too
demanding.
| |
| Phil Carmody 2006-04-25, 6:56 pm |
| Andy <nomail@nomail.com> writes:
> I am a relative noobie when it comes to video formats.
>
> Recently I downloaded a 700 MB AVI file.
>
> Ass I played it I wanted to jump backwards & forwards in the movie
> clip . Often when I did this there was a long pause (5 or more
> seconds) and then playback resumed although sometimes it was not
> smooth.
>
> I got a converter utility and extracted the MPEG-1 file from the AVI.
> The MPEG-1 is about 790 MB, so it is 14% bigger than the AVI. But I
> can jump back and forth with no problem and no delay.
>
> For the extra 14% i would say it is worth having the movie as an MPEG
> rather than an AVI. Would playback quality of the MPEG-1 be less
> than the AVI?
Was the playback quality less than the AVI?
If it was, then yes.
If it wasn't noticably worse, then it's not noticably worse.
There's _no way_ it can ever be better quality, as moving
between lossy formats almost always doubles your lossage.
> My PC is not fast and maybe I notice those awful delays more than
> other people do.
If your machine is ten years old or less it should be powerful
enough.
> My question is ... what is it about AVI which makes it so popular?
From the specification:
<<<
The Microsoft Audio/Video Interleaved (AVI) file format is a RIFF file specification used with applications that capture, edit, and playback audio/video sequences.
It's popular because it's bundled with the OS that's shipped
with the majority of desktop boxes.
In the same way that AIDS is popular in Botswana - it comes
bundled with 35% of bed-top boxes.
[color=darkred]
> If I have the disk space (and time) then is it unwise to convert all
> my AVIs to MPEG-1 or whatever native format the video clip was made
> in before it went into AVI form?
>
> There must be many others with a modest PC and who also find AVIs too
> demanding.
I find windows too demanding.
For example, playing an AVI on my 2GHz P4 laptop takes 60% of the CPU,
and causes the processor fan to spin so noisily I can't hear the audio.
Playing the same file in linux using xine takes 2% of the CPU.
However, I definitely prefer working with MPEG files. I also get the
feeling that at a given bitrate, they are higher quality than AVIs.
However, that could just be because people who care more about the
settings and the tools they use tend to prefer MPEG too.
Phil
--
What is it: is man only a blunder of God, or God only a blunder of man?
-- Friedrich Nietzsche (1844-1900), The Twilight of the Gods
| |
|
| >> Recently I downloaded a 700 MB AVI file.
On 22 Apr 2006, Phil Carmody<thefatphil_demunged@yahoo.co.uk> wrote:[color=darkred]
>
> Was the playback quality less than the AVI?
> If it was, then yes.
> If it wasn't noticably worse, then it's not noticably worse.
>
> There's _no way_ it can ever be better quality, as moving
> between lossy formats almost always doubles your lossage.
Phil
I had *assumed* that the extraction process performed by my Blaze Media
Pro would remove the AVI wrapper and therefore I thought that the
quality of the un-wrappered "underlying MPEG" (which I would receive as
a file from the extraction process) would not be of a different quality
than the MPEG inside the AVI.
If I have understood you correctly, it seems that I have made some
incorrect assumptions because you refer to extra losses.
I would make a guess that the additional losses you refer to come from
the extractor utility effectively 'playing' the AVI and then re-encoding
that played output into a new MPEG. Presumably the extra losses come
from the compression of the video images into that new MPEG.
Is my understanding now correct or am I getting hopelessly tangled?
Anyone?
:-)
| |
| Willem 2006-04-25, 6:56 pm |
| Andy wrote:
) I had *assumed* that the extraction process performed by my Blaze Media
) Pro would remove the AVI wrapper and therefore I thought that the
) quality of the un-wrappered "underlying MPEG" (which I would receive as
) a file from the extraction process) would not be of a different quality
) than the MPEG inside the AVI.
Highly unlikely, given that most AVIs do not use MPEG-1 compression.
Usually, they use MPEG-4 (you know, divx etc.), sometimes something else.
) I would make a guess that the additional losses you refer to come from
) the extractor utility effectively 'playing' the AVI and then re-encoding
) that played output into a new MPEG. Presumably the extra losses come
) from the compression of the video images into that new MPEG.
)
) Is my understanding now correct or am I getting hopelessly tangled?
Exactly. Furthermore, MPEG-1 is usually of worse quality (per bitrate)
than AVI (with MPEG-4), because it's an older codec, and less
CPU-intensive.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
| |
| Phil Carmody 2006-04-25, 6:56 pm |
| Andy <nomail@nomail.com> writes:
>
> On 22 Apr 2006, Phil Carmody<thefatphil_demunged@yahoo.co.uk> wrote:
>
>
> Phil
>
> I had *assumed* that the extraction process performed by my Blaze Media
> Pro would remove the AVI wrapper and therefore I thought that the
> quality of the un-wrappered "underlying MPEG" (which I would receive as
> a file from the extraction process) would not be of a different quality
> than the MPEG inside the AVI.
If you have some information to support that assumption, then it
may well be a fair one. If you have no such evidence, then it may
well be false. Last time I converted a windows-esque format to
MPEG, the program I used _definitely_ went via a reconstruction
of the video stream. Note that an AVI may contain any number of
different video-compression formats as its payload, more than
there are variations of MPEG. You might be lucky.
> If I have understood you correctly, it seems that I have made some
> incorrect assumptions because you refer to extra losses.
>
> I would make a guess that the additional losses you refer to come from
> the extractor utility effectively 'playing' the AVI and then re-encoding
> that played output into a new MPEG. Presumably the extra losses come
> from the compression of the video images into that new MPEG.
>
> Is my understanding now correct or am I getting hopelessly tangled?
You might be perfectly correct. Use an AVI player to tell you about
the compression format used inside it. If it's claiming to be carrying
MPEG, and it's not some unpleasant bastardisation thereof, then you
might be lucky, it's entirely possible.
Phil
--
What is it: is man only a blunder of God, or God only a blunder of man?
-- Friedrich Nietzsche (1844-1900), The Twilight of the Gods
| |
|
| On 22 Apr 2006, Willem<willem@stack.nl> wrote:
> Andy wrote:
> ) I had *assumed* that the extraction process performed by my Blaze
> Media ) Pro would remove the AVI wrapper and therefore I thought
> that the ) quality of the un-wrappered "underlying MPEG" (which I
> would receive as ) a file from the extraction process) would not
> be of a different quality ) than the MPEG inside the AVI.
>
> Highly unlikely, given that most AVIs do not use MPEG-1
> compression. Usually, they use MPEG-4 (you know, divx etc.),
> sometimes something else.
>
> ) I would make a guess that the additional losses you refer to come
> from ) the extractor utility effectively 'playing' the AVI and then
> re-encoding ) that played output into a new MPEG. Presumably the
> extra losses come ) from the compression of the video images into
> that new MPEG. )
> ) Is my understanding now correct or am I getting hopelessly
> tangled?
>
> Exactly. Furthermore, MPEG-1 is usually of worse quality (per
> bitrate) than AVI (with MPEG-4), because it's an older codec, and
> less CPU-intensive.
Hello Willem, I do not know a whole lot about AVI and MPEG but my
understanding of what you are saying does not line up with the
explanation given on web pages such as the one I quote below.
You seem to be saying that MPEG-4 is often seen as the format inside an
AVI and that may well be true. However GSpot shows that my AVI contains
an MPEG-1 encoded video.
The question I ask is if it is better to have the internal video on its
own or in an AVI wrapper. So in my case it would be an MPEG-1 video
with or without AVI.
And in your case I *think* you would be referring to an MPEG-4 video
with or without AVI.
However AFAICT (and i am a noobie) you and I are referring to MPEG-1 and
MPEG-4 respectively and that is not the same thing as considering the
impact of embedding either in AVI.
If you see what I mean!
Andy
----------------- START WEB PAGE INFO --------------------
http://www.gromkov.com/faq/faq2004-0041.html
-- snipped --
"QUESTION: I am looking for a document or an article that clears up once
and for all what is MPEG4 and what is AVI???"
"ANSWER: The "difference" is that AVI is a container. It's not a
coder/decoder.
AVI contains only information that describes how the data is included in
file and how to decompress video and audio (which codec to use).
MPEG4 - is a compressor. Video data can be compressed with MPEG-4.
AVI can have any type of codec (or no codec even) for compression,
CinePak, Indeo, Huffyuv, etc whilst a "MPEG4 'file'" specifically
denotes any AVI file that uses an MPEG4 codec (i.e,, DivX)
For ex.: AVI may have MPEG-4 as Video, and MP3 as Audio.
AVI may have Cinepak as Video, and WAV PCM as Audio.
----------------- END WEB PAGE INFO --------------------
| |
| Phil Carmody 2006-04-25, 6:56 pm |
| Andy <nomail@nomail.com> writes:
> http://www.gromkov.com/faq/faq2004-0041.html
> -- snipped --
>
> "QUESTION: I am looking for a document or an article that clears up once
> and for all what is MPEG4 and what is AVI???"
>
> "ANSWER: The "difference" is that AVI is a container. It's not a
> coder/decoder.
>
> AVI contains only information that describes how the data is included in
> file and how to decompress video and audio (which codec to use).
>
> MPEG4 - is a compressor. Video data can be compressed with MPEG-4.
>
> AVI can have any type of codec (or no codec even) for compression,
> CinePak, Indeo, Huffyuv, etc whilst a "MPEG4 'file'" specifically
> denotes any AVI file that uses an MPEG4 codec (i.e,, DivX)
With wording like that - no wonder people are  .
Phil
--
What is it: is man only a blunder of God, or God only a blunder of man?
-- Friedrich Nietzsche (1844-1900), The Twilight of the Gods
| |
|
| On 23 Apr 2006, Phil Carmody<thefatphil_demunged@yahoo.co.uk> wrote:
> Andy <nomail@nomail.com> writes:
>
>
> With wording like that - no wonder people are .
>
I think the author's native language is not English. Apart from a
couple of small grammatical errors, I thought it was quite easy to
follow!
From what I understand, he says an AVI contains only information that
describes which codec to use to decompress the video & audio in
itself and, by contrast, MPEG-4 is the name of a specific codec.
However I don't know how right he is in saying that!
Any comments?
| |
| Thomas Richter 2006-04-25, 6:56 pm |
| Hi,
[color=darkred]
> I think the author's native language is not English. Apart from a
> couple of small grammatical errors, I thought it was quite easy to
> follow!
> From what I understand, he says an AVI contains only information that
> describes which codec to use to decompress the video & audio in
> itself and, by contrast, MPEG-4 is the name of a specific codec.
Which is, however, still wrong. MPEG-4 is *also* a container
format. The codec is something like an H.264 or an H.26L. And you can
put this codestream into an AVI, or an MPEG-4. You can also put a JPEG2000
codestream into a MPEG4 container.
AVI is kinna like TIFF: It is a container format that can contain other
formats. TIFF can also enclose JPEGs - though that's rarely used, the natural
container for JPEG is JFIF. The same goes for the MPEG4 container.
Greetings,
Thomas
| |
| Ben Rudiak-Gould 2006-04-25, 6:56 pm |
| Andy wrote:
> As I played it I wanted to jump backwards & forwards in the movie
> clip . Often when I did this there was a long pause (5 or more
> seconds) and then playback resumed although sometimes it was not
> smooth.
Almost all video codecs encode each video frame using some nearby frame(s)
as a reference. The reason is that nearby video frames tend to be similar,
and you can save a lot of space by using a code that says "copy this region
of the image from the reference frame, with minor changes" instead of
reencoding the region from scratch.
This means that in order to decode a certain video frame, you have to first
decode the frame(s) it depends on, and the frame(s) those frames depend on,
and so on. Ultimately this ends with frames that don't depend on other
frames, which are called "key frames" in AVI and "I frames" in MPEG.
I seem to recall that some early versions of the Microsoft MPEG-4 codec
defaulted to inserting a key frame every 10 minutes (or after a scene
change). At 15 fps, that means that you might have to decode up to 9000
video frames to s to a particular location in the file. So video playing
applications have to either:
1. Bite the bullet and decode the frames---means sing is slow.
2. S to the nearest key frame instead of the exact frame that was
requested---fast but inaccurate.
Your slow s times are probably the result of an unfortunate combination
of a large keyframe interval and a player that chose option 1. This has
nothing to do with AVI vs MPEG. Both formats support any keyframe interval
the encoder chooses to use. The encoder you used to convert to MPEG probably
used a small keyframe interval---the typical default for MPEG is every 0.5
seconds or so. You'd get similar results by reencoding to AVI with a small
keyframe interval. Actually, you're probably better off with AVI if you care
about random access, because AVI, unlike MPEG, has an index which makes it
possible to quickly find the exact location of every frame in the file.
Accurate sing in a variable-bitrate MPEG stream is much harder.
Phil Carmody wrote:
> I find windows too demanding.
>
> For example, playing an AVI on my 2GHz P4 laptop takes 60% of the CPU,
> and causes the processor fan to spin so noisily I can't hear the audio.
> Playing the same file in linux using xine takes 2% of the CPU.
This is a problem which you could, if so inclined, troubleshoot and probably
solve. Have you tried different players? Downloading and installing the
latest video drivers for your card? Without knowing the details, my best
guess is that the YUY2 overlay hardware is unavailable under Windows for
some reason, and the player is doing resampling and colorspace conversion in
software. I don't see why you blame this on the OS. I have a hard time
seeing how the OS could be responsible for a problem like this.
-- Ben
| |
| Phil Carmody 2006-04-29, 7:55 am |
| Ben Rudiak-Gould <br276deleteme@cam.ac.uk> writes:
> Phil Carmody wrote:
>
> This is a problem which you could, if so inclined, troubleshoot and
> probably solve. Have you tried different players? Downloading and
> installing the latest video drivers for your card? Without knowing the
> details, my best guess is that the YUY2 overlay hardware is
> unavailable under Windows for some reason, and the player is doing
> resampling and colorspace conversion in software. I don't see why you
> blame this on the OS. I have a hard time seeing how the OS could be
> responsible for a problem like this.
Simple.
The AVI player is a CPU hog.
The AVI player came bundled with the OS.
Therefore the OS is to blame.
Phil
--
What is it: is man only a blunder of God, or God only a blunder of man?
-- Friedrich Nietzsche (1844-1900), The Twilight of the Gods
| |
| cr88192 2006-04-29, 6:55 pm |
|
"Thomas Richter" <thor@mersenne.math.TU-Berlin.DE> wrote in message
news:e2l2ak$73u$1@mamenchi.zrz.TU-Berlin.DE...
> Hi,
>
<snip>
>
> AVI is kinna like TIFF: It is a container format that can contain other
> formats. TIFF can also enclose JPEGs - though that's rarely used, the
> natural
> container for JPEG is JFIF. The same goes for the MPEG4 container.
>
I have often heard this (JFIF being a container for JPEG). however, from how
I understand it, this is not the case. instead, the JFIF info is constained
within the JPEG bitstream (an APP0 marker, containing data starting with a
magic string "JFIF", "JFXX", ...).
from my understanding, the actual container (the markers and other data) is
part of the core JPEG spec, and not JFIF. in my case, the info contained in
the JFIF header (pixel density, thumbnail, ...) was largely irrelevant to my
decoder, so I just ignored it...
to a large degree my decoder does not worry about "display" aspects of the
image, only getting a rectangle of pixels in RGBA layout (err, and that the
image is "right side up", which in my case tends to have pixel 0 in the
lower left corner...).
can anyone clarify on this?...
> Greetings,
> Thomas
| |
| Pete Fraser 2006-04-29, 6:55 pm |
| "cr88192" <cr88192@NOSPAM.hotmail.com> wrote in message
news:c2e6a$4454011c$ca83b3d3$6128@saipan
.com...
> I have often heard this (JFIF being a container for JPEG). however, from
> how I understand it, this is not the case. instead, the JFIF info is
> constained within the JPEG bitstream (an APP0 marker, containing data
> starting with a magic string "JFIF", "JFXX", ...).
I'm not sure I understand.
T.81 doesn't specify a file format; only a codestream format.
However, most applications can understant the "raw" JPEG
codestream format. If you start at SOI (0xFFD8) and end in EOI
(0xFFD9), and use the jpg extension, every application I know
of will open it correctly.
I don't think this was always the case, and JFIF and JFXX
were a way of encapsulating the raw codestream and making
it into a file. JFIF doesn't really add anything (only the APP0
marker), and JFXX typically adds APP0 and a thumbnail.
| |
| cr88192 2006-04-30, 3:55 am |
|
"Pete Fraser" <pfraser@covad.net> wrote in message
news:12582i3282hoo2d@news.supernews.com...
> "cr88192" <cr88192@NOSPAM.hotmail.com> wrote in message
> news:c2e6a$4454011c$ca83b3d3$6128@saipan
.com...
>
>
> I'm not sure I understand.
> T.81 doesn't specify a file format; only a codestream format.
and in nearly all cases the codestream is used as the file-format...
no special headers precede the codestream, and nothing wraps it.
> However, most applications can understant the "raw" JPEG
> codestream format. If you start at SOI (0xFFD8) and end in EOI
> (0xFFD9), and use the jpg extension, every application I know
> of will open it correctly.
>
going around with a hexdump, it appears that this is the coding of pretty
much all the various jpegs anyways. one 'can' use a container format, but
they don't, the container is the jpeg codestream.
so, the file is the codestream afaict.
> I don't think this was always the case, and JFIF and JFXX
> were a way of encapsulating the raw codestream and making
> it into a file. JFIF doesn't really add anything (only the APP0
> marker), and JFXX typically adds APP0 and a thumbnail.
>
yes, there may be other formats, but they are other formats (BMP or TIFF
with a jpeg payload, or other combinations, but these are different formats,
with different extensions, eg, BMP or TIFF...).
note that the JFIF header comes after the SOI marker:
SOI (0xFF 0xD8)
APP0 (0xFF 0xE0)
U16BE Len (eg: 0x10)
'JFIF\x00'
...
also, note that the both the marker structure and the SOI and APP0 markers
are defined in T.81 (albeit the APP# markers' contents are left undefined).
imo, JFIF does not count as a container format under my definitions, if
anything, it is an extension. the format is itself just the codestream
dumped into a file...
under my definitions, the container for jpeg is jpeg itself...
>
| |
|
| >> >> "ANSWER: The "difference" is that AVI is a container. It's
[color=darkred]
[color=darkred]
>
On 25 Apr 2006, Thomas Richter wrote:[color=darkred]
>
> Which is, however, still wrong. MPEG-4 is *also* a container
> format. The codec is something like an H.264 or an H.26L. And you
> can put this codestream into an AVI, or an MPEG-4. You can also put
> a JPEG2000 codestream into a MPEG4 container.
>
> AVI is kinna like TIFF: It is a container format that can contain
> other formats. TIFF can also enclose JPEGs - though that's rarely
> used, the natural container for JPEG is JFIF. The same goes for the
> MPEG4 container.
Thomas/anyone, just so I can be ultra clear, are you saying that...
(1) MPEG-4 is a name of a definition of the format of a software
container for video files.
(2) The video files inside the MPEG-4 container may be in one of a
variety of different video formats.
(3) One of the formats which the video file inside an MPEG4 could be in
is a format which is also called MPEG-4.
Is the above undertanding correct?
If so then is there a way to be more specific about the precise name of
the standard which describes MPEG-4 as
(a) a container
(b) a playable video file?
-------
WHAT I HAVE READ TO TRY AND UNDERSTAND THIS ...
(A) There are too many items described in the Wiki for me to be able to
untangle what you have referred to above. My understanding stopped soon
after "MPEG-4 consists of several standards—termed "parts".
See http://en.wikipedia.org/wiki/MPEG-4
(B) There is a similar list in question 6 of the MPEG-4 FAQ at
http://tinyurl.com/oxvel
(C) The following web page is the closest I came to a rigorous but
basic statement of MPEG-4.
http://streamingmediaworld.com/vide...EG4/index2.html
It refers to concepts such as:
"The wavelet compression of MPEG-4 ... Wavelets dynamically
allow servers to reduce bitmap file sizes (which also affect
quality) when working with lower bandwidths"
"For Rich Media, MPEG-4 constructs everything out of media
objects, such as video/audio streams, stills, text, etc. ...
MPEG-4 can blend the capabilities of Flash, VRML, Shockwave
and digital video into a single file format"
" Version 1 of MPEG-4 offered nine video and four audio
profiles [designed to work on different platforms]. Version 2
added seven more video and four audio profiles. These
profiles create subsets for different marketing options."
But I can't link this to to the "ultra clear" statements (1), (2) & (3)
above.
(D) The other thing I came across is this document with its mind-
blowing detail: "ISO/IEC JTC1/SC29/WG11 CODING OF MOVING PICTURES &
AUDIO"
N4668. MARCH 2002 http://www.m4if.org//resources/Overview.pdf
| |
|
| On 25 Apr 2006, Ben Rudiak-Gould<br276deleteme@cam.ac.uk> wrote:
> Andy wrote:
>
> Almost all video codecs encode each video frame using some nearby
> frame(s) as a reference. The reason is that nearby video frames
> tend to be similar, and you can save a lot of space by using a code
> that says "copy this region of the image from the reference frame,
> with minor changes" instead of reencoding the region from scratch.
>
> This means that in order to decode a certain video frame, you have
> to first decode the frame(s) it depends on, and the frame(s) those
> frames depend on, and so on. Ultimately this ends with frames that
> don't depend on other frames, which are called "key frames" in AVI
> and "I frames" in MPEG.
>
> I seem to recall that some early versions of the Microsoft MPEG-4
> codec defaulted to inserting a key frame every 10 minutes (or after
> a scene change). At 15 fps, that means that you might have to
> decode up to 9000 video frames to s to a particular location in
> the file. So video playing applications have to either:
>
> 1. Bite the bullet and decode the frames---means sing is
> slow. 2. S to the nearest key frame instead of the exact
> frame that was
> requested---fast but inaccurate.
>
> Your slow s times are probably the result of an unfortunate
> combination of a large keyframe interval and a player that chose
> option 1. This has nothing to do with AVI vs MPEG. Both formats
> support any keyframe interval the encoder chooses to use. The
> encoder you used to convert to MPEG probably used a small keyframe
> interval---the typical default for MPEG is every 0.5 seconds or so.
> You'd get similar results by reencoding to AVI with a small
> keyframe interval. Actually, you're probably better off with AVI if
> you care about random access, because AVI, unlike MPEG, has an
> index which makes it possible to quickly find the exact location of
> every frame in the file. Accurate sing in a variable-bitrate
> MPEG stream is much harder.
That is a very good explantion. Thank you.
What you write seems to make a lot of sense to me and I am grateful for
you to have taken the trouble to post it.
I am still struggling with MPEG-4 as a container and as an encoding
format. See my post a few moments ago today in this thread to Thomas
Richter.
Date: Thu, 11 May 2006 11:43:44 +0100
Message-ID: <Xns97C077501A49674C1H4@127.0.0.1>
| |
| Thomas Richter 2006-05-11, 7:55 am |
| Hi Folks,
> On 25 Apr 2006, Thomas Richter wrote:
>
>
>
> Thomas/anyone, just so I can be ultra clear, are you saying that...
>
> (1) MPEG-4 is a name of a definition of the format of a software
> container for video files.
Still ? (-; Yes, I see. MPEG is, for first, the name
of a standardization group within ISO. They are maintaining a
standard, called MPEG-4, which defines a container file-format intended
to be used for video.
> (2) The video files inside the MPEG-4 container may be in one of a
> variety of different video formats.
Yes, Video codestreams.
> (3) One of the formats which the video file inside an MPEG4 could be in
> is a format which is also called MPEG-4.
Not quite. You can put codestreams into an MPEG-4 container that are
*also*, but not exclusively discussed within the MPEG community. MPEG-4
can, for example, contain the H263L video encoding standard - an ITU
standard. They can also contain Motion JPEG2000, an ISO standard, where
the details of how this wrapping has to be done (which box types are
used, etc...) is then layed out in just another standard, JPEG2000
part-12. (Yikes!)
Thus, much of the confusion comes probably from the fact that those
standards are often the result of a discussion between different
working groups, and different standardization groups.
(JPEG is an ISO standard, but also an ITU standard, for example.)
>
> Is the above undertanding correct?
>
> If so then is there a way to be more specific about the precise name of
> the standard which describes MPEG-4 as
>
> (a) a container
> (b) a playable video file?
MPEG-4 *defines* a container standard is more apropriate. That is, one
part of MPEG-4 is the container file format. (Namely, more or less
copied over from Apple's QuickTime, IIRC, which is again a bastardized
version of the Electronic Arts IFF container definition. Yes, really).
It *also* defines what can be put in there. AVI also defines a container
file format, but AFAIK only that.
> -------
>
> WHAT I HAVE READ TO TRY AND UNDERSTAND THIS ...
>
> (A) There are too many items described in the Wiki for me to be able to
> untangle what you have referred to above. My understanding stopped soon
> after "MPEG-4 consists of several standards—termed "parts".
> See http://en.wikipedia.org/wiki/MPEG-4
Huge standards are often split into parts. As I'm not in the MPEG but
in the JPEG community, I rather make an example from JPEG2000 if you
allow. Part-1 defines both a file format - a container - and a
codestream to be put into this container. Part-4 defines how to test
software against the standard, part-9 defines how to make these images
interactively browsable with minimum data transfer, part-12 how to put
them into MPEG-4 containers as frames and so on.
>
> (B) There is a similar list in question 6 of the MPEG-4 FAQ at
> http://tinyurl.com/oxvel
>
> (C) The following web page is the closest I came to a rigorous but
> basic statement of MPEG-4.
> http://streamingmediaworld.com/vide...EG4/index2.html
> It refers to concepts such as:
>
> "The wavelet compression of MPEG-4 ... Wavelets dynamically
> allow servers to reduce bitmap file sizes (which also affect
> quality) when working with lower bandwidths"
Well, wavelets in MPEG-4... They are only used to compress patterns, not
the images. MPEG-4 here means: "There is a part of the full MPEG-4
standardization efford where...". The file format is just one part of
it, though I don't know which part. IIRC, it was also part-12. (JPEG2000
part-12 and MPEG-4 part-12 were given the same part number to keep the
confusion level... uhm... low?)
> "For Rich Media, MPEG-4 constructs everything out of media
> objects, such as video/audio streams, stills, text, etc. ...
> MPEG-4 can blend the capabilities of Flash, VRML, Shockwave
> and digital video into a single file format"
Just another part of MPEG-4: Segmentation of images into objects
and a descriptive/parametric method of defining a scene. IIRC, there's
no consumer codec which would handle these things.
>
> " Version 1 of MPEG-4 offered nine video and four audio
> profiles [designed to work on different platforms]. Version 2
> added seven more video and four audio profiles. These
> profiles create subsets for different marketing options."
A "profile" is yet another thing: It is the restriction of possible
coding options to a suitable subset. For example, a profile of MPEG-4
might (remember, I'm not a MPEG guy) restrict which kind of video
streams can be put into the MPEG-4 container, or which coding options
can be used for them. (I.e. how many B frames, etc...)
There is not a single codec out in the wilderness which can decompress
a full profile MPEG-4 file - no chance. IIRC, something like the
advanced simple profile is most often used, but please don't ask me
of what this profile defines in detail. One would need to read the
MPEG-4 standards (note the plural) to get an idea.
So long,
Thomas
| |
|
| On 11 May 2006, Thomas Richter<thor@math.TU-Berlin.DE> wrote:
> Hi Folks,
>
-- big snip --
[color=darkred]
>
> There is not a single codec out in the wilderness which can
> decompress a full profile MPEG-4 file - no chance. IIRC, something
> like the advanced simple profile is most often used, but please
> don't ask me of what this profile defines in detail. One would need
> to read the MPEG-4 standards (note the plural) to get an idea.
>
> So long,
> Thomas
Thomas, you are a real gent for posting your explanations. Thank you
kindly.
I had thought knowledgeable people had left the net and those in
favor of unintelligent utterances had largely taken over.
However I can see this is not entirely so. I'm glad to see there are
still islands of sanity, expertise & helpfulness. Good man. Thanks.
|
|
|
|
|