As the nvEncodeApi.h header is now MIT licensed, this can be dropped.
The loaded CUDA and NVENC libraries are part of the nvidia driver, and
thus count as system libraries.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

The code needs only a few definitions from cuda.h, so define them
directly when CUDA is not enabled. CUDA is still required for accepting
HW frames as input.

Based on the code by Timo Rothenpieler <timo@rothenpieler.org>.

hwcontext_cuda.h includes cuda.h, so this will allow building nvenc
without depending on cuda.h

Bump the API version requirement to 6.

Based on a patch by Agatha Hu <ahu@nvidia.com>.

Based on a patch by Agatha Hu <ahu@nvidia.com>.

For some unknown reason enabling these causes proper CBR padding,
so as there are no known downsides just always enable them in CBR mode.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Based on a patch by Philip Langdale <philipl@overt.org>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Print them as a subsection of the external library section, in line with
what is done for the help text in the previous commit.

Group them in a subsection of the external library section. That should
make them easier to find and understand how they fit in the scheme of
things.

Also, rewrite the description text in a similar way as in the previous
commit.

Add a more accurate description of what the switches actually do (i.e.
allow using the given library, not enabling the corresponding
codecs etc.).

Replace the library descriptions, in many cases boilerplate text without
useful information, with a short summary of what the library does.

There is no real advantage to listing some codecs or subsystems
separately simply because they are somehow "hw-accelerated", on the
contrary it makes them harder to find than in a plain alphabetically
ordered list.

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Previously, we required the minimum number of bytes required for
the full box. Don't strictly require the astronomical body and additional
notes fields, but do require an altitude field (which currently isn't
parsed). This matches the initial length check at the start of the function
(which doesn't know about the variable length place field).
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

This was missed in e1eb0fc9, when ff_interleaved_peek was
changed to include const during the evolution of the patch.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

As long as caller only writes packets using av_interleaved_write_frame
with no manual flushing, this should allow us to always have accurate
durations at the end of fragments, since there should be at least
one queued packet in each stream (except for the stream where the
current packet is being written, but if the muxer itself does the
cutting of fragments, it also has info about the next packet for that
stream).
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

This allows callers with avio write callbacks to get the bytestream
positions that correspond to keyframes, suitable for live streaming.

In the simplest form, a caller could expect that a header is written
to the bytestream during the avformat_write_header, and the data
output to the avio context during e.g. av_write_frame corresponds
exactly to the current packet passed in.

When combined with av_interleaved_write_frame, and with muxers that
do buffering (most muxers that do some sort of fragmenting or
clustering), the mapping from input data to bytestream positions
is nontrivial.

This allows callers to get directly information about what part
of the bytestream is what, without having to resort to assumptions
about the muxer behaviour.

One keyframe/fragment/block can still be split into multiple (if
they are larger than the aviocontext buffer), which would call
the callback with e.g. AVIO_DATA_MARKER_SYNC_POINT, followed by
AVIO_DATA_MARKER_UNKNOWN for the second time it is called with
the following data.
Signed-off-by: Martin Storsjö <martin@martin.st>

Use it in av_dump_format() instead of a huge switch case.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Signed-off-by: Martin Storsjö <martin@martin.st>