ts_offset was added to cluster timecode, but then effectively subtracted
back off the block timecode
When setting initial_padding for an audio stream, the timestamps are
written incorrectly to the mkv file. cluster timecode gets written
as pts0 + ts_offset which is correct, but then block timecode gets
written as pts - cluster timecode which expanded is
pts - (pts0 + ts_offset). Adding cluster and block tc back together:
cluster + block = (pts0 + ts_offset) + (pts - (pts0 + ts_offset)) = pts
But the result should be pts + ts_offset since demux will subtract the
CodecDelay element from pts and set initial_padding to CodecDelay.
This patch gives the correct result.
The Intel proprietary VAAPI driver enforces the restriction that a
buffer must be created inside an existing context, so just ensure
this is always true.
When slice_h is rounded up due to chroma subsampling, there's
a risk that jobnr * slice_h exceeds frame->height.
Prior to a638e9184d, this wasn't an issue for the last slice
of a frame, since slice_end was set to frame->height for the last
slice.
a638e9184d tried to fix the case where other slices than the
last one would exceed frame->height (which can happen where the
number of slices/threads is very large compared to the frame
height).
However, the fix in a638e9184d instead broke other cases,
where slice_h * nb_threads < frame->height. Therefore, make
sure the last slice always ends at frame->height.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
If the stream timebase is coarser than the muxing timebase then the
monotonisation process may fail because adding one to the timestamp
need not actually produce a different timestamp after the rescale.
The early check for inconsistent in-source vs out-of-source build
cannot generate a config.log otherwise.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
According to the spec[1], a value of 0 means the footer is present and a value
of 1 means it's absent, the exact opposite of header presence flag where 1
means present and 0 absent.
The reason for this is compatibility with APEv1 tags, where there's no header,
footer presence was mandatory for all files, and the flags field was a zeroed
reserved field.
[1] http://wiki.hydrogenaud.io/index.php?title=Ape_Tags_Flags
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Core of patch is from paul@paulmehta.com
Reference https://crbug.com/643952 (udta_string portion)
Signed-off-by: Matt Wolenetz <wolenetz@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If this is wanted iam not against it but it must be designed to work with all cases
like slice threads, and a single growing buffer does not work very well with slices.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes all sorts of configuration problems introducec by dad7a9c7c0
on non-Linux or non-vanilla configs. Also removes a line made redundant
in that commit.
This swaps which field is set when the Window Acknowledgement Size
and Set Peer BW packets are received, renames the fields in
order to clarify their role further and adds verbose comments
explaining their respective roles and how well the code currently
does what it is supposed to.
The Set Peer BW packet tells the receiver of the packet (which
can be either client or server) that it should not send more data
if it already has sent more data than the specified number of bytes,
without receiving acknowledgement for them. Actually checking this
limit is currently not implemented.
In order to be able to check that properly, one can send the
Window Acknowledgement Size packet, which tells the receiver of the
packet that it needs to send Acknowledgement packets
(RTMP_PT_BYTES_READ) at least after receiving a given number of bytes
since the last Acknowledgement.
Therefore, when we receive a Window Acknowledgement Size packet,
this sets the maximum number of bytes we can receive without sending
an Acknowledgement; therefore when handling this packet we should set
the receive_report_size field (previously client_report_size).
Signed-off-by: Martin Storsjö <martin@martin.st>
Implements support for height/width expressions in vf_scale_vaapi,
by refactoring common code into a new libavfilter/scale.c
Signed-off-by: Mark Thompson <sw@jkqxz.net>
* commit 'd639dcdae022130078c9c84b7b691c5e9694786c':
ratecontrol: Move Xvid-related functions to the place they are actually used
Merged-by: Clément Bœsch <u@pkh.me>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Also makes sure all streams are assigned to exactly one AdaptationSet.
This patch is originally based partially on code by Vignesh Venkatasubramanian.
Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Martin Storsjö <martin@martin.st>
If set, adds a UTCTiming tag in the manifest.
This is part of the recommendations listed in the "Guidelines for
Implementations: DASH-IF Interoperability Points" [1][2]
Section 4.7 describes means for the Availability Time Synchronization.
A usable default is "https://time.akamai.com/?iso"
[1] http://dashif.org/guidelines/
[2] http://dashif.org/wp-content/uploads/2016/12/DASH-IF-IOP-v4.0-clean.pdf
(current version as of writing)
Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Martin Storsjö <martin@martin.st>
Instead of just updating statistics and leaving the work to the
call site, have it actually do the work.
Also: skip the samples by updating the frame data pointers
instead of moving the samples. More efficient and avoid writing
into shared frames.
Found-By: Muhammad Faiz <mfcc64@gmail.com>
Servers seem to be happy to receive the wrapped-around value as long
as they receive a report, otherwise they timeout.
Initially reported and analyzed by Thomas Bernhard.
This allows testing EC and non EC. Avoids spending most time in EC on
high res samples and reduces the likelyhood of hitting timeouts
Fixes: Timeout in 467/fuzz-2-ffmpeg_VIDEO_AV_CODEC_ID_H263_fuzzer
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'f450cc7bc595155bacdb9f5d2414a076ccf81b4a':
h264: eliminate decode_postinit()
Also includes fixes from 1f7b4f9abc and e344e65109.
Original patch replace H264Context.next_output_pic (H264Picture *) by
H264Context.output_frame (AVFrame *). This change is discarded as it
is incompatible with the frame reconstruction and motion vectors
display code which needs the extra information from the H264Picture.
Merged-by: Clément Bœsch <u@pkh.me>
Merged-by: Matthieu Bouron <matthieu.bouron@gmail.com>
Seemingly ff_clear_block_sse assumed that the block array is aligned,
so make sure it is.
Fixes ticket #6079
Signed-off-by: James Almer <jamrial@gmail.com>
No need to loop through the known surfaces, we'll use the requested surface
anyway.
The loop is only done for DXVA2.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
start_number option starts the playlist sequence number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have unique
starting numbers at each run, but currently it is only achiveable by
setting this parameter manually.
This patch enables to specify start_number source parameter by
introducing hls_start_number_source with 3 possible values:
generic/epoch/datetime. This ensures to set start sequence number
automatically for practically unique numbers. Generic option is the
default and this is the curent behaviour: start_number option value
specifies the start sequence number. (start_number default value is 0)
If hls_start_number_source is set to epoch, then the start number will
be the seconds since epoch (1970-01-01 00:00:00). If set to datetime,
then the start sequence number will be based on the current date/time
value as YYYYmmddHHMMSS. e.g. 20161231235659.
Hls speficication allows 64 bit integers as sequence numbers. This patch
also changes some code where only 32 bit integer values were handled
correctly.
Reviewed-by: Moritz Barsnick <barsnick@gmx.net>
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
When allocating stack space with an alignment requirement that is larger
than the current stack alignment we need to store a copy of the original
stack pointer in order to be able to restore it later.
If we chose to use another register for this purpose we should not pick
eax/rax since it can be overwritten as a return value.
fix CID: 1398364 Resource leak
refine the code of the new options
Reviewed-by: Bodecs Bela <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
If a read fails, the current code will free the data but leave the size
non-zero. Make sure the size is zeroed in such a case.
CC: libav-stable@libav.org
Bug-Id: 1001
Found-By: Kamil Frankowicz
Signed-off-by: Sean McGovern <gseanmcg@gmail.com>
A wrong, unitialized variable is used for testing. This patch fixes this
typo.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Fixes assertion failure due to unsupported case
Fixes: 356/fuzz-1-ffmpeg_VIDEO_AV_CODEC_ID_MJPEG_fuzzer
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In ff_index_search_timestamp(), if b == num_entries,
m == num_entries - 1, and entries[m].flags & AVINDEX_DISCARD_FRAME is
true, then the search for the next non-discarded packet could access
entries[nb_entries], exceeding its bounds. This change adds a protection
against that scenario. Reference: https://crbug.com/666770
Reviewed-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Otherwise the .rep file would still contain a signal instead of a
zero, even if the process returned success.
Signed-off-by: Martin Storsjö <martin@martin.st>
This moves work from the configure to the Make stage where it can
be parallelized and ensures that shared libraries are built with
the right version number in the filename.
When receiving fragmented packets, the first packet declares the size,
and the later ones normally are small follow-on packets that don't repeat
the size and the other header fields. But technically, the later fragments
also can have a full header, declaring a different size than the previous
packet.
If the follow-on packet declares a larger size than the initial one, we
could end up writing outside of the allocation.
This fixes out of bounds writes.
Found-by: Paul Cher <paulcher@icloud.com>
Reviewed-by: Paul Cher <paulcher@icloud.com>
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
It is useful for testing/debugging and will also be used as the default
filter in the following commit adding pre-decode filtering to avoid
having a separate non-filtered codepath.
Fixes undefined operation
Fixes part of 668007-media
Found-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Examples use the native FFmpeg AAC encoder but it is no longer
considered experimental and therefore not required.
Signed-off-by: Lou Logan <lou@lrcd.com>
While no decoder currently exports spherical information, this type
represents a frame property that has to be passed through from container
to frames.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This matrix needs to be applied after all others have (currently only
display matrix from trak), but cannot be handled in movie box, since
streams are not allocated yet. So store it in main context, and apply
it when appropriate, that is after parsing the tkhd one.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
The delta escape (2) is supposed to work the same in 4-bit RLE as in
8-bit RLE. This is documented in the MSDN Bitmap Compression page:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd183383(v=vs.85).aspx
The unchecked modification of line is safe, since the loop condition
(line >= 0) will check it before any pixel data is written.
Fixes ticket #5153 (output now matches ImageMagick for the provided sample).
Signed-off-by: Daniel Verkamp <daniel@drv.nu>
openvela-robot