Lyndon Brown authored 5 years ago and Rémi Denis-Courmont committed 4 years ago

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Lyndon Brown authored 5 years ago and Rémi Denis-Courmont committed 4 years ago

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Lyndon Brown authored 5 years ago and Rémi Denis-Courmont committed 4 years ago

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Lyndon Brown authored 4 years ago and Rémi Denis-Courmont committed 4 years ago

every option should have a short text label for use in help output and
preference interfaces.

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

This message is not helpful for the average user.

By default p_next is always set to NULL in a picture. We can always use it as
a proper picture chain.

When a chain becomes empty p_next goes back to zero and the "known tail" is
invalid. But we only use the tail when the front is not empty, so there is no
problem.

Since the snapshot keeps a reference to the picture to export, it's not made
available to the decoder until the export is done. It's better to release
pictures in the receiving order to match the decoder.

Received pictures are chained in ret_pics, first directly then through the
chain_tail local variable which keeps track of the tail of the picture chain.

pf->head represents the picture chain and pf->tail the tail that is used to
append pictures.

p_sys->p_previous_pic represents the picture chain.

id->fifo.pic.first represents the picture chain and id->fifo.pic.tail the tail
that is used to append pictures.

Rather than a pointer on the last picture pointer, we use either NULL (no
tail/chain empty) or a pointer to the last picture in the chain.

Make sure that the pictures we queue don't have a p_next otherwise it would
screw the computation of the last. (the issue existed before this patch)

fifo->first represents the picture chain and fifo->tail the tail that is used
to append pictures.

Rather than a pointer on the last picture pointer, we use either NULL (no
tail/chain empty) or a pointer to the last picture in the chain.

Make sure that the pictures we queue don't have a p_next otherwise it would
screw the computation of the last. (the issue existed before this patch)

We always check what to do with the picture rather than the the picture chain.

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.

p_es->p_picture represents the picture chain and p_es->chain_tail the tail that
is used to append pictures.

Rather than a pointer on the last picture pointer, we use either NULL (no
tail/chain empty) or a pointer to the last picture in the chain.

This makes the code less dependent on how picture chains are stored.

Picture chains are used either to keep a list of picture (in FIFO order) or to
attach a picture to another and return them all at once (filters).

With older versions of mingw-w64, the d3d12 configure test
fails and the plugin is disabled automatically, but with the
very latest versions, it is enabled.

Building this plugin requires fixes for running fxc.exe when
cross compiling, similar to what's done for the main qtbase build.

If a second master was created, the first one was automatically
downgraded without notifying the owner.

This was never the case since es_out.c, the only clock client (for now)
is always ensuring that only one master is created.

The es_out is never changing the clock type for now. If it is needed in
the future, delete() + new() could be a good solution.

  vlc_media_tree_Preparse will only notify about newly found entry. If entries
  are already in the tree they won't show up.