{"id":1826,"date":"2009-09-19T23:30:04","date_gmt":"2009-09-20T06:30:04","guid":{"rendered":"http:\/\/multimedia.cx\/eggs\/?p=1826"},"modified":"2009-09-22T14:46:48","modified_gmt":"2009-09-22T21:46:48","slug":"optimizing-away-arrows","status":"publish","type":"post","link":"https:\/\/multimedia.cx\/eggs\/optimizing-away-arrows\/","title":{"rendered":"Optimizing Away Arrows"},"content":{"rendered":"

Google released the third version of their year-old Chrome browser<\/a> this past week. This reminded me that they incorporate FFmpeg<\/a> into the software (and thanks to the devs for making various fixes available to us<\/a>). Chrome uses FFmpeg for decoding HTML5\/video tag-type video and accompanying audio. This always makes me wonder, why would they use FFmpeg’s Theora decoder? It sucks. I should know; I wrote it.<\/em><\/p>\n

Last year, Reimar discovered<\/a> that the VP3\/Theora decoder spent the vast majority of its time decoding the coefficient stream. He proposed a fix that made it faster. I got a chance to check out the decoder tonight and profile it with OProfile<\/a> and FFmpeg’s own internal timer facilities. It turns out that the function named unpack_vlcs() is still responsible for 44-50% of the decoding time, depending on machine and sample file. This is mildly disconcerting considering the significant amount of effort I put forth to even make it that fast (it took a lot of VLC magic).<\/p>\n

So a function in a multimedia program is slow? Well, throw assembly language and SIMD instructions at the problem! Right? It’s not that simple with entropy decoders.<\/p>\n

Reimar had a good idea in his patch and I took it to its logical conclusion: Optimize away the arrows, i.e., structure dereferences. The function insists on repeatedly grabbing items out of arrays from a context structure. Thus, create local pointers to the same array and save a bunch of dereferences through each of the innumerable iterations.<\/p>\n

Results were positive– both OProfile and the TSC-based internal counter showed notable improvements.<\/p>\n

Ideas for further improvements: Multithreading is all the rage for video decoders these days. Unfortunately, entropy decoding is always a serial proposition. However, VP3\/Theora is in a unique position to take advantage of another multithreading opportunity: It could call reverse_dc_prediction() in a separate thread after all the DC coefficients are decoded. Finally, an upside to the algorithm’s unorthodox bitstream format! According to my OProfile reports, reverse_dc_prediction() consistently takes around 6-7% of the decode time. So it would probably be of benefit to remove that from the primary thread which would be busy with the AC coefficients.<\/p>\n

Taking advantage of multiple threads would likely help with the render_slice() function. One thing at a time, though. Wish me luck with presenting the de-dereferencing patch to the list.<\/p>\n","protected":false},"excerpt":{"rendered":"

Banish dereferences from inner loops<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[28,33],"tags":[],"class_list":["post-1826","post","type-post","status-publish","format-standard","hentry","category-programming","category-vp3theora"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\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