How to reproduce:
./ffmpeg -f lavfi -i testsrc -c:v libx264 -g 25 -bsf:v h264_metadata=sei_user_data=186f3693-b7b3-4f2c-9653-21492feee5b8+hello -frames:v 1 h264.mp4

master:
[Parsed_showinfo_0 @ 0x7fc8a0703180] UUID=186f3693-7030-4f2c-6030-21492feee5b8
[Parsed_showinfo_0 @ 0x7fc8a0703180] User Data=hello

Applied the patch:
[Parsed_showinfo_0 @ 0x7f969d408e00] UUID=186f3693-b7b3-4f2c-9653-21492feee5b8
[Parsed_showinfo_0 @ 0x7f969d408e00] User Data=hello
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Reviewed-by: "mypopy@gmail.com" <mypopy@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The Dash muxer uses submuxers and when one such submuxer has been allocated,
it is initially only stored in a temporary variable. Therefore it leaks
if an error happens between the allocation and storing it permanently.
This commit changes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: "Jeyapal, Karthick" <kjeyapal@akamai.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

It does nothing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This commit improves returned error codes by forwarding error codes. In
some instances, the hardcoded returned error codes made no sense at all:
The normal error code for failure of av_new_packet() is AVERROR(ENOMEM),
yet there were instances where AVERROR(EIO) was returned.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

by freeing it a bit earlier.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

It did nothing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Converting explicit avio_flush() calls helps us to buffer more data and avoid
flushing the IO context too often which causes reduced IO throughput for
non-streamed file output.

The user can control FLUSH_POINT flushing behaviour using the -flush_packets
option, the default typically means to flush unless a non-streamed file output
is used, so this change should have no adverse effect on streaming even if it
is assumed that after an avio_flush() the output buffer is clean so small
seekbacks within the output buffer will work even when the IO context is not
seekable.
Signed-off-by: Marton Balint <cus@passwd.hu>

These instances are simply redundant or present because avio_flush() used to be
required before doing a seekback. That is no longer the case, aviobuf code does
the flush automatically on seek.

This only affects code which is either disabled for streaming IO contexts or
does no seekbacks after the flush, so this change should have no adverse effect
on streaming.
Signed-off-by: Marton Balint <cus@passwd.hu>

Removing explicit avio_flush() calls helps us to buffer more data and avoid
flushing the IO context too often which causes reduced IO throughput for
non-streamed file output.

The user can control flushing behaviour at the end of every packet using the
-flush_packets option, the default typically means to flush unless a
non-streamed file output is used.

Therefore this change should have no adverse effect on streaming, even if it is
assumed that a new packet has a clean buffer so small seekbacks within the
output buffer work even when the IO context is not seekable.
Signed-off-by: Marton Balint <cus@passwd.hu>

The IO context is always flushed by libavformat/mux.c after write_trailer is
called, so this change should have no effect at all.

To make it consistent with other muxers.

The user can still control the generic flushing behaviour after write_header
(same way as after packets) using the -flush_packets option, the default
typically means to flush unless a non-streamed file output is used.

Therefore this change should have no adverse effect on streaming, even if it is
assumed that the first packet has a clean buffer, so small seekbacks within the
output buffer work even when the IO context is not seekable.
Signed-off-by: Marton Balint <cus@passwd.hu>

avio_close_dyn_buf() also does avio_flush().
Signed-off-by: Marton Balint <cus@passwd.hu>

The following is a python script to halve the value of the gray
image. It demos how to setup and execute dnn model with python+tensorflow.
It also generates .pb file which will be used by ffmpeg.

import tensorflow as tf
import numpy as np
from skimage import color
from skimage import io
in_img = io.imread('input.jpg')
in_img = color.rgb2gray(in_img)
io.imsave('ori_gray.jpg', np.squeeze(in_img))
in_data = np.expand_dims(in_img, axis=0)
in_data = np.expand_dims(in_data, axis=3)
filter_data = np.array([0.5]).reshape(1,1,1,1).astype(np.float32)
filter = tf.Variable(filter_data)
x = tf.placeholder(tf.float32, shape=[1, None, None, 1], name='dnn_in')
y = tf.nn.conv2d(x, filter, strides=[1, 1, 1, 1], padding='VALID', name='dnn_out')
sess=tf.Session()
sess.run(tf.global_variables_initializer())
graph_def = tf.graph_util.convert_variables_to_constants(sess, sess.graph_def, ['dnn_out'])
tf.train.write_graph(graph_def, '.', 'halve_gray_float.pb', as_text=False)
print("halve_gray_float.pb generated, please use \
path_to_ffmpeg/tools/python/convert.py to generate halve_gray_float.model\n")
output = sess.run(y, feed_dict={x: in_data})
output = output * 255.0
output = output.astype(np.uint8)
io.imsave("out.jpg", np.squeeze(output))

To do the same thing with ffmpeg:
- generate halve_gray_float.pb with the above script
- generate halve_gray_float.model with tools/python/convert.py
- try with following commands
  ./ffmpeg -i input.jpg -vf format=grayf32,dnn_processing=model=halve_gray_float.model:input=dnn_in:output=dnn_out:dnn_backend=native out.native.png
  ./ffmpeg -i input.jpg -vf format=grayf32,dnn_processing=model=halve_gray_float.pb:input=dnn_in:output=dnn_out:dnn_backend=tensorflow out.tf.png
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Pedro Arthur <bygrandao@gmail.com>

do not request AVFrame's format in vf_ddn_processing with 'fmt',
but to add another filter for the format.

command examples:
./ffmpeg -i input.jpg -vf format=bgr24,dnn_processing=model=halve_first_channel.model:input=dnn_in:output=dnn_out:dnn_backend=native -y out.native.png
./ffmpeg -i input.jpg -vf format=rgb24,dnn_processing=model=halve_first_channel.model:input=dnn_in:output=dnn_out:dnn_backend=native -y out.native.png
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Pedro Arthur <bygrandao@gmail.com>

Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: James Zern <jzern@google.com>

Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
Fixes: 19788/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VMDAUDIO_fuzzer-5743379690553344

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Have tested with be and le pixel format on be and le system for >8bit.
System:
lmwang@ubuntu:~/ffmpeg.git.mips$ grep HAVE_BIGENDIAN config.h
ffmpeg.git git:(showinfo) ✗ grep HAVE_BIGENDIAN config.h

Test result:
1, yuv420p
./ffmpeg -f lavfi  -i color=black:duration=1:r=1:size=1280x720,format=yuv420p,showinfo
Master:
mean:[16 128 128] stdev:[0.0 0.0 0.0]
After applied the patch:
 mean:[16 128 128] stdev:[0.0 0.0 0.0]

2, yuv420p10le
./ffmpeg -f lavfi  -i color=black:duration=1:r=1:size=1280x720,format=yuv420p10le,showinfo
Master:
mean:[32 1 1] stdev:[32.0 1.0 1.0]
After applied the patch:
mean:[64 512 512] stdev:[0.0 0.0 0.0]

3, yuv420p10be
./ffmpeg -f lavfi  -i color=black:duration=1:r=1:size=1280x720,format=yuv420p10be,showinfo
Master:
mean:[32 1 1] stdev:[32.0 1.0 1.0]
After applied the patch:
mean:[64 512 512] stdev:[0.0 0.0 0.0]
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The documentation of both avio_open() as well as avio_open2() states
that on failure, the pointer to an AVIOContext given to this function
(via a pointer to a pointer to an AVIOContext) will be set to NULL. Yet
it didn't happen upon failure of ffurl_open_whitelist() or when allocating
the internal buffer failed. This commit changes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes CID 1457236.

"VAProcFilterParameterBufferHDRToneMapping" was defined in libva 2.4.1, which will lead to
build failure for the filter tonemap_vaapi for libva 2.3.0 with current check. This patch
is to fix this build error.
Signed-off-by: Xinpeng Sun <xinpeng.sun@intel.com>

Fixes the following gcc warning:
libavcodec/vdpau_vp9.c:45:5: warning: ISO C90 forbids mixed declarations and code

libswscale/utils.c:89:42: warning: adding 'unsigned long' to a string does not append to the string [-Wstring-plus-int]

Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Gyan Doshi <ffmpeg@gyani.pro>

Currently, the decoder checks the 128th value of the 4th quant table during
while deriving the context on each sample, in order to speed itself up. This
is due to relying on the behavior of FFmpeg's FFV1 encoder, in which if that
value is zero, the entire 4th and 5th quant tables are assumed to be entirely
zero.

This does not match the FFV1 spec, which has no such restriction, and after
some discussion, it was decided to fix FFmpeg to abide by the spec, rather
than change the spec.

We will now check whether the 4th and 5th quant tables are zero properly,
by checking the 128th valye of both tables (which means they are zero due
to the way they're coded in the bitstream).

For further context, the FFV1 issue in question is located at:

    https://github.com/FFmpeg/FFV1/issues/169Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Sources include various lists on the Internet, as well as the current
Wikipedia page at
https://en.wikipedia.org/w/index.php?title=List_of_ID3v1_Genres&oldid=896774343
but most importantly the list as used by taglib at
https://github.com/taglib/taglib/commit/3e60e339a4bc46e2a1a7aea782502480561a8acf#diff-f86455366624350770f41b4940925dde

Further patches to harmonize the spelling have been sent to taglib and
libid3tag. See also https://github.com/taglib/taglib/pull/942/Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: Assertion failure
Fixes: 19753/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGSSUB_fuzzer-5688461843759104

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

In the merge commit 878f8b0d, entry for replaygain_noclip
was placed in commands, which it is not, instead of among
the options.

Instead of dereferencing same thing again.

Prevents a run of consecutive duplicate frames from all being encoded
as keyframes, when force_key_frames is set to source.

The user-set forced KF times are parsed *after* this deleted
loop and rescaled right after parsing.

Also clarify behaviour in case of specified timestamps

This patch rewrites the innermost loop of ff_yuv2planeX_8_neon to avoid zips and
horizontal adds by using fused multiply adds. The patch also uses ld1r to load
one element and replicate it across all lanes of the vector. The patch also
improves the clipping code by removing the shift right instructions and
performing the shift with the shift-right narrow instructions.

I see 8% difference on an m6g instance with neoverse-n1 CPUs:
$ ffmpeg -nostats -f lavfi -i testsrc2=4k:d=2 -vf bench=start,scale=1024x1024,bench=stop -f null -
before: t:0.014015 avg:0.014096 max:0.015018 min:0.013971
after:  t:0.012985 avg:0.013013 max:0.013996 min:0.012818

Tested with `make check` on aarch64-linux.
Signed-off-by: Sebastian Pop <spop@amazon.com>
Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>