this is not a question. I simply want to show (to whom interested in) my pure assembly MPEG1/MPEG2/VOB Player without any DirectX, MCI, ActiveX and other shit. Just parse, decode and play

My wish: if you want to waste some time with playing MPEGs just do it and tell me if you find it usefull. Any comments highly appreciated.

Tnanxs in advance

Bye Miracle
(maybe a good topic for the crusades ;-)
Posted on 2001-09-21 11:14:51 by miracle
Pretty cool I must say, but you shouldn't use peekmessage, but instead getmessage and a timerproc so you don't waste so much CPU time, but that's just my opinion.
Posted on 2001-09-21 14:58:40 by Kenny
i must agree with kenny , it is pertty cool. but it can br cooler if you do it open source.
or just keep working on that
(add some functions)


Posted on 2001-09-22 14:02:02 by eko
thats well good.
i was expecting no sound or dodgy framerate but thats great!!
keep up the good work!

Posted on 2001-09-22 17:07:43 by skud
Since you said you use no ActiveX or anything, I was expecting crap. But its actually really cool. Its only missing the normal stuff (play, stop, etc)
Posted on 2001-09-22 20:03:41 by ChimpFace9000
Try to open multiple instances of this player vs. multiple instances of another?
Posted on 2001-09-22 21:55:41 by bitRAKE
Pretty impresive indeed, but i have to act as a critic for a moment. I found it to be a bit choppy on a 800 AMD Durron with 256MB ram, and a 32Mb G-Force 2 card. I think it has alot to do with the loop discussion earlier by Kenny. As it was very periodic when it 'stalled' between frames.. (about every 3 seconds). As well ending a MPEG hangs on the same frames, repeating them over and over, while playing the normal back ground music frames over and over.

I dont what to rub you the wrong way here. I think this is quite impressive and a bit of a triumph for 32 ASM coding, but i thought i would give back constructive feedback as i have seen it.

Keep up the good work..
Posted on 2001-09-23 02:04:16 by NaN
Heh... no fullscreen, resizing is messed up (but not disabled), cpu
usage is 100%, and no playback controls. I think I'll stick with media
player (good old mplayer2.exe) for some time yet.

But it looks pretty interesting, miracle. Keep working on it and it will
probably end up as something good (I supposed the 100% CPU
usage is because of PeekMessage vs. GetMessage).

As for "without any DirectX, MCI, ActiveX and other shit"... well, it
would be nice to support DirectDraw so you can go fullscreen, and
take advantage of nice hardware features such as filtered stretching.
Posted on 2001-09-23 10:46:37 by f0dder
could you post the source? i wouldnt even have any idea where to start if i wanted to program something such as an mpeg player or a wav / mp3 whatever player.

and i just noticed you said VOB player... arent they DVD's?

Posted on 2001-09-23 14:40:15 by skud
You know, this could make a great tutorial.
Posted on 2001-09-23 15:41:14 by ChimpFace9000
Hi to all,

thanxs for all that interestings comments.
Some things want to say now:

Kenny (and others): The reason why I always consumpt (waste) 100% cpu time is that the timing for the video display process is far from good.
I tried many things. The actual solution is as the follows. I do timeGetTime(), pares stream, decode picture, display picture, add the frame delay to the time got formerly, if this process was faster than the frame rate I loop over timeGetTime() until the time is right to continue. Pretty ugly - I see. Maybe one of you have more ideas.

eko: I am not that familar with OPEN Source. I dont have a problem to public the sources now, but I will use this code for an own 'closed' commercial project too. Is there a conflict with any licence term. Do I neeed my own one?

f0dder: Yes, the DDraw version is already finished. IT's much faster because the gfx-card can do the YCbCr2RGB conversion. A fullscreen blit also is possible easily, but there are man restrictions (multiple of 32 in width etc.) I keep work on it.

Skud: A VOB-file (from a DVD) is the same like a MPEG2 file except the sound (maybe AC3) is not stored as a regular sound stream. Normally as a private stream because AC3 or dolby sound is not from MPEG.

NaN: Know this problem of playing the last frames in an endless loop. Will fix this soon.

ChimpFace9000: I agree. Maybe the time will come:cool:

Thanxs, Bye Miracle
Posted on 2001-09-24 04:00:58 by miracle
Miracle, there are a few ways to go OpenSource. You need to pick
one where other people don't take advantage of you and you work :).
The GNU GPL and LGPL licenses are probably the most widely known.
The GPL basically means that you, and anybody else, can use your
source for commercial work, *but*... everybody will have to supply
the full source code of their app. The LPGL is less restrictive, it would
eg allow the use of your mpeg decoding routines, and require anybody
who makes modifications to your routines to supply source, but the
rest of the app can be closed-source. Or at least that's how I understood
the licenses.

There are other licenses available as well. You could try snooping
around on www.fsf.org and www.opensource.org.
Posted on 2001-09-24 07:11:15 by f0dder
Hi miracle, wonderful program.

Regarding the loop, one quick and dirty fix is to stick an invoke Sleep,1 into that GetTickCount loop. You'd be surprised how helpful it would be.

Second regarding the source. If you're going to make a comercial app then it would be safer to stay away from the liscences unless you fully understand them.

What if you released the source but copyright it as yours and provide absolutly no premission for the source to be used by anyone, for any reason.

That would give you come back if someone tried to rob it and screw you but it would also allow you also to turn a blind eye on genuine people here who just want to read the source to learn.

P.S. If you made it work with DivX you have a real winner.
Posted on 2001-09-24 07:59:24 by Eóin
To make it work with DivX, it would probably be insane to use anything
but the codecs :). Otherwise, if you feel up to the task of an asm
implementation of DivX decoding... contact the DivX team and give
them a helping hand, and *everybody* will benefit :].
Posted on 2001-09-24 08:08:53 by f0dder

will test Sleep(1) and give feedback if it's exact enough.

Regarding Open Source:
If anyone is interested in, send an email
to mailto:Info@dp4.de and I will send you
the sources.

Bye Miracle
Posted on 2001-09-24 08:27:54 by miracle
Sleep is NOT very accurate. On 9x, I think it's precision is around 53ms.
A lot better on NT/2k, but still not enough. It's ok to make a thread
sleep a little, though.
Posted on 2001-09-24 08:48:37 by f0dder
Which is why once again Getmessage is better...

I almost always use it and a timer now because I don't want 100% CPU usage on stuff I make :)
Posted on 2001-09-24 11:18:15 by Kenny
Very, very impressive!
Posted on 2001-09-24 17:52:03 by comrade
Kenny, the problem is that he needs to maintain a specific framerate. I wasn't aware that sleep is so inaccurate on win9x but I do know that timers are as well.

You're limited to a max frame rate of about 18 which is grand if thats the most you'll need, but for this program I'm not sure it is.
Posted on 2001-09-25 12:49:26 by Eóin
I'm not sure it will help, but I have this idea that windows biases
"processor usage" *very* much on your message loop... after all,
it says a program is hung if it hasn't called GetMessage or PeekMessage
for some time.

So, try setting up an additional thread for the timer work, this might
change how windows views the processor usage :). For syncing,
if necessary, use a critical section, as they are pretty efficient... when
a thread doesn't need to "block" on it (ie, the CS is not already "taken"),
the code paths are entirely user-space, unlike the various other
synchronization objects.
Posted on 2001-09-25 12:59:19 by f0dder