>i have another suggestion: we may call decoder->flush() when
>BUF_CONTROL_END is received. is that ok?
If the comments in code are correct, no. /xine-lib/src/libmpeg2/decode.c:
//* flush must never allocate any frame (get_frame/duplicate_frame).
* it is called from inside video_out loop and frame allocation
* may cause some (rare) deadlocks.
I'm used to distinguish the two processes:
1. Flush, meaning that component should process any data pending.
2. Flush, meaning discard all the data pending as soon as possible and
get ready for new data.
The second is used for positioning to prepare decoder for new data, and
when user requires to stop (or abort). The first is used primarily for
encoders, when all incoming frames must appear in encoded stream, and
source component signals that the last sample has been transmitted.
Xine has 2 methods for case 1 - flush() and reset(). Some components use
flush() to display the last frame (libmpeg2), some just ignore it
(libffmpeg). And one method for 2 which is not used yet.
I think parallels with DirectShow are applicable to Xine. DirectShow has
3 methods - EndOfStream() (1), BeginFlush()/EndFlush() (2). Reset() is
implemented implicitly via discontinuity flag, and also EndFlush()
implies Reset() as well.
IMHO it would be wise to specify what behavior is expected by Xine
components on flush(), reset() and BUF_CONTROL_END. I would probably
regard flush() as way (1) flush (process pending data), but for the time
being the comment above confuses me.