gstv4l2videodec.c: fix to merged item !2517 to allow "fluster test" with out-of-order frames to succeed
@ming.qian in a comment on !2517 (merged) (merged) notes that it breaks a "fluster test" for certain drivers that sends video frames in unusual orders not starting with frame 0.
The problem fixed in !2517 (merged) was that a Caps renegotiation triggered a driver bug where the driver incorrectly dropped the initial frames, leaving them to be dropped one-by-one (with error-messages spamming each time) once they were 100 frames older than current frame.
The fix in !2517 (merged) dropped the "lost frames" (all together, with a single error message) the first time an undropped frame is successfully dequeued from the driver.
@ming.qian reported that a "fluster test" which send frames in order 2,1,0,5,4,3.... fails because it doesnt match the assumption that frames dequeue in order of increasing frame number.
Solution is to postpone the cleanup till frame 100 is received, as prior to !2517 (merged). Consecutive pending frames starting with frame 0 will be removed in one go, if the oldest pending frame is frame 0 when the current frame is frame 100.
A merge request !3398 (merged) has been submitted.