Anton Khirnov [Mon, 19 Jan 2015 20:58:12 +0000 (21:58 +0100)]
h264: drop any pretense of support for data partitioning
It does not work correctly and apparently never did. There is no
indication that this (mis)feature is ever used in the wild or even that
any software other than the reference supports it.
Since the code that attempts to support it adds some nontrivial
complexity and has resulted in several bugs in the past, it is better to
just drop it.
Anton Khirnov [Sat, 17 Jan 2015 16:16:20 +0000 (17:16 +0100)]
error_resilience: move the MECmpContext initialization into ER code
Currently, it needs to be initialized by the ER caller (which is
currently either a mpegvideo decoder or h264dec). However, since none of
those decoders use MECmpContext for anything except ER, it makes more
sense to handle it purely inside ER.
Vittorio Giovara [Thu, 22 Jan 2015 19:10:27 +0000 (19:10 +0000)]
mov: Do not compute negative SAR values
This partially reverts cf70ba37ba74089a18295b29e77dead0a3222c9e, since
it didn't take into account when rotation is 0, but there is another
valid operation (eg. translation) in the matrix.
mpegvideo_enc: Draw edges on input for non-multiple of 16 resolutions
This improves motion estimation and avoids using uninitialized data
for resolutions that aren't a multiple of 16.
Prior to d2a25c40, the edges used to be initialized so that encoding
was deterministic, but after that commit it started using uninitialized
data (for non multiple of 16 resolutions).
CC: libav-stable@libav.org Signed-off-by: Martin Storsjö <martin@martin.st>
Martin Storsjö [Wed, 14 Jan 2015 21:09:06 +0000 (23:09 +0200)]
rtmppkt: Repeat the full 32 bit timestamp for chunking continuation packets
This fixes sending chunked packets (packets larger than the output
chunk size, which often can be e.g. 4096 bytes) with a timestamp delta
(or absolute timstamp, if it's a timestamp step backwards, or the
first packet of the stream) larger than 0xffffffff.
The RTMP spec explicitly says (in section 5.3.1.3.) that packets of
type 3 (continuation packets) should include this field, if the
previous non-continuation packet had it included.
The receiving code handles these packets correctly.
Pointed out by Cheolho Park.
CC: libav-stable@libav.org Signed-off-by: Martin Storsjö <martin@martin.st>
Stefano Sabatini [Wed, 10 Dec 2014 12:20:49 +0000 (12:20 +0000)]
imgutils: create misc functions for dealing with buffers
Move the lavc/imgconvert functions and rename them as follows:
avpicture_get_size -> av_image_get_buffer_size()
avpicture_fill -> av_image_fill_arrays()
avpicture_layout -> av_image_copy_to_buffer()
The new functions have an align parameter, which allows to define the
linesize alignment assumed in the buffer (which is set or read).
The names of the functions are consistent with the lavu/samples API
(av_samples_get_buffer_size(), av_samples_fill_arrays()).
A redundant check has been dropped from av_image_fill_arrays().
mov: Check angle rather than full matrix when updating SAR
When the display matrix is not the identity one, but the rotation angle
is zero, there is no need to update the sample aspect ratio.
Otherwise, it is possible to obtain negative values which interferes
with transcoding in later stages. This kind of behaviour is reproducible
on mov files with "major_brand: MSNV".
Martin Storsjö [Wed, 7 Jan 2015 21:49:41 +0000 (23:49 +0200)]
libfdk-aacdec: Make sure decoding doesn't add any extra delay in the latest version of fdk-aac
The latest version added support for a new option for enabling
a signal level limiter, which adds some extra delay. In fdk-aac, this
is enabled by default, but disable it by default here since we'd rather
have zero-delay decoding.
Luca Barbato [Mon, 5 Jan 2015 09:40:41 +0000 (10:40 +0100)]
segment: Fix the failure paths
A failure in segment_end() or segment_start() would lead to freeing
a dangling pointer and in general further calls to seg_write_packet()
or to seg_write_trailer() would have the same faulty behaviour.
Vittorio Giovara [Thu, 18 Dec 2014 19:26:58 +0000 (20:26 +0100)]
ulti: invert the order of parameters of ulti_decode_frame()
This is the order that the caller uses in the rest of the file.
Variables are modified to reflect the order above too and their
initialization is merged with their declarationt. No behavioral
change.
Stefano Pigozzi [Mon, 29 Dec 2014 20:28:50 +0000 (21:28 +0100)]
vda: error out if decoded CVPixelBuffer is empty
On some video samples, VDA silently fails to decode frames and returns
kVDADecoderNoErr. Error out in these cases to avoid producing AVFrames with
empty planes.
Martin Storsjö [Sat, 3 Jan 2015 19:22:31 +0000 (21:22 +0200)]
libavformat: Remove a misleading/incorrect comment
This comment can be traced back to the initial commit from 2001,
and it seemed to be misleading/incorect already back then. (It
was used for normal, non-raw file formats already then.)
Martin Storsjö [Fri, 28 Nov 2014 07:40:31 +0000 (09:40 +0200)]
sidxindex: Don't adjust the Period start time depending on the track start time
This was only necessary to get playback to start with dash.js 1.2.0,
it has been fixed in the git version.
The previous behaviour was incorrect - the Period's start time
is irrespective of the actual first timestamp of the contents
within the period. The Period start time only says when, within the
global timeline, this particular piece should start to be played
back.
Martin Storsjö [Mon, 17 Nov 2014 12:34:46 +0000 (14:34 +0200)]
dashenc: Use pts for MPD timeline timestamps
This should be more correct. This also should give more sensible
switching between video streams with different amount of b-frame
delay.
The current dash.js release (1.2.0) fails to start playback of
such files from the start (if the start pts is > 0), but this has
been fixed in the current git version of dash.js.
Also enable the use of edit lists, so that streams in many cases
start at pts=0.
Martin Storsjö [Mon, 3 Nov 2014 14:09:15 +0000 (16:09 +0200)]
movenc: Add an option for delaying writing the moov with empty_moov
This delays writing the moov until the first fragment is written,
or can be flushed by the caller explicitly when wanted. If the first
sample in all streams is available at this point, we can write
a proper editlist at this point, allowing streams to start at
something else than dts=0. For AC3 and DNXHD, a packet is
needed in order to write the moov header properly.
This isn't added to the normal behaviour for empty_moov, since
the behaviour that ftyp+moov is written during avformat_write_header
would be changed. Callers that split the output stream into header+segments
(either by flushing manually, with the custom_frag flag set, or by
just differentiating between data written during avformat_write_header
and the rest) will need to be adjusted to take this option into use.
For handling streams that start at something else than dts=0, an
alternative would be to use different kinds of heuristics for
guessing the start dts (using AVCodecContext delay or has_b_frames
together with the frame rate), but this is not reliable and doesn't
necessarily work well with stream copy, and wouldn't work for getting
the right initialization data for AC3 or DNXHD either.
Martin Storsjö [Thu, 18 Dec 2014 21:59:27 +0000 (23:59 +0200)]
movenc: Remove an unnecessary condition when flushing fragments
If fragments == 0 it means we haven't written any moov atom yet.
If the empty_moov flag is set, we already have written an empty moov
atom at startup. Thus, the check for empty_moov is redundant.
This is in preparation for allowing writing the moov atom later,
even when using the empty moov flag.
Martin Storsjö [Mon, 29 Dec 2014 13:39:23 +0000 (15:39 +0200)]
dashenc: Fix writing of timelines that don't start at t=0
When writing an explicit time, reset the cur_time variable to this
value as well. This avoids writing excessive time attributes for each
segment in the timeline, as long as the segments are continuous.
vdpau: add helper for surface chroma type and size
Since the VDPAU pixel format does not distinguish between different
VDPAU video surface chroma types, we need another way to pass this
data to the application.
Originally VDPAU in libavcodec only supported decoding to 8-bits YUV
with 4:2:0 chroma sampling. Correspondingly, applications assumed that
libavcodec expected VDP_CHROMA_TYPE_420 video surfaces for output.
However some of the new HEVC profiles proposed for addition to VDPAU
would require different depth and/or sampling:
http://lists.freedesktop.org/archives/vdpau/2014-July/000167.html
...as would lossless AVC profiles:
http://lists.freedesktop.org/archives/vdpau/2014-November/000241.html
To preserve backward binary compatibility with existing applications,
a new av_vdpau_bind_context() flag is introduced in a further change.
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net> Signed-off-by: Anton Khirnov <anton@khirnov.net>
This carries the pixel format that would be used if it were not for
hardware acceleration. This is equal to AVCodecContext.pix_fmt if
hardware acceleration is not in use.
projects / ffmpeg / log