home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2490 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  1.7 KB
  1. Path: Hermes.grace.irl.cri.nz!maths!peterm
  2. From: peterm@maths.grace.cri.nz (Peter McGavin)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Is a real good mpeg player possible on the amiga ?
  5. Date: 31 Jan 1996 22:22:50 GMT
  6. Organization: Industrial Research Ltd
  7. Message-ID: <PETERM.96Feb1112250@tui.maths.irl.cri.nz>
  8. References: <4e2gqu$5ca@caers3.unicaen.fr> <4e2o57$5a2@serpens.rhein.de>
  9.     <574.6598T297T795@login.eunet.no> <4e7n75$krh@serpens.rhein.de>
  10.     <386.6603T1404T1784@login.eunet.no>
  11. NNTP-Posting-Host: tui.grace.cri.nz
  12. In-reply-to: patrick.hanevold@login.eunet.no's message of 31 Jan 1996 18:48:35
  13.     GMT
  14.  
  15. patrick.hanevold@login.eunet.no (Patrick Hanevold) writes:
  16. >>>There is FLIC players around that is just as slow as MP.
  17. >>Does this say anything ?
  18. >Yes. They happen to be coded very slow. Just like MP.
  19. >Maby some asm would help a little?
  20.  
  21. I tried compiling the Unix mpeg_play v1.2 first with optimised SAS/C,
  22. then later with optimised GNU C, with appropriate changes for CGraphX
  23. (no c2p).  In both cases the result ran about twice as slow as mp103.
  24. Rewriting the critical parts in asm would probably achieve about the
  25. same speed as mp103.  To get significantly more speed, we need a
  26. faster algorithm (if one exists), I think.
  27.  
  28. I haven't followed all the details, but I can see that mpeg_play
  29. calculates YUV for each frame in one buffer, then converts it to RGB
  30. in another buffer, then finally renders it to the display device (in
  31. my case with cybergraphics.library WritePixelArray()).  It is
  32. conceivable that combining these operations could save a lot of memory
  33. reads/writes.  Unfortunately I can't see how to do it because the YUV
  34. and RGB frames are calculated in non-sequential order and saved in
  35. buffers until they are needed.
  36. -- 
  37. Peter McGavin.   (p.mcgavin@irl.cri.nz)
  38.