2003-07-10 02:10:59 +03:00
|
|
|
/*
|
2006-10-23 11:57:54 +03:00
|
|
|
* FLV muxer
|
2011-03-18 19:35:10 +02:00
|
|
|
* Copyright (c) 2003 The Libav Project
|
2003-07-10 02:10:59 +03:00
|
|
|
*
|
2011-03-18 19:35:10 +02:00
|
|
|
* This file is part of Libav.
|
2006-10-07 18:30:46 +03:00
|
|
|
*
|
2011-03-18 19:35:10 +02:00
|
|
|
* Libav is free software; you can redistribute it and/or
|
2003-07-10 02:10:59 +03:00
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
2006-10-07 18:30:46 +03:00
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
2003-07-10 02:10:59 +03:00
|
|
|
*
|
2011-03-18 19:35:10 +02:00
|
|
|
* Libav is distributed in the hope that it will be useful,
|
2003-07-10 02:10:59 +03:00
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
2011-03-18 19:35:10 +02:00
|
|
|
* License along with Libav; if not, write to the Free Software
|
2006-01-13 00:43:26 +02:00
|
|
|
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
|
2003-07-10 02:10:59 +03:00
|
|
|
*/
|
2011-06-04 14:42:16 +03:00
|
|
|
|
2012-06-27 11:16:18 +03:00
|
|
|
#include "libavutil/dict.h"
|
2011-11-27 17:04:16 +03:00
|
|
|
#include "libavutil/intfloat.h"
|
2016-05-04 21:06:43 +02:00
|
|
|
#include "libavutil/mathematics.h"
|
2012-06-27 11:16:18 +03:00
|
|
|
#include "avc.h"
|
2003-07-10 02:10:59 +03:00
|
|
|
#include "avformat.h"
|
2006-12-06 02:23:04 +02:00
|
|
|
#include "flv.h"
|
2010-05-22 19:01:32 +03:00
|
|
|
#include "internal.h"
|
2010-09-11 02:29:07 +03:00
|
|
|
#include "metadata.h"
|
2003-07-10 02:10:59 +03:00
|
|
|
|
2004-04-17 15:04:59 +03:00
|
|
|
#undef NDEBUG
|
|
|
|
#include <assert.h>
|
|
|
|
|
2007-01-21 03:39:17 +02:00
|
|
|
static const AVCodecTag flv_video_codec_ids[] = {
|
2012-08-05 12:11:04 +03:00
|
|
|
{ AV_CODEC_ID_FLV1, FLV_CODECID_H263 },
|
|
|
|
{ AV_CODEC_ID_FLASHSV, FLV_CODECID_SCREEN },
|
|
|
|
{ AV_CODEC_ID_FLASHSV2, FLV_CODECID_SCREEN2 },
|
|
|
|
{ AV_CODEC_ID_VP6F, FLV_CODECID_VP6 },
|
2013-08-15 11:04:07 +03:00
|
|
|
{ AV_CODEC_ID_VP6A, FLV_CODECID_VP6A },
|
2012-08-05 12:11:04 +03:00
|
|
|
{ AV_CODEC_ID_H264, FLV_CODECID_H264 },
|
|
|
|
{ AV_CODEC_ID_NONE, 0 }
|
2006-12-28 14:35:22 +02:00
|
|
|
};
|
|
|
|
|
2007-01-21 03:39:17 +02:00
|
|
|
static const AVCodecTag flv_audio_codec_ids[] = {
|
2012-08-05 12:11:04 +03:00
|
|
|
{ AV_CODEC_ID_MP3, FLV_CODECID_MP3 >> FLV_AUDIO_CODECID_OFFSET },
|
|
|
|
{ AV_CODEC_ID_PCM_U8, FLV_CODECID_PCM >> FLV_AUDIO_CODECID_OFFSET },
|
|
|
|
{ AV_CODEC_ID_PCM_S16BE, FLV_CODECID_PCM >> FLV_AUDIO_CODECID_OFFSET },
|
|
|
|
{ AV_CODEC_ID_PCM_S16LE, FLV_CODECID_PCM_LE >> FLV_AUDIO_CODECID_OFFSET },
|
|
|
|
{ AV_CODEC_ID_ADPCM_SWF, FLV_CODECID_ADPCM >> FLV_AUDIO_CODECID_OFFSET },
|
|
|
|
{ AV_CODEC_ID_AAC, FLV_CODECID_AAC >> FLV_AUDIO_CODECID_OFFSET },
|
|
|
|
{ AV_CODEC_ID_NELLYMOSER, FLV_CODECID_NELLYMOSER >> FLV_AUDIO_CODECID_OFFSET },
|
|
|
|
{ AV_CODEC_ID_PCM_MULAW, FLV_CODECID_PCM_MULAW >> FLV_AUDIO_CODECID_OFFSET },
|
|
|
|
{ AV_CODEC_ID_PCM_ALAW, FLV_CODECID_PCM_ALAW >> FLV_AUDIO_CODECID_OFFSET },
|
|
|
|
{ AV_CODEC_ID_SPEEX, FLV_CODECID_SPEEX >> FLV_AUDIO_CODECID_OFFSET },
|
|
|
|
{ AV_CODEC_ID_NONE, 0 }
|
2006-12-28 14:35:22 +02:00
|
|
|
};
|
|
|
|
|
2003-07-10 02:10:59 +03:00
|
|
|
typedef struct FLVContext {
|
2012-06-27 11:16:18 +03:00
|
|
|
int reserved;
|
2008-10-03 13:16:29 +03:00
|
|
|
int64_t duration_offset;
|
|
|
|
int64_t filesize_offset;
|
2006-08-06 18:29:50 +03:00
|
|
|
int64_t duration;
|
2011-10-26 19:43:18 +03:00
|
|
|
int64_t delay; ///< first dts delay (needed for AVC & Speex)
|
2014-11-07 23:09:09 +02:00
|
|
|
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
AVCodecParameters *audio_par;
|
|
|
|
AVCodecParameters *video_par;
|
2014-11-07 23:09:09 +02:00
|
|
|
double framerate;
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
AVCodecParameters *data_par;
|
2003-07-10 02:10:59 +03:00
|
|
|
} FLVContext;
|
|
|
|
|
2011-10-20 22:08:48 +03:00
|
|
|
typedef struct FLVStreamContext {
|
|
|
|
int64_t last_ts; ///< last timestamp for each stream
|
|
|
|
} FLVStreamContext;
|
|
|
|
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
static int get_audio_flags(AVFormatContext *s, AVCodecParameters *par)
|
2012-05-07 17:09:30 +03:00
|
|
|
{
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
int flags = (par->bits_per_coded_sample == 16) ? FLV_SAMPLESSIZE_16BIT
|
2012-06-27 11:16:18 +03:00
|
|
|
: FLV_SAMPLESSIZE_8BIT;
|
2004-07-02 22:26:51 +03:00
|
|
|
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
if (par->codec_id == AV_CODEC_ID_AAC) // specs force these parameters
|
2012-06-27 11:16:18 +03:00
|
|
|
return FLV_CODECID_AAC | FLV_SAMPLERATE_44100HZ |
|
|
|
|
FLV_SAMPLESSIZE_16BIT | FLV_STEREO;
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
else if (par->codec_id == AV_CODEC_ID_SPEEX) {
|
|
|
|
if (par->sample_rate != 16000) {
|
2012-06-27 11:16:18 +03:00
|
|
|
av_log(s, AV_LOG_ERROR,
|
|
|
|
"flv only supports wideband (16kHz) Speex audio\n");
|
2009-10-16 06:02:25 +03:00
|
|
|
return -1;
|
|
|
|
}
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
if (par->channels != 1) {
|
2012-05-07 17:09:30 +03:00
|
|
|
av_log(s, AV_LOG_ERROR, "flv only supports mono Speex audio\n");
|
2009-10-16 06:02:25 +03:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return FLV_CODECID_SPEEX | FLV_SAMPLERATE_11025HZ | FLV_SAMPLESSIZE_16BIT;
|
|
|
|
} else {
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
switch (par->sample_rate) {
|
2012-06-27 11:16:18 +03:00
|
|
|
case 44100:
|
2006-12-06 02:23:04 +02:00
|
|
|
flags |= FLV_SAMPLERATE_44100HZ;
|
2004-07-02 22:26:51 +03:00
|
|
|
break;
|
2012-06-27 11:16:18 +03:00
|
|
|
case 22050:
|
2006-12-06 02:23:04 +02:00
|
|
|
flags |= FLV_SAMPLERATE_22050HZ;
|
2004-07-02 22:26:51 +03:00
|
|
|
break;
|
2012-06-27 11:16:18 +03:00
|
|
|
case 11025:
|
2006-12-06 02:23:04 +02:00
|
|
|
flags |= FLV_SAMPLERATE_11025HZ;
|
2004-07-02 22:26:51 +03:00
|
|
|
break;
|
2012-06-27 11:16:18 +03:00
|
|
|
case 16000: // nellymoser only
|
|
|
|
case 8000: // nellymoser only
|
|
|
|
case 5512: // not MP3
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
if (par->codec_id != AV_CODEC_ID_MP3) {
|
2007-10-09 04:12:27 +03:00
|
|
|
flags |= FLV_SAMPLERATE_SPECIAL;
|
|
|
|
break;
|
2007-10-09 04:01:07 +03:00
|
|
|
}
|
2004-07-02 22:26:51 +03:00
|
|
|
default:
|
2012-06-27 11:16:18 +03:00
|
|
|
av_log(s, AV_LOG_ERROR,
|
|
|
|
"flv does not support that sample rate, "
|
|
|
|
"choose from (44100, 22050, 11025).\n");
|
2004-07-02 22:26:51 +03:00
|
|
|
return -1;
|
2012-06-27 11:16:18 +03:00
|
|
|
}
|
2008-05-27 01:00:35 +03:00
|
|
|
}
|
2004-07-02 22:26:51 +03:00
|
|
|
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
if (par->channels > 1)
|
2006-12-06 02:23:04 +02:00
|
|
|
flags |= FLV_STEREO;
|
2005-12-17 20:14:38 +02:00
|
|
|
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
switch (par->codec_id) {
|
2012-08-05 12:11:04 +03:00
|
|
|
case AV_CODEC_ID_MP3:
|
2006-12-06 02:23:04 +02:00
|
|
|
flags |= FLV_CODECID_MP3 | FLV_SAMPLESSIZE_16BIT;
|
2004-07-02 22:26:51 +03:00
|
|
|
break;
|
2012-08-05 12:11:04 +03:00
|
|
|
case AV_CODEC_ID_PCM_U8:
|
2008-02-24 02:57:15 +02:00
|
|
|
flags |= FLV_CODECID_PCM | FLV_SAMPLESSIZE_8BIT;
|
2005-12-22 03:10:11 +02:00
|
|
|
break;
|
2012-08-05 12:11:04 +03:00
|
|
|
case AV_CODEC_ID_PCM_S16BE:
|
2008-02-24 02:57:15 +02:00
|
|
|
flags |= FLV_CODECID_PCM | FLV_SAMPLESSIZE_16BIT;
|
2005-12-22 03:10:11 +02:00
|
|
|
break;
|
2012-08-05 12:11:04 +03:00
|
|
|
case AV_CODEC_ID_PCM_S16LE:
|
2006-12-06 02:23:04 +02:00
|
|
|
flags |= FLV_CODECID_PCM_LE | FLV_SAMPLESSIZE_16BIT;
|
2005-12-22 03:10:11 +02:00
|
|
|
break;
|
2012-08-05 12:11:04 +03:00
|
|
|
case AV_CODEC_ID_ADPCM_SWF:
|
2012-06-27 11:16:18 +03:00
|
|
|
flags |= FLV_CODECID_ADPCM | FLV_SAMPLESSIZE_16BIT;
|
2005-12-22 03:10:11 +02:00
|
|
|
break;
|
2012-08-05 12:11:04 +03:00
|
|
|
case AV_CODEC_ID_NELLYMOSER:
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
if (par->sample_rate == 8000)
|
2012-06-27 11:16:18 +03:00
|
|
|
flags |= FLV_CODECID_NELLYMOSER_8KHZ_MONO | FLV_SAMPLESSIZE_16BIT;
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
else if (par->sample_rate == 16000)
|
2011-12-15 16:10:57 +03:00
|
|
|
flags |= FLV_CODECID_NELLYMOSER_16KHZ_MONO | FLV_SAMPLESSIZE_16BIT;
|
2012-06-27 11:16:18 +03:00
|
|
|
else
|
|
|
|
flags |= FLV_CODECID_NELLYMOSER | FLV_SAMPLESSIZE_16BIT;
|
2008-05-02 22:35:31 +03:00
|
|
|
break;
|
2012-08-05 12:11:04 +03:00
|
|
|
case AV_CODEC_ID_PCM_MULAW:
|
2012-06-28 17:28:56 +03:00
|
|
|
flags = FLV_CODECID_PCM_MULAW | FLV_SAMPLERATE_SPECIAL | FLV_SAMPLESSIZE_16BIT;
|
|
|
|
break;
|
2012-08-05 12:11:04 +03:00
|
|
|
case AV_CODEC_ID_PCM_ALAW:
|
2012-06-28 17:28:56 +03:00
|
|
|
flags = FLV_CODECID_PCM_ALAW | FLV_SAMPLERATE_SPECIAL | FLV_SAMPLESSIZE_16BIT;
|
|
|
|
break;
|
2004-07-02 22:26:51 +03:00
|
|
|
case 0:
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
flags |= par->codec_tag << 4;
|
2004-07-02 22:26:51 +03:00
|
|
|
break;
|
|
|
|
default:
|
2012-05-07 17:09:30 +03:00
|
|
|
av_log(s, AV_LOG_ERROR, "codec not compatible with flv\n");
|
2004-07-02 22:26:51 +03:00
|
|
|
return -1;
|
|
|
|
}
|
2005-12-17 20:14:38 +02:00
|
|
|
|
2004-07-02 22:26:51 +03:00
|
|
|
return flags;
|
|
|
|
}
|
|
|
|
|
2011-02-20 12:04:12 +02:00
|
|
|
static void put_amf_string(AVIOContext *pb, const char *str)
|
2006-07-18 00:51:21 +03:00
|
|
|
{
|
|
|
|
size_t len = strlen(str);
|
2011-02-21 20:28:17 +02:00
|
|
|
avio_wb16(pb, len);
|
|
|
|
avio_write(pb, str, len);
|
2006-07-18 00:51:21 +03:00
|
|
|
}
|
|
|
|
|
2012-06-27 11:16:18 +03:00
|
|
|
static void put_avc_eos_tag(AVIOContext *pb, unsigned ts)
|
|
|
|
{
|
2011-02-21 20:28:17 +02:00
|
|
|
avio_w8(pb, FLV_TAG_TYPE_VIDEO);
|
2012-06-27 11:16:18 +03:00
|
|
|
avio_wb24(pb, 5); /* Tag Data Size */
|
|
|
|
avio_wb24(pb, ts); /* lower 24 bits of timestamp in ms */
|
|
|
|
avio_w8(pb, (ts >> 24) & 0x7F); /* MSB of ts in ms */
|
|
|
|
avio_wb24(pb, 0); /* StreamId = 0 */
|
|
|
|
avio_w8(pb, 23); /* ub[4] FrameType = 1, ub[4] CodecId = 7 */
|
|
|
|
avio_w8(pb, 2); /* AVC end of sequence */
|
|
|
|
avio_wb24(pb, 0); /* Always 0 for AVC EOS. */
|
|
|
|
avio_wb32(pb, 16); /* Size of FLV tag */
|
2010-08-18 12:39:21 +03:00
|
|
|
}
|
|
|
|
|
2011-02-20 12:04:12 +02:00
|
|
|
static void put_amf_double(AVIOContext *pb, double d)
|
2006-07-18 00:51:21 +03:00
|
|
|
{
|
2011-02-21 20:28:17 +02:00
|
|
|
avio_w8(pb, AMF_DATA_TYPE_NUMBER);
|
2011-11-27 17:04:16 +03:00
|
|
|
avio_wb64(pb, av_double2int(d));
|
2006-07-18 00:51:21 +03:00
|
|
|
}
|
|
|
|
|
2012-06-27 11:16:18 +03:00
|
|
|
static void put_amf_bool(AVIOContext *pb, int b)
|
|
|
|
{
|
2011-02-21 20:28:17 +02:00
|
|
|
avio_w8(pb, AMF_DATA_TYPE_BOOL);
|
|
|
|
avio_w8(pb, !!b);
|
2006-12-28 14:35:22 +02:00
|
|
|
}
|
|
|
|
|
2014-11-07 23:09:10 +02:00
|
|
|
static void write_metadata(AVFormatContext *s, unsigned int ts)
|
2003-07-10 02:10:59 +03:00
|
|
|
{
|
2011-02-20 12:04:12 +02:00
|
|
|
AVIOContext *pb = s->pb;
|
2003-07-10 02:10:59 +03:00
|
|
|
FLVContext *flv = s->priv_data;
|
2014-11-17 14:08:05 +02:00
|
|
|
int metadata_count = 0;
|
2011-09-21 16:58:07 +03:00
|
|
|
int64_t metadata_size_pos, data_size, metadata_count_pos;
|
2011-05-22 13:46:29 +03:00
|
|
|
AVDictionaryEntry *tag = NULL;
|
2003-07-10 02:10:59 +03:00
|
|
|
|
2006-07-18 00:51:21 +03:00
|
|
|
/* write meta_tag */
|
2012-06-27 11:16:18 +03:00
|
|
|
avio_w8(pb, 18); // tag type META
|
|
|
|
metadata_size_pos = avio_tell(pb);
|
|
|
|
avio_wb24(pb, 0); // size of data part (sum of all parts below)
|
2014-11-07 23:09:10 +02:00
|
|
|
avio_wb24(pb, ts); // timestamp
|
2012-06-27 11:16:18 +03:00
|
|
|
avio_wb32(pb, 0); // reserved
|
2006-07-18 00:51:21 +03:00
|
|
|
|
|
|
|
/* now data of data_size size */
|
|
|
|
|
|
|
|
/* first event name as a string */
|
2011-02-21 20:28:17 +02:00
|
|
|
avio_w8(pb, AMF_DATA_TYPE_STRING);
|
2006-07-18 00:51:21 +03:00
|
|
|
put_amf_string(pb, "onMetaData"); // 12 bytes
|
|
|
|
|
|
|
|
/* mixed array (hash) with size and string/type/data tuples */
|
2011-02-21 20:28:17 +02:00
|
|
|
avio_w8(pb, AMF_DATA_TYPE_MIXEDARRAY);
|
2011-09-21 16:58:07 +03:00
|
|
|
metadata_count_pos = avio_tell(pb);
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
metadata_count = 4 * !!flv->video_par +
|
|
|
|
5 * !!flv->audio_par +
|
|
|
|
1 * !!flv->data_par +
|
2012-05-10 00:35:58 +03:00
|
|
|
2; // +2 for duration and file size
|
|
|
|
|
2011-09-21 16:58:07 +03:00
|
|
|
avio_wb32(pb, metadata_count);
|
2006-07-18 00:51:21 +03:00
|
|
|
|
2006-08-06 18:29:50 +03:00
|
|
|
put_amf_string(pb, "duration");
|
2014-11-07 23:09:09 +02:00
|
|
|
flv->duration_offset = avio_tell(pb);
|
2006-07-18 00:51:21 +03:00
|
|
|
|
2012-06-27 11:16:18 +03:00
|
|
|
// fill in the guessed duration, it'll be corrected later if incorrect
|
|
|
|
put_amf_double(pb, s->duration / AV_TIME_BASE);
|
|
|
|
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
if (flv->video_par) {
|
2006-07-18 00:51:21 +03:00
|
|
|
put_amf_string(pb, "width");
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
put_amf_double(pb, flv->video_par->width);
|
2006-07-18 00:51:21 +03:00
|
|
|
|
|
|
|
put_amf_string(pb, "height");
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
put_amf_double(pb, flv->video_par->height);
|
2006-07-18 00:51:21 +03:00
|
|
|
|
|
|
|
put_amf_string(pb, "videodatarate");
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
put_amf_double(pb, flv->video_par->bit_rate / 1024.0);
|
2006-07-18 00:51:21 +03:00
|
|
|
|
2014-11-07 23:09:09 +02:00
|
|
|
if (flv->framerate != 0.0) {
|
2014-05-27 10:49:29 +03:00
|
|
|
put_amf_string(pb, "framerate");
|
2014-11-07 23:09:09 +02:00
|
|
|
put_amf_double(pb, flv->framerate);
|
2014-06-11 04:45:07 +03:00
|
|
|
metadata_count++;
|
2014-05-27 10:49:29 +03:00
|
|
|
}
|
2006-12-28 14:35:22 +02:00
|
|
|
|
|
|
|
put_amf_string(pb, "videocodecid");
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
put_amf_double(pb, flv->video_par->codec_tag);
|
2006-07-18 00:51:21 +03:00
|
|
|
}
|
|
|
|
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
if (flv->audio_par) {
|
2009-02-02 18:10:46 +02:00
|
|
|
put_amf_string(pb, "audiodatarate");
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
put_amf_double(pb, flv->audio_par->bit_rate / 1024.0);
|
2009-02-02 18:10:46 +02:00
|
|
|
|
2006-07-18 00:51:21 +03:00
|
|
|
put_amf_string(pb, "audiosamplerate");
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
put_amf_double(pb, flv->audio_par->sample_rate);
|
2006-12-28 14:35:22 +02:00
|
|
|
|
|
|
|
put_amf_string(pb, "audiosamplesize");
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
put_amf_double(pb, flv->audio_par->codec_id == AV_CODEC_ID_PCM_U8 ? 8 : 16);
|
2006-12-28 14:35:22 +02:00
|
|
|
|
|
|
|
put_amf_string(pb, "stereo");
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
put_amf_bool(pb, flv->audio_par->channels == 2);
|
2006-12-28 14:35:22 +02:00
|
|
|
|
|
|
|
put_amf_string(pb, "audiocodecid");
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
put_amf_double(pb, flv->audio_par->codec_tag);
|
2006-07-18 00:51:21 +03:00
|
|
|
}
|
|
|
|
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
if (flv->data_par) {
|
2012-05-10 00:35:58 +03:00
|
|
|
put_amf_string(pb, "datastream");
|
|
|
|
put_amf_double(pb, 0.0);
|
|
|
|
}
|
|
|
|
|
2011-05-22 13:46:29 +03:00
|
|
|
while ((tag = av_dict_get(s->metadata, "", tag, AV_DICT_IGNORE_SUFFIX))) {
|
2010-09-11 02:29:07 +03:00
|
|
|
put_amf_string(pb, tag->key);
|
2011-02-21 20:28:17 +02:00
|
|
|
avio_w8(pb, AMF_DATA_TYPE_STRING);
|
2010-09-11 02:29:07 +03:00
|
|
|
put_amf_string(pb, tag->value);
|
2011-09-21 16:58:07 +03:00
|
|
|
metadata_count++;
|
2010-09-11 02:29:07 +03:00
|
|
|
}
|
|
|
|
|
2006-08-06 18:29:50 +03:00
|
|
|
put_amf_string(pb, "filesize");
|
2012-06-27 11:16:18 +03:00
|
|
|
flv->filesize_offset = avio_tell(pb);
|
2006-08-06 18:29:50 +03:00
|
|
|
put_amf_double(pb, 0); // delayed write
|
2006-07-18 00:51:21 +03:00
|
|
|
|
|
|
|
put_amf_string(pb, "");
|
2011-02-21 20:28:17 +02:00
|
|
|
avio_w8(pb, AMF_END_OF_OBJECT);
|
2006-07-18 00:51:21 +03:00
|
|
|
|
|
|
|
/* write total size of tag */
|
2012-06-27 11:16:18 +03:00
|
|
|
data_size = avio_tell(pb) - metadata_size_pos - 10;
|
2011-09-21 16:58:07 +03:00
|
|
|
|
|
|
|
avio_seek(pb, metadata_count_pos, SEEK_SET);
|
|
|
|
avio_wb32(pb, metadata_count);
|
|
|
|
|
2011-02-28 15:57:54 +02:00
|
|
|
avio_seek(pb, metadata_size_pos, SEEK_SET);
|
2011-02-21 20:28:17 +02:00
|
|
|
avio_wb24(pb, data_size);
|
2011-03-15 10:14:38 +02:00
|
|
|
avio_skip(pb, data_size + 10 - 3);
|
2011-02-21 20:28:17 +02:00
|
|
|
avio_wb32(pb, data_size + 11);
|
2014-11-07 23:09:09 +02:00
|
|
|
}
|
|
|
|
|
2015-03-03 15:39:26 +02:00
|
|
|
static int unsupported_codec(AVFormatContext *s,
|
|
|
|
const char* type, int codec_id)
|
|
|
|
{
|
|
|
|
const AVCodecDescriptor *desc = avcodec_descriptor_get(codec_id);
|
|
|
|
av_log(s, AV_LOG_ERROR,
|
|
|
|
"%s codec %s not compatible with flv\n",
|
|
|
|
type,
|
|
|
|
desc ? desc->name : "unknown");
|
|
|
|
return AVERROR(ENOSYS);
|
|
|
|
}
|
|
|
|
|
2014-11-07 23:09:09 +02:00
|
|
|
static int flv_write_header(AVFormatContext *s)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
AVIOContext *pb = s->pb;
|
|
|
|
FLVContext *flv = s->priv_data;
|
|
|
|
int64_t data_size;
|
|
|
|
|
|
|
|
for (i = 0; i < s->nb_streams; i++) {
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
AVCodecParameters *par = s->streams[i]->codecpar;
|
2014-11-07 23:09:09 +02:00
|
|
|
FLVStreamContext *sc;
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
switch (par->codec_type) {
|
2014-11-07 23:09:09 +02:00
|
|
|
case AVMEDIA_TYPE_VIDEO:
|
|
|
|
if (s->streams[i]->avg_frame_rate.den &&
|
|
|
|
s->streams[i]->avg_frame_rate.num) {
|
|
|
|
flv->framerate = av_q2d(s->streams[i]->avg_frame_rate);
|
|
|
|
}
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
if (flv->video_par) {
|
2014-11-07 23:09:09 +02:00
|
|
|
av_log(s, AV_LOG_ERROR,
|
|
|
|
"at most one video stream is supported in flv\n");
|
|
|
|
return AVERROR(EINVAL);
|
|
|
|
}
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
flv->video_par = par;
|
|
|
|
if (!ff_codec_get_tag(flv_video_codec_ids, par->codec_id))
|
|
|
|
return unsupported_codec(s, "Video", par->codec_id);
|
2014-11-07 23:09:09 +02:00
|
|
|
break;
|
|
|
|
case AVMEDIA_TYPE_AUDIO:
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
if (flv->audio_par) {
|
2014-11-07 23:09:09 +02:00
|
|
|
av_log(s, AV_LOG_ERROR,
|
|
|
|
"at most one audio stream is supported in flv\n");
|
|
|
|
return AVERROR(EINVAL);
|
|
|
|
}
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
flv->audio_par = par;
|
|
|
|
if (get_audio_flags(s, par) < 0)
|
|
|
|
return unsupported_codec(s, "Audio", par->codec_id);
|
2014-11-07 23:09:09 +02:00
|
|
|
break;
|
|
|
|
case AVMEDIA_TYPE_DATA:
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
if (par->codec_id != AV_CODEC_ID_TEXT)
|
|
|
|
return unsupported_codec(s, "Data", par->codec_id);
|
|
|
|
flv->data_par = par;
|
2014-11-07 23:09:09 +02:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
av_log(s, AV_LOG_ERROR, "codec not compatible with flv\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
avpriv_set_pts_info(s->streams[i], 32, 1, 1000); /* 32 bit pts in ms */
|
|
|
|
|
|
|
|
sc = av_mallocz(sizeof(FLVStreamContext));
|
|
|
|
if (!sc)
|
|
|
|
return AVERROR(ENOMEM);
|
|
|
|
s->streams[i]->priv_data = sc;
|
|
|
|
sc->last_ts = -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
flv->delay = AV_NOPTS_VALUE;
|
|
|
|
|
|
|
|
avio_write(pb, "FLV", 3);
|
|
|
|
avio_w8(pb, 1);
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
avio_w8(pb, FLV_HEADER_FLAG_HASAUDIO * !!flv->audio_par +
|
|
|
|
FLV_HEADER_FLAG_HASVIDEO * !!flv->video_par);
|
2014-11-07 23:09:09 +02:00
|
|
|
avio_wb32(pb, 9);
|
|
|
|
avio_wb32(pb, 0);
|
|
|
|
|
|
|
|
for (i = 0; i < s->nb_streams; i++)
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
if (s->streams[i]->codecpar->codec_tag == 5) {
|
2014-11-07 23:09:09 +02:00
|
|
|
avio_w8(pb, 8); // message type
|
|
|
|
avio_wb24(pb, 0); // include flags
|
|
|
|
avio_wb24(pb, 0); // time stamp
|
|
|
|
avio_wb32(pb, 0); // reserved
|
|
|
|
avio_wb32(pb, 11); // size
|
|
|
|
flv->reserved = 5;
|
|
|
|
}
|
|
|
|
|
2014-11-07 23:09:10 +02:00
|
|
|
write_metadata(s, 0);
|
2006-07-18 00:51:21 +03:00
|
|
|
|
2008-05-27 01:00:35 +03:00
|
|
|
for (i = 0; i < s->nb_streams; i++) {
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
AVCodecParameters *par = s->streams[i]->codecpar;
|
|
|
|
if (par->codec_id == AV_CODEC_ID_AAC || par->codec_id == AV_CODEC_ID_H264) {
|
2008-10-03 13:16:29 +03:00
|
|
|
int64_t pos;
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
avio_w8(pb, par->codec_type == AVMEDIA_TYPE_VIDEO ?
|
2012-06-27 11:16:18 +03:00
|
|
|
FLV_TAG_TYPE_VIDEO : FLV_TAG_TYPE_AUDIO);
|
2011-02-21 20:28:17 +02:00
|
|
|
avio_wb24(pb, 0); // size patched later
|
|
|
|
avio_wb24(pb, 0); // ts
|
2012-06-27 11:16:18 +03:00
|
|
|
avio_w8(pb, 0); // ts ext
|
2011-02-21 20:28:17 +02:00
|
|
|
avio_wb24(pb, 0); // streamid
|
2011-03-03 21:11:45 +02:00
|
|
|
pos = avio_tell(pb);
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
if (par->codec_id == AV_CODEC_ID_AAC) {
|
|
|
|
avio_w8(pb, get_audio_flags(s, par));
|
2011-02-21 20:28:17 +02:00
|
|
|
avio_w8(pb, 0); // AAC sequence header
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
avio_write(pb, par->extradata, par->extradata_size);
|
2008-05-27 01:00:35 +03:00
|
|
|
} else {
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
avio_w8(pb, par->codec_tag | FLV_FRAME_KEY); // flags
|
2011-02-21 20:28:17 +02:00
|
|
|
avio_w8(pb, 0); // AVC sequence header
|
|
|
|
avio_wb24(pb, 0); // composition time
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
ff_isom_write_avcc(pb, par->extradata, par->extradata_size);
|
2008-05-27 01:00:35 +03:00
|
|
|
}
|
2011-03-03 21:11:45 +02:00
|
|
|
data_size = avio_tell(pb) - pos;
|
2011-02-28 15:57:54 +02:00
|
|
|
avio_seek(pb, -data_size - 10, SEEK_CUR);
|
2011-02-21 20:28:17 +02:00
|
|
|
avio_wb24(pb, data_size);
|
2011-03-15 10:14:38 +02:00
|
|
|
avio_skip(pb, data_size + 10 - 3);
|
2011-02-21 20:28:17 +02:00
|
|
|
avio_wb32(pb, data_size + 11); // previous tag size
|
2008-05-27 01:00:35 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-07-10 02:10:59 +03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int flv_write_trailer(AVFormatContext *s)
|
|
|
|
{
|
2003-07-11 02:18:09 +03:00
|
|
|
int64_t file_size;
|
|
|
|
|
2011-02-20 12:04:12 +02:00
|
|
|
AVIOContext *pb = s->pb;
|
2003-07-10 02:10:59 +03:00
|
|
|
FLVContext *flv = s->priv_data;
|
2010-08-18 12:39:21 +03:00
|
|
|
int i;
|
|
|
|
|
|
|
|
/* Add EOS tag */
|
|
|
|
for (i = 0; i < s->nb_streams; i++) {
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
AVCodecParameters *par = s->streams[i]->codecpar;
|
2011-10-20 22:08:48 +03:00
|
|
|
FLVStreamContext *sc = s->streams[i]->priv_data;
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
if (par->codec_type == AVMEDIA_TYPE_VIDEO &&
|
|
|
|
par->codec_id == AV_CODEC_ID_H264)
|
2011-10-20 22:08:48 +03:00
|
|
|
put_avc_eos_tag(pb, sc->last_ts);
|
2010-08-18 12:39:21 +03:00
|
|
|
}
|
2003-07-10 02:10:59 +03:00
|
|
|
|
2011-03-03 21:11:45 +02:00
|
|
|
file_size = avio_tell(pb);
|
2006-08-06 18:29:50 +03:00
|
|
|
|
2011-10-05 15:12:42 +03:00
|
|
|
/* update information */
|
2012-12-13 16:48:25 +03:00
|
|
|
if (avio_seek(pb, flv->duration_offset, SEEK_SET) < 0)
|
|
|
|
av_log(s, AV_LOG_WARNING, "Failed to update header with correct duration.\n");
|
|
|
|
else
|
|
|
|
put_amf_double(pb, flv->duration / (double)1000);
|
|
|
|
if (avio_seek(pb, flv->filesize_offset, SEEK_SET) < 0)
|
|
|
|
av_log(s, AV_LOG_WARNING, "Failed to update header with correct filesize.\n");
|
|
|
|
else
|
|
|
|
put_amf_double(pb, file_size);
|
2006-08-06 18:29:50 +03:00
|
|
|
|
2011-02-28 15:57:54 +02:00
|
|
|
avio_seek(pb, file_size, SEEK_SET);
|
2003-07-10 02:10:59 +03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2004-05-29 05:06:32 +03:00
|
|
|
static int flv_write_packet(AVFormatContext *s, AVPacket *pkt)
|
2003-07-10 02:10:59 +03:00
|
|
|
{
|
2012-06-27 11:16:18 +03:00
|
|
|
AVIOContext *pb = s->pb;
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
AVCodecParameters *par = s->streams[pkt->stream_index]->codecpar;
|
2012-06-27 11:16:18 +03:00
|
|
|
FLVContext *flv = s->priv_data;
|
2011-10-20 22:08:48 +03:00
|
|
|
FLVStreamContext *sc = s->streams[pkt->stream_index]->priv_data;
|
2008-05-27 01:00:35 +03:00
|
|
|
unsigned ts;
|
2012-06-27 11:16:18 +03:00
|
|
|
int size = pkt->size;
|
|
|
|
uint8_t *data = NULL;
|
2012-09-17 22:14:58 +03:00
|
|
|
int flags = 0, flags_size;
|
2003-07-10 02:10:59 +03:00
|
|
|
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
if (par->codec_id == AV_CODEC_ID_VP6F || par->codec_id == AV_CODEC_ID_VP6A ||
|
|
|
|
par->codec_id == AV_CODEC_ID_AAC)
|
2012-06-27 11:16:18 +03:00
|
|
|
flags_size = 2;
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
else if (par->codec_id == AV_CODEC_ID_H264)
|
2012-06-27 11:16:18 +03:00
|
|
|
flags_size = 5;
|
2007-08-05 02:03:17 +03:00
|
|
|
else
|
2012-06-27 11:16:18 +03:00
|
|
|
flags_size = 1;
|
2007-08-05 02:03:17 +03:00
|
|
|
|
2014-11-07 23:09:10 +02:00
|
|
|
if (flv->delay == AV_NOPTS_VALUE)
|
|
|
|
flv->delay = -pkt->dts;
|
|
|
|
|
|
|
|
if (pkt->dts < -flv->delay) {
|
|
|
|
av_log(s, AV_LOG_WARNING,
|
|
|
|
"Packets are not in the proper order with respect to DTS\n");
|
|
|
|
return AVERROR(EINVAL);
|
|
|
|
}
|
|
|
|
|
|
|
|
ts = pkt->dts + flv->delay; // add delay to force positive dts
|
|
|
|
|
|
|
|
if (s->event_flags & AVSTREAM_EVENT_FLAG_METADATA_UPDATED) {
|
|
|
|
write_metadata(s, ts);
|
|
|
|
s->event_flags &= ~AVSTREAM_EVENT_FLAG_METADATA_UPDATED;
|
|
|
|
}
|
|
|
|
|
2016-05-04 21:06:43 +02:00
|
|
|
avio_write_marker(pb, av_rescale(ts, AV_TIME_BASE, 1000),
|
|
|
|
pkt->flags & AV_PKT_FLAG_KEY && (flv->video_par ? par->codec_type == AVMEDIA_TYPE_VIDEO : 1) ? AVIO_DATA_MARKER_SYNC_POINT : AVIO_DATA_MARKER_BOUNDARY_POINT);
|
|
|
|
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
switch (par->codec_type) {
|
2012-05-10 00:35:58 +03:00
|
|
|
case AVMEDIA_TYPE_VIDEO:
|
2011-02-21 20:28:17 +02:00
|
|
|
avio_w8(pb, FLV_TAG_TYPE_VIDEO);
|
2007-01-02 00:52:22 +02:00
|
|
|
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
flags = ff_codec_get_tag(flv_video_codec_ids, par->codec_id);
|
2007-01-02 00:52:22 +02:00
|
|
|
|
2010-03-31 15:29:58 +03:00
|
|
|
flags |= pkt->flags & AV_PKT_FLAG_KEY ? FLV_FRAME_KEY : FLV_FRAME_INTER;
|
2012-05-10 00:35:58 +03:00
|
|
|
break;
|
|
|
|
case AVMEDIA_TYPE_AUDIO:
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
flags = get_audio_flags(s, par);
|
2005-12-17 20:14:38 +02:00
|
|
|
|
2004-04-17 15:04:59 +03:00
|
|
|
assert(size);
|
|
|
|
|
2011-02-21 20:28:17 +02:00
|
|
|
avio_w8(pb, FLV_TAG_TYPE_AUDIO);
|
2012-05-10 00:35:58 +03:00
|
|
|
break;
|
|
|
|
case AVMEDIA_TYPE_DATA:
|
|
|
|
avio_w8(pb, FLV_TAG_TYPE_META);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return AVERROR(EINVAL);
|
|
|
|
}
|
2012-06-27 11:16:18 +03:00
|
|
|
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
if (par->codec_id == AV_CODEC_ID_H264)
|
2011-10-05 15:12:42 +03:00
|
|
|
/* check if extradata looks like MP4 */
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
if (par->extradata_size > 0 && *(uint8_t*)par->extradata != 1)
|
2009-01-16 03:22:30 +02:00
|
|
|
if (ff_avc_parse_nal_units_buf(pkt->data, &data, &size) < 0)
|
|
|
|
return -1;
|
2012-06-27 11:16:18 +03:00
|
|
|
|
2011-10-19 20:20:15 +03:00
|
|
|
/* check Speex packet duration */
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
if (par->codec_id == AV_CODEC_ID_SPEEX && ts - sc->last_ts > 160)
|
2011-10-19 20:20:15 +03:00
|
|
|
av_log(s, AV_LOG_WARNING, "Warning: Speex stream has more than "
|
|
|
|
"8 frames per packet. Adobe Flash "
|
|
|
|
"Player cannot handle this!\n");
|
|
|
|
|
2011-10-20 22:08:48 +03:00
|
|
|
if (sc->last_ts < ts)
|
|
|
|
sc->last_ts = ts;
|
2011-10-19 20:20:15 +03:00
|
|
|
|
2012-06-27 11:16:18 +03:00
|
|
|
avio_wb24(pb, size + flags_size);
|
|
|
|
avio_wb24(pb, ts);
|
|
|
|
avio_w8(pb, (ts >> 24) & 0x7F); // timestamps are 32 bits _signed_
|
|
|
|
avio_wb24(pb, flv->reserved);
|
2012-05-10 00:35:58 +03:00
|
|
|
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
if (par->codec_type == AVMEDIA_TYPE_DATA) {
|
2012-05-10 00:35:58 +03:00
|
|
|
int data_size;
|
2013-12-19 09:38:15 +03:00
|
|
|
int64_t metadata_size_pos = avio_tell(pb);
|
2012-05-10 00:35:58 +03:00
|
|
|
avio_w8(pb, AMF_DATA_TYPE_STRING);
|
|
|
|
put_amf_string(pb, "onTextData");
|
|
|
|
avio_w8(pb, AMF_DATA_TYPE_MIXEDARRAY);
|
|
|
|
avio_wb32(pb, 2);
|
|
|
|
put_amf_string(pb, "type");
|
|
|
|
avio_w8(pb, AMF_DATA_TYPE_STRING);
|
|
|
|
put_amf_string(pb, "Text");
|
|
|
|
put_amf_string(pb, "text");
|
|
|
|
avio_w8(pb, AMF_DATA_TYPE_STRING);
|
|
|
|
put_amf_string(pb, pkt->data);
|
|
|
|
put_amf_string(pb, "");
|
|
|
|
avio_w8(pb, AMF_END_OF_OBJECT);
|
|
|
|
/* write total size of tag */
|
|
|
|
data_size = avio_tell(pb) - metadata_size_pos;
|
|
|
|
avio_seek(pb, metadata_size_pos - 10, SEEK_SET);
|
|
|
|
avio_wb24(pb, data_size);
|
|
|
|
avio_seek(pb, data_size + 10 - 3, SEEK_CUR);
|
|
|
|
avio_wb32(pb, data_size + 11);
|
|
|
|
} else {
|
2012-06-27 11:16:18 +03:00
|
|
|
avio_w8(pb,flags);
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
if (par->codec_id == AV_CODEC_ID_VP6F || par->codec_id == AV_CODEC_ID_VP6A) {
|
|
|
|
if (par->extradata_size)
|
|
|
|
avio_w8(pb, par->extradata[0]);
|
2013-08-15 11:07:30 +03:00
|
|
|
else
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
avio_w8(pb, ((FFALIGN(par->width, 16) - par->width) << 4) |
|
|
|
|
(FFALIGN(par->height, 16) - par->height));
|
|
|
|
} else if (par->codec_id == AV_CODEC_ID_AAC)
|
2012-06-27 11:16:18 +03:00
|
|
|
avio_w8(pb, 1); // AAC raw
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 21:42:52 +03:00
|
|
|
else if (par->codec_id == AV_CODEC_ID_H264) {
|
2012-06-27 11:16:18 +03:00
|
|
|
avio_w8(pb, 1); // AVC NALU
|
|
|
|
avio_wb24(pb, pkt->pts - pkt->dts);
|
|
|
|
}
|
2009-01-16 03:22:30 +02:00
|
|
|
|
2012-06-27 11:16:18 +03:00
|
|
|
avio_write(pb, data ? data : pkt->data, size);
|
2009-01-16 03:22:30 +02:00
|
|
|
|
2012-06-27 11:16:18 +03:00
|
|
|
avio_wb32(pb, size + flags_size + 11); // previous tag size
|
|
|
|
flv->duration = FFMAX(flv->duration,
|
|
|
|
pkt->pts + flv->delay + pkt->duration);
|
2012-05-10 00:35:58 +03:00
|
|
|
}
|
2009-01-16 03:22:30 +02:00
|
|
|
|
|
|
|
av_free(data);
|
|
|
|
|
2011-06-06 17:13:05 +03:00
|
|
|
return pb->error;
|
2003-07-10 02:10:59 +03:00
|
|
|
}
|
|
|
|
|
2011-01-26 00:03:28 +02:00
|
|
|
AVOutputFormat ff_flv_muxer = {
|
2011-07-16 23:18:12 +03:00
|
|
|
.name = "flv",
|
2012-07-24 04:23:48 +03:00
|
|
|
.long_name = NULL_IF_CONFIG_SMALL("FLV (Flash Video)"),
|
2011-07-16 23:18:12 +03:00
|
|
|
.mime_type = "video/x-flv",
|
|
|
|
.extensions = "flv",
|
|
|
|
.priv_data_size = sizeof(FLVContext),
|
2012-08-05 12:11:04 +03:00
|
|
|
.audio_codec = CONFIG_LIBMP3LAME ? AV_CODEC_ID_MP3 : AV_CODEC_ID_ADPCM_SWF,
|
|
|
|
.video_codec = AV_CODEC_ID_FLV1,
|
2011-07-16 23:18:12 +03:00
|
|
|
.write_header = flv_write_header,
|
|
|
|
.write_packet = flv_write_packet,
|
|
|
|
.write_trailer = flv_write_trailer,
|
2012-06-27 11:16:18 +03:00
|
|
|
.codec_tag = (const AVCodecTag* const []) {
|
|
|
|
flv_video_codec_ids, flv_audio_codec_ids, 0
|
|
|
|
},
|
2011-05-26 21:19:04 +03:00
|
|
|
.flags = AVFMT_GLOBALHEADER | AVFMT_VARIABLE_FPS |
|
|
|
|
AVFMT_TS_NONSTRICT,
|
2003-07-10 02:10:59 +03:00
|
|
|
};
|