GNOME Bugzilla – Bug 685279
DVD still frames need a way to never be dropped by QOS
Last modified: 2018-11-03 12:16:12 UTC
If playback is running late (because things are slow coming off the disc, or any of the usual CPU-busy reasons) then DVD still frames can get dropped - and the presentation will pause and show whichever was the last frame to make it to the DVD SPU, making menus look weird (button highlights on some random intro frame). To fix it, I think we need a buffer flag 'GST_BUFFER_FLAG_NOT_DROPPABLE' that can be set on a frame by the MPEG decoder. I think (from memory, may be wrong) it is required that all still frames be an I frame followed by an END packet, so an MPEG decoder could store a ref to the most recent keyframe, and output the frame when seeing an inbound still frame event, setting the NOT_DROPPABLE flag. I think it would have to do this unconditionally though, as downstream elements (might have dropped the frame). Alternatively, the MPEG decoder could always set the NOT_DROPPABLE frame on outbound keyframes. Comments?
There appears to be a GST_BUFFER_FLAG_DROPPABLE already, which is the opposite of what we want. Maybe we should make decoders mark all output as DROPPABLE and then make the QoS mechanism never drop stuff that's not marked as such? (Would need more places where that flag would need to be set). Question is if that change in behaviour of sinks is acceptable, or if we do need to add NON_DROPPABLE.
Let's go for the GST_BUFFER_FLAG_NOT_DROPPABLE approach then? Could also be a video-specific STILL_FRAME one, but that might be awkward to check for in the basetransform baseclass in core that presumably does the dropping. Could do both and map STILL_FRAME to NON_DROPPABLE of course.
There was an event (gst_video_event_new_still_frame/gst_video_event_parse_still_frame) that is sent when it's time start a still-frame sequence (and again when it's finished), but in DVD the frame which we should display is the one preceding the still-frame notification from the DVD VM. That's what leads to the description in comment-1 - we need the decoder to repeat the most recent frame, but ensure that it is not going to be dropped this time (in case it was dropped the first time it was sent).
Right, and we don't want to make all elements in the chain keep state for this either.
sorry for my noob question, but will a fix for this bug solve many dvd video lags that currently occurs in totem video player?
Strangiato: Depends what exactly you mean, but this bug is more about a corner case where a frame might not be displayed at all because it gets dropped when it shouldn't be dropped. "Lag" sounds like frames are displayed too late, so something else. I would suggest you file a new bug about that.
Jan, can we (upstream, decoder) know if we're "in a Menu" or not? If yes, maybe we can just make the decoder flag keyframes as non-droppable while in menus.
No, I don't think so. Some sequences (like playing a promo video on the way into the main presentation) might use still frames. They're not a "menu specific" thing - and the concept of being in the 'menu' is tenuous anyway.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/30.