[FFmpeg-devel] [PATCH] avformat/hlsenc: Check ret on avformat_write_header
lq at chinaffmpeg.org
Sun Jan 28 06:07:31 EET 2018
> 在 2018年1月28日，上午7:17，Brendan McGrath <redmcg at redmandi.dyndns.org> 写道：
> On 26/01/18 14:30, 刘歧 wrote:
>>> On 24 Jan 2018, at 09:24, Brendan McGrath <redmcg at redmandi.dyndns.org> wrote:
>>> Encoding currently fails when using hls_ts_options with the fmp4
>>> segment type.
>>> This is due to the fact that avformat_write_header does not process
>>> the passed options when the avformat is already initialized.
>>> When using fmp4, the hls_ts_options are parsed and the avformat
>>> initialized within hls_mux_init.
>>> This patch checks the return of avformat_write_header so that if
>>> it is greater than zero (indicating the avformat is already
>>> initialized) then it does not error.
>>> Signed-off-by: Brendan McGrath <redmcg at redmandi.dyndns.org>
>>> I'm not sure if hls_ts_options is supposed to be used with fmp4 as the
>>> description is currently:
>>> hls_ts_options <string> E....... set hls mpegts list of options for the container format used for hls
>>> If it is (and the code within hls_mux_init seems to indicate that it is) - then this
>>> patch fixes that (and the next will change the description - perhaps the option should
>>> be renamed too?).
>> maybe fmp4 need not use this option in short time.
> I guess the options are:
> a) Use 'hls_ts_options' for both mpegts and fmp4 (just change the description and ignore the fact the name isn't quite right);
> b) Create a new option exclusively for fmp4 (say 'hls_fmp4_options' and change the code to use this for fmp4); or
> c) Create a new option for both mpegts and fmp4 (say 'hls_container_options' and deprecate 'hls_ts_options' - but allowing both for mpegts in the interim)
> a) is he easiest to implement - but b) and c) are more user friendly. If there's a precedent - we should probably follow that.
Yes, your way is absolute right
More information about the ffmpeg-devel