Not entirely. We know how the storage is calculated, and it is exploitable. For instance, a -1 video width will crash the decoder. This is due to how it initializes the variable.
Code:
video->displayWidth = (tmpvar + 1) << 2;
video->width = (video->displayWidth + 15) & -16;
Essentially your display width (the active screen area) is over scanned by 1, while the video itself is over scanned by 15, then underscanned by 16. A -1 video width would result in a screen scan of 0, and a video scan of -2. As there is no protection against underflowing (at least I didn't see one), any negative value would really **** this script up, either outright crashing it, or storing the entire video in RAM, which via the size calculator in the script (width*mb / vert*mb) would severely overflow the size calculation into a negative number, and because negative storage is impossible, it could very well panic the kernel, and allow unsigned code to be executed.