- 19 Mar, 2015 27 commits
-
-
Michael Niedermayer authored
Fixes Ticket4227 Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
Fixes 256Gb limit Fixes Ticket4225 Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
* commit '30a04188': ismindex: Calculate the pts duration of trun atoms, not the dts duration Merged-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
* commit '67a29123': movenc: Don't assume that fragment durations in pts is equal to duration in dts Merged-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
* commit '5c337353': movenc: Move sidx edit list timestamp adjustment into a block Merged-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
* commit 'eee13d65': movenc: Only adjust the cts offset at the start of fragments if necessary Merged-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
* commit '5cf892d6': movenc: Write pts timestamps in tfxd, instead of dts timestamps Merged-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
* commit 'b81b0cc2': movenc: Set the last packet duration based on the next packet when autoflushing Merged-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
* commit '30411836': dashenc: Heuristically fill in the duration of packets that need it Merged-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
* commit '2889c5e1': movenc: Heuristically set the duration of the last sample in a fragment if not set Merged-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
* commit '8dc72eea': udp: Fix crashes after adding AVOptions See: aefed6caMerged-by: Michael Niedermayer <michaelni@gmx.at>
-
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>
-
Andreas Cadhalpun authored
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>
-
Michael Niedermayer authored
Based on patch by Martin Vignali <martin.vignali@gmail.com> Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
Fix Ticket3530 Based-on debuging work by Martin Vignali <martin.vignali@gmail.com> Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 18 Mar, 2015 13 commits
-
-
Clément Bœsch authored
Now seems to work fine with different combinations of odd/even heights and odd/even number of threads.
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
This allows storing integer factors instead of just 0 and 1 Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
* 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>
-
Michael Niedermayer authored
* commit '8692d74b': mov: Add option to keep exact packet sequence after seeking Conflicts: libavformat/isom.h libavformat/mov.c libavformat/version.h See: 414d6547Merged-by: Michael Niedermayer <michaelni@gmx.at>
-
Carl Eugen Hoyos authored
This change allows remuxing hevc from mpeg-ts to Matroska.
-
Carl Eugen Hoyos authored
Fixes ticket #4375. Reviewed-by: Hendrik Leppkes
-
Micah Galizia authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
James Cowgill authored
Commit dfa92080 ("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>
-
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.
-
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.
-
Michael Niedermayer authored
This fixes depending on implementation defined behavior Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
This fixes depending on implementation defined behavior Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-