{"id":456,"date":"2007-09-03T21:12:03","date_gmt":"2007-09-04T04:12:03","guid":{"rendered":"http:\/\/multimedia.cx\/eggs\/compiled-duck\/"},"modified":"2007-09-03T22:03:50","modified_gmt":"2007-09-04T05:03:50","slug":"compiled-duck","status":"publish","type":"post","link":"https:\/\/multimedia.cx\/eggs\/compiled-duck\/","title":{"rendered":"Compiled Duck"},"content":{"rendered":"

I actually got the original Duck TM1<\/a> decoder compiled and hooked up to a small test bench app. It even runs without crashing. However, it produces unequivocally incorrect output:<\/p>\n


\n\"Bad
\n<\/center><\/p>\n

I was expecting something more in a solid white for this particular frame. This doesn’t exhibit the normal Duck TM1 bidirectional artifacts that I’m used to seeing. I also wired up a number of different blitting calls with both 16- and 24-bit data, to no avail.<\/p>\n

I’ll give the API calls another look to see if I’m missing anything obvious in that department (this approach is unlikely to bear fruit, considering the dearth of documentation). Failing that, I might find myself in the ironic position of using libavcodec’s native Duck TM1 decoder to verify the operation of the original decoder to see what is going wrong with files that are known to work correctly in lavc, so that the original decoder will work completely and yield clues about the large body of problem TM1 files.<\/p>\n

Addendum:<\/em> I decided to enlist Valgrind’s<\/a> assistance against the adversary. This is the first time I have touched the utility in awhile. Let’s see what it has to say…<\/p>\n

\r\n  valgrind: the 'impossible' happened:\r\n     Killed by fatal signal\r\n<\/pre>\n
I’m not sure what to think about that. Should I feel proud? Fortunately, leading up to the impossible condition are plenty of other memory errors, all ripe for investigation.<\/p>\n","protected":false},"excerpt":{"rendered":"
I actually got the original Duck TM1 decoder compiled and hooked up to a small test bench app. It even runs without crashing. However, it produces unequivocally incorrect output: I was expecting something more in a solid white for this particular frame. This doesn’t exhibit the normal Duck TM1 bidirectional artifacts that I’m used to […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7,4],"tags":[],"class_list":["post-456","post","type-post","status-publish","format-standard","hentry","category-on2duck","category-reverse-engineering"],"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