Not sure if video player needs a target. Its task is to keep the various stages: decoding, deinterlacing/filter, output busy. Every stage can queue some frames. If the buffers are full, the task can go sleep. 

Lateness detection before render stage does not work very well because at this stage it needs to make assumptions about the future. Video/Audio renderers should calculate the error when they render a frame and feeed this information back to players. Ideally players attach pts to the frame. Trying to guess an absolute time is error prone, i.e. we audio changes the clock at start, video schedules a pic to be rendered in 500ms, audio changes the clock back, this does not change anything the the frames already scheduled.

Assume a couple of frames in each stage. Now renderer tells us that last frame rendererd was X ms late. We look at the entire queue in order to decide what's best. The error may have been already corrected by dropping a deint cycle. That's what this change does, it remembers the actions already taken.

What you think about tracking render error of a/v in the clock object?