| MPEG problem [message #22209] |
Wed, 25 October 2000 00:00  |
Carl G Zimba
Messages: 1
Registered: October 2000
|
Junior Member |
|
|
I am trying to create MPEG's using MPEG_OPEN,MPEG_PUT,MPEG_SAVE,MPEG_CLOSE
suite. The problem is that the resulting mpegs are not the intended size,
smaller in both x and y directions. The problem is a bit worse in the
x-direction. Individual images look as if they were rebinned to the smaller
size with a resulting distortion of the color table. Same images were
written to gif and jpeg image files and gif movie file with no problems.
Does anyone have any suggestions?
Carl G. Zimba, Ph.D.
Photons UnLimited
84 Oxford Street
Arlington, MA 02474
781.648.6270
photons@mediaone.net
|
|
|
|
| Re: MPEG problem [message #26829 is a reply to message #22209] |
Mon, 01 October 2001 09:36  |
Rick Towler
Messages: 821
Registered: August 1998
|
Senior Member |
|
|
The codec nightmare.....
From the IDL docs:
"Note - When creating MPEG files, you must be aware of the capabilities of
the MPEG decoder you will be using to view it. Some decoders only support a
limited set of sampling and bitrate parameters to normalize computational
complexity, buffer size, and memory bandwidth. For example, the Windows
Media Player supports a limited set of sampling and bitrate parameters. In
this case, it is best to use 352 x 240 x 30 fps or 352 x 288 x 25 fps when
determining the dimensions and frame rate for your MPEG file. When opening a
file in Windows Media Player that does not use these dimensions, you will
receive a "Bad Movie File" error message. The file is not "bad", this
decoder just doesn't support the dimensions of the MPEG."
WMP's MPEG codec handles other dimensions and bitrates but you'll have to
experiment to find out what works.
What you really need to do is drop MPEG all together. If you are doing
8-bit color animations, take a look at Mark Hadfield's page on scientific
animations at http://katipo.niwa.cri.nz/~hadfield/gust/software/animation/
and try using .flc. If you are doing 16/24 bit animations I highly
recommend looking into the intel indeo video 4 or 5 codecs (free), or the
sorenson codecs available in quicktime pro ($30). These codecs provide by
far the best quality/compression rates of any of the common, free (or mostly
free), legal codecs available.
If you are interested in compatibility then stick with indeo video 4. There
is a Xanim decoder available for this format. In windows it plays out of
the box on 98/ME/2K machines (if not, the codec is free). I don't know how
the Mac handles it out of the box but the codec is free. The quality is the
same as the version 5 codec but it encodes around 20-30% slower. The indeo
5 codec is free too but I don't believe that there is a decoder available
for Xanim. Also, .avi files encoded with version 5 *MAY* be able to be
decoded with version 4 codecs but I haven't been able to test this. The
intel codecs are available here: http://www.ligos.com/indeo
If you go this route you will need a program to stitch together and encode
your frames. I am using the windows shareware program videomach
(http://www.gromada.com/) but I am sure there are others available.
If you don't have access to a windows machine to do the encoding I still
recommend dropping MPEG and finding some linux tools to encode the frames in
a better format.
Did I mention that you should quit using MPEG?
-Rick
----- Original Message -----
From: "Marc Schellens" <m_schellens@hotmail.com>
Newsgroups: comp.lang.idl-pvwave
Sent: Monday, October 01, 2001 1:51 AM
Subject: MPEG problem
> I got a problem here with the IDLgrMPEG object.
> When I generate mpeg files under linux, I can play them
> with mpeg_play from linux, but not with the windows media
> player.
> Has anyone made similar experiences or even knows a workaround?
>
> thanks,
>
> :-) marc
"Marc Schellens" <m_schellens@hotmail.com> wrote in message
news:3BB82EA8.F5A0280C@hotmail.com...
> I got a problem here with the IDLgrMPEG object.
> When I generate mpeg files under linux, I can play them
> with mpeg_play from linux, but not with the windows media
> player.
> Has anyone made similar experiences or even knows a workaround?
>
> thanks,
>
> :-) marc
|
|
|
|
|
|
| Re: MPEG problem [message #26901 is a reply to message #22209] |
Tue, 02 October 2001 15:33 |
Rick Towler
Messages: 821
Registered: August 1998
|
Senior Member |
|
|
I will preface my comments with the understanding that each codec has
strengths and weaknesses and there are many tradeoffs that one must make
when deciding on a codec to use for an animation. Different people will
have different sets of requirements and thus a preference for one codec over
another. My comments are based on a set of experiments that I did a few
months back encoding 24 bit, full-motion animations for both general
consumption and for presentations. I considered two audiences: the "general
public" accessing animations via the web and my lab members who use
animations extensively in their presentations. For each audience I set
criteria to which the codecs were evaluated against.
General Public: defined as colleagues & students first, then the web public
at large.
Criteria: accessibility, file size, quality
I feel that the most important criteria when disseminating animations to a
large audience is accessibility. The goal being that the vast majority of
web site visitors can view our animations by pointing and clicking. No
codec downloads or external viewers needed. Also, I concentrate on Windows
and Mac platforms but if I can include everyone I will. File size, while
important, is secondary since we assume that most colleagues will have
decent connections to the internet. Although quality is last on the list, I
still lean heavily towards the best quality I can muster although with
longer animations quality loses out. In this case I have MPEG-1, Cinepack,
and the Indeo 3.2 or 4.5 codecs to choose from since decoders for these
animation types ship with most PC's. In all cases Cinepack is out since it
just can't compete with the newer codecs. MPEG-1 at 300-600 KB/sec is a
contender along with Indeo 4.
Presentation: animations not meant to be downloaded. Played off of the HD
or CD.
Criteria: quality, quality, and quality.
When I know that an animation will be played on a specific machine that I
have access to, I concentrate on quality only. Quality being image quality
AND playback quality. Within reason, I don't care about file size and since
I have access to the laptop I can make sure that the appropriate codec is
installed and working. Here I can use any codec but most likely will use
Intel Indeo 5 codec.
> There's quite a lot of information here, but what is the REASON Rick
> so adamantly recommends dumping MPEG?
My issue is not so much with MPEG itself, but is a combination of MPEG and
it's implementation in IDL (* apologize for not making that clear in my
first post*). I ran into the problems of playback and quality and got sick
of re-running my application 10+ times to tune the codec parameters to get
the final file I desired. That is if I EVER got the quality I desired. I do
not fault RSI for their implementation, i just find it far easier to create
the individual frames and use software packages designed for this specific
task to stitch together the final product.
It certainly depends on your application. If you are writing a program that
will allow your user to create an animation automagically you don't have a
lot of options. But in this context you can probably tune your codec
parameters beforehand so the user doesn't have to do it at run time. In our
lab, we're not creating a single polished application and each visualization
is different from the last. In our case I can create better animations
quicker using external software packages with the option to use a variety of
codecs.
> IDL's MPEG routines use MPEG-2
> and you are free to use non-standard (non-Microsoft-approved) sized
frames.
IDL can encode both MPEG-1 and MPEG-2.
> Various versions of Windows media player have problems with MPEG-2 or
frame
> size, as Rick pointed out. This is more an indication of Microsoft's
policy
> of not supporting open standards than a problem with MPEG itself.
So true....
> The standard
> workaround is to use VMPEG, an mpeg player for windows that doesn't have
those
> limitations. It's also worth noting that IDL's MPEG routines have
compromised
> and set the compression/quality to something like 75% (last I checked on
it).
> I use mpeg_encode (Stanford freely available encoder), for more
flexibility.
>
My issue is accessability. If I am making this available via the web, I
want most any person with a computer and a decent internet connection to be
able to view the animation. Many people will not, or can not install
external software to view them. If an animation will not play in WMP I am
severly limiting my audience and filling my inbox with "your animation
doesn't work" emails.
> RSI has always supported multiple platforms and open standards, maybe
that's
> why they chose to use MPEG. MPEG is best suited to live video
> (Motion Picture ... EG) and animations are often better achieved using
other
> formats (Mark Hadfields discussion of .flc makes some good points, I'd
> recommend visiting this web site).
Yes, .flc is very good for 8 bit animations where the majority of the the
pixels in a frame don't change from one image to the next. A very bad
application would be full motion animations where every pixel would be
different from one frame to the next. You also need an external player :(
> Quicktime is a collection of mostly proprietary codecs which, even if
> you can get a free decoder, you need to pay for an encoder (I can think of
only
> one exception). The quality can be better than MPEG, but the compression
may be
> lower, I think this really depends on the content and particular codec.
> AVI can give very good compression and high quality, it is however locked
to
> the Windows platform and you'll need to pay (as far as I know anyways) for
> anything that will produce an AVI.
Although you do have to pay for Quicktime Pro, it is $30 US which is quite
reasonable. Quicktime Pro ships with something like 12-15 codecs most of
which are of no use for sci animations. The Sorenson codecs are the
exception, generating very high quality animations with high compression
rates. The only problems I have with quicktime is that viewers must have
the player installed (the accessability issue) and that playback, at least
on windows machines, is sub-par. My guess is that Quicktime for windows is
not optimized for the x86 architecture. But, if your audience is primarily
Mac users then the Sorenson codecs shipped with QT is worth consideration.
AVI is not "locked to the windows platform". AVI files are played and
generated on Mac, UNIX and windows PC's. Also, there are AVI codecs that
are available for free but I don't know if free encoders are available for
UNIX. The Intel Indeo codec I was recommending is available for free for Mac
and PC.
> It's my observation, that you'll have to keep paying, as the AVI codecs
keep
> changing and it seems older codecs stop being supported. I'm interested to
> hear about the free Indeo codec, I visited Ligos web site, it looks like
the
> encoder is available only as a demo, is that correct Rick? What about
> VideoMach, their web page mentions "the commercial" version, what's the
> difference? Do you really produce quality AVI's with free software?
You do not have to keep paying (if you pay at all). The idea is to choose a
encoder that creates files that are able to be decoded on your "average pc"
be it Windows, Mac or Unix. *I think* the Indeo video 4 decoder ships with
all Windows machines going back to at least Win98 and at least QT4 on the
Mac (I say I think because it is hard to find machines that are "pure", that
is where no software has been installed beyond the default OS installation,
where I can test this. My current testing procedure is to send a link to
some people in the building whose OS incarnations I know and ask them if the
file plays. Flawed at best but it is what I can do given that I don't have
3 or 4 machines to dedicate to this cause.) The same decoder is available
compiled for many UNIXs as a module for Xanim. The IV4 codec isn't
changing.
From the ligos website: "Indeo codecs and software are available to
end-users and developers on an individual basis at no cost."
About VideoMach: I don't know what the difference is between the commercial
and non-commercial versions. I think the two versions are the same and the
developer is giving us non-commercial types a discount. And yes, for the
$19 US I paid for VideoMach it, along with my free Indeo Codecs, produces
what I think are very high quality animations. I also recommend VirtualDub
a free as in beer and speech "post processing" package which last I knew was
compiled only for win32. VirtualDub will not combine frames into an
animation (so you still need something like VideoMach) but it can slice and
dice, add sound tracks and even apply video "filters". It also makes for a
great converter. There are probably other free or nearly free tools out
there. I just found these and stopped looking since they filled my needs at
the time.
>
> If you are committed to Microsoft Windows operating system, probably
Rick's
> advice is sound: trying to use open standards will be an uphill battle. I
do
> have to applaud RSI's decision not to cave to this pressure, as in the GIF
> issue. Anyways, I hope Marc got the answer he was looking for.
I think you misunderstood. I do not have any issue with RSI's inclusion of
MPEG in IDL. All I am saying is that IDL can't be everything to everybody
and in the case of creating animations I feel this task is best accomplished
using other software packages. I was really urging Marc to stop wasting his
time with the built in IDL MPEG routines and to try other options (if he had
a windows or Mac machine at his disposal). I also have nothing against MPEG.
I have created some fine animations that were encoded with MPEG and will use
it again. But even when I decide on MPEG as my codec I use an external
package to encode the frames.
-Rick
>
> On Mon, 1 Oct 2001 09:36:43 -0700, Rick Towler <rtowler@u.washington.edu>
wrote:
>> The codec nightmare.....
>>
>> From the IDL docs:
>>
>> "Note - When creating MPEG files, you must be aware of the capabilities
of
>> the MPEG decoder you will be using to view it. Some decoders only support
a
>> limited set of sampling and bitrate parameters to normalize computational
>> complexity, buffer size, and memory bandwidth. For example, the Windows
>> Media Player supports a limited set of sampling and bitrate parameters.
In
>> this case, it is best to use 352 x 240 x 30 fps or 352 x 288 x 25 fps
when
>> determining the dimensions and frame rate for your MPEG file. When
opening a
>> file in Windows Media Player that does not use these dimensions, you will
>> receive a "Bad Movie File" error message. The file is not "bad", this
>> decoder just doesn't support the dimensions of the MPEG."
>>
>> WMP's MPEG codec handles other dimensions and bitrates but you'll have to
>> experiment to find out what works.
>>
>> What you really need to do is drop MPEG all together. If you are doing
>> 8-bit color animations, take a look at Mark Hadfield's page on scientific
>> animations at
http://katipo.niwa.cri.nz/~hadfield/gust/software/animation/
>> and try using .flc. If you are doing 16/24 bit animations I highly
>> recommend looking into the intel indeo video 4 or 5 codecs (free), or the
>> sorenson codecs available in quicktime pro ($30). These codecs provide
by
>> far the best quality/compression rates of any of the common, free (or
mostly
>> free), legal codecs available.
>>
>
>
>> If you are interested in compatibility then stick with indeo video 4.
There
>> is a Xanim decoder available for this format. In windows it plays out of
>> the box on 98/ME/2K machines (if not, the codec is free). I don't know
how
>> the Mac handles it out of the box but the codec is free. The quality is
the
>> same as the version 5 codec but it encodes around 20-30% slower. The
indeo
>> 5 codec is free too but I don't believe that there is a decoder available
>> for Xanim. Also, .avi files encoded with version 5 *MAY* be able to be
>> decoded with version 4 codecs but I haven't been able to test this. The
>> intel codecs are available here: http://www.ligos.com/indeo
>>
>> If you go this route you will need a program to stitch together and
encode
>> your frames. I am using the windows shareware program videomach
>> (http://www.gromada.com/) but I am sure there are others available.
>>
>> If you don't have access to a windows machine to do the encoding I still
>> recommend dropping MPEG and finding some linux tools to encode the frames
in
>> a better format.
>>
>> Did I mention that you should quit using MPEG?
>>
>> -Rick
>>
>>
>> ----- Original Message -----
>> From: "Marc Schellens" <m_schellens@hotmail.com>
>> Newsgroups: comp.lang.idl-pvwave
>> Sent: Monday, October 01, 2001 1:51 AM
>> Subject: MPEG problem
>>
>>
>>> I got a problem here with the IDLgrMPEG object.
>>> When I generate mpeg files under linux, I can play them
>>> with mpeg_play from linux, but not with the windows media
>>> player.
>>> Has anyone made similar experiences or even knows a workaround?
>>>
>>> thanks,
>>>
>>> :-) marc
>> "Marc Schellens" <m_schellens@hotmail.com> wrote in message
>> news:3BB82EA8.F5A0280C@hotmail.com...
>>> I got a problem here with the IDLgrMPEG object.
>>> When I generate mpeg files under linux, I can play them
>>> with mpeg_play from linux, but not with the windows media
>>> player.
>>> Has anyone made similar experiences or even knows a workaround?
>>>
>>> thanks,
>>>
>>> :-) marc
>>
>>
>
>
> --
> Steve S.
>
> steve@NOSPAMmailaps.org
> remove NOSPAM before replying
|
|
|
|
|
|
| Re: mpeg problem [message #39500 is a reply to message #39335] |
Fri, 21 May 2004 12:49 |
hjalti
Messages: 13
Registered: October 2003
|
Junior Member |
|
|
"Rick Towler" <rtowler@u.washington.edu> wrote in message news:<c82pv7$ah4$1@nntp6.u.washington.edu>...
> "Hjalti Sig" wrote
> ...
>> I have a funny problem regarding mpeg files made in idl. To improve
>> the quality of the file I have set the iframe_gap parameter to 4 in
>> MPEG_OPEN. Otherwise the the image is rather coarse. The file plays
>> fine using gtv on linux. But on windows machines, using real player
>> or windows media player, the image quality deteriorates as you play
>> the file. I.e., the image quality is fine in the beginning, but in the
>> end it is a total mess. Does anyone have an explanation or a fix of
>> this problem?
>
> Use a different codec. There are other codecs that do better than MPEG.
> DivX works well and codecs are available for linux, windows, and mac.
> Google the group and you should find a number of posts on this subject.
>
> As for an explanation, how are you setting the other parameters? Have you
> tried playing the file in another application (such as winDVD which uses its
> own MPEG decoder?).
>
> -Rick
Thank you for your reply, Rick
I have found out that this problem has not directly to do with the
iframe_gap parameter, but the file size (my files were 32 Mb). If
fewer timesteps are included in my animation the file it plays fine in
windows media player and real player. However some dvd players (like
winDVD) are able to play the large files.
Regards, Hjalti
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
