* commit '46808fdf04ab113df374157b90b506eb3110daf2':
movenc: Enable editlists by default if delay_moov is enabled
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'b91a5757fcbf723da99b05b298a6f820271dbc2b':
dashenc: Fix writing of timelines that don't start at t=0
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '456e93bfdd4cbc5e995dea415019abd0703d0e16':
dashenc: Adjust the start time of a segment to the end of the previous segment
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '2f628d5943c12389c07d652d23d3916997f9f0f6':
dashenc: Write segment timelines properly if the timeline has gaps
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This is the same adjustment that the mp4 muxer does to the start
timestamp of fragments, since the timestamp of a sample in an mp4
file is implicit from the sum of earlier sample durations.
This avoids gaps in the timeline (which can stop dash.js from
playing it back), and makes sure the timestamp on the segmenter
level matches what the mp4 muxer actually writes into the segments.
This is only an issue if the AVPacket duration of the last
packet of a segment doesn't point to the actual start timestamp
of the next packet (the first in the next segment).
Signed-off-by: Martin Storsjö <martin@martin.st>
Write a new start time if the duration of the previous segment
didn't match the start of the next one. Check that segments
actually are continuous before writing a repeat count.
This makes sure timestamps deduced from the timeline actually
match the real start timestamp as written in filenames (if
using a template containing $Time$).
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'e737a4aaafcb1d761b7f96043c2f83ce742c64ae':
dashenc: Change the duration fields to 64 bit
Conflicts:
libavformat/dashenc.c
See: e65849a70b
Merged-by: Michael Niedermayer <michaelni@gmx.at>
For the last_duration field, it's mostly theoretical, but the
total_duration field more probably may need to actually be 64 bit.
Bug-Id: CID 1254944
Signed-off-by: Martin Storsjö <martin@martin.st>
As the manifest/segments are flushed to disk, log to stderr the
progress, when in verbose logging mode
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes the build on compilers that interpreted the earlier
code as a variable length array (which we intentionally disallow).
Signed-off-by: Martin Storsjö <martin@martin.st>
This allows one to specify templated segment names for init-segments,
media-segments, and for the base-url in the case of single-file.
Signed-off-by: Martin Storsjö <martin@martin.st>
This reverts commit b9d08c77a4.
After taking MoveFileEx into use, we can replace files with renames
on windows as well.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'b9d08c77a44390b0848c06f20bc0e9e951ba6a3c':
lavf: Don't try to update files atomically with renames on windows
Conflicts:
libavformat/dashenc.c
libavformat/hdsenc.c
libavformat/internal.h
libavformat/smoothstreamingenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
On windows, rename(2) will fail if the target file exists. On
unix this trick is used to make sure that people reading the file
either will get the full previous file, or the full new version
of the file, but no intermediate version.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'fe42f94ce1023f9c2f7e86404c60afcee5b078a9':
dashenc: Don't segment all video streams when one stream gets a keyframe
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This makes sure that segments actually start at a keyframe (and
makes sure we don't split segments twice in a row, with one segment
consisting of only a handful of packets), when one stream uses b-frames
while another one doesn't.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'f856d9c2f314c493c672dfb9c876da182525da3d':
dashenc: Don't require the stream bitrate to be known
Conflicts:
libavformat/dashenc.c
See: 5f8fcdd448
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Don't write any bitrate attribute if it isn't known. As long as one
doesn't want automatic bitrate switching, playback can work just
fine even if it isn't set.
If strict standard compliance is requested, this is still considered
an error, since the attribute is mandatory according to the spec.
Based on a patch by Rodger Combs.
Signed-off-by: Martin Storsjö <martin@martin.st>
If a stream's bitrate is not set, this attempts to use its rc_max_rate;
if neither is set, it avoids writing a bandwidth attribute at all.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This is mostly to serve as a reference example on how to segment
the output from the mp4 muxer, capable of writing the segment
list in four different ways:
- SegmentTemplate with SegmentTimeline
- SegmentTemplate with implicit segments
- SegmentList with individual files
- SegmentList with one single file per track, and byte ranges
The muxer is able to serve live content (with optional windowing)
or create a static segmented MPD.
In advanced cases, users will probably want to do the segmenting
in their own application code.
Signed-off-by: Martin Storsjö <martin@martin.st>
