While there are no cases at the moment (and hopefully ever), there is
technically nothing to say that the access output must return a
constant value. By caching the value, we ensure that we will not create
an imbalance between increments and decrements.
Just like in the video output, the user filters should adapt to the source,
better than they should adapt to the encoder. In particular, hardware support
will be favored in more cases.
Just like in the video output, the last converter chain is responsible to adapt
the decoded + prerendered + filtered pictures to the encoder requested input
format (see osys->converters display.c).
In the end we have the same filters as the video output: static, user, final
converter.
With the orientation changes done outside of the p_conv_nonstatic, this filter
cahin was always NULL (b_orient always false).
This is also how the display modules work, the orientation is usually done
while rendering the picture.
The p_final_conv_static filter is also the one that produces pictures on which
we render subpictures, which is when the reorientation is forced.
If b_do_orient is true we returned VLC_EGENERIC a few lines above.
So b_do_orient is false, so we will return VLC_SUCCESS no matter what the
values of b_do_chroma and b_do_scale are.
not having a cat+subcat specified means that the options were ignored
when constructing the preferences tree in Qt (and possibly others).
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
not having a cat+subcat specified means that the options were ignored
when constructing the preferences tree in Qt (and possibly others).
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
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.
Rémi Denis-Courmont
Lyndon Brown
Steve Lhomme