[FFmpeg-devel] libavformat/mov: Speed up fragmented mp4 parsing

Submitted by Aaron Boushley on Nov. 5, 2018, 7:17 p.m.

Details

Message ID CA+uH8NOmKu59tEncp6NmrRPbiM6zLRZ01uq30FawynxXG1vGrA@mail.gmail.com
State New
Headers show

Commit Message

Aaron Boushley Nov. 5, 2018, 7:17 p.m.
When parsing a fragmented MP4 with the use_mfra_for option set so that
the mfra box is parsed we currently continue to parse all the top level
boxes in the mp4. We also avoid using the index in mov_seek_fragment
unless the fragment index is marked as complete, which the mfra parsing
code never does.

This updates the mfra parsing code to mark the fragment index as
complete, similar to the way the sidx parsing code does.

With this change in place mov_read_default stops parsing top level boxes
in a fragmented mp4 and uses the mfra data for mov_seek_fragment calls
(assuming a use_mfra_for option is passed). When loading the file over a
network this results in significantly better performance since
avformat_open_input doesn't require a scan of the entire file.

Signed-off-by: Aaron Boushley <boushley@gmail.com>
---
 libavformat/mov.c | 2 ++
 1 file changed, 2 insertions(+)

     seek_ret = avio_seek(f, original_pos, SEEK_SET);

Comments

Michael Niedermayer Nov. 5, 2018, 10:20 p.m.
On Mon, Nov 05, 2018 at 11:17:25AM -0800, Aaron Boushley wrote:
> When parsing a fragmented MP4 with the use_mfra_for option set so that
> the mfra box is parsed we currently continue to parse all the top level
> boxes in the mp4. We also avoid using the index in mov_seek_fragment
> unless the fragment index is marked as complete, which the mfra parsing
> code never does.
> 
> This updates the mfra parsing code to mark the fragment index as
> complete, similar to the way the sidx parsing code does.
> 
> With this change in place mov_read_default stops parsing top level boxes
> in a fragmented mp4 and uses the mfra data for mov_seek_fragment calls
> (assuming a use_mfra_for option is passed). When loading the file over a
> network this results in significantly better performance since
> avformat_open_input doesn't require a scan of the entire file.
> 
> Signed-off-by: Aaron Boushley <boushley@gmail.com>
> ---
>  libavformat/mov.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index ec57a05803..1def594626 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -7344,6 +7344,8 @@ static int mov_read_mfra(MOVContext *c, AVIOContext
> *f)
>          if (ret < 0)

patch is corrupted by a newline

[...]
Aaron Boushley Nov. 5, 2018, 11:03 p.m.
On Mon, Nov 5, 2018 at 2:21 PM Michael Niedermayer
<michael@niedermayer.cc> wrote:
>
> On Mon, Nov 05, 2018 at 11:17:25AM -0800, Aaron Boushley wrote:
> > When parsing a fragmented MP4 with the use_mfra_for option set so that
> > the mfra box is parsed we currently continue to parse all the top level
> > boxes in the mp4. We also avoid using the index in mov_seek_fragment
> > unless the fragment index is marked as complete, which the mfra parsing
> > code never does.
> >
> > This updates the mfra parsing code to mark the fragment index as
> > complete, similar to the way the sidx parsing code does.
> >
> > With this change in place mov_read_default stops parsing top level boxes
> > in a fragmented mp4 and uses the mfra data for mov_seek_fragment calls
> > (assuming a use_mfra_for option is passed). When loading the file over a
> > network this results in significantly better performance since
> > avformat_open_input doesn't require a scan of the entire file.
> >
> > Signed-off-by: Aaron Boushley <boushley@gmail.com>
> > ---
> >  libavformat/mov.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index ec57a05803..1def594626 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -7344,6 +7344,8 @@ static int mov_read_mfra(MOVContext *c, AVIOContext
> > *f)
> >          if (ret < 0)
>
> patch is corrupted by a newline
What's the best way to address this, submit a new patch email thread?
Or is there a way to fix this thread?
[...]

Aaron
Carl Eugen Hoyos Nov. 5, 2018, 11:07 p.m.
2018-11-06 0:03 GMT+01:00, Aaron Boushley <aaron@boushley.com>:
> On Mon, Nov 5, 2018 at 2:21 PM Michael Niedermayer
> <michael@niedermayer.cc> wrote:

>> > diff --git a/libavformat/mov.c b/libavformat/mov.c
>> > index ec57a05803..1def594626 100644
>> > --- a/libavformat/mov.c
>> > +++ b/libavformat/mov.c
>> > @@ -7344,6 +7344,8 @@ static int mov_read_mfra(MOVContext *c,
>> > AVIOContext
>> > *f)
>> >          if (ret < 0)
>>
>> patch is corrupted by a newline
> What's the best way to address this, submit a new patch email thread?
> Or is there a way to fix this thread?

Send the patch again as an attachment instead of inlined.

Carl Eugen
Aaron Boushley Nov. 5, 2018, 11:25 p.m.
On Mon, Nov 5, 2018 at 3:13 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>
> 2018-11-06 0:03 GMT+01:00, Aaron Boushley <aaron@boushley.com>:
> > On Mon, Nov 5, 2018 at 2:21 PM Michael Niedermayer
> > <michael@niedermayer.cc> wrote:
>
> >> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> >> > index ec57a05803..1def594626 100644
> >> > --- a/libavformat/mov.c
> >> > +++ b/libavformat/mov.c
> >> > @@ -7344,6 +7344,8 @@ static int mov_read_mfra(MOVContext *c,
> >> > AVIOContext
> >> > *f)
> >> >          if (ret < 0)
> >>
> >> patch is corrupted by a newline
> > What's the best way to address this, submit a new patch email thread?
> > Or is there a way to fix this thread?
>
> Send the patch again as an attachment instead of inlined.

Let me know if there's any problems with this one.

Aaron
Aaron Boushley Nov. 5, 2018, 11:29 p.m.
On Mon, Nov 5, 2018 at 3:25 PM Aaron Boushley <aaron@boushley.com> wrote:
>
> On Mon, Nov 5, 2018 at 3:13 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> >
> > 2018-11-06 0:03 GMT+01:00, Aaron Boushley <aaron@boushley.com>:
> > > On Mon, Nov 5, 2018 at 2:21 PM Michael Niedermayer
> > > <michael@niedermayer.cc> wrote:
> >
> > >> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > >> > index ec57a05803..1def594626 100644
> > >> > --- a/libavformat/mov.c
> > >> > +++ b/libavformat/mov.c
> > >> > @@ -7344,6 +7344,8 @@ static int mov_read_mfra(MOVContext *c,
> > >> > AVIOContext
> > >> > *f)
> > >> >          if (ret < 0)
> > >>
> > >> patch is corrupted by a newline
> > > What's the best way to address this, submit a new patch email thread?
> > > Or is there a way to fix this thread?
> >
> > Send the patch again as an attachment instead of inlined.
>
> Let me know if there's any problems with this one.

Looks like https://patchwork.ffmpeg.org/patch/10942/ didn't update
with the attached version, so I'm going to try a new thread.

Aaron

Patch hide | download patch | download mbox

diff --git a/libavformat/mov.c b/libavformat/mov.c
index ec57a05803..1def594626 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -7344,6 +7344,8 @@  static int mov_read_mfra(MOVContext *c, AVIOContext
*f)
         if (ret < 0)
             goto fail;
     } while (!ret);
+
+    c->frag_index.complete = 1;
     ret = 0;
 fail: