avpriv_mpeg4audio_sample_rates has a size of 64B and it is currently
avpriv; a clone of it exists in aacenctab.h and from there it is inlined
in aacenc.c (which also uses the avpriv version) and in the FLV muxer.
This means that despite it being avpriv both libavformat as well as
libavcodec have copies already.
This situation is clearly suboptimal. Given the overhead of exporting
symbols (for x64 Elf/Linux/GNU: 2x2B version, 2x24B .dynsym, 24B .rela.dyn,
8B .got, 4B hash + twice the size of the name (here 31B)) the object is
unavprived, i.e. duplicated into libavformat when creating a shared
build; but the duplicates in the AAC encoder and FLV muxer are removed.
This involves splitting of the sample rate table into a file of its own;
this allowed to break some spurious dependencies (e.g. both the AAC
encoder as well as the Matroska demuxer actually don't need the
mpeg4audio_get_config stuff).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
FLV AMF tags have a 24bit field for timestamps plus an 8bit for extended
timestamps.
All FLV AMF tags except when we write metadata handle this correctly
using the put_timestamp function.
Until now when writing metadata we were only using the first
24 bits and thus the timestamp value was wraping around 4 hours 40
minutes (16,800,000 ms, max 24 bit value 16,777,216) of playback.
This commit fixes this applying this same function put_timestamp
for the metadata FLV tag.
Signed-off-by: Marton Balint <cus@passwd.hu>
For most check_bitstream() functions this just avoids having
to dereference s->streams[pkt->stream_index] themselves; but for
meta-muxers it will allow to forward the packet to stream with
a different stream_index (belonging to a different AVFormatContext)
without using a spare packet.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible now that the next-API is gone.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
When shifting the already written data in order to write the keyframe
index, the flv muxer would first store the pre-shift size, then
calculate how big the index will be eventually, then perform some seeks
to update some size fields, then seek back to the end of the file to get
the new position, followed by a seek to the position where writing will
really start. Seeking back to the (already known) end position (that is
actually used to perform this seek) to get the end position is of course
unnecessary. It has been removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Might happen for annex B H.264.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
While the function adding a new element to the keyframe index checked
the allocation, the caller didn't check the return value. This has been
changed. To do so, the return value has been changed to an ordinary ret
instead of pb->error. This doesn't pose a problem, as write_packet() in
mux.c already checks for write errors (since 9ad1e0c1).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
mythtv have problem with non-seekable dont write duration and filesize
and there have problem with some other server and player with 0 value
duation and filesize.
So add a flv flags to fix the ticket and make a choose for users.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Add keyframe index metadata
Used to facilitate seeking; particularly for HTTP pseudo streaming.
1. read live streaming or file by sequence
2. if use add_keyframe_index option, add a mark flag at the position,
use to insert new context at the last step.
3. add the keyframes *offset* and *timestamp* into a list
4. if use add_keyframe_index option, shift the metadata data from
mark flag offset
5. insert the keyframes *offset* and *timestamp* from the list by
sequence
6. free the list
7. end.
Add FATE test case;
Reviewed-by: Lou Logan <lou@lrcd.com>
Signed-off-by: Steven Liu <liuqi@gosun.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Its impossible to update the filesize & duration values if seekback is not
possible as with live streams
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
when split flv file by flv format at first, and cat flvs file
into one flv file, the flv sequence end is be used,
then the whole flv have many flv sequence end TAG.
this flags can give user an option to ignore write sequence end TAG
Signed-off-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
add FLVFlags type, be used to add new FLVFlags options
Signed-off-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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.
The purpose of this patch is to preserve timestamps when using ffmpeg for publishing RTMP streams, e.g. ffmpeg -i rtmp://source/stream -f flv rtmp://target/stream.
There is a setting "copyts" for that purpose. Unfortunately it doesn't work with FLV muxer because it has its own timestamp correction which makes global setting "copyts" ineffective.
This patch removes timestamp correction in FLV muxer. This means FLV will rely on ffmpeg timestamp correction which makes it possible to use copyts.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Neccessary -> Necessary
formated -> formatted
thee -> the
eventhough -> even though
seperately -> separately
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This commit has no known use case ATM as there are no unsupported video codecs in flv and could
theoretically be use to generate broken files allthough that would be not entirely easy as
tags/codecs still get sanity checked
This reverts commit 76f4b11780.
This allows stream copying video codecs before they are explicitly
supported. The same feature was in the past useful for audio codecs
in flv
This partly reverts the changes from 735ab7c5e0
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
