commit "avpacket: Deprecate av_dup_packet" broke the use
av_interleaved_write_uncoded_frame as any input uncoded frame has an
invalid packet size that will crash when av_packet_ref tries to allocate
'size' new memory. Since the packet is a temporary created within mux.c
itself it can be used directly without needing a new ref.
Signed-off-by: Matt Oliver <protogonoi@gmail.com>
This solves the problem discussed in https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179238.html
by allowing AVCodec::write_header to be delayed until after packets have been
run through required bitstream filters in order to generate global extradata.
It also provides a mechanism by which a muxer can add a bitstream filter to a
stream automatically, rather than prompting the user to do so.
All encoders set pts and dts properly now (and have been doing that for
a while), so there is no good reason to do any timestamp guessing in the
muxer.
The newly added AVStreamInternal will be later used for storing all the
private fields currently living in AVStream.
It is well known that fabs and fabsf are at least as fast and sometimes
faster than the FFABS macro, at least on the gcc+glibc combination.
For instance, see the reference:
http://patchwork.sourceware.org/patch/6735/.
This was a patch to glibc in order to remove their usages of a macro.
The reason essentially boils down to fabs using the __builtin_fabs of
the compiler, while FFABS needs to infer to not use a branch and to
simply change the sign bit. Usually the inference works, but sometimes
it does not. This may be easily checked by looking at the asm.
This also has the added benefit of reducing macro usage, which has
problems with side-effects.
Note that avcodec is not handled here, as it is huge and
most things there are integer arithmetic anyway.
Tested with FATE.
Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Move field to internal part of AVStream and struct to internal.h
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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).