Diego Biurrun [Fri, 27 May 2016 18:14:21 +0000 (20:14 +0200)]
build: Only enable symbol reduction if the compiler does proper DCE
With compilers that do not support proper dead code elimination, like
Sun C 5.12, linking fails due to missing references to unavailable,
but also unused, symbols.
Diego Biurrun [Tue, 24 May 2016 00:18:40 +0000 (02:18 +0200)]
build: Change structure of the linker version script templates
Split version files into one line per symbol/directive to allow compatibility
with the Solaris linker without preprocessing and eliminate $ from version file
templates to simplify the postprocessing shell command.
Mark Thompson [Tue, 17 May 2016 22:08:57 +0000 (23:08 +0100)]
vaapi_h264: Add trivial support for low-power encoding
Experimental; requires Skylake and VAAPI 0.39.1 (not yet released).
Also increases the allowed range of the quality option - in low-power
mode, the Intel driver supports levels 1-8 (and 0 meaning default).
Mark Thompson [Mon, 16 May 2016 13:01:31 +0000 (14:01 +0100)]
vaapi_h264: Fix frame_num after non-reference frames
Non-reference frames (nal_ref_idc == 0) should be discardable, so
frame_num does not advance after them. Before this change, a stream
containing unreferenced B-frames would be rejected by the reference
decoder.
Mark Thompson [Wed, 18 May 2016 09:58:56 +0000 (10:58 +0100)]
vaapi_encode: Check config attributes before creating config
This prevents attempts to use unsupported modes, such as low-power
H.264 mode on non-Skylake targets. Also fixes a crash on invalid
configuration, when trying to destroy an invalid VA config/context.
Anton Khirnov [Tue, 24 May 2016 14:49:19 +0000 (16:49 +0200)]
avconv: fix parsing bitstream filters
The current code modifies the user-supplied string, which is shared for
the whole output file. So a bitstream filter specification applied to
multiple streams would not work correctly.
Anton Khirnov [Sat, 21 May 2016 10:05:38 +0000 (12:05 +0200)]
lavc: document that avcodec_close() should not be used
We cannot deprecate it until the new parser API is in place, because of
the way libavformat works. But the majority of the users can already
simply replace it with avcodec_free_context(), which will simplify the
transition once it is finally deprecated.
Anton Khirnov [Sat, 21 May 2016 09:57:28 +0000 (11:57 +0200)]
lavc: deprecate avcodec_get_context_defaults3()
This function is supposed to "reset" a codec context to a clean state so
that it can be opened again. The only reason it exists is to allow using
AVStream.codec as a decoding context (after it was already
opened/used/closed by avformat_find_stream_info()). Since that behaviour
is now deprecated, there is no reason for this function to exist
anymore.
Anton Khirnov [Sat, 21 May 2016 09:46:44 +0000 (11:46 +0200)]
lavc: deprecate avcodec_copy_context()
Since AVCodecContext contains a lot of complex state, copying a codec
context is not a well-defined operation. The purpose for which it is
typically used (which is well-defined) is copying the stream parameters
from one codec context to another. That is now possible with through the
AVCodecParameters API. Therefore, there is no reason for
avcodec_copy_context() to exist.
Initialize the bit buffer with the correct size (amount of bits that will
be read) instead of relying on the bitstream reader overreading the
correct values.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org> Signed-off-by: Diego Biurrun <diego@biurrun.de>
Anton Khirnov [Sat, 21 May 2016 09:37:33 +0000 (11:37 +0200)]
avconv: stop using AVStream.codec
It is now only used by the av_parser_change() call during streamcopy, so
allocate a special AVCodecContext instance for this case. This instance
should go away when the new parser API is finished.
Philip Langdale [Wed, 28 Jan 2015 17:05:53 +0000 (09:05 -0800)]
nvenc: De-compensate aspect ratio compensation of DVD-like content.
For reasons we are not privy to, nvidia decided that the nvenc encoder
should apply aspect ratio compensation to 'DVD like' content, assuming that
the content is not BT.601 compliant, but needs to be BT.601 compliant. In
this context, that means that they make the following, questionable,
assumptions:
1) If the input dimensions are 720x480 or 720x576, assume the content has
an active area of 704x480 or 704x576.
2) Assume that whatever the input sample aspect ratio is, it does not account
for the difference between 'physical' and 'active' dimensions.
From these assumptions, they then conclude that they can 'help', by adjusting
the sample aspect ratio by a factor of 45/44. And indeed, if you wanted to
display only the 704 wide active area with the same aspect ratio as the full
720 wide image - this would be the correct adjustment factor, but what if you
don't? And more importantly, what if you're used to lavc not making this kind
of adjustment at encode time - because none of the other encoders do this!
And, what if you had already accounted for BT.601 and your input had the
correct attributes? Well, it's going to apply the compensation anyway!
So, if you take some content, and feed it through nvenc repeatedly, it
will keep scaling the aspect ratio every time, stretching your video out
more and more and more.
So, clearly, regardless of whether you want to apply bt.601 aspect ratio
adjustments or not, this is not the way to do it. With any other lavc
encoder, you would do it as part of defining your input parameters or do
the adjustment at playback time, and there's no reason by nvenc should
be any different.
This change adds some logic to undo the compensation that nvenc would
otherwise do.
nvidia engineers have told us that they will work to make this
compensation mechanism optional in a future release of the nvenc
SDK. At that point, we can adapt accordingly.
Signed-off-by: Philip Langdale <philipl@overt.org> Reviewed-by: Timo Rothenpieler <timo@rothenpieler.org> Signed-off-by: Anton Khirnov <anton@khirnov.net>
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.
Anton Khirnov [Fri, 13 May 2016 07:13:47 +0000 (09:13 +0200)]
nvenc: drop the hard dependency on CUDA
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>.
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.
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).
Martin Storsjö [Wed, 20 Apr 2016 20:10:37 +0000 (23:10 +0300)]
movenc: Use packets in interleaving queues for the duration at the end of fragments
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).
Martin Storsjö [Wed, 4 May 2016 14:18:35 +0000 (17:18 +0300)]
avio: Allow custom IO users to get labels for the output bytestream
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.
projects / ffmpeg / log