The config "advanced" flag was unused and has been removed by
6a7a137f7b.
It has been removed from many add_*() macros, but not all. Remove it
from the remaining macros.
Move the use of -rpath '$(foodir)' into a macro that can be
conditionnally defined. It allows the variable to be conditionally
defined, which will be used to actually remove the -rpath option for
static builds.
No functional changes.
When filters like deinterlace are returning multiple pictures, forcing
the filtering of the second picture in a filter chain can be done by
calling filter_chain_VideoFilter with NULL.
Without this, additional pictures are dropped instead of being filtered
and encoded.
Some encoders, like MediaCodec, provide SPS/PPS packets only when
decoding is started (in pf_encode_video). This is too late, because the
muxer is already open.
To avoid the problem, add the stream only when the encoder output format
is known.
where identical to shorttext, or near enough.
bad because:
- wastes resources.
- useless tooltips in prefs GUI (poor UX) - tooltip longtext should add
something of value.
- useless repetition of text in certain help output.
in some cases they differed only in full-stop, creating unnecessary extra
burden on translators.
The fps filter must be added when the target framerate is different
from the source framerate, not when we define the fps parameter.
We also check that fps.den > 0 to avoid divide-by-zero errors.
Probably regression from 030183d790 in
which the target framerate was defined in the destination format.
Use it via transcode_encoder_video_set_src() which does a bit more.
As opposed to before we set the output dimensions as the ones from the input,
not the other way around.
Don't use previously set values on the output format which have no good
significance. The format requested by the user is the combination of source
format + user configuration.
Set better encoder fmt_out values that the user configuration (which may be 0).
The transcode_video_size_config_apply() and transcode_video_scale_apply() calls
should give consistent results regardless of what width/height were previously
set on the output video_format_t.
The 16 pixels horizontal alignment was never done since the i_visible_width/height
was always set. Now we do it on the coded values, not the visible values. In the
end the encoder should tell which alignment it wants on the input.
The coded size is deduced from the actual visible sizes that will be used.
The visible width/height is still forced to the even values. Even though
it should be up to the encoder to tell if it can't support odd dimensions.
The width/height configured by the user are applied even if there's only one of
them (fixes Chromecast rescaling), and only if there's no user scaling.
df0a715f3f assumed the converter would do the
scaling, in addition to codec/chroma converters and orientation. But the code
to do it properly was missing.
We do not update the encoder source format anymore when the static/user filters
are added. The encoder should still encode at the size requested, regardless of
the extra filters. It may however use a different input codec/chroma if this
one wasn't forced.
The converter is always adapting between the decoder output (with the video
context in the picture) and the encoder input.
Fixes#25362
The two fields of the union have types demux_t and stream_t, which are
the same type (demux_t is a typedef of stream_t).
Signed-off-by: Thomas Guillem <thomas@gllm.fr>
Romain Vimont
Alexandre Janniaux
Lyndon Brown
Tristan Matthews
Alaric Senat
Steve Lhomme
Rémi Denis-Courmont
Francois Cartegnie