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".

If next_system_pts is INT64_MAX the date_next value cannot be computed
correctly.

Probably missing from 23d2a4cc.

Rather than something looking like a delay.

Those strings are read directly by the mac OS to show some reason
in ressource request dialogs.

The strings for NSAppleEventsUsageDescription, NSCameraUsageDescription
and NSMicrophoneUsageDescription are mandatory, otherwise the
application will crash.

InfoPlist.strings needs to be translated to show localized variants
of those strings.

refs #21378

The translation file should not need to be generated by the build
system to allow more simple translation. In this case the string
cannot be reconstructed during runtime (its read out by the OS),
thus drop the translation.

picture_HasChainedPics() should be avoided if possible

The build is failing as some symbols are duplicated in libopus.

This fixes the (mostly harmless but nevertheless undefined behaviour)
data race on the output file descriptor.

This is simpler and faster (as we get line buffering for free).

(no functional changes)