GNOME Bugzilla – Bug 794192
videodecoder: Event order may get mixed up
Last modified: 2018-05-01 08:30:54 UTC
Created attachment 369480 [details] [review] videodecoder-keep-event-order.patch If the videodecoder has multiple frames to push out it may happen that the queued events are pushed out in wrong order. This issue was observed with image-orientation tag events. A broken event order my result in a final invalid rotation.
Comment on attachment 369480 [details] [review] videodecoder-keep-event-order.patch This seems correct, but a test would be nice. I'm not sure if the loop in gst_video_decoder_flush_parse() also needs to be changed to use g_list_prepend() instead of _append(), can you check? The loop for pushing out all events walks from the last to the first event, so newer events have to be added to the beginning.
Regarding gst_video_decoder_flush_parse() I'm also not really sure. I recognized this issue when feeding live data via an appsrc into the pipeline (additionally the occurrence was strongly dependent on timing). Since gst_video_decoder_flush_parse() seems to be only used for reverse playback I can't really test it with my setup. Maybe you have an idea how to test and verify it?
About gst_video_decoder_flush_parse(): I'm not sure if this should be changed: Only events '<= segment' are considered. 'flush-stop' and 'stream-start' are forwarded immediately, and caps events are consumed. So in reality this loop only handles segment events. I'm not sure if we can have more than one segment event here. I don't think that would work correctly.
Created attachment 371153 [details] [review] videodecoder: add test for event order When frames are dropped or reordered then the serialized events are collected and pushed with the next frame. This test verifies that the order is preserved.
Attachment 371153 [details] pushed as 1b36477 - videodecoder: add test for event order Attachment 369480 [details] pushed as 41c6efb - videodecoder-keep-event-order.patch