If DNH's underlying structure for arrays was a sort of usual dynamic array, then the longer it would take to create the array as the size gets larger, since you can't specify how large the array will be on instantiation and then it would have to restructure by doubling and copying or whatever when it reaches max internal size, which would happen somewhat "often" with large enough arrays. However, arrays in DNH don't seem to even be usual dynamic arrays because apparently the larger the element's index the longer it takes to retrieve, leading me to believe it's a type of linked structure. So on top of addition/deletion taking a lot of time, memory access also doesn't take the expected O(1) time for arrays, which yes, would mean that the longer the video the crappier it would run even without considering other factors.
The "easier" way is just naming the images better and bypassing the need for the array
//make render object
ascent(i in 0..numfiles){
img = dir ~ atoi(i) ~ ".png"; //where files are named 0.png, 1.png, etc
//load, change texture, draw
}or something
But more than that, creating massive arrays for such a purpose is a terrible idea, and really you shouldn't even want to play a video in the background in DNH, never mind using a dumb workaround like drawing individual png frames.