winegstream reintroduce parser flushing

[Zebediah Figura]

On 5/19/22 15:30, Zlice Z wrote:
> Sent a patch yesterday that was mediocre and barely helps.
> 
> commit
> https://github.com/wine-mirror/wine/commit/5144b27661fcd6705353d832e0383085f8afe842#
> 
> removed flushing from parser, which after commit bisecting turns out to be
> the cause of Fallout 3 radio chugging every new song.
> 
> - re-introduced parser flushing (self explanatory, commit said it's not
> worth it but it helps here)
> 
> - moved some variable initialization in wm_reader.c to after initial
> conditional returns. these were in a switch-case before in the middle of
> the function and it seems to be part of the stuttering, wasn't moved in the
> mentioned commit though
> 
> - commented out and left my name by some EOS sets. they used to be checked
> for EOS 'events' but those references have been changed to 'buffer' and idk
> what the right action is. wine seemed to randomly seg fault on exit with
> leaving them on though. suspect they incorrectly guess and set 'end of
> stream' ?
> 

I don't think "reintroduce flushing" is the right answer here, not 
without understanding why it matters.

The point of 5144b2766 is that flushing should not make a difference. It 
allows wg_parser_stream_get_event() to return more quickly, but that 
same cost is added to the subsequent seek or stop request, so 
GST_Seeking_SetPositions() or parser_cleanup_stream() will end up taking 
just as long.

If flushing does make a difference, I think we need to understand why, 
and quite likely solve this a different way.