Draft: Ci/add opt tools debian/1
- Jan 19, 2021
-
-
Alexandre Janniaux authored2050a737
-
Alexandre Janniaux authored
This reverts commit 99b95d5f.
6a60bf96 -
Alexandre Janniaux authoredd274d11a
-
Alexandre Janniaux authored
Add /opt/tools in PATH to make the builtin cmake discoverable.
99b95d5f -
Steve Lhomme authored
By default the filter chains do nothing and are meant to output the same format as the decoder output. Now they can never exist without specifying their output format so we can detect changes, even when the filter chain was never used.
e3da0d14 -
Steve Lhomme authored
And keep the fixed format in sys->original unconditionally. If vout_Request() fails, it doesn't matter if we updated sys->original. The vout is not usable. And the format is cleaned in that case.
2077367a -
Steve Lhomme authored
The rest of vout_ReleaseDisplayAndFilters (formerly vout_ReleaseDisplayAndFilters) also deals with filters, mouse handling, decoder FIFO, etc. The display module is flushed unconditionally (effectively the converters filter chain). The sys->original video format is also released so we detect new inputs as a format change.
736ad81c -
Steve Lhomme authored
vout_Start is also handling filter setup. The function must be called under display lock. The crop and aspect ratio values need to be read under window lock.
2b54a764 -
Steve Lhomme authored61b38851
-
Steve Lhomme authored
Now that there is no mix up possible with displayed.next we can centralize the setting of this value. Rename ThreadDisplayPreparePicture() to ThreadDisplayPrerenderNext().
580b14db -
Steve Lhomme authored
And use sys->filter.changed to trigger ThreadChangeFilters() after we have a decoded picture to use. The picture_Hold is not because the core needs an extra hold but because the filter call may release the picture the core wants to keep.
ec12c2ed -
Steve Lhomme authored849da049
-
Steve Lhomme authored
It was always set when displayed.decoded was set. So we use displayed.decoded directly.
e9f44552 -
Steve Lhomme authored
In frame by frame we already read the picture to put it in displayed.current no matter what. But it was actually doing it twice for the first picture, possibly missing the first picture.
8603bfbf -
Steve Lhomme authoredb0cde744
-
Steve Lhomme authored
And no need to reuse displayed.next which is always NULL otherwise.
cb7f97ee -
Steve Lhomme authored1fcabd76
-
Steve Lhomme authored
Until now, in normal playback (ie not frame by frame), the way to skip to the next frame to display was : * get displayed.current * get displayed.next * if displayed.next has time to render use it to replace displayed.current * the vout thread waits until the deadline to render displayed.current Now we don't use displayed.next anymore. We keep the displayed.current as long as the "time to render" (the deadline to render - current time) is bigger than the time it takes to render (render_delay: average of previous frames + 4 ms tolerance). If there is not enough time, we try to get the next picture from the decoder+prerender. And we check if there's enough time to render that one. If there is not enough time, we try to get the next picture from the decoder+prerender. And so on... This allows having one picture about to be displayed in memory rather than 2 (displayed.current and displayed.next), which should be useful to decide when to change the display module (when displayed.current changes, not displayed.next). date_refresh is set to the render date of the next picture if there is one and the render date of the current picture otherwise. Before, the deadline was the date of the next picture even if we're sticking to the current picture. It would potentially start the rendering of the current picture too late. Now the (start render) deadline always corresponds to the date of displayed.current.
6f6ba9ce
-