emosun wrote:

The boards integrated gpu is a 2mb s3 virge which has the same exact results as the 8500. I actually just now took the 8500 out to make sure the virge still performed the same and it does.

A Virge is not a Trio64. Like the Radeon 8500, it has quite advanced features for accelerating MPEG video.
My point remains: your claim that video playback is done entirely on the CPU is false, when you throw such cards in the mix. If you were to play back MPEG video entirely on the CPU, you'll find that a Pentium-1 would struggle. A Pentium 133 can barely do VideoCD quality MPEG (352x288, 25 fps) in software, but only if you don't scale it. Once you want to play it fullscreen at a resolution of more than say 640x480 (no matter what the source video's resolution is), you'll become bottlenecked.

I use a Software dvd player (New Motion 95) on my Pentium 75 MHz and is was doing fullscreen in color with around 15 fps.

Or fullscreen in Black and White with 25 fps.

Later i bought a Mirco MediaView with HardwareMpegDecoder.

The Software Player was then used on a Pentium 200MMX.

BTW: It also depends if you read the File from CD-Rom (mostly in Pio-Mode) or from HDD with DMA.
DMA has less CPU usage so more CPU-Power is free for the decoding.

Scali wrote:

Try replacing the Radeon 8500 with a 'Pentium 1-era' card like the S3 Trio64, and you'll probably notice a considerable drop in performance on video replay.

Scali wrote:

A Virge is not a Trio64. Like the Radeon 8500, it has quite advanced features for accelerating MPEG video.

I understand what you're saying however....

If both gpu's perform the exact same , it means the gpu has no effect on the quality of the video.

Scali wrote:

your claim that video playback is done entirely on the CPU is false

actually what i said was

emosun wrote:

But as stated earlier the cpu is whats under load not the gpu.

Once again. The gpu's perform the same. Meaning the load is primarily now on the cpu being the limiting factor and not the gpu.

Scali wrote:

If you were to play back MPEG video entirely on the CPU, you'll find that a Pentium-1 would struggle.

So you're saying if i used a worse gpu than the onboard video the pentium 1 era machine came with , it would be worse. I agree.

I get what you're saying. but THIS pentium 1 machine (along with millions of others) shipped with mpeg acceleration that assists the cpu. Once that acceleration is in use , the cpu will have to do SOME other task that isn't specifically acceleration. Whatever task that is , is what's maxing out the cpu. I imagine it's most likely the loading and unloading of system ram to deal with the large file sizes and small amount of system ram.

So I'm well past the mpeg decoding being any sort of problem as both gpu's can handle it. however i can see the cpu usage hitting 100% and causing the video to lag vs hitting 95% and the video playing smoothly. So I know that the limitation is the cpu.

emosun wrote:

If both gpu's perform the exact same , it means the gpu has no effect on the quality of the video.

Yes, but they likely don't. It's just that you can't get better than full framerate/full quality. One GPU may still need 90% of its capacity, while the other does it at 20%. You can't tell from just looking at the framerate.

emosun wrote:

actually what i said was

What you said was this:

emosun wrote:

Well it seems that most video cards that have at least 4 or more mb can playback pretty much anything and the real bottleneck is the pentium 1 itself. Being that the cpu has to do all the work loading and unloading the system ram with information quickly.

I took that to mean that "the CPU has to do all the work", as in, you were not factoring in hardware acceleration. The actual bandwidth required for MPEG-compressed video is not very high for a Pentium-class system, considering that MPEG was mainly designed to reduce bandwidth, so video could be stored on relatively low-bandwidth media like a VideoCD, which is 1150 kbit. That amounts to about 1150/8 = ~144 kB/s. Not a big deal for a Pentium-1, where the PCI bus can do about 133 MB/s, and system ram can do even more. You could say it is negligible.

The amount of work that the CPU has to do, is very much dependent on what video card you use.
Eg, a video card that can perform hardware scaling in RGB space will greatly reduce the bandwidth requirements of the CPU, because it only has to decode the video in-place and can send the unscaled data to video memory.
A video card that can performn YUY2->RGB may somewhat reduce the bandwidth requirements (YUY2 packs 4 pixels in 12 bytes, where most cards of the time used 32-bit RGB formats), and also reduces some of the arithmetic workload of the CPU.
A card like the Radeon 8500 can even perform the computationally expensive iDCT operation, meaning the CPU barely has to do anything in terms of decompression.

emosun wrote:

But as stated earlier the cpu is whats under load not the gpu.

They are both under some load. Where the balance is exactly, depends on a lot of factors.

emosun wrote:

Once again. The gpu's perform the same. Meaning the load is primarily now on the cpu being the limiting factor and not the gpu.

What do you mean with 'perform the same'?
As I said, if both play back a 25 fps video at 25 fps, they 'perform the same', but that doesn't mean much.
A modern system will still 'perform the same', because the video just isn't faster than 25 fps.

Besides, even if neither reaches the 25 fps level, but both get the same framerate (say 20 fps), that still doesn't prove they are running into the same limits.

emosun wrote:

So I'm well past the mpeg decoding being any sort of problem as both gpu's can handle it. however i can see the cpu usage hitting 100% and causing the video to lag vs hitting 95% and the video playing smoothly. So I know that the limitation is the cpu.

It would help if people understood that the 'CPU usage' metric in OSes is useless. It doesn't tell you WHAT it's doing. Hence it also measures a loop waiting for the video card to finish decoding the data as '100%'.
It's certainly possible to create an MPEG video that exceeds the bandwidth available in the video acceleration circuit of the GPU. In which case you'd still get lag and '100% CPU', but it's not the CPU that's the problem.
I think in this case you'll find that you'll run into the limits of the Virge much more quickly than the Radeon 8500, given that the 8500 was designed to handle MPEG-2 and DVD-quality video in hardware.

ok , you aren't helping please stop. thanks

Sammy wrote:

BTW: It also depends if you read the File from CD-Rom (mostly in Pio-Mode) or from HDD with DMA.
DMA has less CPU usage so more CPU-Power is free for the decoding.

Hey this actually helped a bit. At least for .mov files.

The mov files play back much better . I didn't even know what DMA was , but I enabled it on the drive and now they seem much better. I'll have to play with the mixtures of settings for .mov files but I might be able to get standard def which will be interesting.

emosun wrote:

ok , you aren't helping please stop. thanks

Why am I 'not helping'?
Because I'm not telling you what you want to hear?
I'm telling you how MPEG decoding and video acceleration work.
I can't help it if facts conflict with your personal ideas.

Scali wrote:

ratco wrote:

3. Codecs that can be played using Pentium or 486 (I doubt a 386 can play movies). Although I have seen a 286 playing a fullscreen video on youtube (custom software made and it was not really all that great).

Even an 4.77 MHz 8088 with CGA can play movies, with the right software: https://www.youtube.com/watch?v=MWdG413nNkI
It's all about finding an acceptable balance between image/sound quality, framerate, resolution, filesize and processing requirements.

Phantasy is indeed an awesome thing. 😉
Let's see what someone did accomplish on Windows 2.03 :

BadApple PV ASCII Under Windows 2.03
https://www.youtube.com/watch?v=pJ4vn7ejAmI

OK, using ASCII art might perhaps not be the most original idea here, but the result is quite nice.
I'm really surprised someone spent so much time and effort for early Windows.

Jo22 wrote:

Phantasy is indeed an awesome thing. ;) Let's see what someone did accomplish on Windows 2.03 : […]
Show full quote

Phantasy is indeed an awesome thing. 😉
Let's see what someone did accomplish on Windows 2.03 :

BadApple PV ASCII Under Windows 2.03
https://www.youtube.com/watch?v=pJ4vn7ejAmI

OK, using ASCII art might perhaps not be the most original idea here, but the result is quite nice.
I'm really surprised someone spent so much time and effort for early Windows.

Fun, but no more than that.
That would in no way work on an actual machine from the Windows 2.03-era. Back then, high-resolution graphics were still extremely slow, and the fact that it's 'text' doesn't matter. The CPU had to render every pixel individually. You might as well just use regular bitmapped graphics, it would be no slower.

Scali wrote:

Why am I 'not helping'? Because I'm not telling you what you want to hear? I'm telling you how MPEG decoding and video accelerat […]
Show full quote

emosun wrote:

ok , you aren't helping please stop. thanks

Why am I 'not helping'?
Because I'm not telling you what you want to hear?
I'm telling you how MPEG decoding and video acceleration work.
I can't help it if facts conflict with your personal ideas.

ok message received . please stop. thanks

emosun wrote:

ok message received . please stop. thanks

I asked you a question: Why do you accuse me of 'not helping'?
If you're going to throw accusations around, the polite thing to do is to at least explain what this is all about.

I tried VCD playback on a P100 for my Video for CPUs thread (scroll to near the bottom of the first post). I wasn't able to get more than 18fps, even after I retested using ActiveMovie with no scaling.

I was trying to play hi-color 352x240/30p @ 1.15mbps, with 224kbps MP2 audio.

did You try something like chromatic mpact2?

Video accelerator cards usually had custom circuitry to speed up certain aspects of the MPEG compression algorithms, such as the iDCT transform, YUV color space transforms, or motion compensation. GPU load wasn't really relevant at the time in the context of video decode offloading.

I believe the Savage was the first S3 card to implement mocomp and iDCT in hardware. Add-on daughtercards were available for some older models. The R200 GPU had hardware blocks for YUV overlay, iDCT offloading, and mocomp. I remember claims of shader based filtering at the time as well, but that information is more murky.

Standard Def Steve wrote:

I tried VCD playback on a P100 for my Video for CPUs thread (scroll to near the bottom of the first post). I wasn't able to get more than 18fps, even after I retested using ActiveMovie with no scaling.

I was trying to play hi-color 352x240/30p @ 1.15mbps, with 224kbps MP2 audio.

wow that's a hell of a thread!

it's nice to see your results scale to mine. even if it's just one sample size. be fun if you broke out the p100 and did some fine tuning.

what I'm getting right now is 284x378 30fps at 1.8mbps. I'm not settling for anything less than perfect playback and surprisingly it is doing it. I essentially want the framerate to be a non issue so the playback resembles a non struggling machine.

I did discover however the machine can play back 480x360 @ 30 perfect when the audio is completely disabled. Turns out the audio card in the machine couldn't handle the audio due to it just being much older than the integrated audio. I switched to the integradted audio and was able to gain some more overhead for bitrate. So it's currently playing that 284x378 at 30fps with zero compression distortion and it looks really good.

If i can find a way to make the audio extremely lightweight , the machine should be able to play 360p video and audio with ease.

emosun wrote:

ok , you aren't helping please stop. thanks

He's trying to help you by actually pointing out how things really work. That you get good results if you pair a good quality high-end fairly modern video card with an older processor is logical, *since video cards were improved to better handle video when it turned out that the run-of-the-mill video cards couldn't handle it very well and caused the CPU to choke on processing video*, meaning you had to use either a MPEG decoding daughter card or a dedicated hardware decoding card - both of which were very expensive back in the 1990s, especially if you wanted good quality. Putting that ability directly onto the video card solved that issue.

Also understand that video is not some magical thing where the quality keeps on going up when you use better equipment - it's encoded with certain settings, and can't go beyond those settings when playing (ignoring player tricks).

BTW, really old TV tuners did not actually capture video (well, you could capture individual frames using a special program), they just put the TV input through to the monitor using a passthrough cable, bypassing the CPU and most of the computer entirely. Actual TV capture cards were expensive monsters that required a pretty fast computer to start with.

If you were to go back to a proper period-correct Pentium I system with a consumer-level VGA card that is period correct for the Pentium processor you use and an amount of RAM that is not ridiculously high for the time (let's say 64 Mb RAM max.) you would get much worse results.
I remember playing with video encoding back in the mid- to late 1990s on a 486 with a 1Mb Trident video card (WfW 3.11, too 🤣 ), specifically rendering animated AVI video from a shareware raytrace program without any form of hardware acceleration 🤣 , and it was a royal pain in the behind. First you realise that all of those high resolutions and color modes your program can do are completely useless on your own system because of a lack of processing power and speed, then after you select the worst resolution and lowest color options 🤣 it still takes ages to render everything and produce the video. On the other hand, when I saw my extremely simple futuristic spaceship (IIRC, a blue torus and some spheres) make a quarter circle motion at about 15 FPS in 10 seconds, it gave a tremendous feeling of satisfaction 😊 (...and made me promise that I would never again try something similar on a system not capable of it... 😵 )

yawetaG wrote:

He's trying to help you by actually pointing out how things really work. That you get good results if you pair a good quality high-end fairly modern video card with an older processor is logical, *since video cards were improved to better handle video when it turned out that the run-of-the-mill video cards couldn't handle it very well and caused the CPU to choke on processing video*, meaning you had to use either a MPEG decoding daughter card or a dedicated hardware decoding card - both of which were very expensive back in the 1990s, especially if you wanted good quality. Putting that ability directly onto the video card solved that issue.

Getting back to the original question:
Which format, bitrate, resolution etc is best depends a lot on what video card you use.
If you want video formats that can work on ANY Pentium 1, then you'd have to take the lowest common denominator, which means no hardware acceleration at all.
If on the other hand you use a video card that has hardware support for MPEG-2, then you can probably play back even DVD quality video on a Pentium 1, since the video card does all the work anyway. The bitrate is still only ~10 mbit, so not that shocking for a decent Pentium 1.

Does anyone remember the Motion Pixels codec and player from 1996?
Its minimum system requirements were 486 DX 66Mhz/8 MB RAM/128K Cache/1 MB VESA Local Bus Video card/4x CD-ROM/SB card or compatible/DOS 5.0/Win3.1
The recommended specs: Pentium 75 MHz/16 MB RAM/256K Cache/1 MB PCI Video card/DOS 6.0/Win3.1, 3.11 or 95

The last version of the player even supports the 3dfx chipset:

MP Objects™: 3Dfx Support by Christian Huygen Ok gamer fans, Motion Pixels now supports the 3Dfx chipset. Using the Bilinear t […]
Show full quote

MP Objects™: 3Dfx Support
by Christian Huygen
Ok gamer fans, Motion Pixels now supports the 3Dfx chipset. Using the Bilinear textured filtering on your 3Dfx card you can have very quick 640x480 16-bit interpolated video. It looks killer! David and I have been watching this upcoming and rising 3D standard for the gaming market and have now taken advantage of it.

Motion Pixels does require that the GLIDE2X.DLL driver version 2.43 to have been previously installed on your system to get it to work. If it's not there and we detect a 3Dfx chip Motion Pixels will let you know. If your 3Dfx card manufacture does not already have it installed then you can download it at:

http://www.3dfx.com/software/download_glidert.html

All you need to download is the Glide 2.43 runtime drivers. Please install it and you will be ready to go! If for some reason the Motion Pixels cannot see the 3Dfx card please type in 'chdwtestpci' on your keyboard without any menus pulled down from the AWARE32.EXE player and make sure that the VendorID=121A and the DeviceID=0001. When you first start the fullscreen playback using the 3Dfx option located in the playback style dialog under the fullscreen section, you will notice that the first time you play the video you will get the 3Dfx splash logo. If you would like to disable the logo from ever appearing (I personally think its cool, and it also lets you know that you are playing on the 3Dfx card) you can add the following line to your AUTOEXEC.BAT file and restart you computer:

SET FX_GLIDE_NO_SPLASH=1

If you always want to know that you are playing fullscreen video on the 3Dfx card, or just want to show off to your friends that you are playing fullscreen video on your 3Dfx card then you can add the following to your MVICODEC.INI located in your windows subdirectory:

[MVI1] Enable3DfxShamelessPlug=1

If you want to really see the difference that bilinear textured filtering makes on the 3Dfx card you can disable it so that it just looks like 4x pixel enlargement by adding the following to your MVICODEC.INI located in your windows subdirectory:

[MVI1] Disable3DfxBilinearFilter=1
Gamers get ready for fullscreen in your face 3Dfx video!

Source: https://web.archive.org/web/19981212031121/ht … tionpixels.com/

Here are the players I found, the 2.7x from an old Magazine CD and the 5.02 from the archive of the official website:

A video sample can be found at https://samples.ffmpeg.org/mvi/

The codec was used on the Sirius MovieCD collection from 1998, an alternative to MPEG VideoCD:
https://en.wikipedia.org/wiki/MovieCD
https://web.archive.org/web/19981205120055/ht … ww.moviecd.com/

A bunch of those are on ebay, if anyone wants to give it a try and report back:
http://www.ebay.com/sch/i.html?_odkw=movie+si … sirius&_sacat=0

Now that looks pretty cool. I do have a voodoo2 but id like to see how well it does on its own at first. It does mention the video will only be 16bit so that may explain the higher resolutions

Hey Emosun, interesting work! I eagerly await the results of this as I'd love to be able to play full length movies on my humble Packard corner PC. 😁

Oh btw what are you using to encode the videos? I'm a total noob to all this so I hope when you're done you release a tutorial! 🤣