Each time the sub2video structure is initialized, the sub2video
subpicture is initialized together with the first received heartbeat.
The heartbeat's PTS is utilized as the subpicture start time.

Additionally, add some documentation on the stages.

There are no failure cases left in this function.

It is very fragile against fields being moved and hides what is actually
being copied. Copy all the fields explicitly instead.

They use non-public functions, which is unacceptable for a public API
example. Rename the example back to avio_list_dir.

This effectively reverts c84d208c and
767d780e.

It is always 0.

It doesn't do anything: All allocated blocks have already been freed in
write_header.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

There was no consensus wheter or not to allow unofficial frame rates due to
possible interoperability issues, a compromise is to only allow it if -strict
mode is set to unofficial.
Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Marton Balint <cus@passwd.hu>

Fixes ticket #8523.
Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Marton Balint <cus@passwd.hu>

Only MXF used an actual sample array, and that is unneeded there because simple
rounding rules can be used instead.
Signed-off-by: Marton Balint <cus@passwd.hu>

If an AVFormatContext could be allocated, but white-/blacklists couldn't
be copied, the AVFormatContext would leak as it was only accessible
through a local variable that goes out of scope when one goes to fail.

Furthermore, in case writing a header of a submuxer failed, the options
used for said call could leak.

Both of these memleaks have been fixed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Don't read a 64bit number before having checked that the data is at
least 8 bytes long.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

Should writing the header fail, the allocations already performed will
be freed during deinit so remove the frees in nut_write_header().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

If writing a packet didn't directly return an error, the AVIOContext's
error flag is checked for errors (if existing) by write_packet(). And if
write_packet() didn't indicate an error, its callers checked the error
flag of the AVIOContext (if existing). The latter check is redundant.

The reason for checking twice lies in the FFmpeg-Libav split: The check
in write_packet() has been added in 9ad1e0c1 in Libav. FFmpeg already
had the other checks (since aec9390a), but when 9ad1e0c1 was merged
(in 1f1c1008), no one noticed the redundant checks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

as well as includes of libavutil/timer.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes ticket #8568.

This version is able to output multiple coefficients at a time and
is able to altogether remove actual golomb code parsing.
Its also able to partially recover the last coefficient in case
the packet is incomplete.

Total decoder performance gain for 8bit 420 1080p lossless: 40%.
Total decoder performance gain for 10bit 420 1080p lossless: 40%.

clang was able to vectorize the loop much better than
my handwritten assembly, but gcc was very naive and didn't.

Lookup table is a rewritten version of vc2hqdecode.

Requires the dmabuf modifiers extension.
Allows for importing of compressed images with a second plane.

The specifications are very vague about who has ownership, and in this case,
Vulkan takes ownership of all DMABUF FDs passed to it, causing errors
to occur if someone gave us images for mapping which were meant to be kept.
The old behavior worked with one-way VAAPI and DMABUF imports, but was broken
with clients like wlroots' dmabuf-capture.

There was a recent change in Intel's driver that triggered a driver-internal
error if the semaphore given to the command buffer wasn't initialized.
Given that the specifications require the semaphore to be initialized,
this is within spec. Unlike what's causing it in the first place, which is
that there are no ways to extract/import dma sync objects from DMABUFs,
so we must leave our semaphores bare.

We need to consider the amount of layers instead of the image's planes.

Fixes decoding of came2_2020-01-13__20-38-58_21-00-00__Chn2.avi

The Y channel is handled by dnn, and also resized by dnn. The UV channels
are resized with swscale.

The command to use espcn.pb (see vf_sr) looks like:
./ffmpeg -i 480p.jpg -vf format=yuv420p,dnn_processing=dnn_backend=tensorflow:model=espcn.pb:input=x:output=y -y tmp.espcn.jpg
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Reviewed-by: Pedro Arthur <bygrandao@gmail.com>

Only the Y channel is handled by dnn, the UV channels are copied
without changes.

The command to use srcnn.pb (see vf_sr) looks like:
./ffmpeg -i 480p.jpg -vf format=yuv420p,scale=w=iw*2:h=ih*2,dnn_processing=dnn_backend=tensorflow:model=srcnn.pb:input=x:output=y -y srcnn.jpg
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Reviewed-by: Pedro Arthur <bygrandao@gmail.com>

Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Reviewed-by: Pedro Arthur <bygrandao@gmail.com>

make the options same as segments for the http put method
Signed-off-by: Steven Liu <liuqi05@kuaishou.com>

This patch fixes Bug #8469
If x264 baseline profile is used with other profiles,
start_pts will be initialized to audio stream's first pts,
while the duration is calculated based on video stream's pts.
In this patch the start_pts is initialized with the correct stream's first pts.
Signed-off-by: Hongcheng Zhong <sj.hc_Zhong@sjtu.edu.cn>
Reviewed-by: Steven Liu <liuqi05@kuaishou.com>