* commit '9cfa68c560bdec82d2d5ec079f9c5b0f9ca37af0':
mpegts: add support for Opus
Conflicts:
libavcodec/opus_parser.c
libavformat/mpegts.c
See: 74141f693d
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '8ebf02f8f530240edf7e45f35f7647ef9dd44a58':
libavformat: Only use MoveFileExA when targeting the desktop API subset
Conflicts:
configure
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'fc308b30bb24e623fed042ec78b10803b2362a18':
rtpenc_mpegts: Call write_trailer for the mpegts muxer even if no output buffer exists
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e2ce16392205d8efe9143329ed3fb5fcb15498fa':
mpegts: Support running the write_trailer function without an AVIOContext
Merged-by: Michael Niedermayer <michaelni@gmx.at>
use av_get_codec_tag_string() in wav_read_header() for printing the
faulty start code from riff header
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Make it more readable and display an error message in case an invalid
header is detected (the current version just returns
AVERROR_INVALIDDATA)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
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>
* commit '59f0275dd0a42a7f90271a83a78e9ca5e69ff5b0':
movenc: Adjust the pts of new fragments similarly to what is done for dts
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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>
* commit 'df07c07b3de0a5e8890078944de1eb5cb8372ef8':
rtpdec_h263_rfc2190: Clear the stored bits if discarding buffered data
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '01f251c44d83eedc819625d2caac9ff9697a085d':
rtpenc: Set the timestamp properly when sending mpegts data, too
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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>
* 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>
Close segment I/O context and append segment in hls_write_trailer() only
when segment I/O context is allocated.
Signed-off-by: Christian Suloway <csuloway@globaleagleent.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Since 3cec81f4d4, a zero-length metadata value would try to
allocate 2*0 bytes, where av_malloc() returns NULL.
Always add one to the allocated length, to allow space for
a null terminator in the zero-length case.
Incidentally, this fixes fate-alac on RVCT 4.0, where a compiler
bug seems to mess up the mov muxer to the point that it writes
the wrong sort of metadata. Previously this bug was undetected,
but since 3cec81f4d4 such mov files started returning
AVERROR(ENOMEM) in the mov demuxer.
Signed-off-by: Martin Storsjö <martin@martin.st>
In matroska_read_seek(), |tracks| is assigned at the begining of the
function. However, functions like matroska_parse_cues() could reallocate
the tracks and invalidate |tracks|.
This assigns |tracks| only before using it, so that it will not get
invalidated elsewhere.
Bug-Id: chromium/427266
This is primarly to maintain current behavior when r_frame_rate is set for muxers
and could be reverted if it has some advantage
Fixes Ticket3629 part1
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This was suggested by cbsrobot, ubitux and koda
There are files with huge amounts of XMP data, which would otherwise
be displayed in the terminal output of FFmpeg
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e737a4aaafcb1d761b7f96043c2f83ce742c64ae':
dashenc: Change the duration fields to 64 bit
Conflicts:
libavformat/dashenc.c
See: e65849a70b
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This option flag deletes segment files removed from the playlist after a
period of time equal to the duration of the segment plus the duration of
the playlist.
Signed-off-by: Christian Suloway <csuloway@globaleagleent.com>
Signed-off-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>
