Yes, I believe this is true. There is visual corruption; if I do not do pause the input at least 1 time, it will never correct itself.
Pausing the playback seems to correct it.
After having moved to 185.18, there is far less corruption on the screen. However, I now know how to distinguish "tearing" from corruption. The 185.18 driver has significant more tearing in the play back. It looks as if the screen is ripped right down the middle, horizontally.
I will be going back to the 180.51 driver since I have not found a way to get the tearing to quit, where the corruption can be corrected with a pause of the playback. I guess the ffmpeg may not be seeking to the correct I-Frame or some other marker in the TS stream...
Originally Posted by Stephen Warren
Sorry, I didn't mean the clip was corrupt, but that the decoded result showed visual corruption.
This almost sounds normal; any time one jumps into the middle of a stream, if one isn't careful to jump to a legal "reference frame", then the decoded result may be corrupted.
Also note that MythTV contains a very old snapshot of ffmpeg, which is certainly missing some fixes for the code that calls VDPAU. This might also be related to your issue. I believe somebody is working on pulling in a new fffmpeg into MythTV, but I have no idea about the status of that project.