Subject:
|
Re: Some questions about MPEG 1 standards (long)
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Wed, 14 Nov 2001 21:53:49 GMT
|
Viewed:
|
721 times
|
| |
|
|
Thanks for the free computer lesson.
I'll continue for with the standard that I made.
In lugnet.cad, Todd Thuma writes:
> In lugnet.cad, Eduardo Vazquez Harte writes:
> > Well for now I decided to continue with this great format since is
> > compatible with a lot of platforms for "Atari ST to Sega Dreamcast"
> > including PC's "unix to mac".
> > So I just found a way to get a lot of people to view my anymations without
> > problems of compatiblity isues or speed isues but what I whould like to know • is
> > what type of quality are these bit rate settings?
> >
> > Data rate:
> > ----------
> >
> > Profile nmae : Byte rate : Bit rate :
> > --------------:------------:-----------:
> > MPEG-1 : 140 kbytes : 1125 kbits:
> > --------------:------------:-----------:
> > 28Kbits modem : 3 kbytes : 28 kbits:
> > --------------:------------:-----------:
> > 300Kbytes CDx2: 300 kbytes : 2400 kbits:
> > ----------------------------------------
> > 600Kbytes CDx4: 600 kbytes : 4800 kbits:
> > ----------------------------------------
> >
> > now I need to have an idea of quality so tell me what bit rate is near vhs, • dvd.
> >
> > I hope some understands what I'm asking.
>
> Eduardo,
>
> Unfortunately, it is not as easy as that. Bit rate is a poor measure of quality
> because it doesn't actually determine quality all by itself. I worked in a
> educational laboratory where we studied video over the web issues and I learned
> a lot about quality and standards.
>
> One thing you should know is that the higher the bit rate, the better the
> quality, but this only works in general. I will try to provide an example. Bit
> mapped files or BMP allocates one byte per pixel of each image. In order to
> make a large image you need the same number of bytes as there are pixels. This
> compression is poor because every pixel on the screen is represented by some
> data. Several image compression schemes have been created that eliminate the
> need to represent every pixel with a byte because some of the bytes are repeats
> of the pixels around them and so can be eliminated by indicating how many
> repeats there are rather than representing each pixel. The most common
> compression schemes are now as Graphic Interchange Format (GIF) and Joint
> Potographic Experts Group (JPG). (But you probably already know this, so why am
> I telling you this?) I turns out that these compression schemes have been the
> foundation for video data.
>
> Both GIF and JPG throw out information in an effort to save room and lower the
> file size. Video is handled much the same way. In some compression processes
> the entire frame is not coded, only the parts of the frame that move or change
> from one frame to the next (a reason transitions add a lot to the file size of
> a movie). Before I get to deep into compression schemes though you need to
> understand the two factors that effect video quality.
>
> In video the most important things to consider is the resolution and
> compression. Resoulution is the size of the video picture, i.e. 320x240,
> 640x480 and 720x480. There are other resolutions but these are the most popular
> with the last one being mini-DV resolution. Typically the higher the resolution
> the larger the file size and the larger the bit rate will have to be inorder to
> transmit that much data without dropping frames. A dropped frame is one that
> was not delivered in time for the stream to play it, i.e. it arrived after its
> cue to be on stage.
>
> Compression is the next most important consideration to make. By compression I
> refer to the CODEC, the compression and decompression standards that enable the
> video file to be made smaller for transmission but then be able to represent
> the data in a way that doesn't suffer in the decompression.
>
> Currently, there are many options: (1) MPEG, (2) Quicktime, (3) Real, (4)
> Microsoft Media Player. There are others but I will limit the discussion to
> these. In my humble opinion, MPEG is the best over all three becuase of its
> ability to be used in multiple environments, web and TV mediums. It is a little
> large for file delivery for anything longer than 5 minutes, but one of the MPEG
> Levels, #2, is the standard that DVD is based upon. But for a project that
> needs both Web and or CD-Rom based implementation with TV media options (such
> as VHS, DVD, or Satellite) then MPEG is clearly the best choice.
>
> As for the other CODECs, Apple is clearly the winner. Real is great if your not
> interested in the visual aspects of the presentation. Select Audio as a
> priority and who cares if the talking head arrives. If your trying to see the
> visual content though then you really need Quicktime. As evidence of what I am
> saying, what are movie trailers typically delivered in? Quicktime!(A quick note
> about Quicktime. To do it right you need to send everything through Media
> Cleaner Pro. Failure to do so leaves your files way to large. I am not exactly
> certain how Media Cleaner improves on the compression of the Quicktime CODEC,
> but anyone that has made video in both formats, .mov without MCP and .mov with
> MCP, knows what I am talking about.)
>
> If your interested in Media Player from Microsoft, go for it. It really doesn't
> do anything better than the others, but supposedly more people have the player
> than Real or Quicktime. I guess that's becuase they ship Media Player with the
> operating system which uses it for everything from MP3 playing to video. Media
> Player also has the least trouble continuing to run a stream. I am not certain
> why this is but Real seems to freak out when things are not right. Media Player
> just keeps standing by until content arrives. The only times Media Player has
> failed for me happened when the operating system froze. As for Quicktime, the
> only problem I have ever had is when it needed a different version of the
> player than the one I had.
>
> A side note about MPEG. The new MPEG-4 is out and has been for some time. In
> the next year or so you will begin seeing products, software and hardware, that
> work with MPEG-4. This compression is better than MPEG-2 and will allow larger
> files over smaller bandwidth. It will allow video to be a practical option of
> content delivery over the Internet. It will be really key for handheld video on
> small palm pilots and things.
>
> As for video bit rate, these compression techniques provide different bit rates
> based upon the resolution chosen and the type of video. The standard in
> Intranets (note the "a") is 500kbps or 500 kilobits per second (yes bites,
> transmission rates are measure in bits not bytes, and yes that means your
> getting 8 times less than you thought). Typically the in house ethernet connect
> is 100 megabites per second (if your company isn't dust off the resume). A 0.5
> Mb/sec video load on the network is typically not going to crash the system (if
> it does think switches not hubs) and that video quality is MPEG-1 or MPEG-2.
> Compare that to the transmission speed of a 26 Kbps (yes kilobits) modem and
> you begin to undestand the difficulties of good video over a modem. I have
> worked with some VBrick products that do multicast IP video and its amazing. IP
> selectable video, multicast by a server, sending numerous Video selections all
> over a 100Mb Intranet Network at less than 500 Kbps speeds and send full
> screen, full 30 frame per second video. It uses Media Player which introduces
> some artifacting seen on larger monitors with larger resolutions.
>
> I connect from home using a DSL modem and my speeds exceed 1.5 Mb/sec and I can
> usually view video with very little download time or streaming difficulties.
> Friends of mine are not so lucky with their cable modems speeds that are
> advertized at 1 mbps. The reason is simple, cable modems are hubs and DSL
> modems are switches. If you don't know the difference it can be boiled down to
> this, hubs split the bandwidth coming in among the users. A 100 MB hub with 10
> connections provides 10 MB per connection. If you should need 11MB tough luck.
> A switch provides the available transmission speeds to the users on demand. If
> there are 10 connections on a switch not everyone needs all 10 MB of their
> connection at anyone time, so you can get 50MB when no one else is using it.
>
> The cable modem is a shared connection amongst you neighbors. While the TV
> transmission is on a different part of the RF spectrum from the Data
> transmission you still share the capacity with others. As more people get
> online in your neighborhood and begin to exploit their "High Bandwidth"
> Connection, your connection slows down. A friend with a performance metter has
> found speeds after dinner can drop below 56 Kbps modem speeds.
>
> As for DSL, the connection is a little more independent. I do share the
> connection at the level of the phone switch in the routing box in my
> neighborhood, but from the box to my house it is all me in the data. Besides
> the increased security, I enjoy nearly 1.5 MB sustained data rates as can be
> seen by my performance measures.
>
> I haven't tried to access a 500kbps stream of video content yet, but this is in
> the not too distant future for testing purposes.
>
> So to conclude a lengthy response. Bit rates are important becuase different
> CODECS can support different bit rates as a streaming video. Unfortunately, the
> key factors to decide are resolution and compression. These issues are usually
> determined by the intended audience and means of delivery. If your have to
> deliver over the Internet, then you need small. If your deliverying in house o
> n a WAN, LAN or VPN then you can bump the size and quality up just make certain
> your IT and network people have no blocks on file size (past experience).
>
> I would love to offer a dicotomous test for you to delineate the "organism" of
> delivery, but it would be lengthly and ultimately incomplete. The best advice I
> can give is set a standard and then adhere to it after extensive testing proves
> the standard is adequate for your needs.
>
> Hope tis helps!
>
> Todd
|
|
Message is in Reply To:
 | | Re: Some questions about MPEG 1 standards (long)
|
| (...) is (...) dvd. (...) Eduardo, Unfortunately, it is not as easy as that. Bit rate is a poor measure of quality because it doesn't actually determine quality all by itself. I worked in a educational laboratory where we studied video over the web (...) (23 years ago, 14-Nov-01, to lugnet.cad)
|
5 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
