This shouldn't actually be necessary, since the sample iterator will
resume from where it hit the error last anyway. Now that the decoded
data producers don't clear their queues when the demuxer doesn't move,
this works just fine for EOF.
This could easily be triggered by scrubbing aborting reads to restart
seeks, which would force us to decode from a prior keyframe instead of
continuing to decode from where the last seek left off if it's faster.