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.

Calls to filter a picture should be proceeded by a drain call to make sure
there is no picture left from the last picture filtered.

Filters calling vlc_picture_chain_AppendChain() should implement a drain of
their extra pictures instead.

An extra inverted picture is sent for every picture given.

Interactive/User filters are allowed to output more than one frame at a time.
(it could also be deinterlacers or fps filters added manually)

This introduces some timing differences in the processing time we use to adjust
the estimated display time. The drain may be faster or slower than the regular
filtering call.

Filter (chains) that only output one picture at the time won't be affected.

Before this patch, extra pictures from interactive filters were simply dropped
and never displayed.

It may be possible to start in frame by frame mode. Normally we read the next
frame and replace the current frame with it. But if there was no frame we
should return when the first frame is read, not when the second frame replaced
the first one.

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. If the
filtered picture is dropped we keep looping to find a non NULL filtered picture
or no picture at all.

If the frame is dropped, the picture is released and we continue looping until
there's a decoded picture that is not late or no decoded picture at all.

No functional changes.

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

Only use the p_sys->is_late_dropped when needed.

And rename ThreadDisplayPreparePicture to ThreadGetPrerenderedLocked as it's
returning a (pre-rendered) picture and doesn't display or prepare anything.

First if a re-display is needed. And then if the current frame has changed it
doesn't need to be displayed ASAP, we know it's within the render delay.

Merge force_refresh and render_now since they mean the same thing.

The rendering will happen anyway. The flag tells we must not wait and do it
right away.

In the non-frame_by_frame mode. Sometimes we skip the current frame and use the
next frame.

We should actually loop in the "next" frames available until the last one
that still have time to display.

Renamed drop_next_frame to dropped_current_frame so it's clearer that it
already happened.

Simply add "if (frame_by_frame) {} else {}" and double the code. Then simplify
the code for always true or always false conditions.

in the end it's clear the frame_by_frame part only gets the next picture to set
in the current one (and reuse the store displayed.next if there was one).

force_refresh is set to true when frame_by_frame is true, so we can simplify
the is_forced test. (it was false before but is_forced would end up true anyway).

And only check the "late" value if we can drop frames.

is_late_dropped doesn't need to use the pause state, now they are exclusive.

If the value is set we never read it.
If the value is not set we read it. Then the loop exits, regardless if we got a
value or not.

Let ThreadDisplayPicture decide what to do with it.

In the first call sys->displayed.current is NULL, so that's always the value
read. We can copy the assert on sys->displayed.next from the original code.

In the second call sys->displayed.current is never NULL, so we already read
the sys->displayed.next value. The assert on sys->displayed.next from the
original code is not needed.
The while loop was ending if ThreadDisplayPreparePicture didn't return SUCCESS
so that's when sys->displayed.next is read as NULL.

It doesn't return a boolean.

At this stage paused will not be used anymore. No need to set the value.

Only keep the "else" part of the "if".