The ctxi_dst variable is unused outside of the av_assert1,
causing an unused variable warning. The simplest solution
for this is to avoid the intermediate variable here.
Ref https://trac.ffmpeg.org/ticket/11152
According to harfbuzz docs, hb_ft_font_set_funcs() does not need to be
called, as, quoted:
```
An #hb_font_t object created with hb_ft_font_create()
is preconfigured for FreeType font functions and does not
require this function to be used.
```
Using this function seems to cause memory management issues between
harfbuzz and freetype, and could be eliminated.
This commit also call hb_ft_font_changed() when the underlying FC_Face
changes size, as stated on hardbuzz:
```
HarfBuzz also provides a utility function called hb_ft_font_changed() that you should call
whenever you have altered the properties of your underlying FT_Face, as well as a hb_ft_get_face()
that you can call on an hb_font_t font object to fetch its underlying FT_Face.
```
Finally, the execution order between hb_font_destroy() and
hb_buffer_destroy() is flipped to match the order of creation of
the respective objects.
Signed-off-by: Leandro Santiago <leandrosansilva@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
The logic did not follow the documented behaviour and that caused skipping of
some audio in the loop and in the leftover buffer.
Example command line which should produce a smooth sine wave for the whole
duration of the output:
ffmpeg -f lavfi -i "sine=r=48000:f=480:d=4" -af "aloop=loop=4:start=48000:size=48000" out.wav
Fixes ticket #11283.
Signed-off-by: Marton Balint <cus@passwd.hu>
If the audio loop stops inside an audio frame, the leftover buffer contains the
end of the frame, which is not looped. The length supposed to be the part which
was not written to the loop buffer, so we need to drain exactly that number of
bytes from the leftover buffer.
Signed-off-by: Marton Balint <cus@passwd.hu>
Setting it was broken in 8160178dfc, since
links are not yet set up during init. It is also redundant, as the
struct also stores the input index.
Reported-By: llyyr <llyyr.public@gmail.com>
The crop filter has no effect on scale_cuda:
-vf crop=100:100,scale_cuda=100x100
Hardware frames (AV_PIX_FMT_FLAG_HWACCEL) are expected to use the crop_* properties,
as seen in the implementation vf_crop.c.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Ensure those bits are copied, which will result in the output being the same as
the input, where swscale set them to the equivalent of fully opaque.
Signed-off-by: James Almer <jamrial@gmail.com>
As specified in libass's ass_types.h, the colors or ASS_Images
should be converted to YCbCr using the matrix/range specified in
the track's YCbCrMatrix field (unless that field is set to YCBCR_NONE,
and defaulting to TV.601 if the header is missing).
This does not affect any subtitles generated or transcoded by ffmpeg,
since these contain a 'YCbCrMatrix: None' header.
Signed-off-by: arch1t3cht <arch1t3cht@gmail.com>
Signed-off-by: rcombs <rcombs@rcombs.me>
When using **integer** images inside shaders, it turns out
that conversion doesn't automatically happen, but we need to
explicitly use the imageviews to get the image exposed as
a suitable representation for the shader.
Finally enables bitexact image representations.
