mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-10 19:31:12 +00:00
bf849e9a69
This is part of a much larger goal to always keep the frames we schedule to decklink be always increasing. This also allows us to avoid using both the sync and async frame display functions which aren't recomended to be used together. If the output timestatmsp is not always increasing decklink seems to hold onto the latest frame and may cause a flash in the output if the played sequence has a framerate less than the video output. Scenario is play for N seconds, pause, flushing seek to some other position, play again. Each of the play sequences would normally start at 0 with the decklink time. As a result, the latest frame from the previous sequence is kept alive waiting for it's timestamp to pass before either dropping (if a subsequent frame in the new sequence overrides it) or displayed causing the out of place frame to be displayed. This is also supported by the debug logs from the decklink video sink element where a ScheduledFrameCompleted() callback would not occur for the frame until the above had happened. It was timing related as to whether the frame was displayed based on the decklink refresh cycle (which seems to be 16ms here), when the frame was scheduled by the sink and the difference between the 'time since vblank' of the two play requests (and thus start times of scheduled playback). https://bugzilla.gnome.org/show_bug.cgi?id=797130 |
||
|---|---|---|
| .. | ||
| acmenc | ||
| acmmp3dec | ||
| androidmedia | ||
| applemedia | ||
| bluez | ||
| d3dvideosink | ||
| decklink | ||
| directsound | ||
| dshowdecwrapper | ||
| dshowsrcwrapper | ||
| dshowvideosink | ||
| dvb | ||
| fbdev | ||
| ipcpipeline | ||
| kms | ||
| msdk | ||
| nvdec | ||
| nvenc | ||
| opensles | ||
| shm | ||
| tinyalsa | ||
| uvch264 | ||
| vcd | ||
| vdpau | ||
| wasapi | ||
| winks | ||
| winscreencap | ||
| Makefile.am | ||
| meson.build | ||