{"id":505,"date":"2008-01-22T20:52:44","date_gmt":"2008-01-23T04:52:44","guid":{"rendered":"http:\/\/multimedia.cx\/eggs\/success-in-failure\/"},"modified":"2008-01-22T20:52:44","modified_gmt":"2008-01-23T04:52:44","slug":"success-in-failure","status":"publish","type":"post","link":"https:\/\/multimedia.cx\/eggs\/success-in-failure\/","title":{"rendered":"Success In Failure"},"content":{"rendered":"

I’m ecstatic that the FATE Server<\/a> has demonstrated its first real success by highlighting a failure. Specifically, the system already caught a discrepancy in a new test designated alg-mm<\/a>. This tests the American Laser Games MM<\/a> file format. FATE did precisely what I wanted in that it was able to report that the demux operation worked, the PCM audio data was all there, but that the video frames were decoding differently on different CPU architectures.<\/p>\n

What, did you think that I was really carrying out this FATE project for the general benefit of FFmpeg<\/a> and its users? Ha! Now we come to the real, fiendish<\/em><\/strong> rationale behind FATE: to make sure all of the lesser known modules (read: fringe, game-related formats) in the project remain operational over time. How many times have I returned to an old fringe format in FFmpeg after a long absence and found that it broke during one of many API upgrades? In fact, that’s precisely why I have been hesitant to repair any breakages I have found in the past 1.5 years (when I first started brainstorming what would become FATE) because I wanted this test infrastructure in place to notify me of further breakages.<\/p>\n

I investigated the alg-mm issue further and it appears that each frame also has its palette prepended. The palette is stored in native endian format, which is obviously causing trouble for automated testing. Palette handling is a longstanding issue in FFmpeg that has yet to be solved and also falls outside the scope of the immediate task of getting as many working<\/em> tests into the database at the outset as possible. As such, I have disabled the test for now. Fortunately, I should feel more motivated to develop proper palette handling later on once I am confident that future breakages will be detected early.<\/p>\n

Anyway, I have started adding more tests, beginning with the bit exact tests in the good old QuickTime Surge audio suite<\/a> (a particular audio sample encoded in just about every audio format QuickTime supports). Now I am ready to move on to the next big challenge that I knew this project would present– how to test data that is not defined to decode in a bit exact manner. A prime example is MP3 audio data.<\/p>\n

I have been told to look at tiny_psnr.c for this exercise.<\/p>\n","protected":false},"excerpt":{"rendered":"

I’m ecstatic that the FATE Server has demonstrated its first real success by highlighting a failure. Specifically, the system already caught a discrepancy in a new test designated alg-mm. This tests the American Laser Games MM file format. FATE did precisely what I wanted in that it was able to report that the demux operation […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[101],"tags":[],"class_list":["post-505","post","type-post","status-publish","format-standard","hentry","category-fate-server"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t