This goto wasn't necessary originally, but it should have been
added when the write_manifest call was added in 8e276378.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes sending chunked packets (packets larger than the output
chunk size, which often can be e.g. 4096 bytes) with a timestamp delta
(or absolute timstamp, if it's a timestamp step backwards, or the
first packet of the stream) larger than 0xffffffff.
The RTMP spec explicitly says (in section 5.3.1.3.) that packets of
type 3 (continuation packets) should include this field, if the
previous non-continuation packet had it included.
The receiving code handles these packets correctly.
Pointed out by Cheolho Park.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
When the display matrix is not the identity one, but the rotation angle
is zero, there is no need to update the sample aspect ratio.
Otherwise, it is possible to obtain negative values which interferes
with transcoding in later stages. This kind of behaviour is reproducible
on mov files with "major_brand: MSNV".
CC: libav-stable@libav.org
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
A failure in segment_end() or segment_start() would lead to freeing
a dangling pointer and in general further calls to seg_write_packet()
or to seg_write_trailer() would have the same faulty behaviour.
CC: libav-stable@libav.org
Reported-By: luodalongde@gmail.com
This comment can be traced back to the initial commit from 2001,
and it seemed to be misleading/incorect already back then. (It
was used for normal, non-raw file formats already then.)
Signed-off-by: Martin Storsjö <martin@martin.st>
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>
Use the more generic approach with the delay_moov flag, instead of
having a update mechanism specific to this one single atom.
Signed-off-by: Martin Storsjö <martin@martin.st>
This delays writing the moov until the first fragment is written,
or can be flushed by the caller explicitly when wanted. If the first
sample in all streams is available at this point, we can write
a proper editlist at this point, allowing streams to start at
something else than dts=0. For AC3 and DNXHD, a packet is
needed in order to write the moov header properly.
This isn't added to the normal behaviour for empty_moov, since
the behaviour that ftyp+moov is written during avformat_write_header
would be changed. Callers that split the output stream into header+segments
(either by flushing manually, with the custom_frag flag set, or by
just differentiating between data written during avformat_write_header
and the rest) will need to be adjusted to take this option into use.
For handling streams that start at something else than dts=0, an
alternative would be to use different kinds of heuristics for
guessing the start dts (using AVCodecContext delay or has_b_frames
together with the frame rate), but this is not reliable and doesn't
necessarily work well with stream copy, and wouldn't work for getting
the right initialization data for AC3 or DNXHD either.
Signed-off-by: Martin Storsjö <martin@martin.st>
If fragments == 0 it means we haven't written any moov atom yet.
If the empty_moov flag is set, we already have written an empty moov
atom at startup. Thus, the check for empty_moov is redundant.
This is in preparation for allowing writing the moov atom later,
even when using the empty moov flag.
Signed-off-by: Martin Storsjö <martin@martin.st>
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>
The MoveFileExA is available in the headers regardless which API
subset is targeted, but it is missing in the Windows Phone link
libraries. When targeting Windows Store apps, the function is
available both in the headers and in the link libraries, and thus
there is no indication for the build system that this function
should be avoided - such an indication is only given by the
Windows App Certification Kit, which forbids using the MoveFileExA
function.
Therefore check the WINAPI_FAMILY defines instead, to figure out
which API subset is targeted.
Signed-off-by: Martin Storsjö <martin@martin.st>
Since the mpegts muxer now can handle being called with a NULL
AVIOContext, we don't need to try to allocate one before calling
write_trailer.
Signed-off-by: Martin Storsjö <martin@martin.st>
If opening and closing dynamic buffers as AVIOContext, we may
not have any AVIOContext available when wanting to close and
deallocate the muxer. Allow calling write_trailer despite this.
Signed-off-by: Martin Storsjö <martin@martin.st>
The pts and the corresponding duration is written in sidx
atoms, thus make sure these match up correctly.
Signed-off-by: Martin Storsjö <martin@martin.st>
Since this structurally is quite different from normal RTP
(multiple streams are muxed into one single mpegts stream,
which is packetized into one single RTP session), it is kept
as a separate muxer.
Since this structurally also behaves differently than normal
RTP, all of the other muxers that do chained RTP muxing
(rtsp, sap, mp4) would need to be updated similarly to handle
this - in particular, creating one single rtp_mpegts muxer
for the whole presentation instead of one rtp muxer per stream.
Signed-off-by: Martin Storsjö <martin@martin.st>
The packetizer only supports splitting at GOB headers - if
such aren't available frequently enough, it splits at any
random byte offset (not at a macroblock boundary either, which
would be allowed by the spec) and sends a payload header pretend
that it starts with a GOB header.
As long as a receiver doesn't try to handle such cases cleverly
but just drops broken frames, this shouldn't matter too much
in practice.
Signed-off-by: Martin Storsjö <martin@martin.st>
Instead explicitly jump to the default case in the cases where
it is wanted, and avoid fallthrough between different codecs,
which could easily introduce bugs if people editing the code
aren't careful.
Signed-off-by: Martin Storsjö <martin@martin.st>
If we throw away the buffered incomplete frame, make sure to also
throw away the buffered bits of an incomplete byte at the same
time.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
In particular, when packetizing mpegts into rtp, the input packet
timestamp may come from more than one stream, which could cause
multiple packets be written with the same timestamp.
Signed-off-by: Martin Storsjö <martin@martin.st>
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>
