GNOME Bugzilla – Bug 745962
don't destroy and create decoder for each seek
Last modified: 2015-06-19 09:18:57 UTC
The purpose of flush() vmethod is to remove the internal buffers in the decoder, but the configuration of the decoder remains equal. Hence there's no need to create and destroy the decoder.
Created attachment 298985 [details] [review] vaapidecode: drop queued frames when flush() The flush operation intent to discard all remaining data from the decoder without pushing it downstream. This implies discard all the queued frames in the decoder. This patch drop all the frames in processing queue. This makes, in general, the seek operation faster. In the case of playback rate increasing or decreasing, the first frame to play will depend on the demuxer, because some will repeat some buffers already played. * The vmethod flush() is now the old method internal_flush(). * The vmethod finish() is modified to use decoder's flush, not the new vmethod. * The method reset_full() is modified since hard parameter is not used.
Created attachment 299092 [details] [review] vaapidecode: drop queued frames when flush() The flush operation intent to discard all remaining data from the decoder without pushing it downstream. This implies discard all the queued frames in the decoder. This patch drop all the frames in processing queue. This makes, in general, the seek operation faster. In the case of playback rate increasing or decreasing, the first frame to play will depend on the demuxer, because some will repeat some buffers already played. * The vmethod flush() is now the old method internal_flush(). * The vmethod finish() is modified to use decoder's flush, not the new vmethod. * The method reset_full() is modified since hard parameter is not used. v2: 1) call gst_video_decoder_have_frame() in finish() vmethod and refactor it improving readability
Created attachment 299095 [details] [review] vaapidecode: drop queued frames when flush() The flush operation intent to discard all remaining data from the decoder without pushing it downstream. This implies discard all the queued frames in the decoder. This patch drop all the frames in processing queue. This makes, in general, the seek operation faster. In the case of playback rate increasing or decreasing, the first frame to play will depend on the demuxer, because some will repeat some buffers already played. * The vmethod flush() is now the old method internal_flush(). * The vmethod finish() is modified to use decoder's flush, not the new vmethod. * The method reset_full() is modified since hard parameter is not used. v2: 1) call gst_video_decoder_have_frame() in finish() vmethod and refactor it improving readability
Created attachment 302053 [details] [review] vaapidecode: don't destroy and create decoder at flush The flush operation intent to discard all remaining data from the decoder without pushing it downstream. This implies discard all the queued frames in the decoder. This patch drop all the frames in processing queue, but avoids the destruction of the decoder. This makes, in general, the seek operation faster. In the case of playback rate increasing or decreasing, the first frame to play will depend on the demuxer, because some will repeat some buffers already played. * The vmethod flush() is now the old method internal_flush(). * The vmethod finish() is modified to use decoder's flush, not the new vmethod. * The method reset_full() is modified since hard parameter is not used. v2: 1) call gst_video_decoder_have_frame() in finish() vmethod and refactor it improving readability v3: 1) rebased, 2) use the method gst_vaapidecode_purge(), 3) verify the return of gst_video_decoder_have_frame()
Created attachment 302054 [details] [review] decoder: vc1: ignore broken surfaces This patch is required since at flushing some broken surfaces appear.
Though I have worked a lot in these patches, I have realized that, particularly for VC1 decoding, the decoder must be recreated at when flushing, otherwise there are horrible artifacts. Perhaps something can be done in the lower levels, but it is not a big issue right now. Hence, I'll reject these patches, closing this report as NOT A BUG.