Fixes Ticket3514
See: ETSI EN 300 743 V1.3.1 (2006-11)
"In summary, all of the segments of a single display set shall be carried in one (or more) PES packets that have the same
PTS value."
with PTS = DTS and remuxing of such a stream it is to be expected that sometimes
multiple packets would have the same DTS
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
When given a stream starting at dts=0, it would previously consider
s->offset as uninitialized and set an offset when the second packet
was written, ending up writing two packets with dts=0. By initializing
this field to AV_NOPTS_VALUE, we make sure that we only initialize it
once, on the first packet.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is the same logic as is invoked on AVFMT_TS_NEGATIVE,
but which can be enabled manually, or can be enabled
in muxers which only need it in certain conditions.
Also allow using the same mechanism to force streams to start
at 0.
Signed-off-by: Martin Storsjö <martin@martin.st>
It is basically a wrapper around av_get_audio_frame_duration(), with a
fallback to AVCodecContext.frame_size. However, that field is set only
when the stream codec context is actually used for encoding or decoding,
which is discouraged.
For muxing, it is generally the responsibility of the caller to set the
packet duration.
For demuxing, if the duration is not stored at the container level, it
should be set by the parser.
Therefore, removing the frame_size fallback should not break any
important case.
(cherry picked from commit 30e50c5027)
Conflicts:
libavformat/utils.c
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This makes problematic unconditional flushes in mpegts redundant
And is thus part of a fix for ticket 2748
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
libvpx adds very significant delay, which appears normal and we must
buffer all other streams no matter what to interleave them correctly
Fixes Ticket3440
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Previously, AVStream.codec.time_base was used for that purpose, which
was quite confusing for the callers. This change also opens the path for
removing AVStream.codec.
The change in the lavf-mkv test is due to the native timebase (1/1000)
being used instead of the default one (1/90000), so the packets are now
sent to the crc muxer in the same order in which they are demuxed
(previously some of them got reordered because of inexact timestamp
conversion).
Use it instead of checking CODEC_FLAG_BITEXACT in the first stream's
codec context.
Using codec options inside lavf is fragile and can easily break when the
muxing codec context is not the encoding context.
This is continuation of commit 330d547e
Nested struct is set in two places.
Previous commit set nested struct only in one case.
Signed-off-by: Lukasz Marek <lukasz.m.luki2@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This commit allows to benefit from implementing child_next
callback for muxers' AVClasses.
Without that, options cannot be set in nested structs.
Signed-off-by: Lukasz Marek <lukasz.m.luki2@gmail.com>
Currently ff_interleave_packet_per_dts() waits until it gets a frame for
each stream before outputting packets in interleaved order.
Sparse streams (i.e. streams with much fewer packets than the other
streams, like subtitles or audio with DTX) tend to add up latency and in
specific cases end up allocating a large amount of memory.
Emit the top packet from the packet_buffer if it has a time delta
larger than a specified threshold.
Original report of the issue and initial proposed solution by
mus.svz@gmail.com.
Bug-id: 31
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Since we don't write lavf's string when bitexact is requested, this will
prevent the tag from being copied from the source stream.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This is enabled by default and can be disabled with
"-fflags -flush_packets".
Inspired by a patch from Nicolas George <nicolas.george@normalesup.org>.
Signed-off-by: Martin Storsjö <martin@martin.st>