Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to index page
Thread view  Board view
Khusraw

E-mail

Bucharest, Romania,
03.09.2010, 23:50
(edited by Khusraw, 04.09.2010, 00:33)
 

Experimental Mplayer build from SVN (Announce)

Post reply

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
Zyzzle

04.09.2010, 06:31

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

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!
Rugxulo

Homepage

Usono,
04.09.2010, 08:02

@ Zyzzle
 

Experimental Mplayer build from SVN -- 4 GB files?

Post reply

> 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
Khusraw

E-mail

Bucharest, Romania,
04.09.2010, 10:21
(edited by Khusraw, 04.09.2010, 11:42)

@ Zyzzle
 

Experimental Mplayer build from SVN

Post reply

> 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
Zyzzle

05.09.2010, 04:48

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

>
> 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!
ron

Homepage E-mail

Australia,
05.09.2010, 00:43

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

> 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. :)
Zyzzle

05.09.2010, 04:49

@ ron
 

Experimental Mplayer build from SVN

Post reply

> > 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!
ron

Homepage E-mail

Australia,
05.09.2010, 05:35

@ Zyzzle
 

Experimental Mplayer build from SVN

Post reply

> 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 !
DOS386

06.09.2010, 20:04

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

> 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 ??? :crying:

> 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 :clap:

> 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 :clap: - 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 :crying:

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

Homepage

Usono,
06.09.2010, 22:34

@ DOS386
 

Experimental Mplayer build from SVN

Post reply

> > 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 ??? :crying:
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."
Zyzzle

07.09.2010, 00:21

@ DOS386
 

Experimental Mplayer build from SVN

Post reply

> - 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 :clap: - 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?
DOS386

07.09.2010, 01:36

@ Zyzzle
 

Experimental Mplayer build from SVN - ICH/HDA

Post reply

> -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 ***
ron

Homepage E-mail

Australia,
07.09.2010, 03:05

@ DOS386
 

Experimental Mplayer build from SVN - ICH/HDA

Post reply

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.
Khusraw

E-mail

Bucharest, Romania,
07.09.2010, 10:10
(edited by Khusraw, 07.09.2010, 10:48)

@ ron
 

Experimental Mplayer build from SVN - ICH/HDA

Post reply

> 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
ron

Homepage E-mail

Australia,
08.09.2010, 00:06

@ Khusraw
 

Experimental Mplayer build from SVN - ICH/HDA

Post reply

> 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
Khusraw

E-mail

Bucharest, Romania,
07.09.2010, 10:18
(edited by Khusraw, 07.09.2010, 15:21)

@ DOS386
 

Experimental Mplayer build from SVN - ICH/HDA

Post reply

> > -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
Khusraw

E-mail

Bucharest, Romania,
07.09.2010, 10:16
(edited by Khusraw, 07.09.2010, 13:44)

@ Zyzzle
 

Experimental Mplayer build from SVN

Post reply

> 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
Khusraw

E-mail

Bucharest, Romania,
07.09.2010, 14:03
(edited by Khusraw, 07.09.2010, 15:22)

@ Zyzzle
 

Experimental Mplayer build from SVN

Post reply

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
DOS386

08.09.2010, 00:37

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

> 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. :hungry:

> 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 :hungry:

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

E-mail

Bucharest, Romania,
08.09.2010, 01:14
(edited by Khusraw, 08.09.2010, 01:33)

@ DOS386
 

Experimental Mplayer build from SVN

Post reply

> 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. :hungry:
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
DOS386

08.09.2010, 01:46

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

> 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 ***
Khusraw

E-mail

Bucharest, Romania,
08.09.2010, 13:40

@ DOS386
 

Experimental Mplayer build from SVN

Post reply

> 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
Laaca

Homepage

Czech republic,
08.09.2010, 13:47

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

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!
Khusraw

E-mail

Bucharest, Romania,
08.09.2010, 17:54

@ Laaca
 

Experimental Mplayer build from SVN

Post reply

> 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
DOS386

08.09.2010, 19:48

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

> 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 ***
RayeR

Homepage

CZ,
10.09.2010, 21:49

@ DOS386
 

Experimental Mplayer build from SVN

Post reply

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.
DOS386

11.09.2010, 01:53

@ RayeR
 

Experimental Mplayer build from SVN

Post reply

> 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 ??? :-D
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 ***
RayeR

Homepage

CZ,
11.09.2010, 02:37

@ DOS386
 

Experimental Mplayer build from SVN

Post reply

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.
Khusraw

E-mail

Bucharest, Romania,
11.09.2010, 13:13

@ RayeR
 

Experimental Mplayer build from SVN

Post reply

> 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
RayeR

Homepage

CZ,
11.09.2010, 20:49

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

> 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.
Khusraw

E-mail

Bucharest, Romania,
11.09.2010, 22:39
(edited by Khusraw, 11.09.2010, 23:07)

@ RayeR
 

Experimental Mplayer build from SVN

Post reply

> > 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
RayeR

Homepage

CZ,
12.09.2010, 00:07
(edited by RayeR, 12.09.2010, 02:01)

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

> 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.
Khusraw

E-mail

Bucharest, Romania,
12.09.2010, 10:22

@ RayeR
 

Experimental Mplayer build from SVN

Post reply

> 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?
Perhaps he didn't use scheduled display start for VBE 3.0 cards in his libvbe (which I don't have). I will change libvbe to use also non-scheduled display start in case of VBE 3.0 cards.

---
Glory to God for all things
Khusraw

E-mail

Bucharest, Romania,
12.09.2010, 11:53

@ RayeR
 

Experimental Mplayer build from SVN

Post reply

Download from http://ompldr.org/vNWlscQ and see if this one works better with your VBE 3.0 card.

---
Glory to God for all things
RayeR

Homepage

CZ,
12.09.2010, 14:01

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

> Perhaps he didn't use scheduled display start for VBE 3.0 cards in his
> libvbe (which I don't have). I will change libvbe to use also non-scheduled
> display start in case of VBE 3.0 cards.
> Download from
> http://ompldr.org/vNWlscQ and see if
> this one works better with your VBE 3.0 card.
Yes you got it! Now it works exactly the same as Mik's version, including the text screen mess up after quit :)
http://rayer.ic.cz/350d/mp.jpg (It was Dos Navigator screen :P)
But it can be repaired by reloading the font I have it in my batch file. Probably nvidia has some VBE bug or difference in page flipping funcion. Could you add some commandline option to fix this or you leave it as it is now?

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

Homepage

Czech republic,
11.09.2010, 08:45

@ RayeR
 

Experimental Mplayer build from SVN

Post reply

> 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!
RayeR

Homepage

CZ,
11.09.2010, 12:11

@ Laaca
 

Experimental Mplayer build from SVN

Post reply

> 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.
Khusraw

E-mail

Bucharest, Romania,
11.09.2010, 13:25
(edited by Khusraw, 11.09.2010, 13:38)

@ RayeR
 

Experimental Mplayer build from SVN

Post reply

> 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
Laaca

Homepage

Czech republic,
11.09.2010, 08:49

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

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!
Khusraw

E-mail

Bucharest, Romania,
11.09.2010, 13:07
(edited by Khusraw, 11.09.2010, 13:30)

@ Laaca
 

Experimental Mplayer build from SVN

Post reply

> 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
RayeR

Homepage

CZ,
12.09.2010, 00:11
(edited by RayeR, 12.09.2010, 02:08)

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

> 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.
Khusraw

E-mail

Bucharest, Romania,
12.09.2010, 10:08
(edited by Khusraw, 12.09.2010, 10:18)

@ RayeR
 

Experimental Mplayer build from SVN

Post reply

> 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)
Rather it looks like it should have been "get_played_sample_count() != 0". But that code is the same in AdvanceMame's wss, it seems that no one has detected that bug until now.

> 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...
Just look at ALSA's SB live driver and see what it does differently. AFAIK the AC97 part is drawn from ALSA.

---
Glory to God for all things
RayeR

Homepage

CZ,
12.09.2010, 13:38

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

> Rather it looks like it should have been "get_played_sample_count() != 0".
> But that code is the same in AdvanceMame's wss, it seems that no one has
> detected that bug until now.
Maybe... The author probably abandon this code, I found latest vsyncmame from year 2003...

> Just look at ALSA's SB live driver and see what it does differently. AFAIK
> the AC97 part is drawn from ALSA.
I'm afraid it would be more complicated. In kernel config the SBlive is placed in separated emu10k1 module instead of other ac97 cards. And my onboard audio supports only HD (PCI sub class is HD audio) not AC97 :(.

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

E-mail

Bucharest, Romania,
12.09.2010, 13:52
(edited by Khusraw, 12.09.2010, 14:04)

@ RayeR
 

Experimental Mplayer build from SVN

Post reply

> Maybe... The author probably abandon this code, I found latest vsyncmame
> from year 2003...
VSyncMame project is dead, but the latest (and perhaps last?) AdvanceMame, which also uses wss, dates from 2009. But why would matter the fact that the code is abandoned? wss looks so complicated to you? Anyway, the bug (which is corrected now) seems to have no influence on how the sound plays. wss can be easily upgraded to support other sound cards, I just haven't got time until now to add support for new ones, but at first I would rather add support for those which I can test (e.g. HDA).

---
Glory to God for all things
RayeR

Homepage

CZ,
12.09.2010, 14:14

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

> VSyncMame project is dead, but the latest (and perhaps last?) AdvanceMame,
> which also uses wss, dates from 2009. But why would matter the fact that
You pick the WSS code from this latest version? Did it changed significatnly from 2003? I meant that if it still alive to not interfere with code that MAME guys do, but if they didn't updated it for years then you have the living code in hands.

> the code is abandoned? wss looks so complicated to you? Anyway, the bug
Maybe on first look, it's also question of time, which I also having less and less. I have some other DOS progs under work so I don't want to start another new thing. Also as I said I never did any sound programming so I don't have experiences with setting up DMA buffers etc...

> (which is corrected now) seems to have no influence on how the sound plays.
> wss can be easily upgraded to support other sound cards, I just haven't
> got time until now to add support for new ones, but at first I would
> rather add support for those which I can test (e.g. HDA).
I'll forward to your firts HDA test :) Mine ICH7 is device ID 0x27d8.

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

08.09.2010, 02:02

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

> 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.
Khusraw

E-mail

Bucharest, Romania,
08.09.2010, 12:08

@ Zyzzle
 

Experimental Mplayer build from SVN

Post reply

> 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
ron

Homepage E-mail

Australia,
10.09.2010, 03:08

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

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

Homepage E-mail

Australia,
10.09.2010, 03:11

@ ron
 

Experimental Mplayer build from SVN

Post reply

> 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.
ron

Homepage E-mail

Australia,
10.09.2010, 03:13

@ ron
 

Experimental Mplayer build from SVN

Post reply

> 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.
ron

Homepage E-mail

Australia,
10.09.2010, 03:16

@ ron
 

Experimental Mplayer build from SVN

Post reply

> > 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/
ron

Homepage E-mail

Australia,
10.09.2010, 03:17

@ ron
 

Experimental Mplayer build from SVN

Post reply

> > > 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.
Khusraw

E-mail

Bucharest, Romania,
18.09.2010, 20:49

@ ron
 

Experimental Mplayer build from SVN

Post reply

> 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.
Now -framedrop should work as expected. Use -framedrop for audio video synchronization.

---
Glory to God for all things
travolter

11.09.2010, 10:57

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

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)?
Khusraw

E-mail

Bucharest, Romania,
11.09.2010, 15:13

@ travolter
 

Experimental Mplayer build from SVN

Post reply

> 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
Laaca

Homepage

Czech republic,
11.09.2010, 17:50

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

> > 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!
travolter

11.09.2010, 19:47

@ Laaca
 

Experimental Mplayer build from SVN

Post reply

> > > 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 ;)
Khusraw

E-mail

Bucharest, Romania,
11.09.2010, 19:58
(edited by Khusraw, 11.09.2010, 20:44)

@ Laaca
 

Experimental Mplayer build from SVN

Post reply

> 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
DOS386

12.09.2010, 03:14

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

> 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 ***
travolter

12.09.2010, 11:09

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

> 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.
oh.. I use always mplayer in my big computers and I always look for max speed...
do you know since what version mplayer is slower? I need to downgrade
Khusraw

E-mail

Bucharest, Romania,
18.09.2010, 13:01

@ Khusraw
 

Bug-fixed Mplayer build from the same SVN

Post reply

I just fixed in my Mplayer build a bug which prevented -vsync -framedrop to work correctly. I also added experimental svgalib video output support. You may download it for testing purposes from here : http://ompldr.org/vNWtwcw

---
Glory to God for all things
Laaca

Homepage

Czech republic,
19.09.2010, 11:37

@ Khusraw
 

Bug-fixed Mplayer build from the same SVN

Post reply

Fantastic!
I made quick test of SVGAlib output on my computer with ATI Mach 32 graphics card. It works out of the box.
The only issue is that it calls file LIBVGA.CFG in current directory, not in directory where is MPplayer.EXE. It should be fixed.

I will make more test on more computers.

---
DOS-u-akbar!
Khusraw

E-mail

Bucharest, Romania,
19.09.2010, 13:12
(edited by Khusraw, 19.09.2010, 15:33)

@ Laaca
 

Bug-fixed Mplayer build from the same SVN

Post reply

> I will make more test on more computers.
Only the video part from the LIBVGA.CFG matters, the rest is not implemented and ignored (i.e. no mouse, keyboard etc.), and the i810 chipset is also ignored. With some chipset drivers svga:vidix doesn't work, if vidix supports your card use always vesa as "graphics server" (Mplayer's vesa:vidix code is much better than the svga:vidix one). In case your card is not supported by svgalib's hardware accelerated drivers, again use -vo vesa instead of svgalib's vesa driver.

---
Glory to God for all things
Khusraw

E-mail

Bucharest, Romania,
19.09.2010, 15:02

@ Laaca
 

Bug-fixed Mplayer build from the same SVN

Post reply

> Fantastic!
> I made quick test of SVGAlib output on my computer with ATI Mach 32
> graphics card. It works out of the box.
> The only issue is that it calls file LIBVGA.CFG in current directory, not
> in directory where is MPplayer.EXE. It should be fixed.
This one should fix the problem: http://ompldr.org/vNWwxdg. Now it will look for the config file reading the SVGALIB_CARD environment variable (i.e. you should "set SVGALIB_CARD=drive:/path/configfile.ext"). If SVGALIB_CARD is not set it will try to open "C:/libvga.cfg". I don't want to make it search relative paths as svgalib's config file is intended to be used by more than one program.

---
Glory to God for all things
ron

Homepage E-mail

Australia,
20.09.2010, 00:56

@ Khusraw
 

Bug-fixed Mplayer build from the same SVN

Post reply

This one plays sound and vision in sync - except for large or high-definition vids.

And it does seem to produce a clearer picture. :)

A real improvement.

One blip, sometimes it seems reluctant to exit back to the CL and requires a Ctrl+C to close down after a video has finished.
Might be my system, can't be sure.

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

E-mail

Bucharest, Romania,
20.09.2010, 01:16

@ ron
 

Bug-fixed Mplayer build from the same SVN

Post reply

> This one plays sound and vision in sync - except for large or
> high-definition vids.
My building of Mplayer was an answer to DOS386 who recalls me my beloved students (sorry DOS386 if you are older than I think but you resemble perfectly my beloved students I worked with). I appreciate very much DOS386.

---
Glory to God for all things
Zyzzle

20.09.2010, 02:48

@ Khusraw
 

Bug-fixed Mplayer build from the same SVN

Post reply

> My building of Mplayer was an answer to DOS386 who recalls me my beloved
> students (sorry DOS386 if you are older than I think but you resemble
> perfectly my beloved students I worked with). I appreciate very much
> DOS386.
I think we all appreciate DOS386 and the contributions, support, and great benefit to the DOS community. There a few left in this world who realize that DOS can, and should be kept alive. It works, and works FAST and WELL!

Your latest build of MPLAYER works very well for me on all my systems (thanks for experimental svgalib and vidix support!). Sometimes I need to Ctrl-C out, too, but this isn't any problem for me, at least. Audio still doesn't work, but hopefully through WSS other cards will be easy to add in future. Noticed quite a bit of speed decrease between your newest builds and Miks 2008, but thankfully I have the CPU power to handle that bloat. Still, it's quite disconcerting as DOS386 has mentioned that the Mplayer team in only 2 years' time have managed to introduce so much blost / slowdown!
Rugxulo

Homepage

Usono,
20.09.2010, 04:21

@ Zyzzle
 

Bug-fixed Mplayer build from the same SVN

Post reply

> Still, it's quite disconcerting as DOS386 has mentioned that the Mplayer
> team in only 2 years' time have managed to introduce so much blost /
> slowdown!
It could be they are targeting different machines nowadays. Most people only test on common modern machines, not older ones. Or maybe they've fixed a lot of decoding bugs / glitches, so it's slower but more accurate. No easy way to tell. But surely neither x86 nor GCC is perfect, so I wouldn't put it past the dark corners of such complexity.
Khusraw

E-mail

Bucharest, Romania,
20.09.2010, 12:26
(edited by Khusraw, 20.09.2010, 12:43)

@ Zyzzle
 

Bug-fixed Mplayer build from the same SVN

Post reply

> Your latest build of MPLAYER works very well for me on all my systems
> (thanks for experimental svgalib and vidix support!). Sometimes I need to
> Ctrl-C out, too, but this isn't any problem for me, at least. Audio still
> doesn't work, but hopefully through WSS other cards will be easy to add in
> future. Noticed quite a bit of speed decrease between your newest builds
> and Miks 2008, but thankfully I have the CPU power to handle that bloat.
> Still, it's quite disconcerting as DOS386 has mentioned that the Mplayer
> team in only 2 years' time have managed to introduce so much blost /
> slowdown!
Newer SVN are even worse. I tried to build from a more recent SVN, finally I managed to, but a lot of things seem to be broken (beginning with runtime CPU detection), and besides they changed some code as they wouldn't have had something better to do. Anyway, I thank them for their work.

---
Glory to God for all things
RayeR

Homepage

CZ,
21.09.2010, 01:42

@ Khusraw
 

Bug-fixed Mplayer build from the same SVN

Post reply

This ver. works nice for me, but -vo svgalib seems to ignore vsync and looks bit slower but anyway I don't have supported chipset, just VBE so svgalib don't bring me any advantage. VESA output is OK with -vsync now.

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

Homepage

Czech republic,
21.09.2010, 07:39

@ RayeR
 

Bug-fixed Mplayer build from the same SVN

Post reply

Rayer, does it work with SBLive! emulation for you?
It seems I found a regresion - it does not work more with soundblaster cards and even freezes with loaded SBLive! emulation driver.

Even when I tested the precompiled WSS library it successfuly found integrated ICH4 AC97 but didn't find my SB emulation although the BLASTER environment variable was set and pointed to SBLive! with emulation drivers.
Can somebody else confirm it?

---
DOS-u-akbar!
RayeR

Homepage

CZ,
21.09.2010, 15:15

@ Laaca
 

Bug-fixed Mplayer build from the same SVN

Post reply

> Rayer, does it work with SBLive! emulation for you?
> It seems I found a regresion - it does not work more with soundblaster
> cards and even freezes with loaded SBLive! emulation driver.
No no, I'm just talking about video playback, sound doesn't work for me at all. Neither SB live nor ICH7/Realtek HDA. As I wrote I was trying to recompile WSS with VID, PID for SB live but there must be done more changes (1st difference I have seen that AC97 use 2 IO base address and SB live have only one so the detection function returned with fail immediatelly). Currently I don't have time to play with it.

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

Homepage

Czech republic,
21.09.2010, 16:31

@ RayeR
 

Bug-fixed Mplayer build from the same SVN

Post reply

> No no, I'm just talking about video playback, sound doesn't work for me at
> all. Neither SB live nor ICH7/Realtek HDA. As I wrote I was trying to
> recompile WSS with VID, PID for SB live but there must be done more changes
> (1st difference I have seen that AC97 use 2 IO base address and SB live
> have only one so the detection function returned with fail immediatelly).
> Currently I don't have time to play with it.
OK. And what happens if you plug your SBLive! into some pre-ICH6 computer?

---
DOS-u-akbar!
RayeR

Homepage

CZ,
21.09.2010, 23:15

@ Laaca
 

Bug-fixed Mplayer build from the same SVN

Post reply

> OK. And what happens if you plug your SBLive! into some pre-ICH6 computer?
I used it on Abit BX133 Raid before and there it worked fine. But BX/PII4X is very old. I could test it on http://rayer.ic.cz/hardware/azxab100.htm with ICH4 but it depends on correct NMI-SERR# routing that is used by emulation driver to trigger emulation service if legacy IO access will occur. So it needs to be tested on specific board regardless the chipset.

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

13.10.2010, 03:51

@ Khusraw
 

Experimental Mplayer build from SVN

Post reply

New minimal tests:


"MPlayer-rtm-svn-32198.7z" 6'675'920 Sherpya Win32
35F71DCB7188F344A51AEB60AD82CB1D

"mplayer.exe" 17'144'832 2010-09-12 08:16 Sherpya Win32
79867528F5942057EED09444345F5A50
> MPlayer Sherpya-SVN-r32198-4.2.5 (C) 2000-2010 MPlayer Team
> Usage:   mplayer [options] [url|path/]filename
"mplayer.exe" 5'597'400 Khusraw DGJPP
8393C08D9956D96560C71E832BD16F45
"http://ompldr.org/vNWwxdg"
> MPlayer SVN-r31981-snapshot-`gcc (C) 2000-2010 MPlayer Team
> Usage:   mplayer [options] [url|path/]filename

Sherpya:

+ Theora-BUG is fixed
- Arrow keys / seeking doesn't work anymore ... WtF :confused:
- no sound as usual
? Pentium-1 compatibility not tested

Khusraw:

- Theora-BUG still in (same r31981)
+ Arrow keys / seeking looks OK
- "-vo VESA" required - no longer the default ??? ... :confused:
? sound not tested on suitable PC
? sound vs video sync not tested on suitable PC
? Pentium-1 compatibility not tested
- strange apo still in (see above), more useful info could be:

> MPlayer SVN-r39999-snapshot (C) 2000-2010 MPlayer Team
> Compiled by Khusraw 2010-12-31 with DGJPP 2.0.5 / GCC 5.0.0 as rtm-CPUID
> Usage: mplayer [options] [url|path/]filename

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

15.10.2010, 04:27

@ DOS386
 

Experimental Mplayer build from SVN - Sherpya compiled 32492

Post reply

http://sourceforge.net/projects/mplayer-win32/files/

"MPlayer-rtm-svn-32492.7z" 6.7 MiB 2010-10-14

New Sherpya's binaries, I'll test. Maybe it would be a good idea to take some successful SVN version also used by Sherpya for future builds, I don't know how Sherpya picks his versions, though. This MPLAYER is a monster and it's painful enough to test it only, even if I'm not among those having the power to compile it from the source. Thanks to Sherpya and Khusraw.

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

17.11.2010, 05:18

@ DOS386
 

Experimental Mplayer build from SVN - Sherpya compiled 32492

Post reply

> http://sourceforge.net/projects/mplayer-win32/files/
> "MPlayer-rtm-svn-32492.7z" 6.7 MiB 2010-10-14
> New Sherpya's binaries, I'll test.
Done !!!

Tested

Win32 Sherpya MPlayer-rtm-svn-32492.7z | 17'225'728

against

"mplayer.zip" 5'203'892 | Mik | Glennmcc's preferred version "r27185" DGJPP
7F99'C4F7'C576'22ED'092C'B864'5E8E'C024
"http://glennmcc.org/download/mik/"
"mplayer.zip" -- 03/25/10 | 18:36 -- 5203892 bytes

MPD27185.EXE "mplayer.exe" 5'266'124 2008-07-03 10:43
UPX'ed with 3.02 | Mik | Glennmcc's preferred version
D4F3'5AD6'C701'817D'A5D2'4380'0E3C'8856

Results:

- Later is NOT slower (tested various audio and video codecs)

- On some codecs, output is bit identical

- For Vorbis, the output is inverted :confused: (but sounds same)

- For Theora, the big disaster is out: the old DGJPP binary has the Offset-BUG fixed, the new one is still unfixed. OTOH, the old binary has other bugs that the new one does not have (hanging with "invalid frame" , ...)

- Minor issue: new binary whines about "missing codec DLL" on WMV files (even if "-really-quiet" is specified), but plays OK

- Minor issue: old binary hangs on some ISA sound cards, must specify "-ao null"

- New binary works on Pentium 1, apparently even for MP0-XXX-264 videos

Conclusion: 32492 is a fairly good version only, the "best" one until someone finds something better :-|

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

14.02.2011, 11:30

@ DOS386
 

Experimental Mplayer build SVN | 1.0rc4 is out 2011-01-30

Post reply

Warning: bumped 3 months old thread

http://www.mplayerhq.hu/design7/news.html

2011-01-30, Sunday :: MPlayer 1.0rc4 released

MPlayer 1.0rc4: "Yes we can"

Decoders:
add new FourCCs (m1v1, yuvs, VYUY, Y42B, V422, YUNV, UYNV, UYNY, uyv1, 2Vu1, P422, HDYC, IJLV, MVJP) TwoCCs (0xA106, 0x6c75, 0xAAC0, 0x55005354) to existing decoders
AMR now handled via OpenCORE decoder
JPEG 2000 support via OpenJPEG
internal liba52 copy removed
VP8 en-/decoding through libvpx wrapper and native decoder in FFmpeg
support for external libmpeg2 added
hardware MPEG decoder priority lowered
external libmpg123 support

Demuxers:
Mostly fixed timing issues with some H.264 (PAFF) samples
Matroska and Ogg demuxers switched to use libavformat by default. Report issues and use -demuxer ogg and -demuxer mkv to work around them.
support for TrueHD in Blu-ray streams in libmpdemux
more Blu-ray codec support with lavf
fix length in ASF/WMV files
support ISDB-Tb DVB streams

Filters:
remove vf_yuy2, functionality is replaced by -vf format=yuv2
remove vf_rgb2bgr, functionality is replaced by sws and vf_format

Streaming:
Support for unencrypted Blu-ray playback through libbluray. Use it through: mplayer br:////path/to/disc

Drivers:
-vo yuv4mpeg:interlaced no longer does its own interlaced RGB->YUV conversion. Use -vf scale=::1 to keep the same behavior and report if there are any issues with that.
-vo md5sum md5 calculation changed so output matches FFmpeg's -f framemd5
Support for more formats in OpenGL video output drivers (different YUV subsampling, 16 bit per component)
Selectable YUV to RGB conversion standard for -vo gl (-vo gl:colorspace=...:levelconv=...)
-vo gl now tries to use yuv=2 by default if possible
-vo gl:stereo=... for experimental stereo (3D) support
-vo matrixview finally added

Other:
-nosub option for disabling auto-selected subtitles
support for displaying subs in the terminal (FIXME)
support for subtitles with audio-only files
support for right-to-left languages with embedded subtitles
support for UTF-16 encoded external subtitles
support for 8 channel audio
sync dvd:// and dvdnav:// features
support for MPEG-4 ASP in VDPAU video output (non-B-frame only)
support for live and non-live DVB teletext with demuxer lavf
-name, -title and -use-filename-title options for MPlayer
support for stream handling via FFmpeg, in particular RTMP and RTSP (use e.g. ffmpeg://http://example.com/test)
experimental support for external libass, pass '-disable-ass-internal' to configure
better support for 16-bit-per-component formats and formats with alpha channel
better out-of-the-box support for compiling for ARM, IA64, MinGW32 and MinGW-w64, MinGW has ASLR enabled with recent enough binutils
libdvdcss synced with upstream Subversion snapshot

MEncoder:
add -tsprog for demuxer lavf

just differences from this one:

2010-05-30, Sunday :: MPlayer 1.0rc3 released

MPlayer 1.0rc3: "BikeshedCounter AKA Godot"

1.0rc3 was intended to be rolled out over a year ago, but got delayed again and again. Since it is designed to be compatible with the FFmpeg 0.5 branch, it will be useful to distros and other users still tracking said branch. Thus we are now publishing it even though it is outdated even before the day of its release. For general usage current Subversion snapshots should be a better fit, as many bug fixes and new features are available.

No binaries, Sherpya has r32848 from 2011-02-04 instead. I'll test :-)

http://sourceforge.net/projects/mplayer-win32/files/MPlayer%20and%20MEncoder/revision%2032848/

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

17.02.2011, 06:51

@ DOS386
 

Experimental Mplayer build SVN | 1.0rc4 is out 2011-01-30

Post reply

> Sherpya has r32848 from 2011-02-04 instead. I'll test
Done!!! :-| There is a regression: XXX264/AVC decoder sometimes (???) crashes with CMOVNTQ (Pentium 1 with MMX). Old r32492 does not have this problem.

http://ompldr.org/vN2c4Mw/BALLMERA.FLV (3 MiB, crash after 92 frames)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
Back to index page
Thread view  Board view
22049 Postings in 2034 Threads, 396 registered users, 99 users online (0 registered, 99 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum