because subtitles streams will be written to webvtt m3u8 list
so the stream index should minus subtitles streams count when subtitle
between audio and video streams.
testcase:
before patch:
ffmpeg -i input -map 0🅰️0 -map 0:s:0 -map 0✌️0 -f hls aaaa.m3u8
will EXC_BAD_ACCESS
after patch:
ffmpeg -i input -map 0🅰️0 -map 0:s:0 -map 0✌️0 -f hls aaaa.m3u8
will ok
Signed-off-by: Steven Liu <liuqi05@kuaishou.com>
"frag_start" is redundant, and every occurance can be replaced with cluster[0].dts - start_dts
The proof of no behaviour changes: (All line number below is based on commit bff7d662d7)
"frag_start" is read at 4 place (with all possible call stacks):
mov_write_packet
...
mov_flush_fragment
mov_write_moof_tag
mov_write_moof_tag_internal
mov_write_traf_tag
mov_write_tfxd_tag (#1)
mov_write_tfdt_tag (#2)
mov_add_tfra_entries (#3)
mov_write_sidx_tags
mov_write_sidx_tag (#4)
mov_write_trailer
mov_auto_flush_fragment
mov_flush_fragment
... (#1#2#3#4)
mov_write_sidx_tags
mov_write_sidx_tag (#4)
shift_data
compute_sidx_size
get_sidx_size
mov_write_sidx_tags
mov_write_sidx_tag (#4)
All read happens in "mov_write_trailer" and "mov_write_moof_tag". So we need to prove no behaviour change in these two
functions.
Condition 1: for every track that have "trk->entry == 0", trk->frag_start == trk->track_duration.
Condition 2: for every track that have "trk->entry > 0", trk->frag_start == trk->cluster[0].dts - trk->start_dts.
Definition 1: "Before flush" means just before the invocation of "mov_flush_fragment", except for the auto-flush case in
"mov_write_single_packet", which means before L5934.
Lemma 1: If Condition 1 & 2 is true before flush, Condition 1 & 2 is still true after "mov_flush_fragment" returns.
Proof:
No update to the tracks that have "trk->entry == 0" before flushing, so we only consider tracks that have "trk->entry > 0":
Case 1: !moov_written and moov will be written in this iteration
trk->entry = 0 L5366
trk->frag_start == trk->cluster[0].dts - trk->start_dts Lemma condition
trk->frag_start += trk->start_dts + trk->track_duration - trk->cluster[0].dts; L5363
So trk->entry == 0 && trk->frag_start == trk->track_duration
Case 2: !moov_written and moov will NOT be written in this iteration
nothing changed
Case 3: moov_written
trk->entry = 0 L5445
trk->frag_start == trk->cluster[0].dts - trk->start_dts Lemma condition
trk->frag_start += trk->start_dts + trk->track_duration - trk->cluster[0].dts; L5444
So trk->entry == 0 && trk->frag_start == trk->track_duration
Note that trk->track_duration may be updated for the tracks that have "trk->entry > 0" (mov_write_moov_tag will
update track_duration of "tmcd" track, but it must have 1 entry). But in all case, trk->frag_start is also updated
to consider the new value.
Lemma 2: If Condition 1 & 2 is true before "ff_mov_write_packet" invocation, Condition 1 & 2 is still true after it returns.
Proof:
Only the track corresponding to the pkt is updated, and no update to relevant variables if trk->entry > 0 before invocation.
So we only need to prove "trk->frag_start == trk->cluster[0].dts - trk->start_dts" after trk->entry increase from 0 to 1.
Case 1: trk->start_dts == AV_NOPTS_VALUE
Case 1.1: trk->frag_discont && use_editlist
trk->cluster[0].dts = pkt->dts at L5741
trk->frag_start = pkt->pts at L5785
trk->start_dts = pkt->dts - pkt->pts at L5786
So trk->frag_start == trk->cluster[0].dts - trk->start_dts
Case 1.2: trk->frag_discont && !use_editlist
trk->cluster[0].dts = pkt->dts at L5741
trk->frag_start = pkt->dts at L5790
trk->start_dts = 0 at L5791
So trk->frag_start == trk->cluster[0].dts - trk->start_dts
Case 1.3: !trk->frag_discont
trk->cluster[0].dts = pkt->dts at L5741
trk->frag_start = 0 init
trk->start_dts = pkt->dts at L5779
So trk->frag_start == trk->cluster[0].dts - trk->start_dts
Case 2: trk->start_dts != AV_NOPTS_VALUE
Case 2.1: trk->frag_discont
trk->cluster[0].dts = pkt->dts at L5741
trk->frag_start = pkt->dts - trk->start_dts at L5763
So trk->frag_start == trk->cluster[0].dts - trk->start_dts
Case 2.2: !trk->frag_discont
trk->cluster[0].dts = trk->start_dts + trk->track_duration at L5749
trk->track_duration == trk->frag_start Lemma condition
So trk->frag_start == trk->cluster[0].dts - trk->start_dts
Lemma 3: Condition 1 & 2 is true in all case before and after "ff_mov_write_packet" invocation, before flush and after
"mov_flush_fragment" returns.
Proof: All updates to relevant variable happen either in "ff_mov_write_packet", or during flush. And Condition 1 & 2
is true initially. So with lemma 1 & 2, we can prove this use induction.
Noticed that all read of "frag_start" only happen in "trk->entry > 0" branch. Now we need to prove Condition 2 is true
before each read.
Because no update to variables relevant to Condition 2 between "before flush" and "mov_write_moof_tag" invocation, we
can conclude Condition 2 is true before every invocation of "mov_write_moof_tag". No behaviour change in
"mov_write_moof_tag" is proved.
In "mov_write_trailer", No update to relevant variables after the last flush and before the invocation of
"mov_write_sidx_tag". So no behaviour change to "mov_write_trailer" is proved.
Q.E.D.
Signed-off-by: Hu Weiwen <sehuww@mail.scut.edu.cn>
Signed-off-by: Martin Storsjö <martin@martin.st>
track->mdat_buf can be not NULL while the track is still empty if the
last packet write failed.
Signed-off-by: Hu Weiwen <sehuww@mail.scut.edu.cn>
Signed-off-by: Martin Storsjö <martin@martin.st>
Unlike libx264, libx265 does not have a separate "unspecified"/"auto"
default for color range, so we do always have to specify it.
Thus, we are required to handle the RGB case on the libavcodec
side to enable the correct value to be written out in in case
of RGB content with unspecified color range being received.
In other words:
1. If the user has set color range specifically, follow that.
2. If the user has not set color range specifically, set full
range by default in case of RGB and YUVJ pixel formats.
By default the x264 full range flag is set to -1. By not setting
it to something else, we can let libx264 handle the RGB case.
Additionally, change the preference order to user-specified range
first, and then any fall-back logic left for the YUVJ pix_fmts.
Fixes the capture part of #9374
It will be useful in the future when more flags are added.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These fields are mutually exclusive, so putting them in a union
is possible and makes AVFilterPad smaller.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
av_frame_copy_props() already copies pts.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In particular, document that av_opt_copy() always disentangles
allocated options even on error; this guarantee is needed to e.g.
properly free duplicated thread contexts in libavcodec on error.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Currently user may use '-init_hw_device type=name' to initialize a hw
device, however the key parameter is ignored when use '-init_hw_device
type=name,key=value'. After applying this patch, user may set key
parameter if needed.
Reviewed-by: Soft Works <softworkz@hotmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The last init_opaque callback has been removed in commit
07ffdedf784e86b88074d8d3e08e55752869562a; the opaque argument has been
always NULL since 0acf7e268b.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The code for inserting inpads can't be reached by ff_vsrc_openclsrc
(unsurprising given that it is a source filter), so it didn't get
the flag.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also adapt some FATE tests to already cover this.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
AVFrame.metadata is always owned by its AVFrame, it is not shared
in the first place, so one does not need to make the frame writable
to modify it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The current way of doing it involves writing the ctx parameter twice.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The current code reads the wrong number of bits for `fg_model_id`, which
causes all of the values downstream of this to contain corrupt values.
Fixes: corrupt SEI values
Fixes: 4ff73add5d
Signed-off-by: Niklas Haas <git@haasn.dev>
Certain mov/mp4 files have parameter sets out of band, and when required for a
sample it may be propagated within the relevant packet's side data.
This fixes parsing said files if the SPS and/or PPS in the side data is
different than the one in extradata.
Signed-off-by: James Almer <jamrial@gmail.com>
Using ff_cbs_read() on the raw buffer will not parse it as extradata,
resulting in parsing errors for example when handling ISOBMFF avcC.
This helper works around that.
Signed-off-by: James Almer <jamrial@gmail.com>
Nicolas George
Paul B Mahol
Christopher Degawa
Steven Liu
Hu Weiwen
Jan Ekström
Andreas Rheinhardt
Haihao Xiang
Michael Niedermayer
Limin Wang
Niklas Haas
James Almer