I was just about to suggest a thread, then f0dder posted :)

What I was thinking is this:

make a new time critical thread that is a timer and this timer calls WM_PAINT at the frame rate of the movie, and then there is a third thread that is LOW priority that is in the bacground decoding the next two frames, and then all the main program does is blit the decoded to the display every time the WM_PAINT message occures.
Posted on 2001-09-25 14:19:32 by Kenny
all this stuff is way too advanced for me :)
but id like a general idea of whats going on.
do you update it by taking a frame from the mpeg (how you get this frame im not too worried about as i cant even begin to understand :) ) and then effectively updating the window at a given interval with the next bmp in series so its like a big flick book of bmp's? thats what ive understood anyway :P
correct me if im wrong; which i probably am ;)

Posted on 2001-09-25 15:23:30 by skud
I wouldn't use a time critical thread... get it wrong, and your whole
system becomes VERY sluggish :). High priority perhaps, but at least
let the user set the level.

And what about looking at "overlays"? I have no idea how they
work, but seeing as most good video players support them, there
just might be some advantage :].
Posted on 2001-09-25 15:47:44 by f0dder
Hi to all,

let me give a short explanation of the problems I have:

first synchronizing output of video frames to current frame rate: (23.976 Hz .. 60 Hz)
This part is relatively easy. My first idea was to sync the output occording to the display vertical refresh rate. So I created a thread monitoring when the beam starts painting a new frame on the display. Unfortunately not even a highest priority thread is able to do this job. Next idea was the use of a timer. Normal timer (SetTimer()) is far from exact. timeBeginPeriod() etc also, isn't it? That way I get the current time via timeGetTime() and do the parsing, decoding and displaying part. Now I have to possibilities. First I was to slow, that means I have to skip some frames now. Second I was to fast so I have to wait a few milliseconds. And thats the problem. Lets say I wanna wait 4 ms, so I go into a loop over timeGetTime() until the 4 ms are gone. Thats real shit, but it works. A call of Sleep() is not exact enough.

second problem: synchronizing of audio and video
- quite ugly. The best idea I guess is to use the audio as a time master. Because the ears are more sensitive to detect interrupts when playing.
Putting the audio and video decoding in a separate thread causes a periodic delay in one of both threads. I will need some research to find out what combination runs well on a large variety of systems.

third problem: changing the priority of threads or even a process does not have much effect. Very ugly. My experience is to leave the priority untouched and wait what happened.

fourth problem: the use of DirectDraw using overlays is no big deal. It works fine and is really fast. But, there are many restrictions because of capabilities of the graphics card. So I want a plain version using BitBlt() which is very slow.

Okay, I don't want to public boring stuff about the hell of writing a mpegplayer.
;). Feel free to contact me If you have ideas, comments or whatever.

Great board, nice community, keep on coding

Bye Miracle
Posted on 2001-09-27 07:52:46 by miracle
Hi Skud,

Once you have loaded your mpegfile you have to check whether it contains audio and video or only one of them.

Video decoding part (general steps):

- parse the bitstream
- synchronize to next picture in stream
- get header and do the huffmann decoding
- check motion compensation stuff
- inverse discrete cosine transform
- dequantize and some other shit
- copying of the blocks to the YCbCr planes
- converting of YCbCr to RGB

It's a big piece of shit. If you want to get info, search the net for ISO/IEC 11172-2 or 13818-2 which describes the MPEG video coding and decoding. If you check www.whotsit.org for MPEG you will get the 13818-x standard as word document. It's nice to see.

Bye Miracle
Posted on 2001-09-27 08:06:23 by miracle
I mean www.wotsit.org :stupid:
Posted on 2001-09-27 08:10:41 by miracle

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.
By the way.. what if in my application (e.g. a game or a demo) I do not have a message loop? What side effects will happen, other than the mouse pointer looking "busy" and not handling messages? Note that this is for a fullscreen DirectX application.

Second thing: will anything ever "corrupt" the data that is below ESP, if I have only one thread and use no timer callbacks, etc..?
Posted on 2002-03-23 06:52:52 by Maverick
Excuse me, but what ya all are talking about? :)
I mean, I'm not able to see any attached file. Though
in list of threads I see sign of attachment.
Can I somehow download this super app?
Posted on 2002-03-23 07:25:50 by The Svin
The Svin: It's an old post (september '01) so the maximum attachment lifetime is probably expired.. weird that it still shows a paperclip though.
Maybe the original poster can attach it again?

Posted on 2002-03-23 07:38:32 by Thomas
did he ever give out the source to anybody? the dude is crazy if he made an MPEG decoder in assembly
Posted on 2006-04-19 23:29:10 by comrade
People have made jpeg decoders in assembly, *shrug*. Iirc ewald (friend of Scali) was working on an asm mpeg decoder and even got pretty far. Oh well.
Posted on 2006-04-20 05:02:09 by f0dder

the dude is crazy if he made an MPEG decoder in assembly

Thanks, for the flowers. 8)

Posted on 2006-07-10 10:28:47 by miracle
umm, I made a jpeg encoder and decoder in assembly.
But I never done a Mpeg in assembly, this gives me
something to try.

And sence I have already wrote encoder and decoder's for
GIF,JPG,PNG,TIFF, A MPEG one would be nice for me to

Posted on 2006-07-10 22:41:54 by Zcoder
If you want to achieve decent performace you should create an overlay (Direct3D9.0c) with YCbCr colorspace and bitblt the decompressed YCbCr image onto it. The hardware will change the color space (YCbCr -> RGB) during rasterization. Iirc, DX9 calls this color space "YUV". And be sure NOT to use the standard IDCT algorithm which is dead slow.
Posted on 2006-07-11 06:20:35 by ti_mo_n

umm, I made a jpeg encoder and decoder in assembly.
But I never done a Mpeg in assembly, this gives me
something to try.

There is no big difference between JPEG and MPEG. I-Frame-only decoding in a way is even simpler, because MPEG uses only 'hardwired' huffman code tables. The new concept while decoding P- and B-Frames is 'motion compensation' which means copying on a per macroblock basis from other frames and handling 'prediction errors'. No big deal.

A good start is to google for ISO/IEC 11172-2 (MPEG-1 Video) and ISO/IEC 13818 (MPEG-2 Video). It's usually fine to start firsthand with MPEG-2 since there are only slight changes and extensions between them.

Unfortunately a MPEG-4 and MPEG-4 Part 10 (aka H.264 alias AVC) video decoder cannot benefit from the above code. Is there anyone going to spent time on this?

Cheers, Axel
Posted on 2006-07-17 01:19:44 by miracle
Try to resurrect/extend this old-but-interesting topic around video (MPEG) decoding in pure assembly.

A KolibriOS kernel developer pointed me to MenuetOS' DVD movie player that claims:
DVD player is sold separately because MPEG patents
require a fee for delivered decoders. Free or open
source software are no exception.

So i replied:
Well, I don't know about license issues, I believe that you can refer to FFmpeg ones...

BTW it would be really great to have a pure assembly video decoder, IMHO.

If you're scared about MPEG-LA, then support royality-free/open source codecs:

    [*]Vorbis for lossy audio (THE mp3 competitor - check out the Ogg Vorbis acceleration project that introduced asm-optimizations into the codec);
    [*]FLAC for lossless audio;
    [*]Theora for streaming video (the "comparable" XviD competitor, included in the next FireFox version);
    [*]Dirac for HD video (the h264 competitor);
    [*]Huffyuv for lossless video;

Posted on 2009-01-17 05:43:13 by forart.eu