| MPEG problem [message #26837] |
Mon, 01 October 2001 01:51  |
![marc schellens[1] is currently offline](theme/default/images/xoffline.png.pagespeed.ic.XRkd1fkXye.png "marc schellens[1] is currently offline")
marc schellens[1]
Messages: 183
Registered: January 2000
|
Senior Member |
|
|
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 #26899 is a reply to message #26837] |
Tue, 02 October 2001 16:32  |
nobody@nowhere.com (S
Messages: 55
Registered: July 2001
|
Member |
|
|
Rick-
thanks for sharing your (apparently extensive) knowledge of the
subject. I spent a lot of time on creating animations (a few years ago).
At the time making a movie that would play on Windows platform meant
spending a lot of money and choosing "my way or the highway"-style
incompatiblity with other OS's. It used to be MPEG was an "unknown filetype"
on Windows. I think the fact that the tables have turned (non-Windows
OS's are perceived as incompatible) is a testament to the prolific growth of
that OS and it's impact on modern computing. This is probably getting too
off-topic for this ng anyways, I'll check out the resources in your post and
re-consider this topic.
On Tue, 2 Oct 2001 15:33:48 -0700, Rick Towler <rtowler@u.washington.edu> wrote:
> 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.
>
I stand corrected on this issue :^) !!!
>> 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
>
>
--
Steve S.
steve@NOSPAMmailaps.org
remove NOSPAM before replying
|
|
|
|
| Re: MPEG problem [message #26910 is a reply to message #26837] |
Tue, 02 October 2001 10:21 |
nobody@nowhere.com (S
Messages: 55
Registered: July 2001
|
Member |
|
|
Rick & Marc:
There's quite a lot of information here, but what is the REASON Rick
so adamantly recommends dumping MPEG? The answer to Marc's original post is
most likely a problem with Windows Media Player. IDL's MPEG routines use MPEG-2
and you are free to use non-standard (non-Microsoft-approved) sized frames.
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. 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.
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). MPEG is also non-proprietary, so you don't
have to pay for it and you can even examine the code to try to understand how
it works. 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.
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?
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.
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
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
