home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / compress / research / 401 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  1.4 KB
  1. Path: sparky!uunet!pipex!unipalm!uknet!bhamcs!mother!ahp
  2. From: ahp@cs.bham.ac.uk (Anthony H Phillips)
  3. Newsgroups: comp.compression.research
  4. Subject: DCT optimisation
  5. Message-ID: <C1L49B.9ML@cs.bham.ac.uk>
  6. Date: 28 Jan 93 22:10:22 GMT
  7. Sender: news@cs.bham.ac.uk
  8. Reply-To: ahp@cs.bham.ac.uk
  9. Organization: The University of Birmingham Computer Science Department.
  10. Lines: 13
  11. Nntp-Posting-Host: mother
  12.  
  13. I am a final year undergraduate doing a software engineering project in Digital Video.
  14. I have implemented a number of image compression algorithms that run on Sun Unix
  15. workstations, among these is a JPEG and MPEG codec. I should immediately add that these
  16. are not true compliant codecs but merely abstract the core ideas present in them. The
  17. problem I have is that I am currently using the standard fast DCT algorithm, but even
  18. with the speed of a Sun/4 processor I cannot get more than a frame a second at 160 by
  19. 120 image size. I have already scaled the algorithm into integer maths that helped a
  20. lot but I am stuck for the next move. I have also implemented a fairly sophisticated
  21. motion estimation system which allows me to miss out well matched blocks completely
  22. if the error between the motion estimated blocks and the actual block is below a given
  23. threshold, this obviously presents one way of speeding up the process by simply not
  24. doing an inverse DCT on every block !
  25. Any thoughts and ideas would be greatly appreciated. Anthony Phillips.
  26.