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.

The close callback is now typed instead of a vlc_object_t.

Co-authored-by: Alexandre Janniaux <ajanni@videolabs.io>

Getting the front of the picture chain and settings the picture chain to the
rest of the chain is exactly like popping a picture from the front of the chain.

Filters created with aout_filter_Create() already check the structure pointer
is not NULL.

Alexandre Janniaux authored Aug 25, 2020 and Steve Lhomme committed Oct 08, 2020

Generate a simple operations structure for filters generating their own filter
callback via VIDEO_FILTER_WRAPPER().

The filter chain sets a mouse handler on video filters that don't have one,
just as before, by using a local version of the ops structure of the filter and
adding the local mouse callback.

Co-authored-by: Steve Lhomme <robux4@ycbcr.xyz>

This requires picture_GetAndResetChain to return the same type.

chained_filter_t::pending represents the picture chain coming from incoming
pictures. It is set using vlc_picture_chain_get_and_reset() which removes a whole
picture chain from a picture, unlike vlc_picture_chain_PopFront which pops only
one picture.

We pass the new state and we received the modified value in the same variable.

Avoid some boiler plate copy for filters not modifying the output.

sys = chain is guaranteed to be non-null since it's a callback from a
filter_chain_t but the underlying owner can be left zero-initialized in
case there is no decoder device, or dec-dev=none is set so it cannot be
deferenced without checking it first.

Similar to how we get the current output video format.

It will be passed to the first filter when it's created.

It is only set when calling filter_chain_Reset() and no filter has been added yet.

We should not be using the filter chain unless filter_chain_Reset() has been called.

For now it's NULL for the first filter as we don't receive it yet.

Typically used when a CPU to GPU converter is used. It cannot deduce the decoder
device or the video context from the input. Since we are pushing the video
context we don't want to get it from the output/environment either.

When the callback is not provided, a NULL decoder device is returned.

No functional change.

The last output format is always the format of the last filter. It doesn't
matter if it was allowed to change the format or not. It's either the filter
added or the "chain" filter added to compensate for the format change (should
be adjusted in push mode)

This is how filter_chain_GetFmtOut() is documented "last output format of the
last element in the filter chain" and how it's used.

If there's no filter yet, the output format is the one used to initialize the
filter chain (via filter_chain_Reset).

The filter chain itself doesn't automatically adapt the output format to the
requested output format, which is good for push.

Use the local variable set on the whole chain rather than the value set on each
filter.

filter_chain_Reset is reserved for restating new input/output formats and does
not allow empty format anymore.

filter_chain_Clear doesn't change the input/output formats, only remove all the
filters.

This way we can use filter_NewPicture() which will use the allocator of
the filter if there is one.

Set the whole video_filter_owner_t back and forth to pretend it's the real
"owner".

Remove the container_of inline function only used once.

spu filters don't set an owner for the filter chain (for now)

That's only field of the structure that was used

SPU doesn't use callbacks to get the subpictures from an the owner.

If new callbacks are added we want to know (warning or error) if some owners
don't handle the new callback.

Similar to filter_chain_NewVideo() as this is the only use of this supposedly
generic function.

Also fix the function documentation.

Objects have one strong reference held by their "owner", and zero or
more weak references generated by vlc_object_hold() et al. This
provides a separate function to remove the strong reference than
vlc_object_release() to remove weak ones.

With this sole change, this is really only an annotation though.

Keep a copy of vlc_tick_tfor backward compatibility.

Nothing cares about the actual length if it is non-zero. Also constify.