| Commit message (Collapse) | Author | Age |
|
|
|
| |
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|
|
|
| |
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|
|
|
| |
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|
|
|
| |
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|\
| |
| |
| |
| |
| |
| | |
* commit '30a041887f89cd97c372ad6a516da6e012f2c88b':
ismindex: Calculate the pts duration of trun atoms, not the dts duration
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| | |
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>
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '67a2912307c3c08f2725ccae162cfe3426b80184':
movenc: Don't assume that fragment durations in pts is equal to duration in dts
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '5c337353a2546416631a87de4881850d99141c39':
movenc: Move sidx edit list timestamp adjustment into a block
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| | |
When reading these values from track->frag_info, the same adjustment
has already been done.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|\|
| |
| |
| |
| |
| |
| | |
* commit 'eee13d653953083553cceadbbedf6222ef78a006':
movenc: Only adjust the cts offset at the start of fragments if necessary
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '5cf892d6946b19a87bcd00d6b76ce81f45960fdb':
movenc: Write pts timestamps in tfxd, instead of dts timestamps
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| | |
This matches what we write in tfra and tfrf since 9cbf70fa0e.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|\|
| |
| |
| |
| |
| |
| | |
* commit 'b81b0cc22b22413760423e239ea644c9afdbfa2d':
movenc: Set the last packet duration based on the next packet when autoflushing
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '3041183677bda0a431b36e96a2c76617abaa8183':
dashenc: Heuristically fill in the duration of packets that need it
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '2889c5e16711770437f380f1bead5f72c6a0b17a':
movenc: Heuristically set the duration of the last sample in a fragment if not set
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
not set
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>
|
|\|
| |
| |
| |
| |
| |
| |
| | |
* commit '8dc72eeaf647736c287b59a3856a11904bedd58b':
udp: Fix crashes after adding AVOptions
See: aefed6ca87971a9d277157c92fef4cdd42c5c1e2
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
66028b7ba.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes a crash, when trying to mux h264 into mxf_opatom.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Previous version reviewed-by: tomas.hardin@codemill.se
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| | |
Based on patch by Martin Vignali <martin.vignali@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| | |
Fix Ticket3530
Based-on debuging work by Martin Vignali <martin.vignali@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| | |
Now seems to work fine with different combinations of odd/even heights
and odd/even number of threads.
|
| |
| |
| |
| | |
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| | |
This allows storing integer factors instead of just 0 and 1
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* cehoyos/master:
lavf/mkv: Ignore ff_isom_write_hvcc() return value as the mov muxer does.
lavc/dts: Do not set bitrate for DTS-HD Master and High Resolution.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| | |
| | |
| | |
| | | |
This change allows remuxing hevc from mpeg-ts to Matroska.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes ticket #4375.
Reviewed-by: Hendrik Leppkes
|
|\ \ \
| |/ /
|/| /
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* commit '8692d74b7364b405d7939c0ed347e8a2815193a7':
mov: Add option to keep exact packet sequence after seeking
Conflicts:
libavformat/isom.h
libavformat/mov.c
libavformat/version.h
See: 414d6547f33175b3f53eb3320aa13161a584a151
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Commit dfa920807494 ("mips/float_dsp: fix a bug in vector_fmul_window_mips")
fixed vector_fmul_window_mips by unrolling the loop only 4 times, but also
removed the outer C loop and replaced it with assembly branches and pointer
arithmetic. When submitting my 64-bit porting patch I missed this new
assembly which also needed porting.
This patch fixes a bus error in the fate-float-dsp test when run on 64-bit
mips.
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Reviewed-by: Nedeljko Babic <nedeljko.babic@imgtec.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| | |
This fixes depending on implementation defined behavior
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| | |
This fixes depending on implementation defined behavior
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| | |
This fixes depending on implementation defined behavior
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a variant of showwaves. It is implemented as a different filter
so that the user is not allowed to use meaningless options which belong
to showwaves (such as rate).
Major edits done by Stefano Sabatini, from a patch by ubitux.
See thread:
From: Clément Bœsch <u@pkh.me>
To: ffmpeg-devel@ffmpeg.org
Date: Wed, 24 Dec 2014 15:03:26 +0100
Subject: [FFmpeg-devel] [PATCH] avfilter/showwaves: add single_pic option
|
| |
| |
| |
| |
| |
| | |
AVPixelFormats
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|\|
| |
| |
| |
| |
| |
| |
| | |
* commit '58a840e21577a2168843487a98cb2cea44b5a94a':
Replace a few leftover instances of enum PixelFormat with enum AVPixelFormat
See: ac627b3d38d370027406c93c2dcaac0b1712a7d4
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| | |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
| |
| |
| |
| | |
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: James Almer <jamrial@gmail.com>
|
| |
| |
| |
| |
| |
| | |
bits can have a value of 0 or 1 they are never -1 or otherwise negative
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* commit '6289706b35d1b030258bba54cc27bb6d2c04bc9b':
fate: Move tdsc to the appropriate screen capture file
Conflicts:
tests/fate/video.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| | |
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* commit '423f5d50e499ab972f507115700c8f31ed8993e4':
mov: Fix little endian audio detection
Conflicts:
libavformat/mov.c
See: d2549ba9df1a1aac8c0ae19bfca2c81e508ba02e
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|\|
| |
| |
| |
| |
| |
| |
| | |
* commit 'cdce9e8025fff1dee2fd3d6bc28aebc0a330c5a0':
aacsbr: Fix type for index variable
See: a15adabdd32c8736c143fcbef36a0f4a75f772f0
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|