There might still be some pictures left to display before we flush everything.

In pause mode we should still update the filters since the deinterlacing state
didn't change but the user added/removed some user filters.

The same logic should also be applied when fully draining pictures before
updating filters.

First we peek the decoded picture from the FIFO. It the aspect ratio has
changed we use the pictures remaining in the filters, as long as they are not
late.
If there is no more picture left in the filters we change the filter and
actually pop the decoded picture from the FIFO.

They only do one call each. Let's do the call directly.

In full draining we don't use already decoded pictures, only pictures drained
from the filters.

The reused picture happens when the decoding+display starts or after a flush.

In the former case it's possible the decoder took some time and we have fresher
pictures available.

In the latter case the kept decoded picture may be very old and we shouldn't be
reusing if it's late.

In both cases, there will be fresher ones coming if the one left was too late.

The filter producing the drained pictures may be very slow and return pictures
too late.

The static filter may be slow and the returned picture may be late.

And invert the boolean on calls.
This is easier to read.

And rename ThreadDisplayPreparePicture to ThreadGetPrerenderedLocked

This type of draining is usually done before flushing (discontinuity) or before
closing a filter modules.

For now only the "in-line" draining is used.

Ref #12155

The goal of this piece of code is to make sure we use
ThreadDisplayPreparePicture with a displayed.current. It doesn't matter if it's
the first or not. It won't be the first after a flush, for example. We don't
need a temporary variable which is more confusing.

ThreadDisplayPreparePicture with reuse will either use the picture remaining in
the static filter chain, reuse the kept decoded+prepared picture if there is
one, or get a picture from the decoder and prepare it. This picture is then
set in displayed.current, since it was NULL.

Now the p_next can only be used for picture chains, not chained pictures in one
output.

It was only temporary until we can properly drain pictures from filters. Now a
filter must never return chained pictures. It must implement a drain instead.

- FilterChainVideoFilter
- FilterDeletePictures
- pending picture chain

In the past the drained pictures were stored in chained_filter_t::pending. Now
they are either drained explicitly (filter_chain_VideoDrain) or dropped as
they used to before doing a new filter call.

Filtering with a NULL picture is no longer allowed.

From the last filter in the chain to the first we:

- drain to get a picture
- if there is a picture we use it to filter it
- if we have a picture from running all the filters, we return it
- otherwise we try again to drain the filter that produced a picture
- if that filter doesn't produce a picture anymore, we try the previous filter
  in the chain

No functional changes

Loop while there are pictures to encode.

- Start by filtering the first picture through each filter chain, and encode
the result.
- Then drain the first (non-null) filter chain and pass the result through
the other filter chain, and encode the result.
- Then drain the second (non-null) filter chain and pass the result through
the other filter chain, and encode the result.
- And so on, until there is no more filtered pictures to encode.

The draining is done after the picture filtering. This is equivalent to how
a picture was returned with all the chained pictures.

filter_chain_VideoFilter does the same part as filter_chain_VideoFilter() when
called with a NULL picture.

For now filter_chain_VideoFilter() still handles the case where a NULL picture
is used.

Fix the source picture was released after turning it into a MMAL_BUFFER_HEADER_T.
Not sure how this could work.

The while loop to create output picture is turned into single calls. One in the
filter function and others in the drain calls.
The assert done before returning a valid picture is moved up in the Filter
callback.

We no longer return pictures chained using vlc_picture_chain_AppendChain().

We no longer return pictures chained using vlc_picture_chain_AppendChain().

The original code was returning the source picture, with a few metadata changed
and a secondary picture attached.

The secondary picture, with a different date, is prepared during the drain. We
keep a reference to the primary picture while waiting for the drain. This kept
picture is released during a Flush or on Close.

The last_pts that was used locally when chaining picture is kept as
prev_last_pts to generate the secondary picture(s) during the drain.

The picture used to create secondary pictures (cur) is kept as long as pictures
are produced by the drain. It comes from the picture history so it will be
released from there.

cur_frame was either 0 (primary output) or 1 (secondary output). The value is
used the same way in the filter and drain functions.

The i_field_dur duration shift is only done for the drained picture.

We no longer return pictures chained using vlc_picture_chain_AppendChain().

Each filter using the common deinterlacing code now calls DoDrain (similar to
DoDeinterlacing) to do its draining.

We no longer return pictures chained using vlc_picture_chain_AppendChain().

DoDraining calls DoDeinterlacing internally with a NULL input picture. To
create secondary pictures, the state to create the same pictures that were
appended before is kept in the filter p_sys. The prev_pic is the original
picture used to create the primary and secondary pictures. The picture is
released when there is no more pictures to produce from this picture or during
a Flush.

Now DoDeinterlacing() only outputs one picture at a time. By default it outputs
the current_field == 0 picture, then extra pictures up to max_fields.

The p_previous_pic keeps the picture that was returned by Filter(), which is
the basis for the extra pictures created during the drain, by incrementing by
one "framerate tick" each output. We need to keep a reference as the output
picture might be released by the caller, before the drain is called.

We keep the original date of the incoming picture so we can compare to the
"framerate" ticks to know if we need extra pictures or not.

When expanding the frame rate, we have the following output:
- pic0 -> original date
       -> original date + tick 1
- pic1 -> original date + tick 2
       -> original date + tick 3
- pic2 -> original date + tick 4
       -> original date + tick 5

The date of the incoming picture is always included in the last output
frame date + duration.

The code assumes that enough drain calls will be done until the next filter
call. (A flush in between is good as well)

We no longer return pictures chained using vlc_picture_chain_AppendChain().

If pictures are far in the future without a flush we fill the gap with extra
pictures according to the "framerate" tick.

Otherwise that code was never called since the condition to reset the clock was
the same used to produce extra pictures.