| 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
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
