- 21 Mar, 2015 6 commits
-
-
Anton Khirnov authored
-
Anton Khirnov authored
It's a per-slice quantity constructed when parsing the slice header.
-
Anton Khirnov authored
-
Anton Khirnov authored
CC: libav-stable@libav.org
-
Anton Khirnov authored
It's the output_window that is applied to the output frame, not pic_conf_win
-
Anton Khirnov authored
-
- 20 Mar, 2015 2 commits
-
-
Luca Barbato authored
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
Luca Barbato authored
It drops everything that cannot be used for re-encoding and/or streamcopy.
-
- 19 Mar, 2015 11 commits
-
-
Andreas Cadhalpun authored
According to the WebP Lossless Bitstream Specification "each transform is allowed to be used only once". If a transform is more than once this can lead to memory corruption. Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com> Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
Anton Khirnov authored
-
Martin Storsjö authored
Since the duration is compared to the tfra durations/intervals which are expressed in pts, calculate that here as well. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
For strict CFR, they should be pretty much equal, but if the stream is VFR, there can be a sometimes significant difference. Calculate the pts duration separately, used in sidx atoms and for tfrf/tfxd boxes in smooth streaming ismv files. Also make sure to reduce the duration of sidx entries according to edit lists. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
When reading these values from track->frag_info, the same adjustment has already been done. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Adjusting it is only necessary when a sidx/tfrf/tfxd atom already has been written for the previous fragment (since the sidx/tfrf/tfxd atoms include the duration between the first pts of the previous fragment, to the first pts of the new fragment). Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This matches what we write in tfra and tfrf since 9cbf70fa. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
When automatically flushing fragments based on set conditions (fragmentation on keyframes, after some interval or byte size), we already have the next packet for one stream - use this for setting the duration of the last packet in the flushed fragment correctly. This avoids having to adjust the timestamp of the first packet in the new fragment since the last duration was unknown. Unfortunately, this only works for automatic flushing (not for caller-triggered flushing, like in the dash muxer), and only for the one single track that triggered the flushing. The duration of the last sample in all other tracks still is dependent on AVPacket duration (or heuristics). Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This avoids that the mp4 muxer does a similar heuristic, adjusting the timestamps in a way that the dash muxer doesn't know the actual timestamps written to the file in the end. By making sure that the mp4 muxer internal heuristic isn't applied, we know the exact timestamps written to file, so that the timestamps in manifest match the files. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Even if this is a guess, it is way better than writing a zero duration of the last sample in a fragment (because if the duration is zero, the first sample of the next fragment will have the same timestamp as the last sample in the previous one). Since we normally don't require libavformat muxer users to set the duration field in AVPacket, we probably can't strictly require it here either, so don't log this as a strict warning, only as info. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Add a missing AVClass member, check whether localaddr is null. (Previously, localaddr was always a local stack buffer, while it now also can be an avoption string which can be null.) This fixes crashes when not passing any localaddr parameter, since 66028b7b. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 18 Mar, 2015 1 commit
-
-
Derek Buitenhuis authored
The current behavior may produce a different sequence of packets after seeking, compared to demuxing linearly from the beginning. This is because the MOV demuxer seeks in each stream individually, based on timestamp, which may set each stream at a slightly different position than if the file would have been read sequentially. This makes implementing certain operations, such as segmenting, quite hard, and slower than need be. Therefore, add an option which retains the same packet sequence after seeking, as when a file is demuxed linearly.
-
- 17 Mar, 2015 13 commits
-
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Vittorio Giovara authored
-
Vittorio Giovara authored
Set this field to TRUE if the audio component is to operate on little-endian data, and FALSE otherwise. However TRUE and FALSE are not defined. Since this flag is just a boolean, interpret all values except for 0 as little endian. Sample-Id: 64bit_FLOAT_Little_Endian.mov
-
Vittorio Giovara authored
Prevents unsigned overflow and variable truncation. Bug-Id: CID 603186
-
Vittorio Giovara authored
This is a leftover from the static to dynamic vlc table conversion.
-
Carl Eugen Hoyos authored
Instead check for all mov code-points when demuxing avi and print a warning if a video codec is found like this. Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Vittorio Giovara authored
-
Carl Eugen Hoyos authored
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
-
Niels Möller authored
Prevent a spurious read from uninitialized memory.
-
Luca Barbato authored
It uses 6 registers, unbreaks building on hardened x86 system. Bug-Id: gentoo/541930 CC: libav-stable@libav.org
-
Luca Barbato authored
As produced by Camtasia 4.
-
Diego Biurrun authored
-
- 16 Mar, 2015 6 commits
-
-
Martin Storsjö authored
This is incompatible with the omit_tfhd_offset flag (writing position independent fragments with interleaving requires the default_base_moof flag). This makes the moof atoms slightly bigger, but can be better for playback (improving locality of sample data in the mdat). Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This is needed if all the data for one track isn't continuous within the mdat. Normally we make sure all the data for one track is continuous, but in new cases we will need to have the samples interleaved. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Janne Grunau authored
-
Janne Grunau authored
-
Janne Grunau authored
-
Janne Grunau authored
-
- 15 Mar, 2015 1 commit
-
-
Luca Barbato authored
Bug-Id: 833
-