[FFmpeg-devel] [PATCH] Make the process of uuid-xmp atom faster.

[Chen Meng]

Yes, this change is intended.

Previously, the mov_read_uuid always read the uuid-xmp byte by byte even if, c->export_xmp == false, it’s no need to export xmp data by default.
It’s OK for a small size uuid-xmp atom. But for a large size of that atom, which is, for example, exported by non-linear editing system like Premiere, it’s really cost a lot of time.
One of mov file I met has a 56MB uuid-xmp atom, which ffmpeg takes about 5 minutes to operate it in network job.

So, for speeding up, I take the avio_read only if needed, which probe the large size of uuid-xmp atom mov file in seconds.

    On Fri, Nov 11, 2016 at 11:42:26AM +0800, Chen Meng wrote:
    > Ya. It’s really annoying everyone using patchwork. (So loooong text.) I’m trying to fix it.
    > Please use my name, Chen Meng, if nothing changed in a short time.
    > 
    > 2016-11-11 10:36 GMT+08:00 Chen Meng <mengchen.mc at alibaba-inc.com>:
    > ---
    >  libavformat/mov.c | 32 ++++++++++++++++++--------------
    >  1 file changed, 18 insertions(+), 14 deletions(-)
    > 
    > diff --git a/libavformat/mov.c b/libavformat/mov.c
    > index 9ec7d03..436c234 100644
    > --- a/libavformat/mov.c
    > +++ b/libavformat/mov.c
    > @@ -4549,24 +4549,28 @@ static int mov_read_uuid(MOVContext *c, AVIOContext *pb, MOVAtom atom)
    >      } else if (!memcmp(uuid, uuid_xmp, sizeof(uuid))) {
    >          uint8_t *buffer;
    >          size_t len = atom.size - sizeof(uuid);
    > -
    > -        buffer = av_mallocz(len + 1);
    > -        if (!buffer) {
    > -            return AVERROR(ENOMEM);
    > -        }
    > -        ret = avio_read(pb, buffer, len);
    > -        if (ret < 0) {
    > -            av_free(buffer);
    > -            return ret;
    > -        } else if (ret != len) {
    > -            av_free(buffer);
    > -            return AVERROR_INVALIDDATA;
    [...]
    > +            ret = avio_skip(pb, len);
    > +            if (ret < 0)
    > +                return ret;
    
    this treats ret != len differently than before
    is that intended ?
    
    [...]
    -- 
    Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
    
    Does the universe only have a finite lifespan? No, its going to go on
    forever, its just that you wont like living in it. -- Hiranya Peiri
    _______________________________________________
    ffmpeg-devel mailing list
    ffmpeg-devel at ffmpeg.org
    http://ffmpeg.org/mailman/listinfo/ffmpeg-devel