This allows remuxing streams from one mpegts container to another,
without requiring avformat_find_stream_info() (or using `ffmpeg
-probesize 32` on the cli).
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is required since some programs are not able to correctly recognize
the metadata. See H.222, 2.6.58 Metadata pointer descriptor.
putstr8() is modified in order to allow to skip writing the string
length.
This avoids continuity check failures in concatenated streams
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Set the stream_id to 0xbd (private_stream_id_1). Tools seem to assume
that value, and this is consistent with MPEG TS specification (ITU-T
H.222.0 section 2.12.3).
* commit '393596f9d51134d6e45d81ae129223f4faea1232':
mpegtsenc: stop impersonating ses in sdt
This commit also includes the needed FATE updates later spotted by
Martin Storsjö and fixed in 34effe816f on
Libav side.
Merged-by: Clément Bœsch <u@pkh.me>
This allows to copy information related to the stream ID from the demuxer
to the muxer, thus allowing for example to retain information related to
synchronous and asynchronous KLV data packets. This information is used
in the muxer when remuxing to distinguish the two kind of packets (if the
information is lacking, data packets are considered synchronous).
The fate reference changes are due to the use of
av_packet_merge_side_data(), which increases the size of the output
packet size, since side data is merged into the packet data.
Currently, AVStream contains an embedded AVCodecContext instance, which
is used by demuxers to export stream parameters to the caller and by
muxers to receive stream parameters from the caller. It is also used
internally as the codec context that is passed to parsers.
In addition, it is also widely used by the callers as the decoding (when
demuxer) or encoding (when muxing) context, though this has been
officially discouraged since Libav 11.
There are multiple important problems with this approach:
- the fields in AVCodecContext are in general one of
* stream parameters
* codec options
* codec state
However, it's not clear which ones are which. It is consequently
unclear which fields are a demuxer allowed to set or a muxer allowed to
read. This leads to erratic behaviour depending on whether decoding or
encoding is being performed or not (and whether it uses the AVStream
embedded codec context).
- various synchronization issues arising from the fact that the same
context is used by several different APIs (muxers/demuxers,
parsers, bitstream filters and encoders/decoders) simultaneously, with
there being no clear rules for who can modify what and the different
processes being typically delayed with respect to each other.
- avformat_find_stream_info() making it necessary to support opening
and closing a single codec context multiple times, thus
complicating the semantics of freeing various allocated objects in the
codec context.
Those problems are resolved by replacing the AVStream embedded codec
context with a newly added AVCodecParameters instance, which stores only
the stream parameters exported by the demuxers or read by the muxers.
So far an AC-3 elementary stream is refered to in the PMT according to
System A (ATSC). An E-AC-3 ES in contrast is embedded the System B (DVB) way.
To fix this inconsistency, this commit changes the default E-AC-3 behaviour to
use the ATSC way, too. Furthermore a new flag is added to optionally select the
DVB way (regarding both codecs and possible further differences in the future).
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
So far an AC-3 elementary stream is refered to in the PMT according to
System A (ATSC). However System B (DVB) has a different way to signal an AC-3
ES within the PMT. This different way can be enabled by a new flag. The flag is
more generally named 'system_b' as there are further differences between ATSC
and DVB (e.g. the signalling of E-AC-3) which should then also be covered by it
in the future.
Bug-Id: 73
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
ts->mux_rate is int (signed 32-bit) type. The period calculations
will start to overflow when mux_rate > 5mbps. This fixes overflows
by converting first to 64-bit type.
Fixes#5044.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Sebastian Dröge <sebastian@centricular.com>
Previous version reviewed-by: Kieran Kunhya <kierank@obe.tv>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '4512ee78e19fdb011bdec1b3a8dc0b315c82a81e':
mpegts: Mark the muxer as supporting variable fps
Merged-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '7d097a0fc57f0fa8385962a539c657c2f40b5ed0':
mpegtsenc: Take max_delay into account when buffering multiple audio packets into one PES packet
Conflicts:
libavformat/mpegtsenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Make sure we don't buffer up more than max_delay worth of data
before writing a PES packet, even if pes_payload_size is set to
a larger value.
Signed-off-by: Martin Storsjö <martin@martin.st>
