Sunrise, thanks for the file. I was able to reproduce and fix this. This was not a performance problem (that would manifest differently - the video would play normally for small periods of time, and then stopp to rebuffer). It would also be noticeable in the log.
The problem here was caused by the fact that Microsoft VC1 decoder expects decoding instead of presentation timestamps in the input. We've been feeding it presentation timestamps (which is the normal thing to do), but as a result it gave output with wrong timestamps. That means frames out of order, which we have to ignore and which results in video that sort of stutters.
It seems that for last version I've only tested VC1 in Microsoft containers (and matroska), which only store DTS, so it worked fine. But for container such as MPEG TS which has properly timestamped stream it did not. It will in next update.
Great, thanks for fixing it, seems the time to dig into that bug was worth it. As soon as a build is available I will test and report back.
I have another question (not related to the above):
Yesterday I wanted to download one video that was created with Handbrake x264 with preset placebo (H.264 and AAC audio) in an MP4 container to my iPhone 5s without transcoding it. I have therefore activated passthrough "whenever possible" so that it doesn't get transcoded. Air Video HD however sees that the file has 16 reference frames and tells me that only 15 reference frames are supported. What exactly does supported mean in this case? Is that a hardcoded value or do you get these properties from the API of the iPhone 5s itself?
I am asking, since I wanted to test the capabilities of the iPhone 5s and also to retain quality and play these files as is, so I don't want to transcode it at all cost, I want native playback. Is there a way around that and can you allow 16 reference frames?