DOS ain't dead

Having a little spare time, I compiled Mplayer from a recent SVN snapshot using my DJGPP 2.04/GCC 4.4.4. building environment. No network or DVD video support enabled yet, and for sound I used WSS by Shigeaki Sakamaki instead of Allegro (at least WSS has support for some AC97 cards, I plan to add HDA support too). Until I put the few needed patches in order, I provide, for testing purposes, only the binaries. You may download them from here.

---
Glory to God for all things

Many thanks for providing this new build. Testing so far has been mixed. Getting rid of the obsolete Allegro is most welcome, however I tested on an old system with the AC97 integrated audio VT8237 chipset without success. MPLAYER detected the AC97 as present, but froze. Thinking this was an IRQ or DMA problem, I fiddled awhile with BIOS settings and pulled all the PCI cards from the system, and still couldn't get audio working...

EDITED to add that testing with your new build I'm getting a fatal VESA error on my old 1GB netbook with Intel 82945GM integrated graphics which is VBE 3.0 compatible. Something about a page-flip error. Any way around this? Strangely, this identical setup works on Mik's 2008 build.

IDH or HDA audio support with some patches will be even more wonderful...

I wonder if there is a way around the 2GB file-size limit? I think I posted about this topic a couple of years ago (around the time of mik's DJGPP ports of Mplayer), and the consensus then seemed to be a patch to unsigned DWORD integers was possible. At least unsigned 32-bit integers would make the limit 4GB which would play MOST single-layered DVDs and/or .VOBs all the way though!

> I wonder if there is a way around the 2GB file-size limit? I think I posted
> about this topic a couple of years ago (around the time of mik's DJGPP
> ports of Mplayer), and the consensus then seemed to be a patch to unsigned
> DWORD integers was possible. At least unsigned 32-bit integers would make
> the limit 4GB which would play MOST single-layered DVDs and/or .VOBs all
> the way though!

Since he's using DJGPP 2.04 beta to compile, it has the 4 GB patches (according to CWS) though I've never tried it. AFAICT, you need a suitable OS (MS-DOS 7 ???), and FreeDOS still doesn't support > 2 GB files, even on FAT32, where it's able to be supported. At one time Eric Auer said it was "fairly trivial" to maybe? fix, but he never publicly hacked on it. I'm honestly not sure how many kernel devs still exist, and even Eric is "out of town" (or whatever) for another two or three weeks. You could always try the mailing list (or even e-mail Pat directly, who knows ...).

(Hope that helps explain it somehow, but I doubt it.)

---
Know your limits.h

> Many thanks for providing this new build. Testing so far has been mixed.
> Getting rid of the obsolete Allegro is most welcome, however I tested on an
> old system with the AC97 integrated audio VT8237 chipset without success.
> MPLAYER detected the AC97 as present, but froze. Thinking this was an IRQ
> or DMA problem, I fiddled awhile with BIOS settings and pulled all the PCI
> cards from the system, and still couldn't get audio working...

Which are the Vendor ID and the Device ID of your VT8237 card?

> EDITED to add that testing with your new build I'm getting a fatal VESA
> error on my old 1GB netbook with Intel 82945GM integrated graphics which is
> VBE 3.0 compatible. Something about a page-flip error. Any way around this?
> Strangely, this identical setup works on Mik's 2008 build.

Page flipping error means that VESA Set Display Start failed. I will try to fix this problem on my next build.

---
Glory to God for all things

> Having a little spare time, I compiled Mplayer from a recent SVN snapshot

Seems to work out of the box ! At least on this AMD K6 600 MHz with 64 MB RAM.
Picture seems very sharp and sound is good with my SB16 soundcard.
Later today I will run it on my other machine that only has an onboard ac* soundcard.

It was able to use the same config file that I use for Mik's version. :)

>
> Which are the Vendor ID and the Device ID of your VT8237 card?
>

The vendor ID is VIA and the Device ID is 0x3059. It's an integreated AC97 audio on the mb chipset.

> Page flipping error means that VESA Set Display Start failed. I will try to
> fix this problem on my next build.

Thanks, it may have something to do with my turning off native-pixel stretching, and mapping the display 1:1. When I disabled that, your MPLAYER build worked on my netbook. But, Mik's build did work either with, or without my 1:1 pixel-mapping enabled.

Your build has worked flawlessly on my other systems (except for audio, one of those has an Ensoniq ESS1371 (Ensoniq AudioPCI) card, the other has Intel High Def. Audio built. into the chipset onboard. Video quality and speed seem very good!

> > Having a little spare time, I compiled Mplayer from a recent SVN
> snapshot
>
> Seems to work out of the box ! At least on this AMD K6 600 MHz with 64 MB
> RAM.
> Picture seems very sharp and sound is good with my SB16 soundcard.
> Later today I will run it on my other machine that only has an onboard ac*
> soundcard.
>
> It was able to use the same config file that I use for Mik's version. :)

Would you mind sharing that config file? If you have any luck getting your AC97 onboard audio working, please let us know!

> Would you mind sharing that config file?

Sure:
--------------------------------
# This is the configuration file for mplayer, "starter" version.
# It should be placed in the directory:
# Drive:\arachne\mplayer
#
# Comment, or un-comment, parameters to suite your taste.
# The default below should get you going OK, but you may add extra lines
# to suit your equipment, or your needs.
# Please refer to the documentation first, though, such as the man page
# at \mplayer\docs\mplayer.htm or the fuller documentation starting
# at \mplayer\docs\htm\index.htm.

# Remove the # below only if there is good reason to force output to VESA.
# vo=vesa

# The next line should set the full path to the sub-titles font "subfont.ttf",
# so edit the path as necessary.
font=e:\arac190\mplayer\subfont.ttf

# The next line tells mplayer to allow screenshots to be taken when the
# letter "s" is pressed. Screen shots are numbered sequentially, as .PNGs.
vf=screenshot

# Un-comment the next line to force mplayer to go full-screen.
# Not a smart move for slow computers !
# And the picture may be distorted if the movie "screen" geometry is
# different to that of your monitor.
# fs=yes

# But, if you must go full-screen, you may need to drop frames to keep up
# with the audio track. If so, un-comment the next line. It works fairly well.
framedrop=yes

# Turn the display upside-down. For amusement only !
# flip=yes

# Add any other parameters below here.

af=volume=12.1:0
# was 10.1:0

really-quiet=yes

autosync=30

prefer-ipv4=yes

# nocache=yes
# cache=640

----------------------------------------

> If you have any luck getting your
> AC97 onboard audio working, please let us know!

Yes I will. Won't be today, but !

> Having a little spare time, I compiled Mplayer from a recent SVN

COOL

> and for sound I used WSS by Shigeaki Sakamaki instead of Allegro
> (at least WSS has support for some AC97 cards, I plan to add
> HDA support too).

COOL Where to download this "WSS" and what does this
abbreviation mean ?

> You may download them from
> here http : // rapidsh** . com / files/416911577 / Mplayer.7z



> I wonder if there is a way around the 2GB file-size limit?

YES.

> I think I posted about this topic a couple of years ago

??? WtF[1] ??? WtF[2] ???

> and the consensus then seemed to be a patch to unsigned DWORD
> integers was possible. At least unsigned 32-bit integers would make
> the limit 4GB which would play MOST single-layered DVDs
> and/or .VOBs all the way though!

Right.

> Since he's using DJGPP 2.04 beta to compile,
> it has the 4 GB patches (according to CWS)

of what ???

> I've never tried it. AFAICT, you need a suitable OS (MS-DOS 7 ???)

WtF ???

> FreeDOS still doesn't support > 2 GB files, even on FAT32,
> where it's able to be supported.

But EDR-DOS does support files up to 256 GiB, again

> At one time Eric Auer said it was "fairly trivial" to maybe?
> fix, but he never publicly hacked on it.

Because last time I discussed this thing with him his attitude was "there is no 2-GiB-problem in FreeDOS" , "there is no need for files > 2 GiB (or 2 GB ???) in DOS
or FreeDOS" and "use Linux". Another "interesting" point of him: "there is no need for a sound driver model for DOS or FreeDOS" and "there is no need to support
PCI sound hardware in DOS" and "you can't add this to DOS because there is no such thing in DOS" and finally "all sound cards are excellently supported and emulated with DOS-EMU"

Also the 2039 kernel still has this unfixed regression ...

> Hope that helps explain it somehow, but I doubt it
> 2010: the year of the DOS desktop

This says all ...

Test:

- rapidsh** sucks
- got the file "somehow", extracted, it runs (Pentium 4 PC)
- video does play, but ...
- still messing text into the video, problem known from 2008 Mik's DGJPP binaries and Sherpya's binaires via HX, -really-quiet badly needed ( >NUL seems not to work ...)
- it seems to always fullscreen-ize / zoom up the video by some obscure strategy
- even then, there are still severe artifacts with the video, apparently related to the VESA stuff or zooming (Mik's 2008 binaries and Sherpya's via HX usually don't have this problem)
- sound works - at least some chips: ENS:nope ICH:cool other:untested
- -vo yuv4mpeg and -vo pcm seem to work (didn't test > 2 GiB nor fragmentation)
- when done playing it tries to restore 80x25 text mode even if 80x50 was set before, but what's worse, sometimes not even the 80x25 mode is restored proprerly
- WeBM VP8 plays
- OGG Dirac still doesn't work (apprently a problem of primary MPLAYER project)
- Theora improvements untested
- Runs on Pentium 4, Pentium 1 untested -> CMONVTQ and PINSRNTQ issues untested
- CPUID'ding stuff not reported (not done at all ???) anymore
- Some strange "apo" stuff reported " ` " ...
- Seems I'll have to update my BIG video player comparison table and the table width problem will get even bigger

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > Since he's using DJGPP 2.04 beta to compile,
> > it has the 4 GB patches (according to CWS)
>
> of what ???

2.04 has better FAT32/4GB support, in theory, not sure if it was ever tested well or not.

> > I've never tried it. AFAICT, you need a suitable OS (MS-DOS 7 ???)
>
> WtF ???

You know I don't have the inclination (or setup) to test everything! But yeah, forgot about EDR-DOS.

> > At one time Eric Auer said it was "fairly trivial" to maybe?
> > fix, but he never publicly hacked on it.
>
> Because last time I discussed this thing with him his attitude was "there
> is no 2-GiB-problem in FreeDOS" , "there is no need for files > 2 GiB (or 2
> GB ???) in DOS
> or FreeDOS" and "use Linux".

Yes, but he also somewhat recanted and said it should be reasonably possible. But he may have waited for approval or help from Bart or Jeremy, who knows.

> Another "interesting" point of him: "there is
> no need for a sound driver model for DOS or FreeDOS"

I think at best he just wanted a linkable library extracted from Mpxplay (if that's even possible).

> and "there is no need to support
> PCI sound hardware in DOS" and "you can't add this to DOS because there is
> no such thing in DOS" and finally "all sound cards are excellently
> supported and emulated with DOS-EMU"

He likes DOSEMU, and let's face it, it works! The borg have assimilated us, we can't run. We have to accept other OSes and emulators, they aren't going anywhere. Best of a bad situation ....

> Also the 2039 kernel still has this unfixed regression ...

Yeah, very few volunteers, sad.

> > Hope that helps explain it somehow, but I doubt it
> > 2010: the year of the DOS desktop
>
> This says all ...

It does? All it says is that, "Well, here's my lame, crappy answer in lieu of somebody more experienced."

> - still messing text into the video, problem known from 2008 Mik's DGJPP
> binaries and Sherpya's binaires via HX, -really-quiet badly needed (
> >NUL seems not to work ...)
> - it seems to always fullscreen-ize / zoom up the video by some obscure
> strategy
> - even then, there are still severe artifacts with the video, apparently
> related to the VESA stuff or zooming (Mik's 2008 binaries and Sherpya's via
> HX usually don't have this problem)
> - sound works - at least some chips: ENS:nope ICH:cool
> other:untested


-really-quiet works for me, no text displayed while playing .mpeg2 files. As to your fullscreen / zooming problem, could be it defaulting to 640x480 VESA LFB mode 0x4101? I noticed I had to either use the VBEPLUS utility, or manually adjust the settings via -zoom to get correct ratios, and only then the 4x3 aspect ratio worked, couldn't get -pixelaspect to work in 16:10 mode.

You got sound working on ICH soundcard? You mean AC97 ICH, right, now Intel High Definition audio?

I thought WSS stood for Windows Sound System, but that can't be right in this instance!

Also, I noticed this build was built without the -cvidix library?

> -really-quiet works for me, no text displayed while playing

text gone but video still broken

> You got sound working on ICH soundcard?

YES

> right, now Intel High Definition audio?

NO

> Also, I noticed this build was built without the -cvidix library?

Maybe, but I'd like to see the VESA working properly before experimenting with CVidix

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Tried it on my BIG machine with only the on-board AC'97 soundcard.

Video seems fine with -really-quiet.

Sound failed - no sound at all, same as Mik's version on this machine.
FWIW: MPXplayer works with this on-board soundcard, so I know it isn't broken.

I am starting to doubt that this mplayer is actually using my previously claimed config.
It seemed to work the first time, but now it doesn't seem to be affecting anything.
Can't explain it. :( Probably a wet-ware failure.

> Sound failed - no sound at all, same as Mik's version on this machine.
> FWIW: MPXplayer works with this on-board soundcard, so I know it isn't
> broken.

For the present WSS supports only VIA (VT82C686 and VT8233) and Intel (in theory all) AC97 cards. What AC97 card do you have?

> I am starting to doubt that this mplayer is actually using my previously
> claimed config.
> It seemed to work the first time, but now it doesn't seem to be affecting
> anything.
> Can't explain it. :( Probably a wet-ware failure.

The configuration files should work OK, where did you put it?

---
Glory to God for all things

> I thought WSS stood for Windows Sound System, but that can't be right in
> this instance!

WSS is the sound library written by Shigeaki Sakamaki for his VSyncMame. Perhaps he called it WSS because before anything else he added WSS audio support.

> Also, I noticed this build was built without the -cvidix library?

It has vidix enabled and working. If you have a video card supported by the vidix drivers, use Mplayer with "-vo vesa:vidix".

---
Glory to God for all things

> > -really-quiet works for me, no text displayed while playing
>
> text gone but video still broken

Please describe clearly what you mean by "broken video", as I can't reproduce the problem.
EDIT: OTOH it doesn't "fullscreenize" the video except only if you use it with "-fs". And for VESA video output use it with "-fs -zoom" for full screen video.

---
Glory to God for all things

Please see if you still have the Intel 82945GM problem trying this one: http://rapidshare.com/files/417611675/mplayer.exe. The VESA output should work exactly like in the case of Kostylev's builds. For scaling video to full screen, use Mplayer with "-fs -zoom -monitoraspect". Unfortunately I've had no time yet for adding support to other sound cards.

---
Glory to God for all things

> For the present WSS supports only VIA (VT82C686 and VT8233) and Intel (in
> theory all) AC97 cards. What AC97 card do you have?

From NSSI: nVIDIA nForce4 AC'97 Audio Controller
16 Bits Stereo PCI

>
> > I am starting to doubt that this mplayer is actually using my previously
> > claimed config.
> > It seemed to work the first time, but now it doesn't seem to be
> affecting
> > anything.
> > Can't explain it. :( Probably a wet-ware failure.
>
> The configuration files should work OK, where did you put it?

In the same directory as mplayer.exe.
Ran it as: mplayer -really-quiet drive:\dirs\video.ext

> FWIW: MPXplayer works with this on-board soundcard, so I know it isn't broken.

NO, just MPXPLAY sound support is still very superior to anything else

> Please describe clearly what you mean by "broken video",
> as I can't reproduce the problem.

Screen content "jumping" or strange horizontal "stripes" (duplicating or mirroring content) or other artifacts. I'll try to brew some BUG-shots if the problem persists.

> Intel 82945GM integrated graphics which is VBE 3.0 compatible.
> Something about a page-flip error

Maybe my issues are related to this "page-flip" too ?

More tests:

Good news:

+ It works on Pentium 1 too, even VP8, so the binary even lacks the PINSRNTQ-BUG

Bad news:

- From 3 PC's tested all expose the same "broken-video-BUG", it is definitely sensitive to the video size (some sizes seem to play well)

> Please see if you still have the Intel 82945GM problem trying this one:
> http://rapidshare.com/files/417611675/mplayer.exe. The VESA
> output should work exactly like in the case of Kostylev's builds.

So you fixed the VESA ?

> For scaling video to full screen, use Mplayer with "-fs -zoom -monitoraspect".

I'll try ...

> Unfortunately I've had no time yet for adding support to other sound cards.

Let's wait

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> NO, just MPXPLAY sound support is still very superior to anything else

Certainly it is, but its sound card supporting code is too Mpxplay oriented and not so original. If I would have the time, I would write a wrapper for ALSA's or OSS' drivers (which are easily made usable for DOS), but I don't. I like WSS and it can be extended to support new cards without too much effort.

> > Please describe clearly what you mean by "broken video",
> > as I can't reproduce the problem.
>
> Screen content "jumping" or strange horizontal "stripes" (duplicating or
> mirroring content) or other artifacts. I'll try to brew some BUG-shots if
> the problem persists.

Try to use it with "-vsync" to see if it helps. VESA video output is generally awful IMO (before anything else it is very slow), but it can't be improved, this is all that you can get with VESA. As you know, it doesn't support hardware scaling or color space conversion.

---
Glory to God for all things

> Try to use it with "-vsync" to see if it helps

I will.

> As you know, it doesn't support hardware scaling or color space conversion

Right At least it's correct in 2008 Mik's versions and 2010 Sherpya's (at least as long as the video fits on the screen).

What's the preferred way to tell MPLAYER "don't zoom, put video 1:1 centered on screen" ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Please see if you still have the Intel 82945GM problem trying this one:
> http://rapidshare.com/files/417611675/mplayer.exe. The VESA
> output should work exactly like in the case of Kostylev's builds. For

Thanks very much; this new one works VERY WELL now with the 82945GM, with and without my 1:1 native mode support. What code did you change? That native 1:1 pixel-mapping support is what enables me to "center" the 4:3 image on the 16:10 screen, with 1:1 zoom, as DOS386 wants to do. Like thw tool NVCLOCK, but with Intel onboard graphics. (Many thanks to Laaca of this Board for providing me with that Intel 82945GM BIOS extension driver!) But, I suppose some combination of -monitoraspact and -pixelaspect will accomplish the same with *all* video cards with VESA2 and/or VESA3 support.

> Thanks very much; this new one works VERY WELL now with the 82945GM, with
> and without my 1:1 native mode support. What code did you change?

When flipping pages it uses now scheduled display start in case of VBE 3.0 cards.

---
Glory to God for all things

> Right At least it's correct in 2008 Mik's versions and 2010 Sherpya's
> (at least as long as the video fits on the screen).

With my video cards Mik's versions behave exactly the same, I can see no difference. When the output is bad, it is bad with Mik's versions too.

> What's the preferred way to tell MPLAYER "don't zoom, put video 1:1
> centered on screen" ?

AFAIK this is what it does when not told other way.

---
Glory to God for all things

Yesterday I tried your build and it works very well!
I was affraid that sound will not work with SB16 card but everything is fine. Sound is playing on genuine SB16 and also on SBLive! with driver.
And I am happy that it supports CVidix video output!

However, did you check the subtitle feature? The subtitles are not shown and MPplaer complains about missing ~/mplayer/subtitle.ttf file.
The Mik's builds looked for subtitle.ttf into .\shared\mplayer\
Now something changed?
And is here a chance for adding native SBLive! or SB128 soundcard?

---
DOS-u-akbar!

> However, did you check the subtitle feature? The subtitles are not shown
> and MPplaer complains about missing ~/mplayer/subtitle.ttf file.
> The Mik's builds looked for subtitle.ttf into .\shared\mplayer\
> Now something changed?

This one has fixed the problems caused by not having HOME set: http://rapidshare.com/files/417870314/mplayer.exe. Put the font file and the configuration in a subdirectory called "mplayer".

> And is here a chance for adding native SBLive! or SB128 soundcard?

I am most interested in HDA support for the present, but for the future God knows.

---
Glory to God for all things

> AFAIK this is what it does when not told other way

> With my video cards Mik's versions behave exactly the same, I can see no
> difference. When the output is bad, it is bad with Mik's versions too

I'll do more tests (IIRC Mik's binaries do zoom to, Sherpya's don't).

> Sound is playing on genuine SB16 and also on SBLive! with driver

no SBLive support despite AC97 ???

> And is here a chance for adding native SBLive! or SB128 soundcard?

+1

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

I keep trying to post some testing of mplayer, but this board keeps locking up !

> I keep trying to post some testing of mplayer, but this board keeps locking
> up !

I'll keep this short.

Latest version of mplayer: cannot get audio and video to sync.
Seems video processing takes longer than audio, and they drift further apart as the file plays.

> I'll keep this short. Seems short messages get through.
>
> Latest version of mplayer: cannot get audio and video to sync.
> Seems video processing takes longer than audio, and they drift further
> apart as the file plays.

This is on an AMD K6 600 MHz machine. A colleague with a 2.4 GHz P4 can sync with six "+" presses, and it stays in sync.

> > I'll keep this short. Seems short messages get through.

The video card is a Diamond Stealth with 3MB RAM. Maybe a "better" card would also help.

---
AUSREG Consultancy http://www.ausreg.com
Tadpole Tunes http://www.tadpoletunes.com
Sna Keo Il http://www.tadpoletunes.com/sna_keo_il/

> > > I'll keep this short. Seems short messages get through.
>
> The video card is a Diamond Stealth with 3MB RAM.

Typo: make that 2 MB RAM.

I just tested Khusraw's build but I'm not happy about that. At fisrt the video playback is very slow/jumpy. I ran under MS-DOS 6.22 + JEMMEX on FAT16 disk, sound: SB Live, vga: GF7900GT (VBE 3.0). This is options that I started with (used it for Mik's build):

mplayer.exe -vo vesa -nosound -really-quiet -zoom -x 1024 -y 768 -vsync %1 %2 %3 %4 %5 %6 %7 %8 %9

In this case the playback was jumpy like if 2 following frames are swapped, it flickers and moving objects jumps back and forth...
So I disabled -vsync option. Then it seems that frames wasplayed in right order but I can see redrawing of backbuffer in half of currently playing frame and it looks ugly anyway.

Mik's build plays perfectly smooth with this options.

Then I disabled -nosound hoping that I got a sound from my SB Live but nothing. Regardless if running SB Emu driver or not. In this case mplayer hangs at start and don't play just after dysplaying this:
Trying every known audio driver...
I could only press CTRL+C twice to fall back to DOS.
MPlayer interrupted by signal 295 in module: ao2_init

When I ran mplayer under EMM386 I got:

Page Fault cr2=00400000 at eip=3c5; flags=3202                                 
eax=00000300 ebx=01250021 ecx=000000a4 edx=bfeb00b7 esi=00000000 edi=00000000 
ebp=0000091c esp=0000075a cs=87 ds=b7 es=af fs=0 gs=0 ss=8f error=0006


Would it be possible to add SBlive support? I think it's also AC97 card. Here's VID, PID:


PCI device #23 found at bus: 4, dev: 2, func: 0
Vendor ID: 1102h (Creative Labs)
Device ID: 0002h, Revision ID: 7, Class: 04h (multimedia device)
Sub-Class: 01h (audio device)
IRQ: 3, INTA, Cache line: 0B, Latency: 64
BAR: 0000D001h, 00000000h, 00000000h, 00000000h, 00000000h, 00000000h
Device cfg: FBtoB,SERRE,WaitC,PaErr,VGAPS,MemWr,SpecC,BusMa,MemSE,IOSEn
              0     1     0     0     0     0     0     1     0     1

PCI device #24 found at bus: 4, dev: 2, func: 1
Vendor ID: 1102h (Creative Labs)
Device ID: 7002h, Revision ID: 7, Class: 09h (input device)
Sub-Class: 80h (other input device)
IRQ: none, Cache line: 0B, Latency: 64
BAR: 00000201h, 00000000h, 00000000h, 00000000h, 00000000h, 00000000h
Device cfg: FBtoB,SERRE,WaitC,PaErr,VGAPS,MemWr,SpecC,BusMa,MemSE,IOSEn
              0     0     0     0     0     0     0     1     0     1


Anyway thx for your effort improving dos mplayer...

---
DOS gives me freedom to unlimited HW access.

> Anyway thx for your effort improving dos mplayer...

+1

> Would it be possible to add SBlive support?

please (+ENS137x)

> PCI device #23 found at bus: 4, dev: 2, func: 0
> Vendor ID: 1102h (Creative Labs)
> Device ID: 0002h, Revision ID: 7, Class: 04h (multimedia device)

> PCI device #24 found at bus: 4, dev: 2, func: 1
> Vendor ID: 1102h (Creative Labs)
> Device ID: 7002h, Revision ID: 7, Class: 09h (input device)

Some joystick bogus bundled with sound card for obscure reasons? The device "04h (multimedia device)" should be sufficient

New test results:

- the "vidix" works

- "broken video" + "stripes" is worst with Theora. Why? Because there is a regression. Again, RTFB : http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1788 http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1774 http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1771

http://www.file-pasta.com/file/0/MPHTMIRR.PNG Broken
http://www.file-pasta.com/file/0/MPTHMIOK.PNG OK (older version of MPLAYER)

- with other codecs/formats the "artifacts" are considerably weaker, but there is still a problem

- -vo vesa:vidix removes the "artifacts" (so it's apparently a problem of the VESA, made worse by the bugged Theora decoder)

- Zooming up is still strange, it sometimes (?) does zoom up despite not requested, it does NOT behave same as 2008 Mik's binaries

- What about dropping the next version here: http://ompldr.org/

http://www.file-pasta.com/file/0/RAPIDSH0.PNG
http://www.file-pasta.com/file/0/RAPIDSH1.PNG
http://www.file-pasta.com/file/0/RAPIDSH2.PNG push <F2>
http://www.file-pasta.com/file/0/RAPIDSH3.PNG pick "EXE & COM" here ??? I had picked all ....
http://www.file-pasta.com/file/0/RAPIDSH4.PNG takes centuries, needed to bypass Rapid-Sh** delay ???
http://www.file-pasta.com/file/0/RAPIDSH5.PNG
http://www.file-pasta.com/file/0/RAPIDSH6.PNG it runs
http://www.file-pasta.com/file/0/RAPIDSH7.PNG display EXE as text ??? WtF ...
http://www.file-pasta.com/file/0/RAPIDSH8.PNG
http://www.file-pasta.com/file/0/RAPIDSH9.PNG finally

Offending video (16 MiB) : http://www.file-pasta.com/file/0/FF35.OGV

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

I also tried -vo vesa:vidix but then I got only a black screen (monitor OSD reports that mode was set).

>Some joystick bogus bundled with sound card for obscure reasons?
>The device "04h (multimedia device)" should be sufficient

Yes it's integrated gameport on the SB Live, I could delete it from PCI listing.

---
DOS gives me freedom to unlimited HW access.

> When I ran mplayer under EMM386 I got:
>
> Page Fault cr2=00400000 at eip=3c5; flags=3202                                 
> eax=00000300 ebx=01250021 ecx=000000a4 edx=bfeb00b7 esi=00000000
> edi=00000000 
> ebp=0000091c esp=0000075a cs=87 ds=b7 es=af fs=0 gs=0 ss=8f error=0006
>

Maybe it sets the MTRR registers. JEMMX handles this privileged instruction but MS EMM386 not.

But your problems with sound on SBLive! are strange. I have no problem with Mplayer with this card (with SB legacy emulation)

Also video speed is accetable. Even with pure VESA driver on Pentium 300.

---
DOS-u-akbar!

Khursaw, could you please upload somewhere the WSS and CVidix binaries compliled by DJGPP? I mean the .O or even better .DXE files.

I would like to try to use it with Freepascal and somebody else could try it with Freebasic.

I hope I will be able to translate the header into pascal

---
DOS-u-akbar!

Hi :)
Im Using an old Mplayer version I (think DJGPP port by Michael Kostylev) and it runs very well in my ancient p166mmx

Cause my cpu is very limited Usually I need to reencode videos, but about FLV videos (normal res) they play perfect.

I was testing you r new version and In comparison the CPU requirements are higher.. so I cannt play any video with it

Why more cpu? Its cause Allegro removed?

I know about the config (mplayer file). There is any setting to bring back the allegro output?

Its possible create a less cpu consuming Mplayer... (like the one of Michael Kostylev)?

> But your problems with sound on SBLive! are strange. I have no problem with
> Mplayer with this card (with SB legacy emulation)

Due to ICH7 chipset - it is discused in another thread :) If Khusraw would kindly extend native AC'97 driver support to AB Live it may work without SB emu driver also on new system. I don't have problem with MPXplay or QuickView because they use native driver.

> Also video speed is accetable. Even with pure VESA driver on Pentium 300.

I don't know why. I also tried to enable MTRRs manually before but no effect. Mik's version plays nicely smooth.

---
DOS gives me freedom to unlimited HW access.

> Khursaw, could you please upload somewhere the WSS and CVidix binaries
> compliled by DJGPP? I mean the .O or even better .DXE files.
>
> I would like to try to use it with Freepascal and somebody else could try
> it with Freebasic.
>
> I hope I will be able to translate the header into pascal

Download from http://ompldr.org/vNWliZQ.
There is no vidix library, and the objects should be statically linked. The mtrr code does nothing (i.e. there is still no vidix code for the setting of mtrrs under DOS). You may add support for whatever sound card you want in wss.

---
Glory to God for all things

> I also tried -vo vesa:vidix but then I got only a black screen (monitor OSD
> reports that mode was set).

This happens also with my GeForce 7600 GS. Vidix detects, but still doesn't work with, relatively newer NVIDIA cards.

---
Glory to God for all things

> I don't know why. I also tried to enable MTRRs manually before but no
> effect. Mik's version plays nicely smooth.

This Mplayer build doesn't set the mtrrs, neither for vesa nor for vidix. The mttrs should still be set manually. In theory there is no difference (I am not aware of any) concerning the vesa output code comparing to Mik's builds. In practice, with the video files I tested, I can really see no difference. But if you get worse video, this is perhaps caused by some regressions in Mplayer

---
Glory to God for all things

> I was testing you r new version and In comparison the CPU requirements are
> higher.. so I cannt play any video with it
>
> Why more cpu? Its cause Allegro removed?

It is also compiled with "runtime CPU detection", so the CPU requirements are the same. If you imply it is slower, I don't think this has something to do with the audio output. Do they work the same with "-nosound"?

> Its possible create a less cpu consuming Mplayer... (like the one of
> Michael Kostylev)?

Perhaps building an older version.

---
Glory to God for all things

> > Its possible create a less cpu consuming Mplayer... (like the one of
> > Michael Kostylev)?
>
> Perhaps building an older version.

Maybe. Core MPlayer developers are very probably focused on security and vulnerability resulting to various underlows/underflows and potentialy dangerous code.
(Useless in DOS, but can be important in Linux and Windows.)
So there is more various checks in player routines which slow down the decoding.

---
DOS-u-akbar!

> > > Its possible create a less cpu consuming Mplayer... (like the one of
> > > Michael Kostylev)?
> >
> > Perhaps building an older version.
>
> Maybe. Core MPlayer developers are very probably focused on security and
> vulnerability resulting to various underlows/underflows and potentialy
> dangerous code.
> (Useless in DOS, but can be important in Linux and Windows.)
> So there is more various checks in player routines which slow down the
> decoding.

for slow CPUs like mine (166mmx) every speed up improvement is really welcome...
Until now I was using Quickview.. but cause It lacks of support for wmv and flv I moved to mplayer..

If new version is created with speed ups. Ill be glad to test ;)

> Maybe. Core MPlayer developers are very probably focused on security and
> vulnerability resulting to various underlows/underflows and potentialy
> dangerous code.
> (Useless in DOS, but can be important in Linux and Windows.)
> So there is more various checks in player routines which slow down the
> decoding.

Mplayer is not my code. The only thing I do was to provide the VBE interface for DOS (which can't be slower or faster), to add the mapping code for accessing the video frame buffer (which again can't be slower or faster) and to add wss instead of Allegro for sound. Allegro doesn't work with my sound cards, even with my CS425 which has hardware SB Pro emulation the sound is very bad, wss works much better with it and besides has good support for my ICH5 AC97. I have Mik's patch to vo_vesa and I can say without any doubt that neither his patch has any contribution to how fast or clean the VESA video output is. But Windows builds of newer Mplayer (sub)versions are also much slower than older ones, e.g. the latest Sherpya builds are slow with my 2.6GHz Pentium IV, older ones used to be fast enough.

---
Glory to God for all things

> This happens also with my GeForce 7600 GS. Vidix detects, but still doesn't
> work with, relatively newer NVIDIA cards.

This problem is releated VESA VBE implementation or its HW chip difference? I don't know details how vidix is implemented but I guess it tries to utilize VGA beyond VBE so it use some HW specific routines and then it's usual that new HW will not work because of change.

But any idea why I got jumpy on VESA with vsync? It looks like 2 frames are swapped, instead display 1,2,3,4... it shows 1,3,2,4...

---
DOS gives me freedom to unlimited HW access.

> > This happens also with my GeForce 7600 GS. Vidix detects, but still
> doesn't
> > work with, relatively newer NVIDIA cards.
>
> This problem is releated VESA VBE implementation or its HW chip difference?
> I don't know details how vidix is implemented but I guess it tries to
> utilize VGA beyond VBE so it use some HW specific routines and then it's
> usual that new HW will not work because of change.

Vidix doesn't know about VGA or VESA, it uses only the card's specific registers. It detects the GeForce 7600 GS by checking for the device id from its pci database, then plays with the card's registers and provides a pointer to the frame buffer, but unfortunately something fails on the way. The video modes are not set by Vidix, Vidix expects the video modes to be set by the "graphics server". Anyway, Vidix's NVIDIA driver is "in the beta stage" and "untested".

> But any idea why I got jumpy on VESA with vsync? It looks like 2 frames are
> swapped, instead display 1,2,3,4... it shows 1,3,2,4...

Strangely enough, I haven't noticed such a thing yet. But I saw that -vsync and -framedrop doesn't work always as expected.

---
Glory to God for all things

> Vidix doesn't know about VGA or VESA, it uses only the card's specific
> registers. It detects the GeForce 7600 GS by checking for the device id
> from its pci database, then plays with the card's registers and provides a
> pointer to the frame buffer, but unfortunately something fails on the way.
> The video modes are not set by Vidix, Vidix expects the video modes to be
> set by the "graphics server". Anyway, Vidix's NVIDIA driver is "in the beta
> stage" and "untested".

I went through old mails with Mik and remember we discused vidix - he told that new Nvidia and ATI lacks some YUV overlay feature so no acceleration can be done this way. So we gave it up.

> Strangely enough, I haven't noticed such a thing yet. But I saw that -vsync
> and -framedrop doesn't work always as expected.

I found that -nodouble option will make it much better, no jumping but only sometimes small lag. Maybe Mik did more patching around that, did you applied all his patches?

---
DOS gives me freedom to unlimited HW access.

> Download from
> http://ompldr.org/vNWliZQ.
> There is no vidix library, and the objects should be statically linked. The
> mtrr code does nothing (i.e. there is still no vidix code for the setting
> of mtrrs under DOS). You may add support for whatever sound card you want
> in wss.

Thanks. I'm trying to recompile it with main() enabled and found a small bug:
wss.c: In function 'w_get_actual_sample_rate':
wss.c:5365: warning: the address of 'get_played_sample_count' will never be NULL

this is already declared function so it doesn't make sense to compare it's pointer with NULL
if (get_played_sample_count != 0)
GCC 4.x has just smarter code analysis so produce more -Walls :)
Maybe author wanted to do something different (it makes sense for a variable)

I'm also disappointed there are very few comments...

UPDATE:
I tried to add SB live in intel AC97 section but it didn't went so far. It was detected, IO BASE0 was found but IO BASE1 was not set so it displayed that chip is disabled. When I removed this check (just4fun) it looked like trying to play something but any buffer pointer did not incremented. The same for SB Emu driver and trying SB types - all detected but nothing works. Hm seems that AC97 is not strict standard and would need specific SB code. It's beyond my knowledges as I didn't any programming of sound...

---
DOS gives me freedom to unlimited HW access.

> Maybe. Core MPlayer developers are very probably focused on security and
> vulnerability resulting to various underlows/underflows and potentialy
> dangerous code.
> (Useless in DOS, but can be important in Linux and Windows.)
> So there is more various checks in player routines which slow down the decoding

> (sub)versions are also much slower than older ones, e.g. the latest Sherpya
> builds are slow with my 2.6GHz Pentium IV, older ones used to be fast enough.

WtF ??? A few security/limit checks causing a massive slowdown? BTW, newer versions brew less Page Faults, but if it's true that they are that much slower ... (another ToTest item ....)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***