{"id":1606,"date":"2009-06-16T21:49:18","date_gmt":"2009-06-17T04:49:18","guid":{"rendered":"http:\/\/multimedia.cx\/eggs\/?p=1606"},"modified":"2009-06-16T21:49:18","modified_gmt":"2009-06-17T04:49:18","slug":"perceptual-video-testing","status":"publish","type":"post","link":"https:\/\/multimedia.cx\/eggs\/perceptual-video-testing\/","title":{"rendered":"Perceptual Video Testing"},"content":{"rendered":"

While I have thought a lot about the problem of testing perceptual audio decoders in FFmpeg<\/a> via FATE<\/a>, I have put little thought into testing perceptual video decoders. I surmise that my 1-off testing method<\/a> for perceptual audio decoders is probably not tractable for video decoders. I suspect that, while rounding errors also cause off-by-1 errors in video decoders, compounded errors during multiple frames could stretch the threshold. There’s also the minor matter that it would require a much larger amount of space to store raw video data vs. the audio data required for the perceptual audio tests.<\/p>\n

Testing video decoders isn’t such a big deal, though. The FFmpeg devs have had this problem solved via the ‘make test’ regression suite for a long time. There are a few flags to tack onto a command line which will invoke a bit exact inverse discrete cosine transform (IDCT). The trade-off is that optimized IDCT code paths are not exercised.<\/p>\n

I’m thinking of a 2-part solution:<\/p>\n

    \n
  1. As a first pass, enter video decoding tests that leverage the bit exact IDCT.<\/li>\n
  2. As a second pass, craft special test cases that decode one frame of video and leverage the default, optimized IDCT. Test the result using the 1-off method.<\/li>\n<\/ol>\n

    See Also:<\/strong><\/p>\n