[FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
1. organize fragmented information according to the tracks.
2. do NOT skip the last boxes of fragmented info.
ticket #7572
To reproduce #7572, need to revert commit
aa25198f1b925a464bdfa83a98476f08d26c9209 first. That commit works for ticket
7572 luckily. However, #7572 has a deeper reason. Mov demuxer consider that
fragmented index is completed if a ‘sidx’ point to the end of the file. But
there may be other ‘sidx’ for other tracks. If we skip the tail from there, we
will missing the last ‘sidx’ and ‘moof’. Then AV_NOPTS_VALUE occurs.
Signed-off-by: Charles Liu
---
libavformat/isom.h | 10 +-
libavformat/mov.c | 378 +
2 files changed, 185 insertions(+), 203 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 69452cae8e..eea8fa4e8f 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -125,7 +125,7 @@ typedef struct MOVEncryptionIndex {
} MOVEncryptionIndex;
typedef struct MOVFragmentStreamInfo {
-int id;
+unsigned stsd_id;
int64_t sidx_pts;
int64_t first_tfra_pts;
int64_t tfdt_dts;
@@ -136,14 +136,13 @@ typedef struct MOVFragmentStreamInfo {
typedef struct MOVFragmentIndexItem {
int64_t moof_offset;
int headers_read;
-int current;
-int nb_stream_info;
-MOVFragmentStreamInfo * stream_info;
+MOVFragmentStreamInfo stream_info;
} MOVFragmentIndexItem;
typedef struct MOVFragmentIndex {
int allocated_size;
int complete;
+int id; // track id
int current;
int nb_items;
MOVFragmentIndexItem * item;
@@ -274,7 +273,8 @@ typedef struct MOVContext {
int moov_retry;
int use_mfra_for;
int has_looked_for_mfra;
-MOVFragmentIndex frag_index;
+unsigned nb_frag_indices;
+MOVFragmentIndex *frag_indices;
int atom_depth;
unsigned int aax_mode; ///< 'aax' file has been detected
uint8_t file_key[20];
diff --git a/libavformat/mov.c b/libavformat/mov.c
index a7d444b0ee..b150710a40 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1153,59 +1153,29 @@ static int mov_read_moov(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
return 0; /* now go for mdat */
}
-static MOVFragmentStreamInfo * get_frag_stream_info(
-MOVFragmentIndex *frag_index,
-int index,
-int id)
+static MOVFragmentIndex *mov_find_frag_index(MOVFragmentIndex *frag_indices,
int nb_frag_indices, int track_id)
{
-int i;
-MOVFragmentIndexItem * item;
+unsigned i;
+MOVFragmentIndex *frag_index = NULL;
-if (index < 0 || index >= frag_index->nb_items)
-return NULL;
-item = _index->item[index];
-for (i = 0; i < item->nb_stream_info; i++)
-if (item->stream_info[i].id == id)
-return >stream_info[i];
+for (i = 0; i < nb_frag_indices; i++)
+if (frag_indices[i].id == track_id)
+frag_index = _indices[i];
-// This shouldn't happen
-return NULL;
+return frag_index;
}
-static void set_frag_stream(MOVFragmentIndex *frag_index, int id)
+static MOVFragmentStreamInfo *get_current_frag_stream_info(MOVContext *c, int
id)
{
-int i;
-MOVFragmentIndexItem * item;
+MOVFragmentIndex *frag_index = NULL;
-if (frag_index->current < 0 ||
-frag_index->current >= frag_index->nb_items)
-return;
-
-item = _index->item[frag_index->current];
-for (i = 0; i < item->nb_stream_info; i++)
-if (item->stream_info[i].id == id) {
-item->current = i;
-return;
-}
-
-// id not found. This shouldn't happen.
-item->current = -1;
-}
-
-static MOVFragmentStreamInfo * get_current_frag_stream_info(
-MOVFragmentIndex *frag_index)
-{
-MOVFragmentIndexItem *item;
-if (frag_index->current < 0 ||
+frag_index = mov_find_frag_index(c->frag_indices, c->nb_frag_indices, id);
+if (!frag_index ||
+frag_index->current < 0 ||
frag_index->current >= frag_index->nb_items)
return NULL;
-item = _index->item[frag_index->current];
-if (item->current >= 0 && item->current < item->nb_stream_info)
-return >stream_info[item->current];
-
-// This shouldn't happen
-return NULL;
+return _index->item[frag_index->current].stream_info;
}
static int search_frag_moof_offset(MOVFragmentIndex *frag_index, int64_t
offset)
@@ -1232,9 +1202,9 @@ static int search_frag_moof_offset(MOVFragmentIndex
*frag_index, int64_t offset)
return b;
}
-static int64_t get_stream_info_time(MOVFragmentStreamInfo * frag_stream_info)
-{
-av_assert0(frag_stream_info);
+static int64_t get_frag_time(MOVFragmentIndex *frag_index,
+ int index, int track_id) {
+MOVFragmentStreamInfo *frag_stream_info =
_index->item[index].stream_info;
if (frag_stream_info->sidx_pts != AV_NOPTS_VALUE)
return frag_stream_info->sidx_pts;
if (frag_stream_info->first_tfra_pts != AV_NOPTS_VALUE)
@@ -1242,31 +1212,9 @@ static int64_t
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
2019-03-06 8:46 GMT+01:00, C.H.Liu : > Yes. Patch aa25198f1b925a464bdfa83a98476f08d26c9209 works to ticket 7572 > luckily. To reproduce #7572, need to revert this patch first. > As we talked, #7572 has a deeper reason. > Mov demuxer consider that > fragmented index is completed if a ‘sidx’ point to the end of the file. But > there may be other ‘sidx’ for other tracks. If we skip the tail from there, > we will missing the last ‘sidx’ and ‘moof’. Then AV_NOPTS_VALUE occurs. Please explain this in the commit message and please do not top-post here. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
Yes. Patch aa25198f1b925a464bdfa83a98476f08d26c9209 works to ticket 7572 luckily. To reproduce #7572, need to revert this patch first. As we talked, #7572 has a deeper reason. Mov demuxer consider that fragmented index is completed if a ‘sidx’ point to the end of the file. But there may be other ‘sidx’ for other tracks. If we skip the tail from there, we will missing the last ‘sidx’ and ‘moof’. Then AV_NOPTS_VALUE occurs. On Wed, Mar 6, 2019 at 2:35 AM Anthony Recascino wrote: > the bug that caused the hang is absolutely still present, the fix that was > pushed was only fixing the surface level issue of the hang. > > > > On Mar 5, 2019, at 11:28 AM, Carl Eugen Hoyos > wrote: > > > > 2019-03-05 17:02 GMT+01:00, Charles Liu : > >> 1. organize fragmented information according to the tracks. > >> 2. do NOT skip the last boxes of fragmented info. > > > >> ticket #7572 > > > > Assuming the ticket is not reproducible for you with current > > FFmpeg git head (it wasn't for me two weeks ago), please > > reword this so it is clear you saw an issue looking at this > > ticket (and its fix) but that this commit does not fix a bug > > that is still reproducible with the files and command line(s) > > provided there. > > > > Or do I misunderstand? > > > > Carl Eugen > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
the bug that caused the hang is absolutely still present, the fix that was pushed was only fixing the surface level issue of the hang. > On Mar 5, 2019, at 11:28 AM, Carl Eugen Hoyos wrote: > > 2019-03-05 17:02 GMT+01:00, Charles Liu : >> 1. organize fragmented information according to the tracks. >> 2. do NOT skip the last boxes of fragmented info. > >> ticket #7572 > > Assuming the ticket is not reproducible for you with current > FFmpeg git head (it wasn't for me two weeks ago), please > reword this so it is clear you saw an issue looking at this > ticket (and its fix) but that this commit does not fix a bug > that is still reproducible with the files and command line(s) > provided there. > > Or do I misunderstand? > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
2019-03-05 17:02 GMT+01:00, Charles Liu : > 1. organize fragmented information according to the tracks. > 2. do NOT skip the last boxes of fragmented info. > ticket #7572 Assuming the ticket is not reproducible for you with current FFmpeg git head (it wasn't for me two weeks ago), please reword this so it is clear you saw an issue looking at this ticket (and its fix) but that this commit does not fix a bug that is still reproducible with the files and command line(s) provided there. Or do I misunderstand? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
Thanks for your reply.
If a track id of the test clip does not appear in its ‘moov’, the do/while
loop cannot exit indeed.
The purpose of this patch is to solve AV_NOPTS_VALUE in the fragment info
structure. Because the original structures is oriented to ‘moof’ boxes in
file. I tried to organize fragment info according to media tracks.
Since the fragment structures has been changed, it fixes two other issues.
One is #7572, which missed the last ‘sidx’ and ‘moof’.
The other is “mov->fragment.stsd_id == 1” in function cenc_filter(). Mov
muxer read all ‘moof’ while reading header. So the current fragment points
to the last ‘moof’. When we read packets/samples from the beginning, the
sample (belongs to the first ‘moof’) and the current fragment info do not
match.
I don’t mind waiting for other options. And we already have a quick fix
aa25198f1b925a464bdfa83a98476f. Though, I will still update the patch to
resolve the endless loop problem.
BTW, I have’t modified other commit messages. The frag index variable is
changed in isom.h.
Thanks again, and sorry for late response.
Regards,
Charles.
On Wed, Feb 27, 2019 at 9:39 PM Michael Niedermayer
wrote:
> On Mon, Feb 25, 2019 at 07:07:27PM +0800, C.H.Liu wrote:
> > Would you mind share your input file? I still can’t reproduce the OOM.
>
> i belive i cannot share this sample, but the patch really needs to be
> fully reviewed not just one bug that was found by chance fixed otherwise
> we might be missing other bugs ...
>
>
> >
> >
> > I have tried several types of mp4.
> >
> > I also tried to create a file like yours. According to the snapshot,
> seems
> > it has no ‘sidx’ box and enable ‘use_mfra_for’.
> >
> > Massif didn’t report update_frag_index() function. I didn’t see an extra
> > heap as big as here, either.
>
> looking at the sample that triggers the OOM the do/while loop you add
> to update_frag_index() is entered and never exits while doing allocations
> in it.
>
> also the patch as is is not ok. You for example have a list of unrelated
> changes in the commit message. Each should be in its own patch
> also changes that are functional should be splited from non functional
> changes. For example here:
>
> // If moof_offset already exists in frag_index, return index to it
> -index = search_frag_moof_offset(>frag_index, offset);
> -if (index < c->frag_index.nb_items &&
> -c->frag_index.item[index].moof_offset == offset)
> +index = search_frag_moof_offset(frag_index, offset);
> +if (index < frag_index->nb_items &&
> +frag_index->item[index].moof_offset == offset) {
> +frag_index->current = index;
> return index;
> +}
>
> you change frag_index to a local variable this is non functional and
> should not be in a patch that does a functional change ideally.
> Now sure if a functional change is trivial and clear such things are
> sometimes done together but this patch is not clear, at least its not
> clear to me ...
>
> thanks
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I do not agree with what you have to say, but I'll defend to the death your
> right to say it. -- Voltaire
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
1. organize fragmented information according to the tracks.
2. do NOT skip the last boxes of fragmented info.
ticket #7572
Signed-off-by: Charles Liu
---
libavformat/isom.h | 10 +-
libavformat/mov.c | 378 +
2 files changed, 185 insertions(+), 203 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 69452cae8e..eea8fa4e8f 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -125,7 +125,7 @@ typedef struct MOVEncryptionIndex {
} MOVEncryptionIndex;
typedef struct MOVFragmentStreamInfo {
-int id;
+unsigned stsd_id;
int64_t sidx_pts;
int64_t first_tfra_pts;
int64_t tfdt_dts;
@@ -136,14 +136,13 @@ typedef struct MOVFragmentStreamInfo {
typedef struct MOVFragmentIndexItem {
int64_t moof_offset;
int headers_read;
-int current;
-int nb_stream_info;
-MOVFragmentStreamInfo * stream_info;
+MOVFragmentStreamInfo stream_info;
} MOVFragmentIndexItem;
typedef struct MOVFragmentIndex {
int allocated_size;
int complete;
+int id; // track id
int current;
int nb_items;
MOVFragmentIndexItem * item;
@@ -274,7 +273,8 @@ typedef struct MOVContext {
int moov_retry;
int use_mfra_for;
int has_looked_for_mfra;
-MOVFragmentIndex frag_index;
+unsigned nb_frag_indices;
+MOVFragmentIndex *frag_indices;
int atom_depth;
unsigned int aax_mode; ///< 'aax' file has been detected
uint8_t file_key[20];
diff --git a/libavformat/mov.c b/libavformat/mov.c
index a7d444b0ee..b150710a40 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1153,59 +1153,29 @@ static int mov_read_moov(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
return 0; /* now go for mdat */
}
-static MOVFragmentStreamInfo * get_frag_stream_info(
-MOVFragmentIndex *frag_index,
-int index,
-int id)
+static MOVFragmentIndex *mov_find_frag_index(MOVFragmentIndex *frag_indices,
int nb_frag_indices, int track_id)
{
-int i;
-MOVFragmentIndexItem * item;
+unsigned i;
+MOVFragmentIndex *frag_index = NULL;
-if (index < 0 || index >= frag_index->nb_items)
-return NULL;
-item = _index->item[index];
-for (i = 0; i < item->nb_stream_info; i++)
-if (item->stream_info[i].id == id)
-return >stream_info[i];
+for (i = 0; i < nb_frag_indices; i++)
+if (frag_indices[i].id == track_id)
+frag_index = _indices[i];
-// This shouldn't happen
-return NULL;
+return frag_index;
}
-static void set_frag_stream(MOVFragmentIndex *frag_index, int id)
+static MOVFragmentStreamInfo *get_current_frag_stream_info(MOVContext *c, int
id)
{
-int i;
-MOVFragmentIndexItem * item;
+MOVFragmentIndex *frag_index = NULL;
-if (frag_index->current < 0 ||
-frag_index->current >= frag_index->nb_items)
-return;
-
-item = _index->item[frag_index->current];
-for (i = 0; i < item->nb_stream_info; i++)
-if (item->stream_info[i].id == id) {
-item->current = i;
-return;
-}
-
-// id not found. This shouldn't happen.
-item->current = -1;
-}
-
-static MOVFragmentStreamInfo * get_current_frag_stream_info(
-MOVFragmentIndex *frag_index)
-{
-MOVFragmentIndexItem *item;
-if (frag_index->current < 0 ||
+frag_index = mov_find_frag_index(c->frag_indices, c->nb_frag_indices, id);
+if (!frag_index ||
+frag_index->current < 0 ||
frag_index->current >= frag_index->nb_items)
return NULL;
-item = _index->item[frag_index->current];
-if (item->current >= 0 && item->current < item->nb_stream_info)
-return >stream_info[item->current];
-
-// This shouldn't happen
-return NULL;
+return _index->item[frag_index->current].stream_info;
}
static int search_frag_moof_offset(MOVFragmentIndex *frag_index, int64_t
offset)
@@ -1232,9 +1202,9 @@ static int search_frag_moof_offset(MOVFragmentIndex
*frag_index, int64_t offset)
return b;
}
-static int64_t get_stream_info_time(MOVFragmentStreamInfo * frag_stream_info)
-{
-av_assert0(frag_stream_info);
+static int64_t get_frag_time(MOVFragmentIndex *frag_index,
+ int index, int track_id) {
+MOVFragmentStreamInfo *frag_stream_info =
_index->item[index].stream_info;
if (frag_stream_info->sidx_pts != AV_NOPTS_VALUE)
return frag_stream_info->sidx_pts;
if (frag_stream_info->first_tfra_pts != AV_NOPTS_VALUE)
@@ -1242,31 +1212,9 @@ static int64_t
get_stream_info_time(MOVFragmentStreamInfo * frag_stream_info)
return frag_stream_info->tfdt_dts;
}
-static int64_t get_frag_time(MOVFragmentIndex *frag_index,
- int index, int track_id)
-{
-MOVFragmentStreamInfo * frag_stream_info;
-int64_t timestamp;
-int i;
-
-if (track_id >= 0) {
-frag_stream_info = get_frag_stream_info(frag_index, index, track_id);
-
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
On Mon, Feb 25, 2019 at 07:07:27PM +0800, C.H.Liu wrote:
> Would you mind share your input file? I still can’t reproduce the OOM.
i belive i cannot share this sample, but the patch really needs to be
fully reviewed not just one bug that was found by chance fixed otherwise
we might be missing other bugs ...
>
>
> I have tried several types of mp4.
>
> I also tried to create a file like yours. According to the snapshot, seems
> it has no ‘sidx’ box and enable ‘use_mfra_for’.
>
> Massif didn’t report update_frag_index() function. I didn’t see an extra
> heap as big as here, either.
looking at the sample that triggers the OOM the do/while loop you add
to update_frag_index() is entered and never exits while doing allocations
in it.
also the patch as is is not ok. You for example have a list of unrelated
changes in the commit message. Each should be in its own patch
also changes that are functional should be splited from non functional
changes. For example here:
// If moof_offset already exists in frag_index, return index to it
-index = search_frag_moof_offset(>frag_index, offset);
-if (index < c->frag_index.nb_items &&
-c->frag_index.item[index].moof_offset == offset)
+index = search_frag_moof_offset(frag_index, offset);
+if (index < frag_index->nb_items &&
+frag_index->item[index].moof_offset == offset) {
+frag_index->current = index;
return index;
+}
you change frag_index to a local variable this is non functional and
should not be in a patch that does a functional change ideally.
Now sure if a functional change is trivial and clear such things are
sometimes done together but this patch is not clear, at least its not
clear to me ...
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
Attach one of my massif outputs. The max memory usage is approximately 22.05MB. And the *extra *heap is not too big. The peak snapshot is the 7th. The H.264 decoder is responsible for 86.11% of the memory usage. The update_frag_index is responsible for 78,264 bytes. And the relevant code is at line 1276 instead of line 1257. In my opinion, this is usual. It create fragment items for every ‘moof’. Thanks and Regards, Charles On Mon, Feb 25, 2019 at 7:07 PM C.H.Liu wrote: > Would you mind share your input file? I still can’t reproduce the OOM. > > > I have tried several types of mp4. > > I also tried to create a file like yours. According to the snapshot, seems > it has no ‘sidx’ box and enable ‘use_mfra_for’. > > Massif didn’t report update_frag_index() function. I didn’t see an extra > heap as big as here, either. > > > The code around line 1257 creates an array of fragment indices for each > track. It should be very small. Interesting. > > Sorry for disturbing. > > > Thanks and Regards, > > Charles > > Michael Niedermayer 于2019年2月23日周六 下午5:35写道： > >> On Sat, Feb 23, 2019 at 03:22:08PM +0800, C.H.Liu wrote: >> > I can’t reproduce the OOM. Is it possible the problem relate to a >> specific >> > clip? >> > >> > Here is my test steps: >> > 1. To ensure that it’s not affected by caches, delete all except the >> .git >> > dir in my code dir. Then checkout again. >> > 2. To ensure that the latest test clips are used. make fate-rsync >> > SAMPLES=fate-suite/ >> > 3. To ensure that OS environment is clean, run test in docker. >> > Below is one of my test logs: >> >> heres some massif output that should show where the exessive allocation >> happens: >> (note the box has 14gb free and the input file is less than 4kb size) >> >> snapshot=70 >> #--- >> time=1856698079 >> mem_heap_B=8487679 >> mem_heap_extra_B=522580313 >> mem_stacks_B=0 >> heap_tree=peak >> n2: 8487679 (heap allocation functions) malloc/new/new[], --alloc-fns, >> etc. >> n2: 8298639 0x12AAF2B: av_malloc (mem.c:87) >> n1: 8294364 0x12AAF59: av_malloc (mem.c:126) >>n1: 8294364 0x12AB24B: av_mallocz (mem.c:238) >> n1: 8294364 0x12AB122: av_mallocz_array (mem.c:195) >> n1: 8294364 0x743749: update_frag_index (mov.c:1257) >> n1: 8294364 0x756174: read_tfra (mov.c:7293) >>n1: 8294364 0x7563F0: mov_read_mfra (mov.c:7344) >> n1: 8294364 0x743B01: mov_read_moof (mov.c:1338) >> n1: 8294364 0x754A0C: mov_read_default (mov.c:6841) >> n1: 8294364 0x756596: mov_read_header (mov.c:7385) >>n1: 8294364 0x8254BB: avformat_open_input (utils.c:631) >> n1: 8294364 0x415CE6: open_input_file (ffmpeg_opt.c:1104) >> n1: 8294364 0x41F666: open_files (ffmpeg_opt.c:3273) >> n1: 8294364 0x41F7F8: ffmpeg_parse_options >> (ffmpeg_opt.c:3313) >>n0: 8294364 0x43DFC6: main (ffmpeg.c:4869) >> n0: 4275 in 7 places, all below massif's threshold (01.00%) >> n0: 189040 in 8 places, all below massif's threshold (01.00%) >> >> >> [...] >> -- >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB >> >> Its not that you shouldnt use gotos but rather that you should write >> readable code and code with gotos often but not always is less readable >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > massif.out.63483.tar.bz2 Description: BZip2 compressed data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
Would you mind share your input file? I still can’t reproduce the OOM. I have tried several types of mp4. I also tried to create a file like yours. According to the snapshot, seems it has no ‘sidx’ box and enable ‘use_mfra_for’. Massif didn’t report update_frag_index() function. I didn’t see an extra heap as big as here, either. The code around line 1257 creates an array of fragment indices for each track. It should be very small. Interesting. Sorry for disturbing. Thanks and Regards, Charles Michael Niedermayer 于2019年2月23日周六 下午5:35写道： > On Sat, Feb 23, 2019 at 03:22:08PM +0800, C.H.Liu wrote: > > I can’t reproduce the OOM. Is it possible the problem relate to a > specific > > clip? > > > > Here is my test steps: > > 1. To ensure that it’s not affected by caches, delete all except the .git > > dir in my code dir. Then checkout again. > > 2. To ensure that the latest test clips are used. make fate-rsync > > SAMPLES=fate-suite/ > > 3. To ensure that OS environment is clean, run test in docker. > > Below is one of my test logs: > > heres some massif output that should show where the exessive allocation > happens: > (note the box has 14gb free and the input file is less than 4kb size) > > snapshot=70 > #--- > time=1856698079 > mem_heap_B=8487679 > mem_heap_extra_B=522580313 > mem_stacks_B=0 > heap_tree=peak > n2: 8487679 (heap allocation functions) malloc/new/new[], --alloc-fns, etc. > n2: 8298639 0x12AAF2B: av_malloc (mem.c:87) > n1: 8294364 0x12AAF59: av_malloc (mem.c:126) >n1: 8294364 0x12AB24B: av_mallocz (mem.c:238) > n1: 8294364 0x12AB122: av_mallocz_array (mem.c:195) > n1: 8294364 0x743749: update_frag_index (mov.c:1257) > n1: 8294364 0x756174: read_tfra (mov.c:7293) >n1: 8294364 0x7563F0: mov_read_mfra (mov.c:7344) > n1: 8294364 0x743B01: mov_read_moof (mov.c:1338) > n1: 8294364 0x754A0C: mov_read_default (mov.c:6841) > n1: 8294364 0x756596: mov_read_header (mov.c:7385) >n1: 8294364 0x8254BB: avformat_open_input (utils.c:631) > n1: 8294364 0x415CE6: open_input_file (ffmpeg_opt.c:1104) > n1: 8294364 0x41F666: open_files (ffmpeg_opt.c:3273) > n1: 8294364 0x41F7F8: ffmpeg_parse_options > (ffmpeg_opt.c:3313) >n0: 8294364 0x43DFC6: main (ffmpeg.c:4869) > n0: 4275 in 7 places, all below massif's threshold (01.00%) > n0: 189040 in 8 places, all below massif's threshold (01.00%) > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Its not that you shouldnt use gotos but rather that you should write > readable code and code with gotos often but not always is less readable > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
On Sat, Feb 23, 2019 at 03:22:08PM +0800, C.H.Liu wrote: > I can’t reproduce the OOM. Is it possible the problem relate to a specific > clip? > > Here is my test steps: > 1. To ensure that it’s not affected by caches, delete all except the .git > dir in my code dir. Then checkout again. > 2. To ensure that the latest test clips are used. make fate-rsync > SAMPLES=fate-suite/ > 3. To ensure that OS environment is clean, run test in docker. > Below is one of my test logs: heres some massif output that should show where the exessive allocation happens: (note the box has 14gb free and the input file is less than 4kb size) snapshot=70 #--- time=1856698079 mem_heap_B=8487679 mem_heap_extra_B=522580313 mem_stacks_B=0 heap_tree=peak n2: 8487679 (heap allocation functions) malloc/new/new[], --alloc-fns, etc. n2: 8298639 0x12AAF2B: av_malloc (mem.c:87) n1: 8294364 0x12AAF59: av_malloc (mem.c:126) n1: 8294364 0x12AB24B: av_mallocz (mem.c:238) n1: 8294364 0x12AB122: av_mallocz_array (mem.c:195) n1: 8294364 0x743749: update_frag_index (mov.c:1257) n1: 8294364 0x756174: read_tfra (mov.c:7293) n1: 8294364 0x7563F0: mov_read_mfra (mov.c:7344) n1: 8294364 0x743B01: mov_read_moof (mov.c:1338) n1: 8294364 0x754A0C: mov_read_default (mov.c:6841) n1: 8294364 0x756596: mov_read_header (mov.c:7385) n1: 8294364 0x8254BB: avformat_open_input (utils.c:631) n1: 8294364 0x415CE6: open_input_file (ffmpeg_opt.c:1104) n1: 8294364 0x41F666: open_files (ffmpeg_opt.c:3273) n1: 8294364 0x41F7F8: ffmpeg_parse_options (ffmpeg_opt.c:3313) n0: 8294364 0x43DFC6: main (ffmpeg.c:4869) n0: 4275 in 7 places, all below massif's threshold (01.00%) n0: 189040 in 8 places, all below massif's threshold (01.00%) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
I can’t reproduce the OOM. Is it possible the problem relate to a specific clip? Here is my test steps: 1. To ensure that it’s not affected by caches, delete all except the .git dir in my code dir. Then checkout again. 2. To ensure that the latest test clips are used. make fate-rsync SAMPLES=fate-suite/ 3. To ensure that OS environment is clean, run test in docker. Below is one of my test logs: > /ffmpeg_src# valgrind --leak-check=full ./ffmpeg -i issue/dash.mp4 -map 0 > -f null - > > *==8552== Memcheck, a memory error detector* > *==8552== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.* > *==8552== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright > info* > *==8552== Command: ./ffmpeg -i issue/dash.mp4 -map 0 -f null -* > *==8552== * > *ffmpeg version 4.1.git Copyright (c) 2000-2019 the FFmpeg developers* > * built with gcc 7 (Ubuntu 7.3.0-27ubuntu1~18.04)* > * configuration: --samples=fate-suite/ --disable-doc --fatal-warnings > --valgrind=VALGRIND* > * libavutil 56. 26.100 / 56. 26.100* > * libavcodec 58. 47.102 / 58. 47.102* > * libavformat58. 26.101 / 58. 26.101* > * libavdevice58. 6.101 / 58. 6.101* > * libavfilter 7. 48.100 / 7. 48.100* > * libswscale 5. 4.100 / 5. 4.100* > * libswresample 3. 4.100 / 3. 4.100* > *Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'issue/dash.mp4':* > * Metadata:* > *major_brand : iso5* > *minor_version : 512* > *compatible_brands: iso6mp41* > *encoder : Lavf58.20.100* > * Duration: 00:00:57.76, start: 0.00, bitrate: 5193 kb/s* > *Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, > smpte170m/bt709/bt709), 1280x720, 5125 kb/s, 25 fps, 25 tbr, 250k tbn, 50 > tbc (default)* > *Metadata:* > * handler_name: VideoHandler* > *Stream #0:1(und): Audio: aac (HE-AAC) (mp4a / 0x6134706D), 44100 Hz, > stereo, fltp, 79 kb/s (default)* > *Metadata:* > * handler_name: SoundHandler* > *Stream mapping:* > * Stream #0:0 -> #0:0 (h264 (native) -> wrapped_avframe (native))* > * Stream #0:1 -> #0:1 (aac (native) -> pcm_s16le (native))* > *Press [q] to stop, [?] for help* > *Output #0, null, to 'pipe:':ze=N/A time=-577014:32:22.77 bitrate=N/A > speed=N/A* > * Metadata:* > *major_brand : iso5* > *minor_version : 512* > *compatible_brands: iso6mp41* > *encoder : Lavf58.26.101* > *Stream #0:0(und): Video: wrapped_avframe, yuv420p(progressive), > 1280x720, q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc (default)* > *Metadata:* > * handler_name: VideoHandler* > * encoder : Lavc58.47.102 wrapped_avframe* > *Stream #0:1(und): Audio: pcm_s16le, 44100 Hz, stereo, s16, 1411 kb/s > (default)* > *Metadata:* > * handler_name: SoundHandler* > * encoder : Lavc58.47.102 pcm_s16le* > *frame= 1438 fps=5.0 q=-0.0 Lsize=N/A time=00:00:57.68 bitrate=N/A > speed=0.202x* > *video:753kB audio:9904kB subtitle:0kB other streams:0kB global > headers:0kB muxing overhead: unknown* > *==8552== * > *==8552== HEAP SUMMARY:* > *==8552== in use at exit: 0 bytes in 0 blocks* > *==8552== total heap usage: 207,112 allocs, 207,112 frees, 121,288,827 > bytes allocated* > *==8552== * > *==8552== All heap blocks were freed -- no leaks are possible* > *==8552== * > *==8552== For counts of detected and suppressed errors, rerun with: > -v**==8552== > ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)* BTW, below is my dockefile. It show that the installed dependences. And how to configure and test. *FROM ubuntu:18.04* *RUN apt-get update -qq && apt-get dist-upgrade -qy* *RUN apt-get -qy install autoconf automake build-essential cmake libass-dev libfreetype6-dev libtool libvorbis-dev pkg-config texinfo zlib1g-dev \* * libnuma-dev* *RUN apt-get -qy install yasm libx264-dev libx265-dev libfdk-aac-dev* *RUN apt-get -qy install valgrind* *COPY . /ffmpeg_src/* *WORKDIR /ffmpeg_src* *RUN make distclean* *RUN ./configure --samples=fate-suite/ --disable-doc --fatal-warnings --valgrind=VALGRIND* *RUN make -j3 && make fate* *CMD ["/bin/bash"]* Michael Niedermayer 于2019年2月23日周六 上午8:25写道： > On Fri, Feb 22, 2019 at 06:20:40PM +0800, Charles Liu wrote: > > 1. organize fragmented information according to the tracks. > > 2. do NOT skip the last boxes of fragmented info. > > > > ticket #7572 > > > > Signed-off-by: Charles Liu > > --- > > libavformat/isom.h | 10 +- > > libavformat/mov.c | 374 + > > 2 files changed, 181 insertions(+), 203 deletions(-) > > still hitting out of memory and being killed by the kernel > the other issue seems to be fixed though > > thx > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The educated differ from the uneducated as much as the living from the > dead. -- Aristotle > ___ > ffmpeg-devel mailing list >
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
On Fri, Feb 22, 2019 at 06:20:40PM +0800, Charles Liu wrote: > 1. organize fragmented information according to the tracks. > 2. do NOT skip the last boxes of fragmented info. > > ticket #7572 > > Signed-off-by: Charles Liu > --- > libavformat/isom.h | 10 +- > libavformat/mov.c | 374 + > 2 files changed, 181 insertions(+), 203 deletions(-) still hitting out of memory and being killed by the kernel the other issue seems to be fixed though thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
I have updated a new patch that has passed valgrind as follows: *$ ./configure --samples=fate-suite/ --disable-doc --fatal-warnings --valgrind=VALGRIND* *$ make -j4 && make fate-mov* But I never encountered a ‘stream 0, timescale not set’ log in here. Please let me know if you have any questions. Sorry for the previous trouble. Thanks and Regards, Charles Liu Michael Niedermayer 于2019年2月22日周五 上午9:40写道： > On Wed, Feb 20, 2019 at 11:54:56PM +0800, Charles Liu wrote: > > 1. organize fragmented information according to the tracks. > > 2. do NOT skip the last boxes of fragmented info. > > > > ticket #7572 > > > > Signed-off-by: Charles Liu > > --- > > libavformat/isom.h | 10 +- > > libavformat/mov.c | 375 ++--- > > 2 files changed, 185 insertions(+), 200 deletions(-) > > this causes OOM and crashes > > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x3796f00] stream 0, timescale not set > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x3796f00] stream 1, timescale not set > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x3796f00] error reading header > *** Error in `./ffmpeg': double free or corruption (fasttop): > 0x0379b100 *** > Aborted (core dumped) > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > No snowflake in an avalanche ever feels responsible. -- Voltaire > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
1. organize fragmented information according to the tracks.
2. do NOT skip the last boxes of fragmented info.
ticket #7572
Signed-off-by: Charles Liu
---
libavformat/isom.h | 10 +-
libavformat/mov.c | 374 +
2 files changed, 181 insertions(+), 203 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 69452cae8e..eea8fa4e8f 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -125,7 +125,7 @@ typedef struct MOVEncryptionIndex {
} MOVEncryptionIndex;
typedef struct MOVFragmentStreamInfo {
-int id;
+unsigned stsd_id;
int64_t sidx_pts;
int64_t first_tfra_pts;
int64_t tfdt_dts;
@@ -136,14 +136,13 @@ typedef struct MOVFragmentStreamInfo {
typedef struct MOVFragmentIndexItem {
int64_t moof_offset;
int headers_read;
-int current;
-int nb_stream_info;
-MOVFragmentStreamInfo * stream_info;
+MOVFragmentStreamInfo stream_info;
} MOVFragmentIndexItem;
typedef struct MOVFragmentIndex {
int allocated_size;
int complete;
+int id; // track id
int current;
int nb_items;
MOVFragmentIndexItem * item;
@@ -274,7 +273,8 @@ typedef struct MOVContext {
int moov_retry;
int use_mfra_for;
int has_looked_for_mfra;
-MOVFragmentIndex frag_index;
+unsigned nb_frag_indices;
+MOVFragmentIndex *frag_indices;
int atom_depth;
unsigned int aax_mode; ///< 'aax' file has been detected
uint8_t file_key[20];
diff --git a/libavformat/mov.c b/libavformat/mov.c
index bbd588c705..a16788fd21 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1153,59 +1153,29 @@ static int mov_read_moov(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
return 0; /* now go for mdat */
}
-static MOVFragmentStreamInfo * get_frag_stream_info(
-MOVFragmentIndex *frag_index,
-int index,
-int id)
+static MOVFragmentIndex *mov_find_frag_index(MOVFragmentIndex *frag_indices,
int nb_frag_indices, int track_id)
{
-int i;
-MOVFragmentIndexItem * item;
+unsigned i;
+MOVFragmentIndex *frag_index = NULL;
-if (index < 0 || index >= frag_index->nb_items)
-return NULL;
-item = _index->item[index];
-for (i = 0; i < item->nb_stream_info; i++)
-if (item->stream_info[i].id == id)
-return >stream_info[i];
+for (i = 0; i < nb_frag_indices; i++)
+if (frag_indices[i].id == track_id)
+frag_index = _indices[i];
-// This shouldn't happen
-return NULL;
+return frag_index;
}
-static void set_frag_stream(MOVFragmentIndex *frag_index, int id)
+static MOVFragmentStreamInfo *get_current_frag_stream_info(MOVContext *c, int
id)
{
-int i;
-MOVFragmentIndexItem * item;
-
-if (frag_index->current < 0 ||
-frag_index->current >= frag_index->nb_items)
-return;
-
-item = _index->item[frag_index->current];
-for (i = 0; i < item->nb_stream_info; i++)
-if (item->stream_info[i].id == id) {
-item->current = i;
-return;
-}
+MOVFragmentIndex *frag_index = NULL;
-// id not found. This shouldn't happen.
-item->current = -1;
-}
-
-static MOVFragmentStreamInfo * get_current_frag_stream_info(
-MOVFragmentIndex *frag_index)
-{
-MOVFragmentIndexItem *item;
-if (frag_index->current < 0 ||
+frag_index = mov_find_frag_index(c->frag_indices, c->nb_frag_indices, id);
+if (!frag_index ||
+frag_index->current < 0 ||
frag_index->current >= frag_index->nb_items)
return NULL;
-item = _index->item[frag_index->current];
-if (item->current >= 0 && item->current < item->nb_stream_info)
-return >stream_info[item->current];
-
-// This shouldn't happen
-return NULL;
+return _index->item[frag_index->current].stream_info;
}
static int search_frag_moof_offset(MOVFragmentIndex *frag_index, int64_t
offset)
@@ -1232,9 +1202,9 @@ static int search_frag_moof_offset(MOVFragmentIndex
*frag_index, int64_t offset)
return b;
}
-static int64_t get_stream_info_time(MOVFragmentStreamInfo * frag_stream_info)
-{
-av_assert0(frag_stream_info);
+static int64_t get_frag_time(MOVFragmentIndex *frag_index,
+ int index, int track_id) {
+MOVFragmentStreamInfo *frag_stream_info =
_index->item[index].stream_info;
if (frag_stream_info->sidx_pts != AV_NOPTS_VALUE)
return frag_stream_info->sidx_pts;
if (frag_stream_info->first_tfra_pts != AV_NOPTS_VALUE)
@@ -1242,31 +1212,9 @@ static int64_t
get_stream_info_time(MOVFragmentStreamInfo * frag_stream_info)
return frag_stream_info->tfdt_dts;
}
-static int64_t get_frag_time(MOVFragmentIndex *frag_index,
- int index, int track_id)
-{
-MOVFragmentStreamInfo * frag_stream_info;
-int64_t timestamp;
-int i;
-
-if (track_id >= 0) {
-frag_stream_info = get_frag_stream_info(frag_index, index, track_id);
-
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
On Wed, Feb 20, 2019 at 11:54:56PM +0800, Charles Liu wrote: > 1. organize fragmented information according to the tracks. > 2. do NOT skip the last boxes of fragmented info. > > ticket #7572 > > Signed-off-by: Charles Liu > --- > libavformat/isom.h | 10 +- > libavformat/mov.c | 375 ++--- > 2 files changed, 185 insertions(+), 200 deletions(-) this causes OOM and crashes [mov,mp4,m4a,3gp,3g2,mj2 @ 0x3796f00] stream 0, timescale not set [mov,mp4,m4a,3gp,3g2,mj2 @ 0x3796f00] stream 1, timescale not set [mov,mp4,m4a,3gp,3g2,mj2 @ 0x3796f00] error reading header *** Error in `./ffmpeg': double free or corruption (fasttop): 0x0379b100 *** Aborted (core dumped) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
There was a quick solution at aa25198f1b925a464bdfa83a98476f08d26c9209, which luckily works for #7572. To reproduce issue, you can switch to the commit just before it. As we discussed, #7572 has a deeper reason. We missed the last ‘sidx’ and ‘moof’ boxes. This patch try to fix AV_NOPTS_VALUE in fragmented info structure. It may be caused by missing boxes. Or the fragmented structures are not suitable for separate audio and video ‘moof’. Thanks and Regards, Charles Liu Carl Eugen Hoyos 于2019年2月21日周四 上午7:33写道： > 2019-02-20 16:54 GMT+01:00, Charles Liu : > > 1. organize fragmented information according to the tracks. > > 2. do NOT skip the last boxes of fragmented info. > > > > ticket #7572 > > How can I reproduce the hang with current FFmpeg git head? > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
2019-02-20 16:54 GMT+01:00, Charles Liu : > 1. organize fragmented information according to the tracks. > 2. do NOT skip the last boxes of fragmented info. > > ticket #7572 How can I reproduce the hang with current FFmpeg git head? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
1. organize fragmented information according to the tracks.
2. do NOT skip the last boxes of fragmented info.
ticket #7572
Signed-off-by: Charles Liu
---
libavformat/isom.h | 10 +-
libavformat/mov.c | 375 ++---
2 files changed, 185 insertions(+), 200 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 69452cae8e..2b06f5fa58 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -125,7 +125,7 @@ typedef struct MOVEncryptionIndex {
} MOVEncryptionIndex;
typedef struct MOVFragmentStreamInfo {
-int id;
+unsigned stsd_id;
int64_t sidx_pts;
int64_t first_tfra_pts;
int64_t tfdt_dts;
@@ -136,14 +136,13 @@ typedef struct MOVFragmentStreamInfo {
typedef struct MOVFragmentIndexItem {
int64_t moof_offset;
int headers_read;
-int current;
-int nb_stream_info;
-MOVFragmentStreamInfo * stream_info;
+MOVFragmentStreamInfo stream_info;
} MOVFragmentIndexItem;
typedef struct MOVFragmentIndex {
int allocated_size;
int complete;
+int id; // track id
int current;
int nb_items;
MOVFragmentIndexItem * item;
@@ -274,7 +273,8 @@ typedef struct MOVContext {
int moov_retry;
int use_mfra_for;
int has_looked_for_mfra;
-MOVFragmentIndex frag_index;
+unsigned nb_frag_indices;
+MOVFragmentIndex **frag_indices;
int atom_depth;
unsigned int aax_mode; ///< 'aax' file has been detected
uint8_t file_key[20];
diff --git a/libavformat/mov.c b/libavformat/mov.c
index bbd588c705..cd37d08299 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1153,59 +1153,29 @@ static int mov_read_moov(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
return 0; /* now go for mdat */
}
-static MOVFragmentStreamInfo * get_frag_stream_info(
-MOVFragmentIndex *frag_index,
-int index,
-int id)
+static MOVFragmentIndex *mov_find_frag_index(MOVFragmentIndex **frag_indices,
int nb_frag_indices, int track_id) // name?
{
-int i;
-MOVFragmentIndexItem * item;
+unsigned i;
+MOVFragmentIndex *frag_index = NULL;
-if (index < 0 || index >= frag_index->nb_items)
-return NULL;
-item = _index->item[index];
-for (i = 0; i < item->nb_stream_info; i++)
-if (item->stream_info[i].id == id)
-return >stream_info[i];
+for (i = 0; i < nb_frag_indices; i++)
+if (frag_indices[i]->id == track_id)
+frag_index = frag_indices[i];
-// This shouldn't happen
-return NULL;
+return frag_index;
}
-static void set_frag_stream(MOVFragmentIndex *frag_index, int id)
+static MOVFragmentStreamInfo *get_current_frag_stream_info(MOVContext *c, int
id)
{
-int i;
-MOVFragmentIndexItem * item;
+MOVFragmentIndex *frag_index = NULL;
-if (frag_index->current < 0 ||
-frag_index->current >= frag_index->nb_items)
-return;
-
-item = _index->item[frag_index->current];
-for (i = 0; i < item->nb_stream_info; i++)
-if (item->stream_info[i].id == id) {
-item->current = i;
-return;
-}
-
-// id not found. This shouldn't happen.
-item->current = -1;
-}
-
-static MOVFragmentStreamInfo * get_current_frag_stream_info(
-MOVFragmentIndex *frag_index)
-{
-MOVFragmentIndexItem *item;
-if (frag_index->current < 0 ||
+frag_index = mov_find_frag_index(c->frag_indices, c->nb_frag_indices, id);
+if (!frag_index ||
+frag_index->current < 0 ||
frag_index->current >= frag_index->nb_items)
return NULL;
-item = _index->item[frag_index->current];
-if (item->current >= 0 && item->current < item->nb_stream_info)
-return >stream_info[item->current];
-
-// This shouldn't happen
-return NULL;
+return _index->item[frag_index->current].stream_info;
}
static int search_frag_moof_offset(MOVFragmentIndex *frag_index, int64_t
offset)
@@ -1232,9 +1202,10 @@ static int search_frag_moof_offset(MOVFragmentIndex
*frag_index, int64_t offset)
return b;
}
-static int64_t get_stream_info_time(MOVFragmentStreamInfo * frag_stream_info)
+static int64_t get_frag_time(MOVFragmentIndex *frag_index,
+ int index, int track_id)
{
-av_assert0(frag_stream_info);
+MOVFragmentStreamInfo *frag_stream_info =
_index->item[index].stream_info;
if (frag_stream_info->sidx_pts != AV_NOPTS_VALUE)
return frag_stream_info->sidx_pts;
if (frag_stream_info->first_tfra_pts != AV_NOPTS_VALUE)
@@ -1242,31 +1213,10 @@ static int64_t
get_stream_info_time(MOVFragmentStreamInfo * frag_stream_info)
return frag_stream_info->tfdt_dts;
}
-static int64_t get_frag_time(MOVFragmentIndex *frag_index,
- int index, int track_id)
-{
-MOVFragmentStreamInfo * frag_stream_info;
-int64_t timestamp;
-int i;
-
-if (track_id >= 0) {
-frag_stream_info = get_frag_stream_info(frag_index, index,
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
On Sun, 10 Feb 2019, Carl Eugen Hoyos wrote:
2019-02-10 23:04 GMT+01:00, Marton Balint :
On Sun, 3 Feb 2019, Charles Liu wrote:
Binary searching would hang if the fragment items do NOT have timestamp
for the specified stream.
For example, a fmp4 consists of separated 'moof' boxes for each track, and
separated 'sidx' for each segment, but no 'mfra' box.
Then every fragment item only have the timestamp for one of its tracks.
Signed-off-by: Charles Liu
---
libavformat/mov.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9b9739f788..35cb619e9f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1266,7 +1266,7 @@ static int64_t get_frag_time(MOVFragmentIndex
*frag_index,
static int search_frag_timestamp(MOVFragmentIndex *frag_index,
AVStream *st, int64_t timestamp)
{
-int a, b, m;
+int a, b, m, m0;
int64_t frag_time;
int id = -1;
@@ -1282,15 +1282,18 @@ static int search_frag_timestamp(MOVFragmentIndex
*frag_index,
b = frag_index->nb_items;
while (b - a > 1) {
-m = (a + b) >> 1;
-frag_time = get_frag_time(frag_index, m, id);
-if (frag_time != AV_NOPTS_VALUE) {
-if (frag_time >= timestamp)
-b = m;
-if (frag_time <= timestamp)
-a = m;
-}
+m0 = m = (a + b) >> 1;
+
+while (m < b &&
+ (frag_time = get_frag_time(frag_index, m, id)) ==
AV_NOPTS_VALUE)
+m++;
+
+if (m < b && frag_time <= timestamp)
+a = m;
+else
+b = m0;
}
+
return a;
}
As this fixes a hang, I will push this version soon.
Please mention ticket #7572 in the commit message.
Sure. Pushed.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
It is lucky that my patch works to ticket 7572. However, #7572 has a deeper
reason.
Mov demuxer consider that fragmented index is completed if a ‘sidx’ point
to the end of the file. But there may be other ‘sidx’ for other tracks. If
we skip the tail from there, we will missing the last ‘sidx’ and ‘moof’.
Then AV_NOPTS_VALUE occurs.
I tried to avoid skipping the tail simply. However, fate-test run failed on
mov-frag-encrypted.mp4.
BTW, I just got back from vacation. I am willing to follow an optimized
solution.
Thanks and Regards,
Chenhui
Carl Eugen Hoyos 于2019年2月11日周一 上午6:24写道：
> 2019-02-10 23:04 GMT+01:00, Marton Balint :
> >
> >
> > On Sun, 3 Feb 2019, Charles Liu wrote:
> >
> >> Binary searching would hang if the fragment items do NOT have timestamp
> >> for the specified stream.
> >>
> >> For example, a fmp4 consists of separated 'moof' boxes for each track,
> and
> >> separated 'sidx' for each segment, but no 'mfra' box.
> >> Then every fragment item only have the timestamp for one of its tracks.
> >>
> >> Signed-off-by: Charles Liu
> >> ---
> >> libavformat/mov.c | 21 -
> >> 1 file changed, 12 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/libavformat/mov.c b/libavformat/mov.c
> >> index 9b9739f788..35cb619e9f 100644
> >> --- a/libavformat/mov.c
> >> +++ b/libavformat/mov.c
> >> @@ -1266,7 +1266,7 @@ static int64_t get_frag_time(MOVFragmentIndex
> >> *frag_index,
> >> static int search_frag_timestamp(MOVFragmentIndex *frag_index,
> >> AVStream *st, int64_t timestamp)
> >> {
> >> -int a, b, m;
> >> +int a, b, m, m0;
> >> int64_t frag_time;
> >> int id = -1;
> >>
> >> @@ -1282,15 +1282,18 @@ static int
> search_frag_timestamp(MOVFragmentIndex
> >> *frag_index,
> >> b = frag_index->nb_items;
> >>
> >> while (b - a > 1) {
> >> -m = (a + b) >> 1;
> >> -frag_time = get_frag_time(frag_index, m, id);
> >> -if (frag_time != AV_NOPTS_VALUE) {
> >> -if (frag_time >= timestamp)
> >> -b = m;
> >> -if (frag_time <= timestamp)
> >> -a = m;
> >> -}
> >> +m0 = m = (a + b) >> 1;
> >> +
> >> +while (m < b &&
> >> + (frag_time = get_frag_time(frag_index, m, id)) ==
> >> AV_NOPTS_VALUE)
> >> +m++;
> >> +
> >> +if (m < b && frag_time <= timestamp)
> >> +a = m;
> >> +else
> >> +b = m0;
> >> }
> >> +
> >> return a;
> >> }
> >>
> >
> > As this fixes a hang, I will push this version soon.
>
> Please mention ticket #7572 in the commit message.
>
> Thank you, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
2019-02-10 23:04 GMT+01:00, Marton Balint :
>
>
> On Sun, 3 Feb 2019, Charles Liu wrote:
>
>> Binary searching would hang if the fragment items do NOT have timestamp
>> for the specified stream.
>>
>> For example, a fmp4 consists of separated 'moof' boxes for each track, and
>> separated 'sidx' for each segment, but no 'mfra' box.
>> Then every fragment item only have the timestamp for one of its tracks.
>>
>> Signed-off-by: Charles Liu
>> ---
>> libavformat/mov.c | 21 -
>> 1 file changed, 12 insertions(+), 9 deletions(-)
>>
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index 9b9739f788..35cb619e9f 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -1266,7 +1266,7 @@ static int64_t get_frag_time(MOVFragmentIndex
>> *frag_index,
>> static int search_frag_timestamp(MOVFragmentIndex *frag_index,
>> AVStream *st, int64_t timestamp)
>> {
>> -int a, b, m;
>> +int a, b, m, m0;
>> int64_t frag_time;
>> int id = -1;
>>
>> @@ -1282,15 +1282,18 @@ static int search_frag_timestamp(MOVFragmentIndex
>> *frag_index,
>> b = frag_index->nb_items;
>>
>> while (b - a > 1) {
>> -m = (a + b) >> 1;
>> -frag_time = get_frag_time(frag_index, m, id);
>> -if (frag_time != AV_NOPTS_VALUE) {
>> -if (frag_time >= timestamp)
>> -b = m;
>> -if (frag_time <= timestamp)
>> -a = m;
>> -}
>> +m0 = m = (a + b) >> 1;
>> +
>> +while (m < b &&
>> + (frag_time = get_frag_time(frag_index, m, id)) ==
>> AV_NOPTS_VALUE)
>> +m++;
>> +
>> +if (m < b && frag_time <= timestamp)
>> +a = m;
>> +else
>> +b = m0;
>> }
>> +
>> return a;
>> }
>>
>
> As this fixes a hang, I will push this version soon.
Please mention ticket #7572 in the commit message.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
On Sun, 3 Feb 2019, Charles Liu wrote:
Binary searching would hang if the fragment items do NOT have timestamp for the
specified stream.
For example, a fmp4 consists of separated 'moof' boxes for each track, and
separated 'sidx' for each segment, but no 'mfra' box.
Then every fragment item only have the timestamp for one of its tracks.
Signed-off-by: Charles Liu
---
libavformat/mov.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9b9739f788..35cb619e9f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1266,7 +1266,7 @@ static int64_t get_frag_time(MOVFragmentIndex *frag_index,
static int search_frag_timestamp(MOVFragmentIndex *frag_index,
AVStream *st, int64_t timestamp)
{
-int a, b, m;
+int a, b, m, m0;
int64_t frag_time;
int id = -1;
@@ -1282,15 +1282,18 @@ static int search_frag_timestamp(MOVFragmentIndex
*frag_index,
b = frag_index->nb_items;
while (b - a > 1) {
-m = (a + b) >> 1;
-frag_time = get_frag_time(frag_index, m, id);
-if (frag_time != AV_NOPTS_VALUE) {
-if (frag_time >= timestamp)
-b = m;
-if (frag_time <= timestamp)
-a = m;
-}
+m0 = m = (a + b) >> 1;
+
+while (m < b &&
+ (frag_time = get_frag_time(frag_index, m, id)) ==
AV_NOPTS_VALUE)
+m++;
+
+if (m < b && frag_time <= timestamp)
+a = m;
+else
+b = m0;
}
+
return a;
}
As this fixes a hang, I will push this version soon. Can be optimized
later to pure binary search, if anybody is still interested.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
Binary searching would hang if the fragment items do NOT have timestamp for the
specified stream.
For example, a fmp4 consists of separated 'moof' boxes for each track, and
separated 'sidx' for each segment, but no 'mfra' box.
Then every fragment item only have the timestamp for one of its tracks.
Signed-off-by: Charles Liu
---
libavformat/mov.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9b9739f788..35cb619e9f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1266,7 +1266,7 @@ static int64_t get_frag_time(MOVFragmentIndex *frag_index,
static int search_frag_timestamp(MOVFragmentIndex *frag_index,
AVStream *st, int64_t timestamp)
{
-int a, b, m;
+int a, b, m, m0;
int64_t frag_time;
int id = -1;
@@ -1282,15 +1282,18 @@ static int search_frag_timestamp(MOVFragmentIndex
*frag_index,
b = frag_index->nb_items;
while (b - a > 1) {
-m = (a + b) >> 1;
-frag_time = get_frag_time(frag_index, m, id);
-if (frag_time != AV_NOPTS_VALUE) {
-if (frag_time >= timestamp)
-b = m;
-if (frag_time <= timestamp)
-a = m;
-}
+m0 = m = (a + b) >> 1;
+
+while (m < b &&
+ (frag_time = get_frag_time(frag_index, m, id)) ==
AV_NOPTS_VALUE)
+m++;
+
+if (m < b && frag_time <= timestamp)
+a = m;
+else
+b = m0;
}
+
return a;
}
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
